Load balancing на 7200 цисках

[psygex]

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

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

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

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

[Alexandr Ovcharenko]

PBR спасет отечественную демократию :)

[nnm]

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

[psygex]

PBR спасет отечественную демократию :)

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

 

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

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

[NoSe]

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

[psygex]

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

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

[NoSe]

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

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

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

[psygex]

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

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

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

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

[NoSe]

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

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

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

 

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

Edited September 17, 2010 by NoSe

[nnm]

А Catalyst какие?

[psygex]

А Catalyst какие?

3750

[yakuzzza]

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

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

[Stak]

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

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

[psygex]

я конечно уже давно проектированием не занимался, но если:<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 September 18, 2010 by psygex

[Stak]

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

[NoSe]

С внешними адресами нехвата . Возможно ли такое 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 September 20, 2010 by NoSe