Два провайдера + VPN

[deepwalker]

Исходный данные - есть, допустим, центральный офис, где собственно центр сети и находится, есть 7 филиалов в разных городах, с разными провайдерами, конечно же. Имеются cisco PIX 501 в каждом сетевом узле. На данный момент VPN построены на ipsec. Ну и хочется конечно надежности, отсутствия простоев. Хочется добавить альтернативные подключения. Надо чтобы работало по сл схеме - падает где то связь между двумя точками, и автоматически соединение пытается перейти на другой канал. Возможно, что вскоре будут приобретены по крайней мере два маршрутизатора 1841+уже есть один 806й.

Вопрос: кто что может сказать по этому вопросу? Может ссылка толковая есть?

Предпологаемое решение, выведенное из чтения литературы:
Есть еще в центральном офисе маршрутизатор 806, и есть протокол hsrp. Допустим создать ipsec соединение между двумя маршрутизаторами в центральном офисе и удаленным. Затем поднять на основном GRE туннель (int tunnel 0) с этой точкой и настроить HSRP с тестированием этого самого tunnel 0. Я так мыслю что при разрыве связи интерфейс tun 0 упадет, и роль шлюза перейдет к резервному роутеру, а при поднятии обратно. Вот скажите - это полный бред или реально может сработать? Мне то тестировать не на чем...

А еще : )) а как можно это в одном устройстве совместить? Сами понимаете - два роутера это в два раза больше денег. И наверное второй стоит ставить только на случай вылета основного. Как то нужно маршрутизацию наверное настроить, только пока мысль никак не родится. Маловато еще прочел.

[visual]

Вопрос: кто что может сказать по этому вопросу? Может ссылка толковая есть?

в целом - классическая схема подключения к двум isp-ам.
я бы предложил вот такой вариант (в упрощенном виде):

Code: [Select]

                   -- ISP1 --
                  /            \
pix -- router --<              >-- router -- pix
                  \            /
                    -- ISP2 --

Есть еще в центральном офисе маршрутизатор 806, и есть протокол hsrp. Допустим создать ipsec соединение между двумя маршрутизаторами в центральном офисе и удаленным. Затем поднять на основном GRE туннель (int tunnel 0) с этой точкой и настроить HSRP с тестированием этого самого tunnel 0. Я так мыслю что при разрыве связи интерфейс tun 0 упадет, и роль шлюза перейдет к резервному роутеру, а при поднятии обратно. Вот скажите - это полный бред или реально может сработать?

если у тебя упадет рутер в филиале, то упадет и сам туннель. соответ ни один хост в сети филиала не сможет физически взаимодействовать с рутером в центральном офисе. HSRP используют несколько иначе. почитай внимательно http://www.cisco.com/univercd/cc/td/doc/ci...k/ics/cs009.htm

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

А еще : )) а как можно это в одном устройстве совместить? Сами понимаете - два роутера это в два раза больше денег. И наверное второй стоит ставить только на случай вылета основного. Как то нужно маршрутизацию наверное настроить, только пока мысль никак не родится. Маловато еще прочел.

[snapback]6287[/snapback]

достаточно по одному рутеру с двумя внешними (по кол-ву независимых ISP-ов) и одним ethernet-ом для pix-а во все филилы. HSRP с двумя и более маршрутизаторами в каждом филиале имеет смысл ставить только в том случае, если цена простоя измеряется очень серьезными цифрами. иначе заложи в ЗИП пару комплектов на случай выхода из строя. как только что-то погорело, вытащил железку из ЗИП-а, влил нужный конфиг и отправил гонца на замену железки.

[deepwalker]

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

Не, не так. В смысле туннеля два, через каждого ISPa. Основной падает и его роль умолчального маршрутера переходит ко второму. Я так имел в виду. Ну это сырой конечно очень вариант : )) Ой дошло... Ну тогда наверное роутер филиала при упавшем основном канале может пробрасывать трафик по резервному.

достаточно по одному рутеру с двумя внешними (по кол-ву независимых ISP-ов) и одним ethernet-ом для pix-а во все филилы.

А как канал в таком случае будет держаться? В смысле канал между пиксами проложен через рутеры? Или как? Ведь в таком случае придется наверное делать так, чтобы у пиксов были реальные IP, и они роутились через обоих провов... Или поднимать канал на роутерах, а пикс будет иметь внутренний IP? Зачем он тогда вообще?

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

А как у пиксов такое сделать я вообще пока не нашел : (( В смысле я не знаю как пиксы могут резервировать каналы.

Меня смущает что у пиксов при поднятых ipsec каналах, таблица маршрутизации ничего не отображает. Отсюда непонимание как же с этим работать. А когда есть тунельный интерфейс все становится как то прозрачнее. Вот только пиксы видимо его не поддерживают.

[visual]

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

А как канал в таком случае будет держаться? В смысле канал между пиксами проложен через рутеры? Или как? Ведь в таком случае придется наверное делать так, чтобы у пиксов были реальные IP, и они роутились через обоих провов... Или поднимать канал на роутерах, а пикс будет иметь внутренний IP? Зачем он тогда вообще?

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

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

в твоем пиксе нет ни OSPF, ни BGP, ни тривиального RIP-а?
как только перестал анонситься маршрут с основного канала, автоматически идешь по каналу с большей метрикой (это может быть статика с большой метрикой).

Меня смущает что у пиксов при поднятых ipsec каналах, таблица маршрутизации ничего не отображает.

у тебя статическая маршрутизация на пиксах?

[deepwalker]

На пиксах нет никакой маршрутизации, абсолютно. Ее никто и не настраивал. Только access-list's прописаны и все. Она им и не нужна в принципе. Гонять трафик через третьего не планировалось (хотя возможно и стоит, пока мало узлов и full-mesh можно легко админить. Хотя наверное маловато проку будет). Вот читал талмуд на 1000 страниц про VPN, ну в основном средствами ipsec естественно. Динамические крипто мапы, да какие угодно Crypto там. А про маршрутизацию ни гугу толком... Как же на нее влиять то. Вот я только один путь и увидел - int tunnel 0 Продолжаю рыться в книгах, но на начальном этапе пока смутно предcтавляешь себе что же конкретно ищещь - поиск труден.

[deepwalker]

Допустим я напишу между двумя роутерами у каждого из которых два подключения к разным ISP крипто мапы. Где пойдет трафик? Для меня это как то не прозрачно.
А вот если прописываешь GRE туннель и назначаешь ему крипто мап, то  тут более менее становится ясно. Можно уже маршруты прописывать, назначать административные веса. В общем - было бы что покрутить, быстрее бы значительно наверное процесс понимания шел : ))