BGP+OSPF с резервированием и балансировкой.

[Мартен]

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

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

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

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

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

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

 

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

 

PS

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

Edited August 4, 2009 by Мартен

[CNick]

GLBP?

[Мартен]

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

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

[Denis Samsonov]

Я у себя изобрел такую схему http://denjs.habrahabr.ru/blog/62439/ :) пока нареканий нету. правда с бордеров на шейперы я full-view отдаю

 

[CNick]

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

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

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

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

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

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

[Stak]

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

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

[Denis Samsonov]

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

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

[chocholl]

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

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

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

 

[Stak]

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

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

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

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

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

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

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

[Valaskor]

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

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

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

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

Edited August 5, 2009 by Valaskor

[Мартен]

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

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

костыыыыль...

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

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

[Мартен]

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

что-то обычно как раз наоборот.

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

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

[Valaskor]

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

 

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

что-то обычно как раз наоборот.

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

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

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

через default-information originate always?

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

Edited August 5, 2009 by Valaskor

[Мартен]

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

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

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

через default-information originate always?

да.

 

[Valaskor]

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

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

 

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

Edited August 5, 2009 by Valaskor

[Мартен]

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

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

[Valaskor]

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

[Stak]

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

Чудеса... Как же ж у нас то оно работает... Правда не на кваге а на сиске 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

[Мартен]

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

Чудеса... Как же ж у нас то оно работает... Правда не на кваге а на сиске 72й. Один в один картинка в первом посте - только два дефолта с одной метрикой.

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

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

вот за этот момент спасибо, вроде очевидно, а внимания не обращал :)

 

[st_re]

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

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

 

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