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

BGP+OSPF с резервированием и балансировкой. поделитесь мыслями

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

уверен, что колесо уже изобреталось, однако что-то не выходит красоты :(

схема на картинке.

вопрос такой возникает: как от бордеров проанонсировать дефолт так, чтобы исходящий трафик из сети не стекался на какой-то один роутер, а шел на тот бордер, через который сеть назначения ближе? опять же, при отказе канала А трафик должен идти со свитча С на бордер В, однако пока жив А, он будет продолжать анонсировать дефолт с меньшей метрикой и трафик пойдет на него.

тут либо редистрибьют делать внешних маршрутов во внутреннюю сеть :( либо... тут мысли кончаются.

как красивше сделать (L3 свитчей типа С в будущем может стать больше, как и бордеров)?

 

во всех цисковских мурзилках даются общие принципы, а вот конкретной подобной схемы не встречал.

 

PS

чёрт, лишние картинки не убрать. сорри

post-13431-1249402339_thumb.png

post-13431-1249402452_thumb.png

post-13431-1249402496_thumb.png

post-13431-1249402913_thumb.png

Edited by Мартен

Share this post


Link to post
Share on other sites

таак, уже интереснее :)

а теперь представим, что бордеры на квагге

Share this post


Link to post
Share on other sites
таак, уже интереснее :)

а теперь представим, что бордеры на квагге

"во всех цисковских мурзилках даются общие принципы, а вот конкретной подобной схемы не встречал."

В цисковских мурзилках тоже квагу юзают?)

а еслиб вы не поленились почитать за GLBP то нашли бы opensource реализацию CARP

А по поводу стекаться на один бордер не вижу смысла что-то разруливать. У вас между ними должна быть iBGP связаность, так что пофигу на какой бордер пойдет.

Share this post


Link to post
Share on other sites

Дык а что мешает два дефолта с одной метрикой с бордеров отдавать? Заодно и балансировка будет. иБГП свазность у них есть, куда слать исходищий трафик разберутся...

А входящий - тем более)

Share this post


Link to post
Share on other sites

Кстати можно и с разной метрикой раздавать) Но при условии что есть внутреннее bgp между бордерами

там они сами между собой разберуться - куда именно проще послать пакет

Share this post


Link to post
Share on other sites

можно генерировать дефолт через, скажем, сеть 4.0.0.0

т.е. если апстрим ее не отдает, дефолт с конкретного бордера перестает редистрибьютиться в ospf.

в штатном режиме два бордера дают дефолты с равной метрикой, для балансировки.

 

Share this post


Link to post
Share on other sites
можно генерировать дефолт через, скажем, сеть 4.0.0.0

т.е. если апстрим ее не отдает, дефолт с конкретного бордера перестает редистрибьютиться в ospf.

в штатном режиме два бордера дают дефолты с равной метрикой, для балансировки.

Можно и так конечно, но имхо лишнее.

Достаточно при наличии между бордерами линка этого:

в штатном режиме два бордера дают дефолты с равной метрикой, для балансировки.

Р.S. Исходящий трафик попадет не на тот бордер, через который сеть назначения ближе, а на любой из двух. Но это обычно по барабану)

Share this post


Link to post
Share on other sites

У меня сделано очень похоже, только шейперы и бордеры на два уровня разделены, между ними BGP крест-накрест, full-view в сеть не идет, только дефолт.

Между шейперами и L3 каталистами - OSPF. Так как каталистов несколько и бордеры подключены к крайним, каждый каталист смотрит дефолтом в сторону ближайшего шейпера.

Если использовать full-view, можно отфильтровать из него ближайшие сети аплинков + раздать вниз дефолт (как точно делать не знаю, с full-view плотно не работал).

Была только одна проблема при постоении - OSPF маршруты имеют приоритет над BGP, поэтому делал дополнительные фильтры в зебре на шейпере.

Edited by Valaskor

Share this post


Link to post
Share on other sites
можно генерировать дефолт через, скажем, сеть 4.0.0.0

т.е. если апстрим ее не отдает, дефолт с конкретного бордера перестает редистрибьютиться в ospf.

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

Share this post


Link to post
Share on other sites
Была только одна проблема при постоении - OSPF маршруты имеют приоритет над BGP, поэтому делал дополнительные фильтры в зебре на шейпере.
что-то обычно как раз наоборот.

все озвученные варианты не решают проблему полностью - посылать трафик по кратчайшему пути через наиболее подходящий бордер.

тут, видимо, только если фулл-вью на каталист заливать, но это только шеститонники смогут, да и то не все...

Share this post


Link to post
Share on other sites

Когда ospf на каталисте дает 2 дефолта с одинаковой метрикой и весом, они оба появляются в таблице маршрутов и начинается per-destination load-balancing. Так как в этом случае начинает шейпится не правильно, пришлось в ospf вписать maximum-paths 1.

 

Была только одна проблема при постоении - OSPF маршруты имеют приоритет над BGP, поэтому делал дополнительные фильтры в зебре на шейпере.
что-то обычно как раз наоборот.

все озвученные варианты не решают проблему полностью - посылать трафик по кратчайшему пути через наиболее подходящий бордер.

тут, видимо, только если фулл-вью на каталист заливать, но это только шеститонники смогут, да и то не все...

а как у вас дефолт в OSPF раздается?

через default-information originate always?

и если нет always, куда смотрит дефолт на бордере, через который не едет траффик?

Edited by Valaskor

Share this post


Link to post
Share on other sites
Когда ospf на каталисте дает 2 дефолта с одинаковой метрикой и весом, они оба появляются в таблице маршрутов и начинается per-destination load-balancing. Так как в этом случае начинает шейпится не правильно, пришлось в ospf вписать maximum-paths 1.
проверю, но почему-то точно помню, что, принимая два одинаковых дефолта, мой каталист прописывал в таблицу только одного из них.
а как у вас дефолт в OSPF раздается?

через default-information originate always?

да.

 

Share this post


Link to post
Share on other sites

Проверьте, еще можно посмотреть что в самом ospf творится: show ip ospf database | include 0.0.0.0

Дефолт же через ospf идет? Просто в bgp maximum-paths 1 по умолчанию стоит, нужно принудительно увеличивать.

 

И где у вас шейпится траффик?

Edited by Valaskor

Share this post


Link to post
Share on other sites

с шейпингом пока бордеры справляются. перестанут - выделю отдельные машины.

а оспф да, надо поковырять, займусь вечерком. похоже, действительно второй дефолт не анонсируется почему-то

Share this post


Link to post
Share on other sites

Если у вас бордеры шейпят, то такая балансировка вам не подойдет, т.к. через 2 шейпера двойная скорость получается у абонента.

Share this post


Link to post
Share on other sites
похоже, действительно второй дефолт не анонсируется почему-то
Чудеса... Как же ж у нас то оно работает... Правда не на кваге а на сиске 72й. Один в один картинка в первом посте - только два дефолта с одной метрикой.

VS-SW1#sh ip ro vrf Internet 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "ospf 5", distance 110, metric 2, candidate default path
  Tag 5, type extern 1
  Redistributing via bgp 65500
  Advertised by bgp 65500 match internal external 1
  Last update from 172.16.130.52 on Vlan35, 3w4d ago
  Routing Descriptor Blocks:
    172.16.130.52, from 10.3.0.10, 3w4d ago, via Vlan35
      Route metric is 2, traffic share count is 1
      Route tag 5
  * 172.16.130.51, from 10.3.0.9, 3w4d ago, via Vlan35
      Route metric is 2, traffic share count is 1
      Route tag 5

Share this post


Link to post
Share on other sites
похоже, действительно второй дефолт не анонсируется почему-то
Чудеса... Как же ж у нас то оно работает... Правда не на кваге а на сиске 72й. Один в один картинка в первом посте - только два дефолта с одной метрикой.

да никаких чудес. сейчас сделано по схеме основной+резервный. в тот момент, когда я писал про отсутствие анонса дефолта, на резерве были погашены все bgp сессии. инжект дефолта с резервного бордера (В) при этом действительно отсутствовал (проверено), несмотря на default-information originate always в настройках оспф. корректное ли это поведение у ospfd, сейчас разбираюсь. стоило поднять одну из сессий, дефолт стал инжектироваться.
Если у вас бордеры шейпят, то такая балансировка вам не подойдет, т.к. через 2 шейпера двойная скорость получается у абонента.
вот за этот момент спасибо, вроде очевидно, а внимания не обращал :)

 

Share this post


Link to post
Share on other sites
можно генерировать дефолт через, скажем, сеть 4.0.0.0

т.е. если апстрим ее не отдает, дефолт с конкретного бордера перестает редистрибьютиться в ospf.

 

Кстати, а в кваге уже починили сию возможность ?

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
Sign in to follow this