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

From

Petr Novopashenniy (2:5020/400)

To

Eugene Grosbein

Date

2009-10-01T13:05:40Z

Area

RU.CISCO

From: Petr Novopashenniy <pety@rusnet.ru>


On Thu, 1 Oct 2009, Eugene Grosbein wrote:

EG> 01 окт 2009, четверг, в 10:03 KRAT, Petr Novopashenniy написал(а):
EG> 
EG>  PN>>> Ростелеком или Ретн, получая такой трафик с MSK-IX, не хотят его
EG>  PN>> отдавать 
EG>  PN>>> на свои аплинки (Ростелеком) и на свои пиры (Ретн, имеющий пиринг с
EG>  PN>> ТТК 
EG>  PN>>> 20485).
EG>  EG>>> Вот этого я не понимаю. Трафик с MSK-IX к ним приходит, видимо,
EG>  EG>>> потому что они анонсируют доступность IP-адреса через себя?
EG>  PN>> Да. А как же еще? ;)
EG>  EG>>> И что они делают с пакетом, пришедшим к ним от MSK-IX и имеющим далее
EG>  EG>>> более специфичный маршрут в ТТК AS20485?
EG>  PN>> Дропают.
EG>  EG>> Это замечательная доступность. Просто великолепная.
EG>  EG>> А какого, спрашивается, дропать?.. Если анонсируешь доступность через
EG>  EG>> себя.
EG>  EG>> Или не анонсируй, или пропускай. "По-моему, так."
EG> 
EG>  PN> А что Вы предлагаете сделать с таким пакетом?
EG>  PN> Пускать по специфику?
EG>  PN> Чтобы было понятней, попробую привести более глобальный пример.
EG> 
EG> [skip пример]
EG> 
EG> Я в курсе проблем телекомов, связанных с peer fraud. Это их проблемы
EG> и они их должны решать.

Дык, решают! ;)

EG> И вовсе не дропом пакетов. Принцип
EG> "анонсировать только достижимое" должен быть непокоб^Нлебим.

"анонсировать только достижимое" - очень расплывчатая формулировка. Как 
это делать на деле?

EG> 
EG>  PN> Пускать по агрегату, который смотрит на клиента (игнорировать 
EG>  PN> его специфики, которые смотрят не на клиента)?
EG> 
EG> По-моему, это очевидно - если оператор анонсирует доступность
EG> сети через себя, при этом не намерен пускать трафик через пира
EG> и имеет другой маршрут через своего клиента, надо пускать через клиента.

Оказывается, это совсем не очевидно.

EG> 
EG>  PN> Это в любом случае, или 
EG>  PN> только тогда когда трафик на этот специфик получен от пиров/аплинков, а 
EG>  PN> если от другого клиента, то по специфику, даже если он на клиента (для 
EG>  PN> которого трафик) не смотрит?
EG> 
EG> В любом случае. Если оператор не намерен использовать специфик
EG> в сторону пира,
Только в случае если трафик на специфик приходит от пиров/аплинков, а так 
- намерен, почему бы и нет?

EG> он его не должен анонсировать своим клиентам
EG> доступность специфика через этого пира. Анонсировать только доступное.
Почему? От своих клиентов, которым оператор дает транзит, он этот трафик 
вполне может отправить на специфик, для клиентов он вполне доступен. И к 
тому же, full view есть full view. ;)

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

Да. Но кто сказал, что это абсолютно верное решение?

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

Почему в данном случае 12389 не должен отдавать этот специфик своему 
клиенту?

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

Зато по тому AS-PATH, который получает Ваш роутер.

Кстати, ради балансировки каналов Вы портите себе связность. Полагаю те 
самые vestu.ru через Ростелеком доступны без выхода зарубеж.
Тут уж нужно решить, что важнее, балансировка или кол-во петель.

EG> 6684 не будет иметь специфика
EG> через 12389 и проблема не возникнет.

Каким способом будет решаться, какие специфики отдавать клиенту, а какие 
нет?

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

Да, если это не специфик.

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

Для клиентов - хочется!

EG> 
EG>  PN> То что там написано не является стандартом и обязателным к исполнению 
EG>  PN> всеми операторами. Я дал эту ссылку исключительно как материал для 
EG>  PN> размышлений. А также там есть слова:
EG> 
EG>  PN> Another one is from Cisco-land: QPPB. There's a quite cool method 
EG>  PN> described in details in another NANOG presentation: 
EG>  PN> http://www.nanog.org/meetings/nanog42/presentations/DavidSmith-PeeringPolicyEnforcement.pdf.
EG> 
EG>  PN> These solutions can deal with the problem, but there's a catch. They are 
EG>  PN> designed to drop traffic when a peer tries to defraud us. This is a 
EG>  PN> problem, because even unintentional misconfiguration (say, a sloppy 
EG>  PN> attempt at traffic engineering) will result in service disruption. It 
EG>  PN> would be nice, if we could handle it better and somehow ignore 
EG>  PN> fraudulent/erroneous routes.
EG> 
EG> В общем, по принципу "спасение утопающих дело рук самих утопающих",
EG> реально остается только ужасное решение в виде conditional advertisement
EG> и молиться, что сессии не будут рваться слишком часто...

Да, в реальной жизни именно так.

А если все таки говорить о Вашей проблеме с балансировкой, то смотря на 
ситуацию сейчас, Ваши анонсы через РТКомм в мире практически отсутствуют, 
если агрегат это 62.231.160.0/19. Если при этом входящего трафика через 
РТКомм все равно много, значит там много трафика с MSK-IX. У Ростелекома 
есть community, чтобы не анонсироваться туда, попробуйте, трафик должен 
сильно упасть (на RS MSK-IX Ваших анонсов через Ретн сегодня нет).

Petr Novopashenniy
--- ifmail v.2.15dev5.4
 * Origin: NPO RUSnet InterNetNews site (2:5020/400)
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: 5020/400 545 5054/1 37