antiCisco blogs


блоги по технологиям и оборудованию cisco от инструкторов

Опубликовано 17 Апрель , 2012

В предыдущей части блога  DMVPN (Dynamic Multipoint VPN). Часть 1.   были рассмотрены основы технологии DMVPN и рассмотрен  базовый вариант настройки сервиса DMVPN без элементов отказоустойчивости.   Если вы с этой технологией совсем не знакомы,  рекомендую ознакомиться сначала с первой частью.

Одно из главных преимуществ DMVPN – возможность построения отказоустойчивых виртуальных сетей на базе классического подхода посредством использованием протоколов динамической маршрутизации. Шифрованное mGRE облако фактически представляет собой легко масштабируемый L3 транспорт, прозрачный для протоколов маршрутизации – в этом основное преимущество перед классическим IPsec.

Рассмотрим наиболее сложную в плане отказоустойчивости схему, включающую всевозможные варианты :

  • 2 DMVPN hub-а в центральном офисе.
  • 3 провайдера в центральном офисе.
  • 1 из hub-ов подключен одновременно к двум провайдерам.
  • 2 удаленных Spoke офиса.
  • 1 из spoke-ов подключен одновременно к двум провайдерам.

(обращаю особое внимание на то, что приведенная схема ни коим образом не относится к рекомендациям по дизайну/best practice. Очевидно, что нет большого смысла заводить 2 облака на маршрутизатор, если у тебя 2 маршрутизатора. Цель статьи — рассмотрение всех возможных вариантов отказоустойчивости, которые могут быть применимы, когда маршрутизатор 1, и т.д. )
Лабораторный стенд будет иметь следующий вид:

 

Итак, в данной схеме со стороны центрального офиса мы имеем 2  HUB маршрутизатора и 2 провайдера, оба из которых терминируются на первом маршрутизаторе, и один на втором.  Нашей целью является организовать свое mGRE облако поверх каждого провайдерского линка центрального офиса. Соответственно мы будем иметь 2 виртуальных туннельных mGRE интерфейса на  первом маршрутизаторе и 1 mGRE интерфейс на втором.  Итого 3 облака.  И на каждом Spoke маршрутизаторе будет терминироваться 3 туннельных интерфейса.  На Spoke_2 — первое облако будет работать через первого провайдера — остальные два через второго. Маршрутизатор LAN_CORE – эмулирует ядро локальной сети центрального офиса.

Основным вопросом в данной ситуации является: как заставить трафик интересующего туннельного mGRE интерфейса ходить всегда через соответствующего провайдера?  Ответом на этот вопрос является весьма простая технология Tunnel route selection, которая непосредственно в настройках туннельного интерфейса позволяет явным образом указать физический интерфейс, через который должен маршрутизироваться туннельный трафик: tunnel route-via interface-type interface-number {mandatory | preferred}.  Важно понимать, что данная опция работает только в том случае, если в таблице маршрутизации имеется соответствующий маршрут!

Вторым важным вопросом является:  как Spoke маршрутизатор сможет понять, к какому туннельному интерфейсу отнести приходящий GRE пакет?   Для этого существует технология tunnel key.  Данный механизм осуществляет маркировку GRE пакетов заданным значением tunnel key. Маркировка осуществляется  посредством записи  значения в добавляемые 4 байта к GRE заголовку.

Приступим к конфигурации наших маршрутизаторов.  Тестовая лаборатория собрана и отлажена в GNS3, платформа 7200 NPE-400, версия 15.0(1)M. Аналогично подобная конфигурация успешно опробована в боевой среде на платформах 7200 NPE-G2, ISR 1800/2800. В том числе с версиями 12.4(24)T  и более ранними.

 

1.) Первоначальная конфигурация:

HUB 1:
interface FastEthernet0/0
ip address 10.10.10.1 255.255.255.0
!
interface FastEthernet1/0
ip address 1.1.1.2 255.255.255.0
!
interface FastEthernet2/0
ip address 2.2.2.2 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 1.1.1.1
ip route 0.0.0.0 0.0.0.0 2.2.2.1

HUB 2:
interface FastEthernet0/0
ip address 10.10.10.2 255.255.255.0
!
interface FastEthernet2/0
ip address 2.2.2.3 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 2.2.2.1

INTERNET:
interface FastEthernet1/0
ip address 1.1.1.1 255.255.255.0
!
interface FastEthernet2/0
ip address 2.2.2.1 255.255.255.0
!
interface FastEthernet3/0
ip address 3.3.3.1 255.255.255.0
!
interface FastEthernet4/0
ip address 4.4.4.1 255.255.255.0
!
interface FastEthernet5/0
ip address 5.5.5.1 255.255.255.0
!

SPOKE_1:
interface Loopback0
ip address 10.2.2.2 255.255.255.0
!
interface FastEthernet3/0
ip address 3.3.3.2 255.255.255.0
!
interface FastEthernet4/0
ip address 4.4.4.2 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 3.3.3.1
ip route 0.0.0.0 0.0.0.0 4.4.4.1

SPOKE_2:
interface Loopback0
ip address 10.3.3.3 255.255.255.0
!
interface FastEthernet0/0
ip address 5.5.5.2 255.255.255.0
duplex full
!
ip route 0.0.0.0 0.0.0.0 5.5.5.1

LAN_CORE:
interface Loopback0
ip address 10.1.1.1 255.255.255.0
!
interface FastEthernet0/0
ip address 10.10.10.3 255.255.255.0
!

Ключевым моментом данной части является настройка равноценных маршрутов (выделено желтым) до всех остальных маршрутизаторов, если на конфигурируемом маршрутизаторе терминируется 2 или более провайдеров. В данном случае мы используем маршруты по умолчанию – но это могут быть и конкретные маршруты до конечных узлов.  Без этого не будет работать функционал tunnel routevia.

 

2.) Настраиваем mGRE транспорт:

HUB 1:
interface Tunnel1
ip address 192.168.1.1 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map multicast dynamic
ip nhrp network-id 1
ip tcp adjust-mss 1360
tunnel source FastEthernet1/0
tunnel mode gre multipoint
tunnel key 1
tunnel route-via FastEthernet1/0 mandatory
tunnel path-mtu-discovery
!
interface Tunnel2
ip address 192.168.2.1 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map multicast dynamic
ip nhrp network-id 2
ip tcp adjust-mss 1360
tunnel source FastEthernet2/0
tunnel mode gre multipoint
tunnel key 2
tunnel route-via FastEthernet2/0 mandatory
tunnel path-mtu-discovery

HUB 2:
interface Tunnel3
ip address 192.168.3.1 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map multicast dynamic
ip nhrp network-id 3
ip tcp adjust-mss 1360
tunnel source FastEthernet2/0
tunnel mode gre multipoint
tunnel key 3
tunnel route-via FastEthernet2/0 mandatory
tunnel path-mtu-discovery

SPOKE_1:
interface Tunnel1
ip address 192.168.1.101 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map 192.168.1.1 1.1.1.2
ip nhrp map multicast 1.1.1.2
ip nhrp network-id 1
ip nhrp nhs 192.168.1.1
ip tcp adjust-mss 1360
tunnel source FastEthernet3/0
tunnel mode gre multipoint
tunnel key 1
tunnel route-via FastEthernet3/0 mandatory
tunnel path-mtu-discovery
!
interface Tunnel2
ip address 192.168.2.101 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map 192.168.2.1 2.2.2.2
ip nhrp map multicast 2.2.2.2
ip nhrp network-id 2
ip nhrp nhs 192.168.2.1
ip tcp adjust-mss 1360
tunnel source FastEthernet4/0
tunnel mode gre multipoint
tunnel key 2
tunnel route-via FastEthernet4/0 mandatory
tunnel path-mtu-discovery
!
interface Tunnel3
ip address 192.168.3.101 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map 192.168.3.1 2.2.2.3
ip nhrp map multicast 2.2.2.3
ip nhrp network-id 3
ip nhrp nhs 192.168.3.1
ip tcp adjust-mss 1360
tunnel source FastEthernet4/0
tunnel mode gre multipoint
tunnel key 3
tunnel route-via FastEthernet4/0 mandatory
tunnel path-mtu-discovery

SPOKE_2:
interface Tunnel1
ip address 192.168.1.102 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map 192.168.1.1 1.1.1.2
ip nhrp map multicast 1.1.1.2
ip nhrp network-id 1
ip nhrp nhs 192.168.1.1
ip tcp adjust-mss 1360
tunnel source FastEthernet0/0
tunnel mode gre multipoint
tunnel key 1
tunnel route-via FastEthernet0/0 mandatory
tunnel path-mtu-discovery
!
interface Tunnel2
ip address 192.168.2.102 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map 192.168.2.1 2.2.2.2
ip nhrp map multicast 2.2.2.2
ip nhrp network-id 2
ip nhrp nhs 192.168.2.1
ip tcp adjust-mss 1360
tunnel source FastEthernet0/0
tunnel mode gre multipoint
tunnel key 2
tunnel route-via FastEthernet0/0 mandatory
tunnel path-mtu-discovery
!
interface Tunnel3
ip address 192.168.3.102 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map 192.168.3.1 2.2.2.3
ip nhrp map multicast 2.2.2.3
ip nhrp network-id 3
ip nhrp nhs 192.168.3.1
ip tcp adjust-mss 1360
tunnel source FastEthernet0/0
tunnel mode gre multipoint
tunnel key 3
tunnel route-via FastEthernet0/0 mandatory
tunnel path-mtu-discovery

Наиболее важные моменты выделены желтым. Это:
1.) ip nhrp networkid — идентификатор nhrp процесса/базы – для каждого облака должен быть свой уникальный идентификатор.
2.) tunnel key идентификатор туннельного интерфейса на маршрутизаторе, для выяснения соответствия туннельного интерфейса и приходящего GRE пакета.
3.) tunnel routevia FastEthernetX/X mandatory – явное указание маршрутизировать туннельный трафик через указанный интерфейс. Параметр mandatory указывает, что в случае падения интерфейса или отсутствия маршрута — трафик не пойдет никуда.

 

3.) Настраиваем динамическую маршрутизацию:

HUB маршрутизаторы:
interface TunnelX // для всех туннелей
bandwidth 1000
no ip next-hop-self eigrp 1
no ip split-horizon eigrp 1

!
router eigrp 1
network 10.0.0.0
network 192.168.0.0 0.0.255.255

SPOKE маршрутизаторы:
interface TunnelX // для всех туннелей
bandwidth 100
no ip next-hop-self eigrp 1
no ip split-horizon eigrp 1

!
router eigrp 1
network 10.0.0.0
network 192.168.0.0 0.0.255.255
eigrp stub connected summary

LAN_CORE:
router eigrp 1
network 10.0.0.0

Важным моментом здесь являются специфические настройки туннельных интерфейсов (выделено желтым), обусловленные non-broadcast multi-access природой сети mGRE.
Также крайне рекомендуется настраивать везде, где возможно, опцию stub zone на SPOKE маршрутизаторах. Это может ускорить процесс сходимости сети, а так же исключит возможность транзитного трафика через филиалы.

Стоит отметить, что в данном случае я растянул процесс маршрутизации EIGRP 1 до маршрутизатора LAN_CORE. Для реальной сети это не совсем правильная практика, и используется она исключительно в целях упрощения лабораторного стенда.

 

4.) Проверяем, что у нас получилось:

HUB_1#sh ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
5 192.168.2.102 Tu2 10 03:43:00 873 5000 0 5
4 192.168.1.102 Tu1 12 03:43:00 819 4914 0 4
3 192.168.1.101 Tu1 12 03:43:01 427 2562 0 4
2 192.168.2.101 Tu2 10 03:43:01 326 1956 0 5

1 10.10.10.3 Fa0/0 10 03:43:07 128 768 0 9
0 10.10.10.2 Fa0/0 12 03:43:07 215 1290 0 14

HUB_1#show ip nhrp
192.168.1.101/32 via 192.168.1.101
Tunnel1 created 03:45:17, expire 00:04:48
Type: dynamic, Flags: unique registered
NBMA address: 3.3.3.2
192.168.1.102/32 via 192.168.1.102
Tunnel1 created 03:45:17, expire 00:05:08
Type: dynamic, Flags: unique registered
NBMA address: 5.5.5.2
192.168.2.101/32 via 192.168.2.101
Tunnel2 created 03:45:17, expire 00:04:50
Type: dynamic, Flags: unique registered
NBMA address: 4.4.4.2
192.168.2.102/32 via 192.168.2.102
Tunnel2 created 03:45:17, expire 00:05:10
Type: dynamic, Flags: unique registered
NBMA address: 5.5.5.2

HUB_1#sh ip route
S* 0.0.0.0/0 [1/0] via 2.2.2.1
[1/0] via 1.1.1.1

1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 1.1.1.0/24 is directly connected, FastEthernet1/0
L 1.1.1.2/32 is directly connected, FastEthernet1/0
2.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 2.2.2.0/24 is directly connected, FastEthernet2/0
L 2.2.2.2/32 is directly connected, FastEthernet2/0
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
D 10.1.1.0/24 [90/156160] via 10.10.10.3, 03:43:18, FastEthernet0/0
D 10.2.2.0/24 [90/3968000] via 192.168.2.101, 03:43:09, Tunnel2
[90/3968000] via 192.168.1.101, 03:43:09, Tunnel1
D 10.3.3.0/24 [90/3968000] via 192.168.2.102, 03:43:09, Tunnel2
[90/3968000] via 192.168.1.102, 03:43:09, Tunnel1

C 10.10.10.0/24 is directly connected, FastEthernet0/0
L 10.10.10.1/32 is directly connected, FastEthernet0/0
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.1.0/24 is directly connected, Tunnel1
L 192.168.1.1/32 is directly connected, Tunnel1
192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.2.0/24 is directly connected, Tunnel2
L 192.168.2.1/32 is directly connected, Tunnel2
D 192.168.3.0/24 [90/3842560] via 10.10.10.2, 03:43:10, FastEthernet0/0

HUB_2#sh ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
3 192.168.3.101 Tu3 11 03:55:52 1612 5000 0 6
2 192.168.3.102 Tu3 12 03:55:52 170 1020 0 6

1 10.10.10.1 Fa0/0 11 03:56:04 227 1362 0 16
0 10.10.10.3 Fa0/0 11 03:56:06 519 3114 0 9

HUB_2#sh ip nhrp
192.168.3.101/32 via 192.168.3.101
Tunnel3 created 03:56:05, expire 00:05:08
Type: dynamic, Flags: unique registered
NBMA address: 4.4.4.2
192.168.3.102/32 via 192.168.3.102
Tunnel3 created 03:56:06, expire 00:05:27
Type: dynamic, Flags: unique registered
NBMA address: 5.5.5.2

HUB_2#sh ip route
S* 0.0.0.0/0 [1/0] via 2.2.2.1
2.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 2.2.2.0/24 is directly connected, FastEthernet2/0
L 2.2.2.3/32 is directly connected, FastEthernet2/0
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
D 10.1.1.0/24 [90/156160] via 10.10.10.3, 03:56:22, FastEthernet0/0
D 10.2.2.0/24 [90/3968000] via 192.168.3.101, 03:56:08, Tunnel3
D 10.3.3.0/24 [90/3968000] via 192.168.3.102, 03:56:08, Tunnel3

C 10.10.10.0/24 is directly connected, FastEthernet0/0
L 10.10.10.2/32 is directly connected, FastEthernet0/0
D 192.168.1.0/24 [90/3842560] via 10.10.10.1, 03:56:08, FastEthernet0/0
D 192.168.2.0/24 [90/3842560] via 10.10.10.1, 03:56:08, FastEthernet0/0
192.168.3.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.3.0/24 is directly connected, Tunnel3
L 192.168.3.1/32 is directly connected, Tunnel3

SPOKE_1#sh ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
2 192.168.1.1 Tu1 12 04:01:24 788 5000 0 19
1 192.168.2.1 Tu2 12 04:01:24 836 5000 0 20
0 192.168.3.1 Tu3 14 04:01:25 612 5000 0 15

SPOKE_1#sh ip nhrp
192.168.1.1/32 via 192.168.1.1
Tunnel1 created 04:02:09, never expire
Type: static, Flags: used
NBMA address: 1.1.1.2
192.168.2.1/32 via 192.168.2.1
Tunnel2 created 04:02:08, never expire
Type: static, Flags: used
NBMA address: 2.2.2.2
192.168.3.1/32 via 192.168.3.1
Tunnel3 created 04:02:08, never expire
Type: static, Flags: used
NBMA address: 2.2.2.3

SPOKE_1# show ip route eigrp
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
D 10.1.1.0/24 [90/27010560] via 192.168.3.1, 04:03:18, Tunnel3
[90/27010560] via 192.168.2.1, 04:03:18, Tunnel2
[90/27010560] via 192.168.1.1, 04:03:18, Tunnel1
D 10.3.3.0/24 [90/28288000] via 192.168.3.102, 04:03:13, Tunnel3
[90/28288000] via 192.168.2.1, 04:03:13, Tunnel2
[90/28288000] via 192.168.1.102, 04:03:13, Tunnel1
D 10.10.10.0/24 [90/26882560] via 192.168.3.1, 04:03:18, Tunnel3
[90/26882560] via 192.168.2.1, 04:03:18, Tunnel2
[90/26882560] via 192.168.1.1, 04:03:18, Tunnel1

SPOKE_2#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
2 192.168.1.1 Tu1 13 04:06:30 256 5000 0 17
1 192.168.2.1 Tu2 11 04:06:30 292 5000 0 18
0 192.168.3.1 Tu3 13 04:06:31 384 5000 0 16

SPOKE_2#sh ip nhrp
192.168.1.1/32 via 192.168.1.1
Tunnel1 created 04:06:55, never expire
Type: static, Flags: used
NBMA address: 1.1.1.2
192.168.2.1/32 via 192.168.2.1
Tunnel2 created 04:06:54, never expire
Type: static, Flags: used
NBMA address: 2.2.2.2
192.168.3.1/32 via 192.168.3.1
Tunnel3 created 04:06:54, never expire
Type: static, Flags: used
NBMA address: 2.2.2.3

SPOKE_2#sh ip route eigrp
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
D 10.1.1.0/24 [90/27010560] via 192.168.3.1, 04:06:45, Tunnel3
[90/27010560] via 192.168.2.1, 04:06:45, Tunnel2
[90/27010560] via 192.168.1.1, 04:06:45, Tunnel1
D 10.2.2.0/24 [90/28288000] via 192.168.3.101, 04:06:41, Tunnel3
[90/28288000] via 192.168.2.1, 04:06:41, Tunnel2
[90/28288000] via 192.168.1.101, 04:06:41, Tunnel1
D 10.10.10.0/24 [90/26882560] via 192.168.3.1, 04:06:45, Tunnel3
[90/26882560] via 192.168.2.1, 04:06:45, Tunnel2
[90/26882560] via 192.168.1.1, 04:06:45, Tunnel1

Итак видно, что полная связность mGRE сети имеется, трафик балансируется по всем имеющимся туннелям.
Проверяем работу сети посредством ICMP:

LAN_CORE#ping 10.2.2.2 source loopback 0 repeat 50
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 140/177/264 ms

LAN_CORE#ping 10.3.3.3 source loopback 0 repeat 50
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 10.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 140/170/220 ms

Видно, что проходящий через HUB-ы трафик маршрутизируется успешно.
Теперь протестируем Spoke to Spoke трафик:

SPOKE_1#ping 10.3.3.3 source loopback 0 repeat 50

Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 10.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 10.2.2.2
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 168/233/380 ms

SPOKE_1#sh ip nhrp
192.168.1.1/32 via 192.168.1.1
Tunnel1 created 04:13:06, never expire
Type: static, Flags: used
NBMA address: 1.1.1.2
192.168.1.102/32 via 192.168.1.102
Tunnel1 created 00:00:18, expire 00:06:21
Type: dynamic, Flags: router used
NBMA address: 5.5.5.2

192.168.2.1/32 via 192.168.2.1
Tunnel2 created 04:13:06, never expire
Type: static, Flags: used
NBMA address: 2.2.2.2
192.168.3.1/32 via 192.168.3.1
Tunnel3 created 04:13:05, never expire
Type: static, Flags: used
NBMA address: 2.2.2.3
SPOKE_1#

Также видим, что в результате теста появилась выделенная динамическая NHRP запись. Т.е. трафик между SPOKE маршрутизаторами прошел напрямую, минуя HUB маршрутизаторы.

 

5.) Настраиваем шифрование полученного транспорта посредством IPsec:

Теперь самое интересное – настройка IPSec.
Ключевыми моментами здесь является:

  • Для каждого туннельного интерфейса необходимо настроить отдельный IPsec profile.
  • Для каждого IPsec profile необходимо настроить отдельный crypto isakamp profile с явным указанием используемого физического интерфейса.
  • Для каждого crypto isakamp profile необходимо настроить отдельный crypto keyring с явным указанием используемого физического интерфейса.

Без выше приведенных указаний схема работать не будет! Даже если все туннели бегают через один и тот же физический интерфейс.

HUB_1:
crypto keyring DMVPN-1
local-address FastEthernet1/0
pre-shared-key address 0.0.0.0 0.0.0.0 key secret
crypto keyring DMVPN-2
local-address FastEthernet2/0
pre-shared-key address 0.0.0.0 0.0.0.0 key secret
!
crypto isakmp policy 10
authentication pre-share
group 2

crypto isakmp profile DMVPN-1
keyring DMVPN-1
match identity address 0.0.0.0
local-address FastEthernet1/0
crypto isakmp profile DMVPN-2
keyring DMVPN-2
match identity address 0.0.0.0
local-address FastEthernet2/0
!
crypto ipsec transform-set ESP-DES-MD5-HMAC esp-des esp-md5-hmac
!
crypto ipsec profile DMVPN-1
set transform-set ESP-DES-MD5-HMAC
set isakmp-profile DMVPN-1
!
crypto ipsec profile DMVPN-2
set transform-set ESP-DES-MD5-HMAC
set isakmp-profile DMVPN-2
!
interface Tunnel1
tunnel protection ipsec profile DMVPN-1
!
interface Tunnel2
tunnel protection ipsec profile DMVPN-2

HUB_2:
crypto keyring DMVPN-3
local-address FastEthernet2/0
pre-shared-key address 0.0.0.0 0.0.0.0 key secret
!
crypto isakmp policy 10
authentication pre-share
group 2

crypto isakmp profile DMVPN-3
keyring DMVPN-3
match identity address 0.0.0.0
local-address FastEthernet2/0
!
crypto ipsec transform-set ESP-DES-MD5-HMAC esp-des esp-md5-hmac
!
crypto ipsec profile DMVPN-3
set transform-set ESP-DES-MD5-HMAC
set isakmp-profile DMVPN-3
!
interface Tunnel3
tunnel protection ipsec profile DMVPN-3

SPOKE_1:
crypto keyring DMVPN-1
local-address FastEthernet3/0
pre-shared-key address 0.0.0.0 0.0.0.0 key secret
crypto keyring DMVPN-2
local-address FastEthernet4/0
pre-shared-key address 0.0.0.0 0.0.0.0 key secret
crypto keyring DMVPN-3
local-address FastEthernet4/0
pre-shared-key address 0.0.0.0 0.0.0.0 key secret
!
crypto isakmp policy 10
authentication pre-share
group 2

crypto isakmp profile DMVPN-1
keyring DMVPN-1
match identity address 0.0.0.0
local-address FastEthernet3/0
crypto isakmp profile DMVPN-2
keyring DMVPN-2
match identity address 0.0.0.0
local-address FastEthernet4/0
crypto isakmp profile DMVPN-3
keyring DMVPN-3
match identity address 0.0.0.0
local-address FastEthernet4/0
!
crypto ipsec transform-set ESP-DES-MD5-HMAC esp-des esp-md5-hmac
!
crypto ipsec profile DMVPN-1
set transform-set ESP-DES-MD5-HMAC
set isakmp-profile DMVPN-1
!
crypto ipsec profile DMVPN-2
set transform-set ESP-DES-MD5-HMAC
set isakmp-profile DMVPN-2
!
crypto ipsec profile DMVPN-3
set transform-set ESP-DES-MD5-HMAC
set isakmp-profile DMVPN-3
!
interface Tunnel1
tunnel protection ipsec profile DMVPN-1
!
interface Tunnel2
tunnel protection ipsec profile DMVPN-2
!
interface Tunnel3
tunnel protection ipsec profile DMVPN-3

SPOKE_2:
crypto keyring DMVPN-1
local-address FastEthernet0/0
pre-shared-key address 0.0.0.0 0.0.0.0 key secret
crypto keyring DMVPN-2
local-address FastEthernet0/0
pre-shared-key address 0.0.0.0 0.0.0.0 key secret
crypto keyring DMVPN-3
local-address FastEthernet0/0
pre-shared-key address 0.0.0.0 0.0.0.0 key secret
!
crypto isakmp policy 10
authentication pre-share
group 2

crypto isakmp profile DMVPN-1
keyring DMVPN-1
match identity address 0.0.0.0
local-address FastEthernet0/0
crypto isakmp profile DMVPN-2
keyring DMVPN-2
match identity address 0.0.0.0
local-address FastEthernet0/0
crypto isakmp profile DMVPN-3
keyring DMVPN-3
match identity address 0.0.0.0
local-address FastEthernet0/0
!
crypto ipsec transform-set ESP-DES-MD5-HMAC esp-des esp-md5-hmac
!
crypto ipsec profile DMVPN-1
set transform-set ESP-DES-MD5-HMAC
set isakmp-profile DMVPN-1
!
crypto ipsec profile DMVPN-2
set transform-set ESP-DES-MD5-HMAC
set isakmp-profile DMVPN-2
!
crypto ipsec profile DMVPN-3
set transform-set ESP-DES-MD5-HMAC
set isakmp-profile DMVPN-3
!
interface Tunnel1
tunnel protection ipsec profile DMVPN-1
!
interface Tunnel2
tunnel protection ipsec profile DMVPN-2
!
interface Tunnel3
tunnel protection ipsec profile DMVPN-3

Проверяем работоспособность

 

6.) Проверяем, что получилось в конечном варианте:

SPOKE_1#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
2.2.2.2 4.4.4.2 QM_IDLE 1002 ACTIVE
1.1.1.2 3.3.3.2 QM_IDLE 1001 ACTIVE
2.2.2.3 4.4.4.2 QM_IDLE 1003 ACTIVE

SPOKE_2#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
2.2.2.3 5.5.5.2 QM_IDLE 1001 ACTIVE
1.1.1.2 5.5.5.2 QM_IDLE 1003 ACTIVE
2.2.2.2 5.5.5.2 QM_IDLE 1002 ACTIVE

LAN_CORE#ping 10.2.2.2 source loopback 0 repeat 50
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 148/213/540 ms

LAN_CORE#ping 10.3.3.3 source loopback 0 repeat 50
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 10.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 132/168/232 ms

SPOKE_2#ping 10.2.2.2 source loopback 0 repeat 50
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 10.3.3.3
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 144/293/1176 ms

HUB_1#show crypto ipsec sa

interface: Tunnel1
Crypto map tag: Tunnel1-head-0, local addr 1.1.1.2

protected vrf: (none)
local ident (addr/mask/prot/port): (1.1.1.2/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (3.3.3.2/255.255.255.255/47/0)

current_peer 3.3.3.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 4016, #pkts encrypt: 4016, #pkts digest: 4016
#pkts decaps: 3941, #pkts decrypt: 3941, #pkts verify: 3941

#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.: 1.1.1.2, remote crypto endpt.: 3.3.3.2
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet1/0
current outbound spi: 0x6D6950C(114726156)
PFS (Y/N): N, DH group: none

*******
interface: Tunnel2
Crypto map tag: Tunnel2-head-0, local addr 2.2.2.2

protected vrf: (none)
local ident (addr/mask/prot/port): (2.2.2.2/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (4.4.4.2/255.255.255.255/47/0)

current_peer 4.4.4.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 3823, #pkts encrypt: 3823, #pkts digest: 3823
#pkts decaps: 3830, #pkts decrypt: 3830, #pkts verify: 3830

#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.: 2.2.2.2, remote crypto endpt.: 4.4.4.2
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet2/0
current outbound spi: 0xAC4640D5(2890285269)
PFS (Y/N): N, DH group: none

********
Из приведенных пингов и куска show crypto ipsec sa на первом HUB-е видно, что все работает как надо, пакеты успешно ходят через оба туннельных интерфейса, GRE транспорт в обоих случаях успешно шифруется. Задача наша выполнена.
А теперь интересная деталь:

HUB_1#show ip cef tunnel 1 detail
IPv4 CEF is enabled and running

VRF Default
43 prefixes (43/0 fwd/non-fwd)
Table id 0x0
Database epoch: 0 (43 entries at this epoch)

10.2.2.0/24, epoch 0, per-destination sharing
nexthop 192.168.1.101 Tunnel1
10.3.3.0/24, epoch 0, per-destination sharing
nexthop 192.168.1.102 Tunnel1
192.168.1.0/24, epoch 0, flags attached, connected, cover dependents, need deagg
Covered dependent prefixes: 4
need deagg: 2
notify cover updated: 2
attached to Tunnel1
192.168.1.101/32, epoch 0, flags attached
Adj source: IP midchain out of Tunnel1, addr 192.168.1.101 67DE0C20
Dependent covered prefix type adjfib cover 192.168.1.0/24
attached to Tunnel1
192.168.1.102/32, epoch 0, flags attached
Adj source: IP midchain out of Tunnel1, addr 192.168.1.102 68738D00
Dependent covered prefix type adjfib cover 192.168.1.0/24
attached to Tunnel1

Как видно, в последних версиях IOS туннельные интерфейсы работают в режиме Cisco Express Forwarding (CEF) в том числе в случае использования опции tunnel key.
PS
Теперь отвечу на вопрос: почему я не рассмотрел вариант с 4 перекрещивающимися mGRE облаками для HUB-ов и SPOKE-ов, терминирующих по два провайдера (fullmesh) ? Мое мнение следующее: подобная схема конечно же имеет право на существование в воспаленном мозгу. Также, чисто теоретически, она должна работать на основе рассмотренной конфигурации (tunnel route via). Но в реальной жизни в здравом уме я бы определенно не стал этого делать. Так как ничего хорошего, кроме лишнего фактора непредсказуемости, нагрузки CPU и утилизации канала служебным трафиком — сложная и чрезмерно отказоустойчивая схема не принесет. ИМХО.

***

Рекомендуемое чтиво:
http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/DMVPDG.html
http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/ht_trsel.html
http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_per_tunnel_qos.pdf

С уважением,
Павел Попп aka P@ve1
🙂

 

Метки: , , , ,
Опубликовано: Безопасность cisco

 

17 комментариев “DMVPN (Dynamic Multipoint VPN). Часть 2. Отказоустойчивая конфигурация.”

comment rss - Trackback

  1. P@ve1:

    Критика, предложения по улучшению, дополнения — крайне приветствуются.

  2. Aleks305:

    Привет!Отличная статья!
    Возник вопрос, а пробовал ли ты опускать физические интерфейсы или перегружать роутеры после того как у тебя схема заработала?
    Помню я столкнулся с таким моментом, что ipsec-сессия в таких случаях не сразу обрывалась, и роутеры заново не могли подружиться по ipsec. Помогло в этом случае keeplive.

  3. P@ve1:

    Aleks305, Спасибо.

    Keepalive — действительно нужная штука, и я ее всегда использую в жизни. И в лаборатории она тоже была задействована. Аналогично ускорить процесс восстановления может команда crypto isakmp invalid-spi-recovery.

    Но это скорее особенности тонкой настройки IPSec, и к DMVPN имеет косвенное отношение. Поэтому я старался по максимуму убрать все лишнее из статьи, дабы не замыливать глаз)

  4. Aleks305:

    Кстати, если уж зашла речь о DMVPN, пользуясь случаем, хотел бы сросить: не было у Вас прецедентов по настройке DMVPN совместно с модулями NME-RVPN.
    Почему интересуюсь? Потому что сейчас достаточно сложно легально ввести cisco routers с поддержкой VPN и как возможный вариант для реализации DMVPN смотрю в сторону этих модулей.

  5. P@ve1:

    У самого подобного опыта не было. Но есть хорошая статья на хабре:
    http://habrahabr.ru/post/114328/
    Т.е. по всей видимости это возможно.

  6. NiX:

    Спасибо за статью.

    Возник вопрос по одному из указанных Вами ключевых моментов для настройки шифрования (пункт 5):
    «Для каждого crypto isakamp profile необходимо настроить отдельный crypto keyring с явным указанием используемого физического интерфейса.

    Без выше приведенных указаний схема работать не будет!»
    Но вот из моего опыта следует, что это вовсе не обязательно — можно обойтись одним дефолтовым ключем для всех профилей (если это позволяют условия задачи), например:

    crypto isakmp key 6 HGhiuhIhpoiu address 0.0.0.0 0.0.0.0 no-xauth

    crypto isakmp profile DMVPN-Primary
    keyring default
    match identity address 0.0.0.0
    local-address Dialer0
    crypto isakmp profile DMVPN-Backup
    keyring default
    match identity address 0.0.0.0
    local-address Dialer1

    В чем моя ошибка?

  7. P@ve1:

    Если честно, вариант как у вас с общим ключом и отдельными isakmp profile — я не пробовал 🙂 Пробовал множество иных комбинаций (без isakmp profile, с одним профилем для физического интерфейса и т.д.) — все они были не работоспособны. В ближайшее время протестирую предложенный вариант и внесу дополнения. Спасибо большое за комментарий.

  8. Паша, супер! МуЩина! Дописал и здорово подробно все изложил!

    ЗЫ Теперь мне есть куда подглядывать 🙂

  9. Slade:

    Благодарю за статью. Не до конца понятно зачем на тунельном интерфейсе использовать привязку к конкретному интерфейсу (туннель-роут). А если на Хаб1 3 провайдера и на Хаб2 3 провайдера и на каждом споке по 2 роутера на 2 провайдера каждый это ж сколько туннелей рисовать? Не проще сделать 2 облака и довериться BGP и куда скажет ходить так тому и быть?

    • P@ve1:

      2 Slade:
      Дык понятно что BGP multihoming — это круто! Но далеко не у всех он есть, да и оправдан далеко не всегда. И не у всех по 2 рутера для этого есть. Понятно, что если рутера 2 — то незачем городить 3 облака, как в приведенной лабе.
      Цель статьи — рассмотреть всевозможные варианты отказоустойчивости на все случаи жизни, а не описать некий bestpractice — это задача вендора. Т.к. вопрос заведения нескольких облак на 1 рутер вообще нигде в интернете не освещен. И периодически возникают вопросы без ответа на форумах, люди мучаются городя бесполезный в этом случае PBR, и т.д.

  10. axell:

    возможно для работы с одним профилем ipsec через один физический интерфейс должно помочь следующее:
    interface Tunnel
    tunnel protection ipsec profile DMVPN shared

  11. sadm:

    А каким образом реализуется схема, когда на хабе BGP, а на споках по нескольку провайдеров без BGP?

    • P@ve1:

      > А каким образом реализуется схема, когда на хабе BGP

      Вешаете на лупбэк белый адрес из вашего PI блока — и привязываете к нему тунельный интерфейс. Если надо больше одного — делаете соответсвенно 2 лупбэка.

      > а на споках по нескольку провайдеров без BGP?

      Этот вариант по сути описан в статье. Это частный вариант. На хабе 2 тунельных интерфейса привязанных к разным лупбэкам. И дальше все тоже самое.

  12. Krasser:

    Павел, день добрый!
    В свое время тоже столкнулся с проблемй завода двух ДМВПН облак на один хаб, при условии что на споке только один аплинк в инет. К сожалению в инете инфы по этому вопросу совсем почти нет. Но я проблему решил несколько иначе, без использования crypto isakmp profile. Схема заработала при использовании разных transform-set для разных ipsec profile.
    Спасибо за статью, теперь буду знать и такой вариант!

  13. daguta:

    Здравствуйте.
    Подскажите, я так понимаю при вашей схеме происходит балансировка нагрузки и трафик размазывается по всем mGRE облакам? А если нужно чтобы трафик ходил по конкретному облаку, что тогда делать?
    регулировать через bandwidth на тунели?

  14. Fantom:

    Хотел бы тоже узнать

» Оставить комментарий

Вы должны войти чтобы прокомментировать.