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

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

Спасибо, т.е. если грубо говоря, у нас с аплинком два 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

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


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

http://wiki.nil.com/Multipath_Load_Sharing_with_two_ISPs

 

Тут наверное прям то, что хотелось, описано. Не умеет кваггин bgpd релаксировать на мультипатх :-).

 

Fortunately, Cisco has undocumented command that allows us to bypass this requirement (AS paths still have to be te same length, but don't have to be identical).

 

bgp bestpath as-path multipath-relax

 

В квагге:

 

(config-router)# bgp bestpath as-path ?

confed Compare path lengths including confederation sets & sequences in selecting a route

ignore Ignore as-path length in selecting a route

(config-router)# bgp bestpath as-path

 

Может быть конечно, что в квагге есть что-то другое на этот счёт, но я не нашёл.

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


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

http://quagga.net/faq/?topic=zebra

 

Там описано два интересных для топика момента. Вопросы 13 и 15. с 13 всё понятно, 15 интересен в данном случае вот в чём:

 

Можно сделать реальную балансировку, но для всего трафика. Надо не принимать от апстримов ничего, но анонсировать им свои сети. Прописать два маршрута по-умолчанию с одинаковым или разными весами. Тогда исходящий трафик распределится равномерно(соответственно). Правда, при падении одного из каналов резервирования не случится ... хотя если физический линк на сетевой карте при этом пропадёт, то может быть резервирование и случится :-).

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


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

15 интересен в данном случае вот в чём:

 

Можно сделать реальную балансировку, но для всего трафика. Надо не принимать от апстримов ничего, но анонсировать им свои сети. Прописать два маршрута по-умолчанию с одинаковым или разными весами. Тогда исходящий трафик распределится равномерно(соответственно). Правда, при падении одного из каналов резервирования не случится ... хотя если физический линк на сетевой карте при этом пропадёт, то может быть резервирование и случится :-).

 

Эти правки будут в zebra, а не bgpd.

Резервирования таки не будет, придется скриптом править настройки zebra при падении одного из аплинков.

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


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

15 интересен в данном случае вот в чём:

 

Можно сделать реальную балансировку, но для всего трафика. Надо не принимать от апстримов ничего, но анонсировать им свои сети. Прописать два маршрута по-умолчанию с одинаковым или разными весами. Тогда исходящий трафик распределится равномерно(соответственно). Правда, при падении одного из каналов резервирования не случится ... хотя если физический линк на сетевой карте при этом пропадёт, то может быть резервирование и случится :-).

 

Эти правки будут в zebra, а не bgpd.

Резервирования таки не будет, придется скриптом править настройки zebra при падении одного из аплинков.

 

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

 

По ссылке вообще-то не про зебру или кваггу написано, а про ip:

 

ip route add <prefix> via <nexthop1> weight x via <nexthop2> weight y

 

Кстати, если на то пошло, то вот ещё что вспомнилось и придумалось: анонсировать свои сети в мир в оба апстрима можно просто спомощью bgpd без запуска зебры, тогда маршруты уйдут в мир, но полученные от апстримов маршруты в ядро не попадут. Если вы собрались балансировать ровно 50х50 (нечётные пакеты в одного, чётные в другого апстрима независимо от "хорошести" bgp), то fulview вам и не нужен. Надо использовать что-то вроде m-route (http://wiki.openwrt.org/doc/uci/multiwan) или самому написать аналогичный скрипт. Надо чтобы он пингал connected апстримов и ставил/убирал/менял маршрут по-умолчанию соответственно.

 

Если же хотите именно спомощью bgp, то, во-первых, придётся использовать сомнительные патчи, во-вторых, 50х50 ровно неполучится. 50х50 возможно будет работать только на префиксы с одинаковыми по длине as-path. Кстати на самом деле связь до таких префиксов далеко не всегда будет одинаковая. as-path одной длины не означает одинакового качества. Будет у вас половина пакетов номрально ходить, половина с другой задержкой или ещё чем. WoW, скайп и другие абоненты, которым критичны задержки и джиттер, будут клевать вам мозги.

 

В общем решайте сами.

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


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

Join the conversation

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

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

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

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

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

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

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