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

[alibek]

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

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

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

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

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

[dignity]

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

[sol]

1. Препенды.

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

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

 

[alibek]

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

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

[stalker86]

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

[GrandPr1de]

mpls должен уметь такие штуки, но никак не bgp

[StSphinx]

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

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

[asteroid]

Мы очень грубо, но распределили нагрузку через 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
 Если все, или что то устраивает из предложенного, то экспериментируем и смотрим чего вышло.

[pppoetest]

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

[alibek]

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

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

[kt]

21 минуту назад, alibek сказал:

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

BGP Unequal Load Cost Sharing

[alibek]

11 минут назад, kt сказал:

BGP Unequal Load Cost Sharing

Да, почти оно самое.

Но насколько я понимаю, к входящему трафику это неприменимо.

[murano]

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

[YuryD]

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

[vurd]

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

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

 

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

[alibek]

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

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

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

[v_r]

6 часов назад, StSphinx сказал:

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

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

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

BGP Unequal Load Cost Sharing

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

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

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

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

[dignity]

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

[vurd]

13 часов назад, alibek сказал:

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

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

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

 

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

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

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

 

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

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

2. Вконтакте

3. Мейл.ру

4. Фейсбук

5. Рутьюб

6. Твич

7. Яндекс

8. Эппл

 

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

 

[alibek]

4 минуты назад, vurd сказал:

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

Понял.

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

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

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

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

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

[vurd]

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

 

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

 

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

[DGM]

55 минут назад, vurd сказал:

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

....

 

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

[vurd]

Писать в гугл заявку на установку 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.

[DGM]

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

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

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

[vurd]

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