psygex Опубликовано 17 сентября, 2010 · Жалоба Имееться следующая схема Значит так, маршрутизация внутреннего траффика между пользователями происходит на каталистах, на 7200 цисках поднят нат и подключены к инету (через 1 гейтвей в будущем планируется отдельно подключить ) Нужно настроить так чтоб загрузка на 72е была равномерная. На данный момент поднял между каталистами и 72ми EIGRP, а на 72 стоят разные пулы для ната но весь траффик идет через один роутер хотя EIGRP на каталисте показывает 4 идентичных маршрута к 72м. Может кто уже делал что то подобное , прошу совета ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alexandr Ovcharenko Опубликовано 17 сентября, 2010 · Жалоба PBR спасет отечественную демократию :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nnm Опубликовано 17 сентября, 2010 · Жалоба Не балансируется входящий или исходящий трафик? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
psygex Опубликовано 17 сентября, 2010 · Жалоба PBR спасет отечественную демократию :) Забыл сказать что при отключении одного из рутеров юзеры не должны почувствовать это. С PBR я настраивал лоад балансинг но при отключении одно из рутеров часть юзеров отрубало от инета. Не балансируется входящий или исходящий трафик? Как выше написал балансировка должна работать в сочетании с отказоустойчивостью. При отключении одного из рутеров весь трафик шел через другой Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NoSe Опубликовано 17 сентября, 2010 · Жалоба а GLBP не катит или тупо нет на 72-ой? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
psygex Опубликовано 17 сентября, 2010 · Жалоба а GLBP не катит или тупо нет на 72-ой? GLBP актуален если интерфейсы роутеров смотрели бы в сторону хостов. Между хостами и роутерами несколько подсетей. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NoSe Опубликовано 17 сентября, 2010 · Жалоба а GLBP не катит или тупо нет на 72-ой?GLBP актуален если интерфейсы роутеров смотрели бы в сторону хостов. Между хостами и роутерами несколько подсетей. в данном случае большей проблемой видится mac-адрес интерфейсов предпоследнего маршрутизатора, от имени которого шли бы все сессии... round-robin между двумя пуллами nat выглядел бы забавно. честно говоря я не понял в чем вопрос, нужно решение или трудность именно в конфигурации? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
psygex Опубликовано 17 сентября, 2010 · Жалоба а GLBP не катит или тупо нет на 72-ой?GLBP актуален если интерфейсы роутеров смотрели бы в сторону хостов. Между хостами и роутерами несколько подсетей. в данном случае большей проблемой видится mac-адрес интерфейсов предпоследнего маршрутизатора, от имени которого шли бы все сессии... round-robin между двумя пуллами nat выглядел бы забавно. честно говоря я не понял в чем вопрос, нужно решение или трудность именно в конфигурации? Нужно решение Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NoSe Опубликовано 17 сентября, 2010 (изменено) · Жалоба Нужно решение я конечно уже давно проектированием не занимался, но если: на обоих 72-х в рамках OSPF включить default information originate без приставки always, вручную поменять стоимость маршрутов на альтернативных интерфейсах(перекрестные линки) посредством ip ospf cost, то вроде бы все как бы должно заработать. То же самое можно и на IS-IS сделать. В общем, тема-то стандартная... Все интерфейсы L3 и все естественно в рамках Area 0. Только надо понимать, что в данном случае получается пассивная псевдо-балансировка. т.е. каждый коммутатор работает через свой маршрутизатор и в случае аварии переключается. Можно не меняя стоимости маршрутов анонсировать во внутреннюю область два дефолтных маршрута с идентичной метрикой. Тогда можно балансировать потоки per-flow(не per-packet!!!) между маршрутизаторами --- активная псевдо-балансировка. Особенностей конфигурации уже не помню. С балансировкой посредством EIGRP никогда не сталкивался. Изменено 17 сентября, 2010 пользователем NoSe Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nnm Опубликовано 17 сентября, 2010 · Жалоба А Catalyst какие? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
psygex Опубликовано 17 сентября, 2010 · Жалоба А Catalyst какие? 3750 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
yakuzzza Опубликовано 17 сентября, 2010 · Жалоба Между роутерами - HSRP. Для балансировки, а это только исходящий трафик, который косвенно влияет и на входящий - PBR. Для отслеживания шлюзов - IP SLA. Все должно работать. Рекомендую переходить на BGP. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Stak Опубликовано 17 сентября, 2010 · Жалоба я конечно уже давно проектированием не занимался, но если:<br />на обоих 72-х в рамках OSPF включить default information originate без приставки always, вручную поменять стоимость маршрутов на альтернативных интерфейсах(перекрестные линки) посредством ip ospf cost, то вроде бы все как бы должно заработать. То же самое можно и на IS-IS сделать. В общем, тема-то стандартная... Все интерфейсы L3 и все естественно в рамках Area 0.Только надо понимать, что в данном случае получается пассивная псевдо-балансировка. т.е. каждый коммутатор работает через свой маршрутизатор и в случае аварии переключается. Можно не меняя стоимости маршрутов анонсировать во внутреннюю область два дефолтных маршрута с идентичной метрикой. Тогда можно балансировать потоки per-flow(не per-packet!!!) между маршрутизаторами --- активная псевдо-балансировка. Особенностей конфигурации уже не помню. С балансировкой посредством EIGRP никогда не сталкивался. Вполне рабочее решение. Единственная проблема - что размер нат пула на каждой 72й должен вдвое превышать число активных на ней абонентов. Но это только для чистого ната актуально, с патом - некритично. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
psygex Опубликовано 18 сентября, 2010 (изменено) · Жалоба я конечно уже давно проектированием не занимался, но если:<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 ? Изменено 18 сентября, 2010 пользователем psygex Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Stak Опубликовано 18 сентября, 2010 · Жалоба Немного не так надо. Идея такая: юзеры, терминируемые на первом свиче, натятся через первый роутер, а терминируемые на втором свиче - через второй. Для этого нужен анонс 4х дефолтов, 2 из которых - с худшими метриками. А удвоенный размер нат-пула нужен для обеспечения резервирования, если одна из 72х даст дуба. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NoSe Опубликовано 20 сентября, 2010 (изменено) · Жалоба С внешними адресами нехвата . Возможно ли такое 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 я бы лучше отказался. Изменено 20 сентября, 2010 пользователем NoSe Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...