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

From

Eugene Grosbein (2:5006/1)

To

Petr Novopashenniy

Date

2009-10-05T09:43:16Z

Area

RU.CISCO

Reply-To: eugen@grosbein.pp.ru

02 окт 2009, пятница, в 14:46 KRAT, Petr Novopashenniy написал(а):

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

Придумали дропать пакеты. Замечательная придумка.
Придумывать надо, как обеспечивать транзит для анонсируемых префиксов.
Или как их не анонсировать. Одно из двух, третьего быть не должно.

 PN>> Что-то сложно уже получается. Нужно у операторов транзита вводить PBR,
 PN> да 
 PN>> еще каким-то способом вырезать из анонсов к клиентам некотрые
 PN> специфики.
 EG>> А кто говорил, что хитрые политики будет легко реализовывать?
 EG>> Это только платежи принимать легко ;-)
 PN> Хитрые политики требуют хитрых платежей. ;)

За услугу уже уплочено, надо отрабатывать.

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

В том и дело, что отсутствие дропов должен предоставлять общий подход.
Масштабы не оправдывают косорукость.

 PN> Введение PBR на сети магистральных 
 PN> операторов поломает много годами работающих схем. Все-таки у нас 
 PN> глобальная маршрутизация в Inet делается посредством BGP. PBR же будет 
 PN> вести себя совсем несколько по другому. Да, при IPv6 с таким PBR там 
 PN> будет совсем весело.

Каким именно способом будет обеспечена маршрутизация трафик на анонсируемые
сети - PBR или фильтрацией анонсов или святым духом - всё равно.
Если кому-то свербит маршрутизировать трафик в зависимости
от его точки входа, пусть реализует это полностью.

 PN> Вот небольшой пример с уже упоминавшимся Релкомом и его старой доброй 
 PN> сетью 193.124.0.0/15 (ALLOCATED UNSPECIFIED). Там есть ~55 спецификов, как
 PN> 
 PN> из России, так и из Украины. Relcom анонсирует в мир и на MSK-IX агрегат.
 PN> Большинство операторов, имеющих эти специфики, имеют собственные 
 PN> альтернативные каналы связи - пиринги и транзиты. В мире большинство этих 
 PN> спецификов видны напрямую, без транзита через Релком. Но на MSK-IX многих 
 PN> этих спецификов нет вообще. Нет, связность у таких как vesti.ru 
 PN> без full view останется, Релком предоставит транизт через себя. Т.е. 
 PN> трафик пойдет по агрегату через MSK-IX в Релком, а тот уже его отправит по
 PN> 
 PN> специфику черз своих АПЛИНКОВ. Для примера брал 193.124.54.0/24


 PN> А теперь включим наш PBR у аплинков Релкома - Retn'а и ТТК, а может и еще 
 PN> где между ними (на их аплинках). Как это заработает? С учетом вырезания 
 PN> спецификов для предотвращения r/l?

А какие проблемы? Если аплинки не хотят пропускать этот трафик с MSK-IX
через себя _для всех_, пусть не посылают туда анонсы. Анонс это
недвусмысленная заявка на пропуск трафика, разве не так?

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

За транзит уже заплачено, надо отрабатывать.

 PN> Если серьезно, как мне кажется, дропы здесь это самое малое зло.

Хуже дропов только лупы (атаки сейчас не рассматриваем).

 PN> Я же 
 PN> говорил, что универсального решения устраивающего всех - нет. С краю 
 PN> остаются малые и слабые, да.

С краю остаются общие для всех краевые условия.
Выполнение обязательств, отсутствие дропов.

 PN>> Лупов ведь нет (я про r/l).
 EG>> Дропы ничуть не лучше.
 PN> Зато они предсказуемей.

О да.

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

А тогда оно должно быть доступно, пока живо само по себе.

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

 PN> Тогда перепишите ядро (C).

Ммм?

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

 PN> Я к тому, что некотрые следят за связностью, и дают больший приоритет 
 PN> маршруту с меньшим rtt, и он случайно не перескочит, до тех пор пока жив. 
 PN> Да, это мешает балансировке, но она не всегда первостепенна.

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

Более-менее.

 PN> Вам действительно бажнее входящая балансировка, нежели rtt?

При забитом канале rtt получается грустный в любом случае.

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 8 9 14 5007/1 5010/70 5011/13 5012/46 5015/28
SEEN-BY: 5019/26 5020/175 400 545 982 1521 2238 4441 5021/29 5025/3 5026/14
SEEN-BY: 5027/12 5030/1080 5034/13 5035/38 5036/1 5037/28 5045/7 5049/1 5054/1
SEEN-BY: 5054/4 8 9 28 30 36 37 67 75 81 89 5060/88 5061/15 5062/10 5063/3
SEEN-BY: 5066/18 5075/35 5077/70 5080/68 5084/9 5085/13 5095/20 5096/18
SEEN-BY: 6001/10 6004/3 6009/3

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