Connecting the world…
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. Install the XenServer tools on the virtual server;
- 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:
- Dual hub-dual DMVPN cloud
- 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.
The configuration from the three routers can be found below.
|
router R0 |
|
|
router R1 |
|
|
router R3 |
|
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 httppermit 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 anyremark 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 httppermit 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.
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-levelno ip address
!
interface Redundant1.4
vlan 4
nameif inside
security-level 100
ip address 172.16.10.1 255.255.255.0
!
interface Redundant1.10vlan 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.
Follow Me
