Jump to content
Калькуляторы

bgp/quagga нет балансировки исходящего трафика

Доброго времени суток!

 

У меня есть проблемы с bgp/quagga, а именно:

есть два аплинка, оба шлют FW.

Обшее количество маршрутов:

[root@router log]# ip route | wc -l

373412

 

Но исходящий трафик идет в своей большей массе (90%) через одного аплинка (vlan7):

Маршруты распределяются так:

[root@router log]# ip route | grep vlan6 | wc -l

24474

[root@router log]# ip route | grep vlan7 | wc -l

348899

 

Если опустить один канал

[root@router log]# ifdown vlan7

Removed VLAN -:vlan7:-

 

то трафик идет через другого :

[root@router log]# ip route | grep vlan6 | wc -l

370603

[root@router log]# ip route | grep vlan7 | wc -l

0

 

если его поднять назад, то все возращаетса на свои места:

[root@router log]# ip route | grep vlan6 | wc -l

34505

[root@router log]# ip route | grep vlan7 | wc -l

338879

[root@router log]# ip route | wc -l

373402

 

Никаких приоритетов на трафик нет, конфиг прост.

Создается такое ощущение, что система в принципе не способна принять больше, чем 370 с небольшим тысяч маршрутов.

При этом

[root@router log]# dmesg | grep '^IP route'

IP route cache hash table entries: 16777216 (order: 15, 134217728 bytes)

 

/proc/sys/net/ipv4/route/max_size:16777216

 

Что я делаю не так?

Share this post


Link to post
Share on other sites

Но исходящий трафик идет в своей большей массе (90%) через одного аплинка (vlan7)

Это нормальная ситуация. BGP path selection algorithm помните?

 

И цифра маршрутов у вас правильная. У меня сию минуту 376021.

Share this post


Link to post
Share on other sites

Но исходящий трафик идет в своей большей массе (90%) через одного аплинка (vlan7)

Это нормальная ситуация. BGP path selection algorithm помните?

 

И цифра маршрутов у вас правильная. У меня сию минуту 376021.

 

Ничего нормального не вижу.

Это сейчас у меня так. Еще неделю назад другая ситуация была:

трафик идет на того провайдера, аплинк которого раньше поднялся. И если опустить/поднять одного из них, трафик идет через другого. Такой "тумблер" получался...

....

Да, еще самое неприятное, исходящий трафик сейчас заворачивается на того аплинка, который явно хуже - Ростелек...

Такое ощущение, что они там что-то мудрят с маршрутами.

Share this post


Link to post
Share on other sites

они там что-то мудрят с маршрутами

Запросто. Но вам что мешает смотреть show ip bgp?

Share this post


Link to post
Share on other sites

посмотрел...

практические советы по балансировке есть?)

Share this post


Link to post
Share on other sites

Препенды. У меня нет full-view от РТ, так что не могу ничего сказать о комьюнити.

Share this post


Link to post
Share on other sites

 

Ничего нормального не вижу.

Это сейчас у меня так. Еще неделю назад другая ситуация была:

трафик идет на того провайдера, аплинк которого раньше поднялся. И если опустить/поднять одного из них, трафик идет через другого. Такой "тумблер" получался...

....

Да, еще самое неприятное, исходящий трафик сейчас заворачивается на того аплинка, который явно хуже - Ростелек...

Такое ощущение, что они там что-то мудрят с маршрутами.

 

Неправильная настройка quagga.

Можете обратиться в личку.

Помогу отбалансировать, даже разные по толщине каналы :)

Share this post


Link to post
Share on other sites

они там что-то мудрят с маршрутами

Запросто. Но вам что мешает смотреть show ip bgp?

 

Спасибо за совет. По части проблемы помогло. У меня два аплинка. Ростелек и Синтерра. Так вот, то что теперь большая часть трафика утекает через Ростелек абсолютно понятно. Это из-за того, что маршруты Синтерры очень сильно изменились. Теперь у Синтерры почти весь трафик идет через AS`ку Мегафона. Таким образом, маршруты удлинились на одну AS`ку и трафик справедливо туда не идет, если есть более короткий путь. Решение пока вижу одно, топать ногами, что бы на мегафон напрямую подключили, а то договор на мегафон переписали, а фактическое подключение к синтерре осталось. Есть ли смысл это делать?

 

Но тем не менее, если эту проблему откатить, то все равно плохо... Ведь, кто первый встал того и тапки! Т.е. при равных путях, трафик пойдет на первого подключенного аплинка. А мне надо при равнозначных путях трафик равномерно распределить! Возможно ли такое на квагге?

Жду совета спецов.

Share this post


Link to post
Share on other sites

По первому вопросу всё очевидно. Сделать роутмап-препенд на вход(https://sites.google.com/site/amitsciscozone/home/bgp/bgp-as-path-prepending-and-as-path-filters ) , добавив к маршрутам получаемым от Ростелекома ещё одну AS, чтобы не заставлять синтерру делать L2 до мегафона и поднимать сессию с ними.

 

По второму вопросу решение не тривиально. Google сделал свою quagga, с блекджеком и шл мультипасом. http://lists.quagga.net/pipermail/quagga-dev/2011-July/008781.html

 

Попробуйте, потом расскажите как результат в этом топике

Share this post


Link to post
Share on other sites

А Вы ее, Гугловскую квагу пробовали?

А Птица не лучше будет?)

Share this post


Link to post
Share on other sites

bird умеет multipath для static и ospf. поправьте, если я ошибаюсь

 

гуглокваггу не пробовал, знаю о ней, т.к. подписан на quagga-dev, поэтому и прошу рассказать результат :)

Share this post


Link to post
Share on other sites

В общем, как все в этом мире, неоднозначно...

Share this post


Link to post
Share on other sites

По второму вопросу решение не тривиально. Google сделал свою quagga, с блекджеком и шл мультипасом. http://lists.quagga.net/pipermail/quagga-dev/2011-July/008781.html

 

Попробуйте, потом расскажите как результат в этом топике

 

Ради интереса сделал diff между гугловской и гит-оригинала, патч получился около 100 кбайт...

 

А железные (киска или джунипер) как к мультипатху относятся?)

Edited by telecom

Share this post


Link to post
Share on other sites

 

Ради интереса сделал diff между гугловской и гит-оригинала, патч получился около 100 кбайт...

 

А железные (киска или джунипер) как к мультипатху относятся?)

 

этот multipath работает только в пределах сервера.

Соседи-пиры никаким боком о нем и не догадываются.

Edited by vlad11

Share this post


Link to post
Share on other sites

Решение пока вижу одно, топать ногами, что бы на мегафон напрямую подключили, а то договор на мегафон переписали, а фактическое подключение к синтерре осталось. Есть ли смысл это делать?

Ржали всей комнатой NOC.

Share this post


Link to post
Share on other sites

Ржали всей комнатой NOC.

 

Вся комната на выходных работала? :)

Share this post


Link to post
Share on other sites

Ржали всей комнатой NOC.

 

Вся комната на выходных работала? :)

Ну, подумаешь, кавычки забыл поставить, IRC ж :)

Share this post


Link to post
Share on other sites

Решение пока вижу одно, топать ногами, что бы на мегафон напрямую подключили, а то договор на мегафон переписали, а фактическое подключение к синтерре осталось. Есть ли смысл это делать?

Ржали всей комнатой NOC.

Думаю, это далеко не первый раз, когда вся комната ржала, вместо того, что бы работать... Предпоследний раз это было, когда Синтерра (Мегафон) упал.

Почти сутки суки ржали!

Share this post


Link to post
Share on other sites

 

Ради интереса сделал diff между гугловской и гит-оригинала, патч получился около 100 кбайт...

 

А железные (киска или джунипер) как к мультипатху относятся?)

 

этот multipath работает только в пределах сервера.

Соседи-пиры никаким боком о нем и не догадываются.

Это утверждение относится к ECMP вцелом, либо к гугловской квагге в частности?

Share this post


Link to post
Share on other sites

этот multipath работает только в пределах сервера.

Соседи-пиры никаким боком о нем и не догадываются.

Это утверждение относится к ECMP вцелом, либо к гугловской квагге в частности?

В целом.

Share this post


Link to post
Share on other sites

Спасибо, т.е. если грубо говоря, у нас с аплинком два FE канала, два влана, две ип-сетки на каждый канал по подсети, в конфиге BGP прописано:

 

 

router bgp 7675

bgp router-id 10.0.0.1

neighbor 10.0.0.2 remote-as 7676

neighbor 10.0.0.2 next-hop-self

neighbor 10.0.0.3 remote-as 7676

neighbor 10.0.0.3 next-hop-self

 

 

Аплинк, нам размазывает входящий по Multipath, а мы его(Multipath) забыли(не захотели) включить, то оно вообще взлетит? И если да, то я так понимаю что просто балансировка исходящего от нас не будет работать(все будет валиться в один канал)?

Edited by KaraVan

Share this post


Link to post
Share on other sites

Спасибо, т.е. если грубо говоря, у нас с аплинком два FE канала, два влана, две ип-сетки на каждый канал по подсети, в конфиге BGP прописано:

 

Что мешает lagg соорудить?

Share this post


Link to post
Share on other sites

на их стороне тупой SDH мультиплексор, экзотика, сэр :D

Share this post


Link to post
Share on other sites

они там что-то мудрят с маршрутами

Запросто. Но вам что мешает смотреть show ip bgp?

 

Спасибо за совет. По части проблемы помогло. У меня два аплинка. Ростелек и Синтерра. Так вот, то что теперь большая часть трафика утекает через Ростелек абсолютно понятно. Это из-за того, что маршруты Синтерры очень сильно изменились. Теперь у Синтерры почти весь трафик идет через AS`ку Мегафона. Таким образом, маршруты удлинились на одну AS`ку и трафик справедливо туда не идет, если есть более короткий путь. Решение пока вижу одно, топать ногами, что бы на мегафон напрямую подключили, а то договор на мегафон переписали, а фактическое подключение к синтерре осталось. Есть ли смысл это делать?

 

Но тем не менее, если эту проблему откатить, то все равно плохо... Ведь, кто первый встал того и тапки! Т.е. при равных путях, трафик пойдет на первого подключенного аплинка. А мне надо при равнозначных путях трафик равномерно распределить! Возможно ли такое на квагге?

Жду совета спецов.

 

Посмотрите алгоритм выбора маршрутов в бгп. Там всё сделано для того, чтобы пути никогда не были одинаковыми. Даже если так случается, что одинаковы казалось бы вообще все атрибуты, то выбирается тот пир, сессия бгп с которым старше по времени.

 

Балансировку в общем случае сделать можно, но весьма условную. Надо чтобы апстимы были "одинаковые", т.е. чтобы они имели примерно одинаковые доступности до ресурсов - чтобы as-path был одинаковой длины до большинства ресурсов. Тогда, если взять два full-view, то каналы загрузятся примерно одинаково.

 

Если вам надо слать до какого-то ресурса один пакет в одного апстрима, второй во второго, третий опять в первого, то бгп ИМХО так не умеет (или я про такое не знаю). Чтобы было именно так, надо чтобы роутеры сами по себе умели muti-path (IP_ROUTE_MULTIPATH для linux), + чтобы они это умели чем-то типа IP_ROUTE_MULTIPATH_RR, ну и сам протокол маршрутизации должен вставлять две или более записей в основную таблицу маршрутизации. ospf вроде это хорошо делает.

 

Т.е. сперва ospfd получает информацию о том, что такая-то сеть доступна через вот этот ойпи и через вот этот, затем передаёт это в zebra, которая рулит основной табицей, zebra сравнивает "мощности" (веса, предпочтения) протоколов маршрутизации и правит таблицу маршутизации ядра - т.е. в ядро должно попасть две записи про "такую-то" подсеть. Дальше, когда пришла пора реально слать пакеты в эту подсеть, ядро должно поместить запись в кеш маршрутизации. Тут самое интересное - либо запись будет одна и трафик пойдёт всёравно через одного апстрима, либо запись будет такая, что обрабатываться она будет по rr (или по другому алгоритму балансировки), тогда действительно будет что-то типа каждый нечётный пакет в одного апстрима, каждый чётный - в другого.

 

Представляете, какое невероятное стечение обстоятельств должно случиться, чтобы эта вся байда заработала как вы хотите ? :-).

 

В другой теме форума читал, что там балансировали два линка в одного апстрима, потому что первый гигабит кончился - заюзали второй. Но там апстрим был один, бгп сессия одна. Т.е. сделали два линка между роутерами, подняли multihop-bgp на адресах на loopback'ах, затем статически прописали два маршрута к адресу соседнего loopback'а. По-скольку bgp рекурсивно маршруты считает, то балансировка должна была заработать, но непосредственно абалансировкой в данном случае занимались статические маршруты, а не bgp. Что-то у них вроде не получилось, потому что BSD 7.3 не умела multi-path.

 

В общем, по-моему, с *разными* апстримами полной балансировки не получится никогда. Ну или можно заюзать какие-то сомнительные патчи или роут-мап нарисовать как-то так, чтобы маршруты в ядро всё же попали два одновременно, но это плохая идея. EBGP как раз не для этого. Скорее даже навернео против этого.

 

P.S. Полез смотреть свою кваггу, а она в дистрибутиве собрана с --enable-multipath=0.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this