Junos Switching Basics

(1)

1194 North Mathilda Avenue

Sunnyvale, CA 94089

USA

408-745-2000

www.juniper.net

Worldwide Education Services

Lab Guide

(2)

Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.

Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice. YEAR 2000 NOTICE

Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The Junos operating system has no known time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.

SOFTWARE LICENSE

The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable, in an agreement executed between you and Juniper Networks, or Juniper Networks agent. By using Juniper Networks software, you indicate that you understand and agree to be bound by its license terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the Juniper Networks software, may contain prohibitions against certain uses, and may state conditions under which the license is automatically terminated. You should consult the software license for further details.

Junos Switching Basics Lab Guide, Revision A

The information in this document is current as of the date listed above.

(3)

(4)

(5)

The new enterprise Ethernet switching features of the Junos OS now make it possible to operate Juniper Networks enterprise switches with the same operating system you already use to manage the routers on your network.

Objectives

In this course, we focus on EX Series switches and the Layer 2 configuration syntax that provides enterprises the ability to quickly configure Layer 2 features most appropriate for the enterprise environment. The course covers the following topics:

• Interface Configuration; • Switching Configuration; • Monitoring; • Security; and • Virtual Chassis.

Intended Audience

(6)

CLI and GUI Text

Frequently throughout this course, we refer to text that appears in a command-line interface (CLI) or a graphical user interface (GUI). To make the language of these documents easier to read, we distinguish GUI and CLI text from chapter text according to the following table.

Input Text Versus Output Text

You will also frequently see cases where you must enter input text yourself. Often this will be shown in the context of where you must enter it. We use bold style to distinguish text that is input versus text that is simply displayed.

Style Description Usage Example

Franklin Gothic

Normal text. Most of what you read in the Lab

Guide and Student Guide. Courier New Console text: • Screen captures • Noncommand-related syntax GUI text elements:

• Menu names

• Text field entry

commit complete

Exiting configuration mode

Select File > Open, and then click Configuration.conf in the Filename text box.

Normal CLI Normal GUI

No distinguishing variant. Physical interface:fxp0,

Enabled

View configuration history by clicking Configuration > History.

CLI Input GUI Input

Text that you must enter. lab@San_Jose> show route

Select File > Save, and enter

config.ini in the Filename

(7)

distinguishes between syntax variables where the value is already assigned (defined variables) and syntax variables where you must assign the value (undefined variables). Note that these styles can be combined with the input style as well.

CLI Variable GUI variable

Text where variable value is already

assigned. policy my-peers

Click my-peers in the dialog.

CLI Undefined GUI Undefined

Text where the variable’s value is the user’s discretion and text where the variable’s value as shown in the lab guide might differ from the value the user must input.

Type set policy

policy-name.

ping 10.0.x.y

Select File > Save, and enter

(8)

Education Services Offerings

You can obtain information on the latest Education Services offerings, course dates, and class locations from the World Wide Web by pointing your Web browser to:

http://www.juniper.net/training/education/.

About This Publication

The Junos Switching Basics Lab Guide was developed and tested using software Release 10.0R1.8. Previous and later versions of software might behave differently so you should always consult the documentation and release notes for the version of code you are running before reporting errors.

This document is written and maintained by the Juniper Networks Education Services development team. Please send questions and suggestions for improvement to [email protected].

Technical Publications

You can print technical manuals and release notes directly from the Internet in a variety of formats:

• Go to http://www.juniper.net/techpubs/.

• Locate the specific software or hardware release and title you need, and choose

the format in which you want to view or print the document.

Documentation sets and CDs are available through your local Juniper Networks sales office or account representative.

Juniper Networks Support

(9)

Introduction to the Juniper Networks Virtual Lab

Overview

This lab shows the basic procedures for how to access the Juniper Networks Virtual Lab (vLab) using a standard Web browser.

The Purpose of the Virtual Labs

The Virtual Labs help partners receive hands-on training through a virtual portal which is available 24 hours a day, 7 days a week. This is not a simulator, but live equipment to promote learning and development for interested partners to the Juniper Networks Partner Learning Academy.

JNSS labs are an online class with a series of modules and lab exercises to assist a student to become proficient at installing, configuring, and troubleshooting Juniper products. Each course design takes approximately 8 hours to complete. Once connected to the JNSS site, you will need to register (with a valid e-mail address) and then log in.

Access is granted on a first come, first served basis through the training section of the Partner Center. The Virtual Labs (vLabs) are also available for dedicated Leader Led courses on an as needed basis. The system will check to see if one of the selected labs is available. If a vLab is available, access is granted. If no lab is available, you will be asked to try again later.

Each of the vLabs is duplicated multiple times. In the case of the Router/Firewall lab there are extra cross connects between the labs so that in a classroom environment they can be connected in interesting network topologies.

Note

(10)

The first step in accessing the Virtual Lab is to login to the Virtual Lab homepage. To access the Virtual Lab home page, copy and paste the below URL into a browser window:

https://virtuallabs.juniper.net

Part 2: Accepting the EULA

You will need to accept the End User License Agreement to log in and begin your work in the Virtual Lab.

Part 3: Logging in to the TrueLab Manager

If you are already logged in to the Partner Learning Academy on the Juniper Partner Center, you will not need to log in to TrueLab Manager. However, if you are not logged in to the Partner Center, you can log in on this screen.

(11)

Next, you must specify a time zone. Once your correct time zone has been specified, click Update in the bottom left corner of the screen.

Step 4.1

(12)

You will then create a session under the Sessions tab and select the lab that you want to use.

First, identify the correct row for your course under the Event heading. Next, select the course title from the Purpose drop down menu under the Session Information column and click Open.

Note

(13)

(14)

Step 6.2

Click Finish to return to the Sessions tab.

Part 7: Starting the Session

Once the Start Session Now link has been clicked (under the session link), you will be prompted to click OK to continue and log in.

Note

(15)

Step 7.1

Click OK to see the following screen.

Each session can be a maximum of 3 hours.

Note

(16)

virtual desktop, you must double-click on the Secure CRT icon to begin your lab.

Note

(17)

Part 8: Additional Information and Feedback

Connection Test

You can test your ability to connect by navigating to http://truelab.hatsize.com/syscheck/. Virtual Lab Support

For support, please call 1-866-933-5487 (207-319-1142 if outside North America) Go to: https://support.hatsize.com/

Or send an e-mail to [email protected] Feedback

If you would like to provide feedback on ways we can improve your vLab experience, please an e-mail to [email protected].

STOP

Note

Make sure that you consult your lab guide before opening any of the VT100 terminal sessions.

(18)

(19)

Configuring and Monitoring Interfaces

Overview

In this lab, you use the CLI to perform basic interface configuration. By completing this lab, you will perform the following tasks:

• Perform basic interface configuration.

• Configure an aggregated Ethernet interface.

(20)

Part 1: Configuring Interfaces and Verifying Operational State

The objective of this lab part is to perform interface configuration and verify the operational state of interfaces using the Junos OS CLI.

Step 1.1

Access the CLI using SecureCRT. Double click on the SecureCRT 5.0 icon located on the desktop to open the connection manager. Highlight EX1 and click the connect button.

Step 1.2

Log in as user lab with the password lab123. switch1-d (ttyu0)

login: lab Password:

--- JUNOS 10.1R2.8 built 2010-05-11 04:08:08 UTC {master:0}

lab@switch1-d>

Step 1.3

Issue the show interfaces terse CLI command to check the state of your device’s interfaces.

{master:0}

lab@switch1-d> show interfaces terse

(21)

ge-0/0/6 up up ge-0/0/7 up up ge-0/0/8 up up ge-0/0/9 up up ge-0/0/10 up up ge-0/0/11 up up ge-0/0/12 up up ge-0/0/13 up up ge-0/0/14 up up ge-0/0/15 up up ge-0/0/16 up down ge-0/0/17 up down ge-0/0/18 up down ge-0/0/19 up down ge-0/0/20 up down ge-0/0/21 up down ge-0/0/22 up down ge-0/0/23 up down xe-0/1/0 up down vcp-0 down down vcp-0.32768 up down vcp-1 down down vcp-1.32768 up down bme0 up up bme0.32768 up up inet 128.0.0.1/2 128.0.0.16/2 128.0.0.32/2 tnp 0x10 dsc up up gre up up ipip up up lo0 up up lsi up up me0 up up me0.0 up up inet 10.210.14.147/27 mtun up up pimd up up pime up up tap up up vlan up up vme up down

Notice that several interfaces are up, but only the me0 interface has been configured. The bme0 interface is an internal interface an can safely be ignored. Your output may vary.

Step 1.4

Enter configuration mode and navigate to the [edit interfaces] hierarchy. {master:0}

lab@switch1-d> configure Entering configuration mode {master:0}[edit]

(22)

{master:0}[edit interfaces] lab@switch1-d#

Step 1.5

Configure the lo0.0 interface for layer 3 operations using the IP address referenced in the network diagram for this lab.

{master:0}[edit interfaces]

lab@switch1-d# set lo0 unit 0 family inet address 192.168.3.1/32

Step 1.6

Configure the ge-0/0/6.0 interface for layer 2 operations. Specify a link-speed of 1Gbps and a duplex setting of full.

lab@switch1-d# set ge-0/0/6 unit 0 family ethernet-switching {master:0}[edit interfaces]

lab@switch1-d# set ge-0/0/6 ether-options link-mode full-duplex {master:0}[edit interfaces]

lab@switch1-d# set ge-0/0/6 ether-options speed 1g {master:0}[edit interfaces]

lab@switch1-d# show ge-0/0/6 ether-options { link-mode full-duplex; speed { 1g; } } unit 0 { family ethernet-switching; }

Step 1.7

Use the copy command to replicate the configuration associated with the ge-0/0/6 interface to the ge-0/0/7 and ge-0/0/8 interfaces.

lab@switch1-d# copy ge-0/0/6 to ge-0/0/7 {master:0}[edit interfaces]

(23)

} unit 0 { family ethernet-switching; } } ge-0/0/7 { ether-options { link-mode full-duplex; speed { 1g; } } unit 0 { family ethernet-switching; } } ge-0/0/8 { ether-options { link-mode full-duplex; speed { 1g; } } unit 0 { family ethernet-switching; } } lo0 { unit 0 { family inet { address 192.168.3.1/32; } } } me0 { unit 0 { family inet { address 10.210.14.147/27; } } }

Step 1.8

Activate the configuration and issue the run show interfaces terse CLI command to verify the state of the configured interfaces.

{master:0}[edit interfaces] lab@switch1-d# commit

configuration check succeedscommit complete {master:0}[edit interfaces]

lab@switch1-d# run show interfaces terse

(24)

(25)

Question: What is the Admin and Link state of the recently configured interfaces?

Answer: All configured interfaces should show an Admin and Link state of up, as shown in the sample capture.

Step 1.9

Issue the run show interfaces ge-0/0/6 command and answer the question that follows.

lab@switch1-d# run show interfaces ge-0/0/6

Physical interface: ge-0/0/6, Enabled, Physical link is Up Interface index: 135, SNMP ifIndex: 118

Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps, Duplex: Full-Duplex, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled,

Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Enabled,

Remote fault: Online

Device flags : Present Running

Interface flags: SNMP-Traps Internal: 0x0 Link flags : None

CoS queues : 8 supported, 8 maximum usable queues

Current address: 00:19:e2:51:65:86, Hardware address: 00:19:e2:51:65:86 Last flapped : 2010-02-25 14:37:39 UTC (00:02:29 ago)

Input rate : 0 bps (0 pps) Output rate : 0 bps (0 pps) Active alarms : None

Active defects : None

Logical interface ge-0/0/6.0 (Index 65) (SNMP ifIndex 509) Flags: SNMP-Traps Encapsulation: ENET2

Input packets : 0 Output packets: 0 Protocol eth-switch Flags: Is-Primary

Question: What are the speed and duplex settings according to the displayed output?

Answer: The link and speed and duplex settings should show 1000mbps and Full-Duplex respectively. By default, interfaces on EX Series switches auto negotiate speed and duplex as shown in the following output: {master:0}[edit interfaces]

lab@switch1-d# run show interfaces ge-0/0/0

(26)

Interface index: 129, SNMP ifIndex: 125

Link-level type: Ethernet, MTU: 1514, Speed: Auto, Duplex: Auto, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled,

Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Enabled,

Remote fault: Online

Device flags : Present Running

Interface flags: Hardware-Down SNMP-Traps Internal: 0x0 Link flags : None

CoS queues : 8 supported, 8 maximum usable queues

Current address: 00:19:e2:51:65:80, Hardware address: 00:19:e2:51:65:80 Last flapped : Never

Input rate : 0 bps (0 pps) Output rate : 0 bps (0 pps) Active alarms : LINK

Active defects : LINK

Part 2: Configure an Aggregated Ethernet Interface

In this part you will use the Junos CLI to configure an aggregated Ethernet interface.

Step 2.1

Issue the run show interfaces terse | match ae command to determine if any aggregated Ethernet interfaces currently exist on your device.

lab@switch1-d# run show interfaces terse | match ae {master:0}[edit interfaces]

lab@switch1-d#

Question: Does your device currently show any aggregated Ethernet interfaces?

Answer: As indicated in the sample output, your device should not currently show any aggregated Ethernet interfaces. We create a single aggregated Ethernet interface in a subsequent step.

Step 2.2

Navigate to the [edit chassis] configuration hierarchy and create a single aggregated Ethernet interface.

{master:0}[edit interfaces] lab@switch1-d# top edit chassis {master:0}[edit chassis]

(27)

lab@switch1-d#

Step 2.3

Activate the configuration and issue the run show interfaces terse | match ae command to determine if an aggregated Ethernet interface now exists on your device. {master:0}[edit chassis]

lab@switch1-d# commit

configuration check succeedscommit complete {master:0}[edit chassis]

lab@switch1-d# run show interfaces terse | match ae ae0 up down

Question: Does your device show an aggregated Ethernet interface? If so, what is the current link state of that interface?

Answer: As indicated in the sample output, your device should now show a single aggregated Ethernet interface named ae0. The current link state of ae0 should be down. Once you actually define the ae0 interface in the configuration file and associate active member links with ae0, the link state should change to up. You perform these tasks in a subsequent lab step.

Step 2.4

Return to the [edit interfaces] hierarchy level and configure the ae0.0 interface for layer 2 operations then configure ge-0/0/12 and ge-0/0/13 as member links for the ae0 interface. Activate the configuration changes and issue the run show interfaces terse

| match ae command.

{master:0}[edit chassis]

lab@switch1-d# top edit interfaces {master:0}[edit interfaces]

lab@switch1-d# set ae0 unit 0 family ethernet-switching {master:0}[edit interfaces]

lab@switch1-d# set ge-0/0/12 ether-options 802.3ad ae0 {master:0}[edit interfaces]

lab@switch1-d# set ge-0/0/13 ether-options 802.3ad ae0 {master:0}[edit interfaces]

configuration check succeedscommit complete {master:0}[edit interfaces]

(28)

ae0 up up

ae0.0 up up eth-switch {master:0}[edit interfaces]

lab@switch1-d#

Question: What is the current link state of the ae0 interface?

Answer: As indicated in the sample output, the current link state of the ae0 interface should now show up.

Part 3: Deactivate and Reactivate an Interface

In this part you will use the Junos OS CLI to deactivate and reactivate an interface.

Step 3.1

Issue the set ae0 disable command followed by the commit command to administratively disable the referenced interface.

{master:0}[edit interfaces] lab@switch1-d# set ae0 disable {master:0}[edit interfaces] lab@switch1-d# commit

configuration check succeedscommit complete

Step 3.2

Issue the run show interface ae0 terse command to verify the current state of the referenced interface.

lab@switch1-d# run show interfaces ae0 terse

Interface Admin Link Proto Local Remote ae0 down down

ae0.0 up down eth-switch

Question: What is the Admin and Link state of the ae0 interface?

Answer: The ae0 interface should show an Admin and Link state of down, as shown in the sample capture.

Step 3.3

Re-enable the ae0 interface. Next activate the configuration change and return to operational mode using the commit and-quit command.

(29)

lab@switch1-d# delete ae0 disable {master:0}[edit interfaces]

lab@switch1-d# commit and-quit

configuration check succeedscommit complete Exiting configuration mode

{master:0} lab@switch1-d>

Step 3.4

Issue the show interfaces ae0 terse command. {master:0}

lab@switch1-d> show interfaces ae0 terse

Interface Admin Link Proto Local Remote ae0 up up

ae0.0 up up eth-switch

Question: What is the Admin and Link state of the ae0 interface?

Answer: The ae0 interface should once again show an Admin and Link state of up, as shown in the capture.

(30)

(31)

Configuring and Monitoring Layer 2 Switching

Overview

In this lab, you use the CLI to perform basic VLAN configuration. By completing this lab, you will perform the following tasks:

• Configure access and trunk ports.

• Monitor switching operations.

(32)

Part 1: Configure Access and Trunk Ports

The objective of this lab part is to configure switch ports as access or trunk ports and assign them to their designated VLANs using the Junos OS CLI.

Step 1.1

Step 1.2

lab@switch1-d>

Step 1.3

Enter Configuration mode using the configure command. {master:0}

(33)

Step 1.4

Using the load override command, load the file switch1-X_L4_EXEna.config from the /root/ directory. This will load the basic configuration needed to complete the lab. Use the commit and-quit command to apply the changes and exit configuration mode. {master:0}[edit]

lab@switch1-d# load override /root/switch1-X_L4_EXEna.config {master:0}[edit]

configuration check succeedscommit complete {master:0}[edit]

lab@switch1-d#

Step 1.5

Open a new SecureCRT tab and connect to the EX2 device. Enter configuration mode and load the switch2-X_L4_EXEna.config file from the /root/ directory. Commit the changes and exit when complete.

(34)

Select EX2 from the available devices and click connect

lab@switch2-d>

Enter configuration mode. {master:0}

lab@switch2-d#

Load the configuration file and then exit. Exit the device and close the tab and return to the SRX1 device.

{master:0}[edit]

{master:0}

(35)

Step 1.6

Enter configuration mode and navigate to the [edit vlans] hierarchy level. Consult the network diagram for this lab and define the VLANs designated for your switch.

{master:0}

lab@switch1-d# edit vlans {master:0}[edit vlans]

lab@switch1-d# set v10 vlan-id 10 {master:0}[edit vlans]

lab@switch1-d# set v11 vlan-id 11 {master:0}[edit vlans] lab@switch1-d# show v10 { vlan-id 10; } v11 { vlan-id 11; } {master:0}[edit vlans] lab@switch1-d#

Step 1.7

Navigate to the [edit interfaces] hierarchy level and deactivate the ae0 interface. {master:0}[edit vlans]

lab@switch1-d# top edit interfaces {master:0}[edit interfaces]

lab@switch1-d# deactivate ae0 {master:0}[edit interfaces] lab@switch1-d#

Step 1.8

Define the ge-0/0/6.0 and ge-0/0/7.0 interfaces as access ports for their respective VLANs. Consult the network diagram as needed for the VLAN names and VLAN-IDs.

lab@switch1-d# set ge-0/0/6 unit 0 family ethernet-switching port-mode access {master:0}[edit interfaces]

lab@switch1-d# set ge-0/0/6 unit 0 family ethernet-switching vlan members v10 {master:0}[edit interfaces]

(36)

lab@switch1-d# show ge-0/0/6 ether-options { link-mode full-duplex; speed { 1g; } } unit 0 { family ethernet-switching { port-mode access; vlan { members v10; } } } {master:0}[edit interfaces] lab@switch1-d# show ge-0/0/7 ether-options { link-mode full-duplex; speed { 1g; } } unit 0 { family ethernet-switching { port-mode access; vlan { members v11; } } } {master:0}[edit interfaces] lab@switch1-d#

Step 1.9

Define the ge-0/0/8.0 interface as a trunk port and associate both VLANs defined under the [edit vlans] hierarchy level to this interface. Activate the configuration changes and return to operational mode using the commit and-quit command.

lab@switch1-d# set ge-0/0/8 unit 0 family ethernet-switching port-mode trunk {master:0}[edit interfaces]

(37)

{master:0}[edit interfaces] lab@switch1-d# show ge-0/0/8 ether-options { link-mode full-duplex; speed { 1g; } } unit 0 { family ethernet-switching { port-mode trunk; vlan { members [ v10 v11 ]; } } } {master:0}[edit interfaces] lab@switch1-d# commit and-quit

Part 2: Monitor Switching Operations

In this part you will use the Junos CLI to monitor switching operations.

Step 2.1

Issue the show vlans command to determine the current VLAN designations and which interfaces are assigned to the configured VLANs.

{master:0}

lab@switch1-d> show vlans

Name Tag Interfaces default None v10 10 ge-0/0/6.0*, ge-0/0/8.0* v11 11 ge-0/0/7.0*, ge-0/0/8.0*

Question: Which VLANs are listed in the output?

(38)

Question: Which interfaces are associated with the various VLANs?

Answer: No interfaces should be associated with the default VLAN. The ge-0/0/6.0 and ge-0/0/8.0

interfaces should be associated with the v10 VLAN. The ge-0/0/7.0 and ge-0/0/8.0 interfaces should be associated with the v11.

Question: Why is the ge-0/0/8.0 interface associated with both of the user-defined VLANs?

Answer: Remember that the ge-0/0/8.0 interface was defined as a trunk interface and associated with both user-defined VLANs.

Question: What does the asterisk (*) next to the listed interfaces indicate?

Answer: The asterisk (*) next to the listed interfaces indicates that those interfaces are up and operational. If an interface is down the asterisk is omitted as shown with the ge-0/0/0.0 interface in the following capture: {master:0}

lab@switch1-d> show vlans

Name Tag Interfaces default

None v10 10

ge-0/0/0.0, ge-0/0/6.0*, ge-0/0/8.0* v11 11

ge-0/0/7.0*, ge-0/0/8.0*

Step 2.2

Issue the show ethernet-switching interfaces command and answer the question that follows:

{master:0}

lab@switch1-d> show ethernet-switching interfaces

(39)

Question: What is the current blocking state of the listed interfaces?

Answer: The listed interfaces should all be in the unblocked state. If you see a different state, check your configuration.

Step 2.3

Issue the show ethernet-switching table command and answer the question that follows:

{master:0}

lab@switch1-d> show ethernet-switching table Ethernet-switching table: 4 entries, 2 learned

VLAN MAC address Type Age Interfaces v10 * Flood - All-members v10 00:26:88:02:74:86 Learn 0 ge-0/0/6.0 v11 * Flood - All-members v11 00:26:88:02:74:87 Learn 0 ge-0/0/7.0

Question: What entries currently exist in your devices Ethernet switching table?

Answer: The answer may vary but you should see at least one Flood entry for each of the listed VLANs.

Step 2.4

Open a new SecureCRT tab and connect to the SRX1 device . Log in using the lab user account and the password lab123.

(40)

Password:

--- JUNOS 10.1R2.8 built 2010-05-11 05:02:14 UTC lab@host1-d>

Step 2.5

From your assigned host, ping both virtual routers attached to your designated switch. Use the

Ctrl+C key sequence to stop the ping operation.

lab@host1-d> ping 172.23.10.100

PING 172.23.10.100 (172.23.10.100): 56 data bytes

64 bytes from 172.23.10.100: icmp_seq=0 ttl=64 time=1.731 ms 64 bytes from 172.23.10.100: icmp_seq=1 ttl=64 time=7.313 ms 64 bytes from 172.23.10.100: icmp_seq=2 ttl=64 time=6.238 ms 64 bytes from 172.23.10.100: icmp_seq=3 ttl=64 time=6.250 ms 64 bytes from 172.23.10.100: icmp_seq=4 ttl=64 time=6.243 ms ^C

172.23.10.100 ping statistics

---5 packets transmitted, ---5 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.731/5.555/7.313/1.956 ms lab@host1-d> ping 172.23.11.100

PING 172.23.11.100 (172.23.11.100): 56 data bytes

---5 packets transmitted, ---5 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.731/5.555/7.313/1.956 ms

Question: Do the ping tests succeed?

Answer: As indicated in the sample output, the ping tests should succeed. If your ping tests do not succeed, check your configuration.

Step 2.6

Return to the session opened to EX1 and issue the show ethernet-switching table command.

{master:0}

lab@switch1-d> show ethernet-switching table Ethernet-switching table: 6 entries, 4 learned

(41)

v11 00:26:88:02:74:90 Learn 0 ge-0/0/8.0 Question: How many table entries are listed on your switch for each of the defined VLANs?

Answer: Your switch should show three MAC entries for each of the configured VLANs. You should see a Flood entry and two learned entries for each VLAN. Note that the learned entries do time out so you may need to return to your assigned host device and perform the ping tests again to repopulate the Ethernet switching table. You can consult the network diagram for this lab to view the MAC addresses assigned to the interfaces of the directly connected host and virtual routers.

Part 3: Configure an RVI

In this part you will use the Junos OS CLI to configure two RVIs to allow for inter-VLAN routing operations. You will then perform some basic verification steps to ensure the RVIs work properly.

Step 3.1

Return to the session SRX1. From your assigned host device attempt a ping operation to verify reachability between the two virtual routers attached to your switch. Make sure you reference the correct routing instance and use the Ctrl+C key sequence to stop the ping operation. lab@host1-d> show configuration routing-instances vr10 { instance-type virtual-router; interface ge-0/0/6.0; routing-options { static { route 0.0.0.0/0 next-hop 172.23.10.1; } } } vr11 { instance-type virtual-router; interface ge-0/0/7.0; routing-options { static { route 0.0.0.0/0 next-hop 172.23.11.1; } } }

lab@host1-d> ping routing-instance vr10 172.23.11.100 PING 172.23.11.100 (172.23.11.100): 56 data bytes ^C

(42)

---5 packets transmitted, 0 packets received, 100% packet loss Question: Does the ping operation between the two virtual routers succeed? If not, can you explain why?

Answer: As shown in the sample capture the ping operation should not succeed. Although the virtual routers have a default gateway defined, as shown in the preceding capture, the gateway address is not yet configured. You will configure two routed VLAN interfaces in the subsequent steps and apply the required gateway addresses to those VLAN interfaces.

Step 3.2

Return to the EX1 session. On your assigned switch, enter configuration mode and navigate to the [edit interfaces] hierarchy level.

{master:0}

lab@switch1-d# edit interfaces {master:0}[edit interfaces] lab@switch1-d#

Step 3.3

Define two RVIs named vlan.<vlan-id>, where <vlan-id> represents the VLAN-ID values assigned to the two user-defined VLANs. Use the IP addresses shown on this lab’s network diagram for the RVIs.

lab@switch1-d# set vlan unit 10 family inet address 172.23.10.1/24 {master:0}[edit interfaces]

lab@switch1-d# set vlan unit 11 family inet address 172.23.11.1/24 {master:0}[edit interfaces]

(43)

Step 3.4

Navigate to the [edit vlans] hierarchy and associate the recently defined RVIs with their respective VLANs. Next activate the configuration changes and return to operational mode using the commit and-quit command.

{master:0}[edit interfaces] lab@switch1-d# top edit vlans {master:0}[edit vlans]

lab@switch1-d# set v10 l3-interface vlan.10 {master:0}[edit vlans]

lab@switch1-d# set v11 l3-interface vlan.11 {master:0}[edit vlans] lab@switch1-d# show v10 { vlan-id 10; l3-interface vlan.10; } v11 { vlan-id 11; l3-interface vlan.11; } {master:0}[edit vlans]

Step 3.5

Issue the show interfaces vlan terse command. {master:0}

lab@switch1-d> show interfaces vlan terse

Interface Admin Link Proto Local Remote vlan up up

vlan.10 up up inet 172.23.10.1/24 vlan.11 up up inet 172.23.11.1/24

Question: What is the Admin and Link state of the vlan interfaces?

(44)

Step 3.6

Return to the session SRX1. Use the ping utility to verify reachability between the two virtual routers attached to your switch. Make sure you reference the correct routing instance and use the Ctrl+C key sequence to stop the ping operation.

lab@host1-d> ping routing-instance vr10 172.23.11.100 PING 172.23.11.100 (172.23.11.100): 56 data bytes

Question: Does the ping operation between the two virtual routers succeed?

Answer: As shown in the sample capture the ping operation should succeed.

Step 3.7

Use the exit command to log out of your assigned host device and switch. lab@host1-d> exit

{master:0}

lab@switch1-d> exit

(45)

Configuring Stateless Firewall Filters

Overview

In this lab, you use the CLI to configure and monitor stateless firewall filters. By completing this lab, you will perform the following tasks:

• Establish a baseline of operations.

(46)

Part 1: Establish a Baseline of Operations

The objective of this part is to establish a baseline of operations prior to configuring and applying stateless firewall filters.

Step 1.1

Step 1.2

lab@switch1-d>

Step 1.3

(47)

Step 1.4

Using the load override command, load the file switch1-X_L7_EXEna.config from the /root/ directory. This will load the basic configuration needed to complete the lab. Use the commit command to apply the changes.

{master:0}[edit]

lab@switch1-d#

Step 1.5

Open a new SecureCRT tab and connect to the EX2 device. Enter configuration mode and load the switch2-X_L7_EXEna.config file from the /root/ directory. Commit the changes and exit when complete.

(48)

lab@switch2-d>

lab@switch2-d#

Load the configuration file and then exit. Exit the device and close the tab. {master:0}[edit]

{master:0}

(49)

Step 1.6

Open a new SecureCRT tab and connect to the SRX1 device. Log in using the lab user account and the password lab123. Enter configuration mode and load the

host1-X_L7_EXEna.config file from the /cf/root/ directory. Commit the changes

when complete.

host1-d (ttyu0) login: lab Password:

Enter configuration mode. lab@host1-d> configure

Entering configuration mode [edit]

lab@host1-d#

Load the configuration file, then commit the changes and exit configuration mode. [edit]

lab@host1-d# load override /cf/root/host1-X_L7_EXEna.config [edit]

lab@host1-d# commit-and quit commit complete

Exiting configuration mode lab@host1-d>

Step 1.7

(50)

host2-d (ttyp0) login: lab Password:

lab@host2-d#

Load the configuration file and then exit. Exit the device and close the tab and return to the SRX1 device.

[edit]

lab@host2-d# load override /cf/root/host2-X_L7_EXEna.config [edit]

lab@host2-d# commit and-quit commit complete

Exiting configuration mode lab@host2-d> exit

host2-d (ttyu0) login:

Step 1.8

(51)

lab@host1-d> ping 172.23.10.100 count 5

PING 172.23.10.100 (172.23.10.100): 56 data bytes

64 bytes from 172.23.10.100: icmp_seq=0 ttl=64 time=1.197 ms 64 bytes from 172.23.10.100: icmp_seq=1 ttl=64 time=0.861 ms 64 bytes from 172.23.10.100: icmp_seq=2 ttl=64 time=0.913 ms 64 bytes from 172.23.10.100: icmp_seq=3 ttl=64 time=1.083 ms 64 bytes from 172.23.10.100: icmp_seq=4 ttl=64 time=1.105 ms 172.23.10.100 ping statistics

---5 packets transmitted, ---5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.861/1.032/1.197/0.125 ms lab@host1-d> ping 172.23.11.100 count 5

PING 172.23.11.100 (172.23.11.100): 56 data bytes

Question: Do the ping tests succeed?

Answer: Yes, the ping tests from your assigned host to the virtual routers attached to your switch should succeed as shown in the sample output.

Step 1.9

From your assigned host device, attempt to open a telnet session to each of the virtual routers attached to your designated switch. Use the Ctrl+C key sequence to close each session once connectivity is verified. Use the same destination addresses as used in the previous step. lab@host1-d> telnet 172.23.10.100

Trying 172.23.10.100... Connected to 172.23.10.100. Escape character is '^]'. host1-d (ttyp0)

login: ^CClient aborted login Connection closed by foreign host. lab@host1-d> telnet 172.23.11.100 Trying 172.23.11.100...

(52)

login: ^CClient aborted login Connection closed by foreign host.

Question: Do the telnet sessions connect?

Answer: Yes, the telnet sessions should connect as shown in the sample output.

Step 1.10

From your assigned host device, attempt to open a SSH session to each of the virtual routers attached to your designated switch. Use the Ctrl+C key sequence to close each session once connectivity is verified. Use the same destination addresses as used in the previous step. lab@host1-d> ssh 172.23.10.100

[email protected]'s password: lab@host1-d> ssh 172.23.11.100 [email protected]'s password:

Question: Do the SSH sessions connect?

Answer: Yes, the SSH sessions should connect as shown in the sample output. Note that you may see a slightly different result than that shown in the sample capture.

Part 2: Configure and Monitor Stateless Firewall Filters

In this part you will use the Junos CLI to configure and monitor stateless firewall filters.

Step 2.1

Return to the EX1 device tab. Enter configuration mode and navigate to the [edit

firewall family ethernet-switching filter my-filter] hierarchy level in preparation to define a new Layer 2 filter named my-filter.

{master:0}

(53)

Step 2.2

Define three terms for the my-filter firewall filter named term1, term2 and term3. In the first term (term1) discard telnet traffic sourced from your assigned host and destined to the vr10 virtual router. In the second term (term2) discard SSH traffic sourced from your assigned host and destined to the vr11 virtual router. Use the Layer 2 MAC addresses shown on the network diagram in addition to the protocol and port information as part of the matching criteria for term1 and term2. In the third term (term3) accept all other traffic.

{master:0}[edit firewall family ethernet-switching filter my-filter]

lab@switch1-d# set term term1 from protocol tcp destination-port telnet {master:0}[edit firewall family ethernet-switching filter my-filter]

lab@switch1-d# set term term1 from source-mac-address 00:26:88:02:74:90 {master:0}[edit firewall family ethernet-switching filter my-filter]

lab@switch1-d# set term term1 from destination-mac-address 00:26:88:02:74:86 {master:0}[edit firewall family ethernet-switching filter my-filter]

lab@switch1-d# set term term1 then discard

{master:0}[edit firewall family ethernet-switching filter my-filter] lab@switch1-d# set term term2 from protocol tcp destination-port ssh {master:0}[edit firewall family ethernet-switching filter my-filter] lab@switch1-d# set term term2 from source-mac-address 00:26:88:02:74:90 {master:0}[edit firewall family ethernet-switching filter my-filter]

lab@switch1-d# set term term2 from destination-mac-address 00:26:88:02:74:87 {master:0}[edit firewall family ethernet-switching filter my-filter]

lab@switch1-d# set term term2 then discard

{master:0}[edit firewall family ethernet-switching filter my-filter] lab@switch1-d# set term term3 then accept

(54)

00:26:88:02:74:90; } destination-mac-address { 00:26:88:02:74:87; } protocol tcp; destination-port ssh; } then discard; } term term3 { then accept; }

Step 2.3

Navigate to the [edit vlans] hierarchy level and apply my-filter as an input filter to both of the user-defined VLANs. Activate the configuration changes and return to operational mode using the commit and-quit command.

{master:0}[edit firewall family ethernet-switching filter my-filter] lab@switch1-d# top edit vlans

{master:0}[edit vlans]

lab@switch1-d# set v10 filter input my-filter {master:0}[edit vlans]

lab@switch1-d# set v11 filter input my-filter {master:0}[edit vlans]

Step 2.4

Return to the session opened for your assigned host device. From your assigned host device, attempt to open a telnet session to each of the virtual routers attached to your designated switch. Use the Ctrl+C key sequence to close each session or session attempt once connectivity is verified. Use the IP addresses listed on the network diagram for this lab as the destination addresses. lab@host1-d> telnet 172.23.10.100 Trying 172.23.10.100... ^C lab@host1-d> telnet 172.23.11.100 Trying 172.23.11.100... Connected to 172.23.11.100. Escape character is '^]'. host1-d (ttyp0)

(55)

Connection closed by foreign host.

Question: Do the telnet sessions connect? Can you explain these results?

Answer: As shown in the sample output, only the session for the vr11 device should succeed at this time. These results are expected due to the current structure of the my-filter firewall filter. The telnet session to the vr10 device does not succeed because of term1 while the session to the vr11 device does succeed because of term3.

Step 2.5

From your assigned host device, attempt to open a SSH session to each of the virtual routers attached to your designated switch. Use the Ctrl+C key sequence to close each session or session attempt once connectivity is verified. Use the same destination addresses as used in the previous step.

lab@host1-d> ssh 172.23.10.100 [email protected]'s password: lab@host1-d> ssh 172.23.11.100

ssh: connect to host 172.23.11.100 port 22: Operation timed out Question: Do the SSH sessions connect? Can you explain these results?

Answer: As shown in the sample output only the session for the vr10 device should succeed at this time. These results are expected due to the current structure of the my-filter firewall filter. The SSH session to the vr11 device does not succeed because of term2 while the session to the vr10 device does succeed because of term3.

Step 2.6

From your assigned host device, ping both virtual routers attached to your designated switch. Use the same destination addresses as used in the previous step.

lab@host1-d> ping 172.23.10.100 count 5

PING 172.23.10.100 (172.23.10.100): 56 data bytes

(56)

---5 packets transmitted, ---5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.861/1.032/1.197/0.125 ms lab@host1-d> ping 172.23.11.100 count 5

PING 172.23.11.100 (172.23.11.100): 56 data bytes

Question: Do the ping tests succeed? Which term in my-filter permits the ICMP traffic?

Answer: Yes, the ping tests should succeed. Term term3 permits ICMP and all other traffic types not specifically referenced in my-filter.

(57)

Virtual Chassis Systems

Overview

This lab demonstrates the Virtual Chassis feature, which is available on all EX4200 platforms. In this lab, you use the CLI to perform configuration and verification steps typically associated with the Virtual Chassis feature.

By completing this lab, you will perform the following tasks:

• Load a predefined configuration.

• Configure Virtual Chassis parameters.

• Monitor Virtual Chassis operation.

(58)

Key Commands

Part 1: Loading a Predefined Configuration

In this part, you will load a predefined configuration in preparation for converting two standalone EX4200 switches into a single Virtual Chassis.

Note

Step 1.1

Step 1.2

lab@switch1-d>

(59)

Step 1.3

lab@switch1-d#

Step 1.4

Using the load override command, load the file switch1-X_VC.config from the /

root/directory. This will load the basic configuration needed to complete the lab. Use the commit command to apply the changes.

{master:0}[edit]

lab@switch1-d# load override /root/switch1-X_VC.config {master:0}[edit]

lab@switch1-d#

Step 1.5

Open a new SecureCRT tab and connect to the EX2 device. Enter configuration mode and load the switch2-X_VC.config file from the /root/ directory. Commit the changes when complete.

(60)

lab@switch2-d>

lab@switch2-d#

Load the configuration file and then exit. Exit the device and close the tab. {master:0}[edit]

lab@switch2-d# load override /root/switch2-X_VC.config {master:0}[edit]

Step 1.6

(61)

host1-d (ttyu0) login: lab Password:

lab@host1-d#

Load the configuration file, then commit the changes and exit configuration mode. [edit]

lab@host1-d# load override /var/tmp/host1-X.config [edit]

lab@host1-d# commit-and quit commit complete

Exiting configuration mode lab@host1-d>

Step 1.7

(62)

host2-d (ttyp0) login: lab Password:

lab@host2-d#

Load the configuration file and then exit. Exit the device and close the tab and return to the EX1 device.

[edit]

lab@host2-d# load override /var/tmp/host2-X.config [edit]

lab@host2-d# commit and-quit commit complete

Exiting configuration mode lab@host2-d> exit

(63)

Part 2: Configuring Virtual Chassis Parameters

In this part, you will enable the dedicated Virtual Chassis ports and create a basic configuration for your Virtual Chassis.

Step 2.1

Enter configuration mode and navigate to the [edit virtual-chassis] configuration hierarchy level on the EX1 device.

{master:0}

lab@switch1-d> configure {master:0}[edit]

lab@switch1-d# edit virtual-chassis {master:0}[edit virtual-chassis] lab@switch1-d#

Step 2.2

Use the member-id and mastership priority values shown on the topology diagram for this lab and define those parameters. Activate the new configuration and return to operational mode using the commit and-quit command.

{master:0}[edit virtual-chassis]

lab@switch1-d# set member 0 mastership-priority 255 {master:0}[edit virtual-chassis]

lab@switch1-d# commit and-quit commit complete

Exiting configuration mode {master:0}

lab@switch1-d>

Step 2.3

Issue the show virtual-chassis vc-port command to verify the current state of the dedicated Virtual ChassisVirtual Chassis ports.

{master:0}

lab@switch1-d> show virtual-chassis vc-port

(64)

Question: What is the current state of the Virtual Chassis ports (VCPs) for your assigned switch?

Answer: The current state of the VCPs should be disabled. If the VCPs are not disabled, please notify your instructor.

Step 2.4

Enable vcp-0 and vcp-1 using the request virtual-chassis vc-port set

interface interface-name command.

{master:0}

lab@switch1-d> request virtual-chassis vc-port set interface vcp-0 {master:0}

lab@switch1-d>

Step 2.5

Return to the EX2 tab and enable the vcp-0 and vcp-1 interfaces. {master:0}

lab@switch2-d>

Step 2.6

(65)

{master:0}

lab@switch1-d> show virtual-chassis vc-port fpc0:

---Interface Type Trunk Status Speed Neighbor or ID (mbps) ID Interface PIC / Port vcp-0 Dedicated 2 Down 32000 vcp-1 Dedicated 1 Up 32000 1 vcp-0 fpc1: ---Interface Type Trunk Status Speed Neighbor or ID (mbps) ID Interface PIC / Port

vcp-0 Dedicated 2 Up 32000 0 vcp-1 vcp-1 Dedicated 1 Disabled 32000

Question: What is the current state of the VCPs?

Answer: The vcp-1 interface on fpc0 and the vcp-0 interface on fpc1 should both be up.

Step 2.7

Return to the EX2 device. Exit and log in again through the existing console connection using the lab user account and password lab123

{master:0} lab@switch2-b> exit switch2-b (ttyu0) login: lab Logging to master Password:

(66)

Question: To which switch are you now logged in? Why?

Answer: In all cases, the user’s login should be directed to the master switch (switch1-x). In this case the actual console connection is through switch2-x but the user is logged in to switch1-x. Remember, a connection through the console on any member switch in a Virtual Chassis system is redirected to the master switch through the virtual console software.

Step 2.8

Return to the EX1 device and issue the show virtual-chassis vc-port

all-members command.

{master:0}

lab@switch1-d> show virtual-chassis vc-port all-members fpc0:

---Interface Type Trunk Status Speed Neighbor or ID (mbps) ID Interface PIC / Port vcp-0 Dedicated 2 Down 32000 vcp-1 Dedicated 1 Up 32000 1 vcp-0 fpc1: ---Interface Type Trunk Status Speed Neighbor or ID (mbps) ID Interface PIC / Port

vcp-0 Dedicated 2 Up 32000 0 vcp-1 vcp-1 Dedicated 1 Disabled 32000

Step 2.9

Enter configuration mode, then use the rename command to change the management Ethernet interface’s name from me0 to vme.

{master:0}

lab@switch1-d# edit interfaces {master:0}[edit interfaces]

lab@switch1-d# rename me0 to vme {master:0}[edit interfaces]

(67)

unit 0 { family ethernet-switching; } } ge-0/0/1 { unit 0 { family ethernet-switching; } } vme { unit 0 { family inet { address 10.210.14.147/27; } } } {master:0}[edit interfaces] lab@switch1-d#

Question: What is the value in using a vme interface rather than the me0 interface in a Virtual Chassis configuration?

Answer: The me0 interface is tied to a single physical connection and interface. In the case of a Virtual Chassis configuration, only the me0 interface for the device functioning as master is usable. The vme interface associates the me0 interfaces from all participating member switches with the vme interface. In this case, a management connection could be made with the Virtual Chassis system through any available me0 interface and not just the me0 interface associated with the master switch.

Step 2.10

Use the copy command to mirror the configuration details for the ge-0/0/0 and ge-0/0/1 interfaces to the ge-1/0/0 and ge-1/0/1 interfaces.

lab@switch1-d# show ge-0/0/0 {

unit 0 {

(68)

} } ge-0/0/1 { unit 0 { family ethernet-switching; } } ge-1/0/0 { unit 0 { family ethernet-switching; } } ge-1/0/1 { unit 0 { family ethernet-switching; } } vme { unit 0 { family inet { address 10.210.14.147/27; } } } {master:0}[edit interfaces] lab@switch1-d#

Question: To which physical device do the ge-1/0/0 and ge-1/0/1 interfaces belong?

Answer: The ge-1/0/0 and ge-1/0/1 interfaces belong to the backup switch (s2, s4, s6, or s8 depending on the Virtual Chassis group). These devices use a member ID value of 1, which means that the slot value within the interface name also assumes a value of 1. Step 2.11

Use the commit synchronize command to activate the recent changes on both chassis. {master:0}[edit interfaces]

lab@switch1-d# commit synchronize fpc0:

configuration check succeeds fpc1:

commit complete fpc0:

commit complete

(69)

lab@switch1-d#

Question: Why is it advisable to use the commit

synchronize command?

Answer: The commit synchronize command ensures that the configuration files are identical on the master and the backup platforms for the Virtual Chassis.

Step 2.12

Use the exit command to return to operational mode. {master:0}[edit interfaces]

lab@switch1-d# exit {master:0}[edit] lab@switch1-d# exit

Exiting configuration mode lab@switch1-d>

Part 3: Monitoring Virtual Chassis Operation

In this part, you will perform tasks generally associated with monitoring a Virtual Chassis system.

Step 3.1

Using the existing console connection, issue the show virtual-chassis status command and answer the following questions:

lab@switch1-d> show virtual-chassis status Virtual Chassis ID: 65ee.22ff.aad1

Mastership Neighbor List Member ID Status Serial No Model priority Role ID Interface 0 (FPC 0) Prsnt BM0208366799 ex4200-24t 255 Master* 1 vcp-1 1 (FPC 1) Prsnt BM0208327676 ex4200-24t 128 Backup 0 vcp-0 Member ID for next new member: 2 (FPC 2)

(70)

Question: What is the Virtual Chassis identifier assigned to your group’s Virtual Chassis system?

Answer: The answer will vary, but in the sample output shown previously, the Virtual Chassis identifier is 65ee.22ff.aad1. This identifier value is taken from the system MAC address.

Question: What roles are the individual member switches performing within the Virtual Chassis system?

Answer: Because there are only two participating member switches within this Virtual Chassis system, one switch assumes the role of master and the second switch is designated as the backup switch. In a Virtual Chassis configuration that includes at least three member switches, all member switches not selected as the master or backup will assume the role of a linecard. Membership roles within a Virtual Chassis system are determined based on mastership priority and the election process.

Question: What member ID will the next new member switch added to this your Virtual Chassis be assigned?

Answer: As indicated in the output, the next new member added to this Virtual Chassis should be assigned the member ID 2.

Step 3.2

View the current RE status for your Virtual Chassis system by issuing the show chassis

routing-engine command. Compare the displayed output with the output from the show virtual-chassis status command.

lab@switch1-d> show chassis routing-engine Routing Engine status:

Slot 0:

Current state Master

Election priority Master (default)

(71)

Memory utilization 30 percent CPU utilization: User 1 percent Background 0 percent Kernel 1 percent Interrupt 0 percent Idle 98 percent

Model EX4200-24T, 8 POE Serial ID BM0208366799

Start time 2010-05-19 04:22:20 UTC

Uptime 14 days, 5 hours, 30 minutes, 40 seconds Last reboot reason Router rebooted after a normal shutdown. Load averages: 1 minute 5 minute 15 minute

0.00 0.00 0.01 Routing Engine status:

Slot 1:

Current state Backup

Election priority Backup (default)

Temperature 40 degrees C / 104 degrees F CPU temperature 40 degrees C / 104 degrees F DRAM 1024 MB

Memory utilization 25 percent CPU utilization: User 3 percent Background 0 percent Kernel 0 percent Interrupt 0 percent Idle 96 percent

Model EX4200-24T, 8 POE Serial ID BM0208327676

Start time 2010-05-19 04:17:12 UTC

Uptime 14 days, 5 hours, 35 minutes, 45 seconds Last reboot reason Router rebooted after a normal shutdown. Load averages: 1 minute 5 minute 15 minute

0.00 0.00 0.00 lab@switch1-d> show virtual-chassis status

Virtual Chassis ID: 65ee.22ff.aad1

Mastership Neighbor List Member ID Status Serial No Model priority Role ID Interface 0 (FPC 0) Prsnt BM0208366799 ex4200-24t 255 Master* 1 vcp-1 1 (FPC 1) Prsnt BM0208327676 ex4200-24t 128 Backup 0 vcp-0 Member ID for next new member: 2 (FPC 2)

(72)

Question: Based on the comparison between the two generated outputs, which switch is functioning as the master RE? What unique identifier validates your answer?

Answer: The master switch, with a member ID value of 0, is also functioning as the master RE. This is the expected behavior and is considered to be one of the primary functions of the master switch. The serial number, which is shown in both outputs, can help validate this point.

Question: What is the current mastership priority for the member switches participating in your Virtual Chassis?

Answer: The mastership priority for member switch 0 is 255. The member switch 1 assumes the default mastership priority, which is 128.

Part 4: Restoring Standalone Switch Functionality

The objective of this lab part is to restore standalone switch functionality. Ensure that you continue working closely with the partner team for your designated Virtual Chassis group.

Step 4.1

Disable both VCPs using the request virtual-chassis vc-port set interface

<interface-name> disable command.

lab@switch1-d> request virtual-chassis vc-port set interface vcp-0 disable lab@switch1-d> request virtual-chassis vc-port set interface vcp-1 disable lab@switch1-d>

Step 4.2

Return to the EX2 tab and disable the vcp-0 and vcp-1 interfaces. {master:0}

lab@switch2-d> request virtual-chassis vc-port set interface vcp-0 disable {master:0}

lab@switch2-d> request virtual-chassis vc-port set interface vcp-1 disable {master:0}

(73)

Step 4.3

Issue the command request virtual-chassis renumber member-id 1

new-member-id 0 to return the switch to {master:0}. Log back into the switch to confirm

the change. {master:1}

lab@switch1-d> request virtual-chassis renumber member-id 1 new-member-id 0 To move configuration specific to member ID 1 to member ID 0, please

use the replace command. e.g. replace pattern ge-1/ with ge-0/ Do you want to continue ? [yes,no] (no) yes

{master:1} lab@switch1-d> switch1-b (ttyu0) login: lab

Password:

lab@switch1-d>

Step 4.4

Return to the EX1 and log into the device. Issue the command request

virtual-chassis reactivate to return the device back to {master:0} from the

current {linecard:0}. Log back into the device . switch1-d (ttyu0)

login: lab Password:

--- JUNOS 10.1R2.8 built 2010-05-11 04:08:08 UTC {linecard:0}

lab@switch1-d> request virtual-chassis reactivate

This member split from a virtual chassis. Please make sure that no active switch belonging to this virtual chassis has conflicting configuration. Do you want to continue ? [yes,no] (no) yes

{linecard:0} lab@switch1-d> switch1-b (ttyu0) login: lab

Password: