ON THIS PAGE
Example: Determining Member Health Using an MX Series Virtual Chassis Heartbeat Connection with Member Routers in the Same Subnet
A heartbeat connection is an IP-based, bidirectional packet connection in an MX Series Virtual Chassis between the Virtual Chassis primary and backup routers. The heartbeat packets exchanged over this connection provide critical information about the availability and health of each member router. Starting in Junos OS Release 14.1, you can configure a heartbeat connection in an MX Series Virtual Chassis.
This example describes how to configure a heartbeat connection in an MX Series Virtual Chassis when both member routers reside in the same subnet. For information about configuring a heartbeat connection when the Virtual Chassis member routers reside in different subnets, see Example: Determining Member Health Using an MX Series Virtual Chassis Heartbeat Connection with Member Routers in Different Subnets.
Requirements
This example uses the following software and hardware components:
Junos OS Release 14.1 and later releases
Two MX240 Universal Routing Platforms, each with dual Routing Engines
This configuration example has been tested using the software release listed and is assumed to work on all later releases.
We recommend that you use the commit synchronize command to save any configuration changes to the Virtual Chassis.
For an MX Series Virtual Chassis, the force option is the
default and only behavior when you issue the commit synchronize command. Issuing the commit synchronize command for an
MX Series Virtual Chassis configuration has the same effect as issuing
the commit synchronize force command.
Before you configure a heartbeat connection for a Virtual Chassis:
Configure a Virtual Chassis consisting of two MX Series routers.
As part of the preprovisioned Virtual Chassis configuration shown in the configuration example, you must create and apply the
member0-re0,member0-re1,member1-re0, andmember1-re1configuration groups for each member Routing Engine. Each configuration group includes a unique IP address for the management Ethernet interface (fxp0) on each Routing Engine.Note:When you create the preprovisioned Virtual Chassis configuration at the
[edit virtual-chassis]hierarchy level, make sure you do not configure theno-split-detectionstatement to disable detection of a split in the Virtual Chassis. Using theno-split-detectionstatement is prohibited when you configure a Virtual Chassis heartbeat connection, and doing so causes the commit operation to fail.Ensure TCP connectivity between the primary Routing Engine in the Virtual Chassis primary router (VC-Pp) and the primary Routing Engine in the Virtual Chassis backup router (VC-Bp).
The Virtual Chassis heartbeat connection opens a proprietary TCP port numbered 33087 on the VC-Pp to listen for heartbeat messages. If your network design includes firewalls or filters, make sure the network allows traffic between TCP port 33087 on the VC-Pp and the dynamically allocated TCP port on the VC-Bp.
Overview
A heartbeat connection is an IP-based, bidirectional packet connection between the primary router and backup router in an MX Series Virtual Chassis. The member routers forming the heartbeat connection exchange heartbeat packets that provide critical information about the availability and health of each member router. During a disruption or split in the Virtual Chassis configuration, the heartbeat connection prevents the member routers from changing primary role roles unnecessarily, which can cause undesirable results.
This example configures a heartbeat connection for an MX Series Virtual Chassis in which both
MX240 member routers reside in the 10.4.0.0 subnet. Member router
master-router
is the global primary router for the Virtual Chassis (VC-P), and member router
backup-router
is the global backup router (VC-B). Both member routers have dual Routing Engines
installed, and the heartbeat connection is configured between the primary Routing
Engine in
master-router
(represented by VC-Pp or member0-re0) and the primary Routing
Engine in
backup-router
(represented by VC-Bp or member1-re0).
Configuring a heartbeat connection for an MX Series Virtual Chassis when both member routers reside in the same subnet consists of the following tasks:
Configure the global
master-onlyIP address for thefxp0management interface on the same subnet as the four Routing Engines in the Virtual Chassis.Configure a network path for the heartbeat connection.
This example uses a global static route to provide a path for member routers in the same subnet to reach each other via a TCP/IP connection.
Configure the global
master-onlyIP address for thefxp0management interface as the heartbeat address to establish the Virtual Chassis heartbeat connection.(Optional) Configure a nondefault value for the Virtual Chassis heartbeat timeout interval.
Topology
This example configures a heartbeat connection for an MX Series Virtual Chassis with both member routers in the same subnet. For redundancy, each member router is configured with two Virtual Chassis ports.
Table 1 shows the hardware and software configuration settings for each MX Series router in the Virtual Chassis.
Router Name |
Hardware |
Serial Number |
Member ID |
Role |
Virtual Chassis Ports |
Subnet |
|---|---|---|---|---|---|---|
master-router |
MX240 router with:
|
JN11026AFAFC |
0 |
routing-engine (primary) |
vcp-1/0/0vcp-1/1/0 |
10.4.0.0/16 |
backup-router |
MX240 router with:
|
JN112C2FCAFC |
1 |
routing-engine (backup) |
vcp-2/0/0vcp-2/1/0 |
10.4.0.0/16 |
Configuration
To configure a heartbeat connection in an MX Series Virtual Chassis with both member routers in the same subnet, perform these tasks:
- CLI Quick Configuration
- Configuring a Consistent Management IP Address for Each Routing Engine
- Configuring a Static Route Between the Primary and Backup Member Routers
- Configuring the Heartbeat Address and Heartbeat Timeout
CLI Quick Configuration
To quickly configure a heartbeat connection for a Virtual Chassis with both member routers in the same subnet, copy the following commands and paste them into the router terminal window:
[edit] set groups member0-re0 interfaces fxp0 unit 0 family inet address 10.4.2.210/16 master-only set groups member0-re1 interfaces fxp0 unit 0 family inet address 10.4.2.210/16 master-only set groups member1-re0 interfaces fxp0 unit 0 family inet address 10.4.2.210/16 master-only set groups member1-re1 interfaces fxp0 unit 0 family inet address 10.4.2.210/16 master-only set groups global routing-options static route 10.4.0.0/16 next-hop 10.4.0.1 set groups global routing-options static route 10.4.0.0/16 retain set groups global routing-options static route 10.4.0.0/16 no-readvertise set virtual-chassis heartbeat-address 10.4.2.210 set virtual-chassis heartbeat-timeout 20
Configuring a Consistent Management IP Address for Each Routing Engine
Step-by-Step Procedure
In addition to configuring a unique IP address for the fxp0
management interface on each Routing Engine when you first set up the
Virtual Chassis, you must configure an additional management IP address,
known as the master-only address, to ensure consistent
access to the fxp0 management interface on the primary
Routing Engine in the Virtual Chassis primary router (VC-Pp, represented by
member0-re0 in this example). You then use the
master-only address as the heartbeat address to
establish the Virtual Chassis heartbeat connection.
Because the Virtual Chassis member routers in this example both reside in the
same subnet (10.4.0.0), you can configure the same
master-only address for each Routing Engine. The
master-only address is active only on the management
interface for the VC-Pp. During a switchover, the
master-only address moves to the new Routing Engine
currently functioning as the VC-Pp.
To configure the master-only
fxp0 IP address for each Routing Engine:
-
From the console on member 0, configure the same IP address for the
fxp0management interface on each Routing Engine.{master:member0-re0}[edit] user@master-router# set groups member0-re0 interfaces fxp0 unit 0 family inet address 10.4.2.210/16 primary-only user@master-router# set groups member0-re1 interfaces fxp0 unit 0 family inet address 10.4.2.210/16 master-only user@master-router# set groups member1-re0 interfaces fxp0 unit 0 family inet address 10.4.2.210/16 master-only user@master-router# set groups member1-re1 interfaces fxp0 unit 0 family inet address 10.4.2.210/16 master-only
Results
From the console on the Virtual Chassis primary router, display the results of the configuration for each configuration group. For brevity, portions of the configuration unrelated to this procedure are replaced by an ellipsis (...).
For member0-re0:
{master:member0-re0}[edit]
user@master-router# show groups member0-re0
system {
host-name master-router;
backup-router 10.4.0.1 destination [ 172.16.0.0/12 ... 10.204.0.0/16 ];
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 10.4.2.100/16;
address 10.4.2.210/16 {
master-only;
}
}
}
}
}
For member0-re1:
{master:member0-re0}[edit]
user@master-router# show groups member0-re1
system {
host-name master-router1;
backup-router 10.4.0.1 destination [ 172.16.0.0/12 ... 10.204.0.0/16 ];
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 10.4.2.101/16;
address 10.4.2.210/16 {
master-only;
}
}
}
}
}
For member1-re0:
{master:member0-re0}[edit]
user@master-router# show groups member1-re0
system {
host-name backup-router;
backup-router 10.4.0.1 destination [ 172.16.0.0/12 ... 10.204.0.0/16 ];
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 10.4.3.101/16;
address 10.4.2.210/16 {
master-only;
}
}
}
}
}
For member1-re1:
{master:member0-re0}[edit]
user@master-router# show groups member1-re1
system {
host-name backup-router1;
backup-router 10.4.0.1 destination [ 172.16.0.0/12 ... 10.204.0.0/16 ];
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 10.4.3.102/16;
address 10.4.2.210/16 {
master-only;
}
}
}
}
}
If you are done configuring the device, enter commit from
configuration mode.
Configuring a Static Route Between the Primary and Backup Member Routers
Step-by-Step Procedure
You must configure a secure and reliable path between the primary router and backup router for the exchange of TCP/IP heartbeat packets. The heartbeat packets provide critical information about the availability and health of each member router.
The route you create for the heartbeat connection must be independent of the
Virtual Chassis port links. Specifically, you must ensure that the primary
Routing Engine in the Virtual Chassis backup router (VC-Bp) can make a
TCP/IP connection to the master-only IP address of the
primary Routing Engine in the Virtual Chassis primary router (VC-Pp).
This examples creates a global static route between the member routers to configure the heartbeat path. However, you can choose the method that best meets your needs to configure the heartbeat path for member routers in the same subnet. For example, you might use the member router’s default gateway for this purpose.
We recommend that you use the router management interface
(fxp0) as the heartbeat path. The management
interface is generally available earlier than the line card interfaces,
and is typically connected to a more secure network than the other
interfaces.
To create a static route between the primary and backup member routers:
-
From the console on member 0, configure a static route between the member routers in subnet 10.4.0.0.
{master:member0-re0}[edit] user@master-router# set groups global routing-options static route 10.4.0.0/16 next-hop 10.4.0.1 user@master-router# set groups global routing-options static route 10.4.0.0/16 retain user@master-router# set groups global routing-options static route 10.4.0.0/16 no-readvertise
Results
Display the results of the configuration. For brevity, portions of the configuration unrelated to this procedure are replaced by an ellipsis (...).
{master:member0-re0}[edit]
user@master-router# show groups global routing-options static
route 10.4.0.0/16 {
next-hop 10.4.0.1;
retain;
no-readvertise;
}
...
If you are done configuring the device, enter commit from
configuration mode.
Configuring the Heartbeat Address and Heartbeat Timeout
Step-by-Step Procedure
To establish the heartbeat connection in a two-member MX Series Virtual
Chassis, you must configure the IP address for the connection between the
primary and backup member routers. To ensure consistent access to the
primary Routing Engine in the Virtual Chassis primary router (VC-Pp)
regardless of which Routing Engine is currently active, you set the
heartbeat address to the previously configured global
master-only IP address for the fxp0
management interface.
Optionally, you can also configure a nondefault value for the heartbeat timeout interval. The heartbeat timeout is the maximum time within which a Virtual Chassis member router must respond to a heartbeat packet sent by the other member router. If you do not explicitly configure the heartbeat timeout interval, the default value (2 seconds) applies.
To configure the heartbeat address and heartbeat timeout:
-
From the console on member 0, specify that you want to edit the Virtual Chassis preprovisioned configuration.
{master:member0-re0}[edit] user@master-router# edit virtual-chassis -
Configure the common
master-onlyIP address for thefxp0management interface as the heartbeat address.{master:member0-re0}[edit virtual-chassis] user@master-router# set heartbeat-address 10.4.2.210 -
(Optional) Configure a nondefault value for the heartbeat timeout interval.
{master:member0-re0}[edit virtual-chassis] user@master-router# set heartbeat-timeout 20
Results
Display the results of the configuration.
{master:member0-re0}[edit]
user@master-router# show virtual-chassis
preprovisioned;
traceoptions {
file VCCP size 100m;
flag all;
}
heartbeat-address 10.4.2.210;
heartbeat-timeout 20;
member 0 {
role routing-engine;
serial-number JN11026AFAFC;
}
member 1 {
role routing-engine;
serial-number JN112C2FCAFC;
}
If you are done configuring the device, enter commit from
configuration mode.
Verification
To confirm that the Virtual Chassis heartbeat connection is working properly, perform these tasks:
- Verifying the Virtual Chassis Heartbeat Connection
- Verifying Use of the Heartbeat Connection During an Adjacency Split or Disruption
- Verifying Virtual Chassis Member Health from Heartbeat Statistics
Verifying the Virtual Chassis Heartbeat Connection
Purpose
Verify that the heartbeat connection between the Virtual Chassis member routers is properly configured and operational.
Action
Display the state of one or both member routers when a heartbeat connection is configured.
{master:member0-re0}
user@master-router> show virtual-chassis heartbeat
member0:
--------------------------------------------------------------------------
Local Remote State Time
10.4.2.210 10.4.3.101 Alive 2014-02-18 11:18:14 PST
member1:
--------------------------------------------------------------------------
Local Remote State Time
10.4.3.101 10.4.2.210 Alive 2014-02-18 11:18:15 PSTMeaning
For each member router, the command output displays
the IP addresses of the local and remote member routers that form
the heartbeat connection. The value Alive in the State field confirms that the primary Routing Engine in the specified
member router is connected and has received a heartbeat response message.
The Time field specifies the date and time of the last
connection state change.
Verifying Use of the Heartbeat Connection During an Adjacency Split or Disruption
Purpose
Verify use of the heartbeat connection when an adjacency disruption or split is detected in the Virtual Chassis.
Action
Display the status of the member routers in the Virtual Chassis:
{master:member0-re0}
user@master-router> show virtual-chassis status
Preprovisioned Virtual Chassis
Virtual Chassis ID: 4806.94d6.2362
Mastership Neighbor List
Member ID Status Serial No Model priority Role ID Interface
0 (FPC 0- 11) Heartbt JN11026AFAFC mx240 129 Master* 1 vcp-1/0/0
1 vcp-1/1/0
1 (FPC 12- 23) Prsnt JN112C2FCAFC mx240 129 Backup 0 vcp-2/0/0
0 vcp-2/1/0
Meaning
The Status field for member ID 0 displays Heartbt, which indicates that this member router has used the
heartbeat packet connection to maintain primary role roles during
an adjacency disruption or split in the Virtual Chassis configuration.
The Status field for member ID 1 displays Prsnt, which indicates that this member router is connected to the Virtual
Chassis.
If a router is not currently connected to the Virtual Chassis,
the Status field displays NotPrsnt.
Verifying Virtual Chassis Member Health from Heartbeat Statistics
Purpose
Use statistics collected by the heartbeat connection
to verify the availability and health of each Virtual Chassis member
router. You can also use the show virtual-chassis heartbeat detail command to determine the maximum latency and minimum latency in
your network.
Action
Display and review the statistics collected by the heartbeat connection.
{master:member0-re0}
user@master-router> show virtual-chassis heartbeat detail
member0:
--------------------------------------------------------------------------
Local Remote State Time
10.4.2.210 10.4.3.101 Alive 2014-02-18 11:18:14 PST
Heartbeat statistics
Heartbeats sent: 10079
Heartbeats received: 10079
Heartbeats lost/missed: 0
Last time sent: 2014-02-18 20:03:10 PST (00:00:00 ago)
Last time received: 2014-02-18 20:03:10 PST (00:00:00 ago)
Maximum latency (secs): 0
Minimum latency (secs): 0
member1:
--------------------------------------------------------------------------
Local Remote State Time
10.4.3.101 10.4.2.210 Alive 2014-02-18 11:18:15 PST
Heartbeat statistics
Heartbeats sent: 10083
Heartbeats received: 10083
Heartbeats lost/missed: 0
Last time sent: 2014-02-18 20:03:09 PST (00:00:01 ago)
Last time received: 2014-02-18 20:03:09 PST (00:00:01 ago)
Maximum latency (secs): 0
Minimum latency (secs): 0Meaning
In this example, the number of heartbeat request messages
sent (Heartbeats sent) equals the number of heartbeat response
messages received (Heartbeats received), with no heartbeat
messages lost (Heartbeats lost/missed). This indicates
that both member routers forming the heartbeat connection were available
and operational. Any difference between Heartbeats sent and Heartbeats received appears in the Heartbeats
lost/missed field.
The Maximum latency and Minimum latency fields measure the maximum and minimum number of seconds that elapse
on the local router between trasnmission of a heartbeat request message
and receipt of a heartbeat response message. In this example, the
value 0 in the Maximum latency and Minimum
latency fields indicates that there is no measurable network
delay caused by this operation. You can use the Maximum latency value to determine whether you need to increase the heartbeat-timeout to a value higher than the default (2 seconds). If the maximum
latency in your network is too high to accommodate a 2-second heartbeat-timeout value, increasing the heartbeat-timeout interval enables you to account for network delay when a Virtual
Chassis adjacency disruption or split occurs.
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.