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:

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.

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 SwitchTopology for LAGs Connecting SRX Series Devices in Chassis Cluster to an EX Series Switch

In the Figure 1, SRX550 devices are used to configure the interfaces on node0 and node1. For more information on EX Series switch configuration, see Configuring Aggregated Ethernet LACP (CLI Procedure).

Configuration

Configuring LACP on Chassis Cluster

Step-by-Step Procedure

To configure LACP on chassis clusters:

  1. Specify the number of redundant Ethernet interfaces.

  2. Specify a redundancy group's priority for primacy on each node of the cluster. The higher number takes precedence.

  3. Create security zone and assign interfaces to zone.

  4. Bind redundant child physical interfaces to reth1.

  5. Add reth1 to redundancy group 1.

  6. Set the LACP on reth1.

  7. Assign an IP address to reth1.

  8. Configure LACP on aggregated Ethernet interfaces (ae1).

  9. If you are done configuring the device, commit the configuration.

Results

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

Configuring LACP on EX Series Switch

Step-by-Step Procedure

Configure LACP on EX Series switch.

  1. Set the number of aggregated Ethernet interfaces.

  2. Associate physical interfaces with aggregated Ethernet interfaces.

  3. Configure LACP on aggregated Ethernet interfaces (ae1).

Results

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

Verification

Verifying LACP on Redundant Ethernet Interfaces

Purpose

Display LACP status information for redundant Ethernet interfaces.

Action

From operational mode, enter the show chassis cluster status command.

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

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.

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 primary (active) and the others are backups. If the primary device fails, then one of the backup devices becomes the new primary, 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 primary and backup devices. You can also force assignment of primary and backup devices using priorities from 1 through 255, with 255 being the highest priority. In VRRP operation, the default primary 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 primary and begins forwarding packets.

The backup devices do not attempt to preempt the primary 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 primary device of any device associated with addresses it owns.

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

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 SwitchesBasic 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 primary 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 primary 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 primary 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 primary), 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 primary 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 primaries 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).

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.

VRRP does not support session synchronization between members. If the primary device fails, the backup device with the highest priority takes over as primary 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 primary role 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 primary role 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 primary, 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 primary 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 primary, 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 primary, 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 primary, 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 primary, 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.

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 primary (active) and the other devices are backups. If the primary fails, one of the backup devices becomes the new primary 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 primary 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 primary interface.

You can force assignment of primary 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 interfaceVRRP 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

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

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.

Meaning

The sample output shows that the four VRRP groups are active and that the redundant interfaces has assumed the correct primary 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 primary.

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.

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 primary (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 primary 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

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 primary virtual router.

  6. By default, a higher-priority backup router preempts a lower-priority primary router. To explicitly enable the primary 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 primary 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

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 primary virtual router.

  6. By default, a higher-priority backup router preempts a lower-priority primary router. To explicitly enable the primary 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 primary 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 primary for group 3.

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 primary 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.

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.