You configure and manage almost all aspects of a VC via the VC’s master RE. However, you can also configure VC parameters when an EX4200 is a standalone switch and not actually attached to other switches. This is because each EX4200 switch has some innate characteristics of a VC by default. A standalone EX4200 switch is assigned member ID 0 and is the master of its own (and therefore single-member) VC, which allows you to configure VC parameters on a standalone switch.
When the previously standalone switch is interconnected with an existing VC, the VC configuration statements and any VCE uplink settings that you previously specified on the standalone switch remain part of its configuration, where they can do such things as influence mastership reelections. Once a switch becomes part of a VC, the current VC master synchronizes its configuration copy to all member switches, overwriting any local changes that conflict with the current master’s settings.
As with configuration, VC operation and diagnostic troubleshooting is generally performed through the master switch. In a typical configuration, a single virtual IP address is shared among all VC switch members, and any incoming traffic received by a VC member for that shared address is automatically redirected to the current master RE. In a similar manner, a virtual console service redirects console input on any VC switch member to the master RE’s console using an internal communications path.
There is a configuration option to disable the internal management VLAN, which allows you to access each VC switch member through its (now) individually IP-addressed OoB management Ethernet port. This option is generally used only in advanced VC troubleshooting situations, and is described later.
The next section details the parameters that are normally configured when deploying a VC with a preprovisioned configuration file.
Broadly speaking, there are two primary ways to deploy a VC: via plug-and-play with a default or non-provisioned configuration, or via preprovisioned mode. The latter must include explicit configuration that can force VC member ID and roles in a deterministic manner. Although the anything-goes nature of a default configuration VC is guaranteed to work (when using all VCP cabling), such a design is generally not considered to be a best practice. Note that use of VCE ports requires explicit actions because, by default, these ports operate in uplink mode.
In non-provisioned mode with all switches running default configurations, all will have the same mastership priority. As such, the master switch will be the first one powered up, and the backup RE is the second switch powered on. Should the current master later fail, the backup RE becomes the master and any of the remaining switches could become the new backup, assuming they were all powered up at nearly the same time; recall that uptime can influence mastership tiebreaking, as described previously. Although some might argue that having 1:10 RE redundancy (meaning that any of the 10 VC members can become the active RE) is a good thing, others argue that the law of diminishing returns kicks in when you actually factor the probability of a failure mode that manages to take down two switches while somehow managing to spare all other VC members. In most cases, whatever causes you to lose both your current and backup master REs at the same time—for example, the loss of AC power distribution—is going to take down the entire VC anyway.
In contrast, a deterministic design uses a preprovisioned VC
member-to-role mapping that, in the best practice case, assigns a master
and backup RE with all remaining VC members forced into a Line Card (LC) role. In most cases, you will also want to
statically assign switch member IDs. Such an approach removes the significance of
the switch power-up/VC attachment sequence, which, by default, assigns
member IDs in the sequence in which each switch is powered up/attached
to the VC. This is a significant point, because in addition to its use
in various operational and maintenance commands, the member ID also
impacts the interface names for that switch’s front-panel ports. For
example, the first GE port on the VC member with ID 3 is ge-3/0/0, and you may want this ID to be
deterministically assigned to the third EX switch in a vertical stack,
and to ensure that it can never change by nailing the value down with
explicit configuration.
Regardless of whether you use a default or prestaged configuration, when it comes to expanding a VC you will need to physically attach a new switch member to an existing VC. When performing a VC addition, you must ensure that the new switch is powered off before attaching it to the existing VC.
You can attach a powered-on switch to an existing VC, but this operation is disruptive because it constitutes the merging of two VCs into one. Recall that every standalone EX4200 is, by definition, the master of its own domain. Therefore, when attached to a VC after being powered on, there are two active master REs, which forces a contention situation, with the result being the reboot of the losing RE and its VC members, along with the loss of its configuration. Because the old master’s configuration is lost, the final VC configuration will be that of the winning master, and it’s likely that the member ID will also change. Because of the potential for resulting network disruption, cold insertion is always recommended when adding a new member to a VC. In a cold insertion, the newly attached and powered-on switch does not assume a master role, and instead listens to VCCP messages to learn its role in the VC. Assuming the new switch has a lower priority, there will be no master contention process, as would occur with a host insertion.
Several parameters can be configured to control and manage the operation of a VC. At a minimum, you should assign a virtual management address that represents the VC itself and is serviced by whatever member switch is the VC’s current master RE.
Most VC designs, even when using non-provisioned mode, typically add additional configuration to help promote some degree of deterministic operation. This section details VC configuration options, along with some best practice design tips to keep things interesting. Note that with a few exceptions, all of these parameters are configured through the master RE, which then pushes the changes to the affected members when the configuration is synchronized.
You configure a virtual management IP address as you would on any real
interface, except the vme interface
does not accept any encapsulation options, and forces the use of unit
0, given that VLAN tagging is currently not supported. Once in place,
any matching traffic received on the physical me0 interface at any switch member is
automatically redirected to the vme.0 interface on the active VC master,
regardless of the member switch on which the traffic ingresses.
You can configure both an IPv4 and IPv6 address if needed; an
advanced license is not required for IPv6 on the OoB management
interface. The example shown here performs IPv4 address configuration
for the vme.0 interface:
[edit] lab@Vodka#edit interfaces[edit interfaces] lab@Vodka#set vme unit 0 family inet address 172.16.69.34/24[edit interfaces] lab@Vodka#show vmeunit 0 { family inet { address 172.16.69.34/24; } }
The result is a vme.0
interface instantiation on the current master RE. Note that non-master
member switches do not display a vme.0 interface, and show their respective
me0 interfaces as having no
configuration. A later section details use of the no-management-vlan
option to permit explicit IP addresses of a member switch’s me0 interface while part of a VC.
Most of the VC configuration parameters are found at the [edit virtual-chassis] hierarchy, as you
might expect. The options are shown here with the command-line interface (CLI) help function:
[edit virtual-chassis]
lab@Vodka# set ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
> mac-persistence-timer How long to retain MAC address when member leaves virtual
chassis
> member Member of virtual chassis configuration
preprovisioned Only accept preprovisioned members
> traceoptions Global tracing options for virtual chassisThe mac-persistence-timer
knob determines how long a new master continues to use the MAC address
that was owned by the previous master. The default is 10 minutes, and
can be set to 0 for an immediate switch or to some really long value
so that the manual claims are unlimited. The goal is to avoid a MAC
address change and the resulting reflooding/relearning, in the event
that the old master’s departure is short-lived and it can return to
operation without any external device being the wiser.
The preprovisioned option
establishes how deterministic you wish to be. When this is enabled,
you must map each member switch’s serial number to a member ID and a
specific role of either RE or LC. You cannot specify a member priority
in a preprovisioned configuration. The priority is assigned based on a
default mapping-to-member role (i.e., the RE role is assigned 129
while the LC role is assigned 0). In preprovisioned mode, a matching
serial number must be found or the new member cannot become part of
the active VC topology. Note that a VCCP adjacency is still formed in
this case, and the unwelcome switch will quickly be relegated to an LC
role where it can do little damage. Note also that the virtual
console/management functionality will not work from the
non-provisioned switch, and its LSAs are ignored during SPF
calculation, which effectively eliminates it from the active VC’s
topology.
By default, the VC configuration mode is considered non-provisioned, which is synonymous with the factory default in that no explicit VC configuration is required. The default VC mode permits the mapping of specific member IDs to a mastership priority value, but this mapping is not required. Member IDs with no mapping receive the default value of 128; you can prevent a member from being able to become the master or backup RE by assigning a value of 0. The highest priority of 255 should be assigned to the members that you wish to function as the master and backup REs. You cannot manually assign a VC member role, or specify a serial number when in non-provisioned mode.
Note
The current best practice is to have both a master and a backup RE in each VC. When there are more than three VC members, the remaining members are forced into an LC role. Both of the candidate RE members are assigned the same priority, which is typically the highest possible value of 255. This is done to prevent RE mastership preemption in the case that a primary RE suffers a transient failure, such as a reboot, and is known as non-revertive behavior. When the old master comes back online, its equal priority setting prevents it from forcing another mastership change, which promotes general stability while allowing human intervention (e.g., logfile analysis) before the decision is made to revert to the original mastership roles, which can then be performed in a maintenance window.
In a non-provisioned mode, the master RE assigns the next sequential member ID (and any associated priority that is set in the configuration) to each member switch as it is attached to the VC and powered on. The new switch’s priority value is then used to determine its VC member role based on the mastership election algorithm. You control member ID assignment in this mode by powering up the member switches in the desired order so that each switch receives the next sequential (and desired) member ID. After the fact, you can still use the CLI to alter the membership values.
The member subhierarchy
houses the remaining VC configuration options:
[edit virtual-chassis]
lab@Vodka# set member 0 ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
mastership-priority Member's mastership priority (1..255)
no-management-vlan Disable magagement VLAN
role Member's role
serial-number Member's serial numberHere, you set parameters such as member ID to mastership priority when in non-provisioned mode, or in preprovisioned mode by binding a serial number to either an RE or an LC role. A typical non-provisioned mode configuration is as follows:
[edit virtual-chassis]
lab@Vodka# show
member 0 {
mastership-priority 255;
}
member 1 {
mastership-priority 255;
}
member 2 {
mastership-priority 1;
}Note again that to make the priority values matter you must
control member ID assignment via the power-on sequence or via CLI
commands after things have settled. In this example, members 0 and 1
are the primary REs and member 1
could become an RE only in the event of both members 0 and 1
failing. You cannot assign a 0 priority in non-provisioned mode, which
means all VC members are candidates to become the master RE. Here is a
sample preprovisioned configuration:
[edit virtual-chassis]
lab@Vodka# show
preprovisioned;
member 1 {
role routing-engine;
serial-number BM0208269767;
no-management-vlan;
}
member 0 {
role routing-engine;
serial-number BM0208269834;
}
member 2 {
role line-card;
serial-number BM0208269888;
}The preprovisioned keyword
places the VC into non-default mode, where each member must be
explicitly listed by serial number and allowed role. Priority
assignments are now based on default values for the RE and LC roles. The example forces member 2 to function as an LC with a derived
priority of 0, while members 0 and
1 can be REs. All candidate REs are
assigned the same priority, leading to a non-revertive mode of operation.
The use of a front-panel uplink as a VCE is an optional aspect of a VC design. As noted previously, the rear-panel VCP ports simply work, and accept no user configuration. Anytime you attach cables to these ports, a VC will attempt to form.
By default, an uplink port does not run the VCCP; hence it is
called an “uplink” and not a VCE port. You use the request virtual-chassis vc-port operational
mode command to activate or deactivate VCCP/uplink mode on these
ports:
lab@Vodka# run request virtual-chassis vc-port ?
Possible completions:
delete Delete a member's virtual chassis port
set Set a member's virtual chassis portWhen performed in operational mode, these commands write the VCE port information into the affected switches’ private configuration, where it persists until removed.
While in uplink mode the various ports are indexed as ge-id/1/n, where
id is the switches’ member ID and
n is the port number, which can range from
0 to 3, depending on uplink module type. Once placed into VCE mode,
these same ports are renamed and become vcp-255/1/n, and
the corresponding uplink port device is removed. This process is shown
in the following code for a switch with member ID 0:
lab@Vodka>show interfaces ge-0/1/0 terseInterface Admin Link Proto Local Remote ge-0/1/0 up up ge-0/1/0.0 up up eth-switch lab@Vodka>request virtual-chassis vc-port set pic-slot 1 port 0
Once placed into VCP mode, the previous uplink port is no longer available and a new VCP device is created:
lab@Vodka>show interfaces ge-0/1/0 terseerror: device ge-0/1/0 not found lab@Vodka>show interfaces vcp-255/1/0 terseInterface Admin Link Proto Local Remote vcp-255/1/0 up up vcp-255/1/0.32768 up up
When you plan to use a VCE to attach a new switch to an existing VC, you should power up the new switch and configure both ends of the VCE (one end on the new switch, the other on an existing VC member) before you physically attach the new switch to the VC using the VCE link. This ensures that both ends agree to use VCCP over the shared link, and that proper VC topology discovery and member role determination is performed. Failing to perform these steps may cause master reelection and result in disruption to traffic forwarding until the VC topology stabilizes.
Once a switch is part of a VC, additional VCE ports can be
provisioned or removed through the master RE by adding the desired
member ID to the request virtual-chassis commands. In most cases the
master RE will be member ID 0, but this is not mandatory. When a
member ID is not specified, the local switch is assumed and the
command is performed on the local master RE:
lab@Vodka>request virtual-chassis vc-port set pic-slot 1 port 1 ?Possible completions: <[Enter]> Execute this commandall-membersSet virtual chassis port on all virtual chassis memberslocalSet virtual chassis port on local virtual chassis membermemberSet virtual chassis port on specific virtual chassis member (0..9) . . .
Well, that’s pretty much it; there really isn’t much to configuring a VC. In fact, if determinism is not your bag, you can just plug a bunch of EX4200s together using just about any VCP cabling scheme, and things will just work. With that said, you really should configure a virtual management address, and at a minimum map member IDs to priorities as part of a non-provisioned deployment, to ensure consistency across various reboot scenarios. Once a member is assigned it becomes sticky, meaning that the associated priority remains fixed across reboots and power-downs, which tends to ensure the same master, backup, and LC roles when all members are up and running.
The next section details operational analysis and VC maintenance procedures.
This section details commands and techniques used to perform operational analysis, troubleshooting, or VC moves and changes. The next section demonstrates most of these commands and techniques as part of a VC deployment case study.
To help keep you interested, the material is presented in the
context of a VC discovery task, in which your goal is to
reverse-engineer a VC you know nothing about using only CLI operational
mode show commands. We suggest you
use a sheet of paper to diagram your discoveries as they are made. You
start by displaying the VC configuration:
[edit]
regress@EX4200_VC_demo# show virtual-chassis
[edit]From the preceding code, note that you are dealing with a default
virtual-chassis stanza, and therefore
a non-provisioned deployment scenario. The lack of configuration details
means there is not much more to be learned here, so let’s move along.
Your VC discovery diagram remains largely blank, except that the name of
the VC and its mode of deployment are known.
Several CLI commands support member-specific context when executed in a VC.
Generally speaking, when the member
argument is omitted, the command acts on the local master RE. Adding
the all keyword ensures that a
command runs on all members, and in similar fashion, specifying a
specific member ID constrains the command to that member.
For a complete list of VC member-aware commands, consult the
JUNOS documentation matching the EX software release on your
switch. For Release 9.2, this information is available at http://www.juniper.net/techpubs/en_US/junos9.2/topics/reference/general/virtual-chassis-command-forwarding.html.
Most of the CLI’s request system and
show system commands support the
member keyword. The reboot command is demonstrated:
regress@EX4200_VC_demo >request system reboot ?Possible completions: <[Enter]> Execute this command all-members Reboot all virtual chassis members at Time at which to perform the operation in Number of minutes to delay before operation local Reboot local virtual chassis member media Boot media for next boot member Reboot specific virtual chassis member (0..9) message Message to display to all users other-routing-engine Reboot the other Routing Engine partition Partition on boot media to boot from | Pipe through a command regress@ EX4200_VC_demo >request system reboot member 1Reboot the system ? [yes,no] (no)yesRebooting fpc1 regress@ EX4200_VC_demo >
A show version command runs on all members by default, and is a good
way to confirm software compatibility, as all VC members should run
the same code and members with mismatched software versions are
typically not allowed to actively join the VC:
regress@EX4200_VC_demo>show versionfpc0: -------------------------------------------------------------------- Hostname: EX4200_VC_demo Model: ex4200-48t JUNOS Base OS boot [9.2R1.9] . . . fpc1: -------------------------------------------------------------------- Hostname: -fpc1-BKModel: ex4200-48t JUNOS Base OS boot [9.2R1.9] . .
Notice that fpc1 has
automatically been assigned a hostname that reflects its member ID (1)
and its current VC role of BacKup (BK) RE. From the vacant
configuration and its current backup status, you can deduce that
fpc0 has a higher mastership
priority, was powered on first, has been booted the longest, or simply
has the lowest MAC address, as it has won the master election process.
Further investigation shall reveal the truth.
Your discovery diagram now shows a single VC, with two members, both as candidate masters. You can also add that both VC members are 48-port models, but there’s not much else to be learned here.
The show chassis lcd
command is a fine way to view the information displayed on the EX’s
LCD panel, assuming you are not around to gaze upon its cheery
countenance directly:
regress@EX4200_VC_demo> show chassis lcd fpc-slot 0
Front panel contents for slot: 0
---------------------------------
LCD screen:
00:RE EX4200_VC_
LED:SPD ALARM 00
LEDs status:
Alarms LED: Off
Status LED: Green
Master LED: Green
Interface LED(ADM/SPD/DPX/POE)
-------------------------------------
ge-0/0/0 On:3 blinks per sec
ge-0/0/1 On:3 blinks per sec
. . .The information displayed confirms that slot 0 is the active RE, the model number, and that no alarm-level events have been detected. The port status shows that the port is up, but shows no activity (the first LED is on), and that the port is in 1,000 Mbps mode (three blinks per second).
Use the show virtual-chassis
command to obtain VC-specific information. Given your current task,
this seems a fine place to explore:
regress@EX4200_VC_demo> show virtual-chassis ?
Possible completions:
<[Enter]> Execute this command
active-topology Virtual chassis active topology
member-config Show virtual chassis member configuration from specified member
protocol Show virtual chassis protocol information
status Virtual chassis information
vc-port Virtual chassis port information
| Pipe through a commandNote that the full range of command options is available only at the master RE. Non-RE switches run only a subset of the JUNOS processes, and therefore support a subset of the commands shown here for a master RE. Your discovery proceeds with a display of VC ports:
regress@EX4200_VC_demo> show virtual-chassis vc-port
fpc0:
---------------------------------------------------------------------
Interface Type Status
or
PIC / Port
vcp-0 Dedicated Up
vcp-1 Dedicated Down
fpc1:
---------------------------------------------------------------------
Interface Type Status
or
PIC / Port
vcp-0 Dedicated Up
vcp-1 Dedicated DownThe display tells you a few things. It seems that neither member
has any VCE ports defined, given that only VCP port-related
information is displayed. Also, each member switch is showing a single
VCP port in the Up state, indicating that the two switches are
attached in a serial VCP chain, which in this case is attached to the
VCP 0 port on both members. Additional information is displayed to
confirm that VCCP packets are being sent and received over member
0’s VCP 0 interface:
regress@EX4200_VC_demo> show virtual-chassis vc-port statistics vcp-0 member 0
Member ID: 0 Port: vcp-0
RX TX
Total octets: 20807032 7654180
Total packets: 77187 67757Note that show virtual-chassis
and show virtual-chassis status
commands are synonymous in this release:
regress@EX4200_VC_demo> show virtual-chassis
Virtual Chassis ID: 3f04.fea3.76b3
Mastership Neighbor List
Member ID Status Serial No Model priority Role ID Interface
0 (FPC 0) Prsnt BP0208207200 ex4200-48t 128 Master* 1 vcp-0
1 (FPC 1) Prsnt BP0208207201 ex4200-48t 128 Backup 0 vcp-0
Member ID for next new member: 2 (FPC 2)There’s some real gold here. You see confirmation of member ID
assignment, member operational status, and serial number (handy, as
this information is needed for a preprovisioned deployment); the
mastership priority (set to default for non-provisioned mode); the
member’s role within the VC; and the member’s adjacency status. In
this example, you see that member 0
connects to member 1 using VCP 0,
which meshes nicely with your discoveries to date. Also note that the
master switch plans to assign member ID 2 to the next switch that
successfully joins this VC.
The active-topology switch
displays the results of the VCCP that operates between EX-PFEs to
ensure optimal paths and loop-free switching among all member
switches. The active-topology
option is available only on the master RE because LC members do not
run any switching/routing daemons:
regress@EX4200_VC_demo> show virtual-chassis active-topology
Destination ID Next-hop
1(vcp-0)Wow, this is somewhat of a letdown, especially if you have ever had to wade through the route table of an Internet router sporting several full Border Gateway Protocol (BGP) routing feeds. Still, this is a simple two-node VC with a single interconnection link, and therefore the active topology consists of Switch 0 connected to Switch 1, with a single link, as displayed.
The show virtual-chassis
protocol command has several arguments that help get to the
meat of a VC’s operation:
regress@EX4200_VC_demo> show virtual-chassis protocol ?
Possible completions:
adjacency Show virtual chassis adjacency database
database Show virtual chassis link-state database
interface Show virtual chassis protocol interface information
route Show virtual chassis routing table
statistics Show virtual chassis performance statisticsAs with any LS protocol, displaying adjacency status is always a good place to start when performing operational analysis.
This display shows several VCCP adjacencies, and the good news is they are all up:
regress@EX4200_VC_demo> show virtual-chassis protocol adjacency
fpc0:
------------------------------------------------------------------
Interface System State Hold (secs)
internal-0/24 001f.1234.8842 Up 65535
internal-1/25 001f.1234.8842 Up 65535
internal-2/24 001f.1234.8840 Up 65535
internal-2/27 001f.1234.8841 Up 65535
vcp-0 001f.1234.7dc0 Up 58
]
fpc1:
------------------------------------------------------------------
Interface System State Hold (secs)
internal-0/24 001f.1234.7dc2 Up 65535
internal-1/25 001f.1234.7dc2 Up 65535
internal-2/24 001f.1234.7dc0 Up 65535
internal-2/27 001f.1234.7dc1 Up 65535
vcp-0 001f.1234.8840 Up 58At first glance, this output may seem odd. Where did all these devices and interfaces come from? You can find the answer, in part, in Chapter 3.
Recall that an EX4200-48 comprises three EX-PFEs, with each PFE dividing the work associated with front-panel, uplink, and VC ports. Each PFE has an internal device ID and an associated MAC address that serves as its VCCP system ID. By default, the EX itself is represented by the lowest-numbered PFE, which effectively functions as the DIS for the internal LAN connections.
Each PFE has both internal links and external links to other
PFEs, with the latter in the form of VCE or VCP ports. Looking in
detail at fpc0, we see a total of
five adjacencies, only one of which is to an external PFE, in this
case reachable over the VCP-0 port.
The remaining adjacencies must therefore represent internal PFE
connections, and in fact this is found to be the case given the
internal interface designations.
Although you could make some discovery diagram updates based on
the adjacency information, you opt to take the next analysis step by
displaying the VCCP LSDB. In this example, the LSDB is displayed for
switch member 1 only; given that
all members have an identical LSDB when things are working, it should
not matter which copy you view:
regress@EX4200_VC_demo> show virtual-chassis protocol database member 0
fpc0:
----------------------------------------------------------------------
LSP ID Sequence Checksum Lifetime
001f.1234.7dc0.00-00 0xa7c 0xe1e9 116
001f.1234.7dc1.00-00 0x31b 0xb393 114
001f.1234.7dc2.00-00 0x315 0xaceb 115
001f.1234.8840.00-00 0xa6e 0x701c 117
001f.1234.8841.00-00 0x31b 0x869c 111
001f.1234.8842.00-00 0x318 0x4d99 112
6 LSPsThe results show there are six LSPs. This makes sense, given
that there are six EX-PFEs in this VC, and each runs a VCCP instance,
and therefore each forms adjacencies with its neighbor PFEs and floods
LSPs as a result. Based on this information, your VC discovery diagram
begins to take the shape of a network consisting of two LAN segments
(one per member switch), each with three VCCP entities (one per
EX-PFE), which are in turn connected by a serial link (VCP-0).
The extensive switch is used
to display as much VCCP LSDB information as Juniper sees fit to make
available. The display is taken from member 1, in part to show it has the same database
entries as did member 0.
Note that some TLVs are not completely decoded.... How mysterious!
regress@EX4200_VC_demo>show virtual-chassis protocol database extensive member 1| no-morefpc0: ---------------------------------------------------------------------001f.1234.7dc0.00-00Sequence: 0xa3a, Checksum: 0x49ed, Lifetime: 117 secs Neighbor: 001f.1234.7dc2.00 Interface: internal-0/24 Metric: 10 Neighbor: 001f.1234.8840.00 Interface: vcp-0 Metric: 10 Header: LSP ID: 001f.1234.7dc0.00-00, Length: 356 bytes Allocated length: 1492 bytes, Remaining lifetime: 117 secs, Interface: 0 Estimated free bytes: 1075, Actual free bytes: 1136 Aging timer expires in: 117 secs Packet: LSP ID: 001f.1234.7dc0.00-00, Length: 356 bytes, Lifetime : 118 secs Checksum: 0x49ed, Sequence: 0xa3a, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes Packet type: 18,SW version: 9.2TLVs: Node Info: Member ID: 1, VC ID: 3f04.fea3.76b3, Flags: 1, Priority: 128 System ID: 001f.1234.7dc0, Device ID: 3 System ID: 001f.1234.7dc1, Device ID: 4 System ID: 001f.1234.7dc2, Device ID: 5 Neighbor Info: 001f.1234.7dc2.00, Interface: internal-0/24, Metric: 10 Neighbor Info: 001f.1234.8840.00, Interface: vcp-0, Metric: 10 Unknown TLV, Type: 24, Length: 1 Unknown TLV, Type: 28, Length: 112 No queued transmissions 001f.1234.7dc1.00-00 Sequence: 0x307, Checksum: 0x1deb, Lifetime: 111 secs Neighbor: 001f.1234.7dc2.00 Interface: internal-1/25 Metric: 10 Header: LSP ID: 001f.1234.7dc1.00-00, Length: 195 bytes Allocated length: 1492 bytes, Remaining lifetime: 111 secs, Interface: 0 Estimated free bytes: 1233, Actual free bytes: 1297 Aging timer expires in: 111 secs Packet: LSP ID: 001f.1234.7dc1.00-00, Length: 195 bytes, Lifetime : 118 secs Checksum: 0x1deb, Sequence: 0x307, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes Packet type: 18, SW version: 9.2 TLVs: Node Info: Member ID: 1, VC ID: 3f04.fea3.76b3, Flags: 1, Priority: 128 System ID: 001f.1234.7dc0, Device ID: 3 System ID: 001f.1234.7dc1, Device ID: 4 System ID: 001f.1234.7dc2, Device ID: 5 Neighbor Info: 001f.1234.7dc2.00, Interface: internal-1/25, Metric: 10 No queued transmissions 001f.1234.7dc2.00-00 Sequence: 0x301, Checksum: 0x1644, Lifetime: 111 secs Neighbor: 001f.1234.7dc0.00 Interface: internal-2/24 Metric: 10 Neighbor: 001f.1234.7dc1.00 Interface: internal-2/27 Metric: 10 Header: LSP ID: 001f.1234.7dc2.00-00, Length: 239 bytes Allocated length: 1492 bytes, Remaining lifetime: 111 secs, Interface: 0 Estimated free bytes: 1188, Actual free bytes: 1253 Aging timer expires in: 111 secs Packet: LSP ID: 001f.1234.7dc2.00-00, Length: 239 bytes, Lifetime : 118 secs Checksum: 0x1644, Sequence: 0x301, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes Packet type: 18, SW version: 9.2 TLVs: Node Info: Member ID: 1, VC ID: 3f04.fea3.76b3, Flags: 1, Priority: 128 System ID: 001f.1234.7dc0, Device ID: 3 System ID: 001f.1234.7dc1, Device ID: 4 System ID: 001f.1234.7dc2, Device ID: 5 Neighbor Info: 001f.1234.7dc0.00, Interface: internal-2/24, Metric: 10 Neighbor Info: 001f.1234.7dc1.00, Interface: internal-2/27, Metric: 10 No queued transmissions001f.1234.8840.00-00Sequence: 0xa2e, Checksum: 0xaa09, Lifetime: 116 secs Neighbor: 001f.1234.7dc0.00 Interface: vcp-0 Metric: 10 Neighbor: 001f.1234.8842.00 Interface: internal-0/24 Metric: 10 Header: LSP ID: 001f.1234.8840.00-00, Length: 542 bytes Allocated length: 542 bytes, Remaining lifetime: 116 secs, Interface: 26 Estimated free bytes: 42, Actual free bytes: 0 Aging timer expires in: 116 secs Packet: LSP ID: 001f.1234.8840.00-00, Length: 542 bytes, Lifetime : 118 secs Checksum: 0xaa09, Sequence: 0xa2e, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes Packet type: 18, SW version: 9.2 TLVs: Node Info: Member ID: 0, VC ID: 3f04.fea3.76b3, Flags: 3, Priority: 128 System ID: 001f.1234.8840, Device ID: 0 System ID: 001f.1234.8841, Device ID: 1 System ID: 001f.1234.8842, Device ID: 2 Neighbor Info: 001f.1234.8842.00, Interface: internal-0/24, Metric: 10 Neighbor Info: 001f.1234.7dc0.00, Interface: vcp-0, Metric: 10 Master Info: System ID: 001f.1234.8840 Backup Info: System ID: 001f.1234.7dc0 Member Info: System ID: 001f.1234.7dc0, Member ID: 1 Member role: Backup System ID: 001f.1234.7dc0, Device ID: 3 System ID: 001f.1234.7dc1, Device ID: 4 System ID: 001f.1234.7dc2, Device ID: 5 Member Info: System ID: 001f.1234.8840, Member ID: 0 Member role: Master System ID: 001f.1234.8840, Device ID: 0 System ID: 001f.1234.8841, Device ID: 1 System ID: 001f.1234.8842, Device ID: 2 Unknown TLV, Type: 24, Length: 1 Unknown TLV, Type: 28, Length: 112 No queued transmissions 001f.1234.8841.00-00 Sequence: 0x308, Checksum: 0x11cd, Lifetime: 111 secs Neighbor: 001f.1234.8842.00 Interface: internal-1/25 Metric: 10 Header: LSP ID: 001f.1234.8841.00-00, Length: 195 bytes Allocated length: 284 bytes, Remaining lifetime: 111 secs, Interface: 26 Estimated free bytes: 89, Actual free bytes: 89 Aging timer expires in: 111 secs Packet: LSP ID: 001f.1234.8841.00-00, Length: 195 bytes, Lifetime : 118 secs Checksum: 0x11cd, Sequence: 0x308, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes Packet type: 18, SW version: 9.2 TLVs: Node Info: Member ID: 0, VC ID: 3f04.fea3.76b3, Flags: 3, Priority: 128 System ID: 001f.1234.8840, Device ID: 0 System ID: 001f.1234.8841, Device ID: 1 System ID: 001f.1234.8842, Device ID: 2 Neighbor Info: 001f.1234.8842.00, Interface: internal-1/25, Metric: 10 No queued transmissions 001f.1234.8842.00-00 Sequence: 0x305, Checksum: 0xfaa2, Lifetime: 115 secs Neighbor: 001f.1234.8840.00 Interface: internal-2/24 Metric: 10 Neighbor: 001f.1234.8841.00 Interface: internal-2/27 Metric: 10 Header: LSP ID: 001f.1234.8842.00-00, Length: 239 bytes Allocated length: 284 bytes, Remaining lifetime: 115 secs, Interface: 26 Estimated free bytes: 45, Actual free bytes: 45 Aging timer expires in: 115 secs Packet: LSP ID: 001f.1234.8842.00-00, Length: 239 bytes, Lifetime : 118 secs Checksum: 0xfaa2, Sequence: 0x305, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes Packet type: 18, SW version: 9.2 TLVs: Node Info: Member ID: 0, VC ID: 3f04.fea3.76b3, Flags: 3, Priority: 128 System ID: 001f.1234.8840, Device ID: 0 System ID: 001f.1234.8841, Device ID: 1 System ID: 001f.1234.8842, Device ID: 2 Neighbor Info: 001f.1234.8840.00, Interface: internal-2/24, Metric: 10 Neighbor Info: 001f.1234.8841.00, Interface: internal-2/27, Metric: 10 No queued transmissions
The display is rather long, but also largely repetitive. We
highlighted the key points. For example, within each switch, the PFE
with the lowest MAC address serves as the primary system ID. For
switch member 0, this is 001f.1234.8840, which is lower than both
001f.1234.8841 and 001f.1234.8842. This PFE acts as the DIS for
the internal network by advertising the list of internal device (PFE)
IDs along with their adjacent neighbors. The master RE places
additional information into its LSPs that details the role of each VC
member. This information represents the results of mastership
election, and is used to confirm how each member switch should
operate. Each LSP also reports the software version that it’s running.
This information is used to detect software incompatibilities among VC
members.
Figure 4-15 represents the result of your VC discovery exercise.
Considering that no details were originally provided, it’s clear
you can learn a lot about a VC’s operation (or lack thereof when it’s
broken), using the provided CLI commands and tracing tools. Figure 4-15 shows that switch member 0 is the master, and that it contains three
EX-PFEs. The lowest-numbered PFE MAC address is used as the system
identifier, and is shown in the truncated form of 8840. Each internal link, which is numbered
based on PFE ID, has a pair of adjacent PFEs, which accounts for four
of the five adjacencies shown within each switch. The fifth adjacency
is via the external VCP0 connection
to member 1.
The LSDB information indicates that member 0 is the current master and member 1 is a backup master. Similar information is
deduced for switch member 1, using
the same combination of CLI commands and LSDB analyses. Based on the
number of LSPs generated by member 1, you can conclude that it is a three-PFE
system, for example. This information allows the complete VC internal
topology to be documented in Figure 4-15.
Tracing the operation of a VC is an excellent way to learn more about its operation and to troubleshoot problems when things don’t go according to plan. The discovery VC is updated with the following tracing configuration:
[edit]
regress@EX4200_VC_demo# show virtual-chassis
traceoptions {
file vc_trace;
flag hello;
flag lsp;
flag me;
flag error;
flag psn;
flag csn;
}In the trace config, the me
flag traces master election. The error flag should call out any errors, and
the hello, lsp, and sequence number (psn/csn)
flags result in tracing hello packet exchanges, LSP flooding, and
sequence number exchanges, respectively. Note that in IS-IS, DIS and
non-DIS nodes periodically send CSN and PSN packets (respectively) to
perform LSP acknowledgment.
After committing, the vc_trace logfile is monitored as
the virtual-chassis
process is restarted, which is a good way to shake VC things
up:
regress@EX4200_VC_demo>monitor start vc_traceregress@EX4200_VC_demo>restart virtual-chassis-control*** vc_trace *** Oct 5 14:35:28.207928 TASK_SIGNAL_TERMINATE: first termination signal received Oct 5 14:35:28.208897 Oct 5 14:35:28.208897 VCCPD_PROTOCOL_ADJDOWN: Lost adjacency to 001f.1234.8842 on internal-0/24, . . . Oct 5 14:35:28.514872vccpd_provision_cfg_apply: pre_provisioned_cfg 0. . . Oct 5 14:35:28.517918VCCPD_PROTOCOL_ADJUP: New adjacency to 001f.1234.8842 oninternal-0/24Oct 5 14:35:28.517918 Oct 5 14:35:28.518292 Oct 5 14:35:28.518292 VCCPD_PROTOCOL_ADJUP: New adjacency to 001f.1234.8841 on internal-2/27 Oct 5 14:35:28.518292 Oct 5 14:35:28.518700 Oct 5 14:35:28.518700 VCCPD_PROTOCOL_ADJUP: New adjacency to 001f.1234.8840 on internal-2/24 . . . Oct 5 14:35:28.525734Sending PTP IIHon vcp-0.32768 Oct 5 14:35:28.525787 packet length 1492 Oct 5 14:35:28.527487Received PTP IIH, source id 001f.1234.7dc0 on vcp-0.32768 Oct 5 14:35:28.527620 Sending PTP IIH on vcp-0.32768 Oct 5 14:35:28.527663 packet length 1492 Oct 5 14:35:28.528845 Received PTP IIH, source id 001f.1234.7dc0 on vcp-0.32768 Oct 5 14:35:28.529222 . . . Oct 5 14:35:28.547225isis_install_lsp: starting me link electionOct 5 14:35:28.547282 vccpd_run_me_link_election: found 1 members Oct 5 14:35:28.547304 member: id 0, role 5, link 0, me_ifl 0, bme_ifl 0 Oct 5 14:35:28.547376 vccpd_run_me_link_election: me_link_owner is 65535 Oct 5 14:35:28.547399 vccpd_run_me_link_election: my member role 5 . . .
The truncated output shows the detection of a non-provisioned
installation, the formation of new adjacencies, and the exchange of
VCCP hello packets, which are displayed as IIH (which stands for Intermediate System to
Intermediate System Hello, by the way). The capture also shows the
beginnings of the chassis mastership election process. The mastership
election process is traced with all other flags removed to reduce
clutter. Recall that at the time the VC process was restarted,
FPC0 was acting as the backup
RE:
. . . Oct 5 14:49:44.261942 vccpd_run_me_link_election: found 1 members Oct 5 14:49:44.262000 member: id 0, role 5, link 0, me_ifl 0, bme_ifl 0 Oct 5 14:49:44.262019 vccpd_run_me_link_election: me_link_owner is 65535 Oct 5 14:49:44.262040 vccpd_run_me_link_election: my member role 5 Oct 5 14:49:44.293543 isis_run_me Oct 5 14:49:44.293604 isis_run_me: starting exit_vc_mode_startup timer Oct 5 14:49:44.293636 exit_vc_mode_startup timer running, exit ME Oct 5 14:49:44.348031 vccpd_run_me_link_election: found 1 members Oct 5 14:49:44.348089 member: id 0, role 5, link 0, me_ifl 0, bme_ifl 0 Oct 5 14:49:44.348109 vccpd_run_me_link_election: me_link_owner is 65535 Oct 5 14:49:44.348129 vccpd_run_me_link_election: my member role 5 Oct 5 14:49:44.348363 vccpd_run_me_link_election: found 1 members Oct 5 14:49:44.348390 member: id 0, role 5, link 0, me_ifl 0, bme_ifl 0 Oct 5 14:49:44.348409 vccpd_run_me_link_election: me_link_owner is 65535 Oct 5 14:49:44.348428 vccpd_run_me_link_election: my member role 5 Oct 5 14:49:44.348660 vccpd_run_me_link_election: found 1 members Oct 5 14:49:44.348687 member: id 0, role 5, link 0, me_ifl 0, bme_ifl 0 Oct 5 14:49:44.348706 vccpd_run_me_link_election: me_link_owner is 65535 Oct 5 14:49:44.348725 vccpd_run_me_link_election: my member role 5 Oct 5 14:49:44.404440 isis_run_me Oct 5 14:49:44.404499 exit_vc_mode_startup timer running, exit ME Oct 5 14:50:24.293693isis_exit_vc_mode_startup: mastership mode tovc_mode_line_card
At this time, FPC0 has
returned to the default LC role, where it waits to determine whether
any master REs are present:
regress@EX4200_VC_demo>show virtual-chassisVirtual Chassis ID: 3f04.fea3.76b3 Mastership Neighbor List Member ID Status Serial No Model priority Role ID Interface 0 (FPC 0) Prsnt BP0208207200 ex4200-48t 128Linecard*
The tracing continues:
Oct 5 14:50:24.294832isis_run_meOct 5 14:50:24.294889 001f.1234.7dc0.00 selected as master Oct 5 14:50:24.295008 001f.1234.8840.00 selected as backup Oct 5 14:50:24.295034 001f.1234.7dc0.00 over 001f.1234.8840.00 vc_mode_master 1>5 Oct 5 14:50:24.295058 001f.1234.7dc0.00 over 001f.1234.8840.00 vc_mode_master 1>5 Oct 5 14:50:24.295162 Assignment: role-2, mid-0, devs-3, devid1-0, devid2-1 Oct 5 14:50:24.295193mastership mode changed from line_card to backupOct 5 14:50:24.295291 isis_run_me: starting me link election Oct 5 14:50:24.295321 vccpd_run_me_link_election: found 2 members Oct 5 14:50:24.295342 member: id 1, role 1, link 1, me_ifl 0, bme_ifl 0 Oct 5 14:50:24.295362 member: id 0, role 5, link 0, me_ifl 0, bme_ifl 0 Oct 5 14:50:24.295381 vccpd_run_me_link_election: me_link_owner is 1 Oct 5 14:50:24.295401 vccpd_run_me_link_election: my member role 5 Oct 5 14:50:24.396111 isis_run_me Oct 5 14:50:24.396204 001f.1234.7dc0.00 selected as master Oct 5 14:50:24.396231 001f.1234.8840.00 selected as backup . . .
At the end, FPC0 transitions
from LC to backup RE role; given that the current master RE never
restarted, its uptime was higher, and therefore it was not preempted.
Had both FPCs restarted, the result would be the same, as the
tiebreaker is the lowest MAC address, which again favors FPC0 in this example.
Maintaining a VC is much like maintaining a standalone router or switch. As
noted previously, many operational commands have a member context to allow execution on one or
all VC members.
When performing a reboot or shutdown operation, you should factor the potential effects of mastership transitions in the event of only some VC members being rebooted. As a general rule, it’s always best to reboot or shut down all members of a VC at the same time, especially when not using a preprovisioned mode:
lab@Vodkila>request system halt all-memberswarning: This command will halt all the members. If planning to halt only one member use the member option Halt the system ? [yes,no] (no)yesHalting fpc0 *** FINAL System shutdown message from lab@Vodkila *** System going down IMMEDIATELY *** FINAL System shutdown message from lab@Vodkila *** System going down IMMEDIATELY Shutdown NOW! [pid 677]
You can perform software upgrades or downgrades on selected
members by adding the appropriate member switch to the request system software command. Future releases may offer automatic software
download to members with a mismatched version. In the current release,
the user is responsible for ensuring version compatibility:
regress@EX4200_VC_demo>request system software add jinstall-ex-9.2R1.9-domestic-signed.tgz member ?Possible completions: <member> Install package on VC Member (0..9) regress@EX4200_VC_demo>...install-ex-9.2R1.9-domestic-signed.tgz member 1Pushing bundle to fpc1 WARNING: A reboot is required to install the software WARNING: Use the 'request system reboot' command immediately
There are a few scenarios where a VC member switch may be removed from the VC. In some cases, the switch is taken away, never to return, resulting in a smaller VC. In other cases, a switch may be removed temporarily—for example, to have repair actions performed after a hardware failure. In yet other cases, one member switch may be replaced with a different switch—for example, swapping out a 24-port model with a 48-port version.
In all of these cases, you should understand the default member ID assignment function, and how CLI commands are used to alter and control member IDs. By default, a switch member writes its ID into a private area of its configuration, and this value is retained through removal and reinsertion events. To prevent conflicts, the master RE retains a list of all assigned values and assigns the next highest available value when a new switch joins the VC.
Use the request virtual-chassis
recycle command when a switch is removed from a VC to free
up a previously assigned member ID, thus making it available for use
by another switch. Use the request virtual-chassis
renumber command to change a member’s current assignment to
a new value; an error is returned if the new value is currently in
use.
It’s a best practice to assign member ID 0 to the primary master RE, and then number all switches sequentially
based on their vertical or horizontal placement relative to member
0. If you assume a three-member VC,
you would thus have switch IDs 0,
1, and 2 assigned.
If switch member 1 is to be
removed from the VC for good, you perform these actions, which are not
disruptive to the VC’s overall operation:
Power down and remove Switch 1 (the second switch). Adjust the cabling to account for its loss.
Use the
request virtual-chassis renumber member-id 2 new-member-id 1command to maintain best-practice sequential numbering.
Note that as a result of a member ID change, you will need to update the master’s interface configuration to reflect the new member ID, which recalls functions such as the FPC component in a traditional JUNOS interface name. The CLI conveniently warns the user of this necessity, and even offers sample syntax to make the job easier:
lab@switch>request virtual-chassis renumber member-id 1 new-member-id 2To move configuration specific to member ID 1 to member ID 2, please use the replace command. e.g. replace pattern ge-1/ with ge-2/ Do you want to continue ? [yes,no] (no)no
Note
In typical JUNOS software fashion, you can configure interfaces that relate to a VC switch member that has not yet been attached. Such a configuration is simply ignored until the related hardware is present, at which point the related configuration is activated.
To replace switch member 1
with a new switch that is intended to take over its role in the VC,
perform the following steps:
Power down and remove Switch 1 (the second switch).
Load the default config on the replacement switch, power it down, and attach it to the VC.
Apply power to the new switch. The new switch receives the next available member ID, which will be
3in this example. Use therequest virtual-chassis renumber member-id 3 new-member-id 1command to reassign the member ID to1, the value that is associated with the switch being replaced.
You can use the request session
member <id> command to
connect to a non-master switch member using an internal communications
path. This command operates regardless of whether you have configured
the no-management-vlan option for
that member switch. This capability can be useful when you are
troubleshooting an issue with a specific VC member and wish to view
its private configuration or view its local operational status.
In most cases, you will assign a virtual management address that
redirects your session from any management port to the VC’s current
master. You can alter this behavior and assign explicit me0 OoB management addresses to the master
and backup REs so that you can access each simultaneously. Note that
configuring the me0 interface
disables the vme0
functionality.
In either case, you may want to access the OoB port of an LC
member without having to connect to the master and then request a
session. This capability is also useful during VC communications
failures that may prevent you from connecting through the master
switch. In addition to specifying the no-management-vlan
option for the desired member, you must also access a root shell on
the desired member switch so that you can assign an IP address to
the me0 interface using
the ifconfig command.
Note that in the current release you cannot use the CLI to assign an
me0 address to an LC member in a VC. Although this procedure also works
for a backup RE, it’s not needed because you can use the CLI on a
master or backup master to assign an me0 address.
The process is demonstrated here, but is performed on a backup RE as the demonstration VC has only two members, and neither is in the LC role:
[edit virtual-chassis] regress@EX4200_VC_demo#set member 1 no-management-vlan[edit virtual-chassis] regress@EX4200_VC_demo#showmember 1 { no-management-vlan; } [edit virtual-chassis] regress@EX4200_VC_demo#commit synchronizefpc0: configuration check succeeds fpc1: commit complete fpc0: commit complete
You start by placing the no-management-vlan option into effect for
member 1. Note the use of commit synchronize
to push the change to other members, in this case member 1. Next, request a session to member
1. Note that you cannot use the
console to perform this operation because of virtual console
redirection, which places you right back at the master, unless a
communications problem prevents the redirection, in which case you are
presented with a local login prompt:
[edit virtual-chassis] regress@EX4200_VC_demo#run request session member 1€ --- JUNOS 9.2R1.9 built 2008-08-05 07:25:22 UTC regress@EX4200_VC_demo-fpc1-BK> show interfaces terse me0 Interface Admin Link Proto Local Remote me0 up up me0.0 up up eth-switch regress@EX4200_VC_demo-fpc1-BK>show interfaces terse vme0error: device vme0 not found
Once you are connected, the CLI confirms that no me0 or vme0 interface address is currently
assigned. To run ifconfig, you must
access a root shell:
regress@EX4200_VC_demo-fpc1-BK>start shell%suPassword:
As root, the ifconfig command
is used to assign and then display an IPv4 address to the me0 device:
root@EX4200_VC_demo-fpc1-BK%ifconfig me0.0 add inet 172.69.16.6 netmask255.255.255.0root@EX4200_VC_demo-fpc1-BK%ifconfig me0me0: encaps: ether; framing: ether flags=0x3/0x8000 <PRESENT|RUNNING> curr media: i802 0:1f:12:34:7e:3e me0.0: flags=0x8000 <UP|MULTICAST> inet primary mtu 1500 local=172.69.16.6 dest=172.69.16.0/24 bcast=172.69.16.255 <unknown> primary mtu 0 root@EX4200_VC_demo-fpc1-BK%exit%exit
The root shell is exited and the CLI at member 1 confirms that the address is in
effect:
regress@EX4200_VC_demo-fpc1-BK>show interfaces me0Physical interface: me0, Enabled, Physical link is Up Interface index: 1, SNMP ifIndex: 33 Type: Ethernet, Link-level type: Ethernet, MTU: 1514, Speed: 100mbps . . . Addresses, Flags: Is-Preferred Is-Primary Destination: 172.69.16/24,Local: 172.69.16.6, Broadcast: 172.69.16.255 Protocol eth-switch, MTU: 0 Flags: Is-Primary
The result of all this is the ability to telnet or SSH directly
to VC member 1 using the assigned
172.16.69.6 address. Once you are connected, the lack of management
VLAN prevents redirection to the current master RE, thereby allowing
you to work on the member switch directly. Generally speaking, this
capability is used for specific troubleshooting or fault isolation
procedures. For example, if a new JUNOS software bundle cannot be
pushed from the master RE to some switch member using the internal
communications paths, perhaps due to a software version issue, you may
need to FTP a matching software bundle directly to a switch member.
Without the no-management-vlan
option, you can FTP only to the active or backup REs, and this is
possible only when you are not using a virtual
management interface. When you are using a virtual management
interface, you can FTP only to the active RE.
The EX4200 VC does not require any explicit configuration to just work, out of the box, so to speak. The use of uplink ports as a VC extension does require explicit configuration, however. There are two main options when deploying a VC: the non-provisioned and preprovisioned modes. The former, which can use a factory default, can also include a member ID to priority mapping, which, given the sticky nature of member IDs, helps to promote stability of the original VC configuration through reboots and power-down events.
The current best practice is to use preprovisioned mode, which explicitly maps member serial numbers to a desired VC role. This mode provides maximum determinism, and also security, in that a switch must be preconfigured as a member before it is allowed to actively join the VC.
The operation and maintenance of a VC is much like that of any standalone EX, which is the beauty of the design. Various operational mode commands exist to specifically monitor and control VC operation, and many support a member context to allow global versus targeted actions.
The next section combines the information we’ve covered to this point as part of a VC deployment case study involving the book’s topology.
Get JUNOS Enterprise Switching now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
