URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID6
Нить номер: 20569
[ Назад ]

Исходное сообщение
"Site-to-Site IPSec, VTI (pritection ipsec). 2 ISP"

Отправлено druidman , 25-Фев-10 16:49 
Существует такая задача:

Соединить два подразделения.
На каждой стороне Cisco 2811 (ipadvances). На каждой стороне 2 провайдера.
Нужно сделать максимально отказоустойчивую конфигурацию.

Сделано по четыре туннельных интерфейса с каждой стороны (по принципу "Каждый с каждым", по два туннеля на каждый физический интерфейс).
Предполагается поднятие OSPF на интерфейсах для автоматического выбора туннеля.
У меня есть некоторые фундаментальные недопонимания по поводу маршрутизации.
--------------------------
1. Пакет пришедший из локальной сети (local-net1) с адресом назначения из локальной сети на другой стороне (local-net2) анализируется в таблице маршрутизации и находя запись вида
ip route localnet2 tunnel 1 и отправляется в Tunnel 1, где шифруется, затем инкапсулируется и опять просматривается таблица маршрутизации, где ищется запись вида 0.0.0.0 0.0.0.0 ISP1-GATE и пакет отправляется по указанному пути (если не находит маршрут, то уничтожается).

Так вот у меня вопрос: Как сделать так, что выбрав маршрут с меньшей метрикой (по сути выбрав туннель) пакет впоследствии отправлялся через провайдера, в сторону которого смотрит физический интерфейс, к которому привязан этот туннель. Если канал пропал, то из таблицы маршрутизации убирается этот маршрут посредством ospf и выбирается другой туннель, возможно смотрящий на другого провайдера и соответственно маршрут надо менять.
Что мне использовать? Слежение за доступностью гейтов провайдеров(tracking)?

И второе, как собственно будут доставляться анонсы ospf, анонс генерируемый на интерфейсе Tunnel1, у которого Source Fa0/0 смотрящий в сторону ISP1 должен отправляться на ISP1-GATE и такая же ситуация с другими туннелями. Но как привязать маршрут туннелю, т.е. если пакет зашел в туннель, то в зависимости от физического интерфейса, к которому привязан туннель,после инкапсуции, пакет отправлялся в сторону соответсвующего провайдера

Запутался я....может кто-нибудь поможет мне...буду очень признателен


Содержание

Сообщения в этом обсуждении
"Site-to-Site IPSec, VTI (pritection ipsec). 2 ISP"
Отправлено GolDi , 25-Фев-10 17:03 
>[оверквотинг удален]
>Что мне использовать? Слежение за доступностью гейтов провайдеров(tracking)?
>
>И второе, как собственно будут доставляться анонсы ospf, анонс генерируемый на интерфейсе
>Tunnel1, у которого Source Fa0/0 смотрящий в сторону ISP1 должен отправляться
>на ISP1-GATE и такая же ситуация с другими туннелями. Но как
>привязать маршрут туннелю, т.е. если пакет зашел в туннель, то в
>зависимости от физического интерфейса, к которому привязан туннель отправлять в сторону
>соответсвующего провайдера
>
>Запутался я....может кто-нибудь поможет мне...буду очень признателен

Настройке ospf, сделайте чтобы анонсы через туннели имели разные adm dist (чтобы трафик не валил во все туннели), и все ваши вопросы отпадут


"Site-to-Site IPSec, VTI (pritection ipsec). 2 ISP"
Отправлено Gbyte , 25-Фев-10 21:12 
два рутера будут видеть друг друга по каждому туннелю - устанавливать соседские отношения по ospf.
если туннель падает, то соседские отношения по данному тунелю разрываются, маршрут через этот конкретный тоннель удаляется из таблицы ospf и (если он был) из таблицы маршрутизации.

таким образом трафик не будет просто так уничтожаться, пока есть хотя бы один тоннель, трафик пойдет по тоннелю.


"Site-to-Site IPSec, VTI (pritection ipsec). 2 ISP"
Отправлено j_vw , 27-Фев-10 20:19 
Вот есть такое решение у человека:
http://i-ivanov.livejournal.com/tag/dmvpn

Решение рабочее (я повторял), однако есть несколько "но".

Задачка была откатана на эмуляторе...В реальной жизни все не совсем так.
Если не предпринимать никаких дополнительных действий, то работать будет только ОДИН тунель (в сторону дефолтного роута на каждой стороне). НИКАКОГО резервирования.

Как исправить:

Добавляем SLA с каждой стороны (переключаем дефолтный роутинг)... Получаем, опять же, ОДИН рабочий тунель, но с нормальным резервированием.....

Если еще добавить local policy route-map  то получим 3 тунеля (не работает резерв-резерв)....
Вообще то ситуация загадочная, но факт (или лыжи не едут ;) )...

Ну и бегает OSPF.
Замечу, что время схождения сетки, в основном, зависит от таймаутов SLA (а не от OSPF).

Как то так ;)


"P.S."
Отправлено j_vw , 27-Фев-10 20:30 
Я до сих пор не увидел (не нашел) НИ ОДНОГО решения, которое бы позволяло нормально(честно) реализовать вариант два-в-два провайдера для GRE тунелей. Да, впрочем, и один-в-два.


"P.S."
Отправлено KG , 01-Мрт-10 07:50 
>Я до сих пор не увидел (не нашел) НИ ОДНОГО решения, которое
>бы позволяло нормально(честно) реализовать вариант два-в-два провайдера для GRE тунелей. Да,
>впрочем, и один-в-два.

А у меня сделано, 2 в 1, Gre шифрованный ИПсеком, EIGRP, сходимость 2 сек :)
Правда пришлось городить loopback интерфейсы на стороне 2 пров., из-за бага в иосе (и щас есть).


"P.S."
Отправлено KG , 01-Мрт-10 07:52 

>А у меня сделано, 2 в 1, Gre шифрованный ИПсеком, EIGRP, сходимость
>2 сек :)
>Правда пришлось городить loopback интерфейсы на стороне 2 пров., из-за бага в
>иосе (и щас есть).

Пардон, Loopback пришлось городить из-за gre + route map + ios bug :)



"P.S."
Отправлено j_vw , 01-Мрт-10 09:35 

>Правда пришлось городить loopback интерфейсы на стороне 2 пров.,

Можно глянуть кусок конфига?

> из-за бага в
>иосе (и щас есть).

И я по то же....


"Site-to-Site IPSec, VTI (pritection ipsec). 2 ISP"
Отправлено druidman , 01-Мрт-10 07:31 
>Вот есть такое решение у человека:
>http://i-ivanov.livejournal.com/tag/dmvpn

Спасибо, обязательно изучу материал..
Пока реализовано с одной стороны банально просто, с другой собственно довольно эффективно:

Обошелся и без OSPF.

Использовал 4 маршрута вида:
ip route 192.168.2.0 255.255.255.0 Tunnel0
ip route 192.168.2.0 255.255.255.0 Tunnel1 2
ip route 192.168.2.0 255.255.255.0 Tunnel2 3
ip route 192.168.2.0 255.255.255.0 Tunnel3 4

Просто разные AD.
В туннелях и конфигурации isakmp использовал keepalive/
Т.е. если туннель с другой стороны недостижим, то туннельный интерфейс уходит в down и соответствующий маршрут удаляется из таблицы маршрутизации и по keepalive удаляются SA (DPD).
Затем использовал SLA для определения работоспособности канала и переключения на резервный.
Таким образом, мы имеем всегда один рабочий туннель при одном рабочем провайдере с каждой стороны.
На внутреннем интерфейсе привязана маршрутная карта, которая занимается маршрутизацией клиенстких машин в инет, и в общем случае не зависит от default route в основной таблице маршрутов.
Да, использовал не GRE, а VTI (tunnel protection)


"Site-to-Site IPSec, VTI (pritection ipsec). 2 ISP"
Отправлено bsdkom , 24-Мрт-10 16:37 
>[оверквотинг удален]
>Т.е. если туннель с другой стороны недостижим, то туннельный интерфейс уходит в
>down и соответствующий маршрут удаляется из таблицы маршрутизации и по keepalive
>удаляются SA (DPD).
>Затем использовал SLA для определения работоспособности канала и переключения на резервный.
>Таким образом, мы имеем всегда один рабочий туннель при одном рабочем провайдере
>с каждой стороны.
>На внутреннем интерфейсе привязана маршрутная карта, которая занимается маршрутизацией клиенстких машин в
>инет, и в общем случае не зависит от default route в
>основной таблице маршрутов.
>Да, использовал не GRE, а VTI (tunnel protection)

А можно конфиги глянуть?
Меня интересует реализация схеми 2ISP в 1ISP на VTI.