Lab 2 Spanning Tree Protocols Overview This lab demonstrates basic configuration and monitoring tasks when implementing spanning tree and some related protection features on EX Series switches. In this lab, you use the command-line interface (CLI) to configure and monitor RSTP as well as bridge protocol data unit (BPDU) and loop protection. In addition, you will use the command-line interface (CLI) to configure and monitor the Multiple Spanning Tree Protocol (MSTP) and VLAN STP (VSTP). All devices are connected to a common management network which facilitates access to the CLI. These exercises assume you already have some basic understanding of the JUNOS CLI interfaces or you have read the JNCIA-JUNOS documentation or similar. Note that your lab login (password given to you separately) grants you all permissions needed to complete this lab; however, some restrictions have been made to prevent loss of connectivity to the devices. Please be careful, and have fun! By completing this lab, you will perform the following tasks: Update the existing configuration. Configure and monitor RSTP. Configure and monitor BPDU protection. Configure and monitor MSTP Configure and monitor VSTP Please refer to the next page lab diagram to perform this exercise: 1
Lab Diagram Lab 2: Implementing Spanning Tree Bridge Priority: 4K Bridge Priority: 8K 172.23.11.10/24 172.23.12.10/24 srxx-1 ge-0/0/1 ge-0/0/2 srxx-2 172.23.21.10/24 172.23.22.10/24 Bridge Priority: 32K (default) ge-0/0/8 ge-0/0/10 ge-0/0/10 ge-0/0/8 Bridge Priority: 32K (default) ge-0/0/9 exx-1 exx-2 ge-0/0/9 VLAN: v11 172.23.11.100/24 vr11 ge-0/0/6 ge-0/0/7 VLAN: v12 172.23.12.100/24 vr12 Virtual Routers VLAN: v21 172.23.21.100/24 vr21 ge-0/0/6 ge-0/0/7 VLAN: v22 172.23.22.100/24 vr22 2
Part 1: Logging In Using the CLI The goal of this lab part is to become familiar with the access details for your pod of routers & switches and to log in through the CLI. To perform this lab you will have to login in 2x EX switches and 2x SRX devices. 4 sessions in total! srxx-1, srxx-2, exx-1 & exx-2 (being X the initial of the POD being assigned to you) Note Please do NOT delete interface ge-0/0/0 or me0 as this is your management interface which provides access to your session!! Do NOT delete either the security section of your configurations. This allows your system to allow any traffic in/out. Note 2 It is recommended that you use the console connection to access your assigned station. Using the console connection ensures persistent connectivity even when the management network access is unavailable. If needed, review the instructions about how to connect to your system using the console port. Having said that, you can also use the management IP address to perform this lab. Chose the one you want Note 3 Remember that the exercise proposed in this documentation is generic and the examples given here apply only to one particular pod of devices. Please adapt the example to your assigned set of devices (srxa-1, srxa-2, exa-1 & exa-2 or srxb-1, srxb-2, exb-1 & exb-2 or srxc-1, srxc-2, exc-1 & exc-2 or srxd-1, srxd-2, exd-1 & exd-2). Look at you lab diagram and mind the pod of systems that you have been assigned! Step 1.1 Log in to both EX systems with the username lab using the password given to you. Note that both the name and password are case-sensitive. You can connect to your SRX or EX Series devices either using the console connection through the terminal server or through a Telnet or SSH session using the SRX Series device s management IP address. Use the one access method that you prefer. Here is an example on how to login via console into your exx-1 switch. Please open a similar session to the pairing switch exx-2 [luis@js2 ~]$ telnet 10.1.1.253 7011 Trying 10.1.1.253... Connected to 10.1.1.253 (10.1.1.253). Escape character is '^]'. 3
exa-1 (ttyu0) login: lab Password: Enter configuration mode and load the lab2-start configuration from the /var/home/lab/jncis++/ directory. Commit your changes when complete. {master:0 lab@exa-1> configure Entering configuration mode {master:0[edit] lab@exa-1# load override jncis++/lab2-start load complete {master:0[edit] lab@exa-1# commit configuration check succeeds commit complete {master:0[edit] lab@exa-1# Repeat the same for the other switch exx-2. Login in the system, load the lab5-start configuration file, etc. [luis@js2 ~]$ telnet 10.1.1.253 7012... Step 1.2 Open a separate session to your two assigned SRX Series devices. Note you can connect to your SRX Series device using the console connection through the terminal server or through a Telnet or SSH session using the SRX Series device s management IP address. [luis@js2 ~]$ telnet 192.168.2.11 7001 Trying 192.168.2.11... Connected to 192.168.2.11 (192.168.2.11). Escape character is '^]'. login: lab Password: --- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC lab@srxa-1> 4
Enter configuration mode and load the lab2-start configuration from the /var/home/lab/jncis++/ directory. Commit your changes when complete. lab@srxa-1> configure Entering configuration mode [edit] lab@srxa-1# load override jncis++/lab2-start load complete [edit] lab@srxa-1# commit commit complete Exiting configuration mode lab@srxa-1# Note Not likely, but if you happen to get a message like this: lab@host1-a# commit warning: You have changed mpls flow mode. You have to reboot the system for your change to take effect. If you have deployed a cluster, be sure to reboot all nodes. commit complete As the message suggest, please reboot the machine by issuing a request system reboot and keep going. Ignore this note if you do not receive a warning of this kind Repeat the same for the other SRX srxx-2. Login in the system, load the lab5-start.config configuration file, etc. [luis@js2 ~]$ telnet 192.168.2.11 7002... Part 2: Modifying the existing configuration Step 2.1 In this lab part, you will modify the configuration to prepare for subsequent lab parts. Refer to network diagram for this lab for topological and configuration details. Return to your assigned exx-1 switch. From your assigned EX switch, navigate to the [edit vlans] hierarchy level and add the VLANs assigned to virtual routers attached to the remote switch (your other assigned EX switch). Once this step is done, you should see a total of four VLANs defined on your switch; v11, v12, v21, and v22. {master:0[edit] lab@exa-1# edit vlans 5
{master:0[edit vlans] lab@exa-1# show v11 { vlan-id 11; l3-interface vlan.11; v12 { vlan-id 12; l3-interface vlan.12; {master:0[edit vlans] lab@exa-1# set remote-network1-vlan-name vlan-id remote-network1-vlan-id {master:0[edit vlans] lab@exa-1# set remote-network2-vlan-name vlan-id remote-network2-vlan-id {master:0[edit vlans] lab@exa-1# show v11 { vlan-id 11; l3-interface vlan.11; v12 { vlan-id 12; l3-interface vlan.12; v21 { vlan-id 21; v22 { vlan-id 22; Step 2.2 Navigate to the [edit interfaces] hierarchy and associate ge-0/0/8.0 with all vlans. {master:0[edit vlans] lab@exa-1# top edit interfaces {master:0[edit interfaces] lab@exa-1# show ge-0/0/8 unit 0 { family ethernet-switching { port-mode trunk; vlan { members [ v11 v12 ]; {master:0[edit interfaces] lab@exa-1# delete ge-0/0/8 unit 0 family ethernet-switching vlan 6
{master:0[edit interfaces] lab@exa-1# set ge-0/0/8 unit 0 family ethernet-switching vlan members all {master:0[edit interfaces] lab@exa-1# show ge-0/0/8 unit 0 { family ethernet-switching { port-mode trunk; vlan { members all; Step 2.3 Use the copy command to replicate the configuration associated with ge-0/0/8 to the ge-0/0/10 interface. {master:0[edit interfaces] lab@exa-1# copy ge-0/0/8 to ge-0/0/10 {master:0[edit interfaces] lab@exa-1# show ge-0/0/10 unit 0 { family ethernet-switching { port-mode trunk; vlan { members all; Step 2.4 Activate the configuration changes using the commit command. Next, issue the run show ethernet-switching interfaces command. Note Do NOT forget to follow these steps again and configure the other switch exx-2!! {master:0[edit interfaces] lab@exa-1# commit configuration check succeeds commit complete {master:0[edit interfaces] lab@exa-1# run show ethernet-switching interfaces Interface State VLAN members Tag Tagging Blocking 7
ge-0/0/1.0 down default untagged unblocked ge-0/0/6.0 up v11 11 untagged unblocked ge-0/0/7.0 up v12 12 untagged unblocked ge-0/0/8.0 up v11 11 tagged unblocked v12 12 tagged unblocked v21 21 tagged unblocked v22 22 tagged unblocked ge-0/0/10.0 up v11 11 tagged unblocked v12 12 tagged unblocked v21 21 tagged unblocked v22 22 tagged unblocked Based on the resulting output, are any of the listed interfaces currently blocking traffic? As shown in the sample output, you should see all interfaces in the unblocked blocking state, which means all interfaces should be forwarding traffic rather than blocking traffic. Part 3: Configuring and Monitoring RSTP In this lab part, you will configure and monitor RSTP. First, you will perform some ping tests on your SRX Series device to identify the need for spanning tree within a Layer 2 network. Next, you will configure RSTP on your assigned devices. Finally, you will verify the effects of enabling RSTP in a Layer 2 network with redundant paths. You will need to refer to the network diagram for this lab for some of the configuration tasks performed in this lab part. Step 3.1 Note The next lab steps are performed on your assigned SRX Series devices. If needed, refer to the management network diagram for access details. Return to one of your assigned SRX Series device. From your assigned SRX Series device, attempt to ping the IP addresses assigned to the VLAN interfaces defined on your EX Series switch. That is the network1-address and network2-address or the addresses of the vr devices. Refer to the network diagram for this lab, if needed. [edit] lab@srxa-1# run ping 172.23.11.1 PING 172.23.11.1 (172.23.11.1): 56 data bytes 64 bytes from 172.23.11.1: icmp_seq=0 ttl=64 time=9.501 ms 64 bytes from 172.23.11.1: icmp_seq=0 ttl=63 time=39.953 ms (DUP!) 64 bytes from 172.23.11.1: icmp_seq=1 ttl=64 time=1.937 ms 8
64 bytes from 172.23.11.1: icmp_seq=2 ttl=64 time=1.798 ms 64 bytes from 172.23.11.1: icmp_seq=3 ttl=64 time=1.769 ms ^C --- 172.23.11.1 ping statistics --- 8 packets transmitted, 4 packets received, +1 duplicates, 50% packet loss round-trip min/avg/max/stddev = 1.769/10.992/39.953/14.782 ms [edit] lab@srxa-1# run ping 172.23.11.100 count 5 PING 172.23.11.100 (172.23.11.100): 56 data bytes 64 bytes from 172.23.11.100: icmp_seq=0 ttl=64 time=2.765 ms 64 bytes from 172.23.11.100: icmp_seq=0 ttl=64 time=3.678 ms (DUP!) 64 bytes from 172.23.11.100: icmp_seq=1 ttl=64 time=2.201 ms 64 bytes from 172.23.11.100: icmp_seq=1 ttl=64 time=3.558 ms (DUP!) 64 bytes from 172.23.11.100: icmp_seq=2 ttl=64 time=7.214 ms 64 bytes from 172.23.11.100: icmp_seq=2 ttl=64 time=8.276 ms (DUP!) 64 bytes from 172.23.11.100: icmp_seq=3 ttl=64 time=4.154 ms 64 bytes from 172.23.11.100: icmp_seq=3 ttl=64 time=5.055 ms (DUP!) 64 bytes from 172.23.11.100: icmp_seq=4 ttl=64 time=2.223 ms --- 172.23.11.100 ping statistics --- 5 packets transmitted, 5 packets received, +4 duplicates, 0% packet loss round-trip min/avg/max/stddev = 2.201/4.347/8.276/2.024 ms [edit] lab@srxa-1# run ping 172.23.12.1 PING 172.23.12.1 (172.23.12.1): 56 data bytes 64 bytes from 172.23.12.1: icmp_seq=0 ttl=64 time=9.370 ms 64 bytes from 172.23.12.1: icmp_seq=0 ttl=63 time=40.006 ms (DUP!) 64 bytes from 172.23.12.1: icmp_seq=1 ttl=64 time=1.751 ms 64 bytes from 172.23.12.1: icmp_seq=2 ttl=64 time=1.797 ms 64 bytes from 172.23.12.1: icmp_seq=3 ttl=64 time=1.734 ms ^C --- 172.23.12.1 ping statistics --- 8 packets transmitted, 8 packets received, +1 duplicates, 30% packet loss round-trip min/avg/max/stddev = 1.734/6.872/40.006/11.951 ms Do the ping tests succeed? What might these result indicate? Your results may vary from those shown above. In the sample output, the ping tests are not clearly successful. In some situations you may not see any response while in other situations you may see some intermittent replies; including duplicate ICMP echo replies. These results are often indicative of a Layer 2 loop. 9
Step 3.2 Activate the RSTP configuration on both SRX devices (the protocol is actually preconfigured in your device but not activated). Issue the commit and-quit command to activate the change and return to operational mode. [edit] lab@srxa-1# show protocols inactive: rstp { bridge-priority 4k; [edit] lab@srxa-1# activate protocols rstp [edit] lab@srxa-1# commit and-quit commit complete Exiting configuration mode lab@srxa-1> Note Do NOT forget to follow these steps again and configure the other srxx-2!! Step 3.3 Return to your assigned EX Series switches. On both your assigned EX Series switches, enable the RSTP protocol. Next, activate the configuration changes and return to operational mode. {master:0[edit interfaces] lab@exa-1# top set protocols rstp {master:0[edit interfaces] lab@exa-1# commit and-quit configuration check succeeds commit complete Exiting configuration mode Based on the priority values listed on the network diagram for this lab, can you predict which device will be elected the root bridge? Based on the assigned priority values, srxx-1, where X represents your assigned pod value, should be elected the root bridge. 10
Step 3.4 Issue the show spanning-tree bridge command. {master:0 lab@exa-1> show spanning-tree bridge STP bridge parameters Context ID : 0 Enabled protocol : RSTP Root ID : 4096.00:26:88:02:74:90 Root cost : 20000 Root port : ge-0/0/8.0 Hello time : 2 seconds Maximum age : 20 seconds Forward delay : 15 seconds Message age : 1 Number of topology changes : 2 Time since last topology change : 61 seconds Topology change initiator : ge-0/0/8.0 Topology change last recvd. from : 00:26:88:e9:d2:88 Local parameters Bridge ID : 32768.00:23:9c:13:a8:41 Extended system ID : 0 Internal instance ID : 0 What is your switch s bridge ID? The answer will vary. In the sample output, the bridge ID is 32768.00:23:9c:13:a8:41. Remember that the bridge ID is created by combining the bridge priority (32K by default) and the system MAC address. The system MAC address is typically the same as the public base address for the device. The public base address can be viewed on EX Series switches using the following command: {master:0 lab@exa-1> show chassis mac-addresses FPC 0 MAC address information: Public base address 00:23:9c:13:a8:40 Public count 64 Can you determine which device is elected as the root bridge? The srxx-1 device, where X represents your assigned pod value, should be elected as the root bridge based on the bridge priority value of 4096. 11
Which interface on your switch has been selected as the root port? The answer depends on the device you check it. On switch exx-1, where X represents your assigned pod value, you should see ge-0/0/8.0 elected as the root port. On switch exx-2, where X represents your assigned pod value, you should see ge-0/0/10.0 elected as the root port. A sample capture taken from exx-2 follows: {master:0 lab@exa-2> show spanning-tree bridge STP bridge parameters Context ID : 0 Enabled protocol : RSTP Root ID : 4096.00:26:88:02:74:90 Root cost : 20000 Root port : ge-0/0/10.0 Hello time : 2 seconds Maximum age : 20 seconds Forward delay : 15 seconds Message age : 1 Number of topology changes : 2 Time since last topology change : 340 seconds Topology change initiator : ge-0/0/10.0 Topology change last recvd. from : 00:26:88:e9:d2:8a Local parameters Bridge ID : 32768.00:23:9c:13:91:81 Extended system ID : 0 Internal instance ID : 0 What is the cumulative cost to the root bridge from your designated switch? Regardless of your assigned switch, the cumulative cost to the root bridge should be 20000 based on the active topology. Step 3.5 Issue the show spanning-tree interface command to determine the state and role of each switch port. {master:0 lab@exa-1> show spanning-tree interface 12
Spanning tree interface parameters for instance 0 Interface Port ID Designated Designated Port State Role port ID bridge ID Cost ge-0/0/6.0 128:519 128:519 32768.00239c13a841 20000 FWD DESG ge-0/0/7.0 128:520 128:520 32768.00239c13a841 20000 FWD DESG ge-0/0/8.0 128:521 128:521 4096.002688027490 20000 FWD ROOT ge-0/0/10.0 128:523 128:523 8192.002688026b90 20000 BLK ALT Does your switch currently have any ports in the blocking (BLK) state? If so, which interface? Regardless of the switch you look at, you should have one switch port in the blocking (BLK) state. The actual interface in the blocking state will depend on your device. If you look at switch exx-1, where X represents your assigned pod value, you should see ge-0/0/10.0 in the blocking state. If you look at switch is exx-2, you should see ge- 0/0/8.0 in the blocking state. A sample capture taken from exx-2 follows: {master:0 lab@exa-2> show spanning-tree interface Spanning tree interface parameters for instance 0 Interface Port ID Designated Designated Port State Role port ID bridge ID Cost ge-0/0/6.0 128:519 128:519 32768.00239c139181 20000 FWD DESG ge-0/0/7.0 128:520 128:520 32768.00239c139181 20000 FWD DESG ge-0/0/8.0 128:521 128:521 8192.002688026b90 20000 BLK ALT ge-0/0/10.0 128:523 128:523 4096.002688027490 20000 FWD ROOT Why are all the port costs the same for all interfaces? They are all the same because they are using the default port cost for 1 Gbps Ethernet. If a port has been changed to influence root port election you might see something like the following output where the influenced port and path have a lower value than the default 20000 for 1 Gbps Ethernet: {master:0 lab@exa-1> show spanning-tree interface Spanning tree interface parameters for instance 0 13
Interface Port ID Designated Designated Port State Role port ID bridge ID Cost ge-0/0/6.0 128:519 128:519 32768.00239c13a841 20000 FWD DESG ge-0/0/7.0 128:520 128:520 32768.00239c13a841 20000 FWD DESG ge-0/0/8.0 128:521 128:521 4096.002688027490 20000 FWD ROOT ge-0/0/10.0 128:523 128:523 8192.002688026b90 20000 BLK ALT Step 3.6 Issue the show ethernet-switching interfaces command to view the effects of the spanning tree calculations on Ethernet switching interfaces. {master:0 lab@exa-1> show ethernet-switching interfaces Interface State VLAN members Tag Tagging Blocking ge-0/0/1.0 down default untagged blocked by STP ge-0/0/6.0 up v11 11 untagged unblocked ge-0/0/7.0 up v12 12 untagged unblocked ge-0/0/8.0 up v11 11 tagged unblocked v12 12 tagged unblocked v21 21 tagged unblocked v22 22 tagged unblocked ge-0/0/10.0 up v11 11 tagged blocked by STP v12 12 tagged blocked by STP v21 21 tagged blocked by STP v22 22 tagged blocked by STP Are there any Ethernet switching interfaces now in the blocking state? If so, which interfaces and why? Step 3.7 Regardless of the switch you look at, you should have two Ethernet switching ports in the blocking state. In all cases, ge-0/0/1.0 should be blocked by STP because it is not physically up. The second interface in the blocking state will depend on the device. If you look at exx-1, where X represents your assigned pod value, you should see ge- 0/0/10.0 in the blocking state. If you look at exx-2, where X represents your assigned pod value, you should see ge-0/0/8.0 in the blocking state. The second interface is also being blocked by STP due to the least cost path calculation to the root bridge. Issue the show spanning-tree interface ge-0/0/y detail command for the interface currently designated as the root port (where y is either ge-0/0/8 or ge-0/0/10 depending on the switch you are checking). 14
{master:0 lab@exa-1> show spanning-tree interface ge-0/0/8 detail Spanning tree interface parameters for instance 0 Interface name : ge-0/0/8.0 Port identifier : 128.521 Designated port ID : 128.521 Port cost : 20000 Port state : Forwarding Designated bridge ID : 4096.00:26:88:02:74:90 Port role : Root Link type : Pt-Pt/NONEDGE Boundary port : NA Edge delay while expiry count : 1 Rcvd info while expiry count : 0 What is the Link type for this interface? Step 3.8 The Link type for the root port should be Pt-Pt/NONEDGE. This is the default link type for an interface operating in full-duplex that receives BPDUs. Issue the show spanning-tree interface ge-0/0/6 detail command. {master:0 lab@exa-1> show spanning-tree interface ge-0/0/6 detail Spanning tree interface parameters for instance 0 Interface name : ge-0/0/6.0 Port identifier : 128.519 Designated port ID : 128.519 Port cost : 20000 Port state : Forwarding Designated bridge ID : 32768.00:23:9c:13:a8:41 Port role : Designated Link type : Pt-Pt/EDGE Boundary port : NA Edge delay while expiry count : 1 Rcvd info while expiry count : 0 What is the Link type for this interface? Can you explain why it is different than the root port? 15
The Link type for ge-0/0/6 should be Pt-Pt/EDGE. This is the expected link type for this interface because it is operating in full-duplex and is not receiving BPDUs from the connected virtual router. For an interface operating in half-duplex mode, you see a link type of shared rather than point-to-point. The following output confirms the current duplex setting for ge-0/0/6: {master:0 lab@exa-1> show interfaces ge-0/0/6 extensive match "Link mode" Link mode: Full-duplex, Flow control: None, Remote fault: OK, Step 3.9 Return to your assigned SRX Series devices srxx-1. On one of your assigned SRX Series device, use the ping utility and attempt to ping the IP addresses assigned to the VLAN interfaces defined on your EX Series switch (the same ones as in step 3.1). Refer to the network diagram for this lab, if needed. lab@srxa-1> ping 172.23.11.1 count 10 rapid PING 172.23.11.1 (172.23.11.1): 56 data bytes!!!!!!!!!! --- 172.23.11.1 ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.560/1.825/2.337/0.293 ms lab@srxa-1> ping 172.23.11.100 count 10 rapid PING 172.23.11.100 (172.23.11.100): 56 data bytes!!!!!!!!!! --- 172.23.11.100 ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.234/1.343/1.551/0.098 ms lab@srxa-1> ping 172.23.12.1 count 10 rapid PING 172.23.12.1 (172.23.12.1): 56 data bytes!!!!!!!!!! --- 172.23.12.1 ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.633/2.045/2.742/0.343 ms Do the ping tests succeed? Yes, at this time the ping tests should succeed 16
Part 4: Configuring and Monitoring BPDU Protection Step 4.1 In this lab part, you will enable some protection features. First, you will enable the ge-0/0/9.0 interface for Layer 2 operations as an edge port. Next, you will configure BPDU protection and monitor the effects of this protection feature. Finally, you will administratively clear a BPDU error condition. This lab section could be performed on the srxx-1 and exx-1 pair of devices only. Return to your assigned EX Series switches. On your EX Series switches, enter configuration mode and navigate to the [edit interfaces] hierarchy level. {master:0 lab@exa-1> configure Entering configuration mode {master:0[edit] lab@exa-1# edit interfaces Enable ge-0/0/9 for Layer 2 operations as an access port for the default VLAN {master:0[edit interfaces] lab@exa-1# set ge-0/0/9 unit 0 family ethernet-switching Step 4.2 Navigate to the [edit protocols rstp] hierarchy. Define ge-0/0/9.0 as an edge port. Next, issue the commit command to activate the configuration changes. {master:0[edit interfaces] lab@exa-1# top edit protocols rstp {master:0[edit protocols rstp] lab@exa-1# set interface ge-0/0/9.0 edge {master:0[edit protocols rstp] lab@exa-1# commit configuration check succeeds commit complete Step 4.3 Issue the run show spanning-tree interface ge-0/0/9.0 detail command. {master:0[edit protocols rstp] lab@exa-1# run show spanning-tree interface ge-0/0/9.0 detail Spanning tree interface parameters for instance 0 Interface name : ge-0/0/9.0 Port identifier : 128.522 17
Designated port ID : 128.522 Port cost : 20000 Port state : Forwarding Designated bridge ID : 32768.00:23:9c:13:a8:41 Port role : Designated Link type : Pt-Pt/EDGE Boundary port : NA Edge delay while expiry count : 1 Rcvd info while expiry count : 0 Is ge-0/0/9.0 designated as an edge port? Yes, ge-0/0/9.0 should now be designated as a point-to-point edge (Pt-PT/EDGE) interface as shown in the sample output. What is the state and role of ge-0/0/9.0? At this time the newly added interface should be present in the generated output and should assume the forwarding state and designated role. Step 4.4 Enable the BPDU protection feature under the [edit protocols rstp] hierarchy and activate the configuration change using the commit command. {master:0[edit protocols rstp] lab@exa-1# set bpdu-block-on-edge {master:0[edit protocols rstp] lab@exa-1# commit configuration check succeeds commit complete Step 4.5 Issue the run show ethernet-switching interfaces command. {master:0[edit protocols rstp] lab@exa-1# run show ethernet-switching interfaces Interface State VLAN members ge-0/0/1.0 down default Tag Tagging Blocking untagged blocked by STP 18
ge-0/0/6.0 up v11 11 untagged unblocked ge-0/0/7.0 up v12 12 untagged unblocked ge-0/0/8.0 up v11 11 tagged unblocked v12 12 tagged unblocked v21 21 tagged unblocked v22 22 tagged unblocked ge-0/0/9.0 up default untagged unblocked ge-0/0/10.0 up v11 11 tagged blocked by STP v12 12 tagged blocked by STP v21 21 tagged blocked by STP v22 22 tagged blocked by STP What are the interface and blocking states for ge-0/0/9.0? The interface and blocking states for interface ge-0/0/9.0 should be up and unblocked respectively. Step 4.6 Return to your assigned SRX Series device. On your SRX Series device, enter configuration mode and navigate to the [edit interfaces] hierarchy level. lab@srxa-1> configure Entering configuration mode [edit] lab@srxa-1# edit interfaces [edit interfaces] lab@srxa-1# Activate the ge-0/0/9 interface. Next, issue the commit command to activate the configuration change. [edit interfaces] lab@srxa-1# show ge-0/0/9 ## ## inactive: interfaces ge-0/0/9 ## unit 0 { family ethernet-switching { port-mode trunk; vlan { members all; 19
[edit interfaces] lab@srxa-1# activate ge-0/0/9 [edit interfaces] lab@srxa-1# commit commit complete Step 4.7 Return to your assigned exx-1 Series switch and issue the run show ethernet-switching interfaces command to determine the current state of the ge-0/0/9.0 interface. {master:0[edit protocols rstp] lab@exa-1# run show ethernet-switching interfaces Interface State VLAN members Tag Tagging Blocking ge-0/0/1.0 down default untagged blocked by STP ge-0/0/6.0 up v11 11 untagged unblocked ge-0/0/7.0 up v12 12 untagged unblocked ge-0/0/8.0 up v11 11 tagged unblocked v12 12 tagged unblocked v21 21 tagged unblocked v22 22 tagged unblocked ge-0/0/9.0 down default untagged Disabled by bpdu-control ge-0/0/10.0 up v11 11 tagged blocked by STP v12 12 tagged blocked by STP v21 21 tagged blocked by STP v22 22 tagged blocked by STP What are the interface and blocking states for ge-0/0/9.0? Step 4.8 The interface and blocking states for interface ge-0/0/9.0 should be down and disabled by bpdu-control respectively. Issue the run show spanning-tree interface ge-0/0/9.0 detail command. {master:0[edit protocols rstp] lab@exa-1# run show spanning-tree interface ge-0/0/9.0 detail Spanning tree interface parameters for instance 0 Interface name : ge-0/0/9.0 Port identifier : 128.522 Designated port ID : 128.522 Port cost : 20000 Port state : Blocking Designated bridge ID : 32768.00:23:9c:13:a8:41 20
Port role : Disabled (Bpdu-Inconsistent) Link type : Pt-Pt/EDGE Boundary port : NA Edge delay while expiry count : 2 Rcvd info while expiry count : 0 What is the state and role of ge-0/0/9.0? Currently, the ge-0/0/9.0 interface should show the Blocking state and Disabled (Bpdu-Inconsistent) port role. Step 4.9 Return to your assigned srxx-1 Series device and deactivate again the ge-0/0/9 interface. Next, issue the commit and-quit command to activate the configuration change and return to operational mode. [edit interfaces] lab@srxa-1# deactivate ge-0/0/9 [edit interfaces] lab@srxa-1# show ge-0/0/9 ## ## inactive: interfaces ge-0/0/9 ## unit 0 { family ethernet-switching { port-mode trunk; vlan { members all; [edit interfaces] lab@srxa-1# commit and-quit commit complete Exiting configuration mode Step 4.10 Return to your assigned exx-1 Series switch and clear the current BPDU error condition. Next, issue the run show ethernet-switching interfaces ge-0/0/9.0 command to verify the error condition has been cleared. 21
{master:0[edit protocols rstp] lab@exa-1# run clear ethernet-switching bpdu-error {master:0[edit protocols rstp] lab@exa-1# run show ethernet-switching interfaces ge-0/0/9.0 Interface State VLAN members Tag Tagging Blocking ge-0/0/9.0 up default untagged unblocked Has the error condition been administratively removed? Yes, as shown in the sample output, the error condition should now be gone thanks to the illustrated clear command. If the error condition persists, check the configurations on your assigned devices. Part 5: Configuring and Monitoring MSTP Step 5.1 In this lab part, you configure and monitor MSTP. You create two multiple spanning-tree instances (MSTIs); one for VLAN IDs 11 and 21, and a second for VLAN IDs 12 and 22. Once configured, you use various operational mode commands to monitor MSTP Return to your EX devices and delete RSTP, under the [edit protocols] hierarchy. {master:0[edit protocols rstp] lab@exa-1# up {master:0[edit protocols] lab@exa-1# delete rstp {master:0[edit protocols] lab@exa-1# Step 5.2 Configure MSTP to include two MSTIs (MSTI 1 and MSTI 2). Associate MSTI 1 with VLAN IDs 11 and 21 and associate MSTI 2 with VLAN IDs 12 and 22. Name the MSTP configuration my-mstpconfig. Activate the configuration using commit {master:0[edit protocols] lab@exa-1# set mstp configuration-name my-mstp-config {master:0[edit protocols] lab@exa-1# set mstp msti 1 vlan [11 21] {master:0[edit protocols] lab@exa-1# set mstp msti 2 vlan [12 22] 22
{master:0[edit protocols] lab@exa-1# show mstp { configuration-name my-mstp-config; msti 1 { vlan [ 11 21 ]; msti 2 { vlan [ 12 22 ]; {master:0[edit protocols] lab@exa-1# commit configuration check succeeds commit complete Ensure you perform identical configuration steps on your other assigned EX switch device; that is delete the rstp protocol and configure mstp with identical parameters as in your exx-1 device. To be quick, you could make use of the show display function of exx-1 so you can copy & paste the relevant commands in your other switch {master:0[edit protocols] lab@exa-1# show display set set protocols mstp configuration-name my-mstp-config set protocols mstp msti 1 vlan 11 set protocols mstp msti 1 vlan 21 set protocols mstp msti 2 vlan 12 set protocols mstp msti 2 vlan 22 Step 5.3 Return to your assigned srxx-1 device, enter configuration mode and navigate to [edit protocols] hierarchy and delete the existing RSTP configuration. lab@srxa-1> configure Entering configuration mode [edit] lab@srxa-1# edit protocols [edit protocols] lab@srxa-1# delete rstp Step 5.4 Once more, configure MSTP in your srxx-1 device to include two MSTIs (MSTI 1 and MSTI 2). Associate MSTI 1 with VLAN IDs 11 and 21 and associate MSTI 2 with VLAN IDs 12 and 22. Name the MSTP configuration my-mstp-config. [edit protocols] lab@srxa-1# set mstp configuration-name my-mstp-config [edit protocols] lab@srxa-1# set mstp msti 1 vlan [11 21] 23
[edit protocols] lab@srxa-1# set mstp msti 2 vlan [12 22] Step 5.5 Note Repeat identical steps 5.3 and 5.4 on your srxx-2 device Configure a non-default bridge priority for each MSTI. On your assigned srxx-1, specify a bridge priority of 4k for MSTI 1 and 8k for MSTI 2. On your assigned srxx-2, specify a bridge priority of 8k for MSTI 1 and 4k for MSTI 2. Activate the changes and return to operational mode using the commit and-quit command. The following captures illustrate the commands and expected configurations for both SRX Series devices in Pod A: [edit protocols] lab@srxa-1# set mstp msti 1 bridge-priority 4k [edit protocols] lab@srxa-1# set mstp msti 2 bridge-priority 8k [edit protocols] lab@srxa-1# show mstp { configuration-name my-mstp-config; msti 1 { bridge-priority 4k; vlan [ 11 21 ]; msti 2 { bridge-priority 8k; vlan [ 12 22 ]; [edit protocols] lab@srxa-1# commit and-quit commit complete Exiting configuration mode And here is the configuration on the srxx-2: [edit protocols] lab@srxa-2# set mstp msti 1 bridge-priority 8k [edit protocols] lab@srxa-2# set mstp msti 2 bridge-priority 4k [edit protocols] lab@srxa-2# show 24
mstp { configuration-name my-mstp-config; msti 1 { bridge-priority 8k; vlan [ 11 21 ]; msti 2 { bridge-priority 4k; vlan [ 12 22 ]; [edit protocols] lab@srxa-2# commit and-quit commit complete Exiting configuration mode Based on the current configurations, what forwarding paths would you expect for traffic associated with the various VLANs currently in use? Step 5.6 The spanning-tree topology now offers some level of load balancing for the defined VLANs. Based on the current configurations, all traffic associated with VLAN ID 11 and 21 should pass through srxx-1. The traffic associated with the other VLAN IDs 12 & 21 should pass through srxx-2 Return to your assigned exx-1 switch and issue the command run show spanning-tree bridge to answer the questions that follow: {master:0[edit protocols] lab@exa-1# run show spanning-tree bridge STP bridge parameters Context ID : 0 Enabled protocol : MSTP STP bridge parameters for CIST Root ID : 32768.00:23:9c:13:91:81 Root cost : 0 Root port : ge-0/0/10.0 CIST regional root : 32768.00:23:9c:13:91:81 CIST internal root cost : 40000 Hello time : 2 seconds Maximum age : 20 seconds Forward delay : 15 seconds Hop count : 18 Message age : 0 Number of topology changes : 8 Time since last topology change : 622 seconds 25
Topology change initiator : ge-0/0/10.0 Topology change last recvd. from : 00:26:88:e9:d2:88 Local parameters Bridge ID : 32768.00:23:9c:13:a8:41 Extended system ID : 0 Internal instance ID : 0 STP bridge parameters for MSTI 1 MSTI regional root : 4097.00:26:88:02:74:90 Root cost : 20000 Root port : ge-0/0/8.0 Hello time : 2 seconds Maximum age : 20 seconds Forward delay : 15 seconds Hop count : 19 Number of topology changes : 11 Time since last topology change : 622 seconds Topology change initiator : ge-0/0/8.0 Topology change last recvd. from : 00:26:88:e9:d5:0a Local parameters Bridge ID : 32769.00:23:9c:13:a8:41 Extended system ID : 0 Internal instance ID : 1 STP bridge parameters for MSTI 2 MSTI regional root : 4098.00:26:88:02:6b:90 Root cost : 20000 Root port : ge-0/0/10.0 Hello time : 2 seconds Maximum age : 20 seconds Forward delay : 15 seconds Hop count : 19 Number of topology changes : 9 Time since last topology change : 622 seconds Topology change initiator : ge-0/0/10.0 Topology change last recvd. from : 00:26:88:e9:d2:88 Local parameters Bridge ID : 32770.00:23:9c:13:a8:41 Extended system ID : 0 Internal instance ID : 2 Are the expected devices elected root bridges for MSTI 1 and MSTI 2? The answer should be yes. The srxx-1 device should be elected root bridge for MSTI 1 and the srxx-2 device should be elected root bridge for MSTI 2. If you see different results, check your configuration and you have performed all steps in the 4 devices assigned to you. 26
Which device has been elected as the root bridge for the Common and Internal Spanning Tree (CIST)? The answer might vary. In the illustrated example, exa-2 has been elected as the root bridge for the CIST (MSTI 0). What configuration change can you make to ensure srxx-1 is always the root bridge as long as it is available? Step 5.7 To ensure one device is always the root bridge when it is available, you must ensure the bridge priority for that device is set to a lower value than all other switches participating in the MSTP region. In order to check that all is well and no layer 2 loops exist in the network, check it from your srxx-1 device by using the ping utility and attempting to ping the IP addresses assigned to the VLAN interfaces defined on your EX Series switch Refer to the network diagram for this lab, if needed. lab@srxa-1> ping 172.23.11.100 count 10 rapid PING 172.23.11.100 (172.23.11.100): 56 data bytes!!!!!!!!!! --- 172.23.11.100 ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.227/1.449/1.878/0.216 ms lab@srxa-1> ping 172.23.12.100 count 10 rapid PING 172.23.12.100 (172.23.12.100): 56 data bytes!!!!!!!!!! --- 172.23.12.100 ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.202/1.419/1.907/0.224 ms Do the ping tests succeed? Yes, the ping tests should succeed 27
Step 5.8 Verify that MSTP has converged with a loop-free topology. Issue the run show spanning-tree interface command to determine the state and role of each switch port. View each MSTI independently. Take note of the spanning tree that has been built for each. {master:0[edit protocols] lab@exa-1# run show spanning-tree interface Spanning tree interface parameters for instance 0 Interface Port ID Designated Designated Port State Role port ID bridge ID Cost ge-0/0/6.0 128:519 128:519 32768.00239c13a841 20000 FWD DESG ge-0/0/7.0 128:520 128:520 32768.00239c13a841 20000 FWD DESG ge-0/0/8.0 128:521 128:521 32768.002688027490 20000 BLK ALT ge-0/0/10.0 128:523 128:523 32768.002688026b90 20000 FWD ROOT Spanning tree interface parameters for instance 1 Interface Port ID Designated Designated Port State Role port ID bridge ID Cost ge-0/0/6.0 128:519 128:519 32769.00239c13a841 20000 FWD DESG ge-0/0/8.0 128:521 128:521 4097.002688027490 20000 FWD ROOT ge-0/0/10.0 128:523 128:523 8193.002688026b90 20000 BLK ALT Spanning tree interface parameters for instance 2 Interface Port ID Designated Designated Port State Role port ID bridge ID Cost ge-0/0/7.0 128:520 128:520 32770.00239c13a841 20000 FWD DESG ge-0/0/8.0 128:521 128:521 8194.002688027490 20000 BLK ALT ge-0/0/10.0 128:523 128:523 4098.002688026b90 20000 FWD ROOT Has MSTP converged with a loop-free topology? Yes. MSTP should have created a loop free topology. If not, go back and check your work. Does your switch currently have any ports in the blocking (BLK) state? If so, which interfaces? Yes, do notice that there are different port states for each one of the MSTI topologies. 28
That is the main goal of MSTP, to create a different spanning-tree topology for each set of VLANs that belong to an MST instance (MSTI) What is the default port cost for each interface? The default port cost for every interface is 20,000. Step 5.9 On your assigned exx-1 Series switch, issue the run show spanning-tree mstp configuration command. {master:0[edit protocols] lab@exa-1# run show spanning-tree mstp configuration MSTP information Context identifier : 0 Region name : my-mstp-config Revision : 0 Configuration digest : 0x4428410bc7f1759df29e08ab39ad805e MSTI Member VLANs 0 0-10,13-20,23-4094 1 11,21 2 12,22 Does the output display the expected VLAN to MSTI mapping information? Yes, the output should show the correct VLAN to MSTI mapping information. You should see the previously configured ranges for MSTI 1 and MSTI 2 (11 & 21 and 12 & 22 respectively) and the remainder of the supported VLAN ID range associated with the CIST (MSTI 0). Which three components in the displayed output must match for switches participating in the same MST region? 29
The region name, revision level, and the VLAN to MSTI mappings must match on all bridges participating in the same MST region. How is the configuration digest determined? The configuration digest is based on the VLAN to MSTI mapping information. Note that this mapping information must match on all switches intending to participate in the same MST region. Step 5.10 Return to your exx-1 device and change the revision level to test the effects of mismatched settings that are required to match on switches participating in the same MST region. On exx-1, set your revision number to 2. Issue commit to activate the configuration change. {master:0[edit protocols] lab@exa-1# set mstp revision-level 2 {master:0[edit protocols] lab@exa-1# commit configuration check succeeds commit complete Step 5.11 Issue the run show spanning-tree mstp configuration command to verify the change. Next issue the run show spanning-tree bridge command to verify the current state of the MSTP topology and root bridge election details. {master:0[edit protocols] lab@exa-1# run show spanning-tree mstp configuration MSTP information Context identifier : 0 Region name : my-mstp-config Revision : 2 Configuration digest : 0x4428410bc7f1759df29e08ab39ad805e MSTI Member VLANs 0 0-10,13-20,23-4094 1 11,21 2 12,22 {master:0[edit protocols] lab@exa-1# run show spanning-tree bridge 30
STP bridge parameters Context ID : 0 Enabled protocol : MSTP STP bridge parameters for CIST Root ID : 32768.00:23:9c:13:91:81 Root cost : 40000 Root port : ge-0/0/10.0 CIST regional root : 32768.00:23:9c:13:a8:41 CIST internal root cost : 0 Hello time : 2 seconds Maximum age : 20 seconds Forward delay : 15 seconds Hop count : 20 Message age : 2 Number of topology changes : 14 Time since last topology change : 2099 seconds Topology change initiator : ge-0/0/10.0 Topology change last recvd. from : 00:26:88:e9:d2:88 Local parameters Bridge ID : 32768.00:23:9c:13:a8:41 Extended system ID : 0 Internal instance ID : 0 STP bridge parameters for MSTI 1 MSTI regional root : 32769.00:23:9c:13:a8:41 Hello time : 2 seconds Maximum age : 20 seconds Forward delay : 15 seconds Number of topology changes : 18 Time since last topology change : 2099 seconds Topology change initiator : ge-0/0/10.0 Topology change last recvd. from : 00:26:88:e9:d5:0a Local parameters Bridge ID : 32769.00:23:9c:13:a8:41 Extended system ID : 0 Internal instance ID : 1 STP bridge parameters for MSTI 2 MSTI regional root : 32770.00:23:9c:13:a8:41 Hello time : 2 seconds Maximum age : 20 seconds Forward delay : 15 seconds Number of topology changes : 15 Time since last topology change : 2099 seconds Topology change initiator : ge-0/0/10.0 Topology change last recvd. from : 00:26:88:e9:d2:88 Local parameters Bridge ID : 32770.00:23:9c:13:a8:41 Extended system ID : 0 Internal instance ID : 2 What impact did changing the revision level have on the MSTP topology and root bridge election for MSTI 1 and MSTI 2? 31
Because the required settings on the EX Series switches no longer match the other devices within the MST region, each EX Series switch is effectively running in isolation in new MST regions that are based on new settings. This arrangement is verified by the newly elected root bridge in each MSTI. In the sample capture, we see that exx-1 is now the elected root bridge for MSTI 1 and MSTI 2. Note that exx-2 should show a similar output with itself elected root bridge for both MSTIs Part 6: Configuring and Monitoring VSTP Step 6.1 In this lab part, you configure and monitor VSTP. Once configured, you use various operational mode commands to verify VSTP operations. Note that SRX Series devices do not currently support VSTP. Because of this fact, you must alter the current topology to exclude the SRX Series devices for this lab part. Issue the set rstp and commit commands in an attempt to enable RSTP along with MSTP. {master:0[edit protocols] lab@exa-1# set rstp {master:0[edit protocols] lab@exa-1# commit [edit protocols] 'mstp' Another xstp protocol is enabled error: Another xstp protocol is enabled error: configuration check-out failed Did the commit operation succeed? If not, why not? Step 6.2 No, the commit operation should not succeed because RSTP and MSTP cannot be enabled at the same time. Note that RSTP can, however, be enabled at the same time as VSTP. Delete MSTP and attempt the commit operation once again. {master:0[edit protocols] lab@exa-1# delete mstp {master:0[edit protocols] lab@exa-1# commit 32
configuration check succeeds commit complete Step 6.3 Note Repeat identical steps on your other exx-2 device Configure VSTP to support the currently defined VLANs independently. Refer to the following table for the bridge-priority values. Once finished go ahead and commit your configuration. VLAN exx-1 exx-2 v11 4k 8k v12 8k 4k v21 4k 8k v22 8k 4k {master:0[edit protocols] lab@exa-1# set vstp vlan v11 bridge-priority 4k {master:0[edit protocols] lab@exa-1# set vstp vlan v12 bridge-priority 8k {master:0[edit protocols] lab@exa-1# set vstp vlan v21 bridge-priority 4k {master:0[edit protocols] lab@exa-1# set vstp vlan v22 bridge-priority 8k {master:0[edit protocols] lab@exa-1# show rstp; vstp { vlan v11 { bridge-priority 4k; vlan v12 { bridge-priority 8k; vlan v21 { bridge-priority 4k; vlan v22 { bridge-priority 8k; {master:0[edit protocols] lab@exa-1# commit and-quit configuration check succeeds 33
commit complete Exiting configuration mode Step 6.4 Note Do not forget to also configure VSTP on your other exx-2 device with the priorities indicated in the table above Issue show spanning-tree bridge command once again to determine the current root bridge designations for each VLAN. {master:0[edit protocols] lab@exa-1# run show spanning-tree bridge STP bridge parameters Context ID : 0 Enabled protocol : RSTP Root ID : 32768.00:23:9c:13:a8:41 Hello time : 2 seconds Maximum age : 20 seconds Forward delay : 15 seconds Message age : 0 Number of topology changes : 2 Time since last topology change : 12 seconds Topology change last recvd. from : 00:26:88:e9:d5:0a Local parameters Bridge ID Extended system ID : 0 Internal instance ID : 0 STP bridge parameters Context ID : 3 Enabled protocol : RSTP : 32768.00:23:9c:13:a8:41 STP bridge parameters for VLAN 11 Root ID : 4107.00:23:9c:13:a8:41 Hello time : 2 seconds Maximum age : 20 seconds Forward delay : 15 seconds Message age : 0 Number of topology changes : 1 Time since last topology change : 10 seconds Topology change initiator : ge-0/0/8.0 Topology change last recvd. from : 00:23:9c:13:a8:4b Local parameters Bridge ID : 4107.00:23:9c:13:a8:41 Extended system ID : 3 Internal instance ID : 0 STP bridge parameters Context ID : 4 Enabled protocol : RSTP STP bridge parameters for VLAN 12 Root ID : 4108.00:23:9c:13:91:81 Root cost : 20000 34
Root port : ge-0/0/8.0 Hello time : 2 seconds Maximum age : 20 seconds Forward delay : 15 seconds Message age : 1 Number of topology changes : 1 Time since last topology change : 10 seconds Topology change initiator : ge-0/0/8.0 Topology change last recvd. from : 00:23:9c:13:a8:4b Local parameters Bridge ID : 8204.00:23:9c:13:a8:41 Extended system ID : 4 Internal instance ID : 0 STP bridge parameters Context ID : 5 Enabled protocol : RSTP STP bridge parameters for VLAN 21 Root ID : 4117.00:23:9c:13:a8:41 Hello time : 2 seconds Maximum age : 20 seconds Forward delay : 15 seconds Message age : 0 Number of topology changes : 1 Time since last topology change : 10 seconds Topology change initiator : ge-0/0/8.0 Topology change last recvd. from : 00:23:9c:13:a8:4b Local parameters Bridge ID : 4117.00:23:9c:13:a8:41 Extended system ID : 5 Internal instance ID : 0 STP bridge parameters Context ID : 6 Enabled protocol : RSTP STP bridge parameters for VLAN 22 Root ID : 4118.00:23:9c:13:91:81 Root cost : 20000 Root port : ge-0/0/8.0 Hello time : 2 seconds Maximum age : 20 seconds Forward delay : 15 seconds Message age : 1 Number of topology changes : 1 Time since last topology change : 10 seconds Topology change initiator : ge-0/0/8.0 Topology change last recvd. from : 00:23:9c:13:a8:4b Local parameters Bridge ID : 8214.00:23:9c:13:a8:41 Extended system ID : 6 Internal instance ID : 0 Are the correct root bridges now elected? 35
Step 6.5 Yes, the expected root bridges should be elected. Based on the current configuration, exx-1 should be root bridge for the v11 and v21 VLANs and exx-2 should be root bridge for the v12 and v22 VLANs. Note that on top of that, there is an additional RSTP instance for the rest of the VLANs. If your results do not match the expected results, check your configuration. Issue the run show spanning-tree interface command to determine the state and role of each switch port. View each VSTP independently. Take note of the spanning tree that has been built for each. {master:0[edit protocols] lab@exa-1# run show spanning-tree interface Spanning tree interface parameters for VLAN 11 Interface Port ID Designated Designated Port State Role port ID bridge ID Cost ge-0/0/6.0 128:519 128:519 4107.00239c13a841 20000 FWD DESG ge-0/0/8.0 128:521 128:521 4107.00239c13a841 20000 FWD DESG ge-0/0/10.0 128:523 128:521 4107.00239c13a841 20000 BLK BKUP Spanning tree interface parameters for VLAN 12 Interface Port ID Designated Designated Port State Role port ID bridge ID Cost ge-0/0/7.0 128:520 128:520 8204.00239c13a841 20000 FWD DESG ge-0/0/8.0 128:521 128:521 4108.00239c139181 20000 FWD ROOT ge-0/0/10.0 128:523 128:521 4108.00239c139181 20000 BLK ALT Spanning tree interface parameters for VLAN 21 Interface Port ID Designated Designated Port State Role port ID bridge ID Cost ge-0/0/8.0 128:521 128:521 4117.00239c13a841 20000 FWD DESG ge-0/0/10.0 128:523 128:521 4117.00239c13a841 20000 BLK BKUP Spanning tree interface parameters for VLAN 22 Interface Port ID Designated Designated Port State Role port ID bridge ID Cost ge-0/0/8.0 128:521 128:521 4118.00239c139181 20000 FWD ROOT ge-0/0/10.0 128:523 128:521 4118.00239c139181 20000 BLK ALT Has VSTP converged with a loop-free topology? 36
Yes. VSTP should have created an individual loop free topology for each VLAN. Which topology will be used for a VLAN out of the range specified on the VSTP configuration? For any VLAN not explicitly configured to belong to a particular VSTP the switch will be using the global RSTP topology. You can check that for the vlan-id 5 for instance: {master:0[edit protocols] lab@exa-1# run show spanning-tree bridge vlan-id 5 STP bridge parameters Context ID : 0 Enabled protocol : RSTP Root ID : 32768.00:23:9c:13:a8:41 Hello time : 2 seconds Maximum age : 20 seconds Forward delay : 15 seconds Message age : 0 Number of topology changes : 0 Local parameters Bridge ID : 32768.00:23:9c:13:a8:41 Extended system ID : 0 Internal instance ID : 0 Step 6.6 Log out of all your assigned EX Series switches and SRX devices. {master:0[edit protocols] lab@exa-1# top {master:0[edit] lab@exa-1# exit Exiting configuration mode {master:0 lab@exa-1> exit exa-1 (ttyu0) login: STOP You have completed Lab 2! 37