Connecting the world…

multicast

XenServer and Multicast with IGMP support

Today I tried to add a virtual Terminal Server within a XenServer to a NLB cluster. The current NLB cluster contained only physical servers. When adding the virtual server to the NLB cluster with the NLB manager, the server lost all IP communication. It isn’t possible to connect to or from the server. Together with the system administrator, we searched multiple forums and we found the solution to the problem.

It looks like XenServer doesn’t support multicast by default, because of the bridge design of the network interfaces. We found an interesting article on the internet to enable multicast on the virtual interface.

In the end we took the following steps to enable multicast support on the virtual interface of the XenServer.

  1. 1. Install the XenServer tools on the virtual server;
  2. 2. Execute the ifconfig command, like shown below, to enable multicast on the virtual interface;

# Retrieve the DOMID of the virtual server
xe vm-list name-label=<VMNAME> params=dom-id

# Enable multicast on the virtual interface of the virtual server
ifconfig vif<DOMID>.0 multicast

We restarted the virtual server and the DOMID changed, but multicast with IGMP support was still working and the server was still part of the NLB cluster. The system administrator will do some more testing and he will try to add another virtual server to the NLB cluster.

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.

HSRP and ACL’s

I added a Guest VLAN to a network environment with two multi layer switches running HSRP. To secure the internal network from the Guest VLAN, I added a ACL to the Guest VLAN SVI. The ACL is stated below:

ip access-list extended GUEST-DENY-RFC1918
remark Allow DHCP
permit udp any eq bootpc any
remark Deny RFC 1918
deny   ip 10.1.2.0 0.0.1.255 10.0.0.0 0.255.255.255
deny   ip 10.1.2.0 0.0.1.255 172.16.0.0 0.0.15.255
deny   ip 10.1.2.0 0.0.1.255 192.168.0.0 0.0.255.255
remark Allow HTTP / HTTPS
permit tcp 10.1.2.0 0.0.1.255 any eq http

permit tcp 10.1.2.0 0.0.1.255 any eq https

The ACL allows querying the DHCP server to obtain the necessary IP address. Next the ACL denies access to all RFC 1918 IP addresses, which are used on the internal LAN segment of the customer. The last two statements allow HTTP and HTTPS access to the Internet.

At first, I just applied the ACL to both the multi layer switches and thought I was ready. After configuring some other tasks and finishing my work, I always check the configuration. Looking at the show standby brief output, I noticed that the primary HSRP switch didn’t have any standby switch anymore, as show in the output below:

Interface   Grp  Pri P State   Active          Standby         Virtual IP
Vl1            1    200 P Active    local         10.1.0.3          10.1.0.1
Vl2            2    200 P Active    local         unknown         10.1.2.1

Because the only change was applying the ACL to the SVI, I already know where to search to correct the problem. Adding a deny ip any any log statement at the bottom of the ACL gave me the information I needed to know.

05:48:09.366: %SEC-6-IPACCESSLOGP: list GUEST-DENY-RFC1918 denied udp 10.1.2.2(1985) -> 224.0.0.2(1985), 360 packetsde

The ACL is blocking the multicast HSRP packets. Looking at the log output, you can see that the HSRP multicast IP address is 224.0.0.2 and port UDP/1985 is used. The multi layer switch is using his SVI IP address as source in the HSRP packet.

I changed the ACL on both multi layer switches by adding a statement to allow the HSRP packets. The new ACL is stated below:

ip access-list extended GUEST-DENY-RFC1918
remark Allow DHCP
permit udp any eq bootpc any

remark Allow HSRP PACKETS

permit udp host 10.1.2.[2|3] eq 1985 host 224.0.0.2 eq 1985

remark Deny RFC 1918
deny   ip 10.1.2.0 0.0.1.255 10.0.0.0 0.255.255.255
deny   ip 10.1.2.0 0.0.1.255 172.16.0.0 0.0.15.255
deny   ip 10.1.2.0 0.0.1.255 192.168.0.0 0.0.255.255
remark Allow HTTP / HTTPS
permit tcp 10.1.2.0 0.0.1.255 any eq http

permit tcp 10.1.2.0 0.0.1.255 any eq https

The HSRP packets weren’t blocked anymore after applying the new ACL to the SVI’s. The primary multi layer switch got his secondary switch back.

Applying an ACL to a SVI happens more often, so it is important to remember if you are running some sort of special protocol on the SVI or somewhere else in the configuration when applying an ACL.

Looking at the Internet I found a nice article on Aaron’s Worthless Words blog about multicast addresses, port numbers and associated protocols.

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.