This help contains the following topics:

·     Introduction

¡     VRRP group

¡     Collaboration with HA group

¡     Virtual IP address

¡     Device priority in a VRRP group

¡     Preemption

¡     Preemption delay

¡     VRRP advertisement interval

¡     Authentication method

¡     VRRP control VLAN

·     Restrictions and guidelines

Introduction

Virtual Router Redundancy Protocol (VRRP) adds a group of network gateways to a VRRP group called a virtual router. The VRRP group has one master and multiple backups, and provides a virtual IP address. The hosts on the subnet use the virtual IP address as their default network gateway to communicate with external networks.

VRRP avoids single points of failure and simplifies the configuration on hosts. When the master in the VRRP group on a multicast or broadcast LAN (for example, an Ethernet network) fails, another device in the VRRP group takes over. The switchover is complete without causing dynamic route recalculation, route re-discovery, gateway reconfiguration on the hosts, or traffic interruption.

VRRP group

VRRP adds a group of network gateways to a VRRP group called a virtual router. The VRRP group has one master and multiple backups.

Collaboration with HA group

About collaboration with HA group

You can use the HA group and VRRP in combination to control master/backup switchover for device role consistency (master or backup) in multiple VRRP groups. This ensures that both inbound and outbound traffic can be switched to the new master for symmetric forwarding upon device failure.

Figure 1 illustrates VRRP association with the HA group in active/standby mode.

·     As shown in the left, VRRP cannot ensure symmetric forwarding upon failure on a device, which causes traffic interruption.

·     As shown in the right, after the HA control channel is established, the HA group determines the roles of the devices in all VRRP groups. The master election mechanism of VRRP no longer takes effect. If the HA control channel is disconnected, the master election mechanism of VRRP takes effect again.

Figure 1 HA group in collaboration with VRRP

 

VRRP active/standby group

The HA group is associated with VRRP by VRRP active and standby groups.

A VRRP active/standby group can be in master or backup state, which determines the state of devices in the associated VRRP groups. For example, if a VRRP active group is in master state, all devices in the associated VRRP groups are masters.

The initial state of a VRRP active/standby group is as follows:

·     Active/Standby mode—On the primary device, the initial state is master for the VRRP active and standby groups. On the secondary device, the initial state is backup for the VRRP active and standby groups.

·     Dual-active mode—The state of a VRRP active/standby group is not affected by the HA roles. The initial state is master for the VRRP active group and is backup for the VRRP standby group.

VRRP master election in the HA group environment

After the HA group is associated with VRRP, the HA group determines the roles of the devices in the VRRP groups. As shown in Figure 1, Device A is the master in VRRP group 1 and VRRP group 2, and Device B is the backup in VRRP group 1 and VRRP group 2. When Interface A2 on Device A fails, the following events occur:

1.     The HA group receives an interface failure event and sends the status change information of the VRRP active and standby groups to Device B.

2.     Device B sets its role to master in the VRRP standby group and then becomes the master in VRRP group 1 and VRRP group 2.

3.     Device B sends a response to Device A after the master/backup switchover.

4.     Device A sets its role to backup in the VRRP active group and then becomes the backup in VRRP group 1 and VRRP group 2.

5.     When Interface A2 recovers, the HA group performs another master/backup switchover following the same procedure. Traffic is switched back to Device A after the switchover.

ARP and MAC learning in VRRP

When the members of a VRRP group receive an ARP request for the group's virtual IP address, the master replies with the group's virtual MAC address. This allows the upstream and downstream Layer 2 devices and hosts to learn the virtual MAC address.

Virtual IP address

A VRRP group provides a virtual IP address. The hosts on the subnet use the virtual IP address as their default network gateway to communicate with external networks.

The virtual IP address of the virtual router can be either of the following IP addresses:

·     Unused IP address on the subnet where the VRRP group resides.

·     IP address of an interface on a device in the VRRP group.

In the latter case, the router is called the IP address owner.

Device priority in a VRRP group

VRRP determines the role (master or backup) of each router in a VRRP group by priority. A router with higher priority is more likely to become the master.

A VRRP priority can be in the range of 0 to 255, and a greater number represents a higher priority. Priorities 1 to 254 are configurable. Priority 0 is reserved for special uses, and priority 255 is for the IP address owner. The IP address owner in a VRRP group always has a running priority of 255 and acts as the master as long as it operates correctly. A VRRP group can have only one IP address owner.

Preemption

A router in a VRRP group operates in either non-preemptive mode or preemptive mode.

·     Preemptive mode—A backup starts a new master election and takes over as master when it detects that it has a higher priority than the current master. Preemptive mode ensures that the router with the highest priority in a VRRP group always acts as the master.

·     Non-preemptive mode—The master router acts as the master as long as it operates correctly, even if a backup router is later assigned a higher priority. Non-preemptive mode helps avoid frequent switchover between the master and backup routers.

You can configure the VRRP preemption delay timer for the following purposes:

·     Avoid frequent state changes among members in a VRRP group.

·     Provide the backups with enough time to collect information (such as routing information).

In preemptive mode, a backup does not immediately become the master after it receives an advertisement with priority lower than the local priority. Instead, it waits for a period of time before taking over as the master.

Preemption delay

In preemptive mode, upon receiving an advertisement with priority lower than the local priority, a backup waits for a period of time (preemption delay) before taking over as the master. If the preemption delay is 0, the backup immediately takes over as the master.

VRRP advertisement interval

The master in a VRRP group periodically sends VRRP advertisements to declare its presence.

·     As a best practice to maintain system stability, set the VRRP advertisement interval to be greater than 100 centiseconds.

·     In VRRPv2, all routers in an IPv4 VRRP group must have the same VRRP advertisement interval.

·     In VRRPv3, routers in a VRRP group can have different intervals for sending VRRP advertisements. The master in the VRRP group sends VRRP advertisements at specified intervals, and carries the interval in the advertisements. After a backup receives the advertisement, it records the interval in the advertisement. If the backup does not receive a VRRP advertisement before the timer (three times the recorded interval plus Skew_Time) expires, it regards the master as failed and takes over.

·     A high volume of network traffic might cause a backup to fail to receive VRRP advertisements from the master within the specified time. As a result, an unexpected master switchover occurs. To solve this problem, configure a larger interval.

Authentication method

To avoid attacks from unauthorized users, VRRP members add authentication keys in VRRP packets to authenticate one another. VRRP provides the following authentication methods:

·     Simple authentication—The sender fills an authentication key into the VRRP packet, and the receiver compares the received authentication key with its local authentication key. If the two authentication keys match, the received VRRP packet is legitimate. Otherwise, the received packet is illegitimate and gets discarded.

·     MD5 authentication—The sender computes a digest for the VRRP packet by using the authentication key and MD5 algorithm, and saves the result to the packet. The receiver performs the same operation with the authentication key and MD5 algorithm, and compares the result with the content in the authentication header. If the results match, the received VRRP packet is legitimate. Otherwise, the received packet is illegitimate and gets discarded.

On a secure network, you can choose to not authenticate VRRP packets.

VRRP control VLAN

By default, Layer 3 Ethernet subinterfaces on the master with ambiguous VLAN termination configured do not support sending broadcast packets or multicast packets. To allow the master to regularly send VRRP advertisements in multicast to the backups, enable the VLAN termination-enabled subinterfaces to transmit broadcast packets and multicast packets. Then, the master can send VRRP advertisements within all VLANs whose VLAN packets are configured to be terminated by the subinterfaces. If ambiguous VLAN termination is configured on the Layer 3 Ethernet subinterfaces for a large range of VLANs, the VRRP advertisements might overload the subinterfaces. This adversely affects the performance of the routers.

To resolve this problem, you can disable the VLAN termination-enabled subinterfaces from transmitting broadcast packets and multicast packets and configure a VRRP control VLAN. The master sends VRRP advertisements only within the control VLAN.

Specify VRRP control VLANs according to the VLAN termination type.

·     For ambiguous Dot1q termination, specify one control VLAN by the outermost layer of VLAN tag.

·     For ambiguous QinQ termination, specify two control VLANs by the outermost two layers of VLAN tags.

Restrictions and guidelines

·     IPv4 VRRPv3 and IPv6 VRRPv3 do not support VRRP packet authentication.

·     You can configure different authentication modes and authentication keys for VRRP groups on an interface. However, members of the same VRRP group must use the same authentication mode and authentication key.