In this lab I setup Force10 switches with Virtual Router Redundancy Protocol (VRRP). VRRP is a redundancy protocol used to eliminate a single point of failure between a gateway and its respective hosts within the same subnet. I use three different Force10 switches: E1200 [FTOS 8.4.2.1], S60 [FTOS 8.3.3.4], and S55 [FTOS 8.3.5.0]. Below is a diagram of the network and the commands I used to configure VRRP.
E1200:
– enable
– conf
– int gi 7/1
– sw
– no shut
– int vlan 98
– ip address 11.0.0.100/24
– untagged gigabitethernet 7/1
– no shut
– vrrp-group 111
– virtual-address 11.0.0.100
S55:
– enable
– conf
– int gi 0/1
– sw
– no shut
– int vlan 98
– ip address 11.0.0.101/24
– untagged gigabitethernet 0/1
– no shut
– vrrp-group 111
– virtual-address 11.0.0.100
S60:
– enable
– conf
– interface range gigabitethernet 0/0 – 5
– sw
– no shut
– int vlan 98
– untagged gigabitethernet 0/0-5
– no shut
Notice that the E1200 switch became the master router for the VRRP group. When the virtual IP address and the interface’s primary/secondary IP address are the same, the priority on that VRRP group is automatically set to 255; this results in the router becoming the master of the VRRP group. Now if the E1200 switch were to fail, the S55 switch would become the master and take over. You can test this by shutting down gigabitethernet 7/1 on the E1200 switch and using the “show vrrp” command on the S55 switch. Below is the output I got from the S55 switch after shutting down gigabitethernet 7/1 on the E1200 switch. As you can see, the S55 switch did indeed become the master router for the VRRP group.
Pingback: Humair’s Blogs » Blog Archive » Port Monitoring on Force10 Switches
Thanks for all your efforts with these blog posts.
One thing I think is worth mentioning is that if you are using VLT, make sure you use 3 IP addresses for VRRP. One for the VIP and one for each interface. I did this with the primary and virtual being the same IP address and it had some really odd behaviour. Switched it to 10.x.x.1 for vip, 10.x.x.2 for primary interface and 10.x.x.3 for secondary and all the issues went away. This was on an S6000 pair.