Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Aggregated Ethernet Interfaces in a Chassis Cluster

 

IEEE 802.3ad link aggregation enables you to group Ethernet interfaces to form a single link layer interface, also known as a link aggregation group (LAG) or bundle. Reth LAG interfaces combine characteristics of reth interfaces and LAG interfaces. For more information, see the following topics:

Support for Ethernet link aggregation groups (LAGs) based on IEEE 802.3ad makes it possible to aggregate physical interfaces on a standalone device. LAGs on standalone devices provide increased interface bandwidth and link availability. Aggregation of links in a chassis cluster allows a redundant Ethernet interface to add more than two physical child interfaces thereby creating a redundant Ethernet interface LAG. A redundant Ethernet interface LAG can have up to eight links per redundant Ethernet interface per node (for a total of 16 links per redundant Ethernet interface).

The aggregated links in a redundant Ethernet interface LAG provide the same bandwidth and redundancy benefits of a LAG on a standalone device with the added advantage of chassis cluster redundancy. A redundant Ethernet interface LAG has two types of simultaneous redundancy. The aggregated links within the redundant Ethernet interface on each node are redundant; if one link in the primary aggregate fails, its traffic load is taken up by the remaining links. If enough child links on the primary node fail, the redundant Ethernet interface LAG can be configured so that all traffic on the entire redundant Ethernet interface fails over to the aggregate link on the other node. You can also configure interface monitoring for LACP-enabled redundancy group reth child links for added protection.

Aggregated Ethernet interfaces, known as local LAGs, are also supported on either node of a chassis cluster but cannot be added to redundant Ethernet interfaces. Local LAGs are indicated in the system interfaces list using an ae- prefix. Likewise any child interface of an existing local LAG cannot be added to a redundant Ethernet interface and vice versa. Note that it is necessary for the switch (or switches) used to connect the nodes in the cluster to have a LAG link configured and 802.3ad enabled for each LAG on both nodes so that the aggregate links are recognized as such and correctly pass traffic. The total maximum number of combined individual node LAG interfaces (ae) and redundant Ethernet (reth) interfaces per cluster is 128.

Note

The redundant Ethernet interface LAG child links from each node in the chassis cluster must be connected to a different LAG at the peer devices. If a single peer switch is used to terminate the redundant Ethernet interface LAG, two separate LAGs must be used in the switch.

Links from different PICs or IOCs and using different cable types (for example, copper and fiber-optic) can be added to the same redundant Ethernet interface LAG but the speed of the interfaces must be the same and all interfaces must be in full duplex mode. We recommend, however, that for purposes of reducing traffic processing overhead, interfaces from the same PIC or IOC be used whenever feasible. Regardless, all interfaces configured in a redundant Ethernet interface LAG share the same virtual MAC address.

Note

SRX Series devices interface-monitoring feature allows monitoring of redundant Ethernet/aggregated Ethernet interfaces.

Redundant Ethernet interface configuration also includes a minimum-links setting that allows you to set a minimum number of physical child links on the primary node in a given redundant Ethernet interface that must be working for the interface to be up. The default minimum-links value is 1. Note that the minimum-links setting only monitors child links on the primary node. Redundant Ethernet interfaces do not use physical interfaces on the backup node for either ingress or egress traffic.

Note the following support details:

  • Quality of service (QoS) is supported in a redundant Ethernet interface LAG. Guaranteed bandwidth is, however, duplicated across all links. If a link is lost, there is a corresponding loss of guaranteed bandwidth.

  • Layer 2 transparent mode and Layer 2 security features are supported in redundant Ethernet interface LAGs.

  • Link Aggregation Control Protocol (LACP) is supported in chassis cluster deployments, where aggregated Ethernet interfaces and redundant Ethernet interfaces are supported simultaneously.

  • Chassis cluster management, control, and fabric interfaces cannot be configured as redundant Ethernet interface LAGs or added to a redundant Ethernet interface LAG.

  • Network processor (NP) bundling can coexist with redundant Ethernet interface LAGs on the same cluster. However, assigning an interface simultaneously to a redundant Ethernet interface LAG and a network processor bundle is not supported.

    Note

    IOC2 cards do not have network processors but IOC1 cards do have them.

  • Single flow throughput is limited to the speed of a single physical link regardless of the speed of the aggregate interface.

Note

On SRX300, SRX320, SRX340, SRX345, and SRX550M devices, the speed mode and link mode configuration is available for member interfaces of a reth interface.

Note

For more information about Ethernet interface link aggregation and LACP, see the “Aggregated Ethernet” information in the Interfaces Feature Guide for Security Devices.

This example shows how to configure a redundant Ethernet interface link aggregation group for a chassis cluster. Chassis cluster configuration supports more than one child interface per node in a redundant Ethernet interface. When at least two physical child interface links from each node are included in a redundant Ethernet interface configuration, the interfaces are combined within the redundant Ethernet interface to form a redundant Ethernet interface link aggregation group.

Requirements

Before you begin:

Overview

Note

For aggregation to take place, the switch used to connect the nodes in the cluster must enable IEEE 802.3ad link aggregation for the redundant Ethernet interface physical child links on each node. Because most switches support IEEE 802.3ad and are also LACP capable, we recommend that you enable LACP on SRX Series devices. In cases where LACP is not available on the switch, you must not enable LACP on SRX Series devices.

In this example, you assign six Ethernet interfaces to reth1 to form the Ethernet interface link aggregation group:

  • ge-1/0/1—reth1

  • ge-1/0/2—reth1

  • ge-1/0/3—reth1

  • ge-12/0/1—reth1

  • ge-12/0/2—reth1

  • ge-12/0/3—reth1

Note

A maximum of eight physical interfaces per node in a cluster, for a total of 16 child interfaces, can be assigned to a single redundant Ethernet interface when a redundant Ethernet interface LAG is being configured.

Note

Junos OS supports LACP and LAG on a redundant Ethernet interface, which is called RLAG.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

To configure a redundant Ethernet interface link aggregation group:

  • Assign Ethernet interfaces to reth1.

Results

From configuration mode, confirm your configuration by entering the show interfaces reth1 command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

For brevity, this show command output includes only the configuration that is relevant to this example. Any other configuration on the system has been replaced with ellipses (...).

If you are done configuring the device, enter commit from configuration mode.

Verification

Verifying the Redundant Ethernet Interface LAG Configuration

Purpose

Verify the redundant Ethernet interface LAG configuration.

Action

From operational mode, enter the show interfaces terse | match reth command.

user@host> show interfaces terse | match reth

To control failover of redundant Ethernet (reth) interfaces, it is important to configure the weights of interface monitoring according to the minimum-links setting. This configuration requires that the weights be equally distributed among the monitored links such that when the number of active physical interface links falls below the minimum-links setting, the computed weight for that redundancy group falls to zero or below zero. This triggers a failover of the redundant Ethernet interfaces link aggregation group (LAG) once the number of physical links falls below the minimum-links value.

Consider a reth0 interface LAG with four underlying physical links and the minimum-links value set as 2. In this case, a failover is triggered only when the number of active physical links is less than 2.

Note
  • Interface-monitor and minimum-links values are used to monitor LAG link status and correctly calculate failover weight.

  • The minimum-links value is used to keep the redundant Ethernet link status. However, to trigger a failover, interface-monitor must be set.

  • When the physical link is Up and LACP is Down, a failover of the redundant ethernet interfaces link aggregation group (LAG) is triggered.

Configure the underlying interface attached to the redundant Ethernet LAG.

Specify the minimum number of links for the redundant Ethernet interface as 2.

Set up interface monitoring to monitor the health of the interfaces and trigger redundancy group failover.

The following scenarios provide examples of how to monitor redundant Ethernet LAG failover:

Scenario 1: Monitored Interface Weight Is 255

Specify the monitored interface weight as 255 for each underlying interface.

In this case, although there are three active physical links and the redundant Ethernet LAG could have handled the traffic because of minimum-links configured, one physical link is still down, which triggers a failover based on the computed weight.

Scenario 2: Monitored Interface Weight Is 75

Specify the monitored interface weight as 75 for each underlying interface.

In this case, when three physical links are down, the redundant Ethernet interface will go down due to minimum-links configured. However, the failover will not happen, which in turn will result in traffic outage.

Scenario 3: Monitored Interface Weight Is 100

Specify the monitored interface weight as 100 for each underlying interface.

In this case, when the three physical links are down, the redundant Ethernet interface will go down because of the minimum-links value. However, at the same time a failover would be triggered because of interface monitoring computed weights, ensuring that there is no traffic disruption.

Of all the three scenarios, scenario 3 illustrates the most ideal way to manage redundant Ethernet LAG failover.

Understanding LACP on Chassis Clusters

You can combine multiple physical Ethernet ports to form a logical point-to-point link, known as a link aggregation group (LAG) or bundle, such that a media access control (MAC) client can treat the LAG as if it were a single link.

LAGs can be established across nodes in a chassis cluster to provide increased interface bandwidth and link availability.

The Link Aggregation Control Protocol (LACP) provides additional functionality for LAGs. LACP is supported in standalone deployments, where aggregated Ethernet interfaces are supported, and in chassis cluster deployments, where aggregated Ethernet interfaces and redundant Ethernet interfaces are supported simultaneously.

You configure LACP on a redundant Ethernet interface by setting the LACP mode for the parent link with the lacp statement. The LACP mode can be off (the default), active, or passive.

This topic contains the following sections:

Chassis Cluster Redundant Ethernet Interface Link Aggregation Groups

A redundant Ethernet interface has active and standby links located on two nodes in a chassis cluster. All active links are located on one node, and all standby links are located on the other node. You can configure up to eight active links and eight standby links per node.

When at least two physical child interface links from each node are included in a redundant Ethernet interface configuration, the interfaces are combined within the redundant Ethernet interface to form a redundant Ethernet interface LAG.

Having multiple active redundant Ethernet interface links reduces the possibility of failover. For example, when an active link is out of service, all traffic on this link is distributed to other active redundant Ethernet interface links, instead of triggering a redundant Ethernet active/standby failover.

Aggregated Ethernet interfaces, known as local LAGs, are also supported on either node of a chassis cluster but cannot be added to redundant Ethernet interfaces. Likewise, any child interface of an existing local LAG cannot be added to a redundant Ethernet interface, and vice versa. The total maximum number of combined individual node LAG interfaces (ae) and redundant Ethernet (reth) interfaces per cluster is 128.

However, aggregated Ethernet interfaces and redundant Ethernet interfaces can coexist, because the functionality of a redundant Ethernet interface relies on the Junos OS aggregated Ethernet framework.

For more information, see Understanding Chassis Cluster Redundant Ethernet Interface Link Aggregation Groups.

Minimum Links

Redundant Ethernet interface configuration includes a minimum-links setting that allows you to set a minimum number of physical child links in a redundant Ethernet interface LAG that must be working on the primary node for the interface to be up. The default minimum-links value is 1. When the number of physical links on the primary node in a redundant Ethernet interface falls below the minimum-links value, the interface might be down even if some links are still working. For more information, see Example: Configuring Chassis Cluster Minimum Links.

Sub-LAGs

LACP maintains a point-to-point LAG. Any port connected to the third point is denied. However, a redundant Ethernet interface does connect to two different systems or two remote aggregated Ethernet interfaces by design.

To support LACP on redundant Ethernet interface active and standby links, a redundant Ethernet interface is created automatically to consist of two distinct sub-LAGs, where all active links form an active sub-LAG and all standby links form a standby sub-LAG.

In this model, LACP selection logic is applied and limited to one sub-LAG at a time. In this way, two redundant Ethernet interface sub-LAGs are maintained simultaneously while all the LACP advantages are preserved for each sub-LAG.

It is necessary for the switches used to connect the nodes in the cluster to have a LAG link configured and 802.3ad enabled for each LAG on both nodes so that the aggregate links are recognized as such and correctly pass traffic.

Note

The redundant Ethernet interface LAG child links from each node in the chassis cluster must be connected to a different LAG at the peer devices. If a single peer switch is used to terminate the redundant Ethernet interface LAG, two separate LAGs must be used in the switch.

Supporting Hitless Failover

With LACP, the redundant Ethernet interface supports hitless failover between the active and standby links in normal operation. The term hitless means that the redundant Ethernet interface state remains up during a failover.

The lacpd process manages both the active and standby links of the redundant Ethernet interfaces. A redundant Ethernet interface state remains up when the number of active up links is equal to or more than the number of minimum links configured. Therefore, to support hitless failover, the LACP state on the redundant Ethernet interface standby links must be collected and distributed before failover occurs.

Managing Link Aggregation Control PDUs

The protocol data units (PDUs) contain information about the state of the link. By default, aggregated and redundant Ethernet links do not exchange link aggregation control PDUs.

You can configure PDUs exchange in the following ways:

  • Configure Ethernet links to actively transmit link aggregation control PDUs

  • Configure Ethernet links to passively transmit PDUs, sending out link aggregation control PDUs only when they are received from the remote end of the same link

The local end of a child link is known as the actor and the remote end of the link is known as the partner. That is, the actor sends link aggregation control PDUs to its protocol partner that convey what the actor knows about its own state and that of the partner’s state.

You configure the interval at which the interfaces on the remote side of the link transmit link aggregation control PDUs by configuring the periodic statement on the interfaces on the local side. It is the configuration on the local side that specifies the behavior of the remote side. That is, the remote side transmits link aggregation control PDUs at the specified interval. The interval can be fast (every second) or slow (every 30 seconds).

For more information, see Example: Configuring LACP on Chassis Clusters.

By default, the actor and partner transmit link aggregation control PDUs every second. You can configure different periodic rates on active and passive interfaces. When you configure the active and passive interfaces at different rates, the transmitter honors the receiver’s rate.

Example: Configuring LACP on Chassis Clusters

This example shows how to configure LACP on chassis clusters.

Requirements

Before you begin:

Complete the tasks such as enabling the chassis cluster, configuring interfaces and redundancy groups. See SRX Series Chassis Cluster Configuration Overview and Example: Configuring Chassis Cluster Redundant Ethernet Interfaces for more details.

Overview

You can combine multiple physical Ethernet ports to form a logical point-to-point link, known as a link aggregation group (LAG) or bundle. You configure LACP on a redundant Ethernet interface of SRX series device in chassis cluster.

In this example, you set the LACP mode for the reth1 interface to active and set the link aggregation control PDU transmit interval to slow, which is every 30 seconds.

When you enable LACP, the local and remote sides of the aggregated Ethernet links exchange protocol data units (PDUs), which contain information about the state of the link. You can configure Ethernet links to actively transmit PDUs, or you can configure the links to passively transmit them (sending out LACP PDUs only when they receive them from another link). One side of the link must be configured as active for the link to be up.

Figure 1 shows the topology used in this example.

Figure 1: Topology for LAGs Connecting SRX Series Devices in Chassis Cluster to an EX Series Switch
Topology
for LAGs Connecting SRX Series Devices in Chassis Cluster to an EX
Series Switch

In the Figure 1, the ge-3/0/0 interface on SRX Series device is connected to ge-0/0/0 interface on EX Series switch and the ge-15/0/0 interface is connected to ge-0/0/1 on EX Series switch. For more information on EX Series switch configuration, see Configuring Aggregated Ethernet LACP (CLI Procedure).

Configuration

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see the CLI User Guide.

To configure LACP on chassis clusters:

  1. Bind redundant child physical interfaces to reth1.
  2. Add reth1 to redundancy group 1.
  3. Set the LACP on reth1.
  4. Assign an IP address to reth1.
  5. If you are done configuring the device, commit the configuration.

Verification

Verifying LACP on Redundant Ethernet Interfaces

Purpose

Display LACP status information for redundant Ethernet interfaces.

Action

From operational mode, enter the show lacp interfaces reth1 command.

user@host> show lacp interfaces reth1

The output shows redundant Ethernet interface information, such as the following:

  • The LACP state—Indicates whether the link in the bundle is an actor (local or near-end of the link) or a partner (remote or far-end of the link).

  • The LACP mode—Indicates whether both ends of the aggregated Ethernet interface are enabled (active or passive)—at least one end of the bundle must be active.

  • The periodic link aggregation control PDU transmit rate.

  • The LACP protocol state—Indicates the link is up if it is collecting and distributing packets.

This example shows how to specify a minimum number of physical links assigned to a redundant Ethernet interface on the primary node that must be working for the interface to be up.

Requirements

Before you begin:

Overview

When a redundant Ethernet interface has more than two child links, you can set a minimum number of physical links assigned to the interface on the primary node that must be working for the interface to be up. When the number of physical links on the primary node falls below the minimum-links value, the interface will be down even if some links are still working.

In this example, you specify that three child links on the primary node and bound to reth1 (minimum-links value) be working to prevent the interface from going down. For example, in a redundant Ethernet interface LAG configuration in which six interfaces are assigned to reth1, setting the minimum-links value to 3 means that all reth1 child links on the primary node must be working to prevent the interface’s status from changing to down.

Note

Although it is possible to set a minimum-links value for a redundant Ethernet interface with only two child interfaces (one on each node), we do not recommend it.

Configuration

Step-by-Step Procedure

To specify the minimum number of links:

  1. Specify the minimum number of links for the redundant Ethernet interface.
  2. If you are done configuring the device, commit the configuration.

Verification

Purpose

To verify the configuration is working properly, enter the show interface reth1 command.

Action

From operational mode, enter the show show interfaces reth1 command.

{primary:node0}[edit]
user@host> show interfaces reth1

Support for Ethernet link aggregation groups (LAGs) based on IEEE 802.3ad makes it possible to aggregate physical interfaces on a standalone device. LAGs on standalone devices provide increased interface bandwidth and link availability. Aggregation of links in a chassis cluster allows a redundant Ethernet interface to add more than two physical child interfaces, thereby creating a redundant Ethernet interface LAG.

Requirements

This example uses the following software and hardware components:

Overview

This example shows how to configure a redundant Ethernet interface link aggregation group and configure LACP on chassis clusters on an SRX Series device using the ports from either IOC2 or IOC3 in Express Path mode. Note that configuring child interfaces by mixing links from both IOC2 and IOC3 is not supported.

The following member links are used in this example:

  • xe-1/0/0

  • xe-3/0/0

  • xe-14/0/0

  • xe-16/0/0

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, delete, and then copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in CLI User Guide.

To configure LAG Interfaces:

  1. Specify the number of aggregated Ethernet interfaces to be created.
  2. Bind redundant child physical interfaces to reth0.
  3. Add reth0 to redundancy group 1.
  4. Assign an IP address to reth0.
  5. Set the LACP on reth0.

Results

From configuration mode, confirm your configuration by entering the show interfaces command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Verification

Verifying LACP on Redundant Ethernet Interfaces

Purpose

Display LACP status information for redundant Ethernet interfaces.

Action

From operational mode, enter the show lacp interfaces command to check that LACP has been enabled as active on one end.

user@host> show lacp interfaces

The output indicates that LACP has been set up correctly and is active at one end.

Understanding VRRP on SRX Series Devices

SRX Series devices support the Virtual Router Redundancy Protocol (VRRP) and VRRP for IPv6. This topic covers:

Overview of VRRP on SRX Series Devices

Configuring end hosts on your network with static default routes minimizes configuration effort and complexity and reduces processing overhead on the end hosts. When hosts are configured with static routes, the failure of the default gateway normally results in a catastrophic event, isolating all hosts that are unable to detect available alternate paths to their gateway. Using Virtual Router Redundancy Protocol (VRRP) enables you to dynamically provide alternative gateways for end hosts if the primary gateway fails.

You can configure the Virtual Router Redundancy Protocol (VRRP) or VRRP for IPv6 on Gigabit Ethernet interfaces, 10-Gigabit Ethernet interfaces, and logical interfaces on SRX Series devices. VRRP enables hosts on a LAN to make use of redundant devices on that LAN without requiring more than the static configuration of a single default route on the hosts. Devices configured with VRRP share the IP address corresponding to the default route configured on the hosts. At any time, one of the VRRP configured devices is the master (active) and the others are backups. If the master device fails, then one of the backup devices becomes the new master, providing a virtual default device and enabling traffic on the LAN to be routed without relying on a single device. Using VRRP, a backup SRX Series device can take over a failed default device within a few seconds. This is done with minimum loss of VRRP traffic and without any interaction with the hosts. Virtual Router Redundancy Protocol is not supported on management interfaces.

VRRP for IPv6 provides a much faster switchover to an alternate default device than IPv6 Neighbor Discovery (ND) procedures. VRRP for IPv6 does not support the authentication-type or authentication-key statements.

Devices running VRRP dynamically elect master and backup devices. You can also force assignment of master and backup devices using priorities from 1 through 255, with 255 being the highest priority. In VRRP operation, the default master device sends advertisements to the backup device at a regular intervals. The default interval is 1 second. If the backup device do not receive an advertisement for a set period, then the backup device with the highest priority takes over as master and begins forwarding packets.

The backup devices do not attempt to preempt the master device unless it has higher priority. This eliminates service disruption unless a more preferred path becomes available. It is possible to administratively prohibit all preemption attempts, with the exception of a VRRP device becoming master device of any device associated with addresses it owns.

Note

VRRP does not support session synchronization between members. If the master device fails, the backup device with the highest priority takes over as master and will begin forwarding packets. Any existing sessions will be dropped on the backup device as out-of-state.

Note

Priority 255 cannot be set for routed VLAN interfaces (RVIs).

VRRP is defined in RFC 3768, Virtual Router Redundancy Protocol.

Benefits of VRRP

  • VRRP provides dynamic failover of IP addresses from one device to another in the event of failure.

  • You can implement VRRP to provide a highly available default path to a gateway without needing to configure dynamic routing or router discovery protocols on end hosts.

Sample VRRP Topology

Figure 2 illustrates a basic VRRP topology with SRX Series devices. In this example, Devices A and B are running VRRP and share the virtual IP address 192.0.2.1. The default gateway for each of the clients is 192.0.2.1.

Figure 2: Basic VRRP on SRX Series Switches
Basic VRRP on SRX Series
Switches

The following illustrates basic VRRP behavior using Figure 2 for reference:

  1. When any of the servers wants to send traffic out of the LAN, it sends the traffic to the default gateway address of 192.0.2.1. This is a virtual IP address (VIP) owned by VRRP group 100. Because Device A is the master of the group, the VIP is associated with the “real” address 192.0.2.251 on Device A, and traffic from the servers is actually sent to this address. (Device A is the master because it has been configured with a higher priority value.)
  2. If there is a failure on Device A that prevents it from forwarding traffic to or from the servers—for example, if the interface connected to the LAN fails—Device B becomes the master and assumes ownership of the VIP. The servers continue to send traffic to the VIP, but because the VIP is now associated with the “real” address 192.0.2.252 on Device B (because of change of master), the traffic is sent to Device B instead of Device A.
  3. If the problem that caused the failure on Device A is corrected, Device A becomes the master again and reasserts ownership of the VIP. In this case, the servers resume sending traffic to Device A.

Notice that no configuration changes are required on the servers for them to switch between sending traffic to Device A and Device B. When the VIP moves between 192.0.2.251 and 192.0.2.252, the change is detected by normal TCP-IP behavior and no configuration or intervention is required on the servers.

SRX Series Devices Support for VRRPv3

The advantage of using VRRPv3 is that VRRPv3 supports both IPv4 and IPv6 address families, whereas VRRP supports only IPv4 addresses.

Enable VRRPv3 in your network only if VRRPv3 can be enabled on all the devices configured with VRRP in your network because VRRPv3 (IPv4) does not interoperate with the previous versions of VRRP. For example, if VRRP IPv4 advertisement packets are received by a device on which VRRPv3 is enabled, then the device transitions itself to the backup state to avoid creating multiple masters in the network.

You can enable VRRPv3 by configuring the version-3 statement at the [edit protocols vrrp] hierarchy level (for IPv4 or IPv6 networks). Configure the same protocol version on all VRRP devices on the LAN.

Limitations of VRRPv3 Features

Below are some VRRPv3 features limitations.

VRRPv3 Authentication

When VRRPv3 (for IPv4) is enabled, it does not allow authentication.

  • The authentication-type and authentication-key statements cannot be configured for any VRRP groups.

  • You must use non-VRRP authentication.

VRRPv3 Advertisement Intervals

VRRPv3 (for IPv4 and IPv6) advertisement intervals must be set with the fast-interval statement at the [edit interfaces interface-name unit 0 family inet address ip-address vrrp-group group-name] hierarchy level.

  • Do not use the advertise-interval statement (for IPv4).

  • Do not use the inet6-advertise-interval statement (for IPv6).

See also

VRRP failover-delay Overview

Failover is a backup operational mode in which the functions of a network device are assumed by a secondary device when the primary device becomes unavailable because of a failure or a scheduled down time. Failover is typically an integral part of mission-critical systems that must be constantly available on the network.

Note

VRRP does not support session synchronization between members. If the master device fails, the backup device with the highest priority takes over as master and will begin forwarding packets. Any existing sessions will be dropped on the backup device as out-of-state.

A fast failover requires a short delay. Thus, failover-delay configures the failover delay time, in milliseconds, for VRRP and VRRP for IPv6 operations. Junos OS supports a range of 50 through 100000 milliseconds for delay in failover time.

The VRRP process (vrrpd) running on the Routing Engine communicates a VRRP mastership change to the Packet Forwarding Engine for every VRRP session. Each VRRP group can trigger such communication to update the Packet Forwarding Engine with its own state or the state inherited form an active VRRP group. To avoid overloading the Packet Forwarding Engine with such messages, you can configure a failover-delay to specify the delay between subsequent Routing Engine to Packet Forwarding Engine communications.

The Routing Engine communicates a VRRP mastership change to the Packet Forwarding Engine to facilitate necessary state change on the Packet Forwarding Engine, such as reprogramming of Packet Forwarding Engine hardware filters, VRRP sessions and so on. The following sections elaborate the Routing Engine to Packet Forwarding Engine communication in two scenarios:

When failover-delay Is Not Configured

Without failover-delay configured, the sequence of events for VRRP sessions operated from the Routing Engine is as follows:

  1. When the first VRRP group detected by the Routing Engine changes state, and the new state is master, the Routing Engine generates appropriate VRRP announcement messages. The Packet Forwarding Engine is informed about the state change, so that hardware filters for that group are reprogrammed without delay. The new master then sends gratuitous ARP message to the VRRP groups.
  2. The delay in failover timer starts. By default, failover-delay timer is:

    • 500 miliseconds—when the configured VRRP announcement interval is less than 1 second.

    • 2 seconds—when the configured VRRP announcement interval is 1 second or more, and the total number of VRRP groups on the router is 255.

    • 10 seconds—when the configured VRRP announcement interval is 1 second or more, and the number of VRRP groups on the router is more than 255.

  3. The Routing Engine performs one-by-one state change for subsequent VRRP groups. Every time there is a state change, and the new state for a particular VRRP group is master, the Routing Engine generates appropriate VRRP announcement messages. However, communication toward the Packet Forwarding Engine is suppressed until the failover-delay timer expires.
  4. After failover-delay timer expires, the Routing Engine sends message to the Packet Forwarding Engine about all VRRP groups that managed to change the state. As a consequence, hardware filters for those groups are reprogrammed, and for those groups whose new state is master, gratuitous ARP messages are sent.

This process repeats until state transition for all VRRP groups is complete.

Thus, without configuring failover-delay, the full state transition (including states on the Routing Engine and the Packet Forwarding Engine) for the first VRRP group is performed immediately, while state transition on the Packet Forwarding Engine for remaining VRRP groups is delayed by at least 0.5-10 seconds, depending on the configured VRRP announcement timers and the number of VRRP groups. During this intermediate state, receiving traffic for VRRP groups for state changes that were not yet completed on the Packet Forwarding Engine might be dropped at the Packet Forwarding Engine level due to deferred reconfiguration of hardware filters.

When failover-delay Is Configured

When failover-delay is configured, the sequence of events for VRRP sessions operated from the Routing Engine is modified as follows:

  1. The Routing Engine detects that some VRRP groups require a state change.
  2. The failover-delay starts for the period configured. The allowed failover-delay timer range is 50 through 100000 miliseconds.
  3. The Routing Engine performs one-by-one state change for the VRRP groups. Every time there is a state change, and the new state for a particular VRRP group is master, the Routing Engine generates appropriate VRRP announcement messages. However, communication toward the Packet Forwarding Engine is suppressed until the failover-delay timer expires.
  4. After failover-delay timer expires, the Routing Enigne sends message to the Packet Forwarding Engine about all VRRP groups that managed to change the state. As a consequence, hardware filters for those groups are reprogrammed, and for those groups whose new state is master, gratuitous ARP messages are sent.

This process repeats until state transition for all VRRP groups is complete.

Thus, when failover-delay is configured even the Packet Forwarding Engine state for the first VRRP group is deferred. However, the network operator has the advantage of configuring a failover-delay value that best suits the need of the network deployment to ensure minimal outage during VRRP state change.

Note

failover-delay influences only VRRP sessions operated by the VRRP process (vrrpd) running on the Routing Engine. For VRRP sessions distributed to the Packet Forwarding Engine, failover-delay configuration has no effect.

Example: Configuring VRRP/VRRPv3 on Chassis Cluster Redundant Ethernet Interfaces

When Virtual Router Redundancy Protocol (VRRP) is configured, the VRRP groups multiple devices into a virtual device. At any time, one of the devices configured with VRRP is the master (active) and the other devices are backups. If the master fails, one of the backup devices becomes the new master device.

This example describes how to configure VRRP on redundant interface:

Requirements

This example uses the following hardware and software components:

  • Junos OS Release 18.1 R1 or later for SRX Series Services Gateways.

  • Two SRX Series devices connected in a chassis cluster.

  • One SRX Series device connected as standalone device.

Overview

You configure VRRP by configuring VRRP groups on redundant interfaces on a chassis cluster devices and on Gigabit Ethernet interface on standalone device. A redundant interface of chassis cluster devices and Gigabit Ethernet interface of standalone device can be a member of one or more VRRP groups. Within a VRRP group, the master redundant interface of chassis cluster devices and the backup Gigabit Ethernet interface of standalone device must be configured.

To configure VRRP group, you must configure group identifier, and virtual IP address to the redundant interfaces and Gigabit Ethernet interfaces that are members of VRRP group. The virtual IP address must be the same for all the interfaces in the VRRP group. Then you configure the priority to the redundant interfaces and Gigabit Ethernet interfaces to become the master interface.

You can force assignment of master and backup redundant interfaces and Gigabit Ethernet interfaces using priorities from 1 through 255, where 255 is the highest priority.

Topology

Figure 3 shows the topology used in this example.

Figure 3: VRRP on Redundant interface
VRRP on Redundant interface

Configuration VRRP

Configuring VRRPv3, VRRP Groups, and Priority on Chassis Cluster Redundant Ethernet Interfaces

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide .

To configure VRRPv3, VRRP Groups, and priority on chassis cluster devices:

  1. Configure a filename to the traceoptions to trace VRRP protocol traffic.
  2. Specify the maximum trace file size.
  3. Enable vrrp traceoptions.
  4. Set vrrp version to 3.
  5. Configure this command to support graceful Routing Engine switchover (GRES) for VRRP and for nonstop active routing when there is VRRP reth failover. Using vrrp, a secondary node can take over a failed primary node within a few seconds and this is done with minimum VRRP traffic and without any interaction with the hosts
  6. Set up the redundant Ethernet (reth) interfaces and assign the redundant interface to a zone.
  7. Configure the family inet address and virtual address for the redundant interface 0 unit 0.
  8. Configure the family inet address and virtual address for the redundant interface 1 unit 0.
  9. Set the priority of the redundant interface 0 unit 0 to 255.
  10. Set the priority of the redundant interface 1 unit 0 to 150.
  11. Configure the redundant interface 0 unit 0 to accept all packets sent to the virtual IP address.
  12. Configure the redundant interface 1 unit 0 to accept all packets sent to the virtual IP address.

Results

From configuration mode, confirm your configuration by entering the show interfaces reth0 and show interfaces reth1 commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Configuring VRRP Groups on Standalone Device

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide .

To configure VRRP groups on standalone device:

  1. Set vrrp version to 3.
  2. Configure the family inet address and virtual address for the Gigabit Ethernet interface unit 0.
  3. Set the priority of the Gigabit Ethernet interface unit 0 to 50.
  4. Configure the Gigabit Ethernet interface unit 0 to accept all packets sent to the virtual IP address.

Results

From configuration mode, confirm your configuration by entering the show interfaces xe-5/0/5 and show interfaces xe-5/0/6 commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying the VRRP on Chassis Cluster Devices

Purpose

Verify that VRRP on chassis cluster devices has been configured properly.

Action

From operational mode, enter the show vrrp brief command to display the status of VRRP on chassis cluster devices.

user@host> show vrrp brief

Meaning

The sample output shows that the four VRRP groups are active and that the redundant interfaces has assumed the correct master roles. The lcl address is the physical address of the interface and the vip address is the virtual address shared by redundant interfaces. The Timer value (A 0.149, A 0.155, A 0.445, and A 0.414) indicates the remaining time (in seconds) in which the redundant interfaces expects to receive a VRRP advertisement from the Gigabit Ethernet interfaces. If an advertisement for group 0, 1, 2, and 3 does not arrive before the timer expires, Chassis cluster devices asserts itself as the master.

Verifying the VVRP on standalone device

Purpose

Verify that VVRP has been configured properly on a standalone device.

Action

From operational mode, enter the show vrrp brief command to display the status of VRRP on standalone device.

user@host> show vrrp brief

Meaning

The sample output shows that the four VRRP groups are active and that the Gigabit Ethernet interfaces has assumed the correct backup roles. The lcl address is the physical address of the interface and the vip address is the virtual address shared by Gigabit Ethernet interfaces. The Timer value (D 3.093, D 3.502, D 3.499, and D 3.282) indicates the remaining time (in seconds) in which the Gigabit Ethernet interfaces expects to receive a VRRP advertisement from the redundant interfaces. If an advertisement for group 0, 1, 2, and 3 does not arrive before the timer expires, then the standalone device continues to be a backup device.

Example: Configuring VRRP for IPv6

This example shows how to configure VRRP properties for IPv6 in one master (Router A) and one backup  (Router B).

Requirements

This example uses the following hardware and software components:

  • Two routers

  • Junos OS Release 11.3 or later

  • Junos OS Release 18.1 R1 or later for SRX Series Services Gateways.

  • Static routing or a dynamic routing protocol enabled on both routers.

Overview

This example uses a VRRP group, which has its own virtual IPv6 address. Devices on the LAN use this virtual IPv6 address as their default gateway. If the master router fails, the backup router takes over for it.

Configuring VRRP

Configuring Router A

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure this example:

  1. Configure the interfaces.
  2. Configure the IPv6 VRRP group identifier.
  3. Configure the virtual IP address of a virtual router that is a member of the VRRP group.
  4. Configure the virtual link-local address.
  5. Configure the priority for this routing platform to become the master virtual router.
  6. By default, a higher-priority backup router preempts a lower-priority master router. To explicitly enable the master router to be preempted, include the preempt statement.
  7. For VRRP for iPv6, you must configure the interface on which VRRP is configured to send IPv6 router advertisements for the VRRP group. When an interface receives an IPv6 router solicitation message, it sends an IPv6 router advertisement to all VRRP groups configured on it.
  8. Configure router advertisements to be sent only for VRRP IPv6 groups configured on the interface if the groups are in the master state.

Results

From configuration mode, confirm your configuration by entering the show interfaces and show protocols router-advertisement commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.

Configuring Router B

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure this example:

  1. Configure the interfaces.
  2. Configure the IPv6 VRRP group identifier.
  3. Configure the virtual IP address of a virtual router that is a member of the VRRP group.
  4. Configure the virtual link-local address.
  5. Configure the priority for this routing platform to become the master virtual router.
  6. By default, a higher-priority backup router preempts a lower-priority master router. To explicitly enable the master router to be preempted, include the preempt statement.
  7. Configure the interface on which VRRP is configured to send IPv6 router advertisements for the VRRP group. When an interface receives an IPv6 router solicitation message, it sends an IPv6 router advertisement to all VRRP groups configured on it.
  8. Configure router advertisements to be sent only for VRRP IPv6 groups configured on the interface if the groups are in the master state.

Results

From configuration mode, confirm your configuration by entering the show interfaces and show protocols router-advertisement commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.

Verification

Verifying that VRRP Is Working on Router A

Purpose

Verify that VRRP is active on Router A and that its role in the VRRP group is correct.

Action

Use the following command to verify that VRRP is active on Router A and that the router is master for group 3.

user@hostA> show vrrp

Meaning

The show vrrp command displays fundamental information about the VRRP configuration. This output shows that the VRRP group is active and that this router has assumed the master role. The lcl address is the physical address of the interface and the vip address is the virtual address shared by both routers. The Timer value (A .0327) indicates the remaining time (in seconds) in which this router expects to receive a VRRP advertisement from the other router.

Verifying that VRRP Is Working on Router B

Purpose

Verify that VRRP is active on Router B and that its role in the VRRP group is correct.

Action

Use the following command to verify that VRRP is active on Router B and that the router is backup for group 3.

user@hostB> show vrrp

Meaning

The show vrrp command displays fundamental information about the VRRP configuration. This output shows that the VRRP group is active and that this router has assumed the backup role. The lcl address is the physical address of the interface and the vip address is the virtual address shared by both routers. The Timer value (A .0327) indicates the remaining time (in seconds) in which this router expects to receive a VRRP advertisement from the other router.