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

Load balancing на 7200 цисках

Имееться следующая схема

cff4a28f91ad.jpg

Значит так, маршрутизация внутреннего траффика между пользователями происходит на каталистах, на 7200 цисках поднят нат и подключены к инету (через 1 гейтвей в будущем планируется отдельно подключить ) Нужно настроить так чтоб загрузка на 72е была равномерная.

На данный момент поднял между каталистами и 72ми EIGRP, а на 72 стоят разные пулы для ната

но весь траффик идет через один роутер хотя EIGRP на каталисте показывает 4 идентичных маршрута к 72м. Может кто уже делал что то подобное , прошу совета )

Share this post


Link to post
Share on other sites

Не балансируется входящий или исходящий трафик?

Share this post


Link to post
Share on other sites
PBR спасет отечественную демократию :)

Забыл сказать что при отключении одного из рутеров юзеры не должны почувствовать это. С PBR я настраивал лоад балансинг но при отключении одно из рутеров часть юзеров отрубало от инета.

 

Не балансируется входящий или исходящий трафик?

Как выше написал балансировка должна работать в сочетании с отказоустойчивостью. При отключении одного из рутеров весь трафик шел через другой

Share this post


Link to post
Share on other sites

а GLBP не катит или тупо нет на 72-ой?

Share this post


Link to post
Share on other sites

а GLBP не катит или тупо нет на 72-ой?

GLBP актуален если интерфейсы роутеров смотрели бы в сторону хостов. Между хостами и роутерами несколько подсетей.

Share this post


Link to post
Share on other sites
а GLBP не катит или тупо нет на 72-ой?
GLBP актуален если интерфейсы роутеров смотрели бы в сторону хостов. Между хостами и роутерами несколько подсетей.

в данном случае большей проблемой видится mac-адрес интерфейсов предпоследнего маршрутизатора, от имени которого шли бы все сессии... round-robin между двумя пуллами nat выглядел бы забавно. честно говоря я не понял в чем вопрос, нужно решение или трудность именно в конфигурации?

Share this post


Link to post
Share on other sites
а GLBP не катит или тупо нет на 72-ой?
GLBP актуален если интерфейсы роутеров смотрели бы в сторону хостов. Между хостами и роутерами несколько подсетей.

в данном случае большей проблемой видится mac-адрес интерфейсов предпоследнего маршрутизатора, от имени которого шли бы все сессии... round-robin между двумя пуллами nat выглядел бы забавно. честно говоря я не понял в чем вопрос, нужно решение или трудность именно в конфигурации?

Нужно решение

Share this post


Link to post
Share on other sites
Нужно решение

я конечно уже давно проектированием не занимался, но если:

на обоих 72-х в рамках OSPF включить default information originate без приставки always, вручную поменять стоимость маршрутов на альтернативных интерфейсах(перекрестные линки) посредством ip ospf cost, то вроде бы все как бы должно заработать. То же самое можно и на IS-IS сделать. В общем, тема-то стандартная... Все интерфейсы L3 и все естественно в рамках Area 0.

 

Только надо понимать, что в данном случае получается пассивная псевдо-балансировка. т.е. каждый коммутатор работает через свой маршрутизатор и в случае аварии переключается. Можно не меняя стоимости маршрутов анонсировать во внутреннюю область два дефолтных маршрута с идентичной метрикой. Тогда можно балансировать потоки per-flow(не per-packet!!!) между маршрутизаторами --- активная псевдо-балансировка. Особенностей конфигурации уже не помню. С балансировкой посредством EIGRP никогда не сталкивался.

Edited by NoSe

Share this post


Link to post
Share on other sites

Между роутерами - HSRP. Для балансировки, а это только исходящий трафик, который косвенно влияет и на входящий - PBR. Для отслеживания шлюзов - IP SLA.

Все должно работать. Рекомендую переходить на BGP.

Share this post


Link to post
Share on other sites

я конечно уже давно проектированием не занимался, но если:<br />на обоих 72-х в рамках OSPF включить default information originate без приставки always, вручную поменять стоимость маршрутов на альтернативных интерфейсах(перекрестные линки) посредством ip ospf cost, то вроде бы все как бы должно заработать. То же самое можно и на IS-IS сделать. В общем, тема-то стандартная... Все интерфейсы L3 и все естественно в рамках Area 0.Только надо понимать, что в данном случае получается пассивная псевдо-балансировка. т.е. каждый коммутатор работает через свой маршрутизатор и в случае аварии переключается. Можно не меняя стоимости маршрутов анонсировать во внутреннюю область два дефолтных маршрута с идентичной метрикой. Тогда можно балансировать потоки per-flow(не per-packet!!!) между маршрутизаторами --- активная псевдо-балансировка. Особенностей конфигурации уже не помню. С балансировкой посредством EIGRP никогда не сталкивался.

Вполне рабочее решение. Единственная проблема - что размер нат пула на каждой 72й должен вдвое превышать число активных на ней абонентов. Но это только для чистого ната актуально, с патом - некритично.

Share this post


Link to post
Share on other sites
я конечно уже давно проектированием не занимался, но если:<br />на обоих 72-х в рамках OSPF включить default information originate без приставки always, вручную поменять стоимость маршрутов на альтернативных интерфейсах(перекрестные линки) посредством ip ospf cost, то вроде бы все как бы должно заработать. То же самое можно и на IS-IS сделать. В общем, тема-то стандартная... Все интерфейсы L3 и все естественно в рамках Area 0.Только надо понимать, что в данном случае получается пассивная псевдо-балансировка. т.е. каждый коммутатор работает через свой маршрутизатор и в случае аварии переключается. Можно не меняя стоимости маршрутов анонсировать во внутреннюю область два дефолтных маршрута с идентичной метрикой. Тогда можно балансировать потоки per-flow(не per-packet!!!) между маршрутизаторами --- активная псевдо-балансировка. Особенностей конфигурации уже не помню. С балансировкой посредством EIGRP никогда не сталкивался.
Вполне рабочее решение. Единственная проблема - что размер нат пула на каждой 72й должен вдвое превышать число активных на ней абонентов. Но это только для чистого ната актуально, с патом - некритично.

С внешними адресами нехвата . Возможно ли такое http://forum.nag.ru/forum/index.php?showtopic=60341

А какаю балансировку делают протоколы маршрутизации по умолчанию (OSPF , IS-IS) ? per flow или per packet

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

И еще вопрос: как лучше соеденять рутеры со свичами L3 to L3 или L3 to SVI ?

Edited by psygex

Share this post


Link to post
Share on other sites

Немного не так надо. Идея такая: юзеры, терминируемые на первом свиче, натятся через первый роутер, а терминируемые на втором свиче - через второй. Для этого нужен анонс 4х дефолтов, 2 из которых - с худшими метриками. А удвоенный размер нат-пула нужен для обеспечения резервирования, если одна из 72х даст дуба.

Share this post


Link to post
Share on other sites
С внешними адресами нехвата . Возможно ли такое http://forum.nag.ru/forum/index.php?showtopic=60341

А какаю балансировку делают протоколы маршрутизации по умолчанию (OSPF , IS-IS) ? per flow или per packet

ой, это лучше cisco.com спросить или того, у кого рука набита. вот, почитайте

http://www.cisco.com/en/US/tech/tk365/tech...080094820.shtml

 

я бы кстати рекомендовал в качестве IGP IS-IS. Хотя тут в общем не принципиально.

 

С внешними адресами нехвата . Возможно ли такое

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

И еще вопрос: как лучше соеденять рутеры со свичами L3 to L3 или L3 to SVI ?

а заработал наверное потому, что при пинге Destination IP не меняется, т.е. считается сессия одна... собственно, и балансировать-то и нечего. ИМХО, от SVI я бы лучше отказался.

Edited by NoSe

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