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 Link Aggregation Groups in a Chassis Cluster
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. For SRX4600 and SRX5000 line of devices, 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). For SRX300 Series, SRX1500, SRX1600, SRX2300, SRX4100/SRX4200, and SRX4300 devices, a redundant Ethernet interface LAG can have up to maximum four links per redundant Ethernet interface per node (for a total of 8 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.
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.
SRX Series Firewalls 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.
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.
On SRX300, SRX320, SRX340, SRX345, and SRX380 devices, the speed mode and link mode configuration is available for member interfaces of a reth interface.
For more information about Ethernet interface link aggregation and LACP, see the “Aggregated Ethernet” information in the Interfaces User Guide for Security Devices.
See Also
Example: Configuring Link Aggregation Groups in a Chassis Cluster
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:
Configure chassis cluster redundant interfaces. See Example: Configuring Chassis Cluster Redundant Ethernet Interfaces.
Understand chassis cluster redundant Ethernet interface link aggregation groups. See Understanding Link Aggregation Groups in a Chassis Cluster.
Overview
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 Firewalls. In cases where LACP is not available on the switch, you must not enable LACP on SRX Series Firewalls.
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
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.
Junos OS supports LACP and LAG on a redundant Ethernet interface, which is called RLAG.
Configuration
Procedure
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.
{primary:node0}[edit]
set interfaces ge-1/0/1 gigether-options redundant-parent reth1
set interfaces ge-1/0/2 gigether-options redundant-parent reth1
set interfaces ge-1/0/3 gigether-options redundant-parent reth1
set interfaces ge-12/0/1 gigether-options redundant-parent reth1
set interfaces ge-12/0/2 gigether-options redundant-parent reth1
set interfaces ge-12/0/3 gigether-options redundant-parent reth1
Step-by-Step Procedure
To configure a redundant Ethernet interface link aggregation group:
Assign Ethernet interfaces to reth1.
{primary:node0}[edit] user@host# set interfaces ge-1/0/1 gigether-options redundant-parent reth1 user@host# set interfaces ge-1/0/2 gigether-options redundant-parent reth1 user@host# set interfaces ge-1/0/3 gigether-options redundant-parent reth1 user@host# set interfaces ge-12/0/1 gigether-options redundant-parent reth1 user@host# set interfaces ge-12/0/2 gigether-options redundant-parent reth1 user@host# set interfaces ge-12/0/3 gigether-options redundant-parent 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 (...).
user@host# show interfaces reth1
...
ge-1/0/1 {
gigether-options {
redundant-parent reth1;
}
}
ge-1/0/2 {
gigether-options {
redundant-parent reth1;
}
}
ge-1/0/3 {
gigether-options {
redundant-parent reth1;
}
}
ge-12/0/1 {
gigether-options {
redundant-parent reth1;
}
}
ge-12/0/2 {
gigether-options {
redundant-parent reth1;
}
}
ge-12/0/3 {
gigether-options {
redundant-parent reth1;
}
}
...
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.
{primary:node0}
user@host> show interfaces terse | match reth
ge-1/0/1.0 up down aenet --> reth1.0
ge-1/0/2.0 up down aenet --> reth1.0
ge-1/0/3.0 up down aenet --> reth1.0
ge-12/0/1.0 up down aenet --> reth1.0
ge-12/0/2.0 up down aenet --> reth1.0
ge-12/0/3.0 up down aenet --> reth1.0
reth0 up down
reth0.0 up down inet 10.10.37.214/24
reth1 up down
reth1.0 up down inet
Understanding Link Aggregation Group Failover in a Chassis Cluster
You control failover of redundant Ethernet (reth) interfaces in two ways:
- Using the
minimum-linksconfiguration setting. This parameters determines how many physical members of a redundancy group must be up before the group is declared down. By default this parameter is set to one, which means the redundancy group remains active if a single physical interface is up on the primary node.The default value for minimum links is 1.
- Using the
interface-monitorconfiguration statement along with aweightvalue for each member in the LAG. The interface weighting mechanism works by subtracting a failed interface's configured weight from the redundancy group. The group begins with a weight of 255, and when the group falls to, or below 0, the redundancy group is declared down.Note:Its worth noting that the
minimum-linksandinterface-monitorconfiguration statements work independently. Crossing either the threshold of minimum links (on the primary node), or the threshold of 0 on the redundancy group, triggers a switchover.
In most cases its a best practice 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 also falls to, or below, zero.
This triggers a failover of the redundant Ethernet interfaces link aggregation group
(LAG) because both the number of physical links falls below the
minimum-links value and the LAG group's weight falls below 0.
To demonstrate this interaction, consider a reth0 interface LAG with four underlying physical links:
- The LAG is configured with a
minimum-linkssetting of 2. With this setting failover is triggered when the number of active physical links on the primary node is less than 2.Note:When the physical link is Up and LACP is Down, a failover of the redundant Ethernet interfaces link aggregation group (LAG) is triggered.
-
The
Interface-monitorweight values are used to monitor LAG link status and correctly calculate failover weight.
Configure the underlying interface attached to the redundant Ethernet LAG.
{primary:node0}[edit]
user@host# set interfaces ge-0/0/4 gigether-options redundant-parent reth0
user@host# set interfaces ge-0/0/5 gigether-options redundant-parent reth0
user@host# set interfaces ge-0/0/6 gigether-options redundant-parent reth0
user@host# set interfaces ge-0/0/7 gigether-options redundant-parent reth0
Specify the minimum number of links for the redundant Ethernet interface as 2.
{primary:node0}[edit]
user@host# set interfaces reth0 redundant-ether-options minimum-links 2
Configure interface monitoring to monitor the health of the interfaces and trigger redundancy group failover.
These scenarios provide examples of how redundant Ethernet LAG failover operates:
- Scenario 1: Monitored Interface Weight Is 255
- Scenario 2: Monitored Interface Weight Is 75
- Scenario 3: Monitored Interface Weight Is 100
Scenario 1: Monitored Interface Weight Is 255
Specify the monitored interface weight as 255 for each underlying interface.
{primary:node0}[edit]
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/4 weight 255
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/5 weight 255
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/6 weight 255
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/7 weight 255
When 1 of the 4 interfaces fails there are still 3 active physical links in the redundant Ethernet LAG. While this number exceeds the configured minimum links parameter, the loss of one interface with a weight of 255 causes the group's weight to fall to 0, triggering a failover.
Scenario 2: Monitored Interface Weight Is 75
Specify the monitored interface weight as 75 for each underlying interface.
{primary:node0}[edit]
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/4 weight 75
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/5 weight 75
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/6 weight 75
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/7 weight 75
In this case, when three physical links are down, the redundant Ethernet interface
will go down due to falling below the minimum-links value
configured.
Note that in this scenario the LAG group weight remains above 0.
Scenario 3: Monitored Interface Weight Is 100
Specify the monitored interface weight as 100 for each underlying interface.
{primary:node0}[edit]
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/4 weight 100
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/5 weight 100
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/6 weight 100
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/7 weight 100
In this case, when 3 of 4 physical links are down, the redundant Ethernet interface
is declared down both because the minimum-links value is not met,
and due to the interface monitoring weights causing the LAG group's weight to reach
0.
Of all the three scenarios, scenario 3 illustrates the most ideal way to manage redundant Ethernet LAG failover and there will be minimum traffic loss.
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
- Sub-LAGs
- Supporting Hitless Failover
- Managing Link Aggregation Control PDUs
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 Firewall 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.
In the Figure 1, SRX1500 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:
-
Specify the number of redundant Ethernet interfaces.
[edit chassis cluster] user@host# set reth-count 2
-
Specify a redundancy group's priority for primacy on each node of the cluster. The higher number takes precedence.
[edit chassis cluster] user@host# set redundancy-group 1 node 0 priority 200 user@host# set redundancy-group 1 node 1 priority 100
-
Create security zone and assign interfaces to zone.
[edit security zones] user@host# set security-zone trust host-inbound-traffic system-services all user@host# set security-zone trust interfaces reth1.0
-
Bind redundant child physical interfaces to reth1.
[edit interfaces] user@host# set ge-0/0/4 gigether-options redundant-parent reth1 user@host# set ge-0/0/5 gigether-options redundant-parent reth1 user@host# set ge-9/0/4 gigether-options redundant-parent reth1 user@host# set ge-9/0/5 gigether-options redundant-parent reth1
-
Add reth1 to redundancy group 1.
[edit interfaces] user@host# set reth1 redundant-ether-options redundancy-group 1
-
Set the LACP on reth1.
[edit interfaces] user@host# set reth1 redundant-ether-options lacp active user@host# set reth1 redundant-ether-options lacp periodic slow
-
Assign an IP address to reth1.
[edit interfaces] user@host# set reth1 unit 0 family inet address 192.168.2.1/24
-
Configure LACP on aggregated Ethernet interfaces (ae1).
-
Configure LACP on aggregated Ethernet interfaces (ae2).
-
If you are done configuring the device, commit the configuration.
[edit interfaces] user@host# commit
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.
[edit]user@host#show chassis cluster { reth-count 2; redundancy-group 1 { node 0 priority 200; node 1 priority 100; } } [edit]user@host#show security zones security-zone trust { host-inbound-traffic { system-services { all; } } interfaces { reth1.0; } } [edit]user@host#show interfaces reth1 { redundant-ether-options { redundancy-group 1; lacp { active; periodic slow; } } unit 0 { family inet { address 192.168.2.1/24; } } }
Configuring LACP on EX Series Switch
Step-by-Step Procedure
Configure LACP on EX Series switch.
-
Set the number of aggregated Ethernet interfaces.
[edit chassis] user@host# set aggregated-devices ethernet device-count 3
-
Associate physical interfaces with aggregated Ethernet interfaces.
[edit interfaces] user@host# set ge-0/0/1 gigether-options 802.3ad ae1 user@host# set ge-0/0/2 gigether-options 802.3ad ae1 user@host# set ge-0/0/3 gigether-options 802.3ad ae2 user@host# set ge-0/0/4 gigether-options 802.3ad ae2
-
Configure LACP on aggregated Ethernet interfaces (ae1).
[edit interfaces] user@host# set interfaces ae1 unit 0 family ethernet-switching interface-mode access user@host# set interfaces ae1 unit 0 family ethernet-switching vlan members RETH0_VLAN
-
Configure LACP on aggregated Ethernet interfaces (ae2).
[edit interfaces] user@host# set interfaces ae2 unit 0 family ethernet-switching interface-mode access user@host# set interfaces ae2 unit 0 family ethernet-switching vlan members RETH0_VLAN
-
Configure VLAN.
user@host#set vlans RETH0_VLAN vlan-id 10 user@host# set vlans RETH0_VLAN l3-interface vlan.10 user@host# set interfaces vlan unit 10 family inet address 192.168.2.254/24
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.
[edit]user@host#show chassis aggregated-devices { ethernet { device-count 3; } }user@host#show vlans RETH0_VLAN { vlan-id 10; l3-interface vlan.10; }user@host>show vlans RETH0_VLAN Routing instance VLAN name Tag Interfaces default-switch RETH0_VLAN 10 ae1.0* ae2.0*user@host>show ethernet-switching interface ae1 Routing Instance Name : default-switch Logical Interface flags (DL - disable learning, AD - packet action drop, LH - MAC limit hit, DN - interface down, MMAS - Mac-move action shutdown, SCTL - shutdown by Storm-control ) Logical Vlan TAG MAC STP Logical Tagging interface members limit state interface flags ae1.0 131072 untagged RETH0_VLAN 10 131072 Forwarding untaggeduser@host>show ethernet-switching interface ae2 Routing Instance Name : default-switch Logical Interface flags (DL - disable learning, AD - packet action drop, LH - MAC limit hit, DN - interface down, MMAS - Mac-move action shutdown, SCTL - shutdown by Storm-control ) Logical Vlan TAG MAC STP Logical Tagging interface members limit state interface flags ae2.0 131072 untagged RETH0_VLAN 10 131072 Forwarding untaggeduser@host#show interfaces ge-0/0/1 { ether-options { 802.3ad ae1; } } ge-0/0/2 { ether-options { 802.3ad ae1; } } ge-0/0/3 { ether-options { 802.3ad ae2; } } ge-0/0/4 { ether-options { 802.3ad ae2; } } ae1 { aggregated-ether-options { lacp { active; periodic slow; } } unit 0 { family ethernet-switching { interface-mode access; vlan { members RETH0_VLAN; } } } } ae2 { aggregated-ether-options { lacp { active; periodic slow; } } unit 0 { family ethernet-switching { interface-mode access; vlan { members RETH0_VLAN; } } } } vlan { unit 10 { family inet { address 192.168.2.254/24 { } } } }
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.
{primary:node0}[edit]
user@host> show chassis cluster status
Monitor Failure codes:
CS Cold Sync monitoring FL Fabric Connection monitoring
GR GRES monitoring HW Hardware monitoring
IF Interface monitoring IP IP monitoring
LB Loopback monitoring MB Mbuf monitoring
NH Nexthop monitoring NP NPC monitoring
SP SPU monitoring SM Schedule monitoring
CF Config Sync monitoring RE Relinquish monitoring
IS IRQ storm
Cluster ID: 1
Node Priority Status Preempt Manual Monitor-failures
Redundancy group: 0 , Failover count: 1
node0 1 primary no no None
node1 1 secondary no no None
Redundancy group: 1 , Failover count: 1
node0 200 primary no no None
node1 100 secondary no no None{primary:node0}[edit]
user@host> show chassis cluster interfaces
Control link status: Up
Control interfaces:
Index Interface Monitored-Status Internal-SA Security
0 fxp1 Up Disabled Disabled
Fabric link status: Up
Fabric interfaces:
Name Child-interface Status Security
(Physical/Monitored)
fab0 ge-0/0/2 Up / Up Enabled
fab0
fab1 ge-9/0/2 Up / Up Enabled
fab1
Redundant-ethernet Information:
Name Status Redundancy-group
reth0 Down Not configured
reth1 Up 1
Redundant-pseudo-interface Information:
Name Status Redundancy-group
lo0 Up 0 From operational mode, enter the show lacp interfaces
reth1 command.
{primary:node0}[edit]
user@host> show lacp interfaces reth1
Aggregated interface: reth1
LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
ge-0/0/4 Actor No No Yes Yes Yes Yes Slow Active
ge-0/0/4 Partner No No Yes Yes Yes Yes Slow Active
ge-0/0/5 Actor No No Yes Yes Yes Yes Slow Active
ge-0/0/5 Partner No No Yes Yes Yes Yes Slow Active
ge-9/0/4 Actor No No Yes Yes Yes Yes Slow Active
ge-9/0/4 Partner No No Yes Yes Yes Yes Slow Active
ge-9/0/5 Actor No No Yes Yes Yes Yes Slow Active
ge-9/0/5 Partner No No Yes Yes Yes Yes Slow Active
LACP protocol: Receive State Transmit State Mux State
ge-0/0/4 Current Slow periodic Collecting distributing
ge-0/0/5 Current Slow periodic Collecting distributing
ge-9/0/4 Current Slow periodic Collecting distributing
ge-9/0/5 Current Slow periodic Collecting distributingThe 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.
Example: Configuring Chassis Cluster Minimum Links
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:
Configure redundant Ethernet interfaces. See Example: Configuring Chassis Cluster Redundant Ethernet Interfaces.
Understand redundant Ethernet interface link aggregation groups. See Example: Configuring Link Aggregation Groups in a Chassis Cluster.
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.
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
Procedure
Step-by-Step Procedure
To specify the minimum number of links:
Specify the minimum number of links for the redundant Ethernet interface.
{primary:node0}[edit] user@host# set interfaces reth1 redundant-ether-options minimum-links 3If you are done configuring the device, commit the configuration.
{primary:node0}[edit] user@host# commit
Verification
Verifying the Chassis Cluster Minimum Links Configuration
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 reth1Physical interface: reth1, Enabled, Physical link is Down Interface index: 129, SNMP ifIndex: 548 Link-level type: Ethernet, MTU: 1514, Speed: Unspecified, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Disabled, Minimum links needed: 3, Minimum bandwidth needed: 0 Device flags : Present Running Interface flags: Hardware-Down SNMP-Traps Internal: 0x0 Current address: 00:10:db:ff:10:01, Hardware address: 00:10:db:ff:10:01 Last flapped : 2010-09-15 15:54:53 UTC (1w0d 22:07 ago) Input rate : 0 bps (0 pps) Output rate : 0 bps (0 pps) Logical interface reth1.0 (Index 68) (SNMP ifIndex 550) Flags: Hardware-Down Device-Down SNMP-Traps 0x0 Encapsulation: ENET2 Statistics Packets pps Bytes bps Bundle: Input : 0 0 0 0 Output: 0 0 0 0 Security: Zone: untrust Allowed host-inbound traffic : bootp bfd bgp dns dvmrp igmp ldp msdp nhrp ospf pgm pim rip router-discovery rsvp sap vrrp dhcp finger ftp tftp ident-reset http https ike netconf ping reverse-telnet reverse-ssh rlogin rpm rsh snmp snmp-trap ssh telnet traceroute xnm-clear-text xnm-ssl lsping ntp sip Protocol inet, MTU: 1500 Flags: Sendbcast-pkt-to-re
Example: Configuring Chassis Cluster Redundant Ethernet Interface Link Aggregation Groups on an SRX5000 Line Device with IOC2 or IOC3
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:
Junos OS Release 15.1X49-D40 or later for SRX Series Firewalls.
SRX5800 with IOC2 or IOC3 with Express Path enabled on IOC2 and IOC3. For details, see Example: Configuring SRX5K-MPC3-100G10G (IOC3) and SRX5K-MPC3-40G10G (IOC3) on an SRX5000 Line Device to Support Express Path.
Overview
This example shows how to configure a redundant Ethernet interface link aggregation group and configure LACP on chassis clusters on an SRX Series Firewall 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.
A redundant Ethernet interface or aggregated Ethernet interface (aex) must contain child interfaces from the same IOC type for IOC2 and IOC3. For example, if one child link is from 10-Gigabit Ethernet on IOC2, the second child link should also be from IOC2. This limitation is not applicable for IOC3 and IOC4 child interfaces if the child interfaces have the same speed.
The following combination is not supported:
- Node 0-100GbE from IOC2 and 10GbE/40GbE/100GbE from IOC3
- Node 1-100GbE from IOC2 and 10GbE/40GbE/100GbE from IOC3
The following combination is supported (with the same interface speed):
- Node 0-100GbE from IOC3 and 100GbE from IOC4
- Node 1-100GbE from IOC3 and 100GbE from IOC4
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.
set chassis cluster reth-count 5 set interfaces reth0 redundant-ether-options redundancy-group 1 set interfaces reth0 redundant-ether-options lacp active set interfaces reth0 redundant-ether-options lacp periodic fast set interfaces reth0 redundant-ether-options minimum-links 1 set interfaces reth0 unit 0 family inet address 192.0.2.1/24 set interfaces xe-1/0/0 gigether-options redundant-parent reth0 set interfaces xe-3/0/0 gigether-options redundant-parent reth0 set interfaces xe-14/0/0 gigether-options redundant-parent reth0 set interfaces xe-16/0/0 gigether-options redundant-parent reth0
Procedure
Step-by-Step Procedure
To configure LAG Interfaces:
Specify the number of aggregated Ethernet interfaces to be created.
[edit chassis] user@host# set chassis cluster reth-count 5
Bind redundant child physical interfaces to reth0.
[edit interfaces] user@host# set xe-1/0/0 gigether-options redundant-parent reth0 user@host# set xe-3/0/0 gigether-options redundant-parent reth0 user@host# set xe-14/0/0 gigether-options redundant-parent reth0 user@host# set xe-16/0/0 gigether-options redundant-parent reth0
Add reth0 to redundancy group 1.
user@host#set reth0 redundant-ether-options redundancy-group 1
Assign an IP address to reth0.
[edit interfaces] user@host# set reth0 unit 0 family inet address 192.0.2.1/24
Set the LACP on reth0.
[edit interfaces] user@host# set reth0 redundant-ether-options lacp active user@host# set reth0 redundant-ether-options lacp periodic fast user@host# set reth0 redundant-ether-options minimum-links 1
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.
[edit]
user@host# show interfaces
xe-1/0/0 {
gigether-options {
redundant-parent reth0;
}
}
xe-3/0/0 {
gigether-options {
redundant-parent reth0;
}
}
xe-14/0/0 {
gigether-options {
redundant-parent reth0;
}
}
xe-16/0/0 {
gigether-options {
redundant-parent reth0;
}
}
reth0 {
redundant-ether-options {
lacp {
active;
periodic fast;
}
minimum-links 1;
}
unit 0 {
family inet {
address 192.0.2.1/24;
}
}
}
ae1 {
aggregated-ether-options {
lacp {
active;
}
}
unit 0 {
family inet {
address 192.0.2.2/24;
}
}
}
[edit]
user@host# show chassis
chassis cluster {
reth-count 5;
}
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
Aggregated interface: reth0
LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
xe-16/0/0 Actor No No Yes Yes Yes Yes Fast Active
xe-16/0/0 Partner No No Yes Yes Yes Yes Fast Active
xe-14/0/0 Actor No No Yes Yes Yes Yes Fast Active
xe-14/0/0 Partner No No Yes Yes Yes Yes Fast Active
xe-1/0/0 Actor No No Yes Yes Yes Yes Fast Active
xe-1/0/0 Partner No No Yes Yes Yes Yes Fast Active
xe-3/0/0 Actor No No Yes Yes Yes Yes Fast Active
xe-3/0/0 Partner No No Yes Yes Yes Yes Fast Active
LACP protocol: Receive State Transmit State Mux State
xe-16/0/0 Current Fast periodic Collecting distributing
xe-14/0/0 Current Fast periodic Collecting distributing
xe-1/0/0 Current Slow periodic Collecting distributing
xe-3/0/0 Current Slow periodic Collecting distributing
The output indicates that LACP has been set up correctly and is active at one end.
Understanding VRRP on SRX Series Firewalls
SRX Series Firewalls support the Virtual Router Redundancy Protocol (VRRP) and VRRP for IPv6. This topic covers:
- Overview of VRRP on SRX Series Firewalls
- Benefits of VRRP
- Sample VRRP Topology
- SRX Series Firewalls Support for VRRPv3
- Limitations of VRRPv3 Features
Overview of VRRP on SRX Series Firewalls
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 Firewalls. 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 Firewall 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 Firewalls. 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.
The following illustrates basic VRRP behavior using Figure 2 for reference:
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.)
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.
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 Firewalls 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-typeandauthentication-keystatements 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-intervalstatement (for IPv4).Do not use the
inet6-advertise-intervalstatement (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.
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:
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.
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.
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.
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:
The Routing Engine detects that some VRRP groups require a state change.
The failover-delay starts for the period configured. The allowed failover-delay timer range is 50 through 100000 miliseconds.
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.
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, 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.
See Also
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 Firewalls.
Two SRX Series Firewalls connected in a chassis cluster.
One SRX Series Firewall 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.
Configuration VRRP
- Configuring VRRPv3, VRRP Groups, and Priority on Chassis Cluster Redundant Ethernet Interfaces
- Configuring VRRP Groups on Standalone Device
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.
set protocols vrrp traceoptions file vrrp.logset protocols vrrp traceoptions file size 10000000set protocols vrrp traceoptions flag allset protocols vrrp version-3set protocols vrrp ignore-nonstop-routingset interfaces ge-0/0/0 gigether-options redundant-parent reth0set interfaces ge-0/0/3 gigether-options redundant-parent reth1set interfaces ge-5/0/0 gigether-options redundant-parent reth0set interfaces ge-5/0/3 gigether-options redundant-parent reth1set interfaces reth0 redundant-ether-options redundancy-group 1set interfaces reth0 unit 0 family inet address 192.0.2.2/24 vrrp-group 0 virtual-address 192.0.2.3set interfaces reth0 unit 0 family inet address 192.0.2.2/24 vrrp-group 0 priority 255set interfaces reth0 unit 0 family inet address 192.0.2.2/24 vrrp-group 0 accept-dataset interfaces reth0 unit 0 family inet6 address 2001:db8::2/32 vrrp-inet6-group 2 virtual-inet6-address 2001:db8::3set interfaces reth0 unit 0 family inet6 address 2001:db8::2/32 vrrp-inet6-group 2 priority 255set interfaces reth0 unit 0 family inet6 address 2001:db8::2/32 vrrp-inet6-group 2 accept-dataset interfaces reth1 redundant-ether-options redundancy-group 2set interfaces reth1 unit 0 family inet address 192.0.2.4/24 vrrp-group 1 virtual-address 192.168.120.3set interfaces reth1 unit 0 family inet address 192.0.2.4/24 vrrp-group 1 priority 150set interfaces reth1 unit 0 family inet address 192.0.2.4/24 vrrp-group 1 accept-dataset interfaces reth1 unit 0 family inet6 address 2001:db8::3/32 vrrp-inet6-group 3 virtual-inet6-address 2001:db8::4set interfaces reth1 unit 0 family inet6 address 2001:db8::3/32 vrrp-inet6-group 3 priority 150set interfaces reth1 unit 0 family inet6 address 2001:db8::3/32 vrrp-inet6-group 3 accept-data
Step-by-Step Procedure
To configure VRRPv3, VRRP Groups, and priority on chassis cluster devices:
Configure a filename to the traceoptions to trace VRRP protocol traffic.
[edit protocols vrrp] user@host#
set traceoptions file vrrp.logSpecify the maximum trace file size.
[edit protocols vrrp] user@host#
set traceoptions file size 10000000Enable vrrp traceoptions.
[edit protocols vrrp] user@host#
set traceoptions flag allSet vrrp version to 3.
[edit protocols vrrp] user@host#
set version-3Configure 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
[edit protocols vrrp] user@host#
set ignore-nonstop-routingSet up the redundant Ethernet (reth) interfaces and assign the redundant interface to a zone.
[edit interfaces] user@host#
set ge-0/0/0 gigether-options redundant-parent reth0user@host#set ge-0/0/3 gigether-options redundant-parent reth1user@host#set ge-5/0/0 gigether-options redundant-parent reth0user@host#set ge-5/0/3 gigether-options redundant-parent reth1user@host#set reth0 redundant-ether-options redundancy-group 1user@host#set reth1 redundant-ether-options redundancy-group 2Configure the family inet address and virtual address for the redundant interface 0 unit 0.
[edit interfaces] user@host#
set reth0 unit 0 family inet address 192.0.2.2/24 vrrp-group 0 virtual-address 192.168.110.3user@host#set reth0 unit 0 family inet6 address 2001:db8::2/32 vrrp-inet6-group 2 virtual-inet6-address 2001:db8::3Configure the family inet address and virtual address for the redundant interface 1 unit 0.
[edit interfaces] user@host#
set reth1 unit 0 family inet address 192.0.2.4/24 vrrp-group 1 virtual-address 192.168.120.3user@host#set reth1 unit 0 family inet6 address 2001:db8::3/32 vrrp-inet6-group 3 virtual-inet6-address 2001:db8::4Set the priority of the redundant interface 0 unit 0 to 255.
[edit interfaces] user@host#
set reth0 unit 0 family inet address 192.0.2.2/24 vrrp-group 0 priority 255user@host#set reth0 unit 0 family inet6 address 2001:db8::2/32 vrrp-inet6-group 2 priority 255Set the priority of the redundant interface 1 unit 0 to 150.
[edit interfaces] user@host#
set reth1 unit 0 family inet address 192.0.2.4/24 vrrp-group 1 priority 150user@host#set reth1 unit 0 family inet6 address 2001:db8::3/32 vrrp-inet6-group 3 priority 150Configure the redundant interface 0 unit 0 to accept all packets sent to the virtual IP address.
[edit interfaces] user@host#
set reth0 unit 0 family inet address 192.0.2.2/24 vrrp-group 0 accept-datauser@host#set reth0 unit 0 family inet6 address 2001:db8::2/32 vrrp-inet6-group 2 accept-dataConfigure the redundant interface 1 unit 0 to accept all packets sent to the virtual IP address.
[edit interfaces] user@host#
set reth1 unit 0 family inet address 192.0.2.4/24 vrrp-group 1 accept-datauser@host#set reth1 unit 0 family inet6 address 2001:db8::3/32 vrrp-inet6-group 3 accept-data
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.
[edit]
user@host# show interfaces reth0
redundant-ether-options {
redundancy-group 1;
}
unit 0 {
family inet {
address 192.0.2.2/24 {
vrrp-group 0 {
virtual-address 192.0.2.3;
priority 255;
accept-data;
}
}
}
family inet6 {
address 2001:db8::2/32 {
vrrp-inet6-group 2 {
virtual-inet6-address 2001:db8::3;
priority 255;
accept-data;
}
}
}
}
[edit]
user@host# show interfaces reth1
redundant-ether-options {
redundancy-group 2;
}
unit 0 {
family inet {
address 192.0.2.4/24 {
vrrp-group 1 {
virtual-address 192.0.2.5;
priority 150;
accept-data;
}
}
}
family inet6 {
address 2001:db8::3/32 {
vrrp-inet6-group 3 {
virtual-inet6-address 2001:db8::4;
priority 150;
accept-data;
}
}
}
}
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.
set protocols vrrp version-3set interfaces xe-5/0/5 unit 0 family inet address 192.0.2.1/24 vrrp-group 0 virtual-address 192.0.2.3set interfaces xe-5/0/5 unit 0 family inet address 192.0.2.1/24 vrrp-group 0 priority 50set interfaces xe-5/0/5 unit 0 family inet address 192.0.2.1/24 vrrp-group 0 accept-dataset interfaces xe-5/0/5 unit 0 family inet6 address 2001:db8::1/32 vrrp-inet6-group 2 virtual-inet6-address 2001:db8::3set interfaces xe-5/0/5 unit 0 family inet6 address 2001:db8::1/32 vrrp-inet6-group 2 priority 50set interfaces xe-5/0/5 unit 0 family inet6 address 2001:db8::1/32 vrrp-inet6-group 2 accept-dataset interfaces xe-5/0/6 unit 0 family inet address 192.0.2.1/24 vrrp-group 1 virtual-address 192.0.2.5set interfaces xe-5/0/6 unit 0 family inet address 192.0.2.1/24 vrrp-group 1 priority 50set interfaces xe-5/0/6 unit 0 family inet address 192.0.2.1/24 vrrp-group 1 accept-dataset interfaces xe-5/0/6 unit 0 family inet6 address 2001:db8::5/32 vrrp-inet6-group 3 virtual-inet6-address 2001:db8::4set interfaces xe-5/0/6 unit 0 family inet6 address 2001:db8::5/32 vrrp-inet6-group 3 priority 50set interfaces xe-5/0/6 unit 0 family inet6 address 2001:db8::5/32 vrrp-inet6-group 3 accept-data
Step-by-Step Procedure
To configure VRRP groups on standalone device:
Set vrrp version to 3.
[edit protocols vrrp] user@host#
set version-3Configure the family inet address and virtual address for the Gigabit Ethernet interface unit 0.
[edit interfaces] user@host#
set xe-5/0/5 unit 0 family inet address 192.0.2.1/24 vrrp-group 0 virtual-address 192.0.2.3user@host#set xe-5/0/5 unit 0 family inet6 address 2001:db8::1/32 vrrp-inet6-group 2 virtual-inet6-address 2001:db8::3user@host#set xe-5/0/6 unit 0 family inet address 192.0.2.1/24 vrrp-group 1 virtual-address 192.0.2.5user@host#set xe-5/0/6 unit 0 family inet6 address 2001:db8::5/32 vrrp-inet6-group 3 virtual-inet6-address 2001:db8::4Set the priority of the Gigabit Ethernet interface unit 0 to 50.
[edit interfaces] user@host#
set xe-5/0/5 unit 0 family inet address 192.0.2.1/24 vrrp-group 0 priority 50user@host#set xe-5/0/5 unit 0 family inet6 address 2001:db8::1/32 vrrp-inet6-group 2 priority 50user@host#set xe-5/0/6 unit 0 family inet address 192.0.2.1/24 vrrp-group 1 priority 50user@host#set xe-5/0/6 unit 0 family inet6 address 2001:db8::5/32 vrrp-inet6-group 3 priority 50Configure the Gigabit Ethernet interface unit 0 to accept all packets sent to the virtual IP address.
[edit interfaces] user@host#
set xe-5/0/5 unit 0 family inet address 192.0.2.1/24 vrrp-group 0 accept-datauser@host#set xe-5/0/5 unit 0 family inet6 address 2001:db8::1/32 vrrp-inet6-group 2 accept-datauser@host#set xe-5/0/6 unit 0 family inet address 192.0.2.1/24 vrrp-group 1 accept-datauser@host#set xe-5/0/6 unit 0 family inet6 address 2001:db8::5/32 vrrp-inet6-group 3 accept-data
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.
[edit]
user@host# show interfaces xe-5/0/5
unit 0 {
family inet {
address 192.0.2.1/24 {
vrrp-group 0 {
virtual-address 192.0.2.3;
priority 50;
accept-data;
}
}
}
family inet6 {
address 2001:db8::1/32 {
vrrp-inet6-group 2 {
virtual-inet6-address 2001:db8::3;
priority 50;
accept-data;
}
}
}
}
[edit]
user@host# show interfaces xe-5/0/6
unit 0 {
family inet {
address 192.0.2.1/24 {
vrrp-group 1 {
virtual-address 192.0.2.5;
priority 50;
accept-data;
}
}
}
family inet6 {
address 2001:db8::5/32 {
vrrp-inet6-group 3 {
virtual-inet6-address 2001:db8::4;
priority 50;
accept-data;
}
}
}
}
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
Interface State Group VR state VR Mode Timer Type Address
reth0.0 up 0 master Active A 0.149 lcl 192.0.2.3
vip 192.0.2.3
reth0.0 up 2 master Active A 0.155 lcl 2001:db8::2
vip 2001:db8:5eff:fe00:202
vip 2001:db8::2
reth1.0 up 1 master Active A 0.445 lcl 192.0.2.4
vip 192.0.2.4
reth1.0 up 3 master Active A 0.414 lcl 2001:db8::4
vip 2001:db8:5eff:fe00:203
vip 2001:db8::4Meaning
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 VRRP on standalone device
Purpose
Verify that VRRP 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
Interface State Group VR state VR Mode Timer Type Address
xe-5/0/5.0 up 0 backup Active D 3.093 lcl 192.0.2.2.1
vip 192.0.2.2
mas 192.0.2.2.2
xe-5/0/5.0 up 2 backup Active D 3.502 lcl 2001:db8::2:1
vip 2001:db8:200:5eff:fe00:202
vip 2001:db8::2
mas 2001:db8:210:dbff:feff:1000
xe-5/0/6.0 up 1 backup Active D 3.499 lcl 192.0.2.5.1
vip 192.0.2.5
mas 192.0.2.5.2
xe-5/0/6.0 up 3 backup Active D 3.282 lcl 2001:db8::5
vip 2001:db8:200:5eff:fe00:203
vip 2001:db8::4
mas 2001:db8:210:dbff:feff:1001
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.
Requirements
This example uses the following hardware and software components:
-
Three routers
-
Junos OS Release 11.3 or later
- This example has been recently updated and revalidated on Junos OS Release 21.1R1.
- For details on VRRP support for specific platform and Junos OS release combinations, see Feature Explorer.
Overview
This example uses a VRRP group, which has a virtual address for IPv6. Devices on the LAN use this virtual 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
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.
set interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1:1::1/64 vrrp-inet6-group 1 virtual-inet6-address 2001:db8:1:1::254 set interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1:1::1/64 vrrp-inet6-group 1 priority 110 set interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1:1::1/64 vrrp-inet6-group 1 accept-data set interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1:1::1/64 vrrp-inet6-group 1 track interface ge-0/0/2 priority-cost 20 set interfaces ge-0/0/2 unit 0 family inet6 address 2001:db8:1:3::1/64 set protocols router-advertisement interface ge-0/0/1.0 virtual-router-only set protocols router-advertisement interface ge-0/0/1.0 prefix 2001:db8:1:1::/64 set routing-options rib inet6.0 static route 0::0/0 next-hop 2001:db8:1:3::2
Step-by-Step Procedure
To configure this example:
-
Configure the interfaces.
[edit] user@routerA# set interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1:1::1/64 user@routerA# set interfaces ge-0/0/2 unit 0 family inet6 address 2001:db8:1:3::1/64
-
Configure the IPv6 VRRP group identifier and the virtual IP address.
[edit interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1:1::1/64] user@routerA# set vrrp-inet6-group 1 virtual-inet6-address 2001:db8:1:1::254
-
Configure the priority for RouterA higher than RouterB to become the primary virtual router. RouterB is using the default priority of 100.
[edit interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1:1::1/64] user@routerA# set vrrp-inet6-group 1 priority 110
-
Configure
track interfaceto track whether the interface connected to the Internet is up, down, or not present to change the priority of the VRRP group.[edit interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1:1::1/64] user@routerA# set vrrp-inet6-group 1 track interface ge-0/0/2 priority-cost 20
-
Configure
accept-datato enable the primary router to accept all packets destined for the virtual IP address.[edit interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1:1::1/64] user@routerA# set vrrp-inet6-group 1 accept-data
-
Configure a static route for traffic to the Internet.
[edit] user@routerA# set routing-options rib inet6.0 static route 0::0/0 next-hop 2001:db8:1:3::2
-
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.
[edit protocols router-advertisement interface ge-0/0/1.0] user@routerA# set prefix 2001:db8:1:1::/64
-
Configure router advertisements to be sent only for VRRP IPv6 groups configured on the interface if the groups are in the primary state.
[edit protocols router-advertisement interface ge-0/0/1.0] user@routerA# set virtual-router-only
Results
From configuration mode, confirm your configuration by entering the
show interfaces,
show protocols
router-advertisement
and show routing-options commands. If the
output does not display the intended configuration, repeat the instructions
in this example to correct the configuration.
[edit]
user@routerA# show interfaces
ge-0/0/1 {
unit 0 {
family inet6 {
address 2001:db8:1:1::1/64 {
vrrp-inet6-group 1 {
virtual-inet6-address 2001:db8:1:1::254;
priority 110;
accept-data;
track {
interface ge-0/0/2 {
priority-cost 20;
}
}
}
}
}
}
}
ge-0/0/2 {
unit 0 {
family inet6 {
address 2001:db8:1:3::1/64;
}
}
}
[edit]
user@routerA# show protocols router-advertisement
interface ge-0/0/1.0 {
virtual-router-only;
prefix 2001:db8:1:1::/64;
}
[edit]
user@routerA# show routing-options
rib inet6.0 {
static {
route 0::0/0 next-hop 2001:db8:1:3::2;
}
}
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.
set interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1:1::2/64 vrrp-inet6-group 1 virtual-inet6-address 2001:db8:1:1::254 set interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1:1::2/64 vrrp-inet6-group 1 priority 110 set interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1:1::2/64 vrrp-inet6-group 1 accept-data set protocols router-advertisement interface ge-0/0/1.0 virtual-router-only set protocols router-advertisement interface ge-0/0/1.0 prefix 2001:db8:1:1::/64
Step-by-Step Procedure
To configure this example:
-
Configure the interfaces.
[edit] user@routerB# set interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1:1::2/64 user@routerB# set interfaces ge-0/0/2 unit 0 family inet6 address 2001:db8:1:4::1/64
-
Configure the IPv6 VRRP group identifier and the virtual IP address.
[edit interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1:1::2/64] user@routerB# set vrrp-inet6-group 1 virtual-inet6-address 2001:db8:1:1::254
-
Configure
accept-datato enable the backup router to accept all packets destined for the virtual IP address in the event the backup router becomes primary.[edit interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1:1::2/64] user@routerB# set vrrp-inet6-group 1 accept-data
-
Configure a static route for traffic to the Internet.
[edit] user@routerB# set routing-options rib inet6.0 static route 0::0/0 next-hop 2001:db8:1:4::2
-
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.
[edit protocols router-advertisement interface ge-0/0/1.0] user@routerB# set prefix 2001:db8:1:1::/64
-
Configure router advertisements to be sent only for VRRP IPv6 groups configured on the interface if the groups are in the primary state.
[edit protocols router-advertisement interface ge-0/0/1.0] user@routerB# set virtual-router-only
Results
From configuration mode, confirm your configuration by entering the
show interfaces,
show protocols router-advertisement
and
show routing-options
commands. If the output does not display the intended
configuration, repeat the instructions in this example to correct the
configuration.
[edit]
user@routerB# show interfaces
ge-0/0/1 {
unit 0 {
family inet6 {
address 2001:db8:1:1::2/64 {
vrrp-inet6-group 1 {
virtual-inet6-address 2001:db8:1:1::254;
accept-data;
}
}
}
}
}
ge-0/0/2 {
unit 0 {
family inet6 {
address 2001:db8:1:4::1/64;
}
}
}
[edit]
user@routerB# show protocols router-advertisement
interface ge-0/0/1.0 {
virtual-router-only;
prefix 2001:db8:1:1::/64;
}
[edit]
user@routerB# show routing-options
rib inet6.0 {
static {
route 0::0/0 next-hop 2001:db8:1:4::2;
}
}
If you are done configuring the device, enter commit from
configuration mode.
Configuring Router C
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.
set interfaces ge-0/0/0 unit 0 family inet6 address 2001:db8:1:1::3/64 set routing-options rib inet6.0 static route 0::0/0 next-hop 2001:db8:1:1::254
Verification
- Verifying That VRRP Is Working on Router A
- Verifying That VRRP Is Working on Router B
- Verifying Router C Reaches the Internet Transiting Router A
- Verifying Router B Becomes Primary for VRRP
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 commands to verify that VRRP is active on Router A, that the router is primary for group 1 and the interface connected to the Internet is being tracked.
user@routerA> show vrrp
Interface State Group VR state VR Mode Timer Type Address
ge-0/0/1.0 up 1 master Active A 0.690 lcl 2001:db8:1:1::1
vip fe80::200:5eff:fe00:201
vip 2001:db8:1:1::254
user@routerA> show vrrp track Track Int State Speed VRRP Int Group VR State Current prio ge-0/0/2.0 up 1g ge-0/0/1.0 1 master 110
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
0.690)
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 1.
user@routerB> show vrrp
Interface State Group VR state VR Mode Timer Type Address
ge-0/0/1.0 up 1 backup Active D 2.947 lcl 2001:db8:1:1::2
vip fe80::200:5eff:fe00:201
vip 2001:db8:1:1::254
mas fe80::5668:a0ff:fe99:2d7d
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 (D
2.947)
indicates the remaining time (in seconds) in which this router expects to
receive a VRRP advertisement from the other router.
Verifying Router C Reaches the Internet Transiting Router A
Purpose
Verify connectivity to the Internet from Router C.
Action
Use the following commands to verify that Router C can reach the Internet.
user@routerC> ping 2001:db8:16:255::1 count 2 PING6(56=40+8+8 bytes) 2001:db8:1:1::3 --> 2001:db8:16:255::1 16 bytes from 2001:db8:16:255::1, icmp_seq=0 hlim=63 time=12.810 ms 16 bytes from 2001:db8:16:255::1, icmp_seq=1 hlim=63 time=30.139 ms --- 2001:db8:16:255::1 ping6 statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/std-dev = 12.810/21.474/30.139/8.664 ms
user@routerC> traceroute 2001:db8:16:255::1 traceroute6 to 2001:db8:16:255::1 (2001:db8:16:255::1) from 2001:db8:1:1::3, 64 hops max, 12 byte packets 1 2001:db8:1:1::1 (2001:db8:1:1::1) 9.891 ms 32.353 ms 7.859 ms 2 2001:db8:16:255::1 (2001:db8:16:255::1) 257.483 ms 19.877 ms 7.451 ms
Meaning
The ping command shows reachabilty to the Internet and the
traceroute command shows that Router A is being
transited.
Verifying Router B Becomes Primary for VRRP
Purpose
Verify that Router B becomes primary for VRRP when the interface between Router A and the Internet goes down.
Action
Use the following commands to verify that Router B is primary and that Router C can reach the Internet transiting Router B.
user@routerA> show vrrp track detail
Tracked interface: ge-0/0/2.0
State: down, Speed: 1g
Incurred priority cost: 20
Tracking VRRP interface: ge-0/0/1.0, Group: 1
VR State: backup
Current priority: 90, Configured priority: 110
Priority hold-time: disabled
user@routerB> show vrrp
Interface State Group VR state VR Mode Timer Type Address
ge-0/0/1.0 up 1 master Active A 0.119 lcl 2001:db8:1:1::2
vip fe80::200:5eff:fe00:201
vip 2001:db8:1:1::254
user@routerC> traceroute 2001:db8:16:255::1 traceroute6 to 2001:db8:16:255::1 (2001:db8:16:255::1) from 2001:db8:1:1::3, 64 hops max, 12 byte packets 1 2001:db8:1:1::2 (2001:db8:1:1::2) 52.945 ms 344.383 ms 29.540 ms 2 2001:db8:16:255::1 (2001:db8:16:255::1) 46.168 ms 24.744 ms 23.867 ms
Meaning
The show vrrp track detail command shows the tracked
interface is down on Router A, that the priority has dropped to 90, and that
Router A is now the backup. The show vrrp command shows
that Router B is now the primary for VRRP and the
traceroute command shows that Router B is now being
transited.