Растолкуйте pls механизм BGP Link Bandwidth при *BGP Multipath

[andryas]

Использую данную фичу, она работает, но вот задался вопросом о механизме реализации и, соответственно вреде/полезности именно такого способа load balancing

Соответственно, вопрс к общественности:

Согласно какой логики Cisco разбрасывает пакеты соседям, умудряясь подстраивать их соотношение пропорционально и с учётом указанных на интерфейсах bandwidth?

[Yger]

Добрый день!

 

Балансировка идет пропорционально весу, а вес каждого пути (path) расчитывается из настроенной скорости (bandwidth). Если у вас два пути с B1 и B2, то вес первого будет 100%*B1/(B1+B2), а второго будет соответствено 100%*B2/(B1+B2).

Теперь во время принятия решения - каким путем послать пакет, будет учитываться этот коэффициент. При этом реальная нагрузка каждого flow при расчете пути, скорее всего, не берется, т.е. балансировка идет чисто per flow. В случае малого кол-ва потоков с существенно различающимися скоростями вы не увидите строго распределения, которого вы ожидаете по формуле. Но в случае многочисленных одинаковых потоков (1000+) вы конечно же приблизитесь к идеальному распределению. Кстати - bandwidth может передаваться в extended community, а это дает возможность принимать решение о балансировке на маршрутизаторах, отличных от тех, на которых настроен параметр bandwidth. Но и в этом случае кол-во сценариаев применения данной функции не так уж и велико.

[rover-lt]

...

чувака по ходу в гугле забанили. Находится в первых 2 ссылках все :)

[andryas]

Yger, спасибо большое за развёрнутый ответ.

Ещё такой вопрос. Допустим, имеем 2 канала с load balancing, BGP Multipath и multipath-relax. На одном из них внезапно резко увеличились потери, либо какой-то ресурс по каким-то причинам стал недоступен через этот канал. Как должна вести себя балансировка в таком случае?

[s.lobanov]

andryas

маршрутизатор не знает о том, что возникли потери в том или ином "направлении", поэтому ничего происходить не будет. понятие "недоступен" слишком абстрактно. если пришел bgp withdraw на префикс, то исходняк туда больше литься не будет, более ничего. всё остальное - это будут костыли и подпорки

[andryas]

маршрутизатор не знает о том, что возникли потери в том или ином "направлении", поэтому ничего происходить не будет

 

Это понятно

 

более ничего. всё остальное - это будут костыли и подпорки

 

Тоесть для решения подобной проблемы придётся писать пионер-скрипт, пингующий по списку наиболее популярные ресурсы с разным src ip, и рулящий маршрутизацией в псевдоавтоматическом режиме? Или есть какие-то менее костыльные методы решения таких проблем?

[s.lobanov]

Тоесть для решения подобной проблемы придётся писать пионер-скрипт, пингующий по списку наиболее популярные ресурсы с разным src ip, и рулящий маршрутизацией в псевдоавтоматическом режиме? Или есть какие-то менее костыльные методы решения таких проблем?

 

Да. Но на деле это не требуется чаще всего, обычно подобные трюки делают вручную (выставляют комьюнити или вообще снимают префиксы/гасят сессию), ну потому что автоматические подобные штуки до добра не доведут ибо слишком много вариантов и всё это тестировать тоже не очень просто