Re: балансировка BGP
- From
- Petr Novopashenniy (2:5020/400)
- To
- Eugene Grosbein
- Date
- 2009-10-07T17:11:06Z
- Area
- RU.CISCO
From: Petr Novopashenniy <pety@rusnet.ru>
On Mon, 5 Oct 2009, Eugene Grosbein wrote:
EG> EG>> А какие проблемы? Если аплинки не хотят пропускать этот трафик с MSK-IX
EG> EG>> через себя _для всех_, пусть не посылают туда анонсы. Анонс это
EG> EG>> недвусмысленная заявка на пропуск трафика, разве не так?
EG>
EG> PN> Проблемы/решение магистралов я уже описывал. Зачем идти на следующий круг?
EG> PN>
EG> PN> А про заявку на пропуск даже пытаться отвечать не буду. ;)
EG>
EG> Почему "не буду"? Непонятно.
В контексте данной проблемы я просто не знаю ответа на этот вопрос, а его
обсуждение скорее всего приведет в тупик, или в кольцо. ;)
EG> PN>> Иными словами, PBR требует индивидуальной настройки для каждого
EG> PN> случая,
EG> PN>> для крупных сетей это может быть большая проблема, а за ее решение
EG> PN>> придется платить.
EG> EG>> За транзит уже заплачено, надо отрабатывать.
EG> PN> Вы совсем не хотите посмотреть на проблему объективно... Они (магистралы),
EG> PN>
EG> PN> например, вполне считают своих клиентов, плодящих специфики (которые
EG> PN> потом не работают), тоже вполне косорукими.
EG>
EG> Основание? Лично мне магистралы всегда говорили "это ваше право"
EG> об анонсировании спецификов.
Я думаю это страховка от проблем с клиентом еще на уровне договора. Они не
запрещают, а рекомендуют. В этом тоже есть своя логика.
EG>
EG> PN> Давайте больше не будем об
EG> PN> этом, а по возможности остановимся на технической стороне вопроса?
EG>
EG> А истинно пиринговые отношения между автономными системами
EG> в Рунете давно канули в лету.
Ну почему, по мне так вполне остались. Или имелись в виду все AS Рунета?
EG> Можно даже припомнить когда именно
EG> и по чьей инициативе, но смысла нет. Сейчас это отношения "поставщик-клиент".
О, боюсь это история будет уходить корнями гораздо глубже. Ну да,
переход на западную модель ведения бизнеса был неизбежен.
EG>
EG> PN>> Я же
EG> PN>> говорил, что универсального решения устраивающего всех - нет. С краю
EG> PN>> остаются малые и слабые, да.
EG> EG>> С краю остаются общие для всех краевые условия.
EG> EG>> Выполнение обязательств, отсутствие дропов.
EG>
EG> PN> Ну магистралы что, божества с небес? У них специальные роутеры со
EG> PN> специальным софтом? Может Вы считаете, что они зарабатывают очень много
EG> PN> денег, и легко могут себе позволить эксклюзивную разработку (вопрос
EG> PN> риторический)?
EG>
EG> Наверное, магистралы это такие адепты Cisco & Co, принимающие свои
EG> неспециальные роутеры и софт как данность свыше и спускающие
EG> божественное откровение ниже даунлинкам в стиле
EG> "и по-другому делать некошерно"... Да, пожалуй уже офтопик :-)
EG>
EG> PN>>> Лупов ведь нет (я про r/l).
EG> EG>>> Дропы ничуть не лучше.
EG> PN>> Зато они предсказуемей.
EG> EG>> О да.
EG> PN> А соответственно лучше диагностируются.
EG>
EG> Великолепно, а вот после диагностирования дропов дальше какие-то
EG> движения следуют или как?
Со стороны магистралов? Как правило нет. Со стороны инициатора анонсов -
как правило да. ;)
А вообще за своими анонсами, мне кажется, должен следить именно тот,
откуда они начинаются. Пока их мало, и за ними можно уследить. Магистралам
обменивающимся тысячами/десятками тысяч роутов это гораздо сложнее. И
гораздо сложнее отслеживать мусорный/географически петлевой трафик в своих
сетях, в тех случаях, когда петли не нужны (ну, например, лишняя петля
через штаты). И тут к клиентам прислушиваются, если магистрал не отморозок
:).
EG>
EG> PN> Кстати, некотрые магистралы прямо так примерно в договоре и пишут -
EG> PN> делаете специфики - мы связность не гарантируем. Или отдавайте все
EG> PN> специфики. Вас бы такой договор устроил?
EG>
EG> Задешево - да.
EG>
EG> PN> Не подключились бы тогда? У Вас большой выбор в магистралах?
EG>
EG> В последнее время стал большой, им приходится бороться за клиента.
EG> Правда, аргументы там вовсе не технического плана работают :-)
EG>
EG> PN> А ведь это они как бы заранее предупреждают.
EG>
EG> Пока не предупреждали,
Ну, может когда-нибудь..
EG> текст я читал, пару лет назад.
А вот это зря. Или просто не входило в обязанности?
EG>
EG> PN>> Тогда перепишите ядро (C).
EG> EG>> Ммм?
EG> PN> Ну новую модель маршрутизации в инете, чтобы у всех все было одинаково.
EG> PN> Внедрять будем так же быстро как IPv6, ага. У Вас уже все роутеры в сети
EG> PN> поддерживают IPv6 и 32bit ASN? Или пока не нужно?
EG>
EG> IPv6 в проекте, 32bit ASN на прошлом месте уже да, на текущем пока
EG> не везде проверил.
Ну вот, в проекте.. А ведь IPv6 вроде как cisco лучше поддерживается (в
смысле наличия поддержки в софте и кол-ве оборудования), чем 32bit ASN,
или я ошибаюсь? Чем сеть больше, тем менять там что-то страшнее ;).
EG> PN>> Кстати, а как вышел баланс?
EG> EG>> Более-менее.
EG> PN> Да, задал дурацкий вопрос. Не зная условий оплаты каналов
EG> PN> (полоса/берст/погиговка) и их ширины (и тарифов) друг относительно друга -
EG> PN>
EG> PN> ответ мало что мне сказал. ;(
EG>
EG> Два канала flatrate, один более чем вдвое шире другого.
EG> Процентная загрузка стала более-менее одинаковая, разница
EG> в пределах десяти процентов. В первый широкий канал агрегаты и специфики,
EG> во второй узкий только часть спецификов, при падении первого во второй
EG> добавляются агрегаты. Балансировка количеством спецификов в узком канале.
Ну да. Когда-то давно, когда в моих краях интернет был еще достаточно
дорог, делал примерно тоже самое. На спецификах - VIP, на агрегате - не
VIP :). В случае падения канала агрегат не добавлялся, канал был слишком
дорог. ;)
В Вашем же случае при такой аварии там будет поолная полка (нет, это
просто констатация факта, я ведь не предлагал Вам сменять аплинков). :(
Ну, на своих сетях еще так балансировать можно, хотя разные клиенты будут
иметь разную связность (ну в моем случае это было на уровне договора
заранее известно), но балансировать клиентские AS так уже не выйдет.
Кстати, о пользе чтения договора. Там может неожиданно оказаться пункт о
использовании uRPF (видел такое), в самом худшем его виде. И опаньки.
Также в договор желательно заранее включать возможность использования BGP
community, потому что некотрые за эту возможность хотят отдельных денег.
Еще некотрые операторы разрешаю транзит чужих community через себя, а
некотрые нет (вроде как таких большинство). При этом могут мапить свои
community в community аплинка, а могут и нет (в основном нет). Вполне себе
повод для торга.
Вы имеете возможность использовать community описанные в RIPE у AS20485 и
AS12389? Если да, то, мне кажется, можно было бы обойтись и без специфик
и условного анонсирования. Ведь у Вас оба flat'а, а это значит, что
балансировать ради денег смысла нет (а только ради качества), при этом у
всех Ваших клиентов связность будет одинаковая (ну да, если это конечно
нужно).
EG>
EG> PN>> Вам действительно бажнее входящая балансировка, нежели rtt?
EG> EG>> При забитом канале rtt получается грустный в любом случае.
EG>
EG> PN> Честно говоря, я Вам не завидую. Это означает что у Вас нет возможности
EG> PN> держать нормальную входящую/исходящую связность (в плане минимального
EG> PN> rtt, без петель на Россию через зарубеж), расширяясь в сторону того
EG> PN> или иного аплинка, когда приходит время (понимаю, причин этому может быть
EG> PN> множество). Но на месте Ваших клиентов я бы давно взвыл ;)
EG>
EG> Клиенты воют, когда канал забивается или CPU кончается, в других
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