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

BGP: Балансировка входящего трафика по нагрузке (не по подсетям)

Не могу найти старую тему, то ли потерялась, то ли из поискового индекса выпала.

Интересуют способы балансировки входящего трафика с учетом загруженности/качества аплинков.

В идеале нужна равномерная утилизация всех линков пропорционально их пропускной способности.

Вариант с дроблением своих подсетей на /24 (или менее) и их пропорциональном анонсировании не подходит.

Не посоветуете, что тут можно сделать?

Share this post


Link to post
Share on other sites

Нет сынок, это фантастика (с). Только препенды, только коммьюнити, только хардкор.

Share this post


Link to post
Share on other sites

1. Препенды.

2. Комьюнити у аплинков.

3. Моар специфик роуты.

 

Share this post


Link to post
Share on other sites

Балансировка по подсетям вообще не подходит. Нужна балансировка по загрузке линков.

А можно подробнее про коммьюнити? Есть возможность через них определить долю пропускаемого трафика?

Share this post


Link to post
Share on other sites

БГП ничего не знает про пропускную способность Ваших линков и их утилизацию.
Почитайте документацию на предмет что такое коммунити и что такое препенды.

Share this post


Link to post
Share on other sites

Увы, недаром BGP относится к дистанционно-векторным протоколам маршрутизации. Его основная метрика это длина маршрута.

Такое умеет OSPF и IS-IS. А вам только крутить доступные в BGP "крутилки", ручками или автоматизировать скриптами.

Share this post


Link to post
Share on other sites

Мы очень грубо, но распределили нагрузку через community.  whois asxxxxx и читаем, что предлагает нам в комьюнитях наш аплинкер.

Там что то наподобие такого.

remarks:        65020:0   - announce to all peers.
remarks:        65029:0   - not announce to all peers.
remarks:        6502X:0   - announce to all peers with X=1,2,4 prepend, X=9 - not announce
remarks:        6502X:YYY - announce to peer ASYYY with X=1,2,4 prepend, X=9 - not announce
 Если все, или что то устраивает из предложенного, то экспериментируем и смотрим чего вышло.

Share this post


Link to post
Share on other sites

Помню лет 6-7 назад нечто подобное на коленке делал, по dhcpack, дхцп серв посылал на бордер выданный ip, который совался в нужную таблицу маршрутизации в зависимости от загрузки линков, всё это было из говна и палок, но работало стабильно и загрузки аплинков примерно размазывались так как было задумано. Сейчас бы, конечно, такое делать не стал.

Share this post


Link to post
Share on other sites

Я видел пример для джуниперов, распределение трафика по пропорциям, через коммьюнити.

И для Cisco вспоминается, что было что-то про bandwidth balance.

Share this post


Link to post
Share on other sites
21 минуту назад, alibek сказал:

И для Cisco вспоминается, что было что-то про bandwidth balance.

BGP Unequal Load Cost Sharing

Share this post


Link to post
Share on other sites

Когда уже народ усвоит, что BGP дистанционно-векторный протокол? Он в принципе не подразумевает балансировку, кроме статических костылей.

Share this post


Link to post
Share on other sites

БГП многого не умеет, а кривить с препендами и коммюнити - себе дороже. Пытался рулить - это примерно как жердями замногодалеко кобылу двигать.

Share this post


Link to post
Share on other sites

Всё прекрасно делается через bgp community, занимает от 1 дня до 3-х. Лучше заниматься этим в выходные или в чнн.

Начинать надо с анализа трафика.

 

У вас есть возможность слить netflow или sflow на что-нибудь типа as-stats? Бордер с FV?

Share this post


Link to post
Share on other sites

Если трафик нужен разово, то я могу отзеркалить его и получить netflow.

Используется default, но при необходимости с full view проблем не будет.

Только я не совсем понимаю, как FV поможет — мне ведь нужно балансировать входящий трафик, а не исходящий.

Share this post


Link to post
Share on other sites
6 часов назад, StSphinx сказал:

Такое умеет OSPF и IS-IS. А вам только крутить доступные в BGP "крутилки", ручками или автоматизировать скриптами.

Они умеют балансировать трафик только равномерно по линкам. Непропорционально могут BGP и EIGRP (и RSVP но это другой уровень).

5 часов назад, kt сказал:

BGP Unequal Load Cost Sharing

Это для исходящего трафика, его у ТС скорее всего не много и он сам по себе отлично балансируется.

5 часов назад, murano сказал:

Когда уже народ усвоит, что BGP дистанционно-векторный протокол? Он в принципе не подразумевает балансировку, кроме статических костылей.

А как же BGP AIGP metric? А банальный +/- MED?
 

Share this post


Link to post
Share on other sites

Как сказали Выше, берем статистику, расставляем препенды или коммьюнити... Только это все от лукавого... Я в свое время решил в bgp не лазить за исключением частных случаев ухудшения качества прохождения трафика по пути.

Share this post


Link to post
Share on other sites
13 часов назад, alibek сказал:

Если трафик нужен разово, то я могу отзеркалить его и получить netflow.

Используется default, но при необходимости с full view проблем не будет.

Только я не совсем понимаю, как FV поможет — мне ведь нужно балансировать входящий трафик, а не исходящий.

 

Смысл фв в метках origin-as для экспорта флоу на сервер статистики.

В итоге вы получаете график наглядный с какого линка сколько льется трафика. И уже зная эту информацию расставляете комюнити на своих префиксы, сверяясь с райпом.

Без статистики по трафику и ас сделать тонкий тюнинг крайне сложно, ибо тыкание наугад.

 

Могу подсказать с каких автономок начинать, точнее с имён сервисов.

1. Гугл, ютуб.

2. Вконтакте

3. Мейл.ру

4. Фейсбук

5. Рутьюб

6. Твич

7. Яндекс

8. Эппл

 

По мере убывания трафика.

 

Share this post


Link to post
Share on other sites
4 минуты назад, vurd сказал:

В итоге вы получаете график наглядный с какого линка сколько льется трафика. И уже зная эту информацию расставляете комюнити на своих префиксы, сверяясь с райпом.

Понял.

В принципе это всё то же расставление препендов, только не на глазок, а на основе статистики.

Но в любом случае это статическая система и эту процедуру нужно делать регулярно.

Это не то, что я бы хотел. Я бы хотел динамическую систему, которая бы сама распределяла трафик в соответствии с качеством линков, где критериями качества служат не только длина маршрута, но и полоса канала (а в идеале еще и время отклика с потерями).

Я как-то находил пример конфигурации джунипера, где в community указывалась желаемая полоса (bandwidth) и трафик распределялся в соответствии с ней. Но закладку не сделал, а сейчас найти не могу.

Я про подобное спрашиваю.

Share this post


Link to post
Share on other sites

А, ну да, вы же у нас мечтатель. Верите в волшебную фею Автоматизацию? Ну-ну, она всё еще на костылях...

 

По факту, видя тенденцию по трафику выровнять "с перспективой роста" вполне реально. Лично у меня входящий раскинут по трем аплинкам в 90% до полной утилизации закупленных полос.

 

То что вы видели у юнипера, вам не подойдёт. Это всё для собственных бэкбонов. И, кстати, я посмотрел бы на ваши действия, когда в саппорт позвонят все танкисты, у которых лагает после решения о балансировке вашей нейросети. Всё равно отключать и лезть руками.

Share this post


Link to post
Share on other sites
55 минут назад, vurd сказал:

Могу подсказать с каких автономок начинать, точнее с имён сервисов.

....

 

Как быть, если на первом месте AS аплинка(вернее трафик с серверов GGC), а на втором - AS15169(Google) и коммьюнити для управления именно для этого трафика нет?

Share this post


Link to post
Share on other sites

Писать в гугл заявку на установку ggc, разумеется. :)

Вы хотите что именно сделать с этим трафиком?


The supported communities are:
• 15169:13000-13300: preference for receiving traffic at a particular ingress point for a particular block.
15169:13300 indicates the highest preference while 15169:13000 is the lowest priority. Multiple egress-
points can share the same preference and in this case Google will treat as being equally good choices from
the perspective of the peer network. In the case that no tag is applied, 15169:13200 is assumed as the
priority.

Share this post


Link to post
Share on other sites

Есть задача распределить трафик от AS15169 и GGC между аплинками(примерно 60% входящего трафика).

Аплинки эти коммьюнити 15169:13000-13300 не принимают.

Трафик от GGC идет с SRC-AS аплинков, манипулировать им можно только при помощи навешивания препендов на весь свой префикс, это в свою очередь, ведет к перегрузке одного из каналов(каналы по емкости симметричные) в ЧНН.

Share this post


Link to post
Share on other sites

Боюсь между не получится. Максимум скинуть весь трафик или с кеша или с самого гугла на одну из ног. Это тот случай, когда сработает только сегментация на more specific-и, как бы мы этого не хотели.

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