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

From

Eugene Grosbein (2:5006/1)

To

Petr Novopashenniy

Date

2009-10-01T16:55:52Z

Area

RU.CISCO

Reply-To: eugen@grosbein.pp.ru

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

 EG>> Я в курсе проблем телекомов, связанных с peer fraud. Это их проблемы
 EG>> и они их должны решать.
 PN> Дык, решают! ;)

Я вижу, как они решают.

 EG>> И вовсе не дропом пакетов. Принцип
 EG>> "анонсировать только достижимое" должен быть непокоб^Нлебим.
 PN> "анонсировать только достижимое" - очень расплывчатая формулировка. Как 
 PN> это делать на деле?

А вот это уже проблема оператора. Всякие хитрые фильтры там,
пусть об этом голова болит у того, кто хочет себе канал сэкономить от IX.
Дропать пакеты, оно конечно проще. Но это неправильное решение :-)

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

А кто тут приводил примеры с лупами и петлями? :-)
Вот чтобы их не было, потому и нет.

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

Лупы неизбежны, а это не называется "вполне доступен".

 PN> И к тому же, full view есть full view. ;)

Можно подумать-можно подумать :-)
Тогда уж надо пиров кормить трафиком по full view, если во главу угла
его ставить.

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

Если политика не реализуется средствами BGP, приходится привлекать
сторонние средства. Ну или от политики отказываться :-))

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

Чтобы не было routing loop и петель.

 PN>> Либо дополнительная петля:
 PN>> 12389 видит, что точка входа трафика на этот специфик его клиент 6684,
 PN> и 
 PN>> отправляет этот трафик уже по нему своим пирам/аплинкам. При этом
 PN> трафик 
 PN>> может пройти туда-обратно через всю страну.
 EG>> Можно подумать, сейчас трафик не ходит аж "через зарубеж", не говоря уже
 EG>> о "через всю страну"... Но это так, в сторону.
 PN> Зато по тому AS-PATH, который получает Ваш роутер.
 PN> Кстати, ради балансировки каналов Вы портите себе связность. Полагаю те 
 PN> самые vestu.ru через Ростелеком доступны без выхода зарубеж.
 PN> Тут уж нужно решить, что важнее, балансировка или кол-во петель.

А это совершенно другой вопрос, балансировка исходящего трафика.
Я говорил пока только о входящем. И кстати говоря, сегодня вот
трассировка от меня туда уже идет через 6684, на несколько хопов короче
и идет по прямому маршруту через 12389, MSK-IX и сразу к 25292 (vesti.ru).

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

Не моя проблема :-) Если буду работать в Ростелекоме ;-) что-нибудь
придумаю, а пока есть проблемы своего уровня, на которые время тратить.

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

До /24 включительно.

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

А как же петли и циклы? :-)

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

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

Ну и будет пустой канал, ага. Я уж лучше спецификами...

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