This section combines the information we’ve covered thus far in the form of a practical VC deployment case study based on the book’s topology. Here are the design requirements:
Rename Switch 3,
Vodka, toVodkila, to reflect the impending merger of the two previously standalone switch names.Assign 172.16.69.34/24 to the OoB interface; ensure that incoming Telnet and console connections to any switch members are redirected to the current VC master.
Switch 3 and Switch 4 share a closet; the third member is located in a remote closet.
Ensure that Switch 3 and Switch 4 can function as the master RE in a non-revertive manner.
Ensure that the third VC member functions as an LC whenever either or both Switch 3 and Switch 4 are operational.
Assign Switch 3 and Switch 4, and the new VC member IDs 0, 1, and 2, respectively.
Ensure that no additional switches can join the VC without management intervention.
The design must have no single point of VC failure, and the loss of any VC trunk should not prevent ongoing communications.
You may need the following information to complete your task:
All three VC member switches have a 4×1 GE uplink module installed.
The EX4200 serial numbers are:
Switch 3 = BM0208269780
Switch 4 = BM0208269767
Third VC member = BM0208269780
Figure 4-16 shows the before and after topologies.
In this example, the VC deployment occurs in two phases. Phase 1
combines the two existing switches, Vodka and Tequila, into the mythical Vodkila, and phase 2 brings in a third VC member
that is housed in a remote closet. Note how the interface names change on
switch member 1 to reflect its shift
from a standalone VC with member ID 0 to member ID 1. Except for LLDP
updates that report the connected peer’s interface name change, there is
minimal disturbance to the surrounding switches. The same level of
connectivity is maintained, and for the most part things just get simpler,
given that there is one less bridge/router in the network to generate
protocol updates and to contend for the role of designated bridge.
Combining the two switches may result in changes to the spanning
tree forwarding topology, especially if either Switch 3 or Switch 4 is the
current designated bridge. Regardless, the nature of Layer 2 forwarding
and its propensity to form loops means there will be fewer forwarding or
root bridge ports in the “after” topology. For example, assuming that
Whiskey is the current root bridge,
before the merge Switch 3 and Switch 4 have a root port that can forward
toward the root. After the merge the combined VC has a single root port;
assuming default parameters, this will be either the ge-0/0/3 or the ge-0/0/4 interface. Despite the potential for
some reduction in the aggregate number of forwarding ports, the VC
provides many administrative gains, and if desired the physical topology
could be altered to provide added capacity, likely in the form of an
aggregated bundle. In fact, with the addition of AE bundles, more capacity
can be easily attached.
Note that in Layer 3 mode the redundant links can still be used and the ability to load-balance means there is little net effect to forwarding capacity. This is yet another reason router geeks are prone to saying, “Bridge when you must and route when you can.”
Before rolling out the VC bandwagon, there are a few things you should do to ensure a smooth migration:
Back up both standalone switch configurations to a remote location.
Return one of the switches to a factory-default configuration, and power off.
Attach VCP cables.
The first step is just a good practice and is pretty much common sense. After the merge, you will need to modify the interface assignments in one of the switches to match its new member ID. The master switch overwrites the public configuration portion of all VC members, resulting in loss of the original configuration. Lastly, the master could (in some future release) automatically push a new JUNOS install image into any members with a mismatched software version. The install process may only attempt to save SSH keys from the original configuration, so be sure to move anything you plan to keep to safe storage off the EX device itself.
In this example, the OoB is used to quickly copy a saved
configuration from Vodka to an FTP
server. The same process is performed at Tequila, but is not shown:
[edit] lab@Vodka#save Vodka_pre_vc_configWrote 172 lines of configuration to 'Vodka_pre_vc_config' [edit] lab@Vodka#run file copy Vodka_pre_vc_configftp://instructor:training1@ftp_server/juniper/vodka_l3_vcftp://instructor:training1@ftp_server/juniper/100% of 3346 B 917 kBps
Note
In case you’re curious, a static host mapping is configured to allow use of the hostname:
[edit]
lab@Vodka# show system static-host-mapping
ftp_server inet 172.16.69.254;Next, you load and commit a factory default on Tequila. Given that root is
the only user in the new config, you log out as user lab, so you can return as
root to perform a graceful shutdown (the non-existent
lab user is no longer permitted to
perform this operation):
lab@Tequila>configureEntering configuration mode [edit] lab@Tequila#load factory-defaultwarning: activating factory configuration [edit] lab@Tequila#set system root-authentication plain-text-passwordNew password: Retype new password: [edit] lab@Tequila#commit and-quitcommit complete Exiting configuration mode lab@Tequila>quitlogin:Amnesiac(ttyu0) root@% root@%rootroot@% OS 9.0R2.10 built 2008-03-06 10:31:45 UTC root@%cliroot>request system haltHalt the system ? [yes,no] (no)yes*** FINAL System shutdown message from root@ *** System going down IMMEDIATELY Shutdown NOW! [pid 1198] . . .
Though not easy to show in this book, the final preparation step is the attachment of the VCP cables between Switch 3 and Switch 4. Given the redundancy aspects of the design, and their close proximity, you opt for a VCP ring. In this case, there is no merit to any particular VCP cabling scheme, as distance is not an issue and all VCP ports operate the same. As a result, you end up attaching the VCP 0 port of both switches with one VCP cable, and their VCP 1 ports with the other.
Preparation is complete; you are now ready to actually deploy the VC!
Now the fun can officially start. Your first configuration choice is to perform a non-provisioned versus a preprovisioned installation. Thinking back, the choice is clear given the requirement that no switch be allowed to join the VC without management action. The non-provisioned mode does not offer you the ability to list allowed members by serial number, and will therefore allow any switch with compatible software into the VC. So, preprovisioned it is.
The preprovisioned mode allows you to explicitly bind each
member’s serial number with a VC member ID and VC role, which is just
the ticket here. This helps to ensure that you also meet the stated
member ID requirements, which will no longer be based on VC attachment
sequence. This mode also handles priority based on role, taking care of
the requirement that member 3 must be
an LC when either member 1 or member
2 is acting as the master RE.
The first step is to assign the new hostname:
lab@Vodka>configureEntering configuration mode [edit] lab@Vodka#set system host-name Vodkila
The next configuration task removes the standalone me0 OoB management interface configuration to
replace it with a virtual one that is shared among REs. You configure
the vme interface as though it were
any other interface, but currently there is no VLAN encapsulation and
you must use unit 0:
[edit interfaces] lab@Vodka#show me0unit 0 { family inet { address 172.16.69.3/24; } } [edit interfaces] lab@Vodka#delete me0
With the physical me0 interface
out of the way, you are clear to add the vme configuration. Note that committing with
both prevents the virtual interface from being created:
[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; } }
Note
Rather than deleting the me0
and adding a new vme, you might
consider using the CLI’s rename
function. After renaming me0 to
vme you will likely have to
reassign the IP address, an operation that can also be performed using
rename.
Next, position yourself at the [edit
virtual-chassis] hierarchy to begin configuration of the
VC-specific parameters:
[edit interfaces] lab@Vodka#top edit virtual-chassis[edit virtual-chassis] lab@Vodka#set preprovisioned
The preprovisioned statement
does what it says, and once in this mode you must list each member that
is allowed to join the VC by its serial number, which is then mapped to
an ID and VC role. You start with the current switch, Vodka, because it’s supposed to be assigned ID
0, and because it’s the only VC member currently powered on. As
previously explained, this switch is already the master of its one-VC
domain using ID 0. Because you will assign this switch an RE role, and
because it’s been powered up first, expect this switch to
remain as master once construction of the new
Vodkila is complete.
The definition for switch member 0 is added:
[edit virtual-chassis] lab@Vodka#set member 0 role routing-engine[edit virtual-chassis] lab@Vodka#set member 0 serial-number BM0208269834[edit virtual-chassis] lab@Vodka#showpreprovisioned; member 0 { role routing-engine; serial-number BM0208269834; }
That was pretty straightforward, so you move on to complete the definition for member ID 1. The updated configuration is displayed:
[edit virtual-chassis] lab@Vodka#set member 1 role routing-engine serial-number BM0208269766[edit virtual-chassis] lab@Vodka#showpreprovisioned; member 0 { role routing-engine; serial-number BM0208269834; } member 1 { role routing-engine; serial-number BM0208269766; }
Happy with your work, you decide to commit the changes. Before
doing so, add the commit synchronize
option so that all commit events are treated as though the synchronize switch was
included. Recall that in any dual-RE configuration it’s recommended that
you always synchronize the configuration at every commit, for obvious
reasons. As a rule, if you do not have a specific need to maintain
distinctly different configs on the master and backup REs, don’t. Note
that NSR/Non-Stop Bridging support mandates this option, but general
GRES and/or protocol GR does not:
[edit virtual-chassis] lab@Vodka# top [edit] lab@Vodka#set system commit synchronize[edit] lab@Vodka#commit and-quiterror: Could not connect to fpc-1 : Can't assign requested address warning: Cannot connect to other RE, ignoring it commit complete
The commit warning is expected; given that only member 0 is powered up, the attempt to synchronize
the configuration to non-existent VC members is in vain, and fails
accordingly. Before powering up Switch 4, you quickly access VC status
at member 0:
lab@Vodkila>show virtual-chassisPreprovisioned Virtual Chassis Virtual Chassis ID: 001f.123d.b4c0 Mastership Neighbor List Member ID Status Serial No Model priority Role ID Interface0 (FPC 0) Prsnt BM0208269834 ex4200-24t 129 Master*
The VC status is as expected. One switch is up; it’s the current master RE, and it has an ID of 0:
lab@Vodkila> show virtual-chassis vc-port
fpc0:
---------------------------------------------------------------------
Interface Type Status
or
PIC / Port
vcp-0 Dedicated Down
vcp-1 Dedicated DownThere is nothing to be alarmed about here; VCP ports can be up only when attached to another switch that has power applied:
lab@Vodkila> show virtual-chassis protocol adjacency
fpc0:
---------------------------------------------------------------------
Interface System State Hold (secs)
internal-0/27 001f.123d.b4c1 Up 65535
internal-1/24 001f.123d.b4c0 Up 65535The VCCP adjacency status confirms that the switch has two PFEs and that both are internally adjacent. Again, all is as expected. Note that the presence of only two PFEs indicates this must be a 24-port model, which in fact is the case:
lab@Vodkila>show chassis hardwareHardware inventory: Item Version Part number Serial number Description Chassis BM0208269834EX4200-24T
With the single-node VC doing all it can, the time has come to
power up the old Tequila. Before
flipping its power switch, attach to its console to monitor its boot
progress and look for any error messages:
. . .
FLASH: 8 MB
USB: scanning bus for devices... 2 USB Device(s) found
scanning bus for storage devices... 1 Storage Device(s) found
. . .
starting local daemons:.
Sat Jan 1 01:41:09 UTC 2005
Amnesiac (ttyu0)Nothing noteworthy shows in the boot-up messages, except that
things do not end well given the display of an Amnesiac prompt. The expectation was a
virtual console redirection to the current master RE, which clearly
did not happen. This does not bode well for the nascent VC. You log in
to the now factory-default configuration as
root:
root@% root
root@% OS 9.0R2.10 built 2008-03-06 10:31:45 UTC
root@% cli
root> show virtual-chassis
^
syntax error, expecting <command>.After logging in as root, you find it odd
that the show virtual-chassis
command does not complete as it did on Switch 3. You decide to create
a lab/super-user account so that you can log in
via internal communications paths via Switch 3/Vodkila; root logins are not currently
permitted on the intra-VC communications path:
root>configureEntering configuration mode root# ...user lab class super-user authentication plain-text-passwordNew password: Retype new password: [edit] root#commitcommit complete
Back on member 0/Switch 3,
you decide to do some troubleshooting:
lab@Vodkila>show virtual-chassisPreprovisioned Virtual Chassis Virtual Chassis ID: 001f.123d.b4c0 Mastership Neighbor List Member ID Status Serial No Model priority Role ID Interface 0 (FPC 0) Prsnt BM0208269834 ex4200-24t 129 Master* 1 vcp-0 1 vcp-11 (FPC 1) PrsntBM0208269767 ex4200-24t 129Linecard 0 vcp-00 vcp-1
The output of the show
virtual-chassis command works again, and interestingly it
shows two members, each connected by two VC ports, which is pretty
much as expected. The only detail that seems off is that member
1 is shown as an LC, when the
preprovisioned configuration stated it should function in an RE role;
the expected status for member 1 is
therefore backup. Something is not
right. You next display VC adjacency status:
lab@Vodkila> show virtual-chassis protocol adjacency
fpc0:
---------------------------------------------------------------------
Interface System State Hold (secs)
internal-0/27 001f.123d.b4c1 Up 65535
internal-1/24 001f.123d.b4c0 Up 65535
vcp-0 001f.123d.d281 Up 58
vcp-1 001f.123d.d280 Up 57
fpc1:
---------------------------------------------------------------------
Interface System State Hold (secs)
internal-0/27 001f.123d.d281 Up 65535
internal-1/24 001f.123d.d280 Up 65535
vcp-0.32768 001f.123d.b4c1 Up 58
vcp-1.32768 001f.123d.b4c0 Up 59The output confirms that all expected adjacencies for two EX4200-24s connected via two VCP ports are present. Each switch has two internal and two external adjacencies, which is expected given this configuration and cabling scheme. VCCP LSP flooding also seems to be working, given that the expected number of LSPs (one from each PFE in the VC) is present in both members:
lab@Vodkila> show virtual-chassis protocol database
fpc0:
---------------------------------------------------------------------
LSP ID Sequence Checksum Lifetime
001f.123d.b4c0.00-00 0x2cd 0xea48 117
001f.123d.b4c1.00-00 0x2c9 0xef34 117
001f.123d.d280.00-00 0x1e1 0xe412 115
001f.123d.d281.00-00 0x1e3 0xce41 116
4 LSPs
fpc1:
---------------------------------------------------------------------
LSP ID Sequence Checksum Lifetime
001f.123d.b4c0.00-00 0x2cd 0xea48 115
001f.123d.b4c1.00-00 0x2c9 0xef34 115
001f.123d.d280.00-00 0x1e1 0xe412 117
001f.123d.d281.00-00 0x1e3 0xce41 118
4 LSPsThe first clue as to what is wrong comes from a detailed
analysis of the LSP generated by the DIS/pseudonode at member 0/Switch 3. The output is truncated to save
space:
lab@Vodkila>show virtual-chassis protocol database extensive member 0fpc0: -------------------------------------------------------------------------- . . . Packet: LSP ID: 001f.123d.b4c0.00-00, Length: 584 bytes, Lifetime : 118 secs Checksum: 0x84cc, Sequence: 0x2d6, 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: 001f.123d.b4c0, Flags: 3, Priority: 129 System ID: 001f.123d.b4c0, Device ID: 0 System ID: 001f.123d.b4c1, Device ID: 1 Neighbor Info: 001f.123d.b4c1.00, Interface: internal-0/27, Metric: 10 Neighbor Info: 001f.123d.d281.00, Interface: vcp-0, Metric: 10 Master Info: System ID: 001f.123d.b4c0 Backup Info: System ID: 0000.0000.0000 Member Info: System ID: 001f.123d.d280,Member ID: 1 Member role: Not Part ofVirtual ChassisSystem ID: 001f.123d.d280, Device ID: 3 System ID: 001f.123d.d281, Device ID: 4 Member Info: System ID: 001f.123d.b4c0, Member ID: 0 Member role: Master System ID: 001f.123d.b4c0, Device ID: 0 System ID: 001f.123d.b4c1, Device ID: 1 Unknown TLV, Type: 25, Length: 40 Unknown TLV, Type: 24, Length: 1 Unknown TLV, Type: 28, Length: 112 No queued transmissions . . .
Given the highlighted output, it appears the VC’s master feels
that member 1 is not a functional
part of the VC. This condition should help drive home how the
operation of VCCP is independent of the
results; this is to say that VCCP appears to be
working fine here, but the result is not the expected two-member
VC.
You decide to monitor the messages log to see whether anything is up, and the following messages are found to be repeating:
lab@Vodkila>monitor start messageslab@Vodkila> *** messages *** Jan 1 02:13:48 Vodkila fpc1 (mrvl_cos_egr_buf_init) Egress buffer limits on 0 error 0 Jan 1 02:13:48 Vodkila /kernel:invalid fpc 1, closing connection Jan 1 02:13:48 Vodkila /kernel: pfe_listener_disconnect: conn dropped: listener idx=3, tnpaddr=0x11, reason: none Jan 1 02:13:48 Vodkila fpc1 (mrvl_cos_egr_buf_init) Egress buffer limits on 1 error 0 Jan 1 02:13:48 Vodkila fpc1 PFEMAN: Master socket closed Jan 1 02:13:48 Vodkila fpc1 PFEMAN disconnected; PFEMAN socket closed abruptly Jan 1 02:13:48 Vodkila fpc1 pfeman_get_server_addr: selecting master RE Jan 1 02:13:48 Vodkila fpc1 Routing engine PFEMAN reconnection succeeded after 1 tries Jan 1 02:13:48Vodkila fpc1 PFEMAN master RE reconnection made
Clearly something is not right with member 1. You add tracing to the VC, and see what
it has to say:
[edit] lab@Vodkila#show virtual-chassispreprovisioned; traceoptions { file vc_trace; flag error; } member 0 { role routing-engine; serial-number BM0208269834; } member 1 { role routing-engine; serial-number BM0208269767; } [edit] lab@Vodkila#run monitor start vc_trace[edit] lab@Vodkila# *** vc_trace *** Jan 1 02:38:56.329244WARNING: LSP from 001f.123d.d281 on interface vcp-0 withbad packet version 9.0Jan 1 02:38:56.329451WARNING: LSP from 001f.123d.d280 on interface vcp-1 withbad packet version 9.0. . .
The VC trace spews out errors that serve to make the issue
somewhat clear. The bad version messages jog your memory; what was
that about a VC needing compatible software versions again? You
internally connect to member 1 and
have a real “d’oh!” moment as its version is displayed:
ab@Vodkila>request session member 1€ ---JUNOS 9.0R2.10built 2008-03-06 10:31:45 UTC lab>
Breaking the connection and back on the master RE, you are
relieved to note a compatible Jinstall package on its local
storage:
lab>exitrlogin: connection closed lab@Vodkila>file list/var/home/lab/: .ssh/ Vodka_pre_vc_config jinstall-ex-9.2R1.9-domestic-signed.tgz l2_base l2_base_vc . . .
And now the beauty of VCCP strikes you. It provides an opaque transport of VC-related information, and therefore can operate even when VC parameters do not match. Although a VC may not form, the continued operation of the VCCP protocols permits ongoing diagnostics and facilitates maintenance activities, such as use of internal links to allow login into member switches or, luckily for you, the pushing and subsequent installation of software upgrades:
lab@Vodkila>request system software add jinstall-ex-9.2R1.9-domestic-signed.tgzmember 1 rebootPushing bundle to fpc1 WARNING: A reboot is required to install the software WARNING: Use the 'request system reboot' command immediately Rebooting ... shutdown: [pid 720] Shutdown NOW! lab@Vodkila>
The software add command
makes use of the member switch, and
correctly identifies member 1,
preventing the software from being installed on member 0, which is already on that version and
would serve only to force a needless reboot. Meanwhile, you switch
attention back to Switch 4’s console port to again monitor its boot
progress:
. . . Verified SHA1 checksum of jswitch-ex-9.2R1.9.tgz Verified SHA1 checksum of jweb-ex-9.2R1.9.tgz Running requirements check first for jbundle-ex-9.2R1.9-domestic... Running pre-install for jbundle-ex-9.2R1.9-domestic... Installing jbundle-ex-9.2R1.9-domestic in /tmp/pa2350.21/jbundle-ex-9.2R1.9- domestic.x2350... Running post-install for jbundle-ex-9.2R1.9-domestic... Adding jkernel-ex... . . .
Note
Updated JUNOS versions may automate the pushing of compatible software to new switch members. In the 9.2 release, this process must be performed manually.
So far, so good; all indications are that the matched software
version is being installed. It makes watching water boil
seem...enticing, doesn’t it? Sometime later when
the upgrade is complete, the initial console login is again Amnesiac, causing a pang of fear to run up
your spine:
Tue Aug 5 08:59:53 UTC 2008
Amnesiac (ttyu0)Your concerns melt away in true “Calgon bath” fashion, when you
see that the console login is now correctly redirected to the VC’s
master. Eureka! A Vodkila is born
and you can’t help declaring, “It’s alive!”
login: lab
Logging to master
€ƒPassword:
--- JUNOS 9.2R1.9 built 2008-08-05 07:25:22 UTC
lab@Vodkila>With things apparently working, the VC status is displayed to
confirm that member 1 is now correctly listed as a
backup RE:
lab@Vodkila>show virtual-chassisPreprovisioned Virtual Chassis Virtual Chassis ID: 001f.123d.b4c0 Mastership Neighbor List Member ID Status Serial No Model priority Role ID Interface 0 (FPC 0) Prsnt BM0208269834 ex4200-24t 129 Master* 1 vcp-0 1 vcp-11 (FPC 1) PrsntBM0208269767 ex4200-24t 129Backup0 vcp-0 0 vcp-1
The assignment of the same priority (based on the VC member role
in preprovisioned mode) results in a non-revertive mastership
behavior, which is a required aspect of the VC deployment. Should the
current master fail and then come back online, it will not overthrow
the new master, given that both have the same priority. The show chassis
mac-addresses command provides final proof that you now have
a functional two-member VC:
lab@Vodkila> show chassis mac-addresses
FPC 0 MAC address information:
Public base address 00:1f:12:3d:b4:c0
Public count 64
FPC 1 MAC address information:
Public base address 00:1f:12:3d:d2:80
Public count 64Recall that in the event of an RE switch, the new master begins using its own MAC address after the configured age-out time. During the age-out it continues to use the old master’s MAC address.
To complete the VC migration, the original interface assignments
in Tequila’s original (and luckily enough, saved)
configuration are modified to replace slot/FPC number 0 with 1,
resulting in the list shown. While you’re at it, you decide to add
some descriptions to help keep things straight in the new world order
that is Vodkila:
ge-1/0/0 {
description "To Rum also";
unit 0 {
family inet {
address 10.4.5.4/24;
}
}
}
ge-1/0/1 {
description "To Brandy";
unit 0 {
family inet {
address 10.4.6.4/24;
}
}
}
ge-1/0/2 {
description "To Bourbon";
unit 0 {
family inet {
address 10.4.7.4/24;
}
}
}
ge-1/0/3 {
description "To Gin";
unit 0 {
family inet {
address 10.2.4.4/24;
}
}
}
ge-1/0/8 {
description "To Whiskey too";
unit 0 {
family inet {
address 10.1.4.4/24;
}
}
}A load merge terminal
relative is entered at the [edit
interfaces] hierarchy to paste the modified interface name
into the configuration, and the change is committed:
[edit interfaces] lab@Vodkila#load merge terminal relative[Type ^D at a new line to end input] ge-1/0/0 { description "To Rum also"; unit 0 { family inet { address 10.4.5.4/24; } } } ge-1/0/1 { description "To Brandy"; unit 0 { family inet { address 10.4.6.4/24; } } } ge-1/0/2 { description "To Bourbon"; unit 0 { family inet { address 10.4.7.4/24; } } } ge-1/0/3 { description "To Gin"; unit 0 { family inet { address 10.2.4.4/24; } } } ge-1/0/8 { description "To Whiskey too"; unit 0 { family inet { address 10.1.4.4/24; } } } load complete [edit interfaces] lab@Vodkila# [edit interfaces] lab@Vodkila#commit and-quitfpc0: configuration check succeeds fpc1: commit complete fpc0: commit complete Exiting configuration mode lab@Vodkila>
Note how the commit synchronize
setting results in the configuration being mirrored to both REs. You
will be happy you did this should the mastership later change. Not
being one to leave well enough alone, you decide to test a mastership
change now using a request chassis
routing-engine command:
lab@Vodkila> request chassis routing-engine master release no-confirm
lab@Vodkila>
Vodkila (ttyu0)The virtual management session is broken during the mastership change. Upon reconnection, you are again attached to the newly active master:
login:labPassword: --- JUNOS 9.2R1.9 built 2008-08-05 07:25:22 UTC lab@Vodkila> lab@Vodkila>show virtual-chassisPreprovisioned Virtual Chassis Virtual Chassis ID: 001f.123d.b4c0 Mastership Neighbor List Member ID Status Serial No Model priority Role ID Interface 0 (FPC 0) Prsnt BM0208269834 ex4200-24t 129 Backup 1 vcp-0 1 vcp-11 (FPC 1) Prsnt BM0208269767 ex4200-24t 129 Master*0 vcp-0 0 vcp-1
Given the change in mastership that was just triggered, it is no
surprise to see that member 1 is
now acting as the VC’s master RE while member 0 stands by waiting to return to its former
glory. Having confirmed proper mastership switchover (GRES) and the
desired non-revertive behavior, you return to the original member
roles, but using a slightly different approach to keep it real,
yo:
lab@Vodkila>request session member 0€ --- JUNOS 9.2R1.9 built 2008-08-05 07:25:22 UTC lab@Vodkila-fpc0-BK> request chassis routing-engine master acquire no-confirmlab@Vodkila-fpc0-BK> Vodkila-fpc1-BK (ttyu0) login:labLogging to master €Password: --- JUNOS 9.2R1.9 built 2008-08-05 07:25:22 UTC lab@Vodkila>show virtual-chassisPreprovisioned Virtual Chassis Virtual Chassis ID: 001f.123d.b4c0 Mastership Neighbor List Member ID Status Serial No Model priority Role ID Interface0 (FPC 0) Prsnt BM0208269834 ex4200-24t 129 Master*1 vcp-0 1 vcp-1 1 (FPC 1) Prsnt BM0208269767 ex4200-24t 129 Backup 0 vcp-0
The highlights call out the redirection of the console port on
Switch 4 to the current VC master, which is always called Vodkila. The current master is again member
0. In the next section the
two-member VC is expanded to pick up a remote member.
In this section, you will complete the VC deployment by adding a third member switch, located some distance away from the current VC members. Given the distance needed, you will need to use VCE ports, which involves redefining one or more uplink module ports to operate in VCCP mode.
Figure 4-17 shows the VCE design specifics needed to meet the stated redundancy requirements.
The key point is the use of two VCE ports at
member 3, with each port attached to
a different VC member, thereby meeting the stated
redundancy objectives given that this approach ensures no single point
of failure for the VC, and that the VC can continue to communicate with
the loss of any one VC trunk.
You can define as many VCEs as you have uplink ports, but note that VCCP routing will use only one such link for any given destination, based on the results of its shortest-path calculation. VCCP factors link speed so that the high-speed VCP backplane ports are generally preferred over any VCE link when an all-VCP path exists.
As before, you should return the new switch to a factory default, after archiving any configuration it may have. In this case, you also have the foresight to ensure that it’s already running a matched software version.
You can configure the new switch’s uplinks now, as long as you
do not attach its uplink cables to the other VC members
before their uplinks are set to VCCP mode.
Failing to do this may prevent proper VCCP auto-sense, which may force
a restart virtual-chassis-control
to get things working properly.
In our lab, the cables are already attached, and the lab is too far away to warrant a trip just for this. To help ensure that things work to plan, the approach taken is to configure the VC’s VCE ports first. In effect, this places them in auto-discovery mode. The new switch does not have any uplink configuration, so currently only light traffic is sent over its uplink ports, which should avoid any potential confusion to the VCCP auto-sense function. When ready, you plan to activate the VCE ports on the new switch and things should work.
You start at the master RE, where you configure member 0’s VCE link to Switch 3. Note that given
that this is member 0, you are
configuring PIC 0/1, which is the
uplink module:
lab@Vodkila>request virtual-chassis vc-port set ?Possible completions: interface Member's virtual chassis interface pic-slot Member's PIC slot lab@Vodkila>request virtual-chassis vc-port set pic-slot 1 port 0
The pic-slot argument
correctly identifies the uplink module on the local switch, and sets
the first port to VCE mode. The change is confirmed for member
0:
lab@Vodkila> show virtual-chassis vc-port member 0
fpc0:
---------------------------------------------------------------------
Interface Type Status
or
PIC / Port
vcp-0 Dedicated Up
vcp-1 Dedicated Up
1/0 Configured UpThe new VCE is correctly displayed and is in the Up state given
that it’s cabled to the new switch member and has light. This leaves
the three remaining 1 GE ports available for normal uplink usage at
member 0. The same command is used
to create a VCE link at member 1.
In this case, the member argument
is used to push the change to the correct VC member:
lab@Vodkila> request virtual-chassis vc-port set pic-slot member 1 1 port 0
fpc1:
---------------------------------------------------------------------
lab@Vodkila>And the results are confirmed as before:
lab@Vodkila> show virtual-chassis vc-port member 1
fpc1:
---------------------------------------------------------------------
Interface Type Status
or
PIC / Port
vcp-0 Dedicated Up
vcp-1 Dedicated Up
1/0 Configured UpAs expected, no adjacencies have been formed over either VCE at this point:
lab@Vodkila>show virtual-chassis protocol adjacency member 0fpc0: --------------------------------------------------------------------- Interface System State Hold (secs) internal-0/27 001f.123d.b4c1 Up 65535 internal-1/24 001f.123d.b4c0 Up 65535 vcp-0 001f.123d.d281 Up 58 vcp-1 001f.123d.d280 Up 59 vcp-255/1/0 001f.123d.d280Down11
With the VC end ready to go, it’s time to power up the new switch and configure its uplinks for VCE operation. Note that until it’s attached, the switch has member ID 0, which you must keep in mind when you configure its VCE ports. Once it becomes part of the VC it will receive its new member ID and will do the right thing to update its private configuration:
root> show virtual-chassis
Virtual Chassis ID: 001f.123d.e6c0
Mastership Neighbor List
Member ID Status Serial No Model priority Role ID Interface
0 (FPC 0) Prsnt BM0208269780 ex4200-24t 128 Master*
Member ID for next new member: 1 (FPC 1)Both VCE ports are activated. The 1/0 port goes to member 0 and the 1/1 port goes to member 1:
root>request virtual-chassis vc-port set pic-slot 1 port 0root>request virtual-chassis vc-port set pic-slot 1 port 1
After a moment or two, the results are confirmed. You begin by logging out, at which time you note that the prompt changes, which indicates proper VC operation and is a good omen:
-fpc0-LC(ttyu0) . . . root@-fpc0-LC% .9 built 2008-08-05 07:25:22 UTC root@-fpc0-LC%cliroot@-fpc0-LC>show virtual-chassisVirtual Chassis ID: 001f.123d.b4c0 Mastership Neighbor List Member ID Status Serial No Model priority Role ID Interface 0 (FPC 0) Prsnt BM0208269780 ex4200-24t 128 Linecard*
But the show virtual-chassis
display confirms that something is again wrong. The new switch member
has the wrong ID, and fails to list the rest of the VC members that
are known to exist. Back at the master we get some additional hints as
to the nature of the problem:
lab@Vodkila>show virtual-chassisPreprovisioned Virtual Chassis Virtual Chassis ID: 001f.123d.b4c0 Mastership Neighbor List Member ID Status Serial No Model priority Role ID Interface 0 (FPC 0) Prsnt BM0208269834 ex4200-24t 129 Master* 1 vcp-0 1 vcp-1 1 (FPC 1) Prsnt BM0208269767 ex4200-24t 129 Backup 0 vcp-0 0 vcp-255/1/0 0 vcp-1 -Unprvsnd BM0208269780 ex4200-24t
Yep, the display makes the problem clear. We are in a preprovisioned mode but have failed to update the master configuration with the new member’s serial number. The configuration mistake is rectified:
lab@Vodkila>configureEntering configuration mode [edit] lab@Vodkila#set virtual-chassis member 2 role line-card serial-number BM0208269780[edit] lab@Vodkila#commit and-quitfpc0: configuration check succeeds fpc1: commit complete fpc0: commit complete Exiting configuration mode
And the VC status is again displayed:
lab@Vodkila>show virtual-chassisPreprovisioned Virtual Chassis Virtual Chassis ID: 001f.123d.b4c0 Mastership Neighbor List Member ID Status Serial No Model priority Role ID Interface 0 (FPC 0) Prsnt BM0208269834 ex4200-24t 129 Master* 1 vcp-0 2 vcp-255/1/0 1 vcp-1 1 (FPC 1) Prsnt BM0208269767 ex4200-24t 129 Backup 0 vcp-0 2 vcp-255/1/0 0 vcp-12 (FPC 2) Prsnt BM0208269780 ex4200-24t 0 Linecard0 vcp-255/1/0 1 vcp-255/1/1
The results are as expected, and they confirm that a
three-member VC is now operational. The neighbor ID list indicates
that some neighbors are adjacent over a VCE, as indicated by the
vcp-255/1/0 designation. Proper
internal routing is confirmed by displaying the VC’s active
topology:
lab@Vodkila> show virtual-chassis active-topology
Destination ID Next-hop
1 1(vcp-0) 1(vcp-1)
2 (vcp-255/1/0) 1(vcp-1)The display confirms that member 0 plans to reach member 1, which is collocated using the VCP cables.
Its first choice is to use VCP Port 0, and it can fall back to Port 1
if needed. To reach the remote chassis, it prefers the direct VCE link
vcp-255/1/0, but in the event of
that next hop failing it is prepared to fall back to its vcp-1 link, which takes it through member
1 via the VCP connection, and then
from member 1 to member 2 over the remaining VCE link.
A quick look at the VC RT for Destination 3 at member 0 confirms that VCE links have a higher
cost, due to their reduced bandwidth:
lab@Vodkila>show virtual-chassis protocol route 2 member 0fpc0: --------------------------------------------------------------------- Dev 001f.123d.b4c0 ucast routing table Current version: 79 ---------------- System ID Version Metric Interface Via 001f.123d.b4c1 79 10 internal-0/27 001f.123d.b4c1 001f.123d.d280 79 20 vcp-0 001f.123d.d281 internal-0/27 001f.123d.b4c1 001f.123d.d281 79 10 vcp-0 001f.123d.d281 001f.123d.e6c0 7963vcp-255/1/0 001f.123d.e6c0 001f.123d.e6c1 7973vcp-255/1/0 001f.123d.e6c0
The display shows that internal and VCP links have a cost of 10.
Thus, the route from PFE 0 in member 0 to PFE d280, which is in member 1, has a path cost of 20, given the use of
two such links. The lower-speed 1 GE VCE is assigned a cost of 63 by
the automatic scaling algorithm. As such, for member 0 to reach PFE 1 (e6c1) in member 2, the path cost is 73, reflecting the need
to transit one VCE and one internal link.
These results confirm the operation of the new VC and complete the VC deployment case study.
Since you were the one to bring it up, who better to pull it all
down? Note the use of the all-members switch to force the graceful
shutdown of the entire VC:
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)yesHaltingfpc1Haltingfpc2Shutdown NOW! [pid 2413] *** FINAL System shutdown message from lab@Vodkila *** System going down IMMEDIATELY
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.
