Connecting the world…

redundant

Redundant DMVPN network

Today I looked at the configuration DMVPN (Dynamic Multipoint VPN). A Dynamic Multipoint Virtual Private Network is an enhancement of the virtual private network (VPN) configuration process of Cisco IOS-based routers. DMVPN prevents the need for pre-configured (static) IPsec peers in crypto-map configurations and ISAKMP peer statements. This feature of Cisco IOS allows greater scalability over previous IPsec configurations. An IPsec tunnel between two Cisco routers may be created on an as needed basis.

I have created a situation with GNS3, where I have two hub routers and one spoke router. This situation creates extra redundancy when connecting to the hub location. There are two ways to configure redundancy in DMVPN:

  1. Dual hub-dual DMVPN cloud
  2. Dual hub-single DMVPN cloud

In the first scenario the hub routers are connecting to there own DMVPN network. This means that the spoke need to configure two tunnel interfaces to connect to two different DMVPN networks. In the second scenario both hub routers connect to the same DMVPN network. I configured the second scenario using GNS3. The figure below shows my practice setup.

redundant_dmvpn

The configuration from the three routers can be found below.

router R0

key chain authen-hsrp
key 1
key-string hsrp@test
key chain authen-eigrp
key 1
key-string eigrp@test
!
crypto isakmp policy 10
encr aes 256
authentication pre-share
group 5
crypto isakmp key pr3sh@r3d-k3y address 0.0.0.0 0.0.0.0
crypto isakmp invalid-spi-recovery
crypto isakmp keepalive 120 30 periodic
!
!
crypto ipsec transform-set stong-ts esp-aes 256 esp-sha-hmac
!
crypto ipsec profile dmvpn
set transform-set strong-ts
set pfs group5
!
interface Tunnel0
ip address 192.168.255.1 255.255.255.0
no ip redirects
ip mtu 1440
ip hello-interval eigp 1024 15
ip hold-time eigrp 1024 45
no ip next-hop-self eigrp 1024
ip authentication mode eigrp 1024 md5
ip authentication key-chain eigrp 1024 authen-eigrp
ip nhrp authentication nhrp@booches
ip nhrp map multicast dynamic
ip nhrp network-id 1
ip nhrp holdtime 600
no ip split-horizon eigrp 1024
tunnel source FastEthernet0/0
tunnel mode gre multipoint
tunnel key 1
tunnel protection ipsec profile dmvpn
!
interface FastEthernet0/0
description outside
ip address 80.80.10.2 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
description inside
ip address 10.10.13.2 255.255.255.0
duplex auto
speed auto
standby 1 ip 10.10.13.1
standby 1 priority 200
standby 1 preempt
standby 1 authentication md5 key-chain authen-hsrp
!
router eigrp 1024
network 10.10.13.2 0.0.0.0
network 192.168.255.1 0.0.0.0
no auto-summary

router R1

key chain authen-hsrp
key 1
key-string hsrp@test
key chain authen-eigrp
key 1
key-string eigrp@test
!
crypto isakmp policy 10
encr aes 256
authentication pre-share
group 5
crypto isakmp key pr3sh@r3d-k3y address 0.0.0.0 0.0.0.0
crypto isakmp invalid-spi-recovery
crypto isakmp keepalive 120 30 periodic
!
crypto ipsec transform-set strong-ts esp-aes 256 esp-sha-hmac
!
crypto ipsec profile dmvpn
set transform-set strong-ts
set pfs group5
!
interface Tunnel0
ip address 192.168.255.2 255.255.255.0
no ip redirects
ip mtu 1440
ip hello-interval eigrp 1024 15
ip hold-time eigrp 1024 45
no ip next-hop-self eigrp 1024
ip authentication mode eigrp 1024 md5
ip authentication key-chain eigrp 1024 authen-eigrp
ip nhrp authentication nhrp@booces
ip nhrp map multicast dynamic
ip nhrp network-id 1
ip nhrp holdtime 600
no ip split-horizon eigrp 1024
tunnel source FastEthernet0/0
tunnel mode gre multipoint
tunnel key 1
tunnel protection ipsec profile dmvpn
!
interface FastEthernet0/0
description outside
ip address 50.50.1.3 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
description inside
ip address 10.10.13.3 255.255.255.0
duplex auto
speed auto
standby 1 ip 10.10.13.1
standby 1 priority 100
standby 1 preempt
standby 1 authentication md5 key-chain authen-hsrp
!
router eigrp 1024
network 10.10.13.3 0.0.0.0
network 192.168.255.2 0.0.0.0
no auto-summary

router R3

key chain authen-eigrp
key 1
key-string eigrp@booches
!
crypto isakmp policy 10
encr aes 256
authentication pre-share
group 5
crypto isakmp key pr3sh@r3d-k3y address 0.0.0.0 0.0.0.0
crypto isakmp invalid-spi-recovery
crypto isakmp keepalive 120 30 periodic
!
crypto ipsec transform-set strong-ts esp-aes 256 esp-sha-hmac
!
crypto ipsec profile dmvpn
set transform-set strong-ts
set pfs group
!
interface Tunnel0
ip address 192.168.255.3 255.255.255.0
no ip redirects
ip mtu 1440
ip hello-interval eigrp 1024 15
ip hold-time eigrp 1024 45
ip authentication mode eigrp 1024 md5
ip authentication key-chain eigrp 1024 authen-eigrp
ip nhrp authentication nhrp@booches
ip nhrp map multicast dynamic
ip nhrp map 192.168.255.1 80.80.10.2
ip nhrp map multicast 80.80.10.2
ip nhrp map 192.168.255.2 50.50.1.3
ip nhrp map multicast 50.50.1.3
ip nhrp network-id 1
ip nhrp holdtime 600
ip nhrp nhs 192.168.255.1
ip nhrp nhs 192.168.255.2
no ip route-cache cef
no ip route-cache
no ip mroute-cache
tunnel source FastEthernet0/0
tunnel mode gre multipoint
tunnel key 1
tunnel protection ipsec profile dmvpn shared
!
interface FastEthernet0/0
description outside
ip address 40.40.10.4 255.255.255.0
speed auto
duplex auto
!
interface FastEthernet0/1
description inside
ip address 192.168.1.1 255.255.255.0
speed auto
duplex auto
!
router eigrp 1024
network 192.168.1.1 0.0.0.0
network 192.168.255.3 0.0.0.0
no auto-summary

I configured EIGRP authentication as an extra feature. This setup was configured with GNS3, so I guess it needs more tweaking to implement it in a real network. It should however provide a solid base for configuring a redundant DMVPN solution.

Cisco RPS 2300

Lately I was looking at the Cisco Redundant Power System 2300, because this unit delivers power supply redundancy and resiliency for different power requirements. The RPS 2300 helps to seamlessly failover in the event of power failures.

Depending on the number of internal power supplies, the RPS 2300 can provide redundant power of up to two of six connected switches and/or routers. The RPS 2300 supports 1150W AC or 750W AC power supplies. With two 1150W AC power supply modules, the Cisco RPS 2300 can fully back up two 48-port switches that are delivering 15.4W of PoE on all ports.

The RPS 2300 has enhanced capabilities when used in conjunction with Cisco Catalyst 3750-E and 3560-E, like:

  • The ability to remotely place the RPS or any of the six individual RPS ports in active or standby mode;
  • Setting priorities for each RPS port;
  • Failure and exception history reporting;

Normally when switching back from the RPS to normal AC power, the switch reboots. When backed up by a Cisco RPS 2300, a Cisco Catalyst 3750-E and 3560-E is capable of reverting back to its own power supply without rebooting. I really like this feature, because in normal operation a network administrator could miss a power failure of the primary AC and the backup operation by the RPS. When switching back uncontrolled, the reboot of the switch could cause serious problems in the network.

The Cisco RPS 2300 supports two power supplies as mentioned before. These power supplies are also compatible with Cisco Catalyst 3750-E and 3560-E switches. The supported power supplies are:

  1. The C3K-PWR-1150WAC power supply;
  2. The C3K-PWR-750WAC power supply;

The Cisco RPS 2300 can operate with one or two power supplies. If two power supplies are installed, the must be of the same type.

When choosing to use the Cisco RPS 2300, you should pay attention to spare RPS cables. The Cisco Catalyst 3750-E and 3560-E switches use different RPS cables (CAB-RPS2300-E) compared to other switches (CAB-RPS2300). More information about the Cisco RPS 2300 can be found in the following PDF file.

Cisco Firewall Design and Deployment

The session about firewall design and deployment didn’t reveal a lot of new things about the Cisco ASA appliance or FWSM module. The only new thing for me was the possibility to configure a redundant interface for a Cisco ASA appliance. The screen shot below shows the cabling scheme for an implementation with and without interface redundancy.

HA redundancy

This interface redundancy makes it possible to connect a ASA to two different physical switches. When the active switch would crash, the second switch would become the active switch.

Important here is to notice that this configuration doesn’t provide load-balancing across two links. The configuration is only for link redundancy.

To configure interface redundancy you can use the configuration snippet shown below.

interface Redundant1
  member-interface GigabitEthernet0/2
  member-interface GigabitEthernet0/1
  no nameif
  no security-level

  no ip address
!
interface Redundant1.4
  vlan 4
  nameif inside
  security-level 100
  ip address 172.16.10.1 255.255.255.0
!
interface Redundant1.10

  vlan 10
  nameif outside
  security-level 0
  ip address 172.16.50.10 255.255.255.0

The configuration of interface redundancy has some caveats as listed below:

  • Firewalls have to be configured in Active/Standby mode. No load-balancing or link aggregation is supported;
  • Interface redundancy is available on Cisco ASA 5510 and above. The ASA 5505 already has a build in switch and FWSM doesn’t have any physical interfaces;
  • Subinterfaces (IEEE 802.1Q) need to be configured on top of the logic redundant interface;

During the session the different modes for the firewalls have been discussed. Normally we only use the Routed Mode, but there are more modes like described below:

  • Routed mode: traditional mode of the firewall. Two or more interfaces that separate two or more layer 3 domains;
  • Transparent mode: the firewall acts as a bridge and functions mostly at layer 2 of the OSI model (this functions is often used for filtering traffic between two routers who, for example, exchange routing information through a dynamic routing protocol);
  • Multi-context: one physical firewall is divided in more virtual firewalls;
  • Mixed mode: using routed and transparent firewalls in a virtual environment (NOTE: mixed mode is only supported in FWSM today);

Firewall virtualization using multiple context has some caveats. We, Ictivity consultants, already noticed these caveats during firewall implementations. Firewall virtualization has the following caveats:

  • No support for VPN services;
  • No support for dynamic routing protocols;
  • No way to configure the sharing of CPU usage between contexts;
  • No support for multicast routing (multicast bridging is supported);

Especially not supporting VPN services (site-to-site VPN, remote access VPN and SSL VPN) is mostly the most used reason for not using multiple context implementation for the firewall.