Мартен Опубликовано 4 августа, 2009 (изменено) · Жалоба пытаюсь создать красивую схему ядра с резервированием и балансировкой. уверен, что колесо уже изобреталось, однако что-то не выходит красоты :( схема на картинке. вопрос такой возникает: как от бордеров проанонсировать дефолт так, чтобы исходящий трафик из сети не стекался на какой-то один роутер, а шел на тот бордер, через который сеть назначения ближе? опять же, при отказе канала А трафик должен идти со свитча С на бордер В, однако пока жив А, он будет продолжать анонсировать дефолт с меньшей метрикой и трафик пойдет на него. тут либо редистрибьют делать внешних маршрутов во внутреннюю сеть :( либо... тут мысли кончаются. как красивше сделать (L3 свитчей типа С в будущем может стать больше, как и бордеров)? во всех цисковских мурзилках даются общие принципы, а вот конкретной подобной схемы не встречал. PS чёрт, лишние картинки не убрать. сорри Изменено 4 августа, 2009 пользователем Мартен Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
CNick Опубликовано 4 августа, 2009 · Жалоба GLBP? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Мартен Опубликовано 4 августа, 2009 · Жалоба таак, уже интереснее :) а теперь представим, что бордеры на квагге Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Denis Samsonov Опубликовано 4 августа, 2009 · Жалоба Я у себя изобрел такую схему http://denjs.habrahabr.ru/blog/62439/ :) пока нареканий нету. правда с бордеров на шейперы я full-view отдаю Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
CNick Опубликовано 4 августа, 2009 · Жалоба таак, уже интереснее :) а теперь представим, что бордеры на квагге "во всех цисковских мурзилках даются общие принципы, а вот конкретной подобной схемы не встречал."В цисковских мурзилках тоже квагу юзают?) а еслиб вы не поленились почитать за GLBP то нашли бы opensource реализацию CARP А по поводу стекаться на один бордер не вижу смысла что-то разруливать. У вас между ними должна быть iBGP связаность, так что пофигу на какой бордер пойдет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Stak Опубликовано 4 августа, 2009 · Жалоба Дык а что мешает два дефолта с одной метрикой с бордеров отдавать? Заодно и балансировка будет. иБГП свазность у них есть, куда слать исходищий трафик разберутся... А входящий - тем более) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Denis Samsonov Опубликовано 4 августа, 2009 · Жалоба Кстати можно и с разной метрикой раздавать) Но при условии что есть внутреннее bgp между бордерами там они сами между собой разберуться - куда именно проще послать пакет Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
chocholl Опубликовано 5 августа, 2009 · Жалоба можно генерировать дефолт через, скажем, сеть 4.0.0.0 т.е. если апстрим ее не отдает, дефолт с конкретного бордера перестает редистрибьютиться в ospf. в штатном режиме два бордера дают дефолты с равной метрикой, для балансировки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Stak Опубликовано 5 августа, 2009 · Жалоба можно генерировать дефолт через, скажем, сеть 4.0.0.0т.е. если апстрим ее не отдает, дефолт с конкретного бордера перестает редистрибьютиться в ospf. в штатном режиме два бордера дают дефолты с равной метрикой, для балансировки. Можно и так конечно, но имхо лишнее.Достаточно при наличии между бордерами линка этого: в штатном режиме два бордера дают дефолты с равной метрикой, для балансировки. Р.S. Исходящий трафик попадет не на тот бордер, через который сеть назначения ближе, а на любой из двух. Но это обычно по барабану) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Valaskor Опубликовано 5 августа, 2009 (изменено) · Жалоба У меня сделано очень похоже, только шейперы и бордеры на два уровня разделены, между ними BGP крест-накрест, full-view в сеть не идет, только дефолт. Между шейперами и L3 каталистами - OSPF. Так как каталистов несколько и бордеры подключены к крайним, каждый каталист смотрит дефолтом в сторону ближайшего шейпера. Если использовать full-view, можно отфильтровать из него ближайшие сети аплинков + раздать вниз дефолт (как точно делать не знаю, с full-view плотно не работал). Была только одна проблема при постоении - OSPF маршруты имеют приоритет над BGP, поэтому делал дополнительные фильтры в зебре на шейпере. Изменено 5 августа, 2009 пользователем Valaskor Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Мартен Опубликовано 5 августа, 2009 · Жалоба можно генерировать дефолт через, скажем, сеть 4.0.0.0т.е. если апстрим ее не отдает, дефолт с конкретного бордера перестает редистрибьютиться в ospf. костыыыыль...в штатном режиме два бордера дают дефолты с равной метрикой, для балансировки.не очень-то балансируется оно. по умолчанию каталист принимает тот дефолт, который раньше пришел (если метрики одинаковые). весьма возможно, что это поведение можно изменить, но это не то, чего я хотел. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Мартен Опубликовано 5 августа, 2009 · Жалоба Была только одна проблема при постоении - OSPF маршруты имеют приоритет над BGP, поэтому делал дополнительные фильтры в зебре на шейпере.что-то обычно как раз наоборот.все озвученные варианты не решают проблему полностью - посылать трафик по кратчайшему пути через наиболее подходящий бордер. тут, видимо, только если фулл-вью на каталист заливать, но это только шеститонники смогут, да и то не все... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Valaskor Опубликовано 5 августа, 2009 (изменено) · Жалоба Когда ospf на каталисте дает 2 дефолта с одинаковой метрикой и весом, они оба появляются в таблице маршрутов и начинается per-destination load-balancing. Так как в этом случае начинает шейпится не правильно, пришлось в ospf вписать maximum-paths 1. Была только одна проблема при постоении - OSPF маршруты имеют приоритет над BGP, поэтому делал дополнительные фильтры в зебре на шейпере.что-то обычно как раз наоборот.все озвученные варианты не решают проблему полностью - посылать трафик по кратчайшему пути через наиболее подходящий бордер. тут, видимо, только если фулл-вью на каталист заливать, но это только шеститонники смогут, да и то не все... а как у вас дефолт в OSPF раздается?через default-information originate always? и если нет always, куда смотрит дефолт на бордере, через который не едет траффик? Изменено 5 августа, 2009 пользователем Valaskor Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Мартен Опубликовано 5 августа, 2009 · Жалоба Когда ospf на каталисте дает 2 дефолта с одинаковой метрикой и весом, они оба появляются в таблице маршрутов и начинается per-destination load-balancing. Так как в этом случае начинает шейпится не правильно, пришлось в ospf вписать maximum-paths 1.проверю, но почему-то точно помню, что, принимая два одинаковых дефолта, мой каталист прописывал в таблицу только одного из них.а как у вас дефолт в OSPF раздается?через default-information originate always? да. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Valaskor Опубликовано 5 августа, 2009 (изменено) · Жалоба Проверьте, еще можно посмотреть что в самом ospf творится: show ip ospf database | include 0.0.0.0 Дефолт же через ospf идет? Просто в bgp maximum-paths 1 по умолчанию стоит, нужно принудительно увеличивать. И где у вас шейпится траффик? Изменено 5 августа, 2009 пользователем Valaskor Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Мартен Опубликовано 5 августа, 2009 · Жалоба с шейпингом пока бордеры справляются. перестанут - выделю отдельные машины. а оспф да, надо поковырять, займусь вечерком. похоже, действительно второй дефолт не анонсируется почему-то Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Valaskor Опубликовано 5 августа, 2009 · Жалоба Если у вас бордеры шейпят, то такая балансировка вам не подойдет, т.к. через 2 шейпера двойная скорость получается у абонента. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Stak Опубликовано 5 августа, 2009 · Жалоба похоже, действительно второй дефолт не анонсируется почему-тоЧудеса... Как же ж у нас то оно работает... Правда не на кваге а на сиске 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Мартен Опубликовано 5 августа, 2009 · Жалоба похоже, действительно второй дефолт не анонсируется почему-тоЧудеса... Как же ж у нас то оно работает... Правда не на кваге а на сиске 72й. Один в один картинка в первом посте - только два дефолта с одной метрикой. да никаких чудес. сейчас сделано по схеме основной+резервный. в тот момент, когда я писал про отсутствие анонса дефолта, на резерве были погашены все bgp сессии. инжект дефолта с резервного бордера (В) при этом действительно отсутствовал (проверено), несмотря на default-information originate always в настройках оспф. корректное ли это поведение у ospfd, сейчас разбираюсь. стоило поднять одну из сессий, дефолт стал инжектироваться.Если у вас бордеры шейпят, то такая балансировка вам не подойдет, т.к. через 2 шейпера двойная скорость получается у абонента.вот за этот момент спасибо, вроде очевидно, а внимания не обращал :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 6 августа, 2009 · Жалоба можно генерировать дефолт через, скажем, сеть 4.0.0.0т.е. если апстрим ее не отдает, дефолт с конкретного бордера перестает редистрибьютиться в ospf. Кстати, а в кваге уже починили сию возможность ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...