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

From

Petr Novopashenniy (2:5020/400)

To

Eugene Grosbein

Date

2009-10-01T15:33Z

Area

RU.CISCO

From: Petr Novopashenniy <pety@rusnet.ru>


On Thu, 1 Oct 2009, Eugene Grosbein wrote:

EG> 01 окт 2009, четверг, в 12:05 KRAT, Petr Novopashenniy написал(а):
EG> 
EG>  EG>> Я в курсе проблем телекомов, связанных с peer fraud. Это их проблемы
EG>  EG>> и они их должны решать.
EG>  PN> Дык, решают! ;)
EG> 
EG> Я вижу, как они решают.

Там есть еще один бонус для них - клиенту отдается максимум трафика. ;)
Так что с решением сильно торопиться не будут.

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

Э... Это Вы про себя? 
:))

Честно говоря не понял что Вы хотели сказать про экономию от IX.

EG> Дропать пакеты, оно конечно проще. Но это неправильное решение :-)
EG> 
EG>  PN>> Это в любом случае, или 
EG>  PN>> только тогда когда трафик на этот специфик получен от пиров/аплинков,
EG>  PN> а 
EG>  PN>> если от другого клиента, то по специфику, даже если он на клиента (для
EG>  PN>> которого трафик) не смотрит?
EG>  EG>> 
EG>  EG>> В любом случае. Если оператор не намерен использовать специфик
EG>  EG>> в сторону пира,
EG>  PN> Только в случае если трафик на специфик приходит от пиров/аплинков, а так 
EG>  PN> - намерен, почему бы и нет?
EG> 
EG> А кто тут приводил примеры с лупами и петлями? :-)
EG> Вот чтобы их не было, потому и нет.
Лупы (r/l) и петли - это когда тот самый PBR (из статьи) у 
транзитных операторов будет криво настроен (или у одного настроен, а у 
другого - нет). А так routing loops (r/l) не будет (так и есть сейчас), а 
геграфические петли гоаздо меньше, чем могли бы быть при кривом PBR.


Что-то сложно уже получается. Нужно у операторов транзита вводить PBR, да 
еще каким-то способом вырезать из анонсов к клиентам некотрые специфики.

Кстати, а кто из операторов обязан (ну если помечтать) у себя этот PBR 
реализовывать? Мне думается тот, кто предоставляет IP транзит другим 
операторам.
Судя по объекту AS29072 из RIPE, Вы тоже предоставляете. Чем Ваши клиенты 
хуже, если попадут в аналогичную ситуацию, только с Вами?


EG> 
EG>  EG>> он его не должен анонсировать своим клиентам
EG>  EG>> доступность специфика через этого пира. Анонсировать только доступное.
EG>  PN> Почему? От своих клиентов, которым оператор дает транзит, он этот трафик 
EG>  PN> вполне может отправить на специфик, для клиентов он вполне доступен.
EG> 
EG> Лупы неизбежны, а это не называется "вполне доступен".
Почему? Вот если взять ситуацию как сейчас (нет никаких PBR). Лупов ведь 
нет (я про r/l). Я почти уверен, что если Вы снимите специфики с РТКом, то 
связи с сетями самого Ростелекома (12389) и его клиентами Вы не 
потеряете. Так что для клиентов вполне доступен. Но да, с большой 
географической петлей видимо через зарубеж.

В Ростелекоме AS-PATH на этот специфик будет каким-нибудь таким:

12389 <...> 20485 21127 29072

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

;)

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

Боюсь в какой-то момент мы неправильно поняли друг друга. loop'ы и петли 
будут тогда, когда такой PBR из статьи будет настроен не у всех операторов 
транзита. А если такого PBR нет, то и r/l от спецификов не будет.

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

Ну это я тоже, так, в сторону.

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

Как так, само?!! ;)))

EG> 
EG>  EG>> 6684 не будет иметь специфика
EG>  EG>> через 12389 и проблема не возникнет.
EG>  PN> Каким способом будет решаться, какие специфики отдавать клиенту, а какие 
EG>  PN> нет?
EG> 
EG> Не моя проблема :-) Если буду работать в Ростелекоме ;-) что-нибудь
EG> придумаю, а пока есть проблемы своего уровня, на которые время тратить.

Как в таких случаях говорят магистралы, пока у Вас не появятся клиенты, 
которые захотят странного. ;)

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

Без PBR - без проблем!

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

Вам еще повезло, а то бывают и такие реальные ситуации, когда у Вас два 
аплинка, и один сразу же клиент второго. Вот и балансируйте тогда ;).


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