Перейти к содержимому
Калькуляторы

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

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

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

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

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

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

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

 

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

 

PS

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

post-13431-1249402339_thumb.png

post-13431-1249402452_thumb.png

post-13431-1249402496_thumb.png

post-13431-1249402913_thumb.png

Изменено пользователем Мартен

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Изменено пользователем Valaskor

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

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

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

через default-information originate always?

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

Изменено пользователем Valaskor

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

через default-information originate always?

да.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Изменено пользователем Valaskor

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

похоже, действительно второй дефолт не анонсируется почему-то
Чудеса... Как же ж у нас то оно работает... Правда не на кваге а на сиске 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 шейпера двойная скорость получается у абонента.
вот за этот момент спасибо, вроде очевидно, а внимания не обращал :)

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

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

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.