Приветствую. Вопрос такой. Есть центральный офис и есть несколько наших филиалов в других городах. Между центральным офисом и филиалами подняты Site-to-Site IPSec тунели. В центральном офисе стоит рутер cisco 2821. В филиалах стоят cisco 1841. И центральный офис и филиалы выходят в инет через эзернет (фиксированный открытый ip-адрес есть везде). Проблема заключается в следующем. Последнее время, периодически в центральном офисе отваливается внешний канал, ну там у провайдера есть проблемы... Соответственно, нет ни инета, ни тунелей с нашими филиалами в эти моменты времени. У нас есть еще одним рутер cisco 2821. Появилась мысль подключить второй рутер cisco 2821 к другому провайдеру (ну и тоже купить у него открытый ip-адрес) и забэкапить выход в инет в ipsec тунели с нашими филиалами, а заодно и сам рутер. Т.е. если умирает канал с нашим "старым" провйдером, то весь трафик должен идти через "нового" провайдера. В принципе это более менее понятно как сделать (хотя бы через те же метрики у шлюзов по умолчанию). Вопрос в другом. Как забэкапить IPSec тунели с нашими филиалами при условии, что есть два рутера, "смотрящих" в инет и два совершенно разных внешних ip-адреса? В принципе, вполне устроит вариант, при котором при падении одного интернет-канала тунели VPN с филиалами тоже падали и устанавливались через какое-то небольшое время через другой канал. Что можете посоветовать?
Как я понимаю вариант с IPsec Stateful Failover мне не подходит. Как тогда можно сделать?
>[оверквотинг удален]
>весь трафик должен идти через "нового" провайдера. В принципе это более
>менее понятно как сделать (хотя бы через те же метрики у
>шлюзов по умолчанию). Вопрос в другом. Как забэкапить IPSec тунели с
>нашими филиалами при условии, что есть два рутера, "смотрящих" в инет
>и два совершенно разных внешних ip-адреса? В принципе, вполне устроит вариант,
>при котором при падении одного интернет-канала тунели VPN с филиалами тоже
>падали и устанавливались через какое-то небольшое время через другой канал. Что
>можете посоветовать?
>Как я понимаю вариант с IPsec Stateful Failover мне не подходит. Как
>тогда можно сделать?не надо 2й рутер...просто зарегистрировать свою AS и поднять BGP на 2х провайдеров.
>[оверквотинг удален]
>весь трафик должен идти через "нового" провайдера. В принципе это более
>менее понятно как сделать (хотя бы через те же метрики у
>шлюзов по умолчанию). Вопрос в другом. Как забэкапить IPSec тунели с
>нашими филиалами при условии, что есть два рутера, "смотрящих" в инет
>и два совершенно разных внешних ip-адреса? В принципе, вполне устроит вариант,
>при котором при падении одного интернет-канала тунели VPN с филиалами тоже
>падали и устанавливались через какое-то небольшое время через другой канал. Что
>можете посоветовать?
>Как я понимаю вариант с IPsec Stateful Failover мне не подходит. Как
>тогда можно сделать?как вариант, поднимаете два GRE с IPsec и протокол динамической маршрутизации
>как вариант, поднимаете два GRE с IPsec и протокол динамической маршрутизацииЦиска предлагает в случае 2х отдельных центральных роутеров DMVPN. Вроде как работает :)
Поищите по сайту Циско - там довольно много про него сказанно, + в цисковских рекомендациях по построению филиальной сети на ИПСек рекомендуется именно эта схема из за отсутствия единой точки отказа в "голове"
>[оверквотинг удален]
>>шлюзов по умолчанию). Вопрос в другом. Как забэкапить IPSec тунели с
>>нашими филиалами при условии, что есть два рутера, "смотрящих" в инет
>>и два совершенно разных внешних ip-адреса? В принципе, вполне устроит вариант,
>>при котором при падении одного интернет-канала тунели VPN с филиалами тоже
>>падали и устанавливались через какое-то небольшое время через другой канал. Что
>>можете посоветовать?
>>Как я понимаю вариант с IPsec Stateful Failover мне не подходит. Как
>>тогда можно сделать?
>
>как вариант, поднимаете два GRE с IPsec и протокол динамической маршрутизацииА есть ли вариант без использования gre и роутинга, а разруливания только самим ipsec'ом статически? Т.е., грубо говоря, в случае падения связи с таким то соседом, устанавливаем тунель с другим соседом?
>[оверквотинг удален]
>>>падали и устанавливались через какое-то небольшое время через другой канал. Что
>>>можете посоветовать?
>>>Как я понимаю вариант с IPsec Stateful Failover мне не подходит. Как
>>>тогда можно сделать?
>>
>>как вариант, поднимаете два GRE с IPsec и протокол динамической маршрутизации
>
>А есть ли вариант без использования gre и роутинга, а разруливания только
>самим ipsec'ом статически? Т.е., грубо говоря, в случае падения связи с
>таким то соседом, устанавливаем тунель с другим соседом?да, чуть выше вам ответили, это DMVPN
>[оверквотинг удален]
>>>>Как я понимаю вариант с IPsec Stateful Failover мне не подходит. Как
>>>>тогда можно сделать?
>>>
>>>как вариант, поднимаете два GRE с IPsec и протокол динамической маршрутизации
>>
>>А есть ли вариант без использования gre и роутинга, а разруливания только
>>самим ipsec'ом статически? Т.е., грубо говоря, в случае падения связи с
>>таким то соседом, устанавливаем тунель с другим соседом?
>
>да, чуть выше вам ответили, это DMVPNПри всем уважении к Вам, господа, но нафига Вы человеку мозги закампостировали? Зачем DMVPN? Зачем Gre по IPsec'у ??? Достаточно просто обычной связки IPSec'а и DPD. В стндартном IPSec'е в крипто мапе можно указать несколько set peer'ов, но в данном случае, для бэкапа set peer'а для первого в списке set peer'а нужно в конце дописать опцию default. И фсе. Теперь первый set peer будет дефолтовым, а к остальным set peer'ам будет устанавливаться тунель в случае отказа первого set peer'а, это будет делаться просто через DPD.
>[оверквотинг удален]
>>да, чуть выше вам ответили, это DMVPN
>
>При всем уважении к Вам, господа, но нафига Вы человеку мозги закампостировали?
>Зачем DMVPN? Зачем Gre по IPsec'у ??? Достаточно просто обычной связки
>IPSec'а и DPD. В стндартном IPSec'е в крипто мапе можно указать
>несколько set peer'ов, но в данном случае, для бэкапа set peer'а
>для первого в списке set peer'а нужно в конце дописать опцию
>default. И фсе. Теперь первый set peer будет дефолтовым, а к
>остальным set peer'ам будет устанавливаться тунель в случае отказа первого set
>peer'а, это будет делаться просто через DPD.Угу... это называется IPSec Direct Encapsulation для "филиалов", т.к. дальше надо настраивать головные роутеры (2 шт в нашем треде) для работы в связке :)
А это уже IPsec VPN WAN Design Overview
http://www.cisco.com/application/pdf/en/us/guest/netsol/ns17...там же плюсы и минусы разных вариантов.
И далее доки по 28хх серии IPSec часть.
И вообще - http://www.cisco.com/go/srnd
Solutions Reference Network Design (SRND) guides provide deployment scenarios that incorporate Cisco products and technologies into an architecture that is tested and documented in Cisco labs or field-proven.
>[оверквотинг удален]
>
>там же плюсы и минусы разных вариантов.
>
>И далее доки по 28хх серии IPSec часть.
>
>И вообще - http://www.cisco.com/go/srnd
>
>Solutions Reference Network Design (SRND) guides provide deployment scenarios that incorporate Cisco
>products and technologies into an architecture that is tested and documented
>in Cisco labs or field-proven.Зачем Вам такие сложности? Связку головных рутеров можно просто поднять через тот же HSRP для внутренних пользователей, соответственно какой-то из рутеров будет активным изначально в этой связке. На него из филиалов на внешний интерфейс делать set peer <адрес> default, а соответственно на второй головной рутер (который в связке в hsrp будет бэкапным) делать обычный set peer. Соответственно филильный рутер будет обнаруживать"смерть соседа" по DPD (dead peer detection) через кипаливы (которые в свою очередь опять же могут быть как по требованию, так и периодические). Ну и после обнаружения "смерти" филиальный рутер будет уже соединяться с бэкапным рутером, который уже к тому времени через hsrp уже станет активным для локальной сети и весь трафик пойдет через него. Чем Вам не нравиться такой вариант?
Можно ещё два маршрута через туннели
в tunnel mode ipsec с разными метриками.
Проще управлять трафиком: разные transform-set'ы,
разные ip mtu на туннелях и т.д.
С динамической маршрутизацией или без -
это в зависимости от требований к времени
переключения, сложности конфигурации и т.д.
>[оверквотинг удален]
>весь трафик должен идти через "нового" провайдера. В принципе это более
>менее понятно как сделать (хотя бы через те же метрики у
>шлюзов по умолчанию). Вопрос в другом. Как забэкапить IPSec тунели с
>нашими филиалами при условии, что есть два рутера, "смотрящих" в инет
>и два совершенно разных внешних ip-адреса? В принципе, вполне устроит вариант,
>при котором при падении одного интернет-канала тунели VPN с филиалами тоже
>падали и устанавливались через какое-то небольшое время через другой канал. Что
>можете посоветовать?
>Как я понимаю вариант с IPsec Stateful Failover мне не подходит. Как
>тогда можно сделать?Не надо второго роутера.На одном роутере прописываете два WAN адреса (используете инкапсуляцию dot1Q)- от двух разных провайдеров. затем в конфиге включаете такую запись track 1 rtr 1 reachability
Затем прописываете роуты на сетку один роут через одного провайдера, второй через другого, примерно так :
ip route 192.168.222.0 255.255.255.0 10.10.10.1 trac 1 (основной)
ip route 192.168.222.0 255.255.255.0 10.10.20.1 254 (резервный)
Теперь задаёте тайм аут опроса линка , так:
ip sla 1
icmp-echo 10.10.10.1 source-interface Fa 0/1.1
timeout 2000
frequency 3
ip sla schedule 1 life forever start-time nowТаким образом, когда линк первого провайдера отвалится по тайм-ауту, маршруты пойдут по второму роуту.
На другой стороне соответственно, прописываете два пира, две политики ipsec isakamp, но работать будет только тот, который активен в текущий момент :-)