VRRPv2 first steps and simple configuration

VRRPv2 for IPv4

To provide a LAN redundancy you could use Virtual Router Redundancy Protocol (VRRP). You must specify a Virtual IP Address (VIP) on the LAN, which should be available even if one router fails. A VRRP router could have two roles:  master or backup. A master router send hello packets to multicast mac destination. Everything is fine as long as the backup receive those packets. In case of a failure, for e.g. primary router shut down, the backup router don’t reveive any hello packet for a period of time it takeover the master role. This will trigger multiple actions:

  1. Sends out a gracious ARP to make sure that all switches refresh her CAM tables
  2. Accept traffic to the VIP (if accept-data configured)
  3. Reply to ARP request for the VIP
  4. Start sending VRRP hello packets periodically

The following topology shows you, that R1 and R2 using VRRP to provide LAN redundancy in the subnet 10.0.1.0/24 with VIP 10.0.1.1. Both routers also need an own interface address, which must be chosen from the subnet.

vrrpv2_basic

The configuration of VRRP belong to the ip address of the unit. You must specify a VRRP group which must be the same on both routers. This is an example for R1:

R1@ROUTER:R1> show configuration
interfaces {
   fe-0/2/0 {
       unit 0 {
           family inet {
               address 10.0.1.2/24 {
                   vrrp-group 1 {
                       virtual-address 10.0.1.1;
                   }
               }
           }
        }
    }
}

You can verify the prober operation of VRRP with “show vrrp” command.

R1@ROUTER:R1> show vrrp
Interface     State       Group   VR state VR Mode   Timer    Type   Address
fe-0/2/0.0    up              1   backup   Active      D  3.274 lcl    10.0.1.2
                                                               vip    10.0.1.1
                                                               mas    10.0.1.3

R1@ROUTER:R1> show vrrp detail
Physical interface: fe-0/2/0, Unit: 0, Address: 10.0.1.2/24
 Index: 69, SNMP ifIndex: 656, VRRP-Traps: disabled
 Interface state: up, Group: 1, State: backup, VRRP Mode: Active
 Priority: 100, Advertisement interval: 1, Authentication type: none
 Delay threshold: 100, Computed send rate: 0
 Preempt: yes, Accept-data mode: no, VIP count: 1, VIP: 10.0.1.1
 Dead timer: 3.510s, Master priority: 100, Master router: 10.0.1.3
 Virtual router uptime: 00:08:14
  Tracking: disabled
R1@ROUTER:R1>

As you can see, R1 is currently in backup state and R2 with address 10.0.1.3 is the master which provide the VIP.

The master/backup election is based on priority, which is per default 100  and as second tie-breaker the highest numerical ip address of the physical interface. That’s why R2 is currently the master.

Priority

You can influence the master election by changing the priority. In the following example we will change the priority of R2 to 90 which should result in a master switch to R1.

vrrpv2_priority

We add the priority option  to the configuration:

admin@ROUTER:R2> show configuration
interfaces {
    fe-0/2/1 {
        unit 0 {
            family inet {
                address 10.0.1.3/24 {
                    vrrp-group 1 {
                        virtual-address 10.0.1.1;
                        priority 90;
                    }
                }
            }
        }
    }
}

Now we can see that R1 is getting VRRP mastership:

R1@ROUTER:R1> show vrrp
interface     State       Group   VR state VR Mode   Timer    Type   Address
fe-0/2/0.0    up              1   master   Active      A  0.111 lcl    10.0.1.2 vip    10.0.1.1
R1@ROUTER:R1>

Authentification

We can add some security to the VRRP hello packets if we enable authentification. We can use plain-text or HMAC-MD5-96 authentication type.

admin@ROUTER:R2# show
interfaces {
    fe-0/2/1 {
        unit 0 {
            family inet {
                address 10.0.1.3/24 {
                    vrrp-group 1 {
                        virtual-address 10.0.1.1;
                        priority 90;
                        authentication-type md5;
                        authentication-key "$9$NC-wgoaUiHmg4QF/9pu"; ## SECRET-DATA
                    }
                }
            }
        }
    }
}

In fact authentication doesn’t provide you more security….  It cannot prevent you of other vrrp speakers in your LAN which  send out Gratuitous ARP….

Accept-Data

Only traffic with destination MAC Address of the VIP get routed out of the box.  Normally the VIP must not reply for any incoming IP Traffic.  In some cases, for e.g. you need for troubleshooting a ping to VIP, you want that the VIP accept traffic. In order to activate this feature, you must add to your configuration the „accept-data“ option.

R1@ROUTER:R1> show configuration
interfaces {
   fe-0/2/0 {
       unit 0 {
           family inet {
               address 10.0.1.2/24 {
                   vrrp-group 1 {
                       virtual-address 10.0.1.1;
                       accept-data;
                   }
               }
           }
        }
    }
}

Did you know? 

Multiple VRRP groups are needed if you have multiple routers or firewalls running VRRP in the same subnet. You could have up to 256 groups per LAN. As you can see in the following image, there are 2  firewalls and 2 routers which provide redundancy via VRRP.

vrrpv2_two_groups

To distinguish both VIPs from layer 2 point of view, you need different MAC addresses. The last octet (the VRID) of the MAC is derived from the group number. The VIP in group 1 uses 00:00:5e:00:01:01 and the VIP in group 2 uses 00:00:5e:00:01:02. This is a usual case in production networks, but need some agreements….

 

…There are many more configurations knobs in VRRP to blog about…. maybe in one of my next posts we take a look at the VRRP route and interfac tracking, VRRP Process Delegation to FPC or VRRPv3 configuration including IPv6…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.