Перейти к содержимому
Калькуляторы

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

 

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

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

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

....

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

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

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

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

....

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

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

По первому вопросу всё очевидно. Сделать роутмап-препенд на вход(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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

 

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

Изменено пользователем telecom

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

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

 

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

 

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

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

Изменено пользователем vlad11

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

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

 

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

В целом.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Спасибо, т.е. если грубо говоря, у нас с аплинком два 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) забыли(не захотели) включить, то оно вообще взлетит? И если да, то я так понимаю что просто балансировка исходящего от нас не будет работать(все будет валиться в один канал)?

Изменено пользователем KaraVan

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Запросто. Но вам что мешает смотреть 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.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.