forum.opennet.ru - "Site-to-Site IPSec, VTI (pritection ipsec). 2 ISP" (9)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"Site-to-Site IPSec, VTI (pritection ipsec). 2 ISP"

Форумы Маршрутизаторы CISCO и др. оборудование. (VPN, VLAN, туннель)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Site-to-Site IPSec, VTI (pritection ipsec). 2 ISP"		+/–
Сообщение от druidman (ok) on 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 и такая же ситуация с другими туннелями. Но как привязать маршрут туннелю, т.е. если пакет зашел в туннель, то в зависимости от физического интерфейса, к которому привязан туннель,после инкапсуции, пакет отправлялся в сторону соответсвующего провайдера Запутался я....может кто-нибудь поможет мне...буду очень признателен
Высказать мнение \| Ответить \| Правка \| Cообщить модератору

Оглавление

Site-to-Site IPSec, VTI (pritection ipsec). 2 ISP, GolDi, 17:03 , 25-Фев-10, (1)

Site-to-Site IPSec, VTI (pritection ipsec). 2 ISP, Gbyte, 21:12 , 25-Фев-10, (2)

Site-to-Site IPSec, VTI (pritection ipsec). 2 ISP, j_vw, 20:19 , 27-Фев-10, (3)

P.S., j_vw, 20:30 , 27-Фев-10, (4)

P.S., KG, 07:50 , 01-Мрт-10, (6)

P.S., KG, 07:52 , 01-Мрт-10, (7)
P.S., j_vw, 09:35 , 01-Мрт-10, (8)

Site-to-Site IPSec, VTI (pritection ipsec). 2 ISP, druidman, 07:31 , 01-Мрт-10, (5)

Site-to-Site IPSec, VTI (pritection ipsec). 2 ISP, bsdkom, 16:37 , 24-Мрт-10, (9)

Сообщения по теме [Сортировка по времени | RSS]

1. "Site-to-Site IPSec, VTI (pritection ipsec). 2 ISP" +/–

Сообщение от GolDi (??) on 25-Фев-10, 17:03

>[оверквотинг удален]
>Что мне использовать? Слежение за доступностью гейтов провайдеров(tracking)?
>
>И второе, как собственно будут доставляться анонсы ospf, анонс генерируемый на интерфейсе
>Tunnel1, у которого Source Fa0/0 смотрящий в сторону ISP1 должен отправляться
>на ISP1-GATE и такая же ситуация с другими туннелями. Но как
>привязать маршрут туннелю, т.е. если пакет зашел в туннель, то в
>зависимости от физического интерфейса, к которому привязан туннель отправлять в сторону
>соответсвующего провайдера
>
>Запутался я....может кто-нибудь поможет мне...буду очень признателен
Настройке ospf, сделайте чтобы анонсы через туннели имели разные adm dist (чтобы трафик не валил во все туннели), и все ваши вопросы отпадут

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

2. "Site-to-Site IPSec, VTI (pritection ipsec). 2 ISP" +/–

Сообщение от Gbyte (ok) on 25-Фев-10, 21:12

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

3. "Site-to-Site IPSec, VTI (pritection ipsec). 2 ISP" +/–

Сообщение от j_vw on 27-Фев-10, 20:19

Вот есть такое решение у человека:
http://i-ivanov.livejournal.com/tag/dmvpn
Решение рабочее (я повторял), однако есть несколько "но".
Задачка была откатана на эмуляторе...В реальной жизни все не совсем так.
Если не предпринимать никаких дополнительных действий, то работать будет только ОДИН тунель (в сторону дефолтного роута на каждой стороне). НИКАКОГО резервирования.
Как исправить:
Добавляем SLA с каждой стороны (переключаем дефолтный роутинг)... Получаем, опять же, ОДИН рабочий тунель, но с нормальным резервированием.....

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

4. "P.S." +/–

Сообщение от j_vw on 27-Фев-10, 20:30

Я до сих пор не увидел (не нашел) НИ ОДНОГО решения, которое бы позволяло нормально(честно) реализовать вариант два-в-два провайдера для GRE тунелей. Да, впрочем, и один-в-два.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

6. "P.S." +/–

Сообщение от KG (??) on 01-Мрт-10, 07:50

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

7. "P.S." +/–

Сообщение от KG (??) on 01-Мрт-10, 07:52

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

8. "P.S." +/–

Сообщение от j_vw on 01-Мрт-10, 09:35

>Правда пришлось городить loopback интерфейсы на стороне 2 пров.,
Можно глянуть кусок конфига?
> из-за бага в
>иосе (и щас есть).
И я по то же....

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

5. "Site-to-Site IPSec, VTI (pritection ipsec). 2 ISP" +/–

Сообщение от druidman (ok) on 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)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

9. "Site-to-Site IPSec, VTI (pritection ipsec). 2 ISP" +/–

Сообщение от bsdkom (ok) on 24-Мрт-10, 16:37

>[оверквотинг удален]
>Т.е. если туннель с другой стороны недостижим, то туннельный интерфейс уходит в
>down и соответствующий маршрут удаляется из таблицы маршрутизации и по keepalive
>удаляются SA (DPD).
>Затем использовал SLA для определения работоспособности канала и переключения на резервный.
>Таким образом, мы имеем всегда один рабочий туннель при одном рабочем провайдере
>с каждой стороны.
>На внутреннем интерфейсе привязана маршрутная карта, которая занимается маршрутизацией клиенстких машин в
>инет, и в общем случае не зависит от default route в
>основной таблице маршрутов.
>Да, использовал не GRE, а VTI (tunnel protection)
А можно конфиги глянуть?
Меня интересует реализация схеми 2ISP в 1ISP на VTI.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

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


	2. "Site-to-Site IPSec, VTI (pritection ipsec). 2 ISP"		+/–
	Сообщение от Gbyte (ok) on 25-Фев-10, 21:12
	два рутера будут видеть друг друга по каждому туннелю - устанавливать соседские отношения по ospf. если туннель падает, то соседские отношения по данному тунелю разрываются, маршрут через этот конкретный тоннель удаляется из таблицы ospf и (если он был) из таблицы маршрутизации. таким образом трафик не будет просто так уничтожаться, пока есть хотя бы один тоннель, трафик пойдет по тоннелю.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	3. "Site-to-Site IPSec, VTI (pritection ipsec). 2 ISP"		+/–
	Сообщение от j_vw on 27-Фев-10, 20:19
	Вот есть такое решение у человека: http://i-ivanov.livejournal.com/tag/dmvpn Решение рабочее (я повторял), однако есть несколько "но". Задачка была откатана на эмуляторе...В реальной жизни все не совсем так. Если не предпринимать никаких дополнительных действий, то работать будет только ОДИН тунель (в сторону дефолтного роута на каждой стороне). НИКАКОГО резервирования. Как исправить: Добавляем SLA с каждой стороны (переключаем дефолтный роутинг)... Получаем, опять же, ОДИН рабочий тунель, но с нормальным резервированием..... Если еще добавить local policy route-map то получим 3 тунеля (не работает резерв-резерв).... Вообще то ситуация загадочная, но факт (или лыжи не едут ;) )... Ну и бегает OSPF. Замечу, что время схождения сетки, в основном, зависит от таймаутов SLA (а не от OSPF). Как то так ;)
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	4. "P.S."		+/–
	Сообщение от j_vw on 27-Фев-10, 20:30
	Я до сих пор не увидел (не нашел) НИ ОДНОГО решения, которое бы позволяло нормально(честно) реализовать вариант два-в-два провайдера для GRE тунелей. Да, впрочем, и один-в-два.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	6. "P.S."		+/–
	Сообщение от KG (??) on 01-Мрт-10, 07:50
	>Я до сих пор не увидел (не нашел) НИ ОДНОГО решения, которое >бы позволяло нормально(честно) реализовать вариант два-в-два провайдера для GRE тунелей. Да, >впрочем, и один-в-два. А у меня сделано, 2 в 1, Gre шифрованный ИПсеком, EIGRP, сходимость 2 сек :) Правда пришлось городить loopback интерфейсы на стороне 2 пров., из-за бага в иосе (и щас есть).
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	7. "P.S."		+/–
	Сообщение от KG (??) on 01-Мрт-10, 07:52
	>А у меня сделано, 2 в 1, Gre шифрованный ИПсеком, EIGRP, сходимость >2 сек :) >Правда пришлось городить loopback интерфейсы на стороне 2 пров., из-за бага в >иосе (и щас есть). Пардон, Loopback пришлось городить из-за gre + route map + ios bug :)
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	8. "P.S."		+/–
	Сообщение от j_vw on 01-Мрт-10, 09:35
	>Правда пришлось городить loopback интерфейсы на стороне 2 пров., Можно глянуть кусок конфига? > из-за бага в >иосе (и щас есть). И я по то же....
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	5. "Site-to-Site IPSec, VTI (pritection ipsec). 2 ISP"		+/–
	Сообщение от druidman (ok) on 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)
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


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