Schlagwort-Archive: vrrpv2

VRRPv2 interface and route tracking

This post is a followup to my previous post about VRRPv2 and explain simple interface and route tracking conifguration for VRRP.

Why do we need tracking?

In most cases you want check your uplink states to your core routers. Because the VRRP Master should be able to route your traffic into your core and should not be a black hole if your core router fails.

The VRRP configuration gives you two options to achieve this. With interface tracking, you can specify one or more interfaces to track on. This allows you to track for the physical link properties. The other option is route tracking, which allow you to track for a specific route which must be present in your routing-table.  Both options give you the ability to track your uplink states in a more or less simple way.

Interface Tracking

You can add a tracking for one or multiple interfaces. The tracked interface need a priority-cost, which will be substracted from the configured priority if the interface goes down.

vrrpv2_interface_tracking

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
                        track {
                            interface fe-0/2/3.0 {
                                priority-cost 20;
                            }
                        }
                    }
                }
            }
        }
    }
}

Verify operation:

admin@ROUTER:R2> show vrrp detail
Physical interface: fe-0/2/1, Unit: 0, Address: 10.0.1.3/24
  Index: 102, SNMP ifIndex: 657, VRRP-Traps: disabled
  Interface state: up, Group: 1, State: backup, VRRP Mode: Active
  Priority: 90, Advertisement interval: 1, Authentication type: md5
  Delay threshold: 100, Computed send rate: 0
  Preempt: yes, Accept-data mode: no, VIP count: 1, VIP: 10.0.1.1
  Dead timer: 3.101s, Master priority: 100, Master router: 10.0.1.2
  Virtual router uptime: 00:23:50
  Tracking: enabled
    Current priority: 90, Configured priority: 90
    Priority hold time: disabled
    Interface tracking: enabled, Interface count: 1
      Interface     Int state   Int speed   Incurred priority cost
      fe-0/2/3.0    up               100m                       0
    Route tracking: disabled

admin@ROUTER:R2> edit
Entering configuration mode

[edit]
admin@ROUTER:R2# set interfaces fe-0/2/3 unit 0 disable

[edit]
admin@ROUTER:R2# commit
run sh vrrp decommit complete

[edit]
admin@ROUTER:R2# run show vrrp detail
Physical interface: fe-0/2/1, Unit: 0, Address: 10.0.1.3/24  
Index: 102, SNMP ifIndex: 657, VRRP-Traps: disabled
  Interface state: up, Group: 1, State: backup, VRRP Mode: Active
  Priority: 70, Advertisement interval: 1, Authentication type: md5
  Delay threshold: 100, Computed send rate: 0
  Preempt: yes, Accept-data mode: no, VIP count: 1, VIP: 10.0.1.1
  Dead timer: 3.325s, Master priority: 100, Master router: 10.0.1.2
  Virtual router uptime: 00:24:40
  Tracking: enabled
    Current priority: 70, Configured priority: 90
    Priority hold time: disabled
    Interface tracking: enabled, Interface count: 1
      Interface     Int state   Int speed   Incurred priority cost
      fe-0/2/3.0    down                0                      20
    Route tracking: disabled

[edit]
admin@ROUTER:R2#

Route Tracking

You can add a tracking for one or multiple routes. You must specify the exact prefix and the routing-instance, which is for inet.0 the name “default”.

vrrpv2_route_tracking

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
                        track {
                            route 20.0.0.0/8 routing-instance default priority-cost 20;
                        }
                    }
                }
            }
        }
    }
}

This example output show you the active route tracking for 20.0.0.0/8. Because the route is not present in inet.0 the priority-cost of 20 will be substracted from the configured priority.

admin@ROUTER:R2# run show vrrp detail
Physical interface: fe-0/2/1, Unit: 0, Address: 10.0.1.3/24
  Index: 102, SNMP ifIndex: 657, VRRP-Traps: disabled
  Interface state: up, Group: 1, State: backup, VRRP Mode: Active
  Priority: 70, Advertisement interval: 1, Authentication type: md5
  Delay threshold: 100, Computed send rate: 0
  Preempt: yes, Accept-data mode: no, VIP count: 1, VIP: 10.0.1.1
  Dead timer: 3.315s, Master priority: 100, Master router: 10.0.1.2
  Virtual router uptime: 00:35:49
  Tracking: enabled
    Current priority: 70, Configured priority: 90
    Priority hold time: disabled
    Interface tracking: disabled
    Route tracking: enabled, Route count: 1
      Route               VRF name     Route state      Priority cost
      20.0.0.0/8          default      down                        20
 
[edit]
admin@ROUTER:R2#

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…

Differences between VRRPv2 and VRRPv3

During IPv6 testing I discovered several differences between VRRPv2 (RFC 3768 – http://tools.ietf.org/html/rfc3768) and VRRPv3 (RFC 5798 – http://tools.ietf.org/html/rfc5798) which you should be familiar if you wanna use VRRPv3 for IPv4 and IPv6:

  • VRRPv3is a unified protocol for IPv4 and IPv6
  • Its a real version cut
    • every router in your LAN must speak the same version
    • only hard migration is possible
    • With JunOS 12.2 you can switch via „set protocols vrrp version 3“
  • Authentication dropped in VRRPv3, should be done by sub-protocols
    • the only security you get is by TTL 255 check
  • Virtual MAC Address for IPv4 00-00-5e-00-01-{VID}
  • Virtual MAC Address for IPv6 00-00-5e-00-02-{VID}
  • Sub-Second Advertisments
    •  intervals specified in centiseconds
    • 100 centisecond = 1 second
  • IPv6 need 2 addresses: virtual-link-local addresses + global address
    • since JunOS 12.2 auto-generated link-local/virtual-link-local possible
  • You must have Router-Advertisements enabled
    • thats the new cool way for default-gateway propagation to hosts
IPv4/VRRPv2 vs. IPv6/VRRPv3
IPv4/VRRPv2 vs. IPv6/VRRPv3

You need JunOS 12.2 for the full VRRPv3 implementation of RFC 5798. Prior JunOS versions only implement draft (http://tools.ietf.org/html/draft-ietf-vrrp-unified-spec-02), which differs in checksum calculation and serveral minor features.