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

From

Eugene Grosbein (2:5006/1)

To

Petr Novopashenniy

Date

2009-10-01T23:07:46Z

Area

RU.CISCO

Reply-To: eugen@grosbein.pp.ru

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

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

Дык никому и не предлагается перевес делать в сторону пиров.

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

Ну там же проблема в том, что жалко ширины "внешнего" канала/канала от IX,
нет? Ладно, проехали с экономией.

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

Вообще говоря, PBR там или не PBR внутри у операторской железки,
это сугубо его интимное дело. Лишь бы циклов не устраивал
и не дропал пакеты, пришедшие на пропущенный собственными
BGP-роутерами анонсы. Всякие там статьи, как справедливо замечено,
ему не указ, а максимум hint. Вот пусть обхинтуется и придумает.
А routing loop или дропы ("как и есть сейчас"), для пинга-то всё едино.

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

А кто говорил, что хитрые политики будет легко реализовывать?
Это только платежи принимать легко ;-)

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

А уже приходилось разруливать ид^W неумные политики коммерсов,
но мне PBR строить не страшно. Масштабы только не те, да :-)

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

Потому что дропать нельзя, роутить.

 PN> Вот если взять ситуацию как сейчас (нет никаких PBR).

PBR там как раз есть, в Null0.

 PN> Лупов ведь нет (я про r/l).

Дропы ничуть не лучше.

 PN> Я почти уверен, что если Вы снимите специфики с РТКом, то 
 PN> связи с сетями самого Ростелекома (12389) и его клиентами Вы не 
 PN> потеряете. Так что для клиентов вполне доступен. Но да, с большой 
 PN> географической петлей видимо через зарубеж.

А в договоре не сказано, что доступен только 12389 и его клиенты,
да и про недоступность vesti.ru тоже как-то забыли упомянуть, вот беда.

 EG>>> routing loop не будет просто потому что 6684 не должен получить
 EG>>> специфик от 12389, об этом выше написал.
 PN>> Почему в данном случае 12389 не должен отдавать этот специфик своему 
 PN>> клиенту?
 EG>> Чтобы не было routing loop и петель.
 PN> Боюсь в какой-то момент мы неправильно поняли друг друга. loop'ы и петли 
 PN> будут тогда, когда такой PBR из статьи будет настроен не у всех операторов
 PN> 
 PN> транзита. А если такого PBR нет, то и r/l от спецификов не будет.

Пропуск трафика, пришедшего на анонсируемый маршрут,
должен выполняться оператором безусловно, этот постулат обсуждению
не подлежит. Из этого и нежелания маршрутизировать трафик пиру по специфику
сразу следует обязанность маршрутизировать его по агрегату
клиенту, пока такой агрегат от клиента принимается. Из этого и необходимости
недопущения циклов сразу следует необходимость не анонсировать специфик
клиенту, несмотря ни на какой full view. Либо игнорирование
специфика от пира, либо самый фулл view клиенту, одно из двух.

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

Да, совершенно само. Это Internet, здесь могут посл^H^Нменяться маршруты.

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

Уже были.

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

С дропами это не "без проблем".

 EG>> Ну и будет пустой канал, ага. Я уж лучше спецификами...
 PN> Вам еще повезло, а то бывают и такие реальные ситуации, когда у Вас два 
 PN> аплинка, и один сразу же клиент второго. Вот и балансируйте тогда ;).

Было и такое. Условные анонсирования тогда же и выучил, ага.

Eugene
-- 
прибыла в pageout processgroup апача
в группе были перлы, пэхэпа
группа занималась черными делами
и за ней следило ФПЧа (static void free_proc_chain)
--- 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