drakosha Опубликовано 24 сентября, 2011 · Жалоба Доброго времени суток! У меня есть проблемы с 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 Что я делаю не так? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ipaddr.ru Опубликовано 24 сентября, 2011 · Жалоба Но исходящий трафик идет в своей большей массе (90%) через одного аплинка (vlan7) Это нормальная ситуация. BGP path selection algorithm помните? И цифра маршрутов у вас правильная. У меня сию минуту 376021. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
drakosha Опубликовано 24 сентября, 2011 · Жалоба Но исходящий трафик идет в своей большей массе (90%) через одного аплинка (vlan7) Это нормальная ситуация. BGP path selection algorithm помните? И цифра маршрутов у вас правильная. У меня сию минуту 376021. Ничего нормального не вижу. Это сейчас у меня так. Еще неделю назад другая ситуация была: трафик идет на того провайдера, аплинк которого раньше поднялся. И если опустить/поднять одного из них, трафик идет через другого. Такой "тумблер" получался... .... Да, еще самое неприятное, исходящий трафик сейчас заворачивается на того аплинка, который явно хуже - Ростелек... Такое ощущение, что они там что-то мудрят с маршрутами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ipaddr.ru Опубликовано 24 сентября, 2011 · Жалоба они там что-то мудрят с маршрутами Запросто. Но вам что мешает смотреть show ip bgp? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
drakosha Опубликовано 24 сентября, 2011 · Жалоба посмотрел... практические советы по балансировке есть?) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ipaddr.ru Опубликовано 24 сентября, 2011 · Жалоба Препенды. У меня нет full-view от РТ, так что не могу ничего сказать о комьюнити. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 24 сентября, 2011 · Жалоба Ничего нормального не вижу. Это сейчас у меня так. Еще неделю назад другая ситуация была: трафик идет на того провайдера, аплинк которого раньше поднялся. И если опустить/поднять одного из них, трафик идет через другого. Такой "тумблер" получался... .... Да, еще самое неприятное, исходящий трафик сейчас заворачивается на того аплинка, который явно хуже - Ростелек... Такое ощущение, что они там что-то мудрят с маршрутами. Неправильная настройка quagga. Можете обратиться в личку. Помогу отбалансировать, даже разные по толщине каналы :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
drakosha Опубликовано 24 сентября, 2011 · Жалоба они там что-то мудрят с маршрутами Запросто. Но вам что мешает смотреть show ip bgp? Спасибо за совет. По части проблемы помогло. У меня два аплинка. Ростелек и Синтерра. Так вот, то что теперь большая часть трафика утекает через Ростелек абсолютно понятно. Это из-за того, что маршруты Синтерры очень сильно изменились. Теперь у Синтерры почти весь трафик идет через AS`ку Мегафона. Таким образом, маршруты удлинились на одну AS`ку и трафик справедливо туда не идет, если есть более короткий путь. Решение пока вижу одно, топать ногами, что бы на мегафон напрямую подключили, а то договор на мегафон переписали, а фактическое подключение к синтерре осталось. Есть ли смысл это делать? Но тем не менее, если эту проблему откатить, то все равно плохо... Ведь, кто первый встал того и тапки! Т.е. при равных путях, трафик пойдет на первого подключенного аплинка. А мне надо при равнозначных путях трафик равномерно распределить! Возможно ли такое на квагге? Жду совета спецов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 24 сентября, 2011 · Жалоба По первому вопросу всё очевидно. Сделать роутмап-препенд на вход(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 Попробуйте, потом расскажите как результат в этом топике Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
drakosha Опубликовано 24 сентября, 2011 · Жалоба А Вы ее, Гугловскую квагу пробовали? А Птица не лучше будет?) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 24 сентября, 2011 · Жалоба bird умеет multipath для static и ospf. поправьте, если я ошибаюсь гуглокваггу не пробовал, знаю о ней, т.к. подписан на quagga-dev, поэтому и прошу рассказать результат :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
telecom Опубликовано 24 сентября, 2011 · Жалоба В общем, как все в этом мире, неоднозначно... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 24 сентября, 2011 · Жалоба Bird - на любителя. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
telecom Опубликовано 24 сентября, 2011 (изменено) · Жалоба По второму вопросу решение не тривиально. Google сделал свою quagga, с блекджеком и шл мультипасом. http://lists.quagga.net/pipermail/quagga-dev/2011-July/008781.html Попробуйте, потом расскажите как результат в этом топике Ради интереса сделал diff между гугловской и гит-оригинала, патч получился около 100 кбайт... А железные (киска или джунипер) как к мультипатху относятся?) Изменено 24 сентября, 2011 пользователем telecom Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 24 сентября, 2011 (изменено) · Жалоба Ради интереса сделал diff между гугловской и гит-оригинала, патч получился около 100 кбайт... А железные (киска или джунипер) как к мультипатху относятся?) этот multipath работает только в пределах сервера. Соседи-пиры никаким боком о нем и не догадываются. Изменено 24 сентября, 2011 пользователем vlad11 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GFORGX Опубликовано 25 сентября, 2011 · Жалоба Решение пока вижу одно, топать ногами, что бы на мегафон напрямую подключили, а то договор на мегафон переписали, а фактическое подключение к синтерре осталось. Есть ли смысл это делать? Ржали всей комнатой NOC. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 25 сентября, 2011 · Жалоба Ржали всей комнатой NOC. Вся комната на выходных работала? :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GFORGX Опубликовано 25 сентября, 2011 · Жалоба Ржали всей комнатой NOC. Вся комната на выходных работала? :) Ну, подумаешь, кавычки забыл поставить, IRC ж :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
telecom Опубликовано 25 сентября, 2011 · Жалоба Решение пока вижу одно, топать ногами, что бы на мегафон напрямую подключили, а то договор на мегафон переписали, а фактическое подключение к синтерре осталось. Есть ли смысл это делать? Ржали всей комнатой NOC. Думаю, это далеко не первый раз, когда вся комната ржала, вместо того, что бы работать... Предпоследний раз это было, когда Синтерра (Мегафон) упал. Почти сутки суки ржали! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
KaraVan Опубликовано 5 октября, 2011 · Жалоба Ради интереса сделал diff между гугловской и гит-оригинала, патч получился около 100 кбайт... А железные (киска или джунипер) как к мультипатху относятся?) этот multipath работает только в пределах сервера. Соседи-пиры никаким боком о нем и не догадываются. Это утверждение относится к ECMP вцелом, либо к гугловской квагге в частности? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 5 октября, 2011 · Жалоба этот multipath работает только в пределах сервера. Соседи-пиры никаким боком о нем и не догадываются. Это утверждение относится к ECMP вцелом, либо к гугловской квагге в частности? В целом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
KaraVan Опубликовано 5 октября, 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) забыли(не захотели) включить, то оно вообще взлетит? И если да, то я так понимаю что просто балансировка исходящего от нас не будет работать(все будет валиться в один канал)? Изменено 5 октября, 2011 пользователем KaraVan Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 5 октября, 2011 · Жалоба Спасибо, т.е. если грубо говоря, у нас с аплинком два FE канала, два влана, две ип-сетки на каждый канал по подсети, в конфиге BGP прописано: Что мешает lagg соорудить? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
KaraVan Опубликовано 5 октября, 2011 · Жалоба на их стороне тупой SDH мультиплексор, экзотика, сэр :D Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wtyd Опубликовано 6 октября, 2011 · Жалоба они там что-то мудрят с маршрутами Запросто. Но вам что мешает смотреть 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. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...