Re: балансировка BGP

From

Eugene Grosbein (2:5006/1)

To

Petr Novopashenniy

Date

2009-10-01T14:56:36Z

Area

RU.CISCO

Reply-To: eugen@grosbein.pp.ru

01 окт 2009, четверг, в 10:03 KRAT, Petr Novopashenniy написал(а):

 PN>>> Ростелеком или Ретн, получая такой трафик с MSK-IX, не хотят его
 PN>> отдавать 
 PN>>> на свои аплинки (Ростелеком) и на свои пиры (Ретн, имеющий пиринг с
 PN>> ТТК 
 PN>>> 20485).
 EG>>> Вот этого я не понимаю. Трафик с MSK-IX к ним приходит, видимо,
 EG>>> потому что они анонсируют доступность IP-адреса через себя?
 PN>> Да. А как же еще? ;)
 EG>>> И что они делают с пакетом, пришедшим к ним от MSK-IX и имеющим далее
 EG>>> более специфичный маршрут в ТТК AS20485?
 PN>> Дропают.
 EG>> Это замечательная доступность. Просто великолепная.
 EG>> А какого, спрашивается, дропать?.. Если анонсируешь доступность через
 EG>> себя.
 EG>> Или не анонсируй, или пропускай. "По-моему, так."

 PN> А что Вы предлагаете сделать с таким пакетом?
 PN> Пускать по специфику?
 PN> Чтобы было понятней, попробую привести более глобальный пример.

[skip пример]

Я в курсе проблем телекомов, связанных с peer fraud. Это их проблемы
и они их должны решать. И вовсе не дропом пакетов. Принцип
"анонсировать только достижимое" должен быть непокоб^Нлебим.

 PN> Пускать по агрегату, который смотрит на клиента (игнорировать 
 PN> его специфики, которые смотрят не на клиента)?

По-моему, это очевидно - если оператор анонсирует доступность
сети через себя, при этом не намерен пускать трафик через пира
и имеет другой маршрут через своего клиента, надо пускать через клиента.

 PN> Это в любом случае, или 
 PN> только тогда когда трафик на этот специфик получен от пиров/аплинков, а 
 PN> если от другого клиента, то по специфику, даже если он на клиента (для 
 PN> которого трафик) не смотрит?

В любом случае. Если оператор не намерен использовать специфик
в сторону пира, он его не должен анонсировать своим клиентам
доступность специфика через этого пира. Анонсировать только доступное.

 PN> В этом случае это уже маршрутизация не на основе BGP, а некий PBR 
 PN> основанный на данных, полученых в том числе и от BGP.

Дык в статье по указанному URL и описывается самый натуральный
policy-based routing, когда таблица маршрутизации выбирается в зависимости
от точки входа трафика в операторскую сеть.

 PN> Тут тоже есть 
 PN> проблемы. В Вашем случае, к примеру, все три AS 9002 12389 6684 должны 
 PN> иметь одинаковую политику в отношении таких случаев.
 PN> Иначе либо routing loop:
 PN> Например, 6684 видит лучший маршрут на Ваш специфик через 12389. 12389 
 PN> отдает Ваш трафик на агрегат в сторону 6684. А 6684 отдает его 
 PN> обратно по специфику 12389 (это если в 12389 не учитывается точка входа - 
 PN> клиент/не клиент).

routing loop не будет просто потому что 6684 не должен получить
специфик от 12389, об этом выше написал.

 PN> Либо дополнительная петля:
 PN> 12389 видит, что точка входа трафика на этот специфик его клиент 6684, и 
 PN> отправляет этот трафик уже по нему своим пирам/аплинкам. При этом трафик 
 PN> может пройти туда-обратно через всю страну.

Можно подумать, сейчас трафик не ходит аж "через зарубеж", не говоря уже
о "через всю страну"... Но это так, в сторону. 6684 не будет иметь специфика
через 12389 и проблема не возникнет.

 PN> Диагностика таких проблем будет еще более сложна. Когда получаешь full 
 PN> view несколько расчитываешь, что трафик на принятые префиксы пойдет 
 PN> именно по известному по BGP AS-PATH.

Когда отдаешь анонс без communities, несколько расчитываешь,
что префикс будет доступен отовсюду.

 PN> А из последнего примера видно, что 
 PN> Ваши специфики по BGP будут отдаваться всем клиентам (РТКом'а, 
 PN> Ростелекома, Ретна), но трафик к ним пойдет совсем не по тому AS-PATH.

Специфики не должны отдаваться клиентам, раз уж трафик по ним не хочется
маршрутизировать.

 PN> То что там написано не является стандартом и обязателным к исполнению 
 PN> всеми операторами. Я дал эту ссылку исключительно как материал для 
 PN> размышлений. А также там есть слова:

 PN> Another one is from Cisco-land: QPPB. There's a quite cool method 
 PN> described in details in another NANOG presentation: 
 PN> http://www.nanog.org/meetings/nanog42/presentations/DavidSmith-PeeringPolicyEnforcement.pdf.

 PN> These solutions can deal with the problem, but there's a catch. They are 
 PN> designed to drop traffic when a peer tries to defraud us. This is a 
 PN> problem, because even unintentional misconfiguration (say, a sloppy 
 PN> attempt at traffic engineering) will result in service disruption. It 
 PN> would be nice, if we could handle it better and somehow ignore 
 PN> fraudulent/erroneous routes.

В общем, по принципу "спасение утопающих дело рук самих утопающих",
реально остается только ужасное решение в виде conditional advertisement
и молиться, что сессии не будут рваться слишком часто...

Eugene
-- 
Собак ножами режете, а это бандитизьм.
--- slrn/0.9.8.1 (FreeBSD)
 * Origin: Svyaz Service JSC (2:5006/1@fidonet)
SEEN-BY: 50/204 450/1024 461/43 640 465/11 469/142 999 4625/8 4641/444
SEEN-BY: 5000/5000 5006/1 5007/1 5010/70 5011/13 5012/46 5015/28 5019/26
SEEN-BY: 5020/175 400 545 982 1521 2238 4441 5021/29 5025/3 5026/14 5027/12
SEEN-BY: 5030/1080 5034/13 5035/38 5036/1 5037/28 5045/7 5049/1 5054/1 4 8 9
SEEN-BY: 5054/28 30 36 37 67 75 81 89 5060/88 5061/15 5062/10 5063/3 5066/18
SEEN-BY: 5075/35 5077/70 5080/68 5084/9 5085/13 5095/20 5096/18 6001/10 6004/3
SEEN-BY: 6009/3

PATH: 5006/1 5020/400 545 5054/1 37