KaraVan Опубликовано 6 октября, 2011 (изменено) · Жалоба Спасибо, т.е. если грубо говоря, у нас с аплинком два 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) забыли(не захотели) включить, то оно вообще взлетит? И если да, то я так понимаю что просто балансировка исходящего от нас не будет работать(все будет валиться в один канал)? Отвечу сам себе. Все работает. И именно так, как и прогнозировалось. Изменено 6 октября, 2011 пользователем KaraVan Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wtyd Опубликовано 6 октября, 2011 · Жалоба 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 Может быть конечно, что в квагге есть что-то другое на этот счёт, но я не нашёл. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wtyd Опубликовано 6 октября, 2011 · Жалоба http://quagga.net/faq/?topic=zebra Там описано два интересных для топика момента. Вопросы 13 и 15. с 13 всё понятно, 15 интересен в данном случае вот в чём: Можно сделать реальную балансировку, но для всего трафика. Надо не принимать от апстримов ничего, но анонсировать им свои сети. Прописать два маршрута по-умолчанию с одинаковым или разными весами. Тогда исходящий трафик распределится равномерно(соответственно). Правда, при падении одного из каналов резервирования не случится ... хотя если физический линк на сетевой карте при этом пропадёт, то может быть резервирование и случится :-). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 6 октября, 2011 · Жалоба 15 интересен в данном случае вот в чём: Можно сделать реальную балансировку, но для всего трафика. Надо не принимать от апстримов ничего, но анонсировать им свои сети. Прописать два маршрута по-умолчанию с одинаковым или разными весами. Тогда исходящий трафик распределится равномерно(соответственно). Правда, при падении одного из каналов резервирования не случится ... хотя если физический линк на сетевой карте при этом пропадёт, то может быть резервирование и случится :-). Эти правки будут в zebra, а не bgpd. Резервирования таки не будет, придется скриптом править настройки zebra при падении одного из аплинков. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wtyd Опубликовано 6 октября, 2011 · Жалоба 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, скайп и другие абоненты, которым критичны задержки и джиттер, будут клевать вам мозги. В общем решайте сами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...