Jump to content

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

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

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

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

Share this post


Link to post
Share on other sites

Добрый день!

 

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

andryas

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

Share this post


Link to post
Share on other sites

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

 

Это понятно

 

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.