Advanced Junos Enterprise Switching Troubleshooting...Advanced Junos Enterprise Switching Troubleshooting 12.a Worldwide Education Services 1194 North Mathilda Avenue Sunnyvale, CA

Advanced Junos Enterprise

Switching Troubleshooting

DETAILED LAB GUIDE Revision 12.a

Advanced Junos Enterprise

Switching Troubleshooting

12.a

Worldwide Education Services

1194 North Mathilda Avenue

Sunnyvale, CA 94089

USA

408-745-2000

www.juniper.net

Course Number: EDU-JUN-AJEXT

Detailed Lab Guide

[email protected]

This document is produced by Juniper Networks, Inc.

This document or any part thereof may not be reproduced or transmitted in any form under penalty of law, without the prior written permission of Juniper Networks

Education Services.

Juniper Networks, Ju nos, 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 Ju nos 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.

Advanced Junos Enterprise Switching Troubleshooting Detailed Lab Guide, Revision 12.a

Copyright© 2013 Juniper Networks, Inc. All rights reserved.

Printed in USA.

Revision History:

Revision 12.a-June 2013

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

The information in this document has been carefully verified and is believed to be accurate for software Release 12.3R1.7. Juniper Networks assumes no responsibilities for any inaccuracies that may appear in this document. In no event will Juniper Networks be liable for direct, indirect, special, exemplary, incidental, or consequential damages resulting from any defect or omission in this document, even if advised of the possibility of such damages.

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.

[email protected]

Contents

Lab 1: Troubleshooting Packet Loss and Latency (Detailed) .................. 1-1 Part 1: Troubleshooting Packet loss and Latency ............................................... 1-2

Lab 2: Troubleshooting Virtual Chassis and Interfaces (Detailed) ............. 2-1 Part 1: Logging In Using the CLI ............................................................. 2-2

Part 2: Troubleshooting Virtual Chassis ...................................................... 2-10

Lab 3: Troubleshooting Spanning Tree Protocols (Detailed) .................. 3-1 Part 1: Troubleshooting RSTP ............................................................... 3-2

Part 2: Troubleshooting MSTP ............................................................. 3-12

Lab 4: Troubleshooting Port Security (Detailed) ............................ 4-1 Part 1: Troubleshooting Port Security ......................................................... 4-2

Lab 5: Troubleshooting Advanced Features (Detailed) ...................... 5-1 Part 1: Troubleshooting Multicast ............................................................ 5-2

Contents • iii

iv • Contents www.juniper.net

Course Overview

Objectives

www.juniper.net

This one-day course is designed to provide students with information about troubleshooting

EX Series hardware, the Junos operating system, and more obscure problems like packet loss and

latency, Virtual Chassis, spanning tree protocols, Q-in-Q tunneling, port security features, multicast,

and class of service (CoS). Students will gain experience in monitoring and troubleshooting these

topics through demonstration as well as hands-on labs. The course exposes students to common

troubleshooting commands and tools used to troubleshoot various intermediate to advanced

issues.

This course uses Juniper Networks EX Series Switches for the hands-on component, but the lab

environment does not preclude the course from being applicable to other Juniper hardware

platforms running the Junos OS. This course is based on Junos OS Release 12.3R1.7.

After successfully completing this course, you should be able to:

• Determine the right questions to ask when troubleshooting an issue.

• Identify general outputs and the type of information found in outputs.

Simplify a complex network and recreate an issue in the lab environment.

Describe packet loss in a network.

• List the general chassis components.

Identify different methods for troubleshooting major chassis components.

Troubleshoot redundant Routing Engine and Control Board communication.

• Isolate problems with interfaces.

• Troubleshoot 1Pv4 interfaces.

Identify an issue with software and the process of events to recreate the issue.

Define a problem report (PR) and identify relevant information contained in a PR.

• Find relevant topics within the Juniper Networks Knowledge Base.

Verify and troubleshoot Spanning Tree Protocol (STP).

Verify and troubleshoot Rapid Spanning Tree Protocol (RSTP).

• Verify and troubleshoot Multiple Spanning Tree Protocol (MSTP).

Verify and troubleshoot VLAN Spanning Tree Protocol (VSTP).

Verify and troubleshoot Q-in-Q tunneling.

• Verify and troubleshoot port authentication and security.

• Verify and troubleshoot multicast.

Verify and troubleshoot class of service (CoS).

Course Overview • v

Intended Audience

Course Level

Prerequisites

vi • Course Overview

The primary audience for this course is the following:

Individuals responsible for configuring and monitoring devices running the Junos OS.

Advanced Junos Enterprise Switching Troubleshooting is an advanced-level course.

The following courses are the prerequisites for this course:

Junos Troubleshooting in the NOC (JTNOC); and

Advanced Junos Enterprise Switching (AJEX).

www.juniper.net

Course Agenda

Day 1

www.juniper.net

Chapter 1: Course Introduction

Chapter 2: Advanced Troubleshooting Methodology

Troubleshooting Packet Loss Lab

Chapter 3: Hardware and Interface Troubleshooting

Troubleshooting Virtual Chassis and Interfaces Lab

Chapter 4: Troubleshooting Software Issues

Chapter 5: Troubleshooting Spanning Tree Protocols

Troubleshooting Spanning Tree Protocols Lab

Chapter 6: Troubleshooting Port Security

Troubleshooting Port Security Lab

Chapter 7: Troubleshooting Advanced Features

Troubleshooting Advanced Features Lab

Course Agenda • vii

Document Conventions

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.

Style

Franklin Gothic

Courier New

Description

Normal text.

Console text:

Screen captures

Noncommand-related

syntax

GUI text elements:

Menu names

Text field entry

Usage Example

Most of what you read in the Lab Guide

and Student Guide.

commit complete

Exiting configuration mode

Select File > Open, and then click

Configuration.conf in the

Filename text box.

Input Text Versus Output Text

You will also frequently see cases where you must enter input text yourself. Often these instances

will be shown in the context of where you must enter them. We use bold style to distinguish text

that is input versus text that is simply displayed.

Style

Normal CLI

Normal GUI

CLI Input

GUI Input

Description

No distinguishing variant.

Text that you must enter.

Usage Example

Physical interface:fxpO,

Enabled

View configuration history by clicking

Configuration > Histor�

lab@San Jose> show route

Select File > Save, and type

config. ini in the Filename field.

Defined and Undefined Syntax Variables

Finally, this course distinguishes between regular text and syntax variables, and it also

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.

Style

CLI Variable

GUI Variable

CLI Undefined

GUI Undefined

viii • Document Conventions

Description

Text where variable value is already

assigned.

Text where the variable's value is

the user's discretion or text where

the variable's value as shown in

the lab guide might differ from the

value the user must input

according to the lab topology.

Usage Example

policy my-peers

Click my-peers in the dialog.

Type set policy policy-name.

ping 10.0.�

Select File > Save, and type

filename in the Filename field.

www.juniper.net

Additional Information

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:j /www.juniper.net;training/education/.

About This Publication

The Advanced Junos Enterprise Switching Troubleshooting Detailed Lab Guide was developed and

tested using software Release 12.3R 1. 7. 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:j /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

www.juniper.net

For technical support, contact Juniper Networks at http:j /www.juniper.net;customers/support;, or

at 1-888-314-JTAC (within the United States) or 408-745-2121 (outside the United States).

Additional Information • ix

x • Additional Information www.juniper.net

Overview

Lab

Troubleshooting Packet Loss and Latency (Detailed)

In this lab, you will troubleshoot packet loss and latency on your pod and correct the

detected problems.

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

• Troubleshoot packet loss using system CLI.

• Troubleshoot latency using system CLI.

• Correct the problems related to packet loss and latency.

www.juniper.net -: :,,c:,,e_h�.::15 :c.cl.e: ... :.s.: dl.d LJ:e1.cy (Uetailed) • Lab 1-1

Advanced Junos Enterprise Switching Troubleshooting

Part 1: Troubleshooting Packet loss and Latency

Step 1.1

Step 1.2

In this lab part, you become familiar with the access details used to access the lab

equipment. You will troubleshoot problems with packet loss and traffic latency

through your network.

Note

Depending on the class, the lab equipment

used might be remote from your physical

location. The instructor will inform you as to

the nature of your access and will provide

you the details needed to access your

assigned device.

Ensure that you know to which device you are assigned. Check with your instructor if

necessary. Consult the Management Network Diagram to determine the

management address of your student device.

Question: What is the management address

assigned to your student router?

Answer: The actual management address varies

between delivery environments. Consult the

Management Network Diagram for your address.

Access the command-line interface (CLI) of your assigned EX Series switch from your

station using either the console, Telnet, or SSH as directed by your instructor.

Quick Connect �'

Protocol: I Telnet vi Hostname: lx.x.x.x

Port: 123 Firewall:

O Show quick connect on startup

I None

� Save session

� Open in a tab

vi

I Connect � [ Cancel

Lab 1-2 • Troubleshooting Packet Loss and Latency (Detailed) www.juniper.net

Advanced Ju nos Enterprise Switching Troubleshooting

Step 1.3

Log in as user lab with the password labl23. Enter configuration mode and load

the labl-start. configfrom the /var/home/lab/ajextj directory. Commit the

configuration and return to operational mode when complete.

exB-1 (ttypO)

login: lab

Password:

--- JUNOS 12.3Rl.7 built 2013-01-26 01:32:53 UTC

{master:O}

lab@exB-1> configure

Entering configuration mode

{master:O} [edit]

lab@exB-1# load override ajext/labl-start.config

load complete

{master:O} [edit]

lab@srxC-1# commit and-quit

configuration check succeeds

commit complete


{master:0}

lab@exB-1>

Step 1.4

Open a second command-line interface (CLI) session to your assigned SRX Series

gateway from your station using either the console, Telnet, or SSH as directed by

your instructor.

www.juniper.net

Quick Connect �'

Protocol: I Telnet vi

Hostname: !x.x.x.x

Port: 123 Firewall:


!None

� Save session

� Open in a tab

vi

[ Connect � [ Cancel

I roubleshooting Packet Loss and Latency (Detailed) • Lab 1-3


Step 1.5

srxB-1 (ttyuO)

login: lab

Password:

Log in as user lab with the password lab12 3. Enter configuration mode and load

the labl-start. configfrom the /var/home/lab/ajextj directory. Commit the


--- JUNOS 12.1R5.5 built 2013-01-17 06:12:00 UTC

lab@srxB-1> configure


[edit]

lab@srxB-1# load override ajext/labl-start.config

load complete

[edit]

lab@srxB-1# commit and-quit

commit complete


lab@srxB-1>

Step 1.6

{master:0}

lab@exB-1>

ge-0/0/6

ge-0/0/6.0

ge-0/0/7

ge-0/0/7. 0

ge-0/0/8

ge-0/0/8.0

show

Return to your assigned EX Series switch.

From your assigned EX Series switch, use the show interface terse

command to verify that the interfaces shown in the network diagram are in an up

state, both physically and administratively. You can narrow down the output by

restricting the interfaces to the appropriate range by including the I match

"ge-0/0/ [6-8) "restrictions

interfaces

up

up

up

up

up

up

terse match "ge-0/0/ [6-8]"

up

up eth-switch

up

up eth-switch

up

up eth-switch

Question: Are all interfaces that are part of the

topology up?

Answer: Yes, all the interfaces that are part of the

topology should be up. If the interfaces are not up,

notify your instructor.

-- -------------- --------- - ------�----- --



Step 1.7

Return to your assigned SRX Series device.

From both of the virtual routing instances configured on you SRX Series device,

attempt to ping the corresponding IP address on the SRX interface ge-0/0/8 using

size 800 count 5 settings. Refer to the network diagram for the instance

names and the IP addresses assigned to the various virtual routing instances and

do not forget to reference the correct routing instance.

lab@srxB-1> ping address routing-instance Networkl size 800 count

PING 172.23.11.10 (172.23.11.10): 800 data bytes

808 bytes from 172.23.11.10: icmp -

seq= O ttl=64 time= l.330 ms

808 bytes from 172.23.11.10: icmp -

seq= l ttl=64 time= l.351 ms

808 bytes from 172.23.11.10: icmp -

seq=2 ttl=64 time= l.287 ms

808 bytes from 172.23.11.10: icmp -

seq=3 ttl=64 time=131. 955 ms

808 bytes from 172.23.11.10: icmp -

seq=4 ttl=64 time=512.093 ms

172.23.11.10 ping statistics ---

5 packets transmitted, 5 packets received, 0% packet loss

round-trip min/avg/max/stddev = 1.287/129.603/512.093/197.824 ms

lab@srxB-1> ping address routing-instance Network2 size 800 count

PING 172.23.12.10 (172.23.12.10): 800 data bytes

808 bytes from 172.23.12.10: icmp -

seq=O ttl=64 time= l.462 ms

808 bytes from 172.23.12.10: icmp -


808 bytes from 172.23.12.10: icmp -


808 bytes from 172.23.12.10: icmp -


808 bytes from 172.23.12.10: icmp seq=4 ttl=64 time=511. 584 ms




Question: Can you ping both from one routing

instance to the other?

Answer: Yes, you should be able to reach both

routing instances. If not, check you configuration

and notify your instructor.

Question: What can you determine from the

response times?

Answer: The response times become very high and

indicate there is high levels of latency in the

network communication.

5

5

www.juniper.net I roubleshooting Packet Loss and Latency (Detailed) • Lab 1-5


Step 1.8

Attempt to traceroute from each virtual routing instance to the corresponding IP

address on the SRX interface ge-0/0/8. Type Ctrl + c to break out of the traceroute

operation if you do not receive responses for a couple series of attempts.

lab@srxB-1> traceroute address routing-instance Network-1

traceroute to 172.23.11.10 (172.23.11.10), 30 hops max, 40 byte packets

1 * * *

2 * * *

3 * * *

"C

lab@srxB-1> traceroute address routing-instance Network-2


1 * * *

2 * * *

3 * * *

"C

lab@srxB-1>

Step 1.9

master:O}

Question: Do your trace route attempts complete?

Answer: No, the traceroute attempts do not

generate responses.

Question: What are potential causes for the

observed behavior?

Answer: The high latency of the pings could be

related to different factors like duplex mismatch,

Cos problems, high utilization of the line by other

traffic, etc. The fact that traceroute is not working

could be a result of packet filtering (in either

direction).


From your assigned EX Series switch, use the show interfaces interface

match link-level command to verify the speed and duplex settings of all

interfaces configured on your EX Series switch.

lab@exB-1> sho1,• �n":��.f:;i ""eS" g�-0/0/f5 I "l\T.a":�b li'1°

-:-1,p•rE�



Link-level type: Ethernet, MTU: 1514, Speed: Auto, Duplex: Auto,

{master:O}

lab@exB-1> show interfaces ge-0/0/7 I match link-level


{master:0}

lab@exB-1> show interfaces ge-0/0/8 I match link-level


Step 1.10

Question: Do you see any problems with the

auto-negotiation of interface settings between your

EX Switch and your SRX device

Answer: No, there should not be any discrepancies

between the settings on these interfaces. They

should show Speed: Auto and Duplex: Auto. If

not, contact your instructor.


From your assigned SRX Series device, use the show class-of-service

interface interface command to review the current CoS setting on all three

SRX interfaces.

lab@srxB-1> show class-of-service interface ge-0/0/6

Physical interface: ge-0/0/6, Index: 140

Queues supported: 8, Queues in use: 4

Scheduler map: int8-map, Index: 20628

Congestion-notification: Disabled

Logical interface: ge-0/0/6.0, Index: 81

Object Name

Classifier ipprec-compatibility

Type

ip







Object Name


Type

ip




Scheduler map: <default>, Index: 2


Index

13

Index

13

______ _, ___ --�----------- ---------




Object Name


Type

ip

Question: Do you see anything Cos settings on the

interfaces?

Step 1.11

Answer: Yes, you should notice that the ge-0/0/6

and ge-0/0/7 interfaces have the int8-map

scheduler map applied.

Index

13

Use the show class-of-service scheduler-map int8-map command to

review the details about the scheduler map being applied on those interfaces.

lab@srxB-1> show class-of-service scheduler-map int8-map


Scheduler: best-effort, Forwarding class: best-effort, Index: 61257

Transmit rate: 1 percent, Rate Limit: none, Buffer size: 0 us,

Buffer Limit: none, Priority: low

Excess Priority: unspecified

Shaping rate: 5000 bps

Drop profiles:

Loss priority

Low

Medium low

Medium high

High

Protocol

any

any

any

any

Index

1

1

1

1

Name

<default-drop-profile>




Scheduler: expedited-forwarding, Forwarding class: expedited-forwarding,

Index: 1394 6

Transmit rate: 50 percent, Rate Limit: none, Buffer size: remainder,



Drop profiles:

Loss priority Protocol Index Name

Low any 1 <default-drop-profile>

Medium low any 1 <default-drop-profile>

Medium high any 1 <default-drop-profile>

High any 1 <default-drop-profile>

Scheduler: assured-forwarding, Forwarding class: assured-forwarding, Index:

60275

Transmit rate: 45 percent, Rate Limit: none, Buffer size: remainder,



Drop profiles:

Loss pr:ority Protocol Index Name ----------------------- - ______ _, __ _


Low Medium low Medium high High

any any any any


1 <default-drop-profile> 1 <default-drop-profile> 1 <default-drop-profile> 1 <default-drop-profile>

Scheduler: network-control, Forwarding class: network-control, Index: 38488

Transmit rate: unspecified, Rate Limit: none, Buffer size: remainder, Buffer Limit: none, Priority: strict-high Excess Priority: unspecified Drop profiles:

Loss priority Protocol Index Name Low Medium low Medium high High

Step 1.12

any any any any

1 <default-drop-profile> 1 <default-drop-profile> 1 <default-drop-profile> 1 <default-drop-profile>

Question: Do you see anything in the scheduler map

that could be causing the ping packets to

experience the high latency?

Answer: You should notice that the scheduler map

applies a shaping rate to the best effort queue.

Enter configuration mode and navigate to the [edit class-of-service]

hierarchy. Review the current Cos configuration. Modify the configuration so that the

latency issue for your ping traffic disappears by deactivating the ge-0/0/6 and

ge-0/0/7 interfaces. Commit and exit to operational mode when you have finished.

lab@srxB-1> configure Entering configuration mode

[edit] lab@srxB-1# edit class-of-service

[edit class-of-service] lab@srxB-1# show interfaces {

ge-0/0/6 { scheduler-map int8-map;

} ge-0/0/7 {

scheduler-map int8-map;

scheduler-maps int8-map {

forwarding-class best-effort scheduler best-effort; forwarding-class network-control scheduler network-control; forwarding-class assured-forwarding scheduler assured-forwarding; forwa_rdina-c lass P"l<pedit:Pd-f:c-.,.-v.,:-i.rdinrr schedule� ex:1Pdit�d-forwarding;

----- ---------------- --------- _________ ,..... _____ ---------



schedulers

best-effort

transmit-rate percent 1;

shaping-rate 5k;

buffer-size percent O;

priority low;

network-control {

priority strict-high;

expedited-forwarding {


assured-forwarding {


[edit class-of-service]

lab@srxB-1# deactivate interfaces

[edit class-of-service]


commit complete


lab@srxB-1>

Step 1.13

From both of the virtual routing instances configured on you SRX Series device,

verify that your recent configuration changes has resolved the latency issue by

pinging the corresponding IP address on the SRX interface ge-0/0/8 using size

8 O O count 5 settings.

lab@srxB-1> ping address routing-instance Networkl size 800 count

PING 172.23.11.10 (172.23.11.10): 800 data bytes

808 bytes from 172.23.11.10: icmp -

seq= O ttl=64 time= l. 417

808 bytes from 172.23.11.10: icmp -

seq= l ttl=64 time= l.395

808 bytes from 172.23.11.10: icmp -

seq=2 ttl=64 time= l.333

808 bytes from 172.23.11.10: icmp -

seq=3 ttl=64 time= l. 447

808 bytes from 172.23.11.10: icmp -

seq=4 ttl=64 time=9.338




ms

ms

ms

ms

ms

lab@srxB-1> ping address routing-instance Network2 size 800

PING 172.23.12.10 (172.23.12.10): 800 data bytes

808 bytes from 172.23.12.10: icmp -

seq= O ttl=64 time= l.352 ms

808 bytes from 172.23.12.10: icmp -

seq= l ttl=64 time= l. 302 ms

808 bytes from 172.23.12.10: icmp -


808 bytes from 172.23.12.10: icmp -


808 bytes fro!"\ J72.23.12.10: icmp seq=4 +-+-.1=64 time= J .397 ms

count

5

5

----------------------- --------- _________ ,..... _____ -------



--- 172.23.12.10 ping statistics ---



Step 1.14

Question: What kind of response times do you see

now on your ping traffic?

Answer: It varies but it should be much lower than in

the previous attempt.

The next item to figure out is why you did not receive a response to the traceroute

attempts. Determine if any of the interfaces on your SRX device have a firewall filter

applied. You can narrow down the output by including the I match filters

criteria.

lab@srxB-1> show interfaces ge-0/0/6 extensive I match filters

CAM destination filters: 2, CAM source filters: 0





Step 1.15

{master:O}

Question: Do you see any firewall filters applied to

any of the interfaces?

Answer: No, there are no firewall filters applied on

the SRX device.


From your assigned EX Series switch, review the interfaces and determine if there

are any firewall filters that could be blocking the traceroute traffic. Include the I

match filters criteria to narrow down the output.

lab@exB-1> show interfaces ge-0/0/6.0 extensive I match filters

Input Filters: labl-input-6-7

{master:O}


Input Filters: labl-input-6-7

www.juniper.net Troubleshooting Packet Loss and Latency (Detailed) • Lab 1-11


{master:0}


Step 1.16

Question: Do you see any firewall filters applied?

Answer: Yes, you should notice that there is a input

filter applied on ge-0/0/6 and ge-0/0/7.

Use the show configuration firewall command to review the firewall

configuration.

{master:O}

lab@exB-1> show configuration firewall

family ethernet-switching {

filter labl-input-6-7 {

term 1 {

from {

protocol udp;

Step 1.17

then {

discard;

log;

term 2

then accept;

Question: Why is this filter blocking traceroute

traffic?

Answer: Traceroute requests are UDP based

packets and the return packets are ICMP packets

which are either TIL-exceeded or ICMP Echo-Reply.

Enter into configuration mode and navigate to the [edit interfaces]

hierarchy. Remove the input filters from the interfaces. Commit and return to

operational mode when finished.

{master:0}


Entering conf�atration mode


{master:0} [edit)

lab@exB-1# edit interfaces

{master:O} [edit interfaces)


lab@exB-1# delete ge-0/0/6.0 family ethernet-switching filter

{master:O} [edit interfaces)

lab@exB-1# delete ge-0/0/7.0 family ethernet-switching filter

{master:0} [edit interfaces)

lab@exB-1# commit and-quit


commit complete


{master:0}

lab@exB-1>

Step 1.18


From your assigned SRX Series device, attempt to traceroute from each virtual

routing instance to the corresponding IP address on the SRX interface ge-0/0/8.

Type Ctrl + c break out of the traceroute operation if you do not receive responses

for a couple series of attempts.

lab@srxB-1> traceroute address routing-instance Networkl


1 172.23.11.10 (172.23.11.10) 2.234 ms 2.143 ms 2.031 ms

lab@srxB-1> traceroute address routing-instance Network2


1 172.23.12.10 (172.23.12.10) 4.177 ms 2.035 ms 2.486 ms

Question: Was the traceroute successful?

Answer: Yes, the traceroute should succeed.

Step 1.19

From your SRX Series device, log out.

lab@srxB-1> exit

srxB-1 (ttyuO)

login:



Step 1.20

Return to the open session to your EX Series switch.

From your EX Series switch, log out.

{master:O}

lab@exB-1> exit

exB-1 (ttyuO)

login:

• Tell your instructor that you have completed this lab.

Management Network Diagram

__..-0 - __.. __.. __.. �M ++-----�

. ,� SerialConsole Terminal � '- Connections srxA-2 Server \ \. '-

, , '-, \' '

\' '�

\ ' � \ , srxD-2

', '0 \

\

Server

srxA-1 srxA-2 srxB-1 srxB-2 srxC-1 srxC-2

� �

@ F H Workstations

Management Addressing

/_ srxD-1 / _

/_ srx0-2 / _

/_ vr-device /_

/_ Server

/_ Gatev.ey

/_ Term Server

Note: The instructor will provide address and access information

©2013 Juniper Networlcs, Inc All nttits reserved JUntpgr Worldwide Education Ser.ices WWW Juniper net



Pod A Network Diagram: Troubleshooting

Packet Loss and Latency Lab

I MAC: 00 26:88:02:7488

srxA-1

172.23.11 .10/24 172 23.12 .10/24

I MAC: 00:26:88:02:74:86 I I MAC: 00:26:88:02:74:87

Network1 Network2

I MAC: 00:26:88:02:6b:88

srxA-2

172.23.21 .10/24 172 23.22.10/24

I MAC: 00:26:88:02:6b:86

Network1

MAC: 00:26:88:02:6b:87

Network2

©2013 Juniper Networl<s, Inc All ng:hts reserved, JUnLP...§'" \,\/orldwide Education Services wnw Juniper net

Pod B Network Diagram: Troubleshooting


I MAC: 00: 26:88:02:7 4:88

srxB-1

172.23.11 .10/24 172 2312 10/24

exB-1

Network1 Network2

I MAC: 00:26:88:02:6b:88

srxB-2

172 .23.21.10/24 172.23 22 10/24

I MAC: 00:26:88:02:6b 86

Network1

exB-2

MAC: 00 26 88:02:6b:87

Network2

©2013Jun1per Networks, Inc All nthts teseived. Jun,m Worldwide Education Services lf\lVWW Juniper net

______ _, ___ --�----------- ----------



Pod C Network Diagram: Troubleshooting


I MAC: 00:26:88:02:7 4:88

srxC-1

172.23.11.10/24 172.23.12.10/24

exC-1

I MAC: 00:26:88:02:74:86 I MAC: 00:26:88:02:74:87

Net=rk1 Net=rk2

I MAC: 00:26:88 02 6b:88

srxC-2

172 23 21.10/24 172.23.22.10/24

I MAC: 00:26:88:02:6b:86

Net=rk1

MAC: 00:26:88:02:6b:87

Net=rk2

©2013 Juniper Networks, Inc All ne;hh reserved JUnpg_r Worldwide Education Services WW"N Juniper net

Pod D Network Diagram: Troubleshooting


I MAC: 00:26:88:02:7 4:88

srxD-1

172.23.11.10/24 172.23.12.10/24

exD-1

I MAC: 00 26:88:02:74:86 I MAC: 00:26:88:02:74:87

Net=rk1 Net=rk2

I MAC: 00:26:88:02:6b:88

srxD-2

172.23.21.10/24 172.23.22.10/24

I MAC: 00:26 88:02:6b:86

Net=rk1

MAC: 00:26:8802:6b 87

Network2

©2013 Juniper Networl(S, Inc All n,hts reserwed JUn� Worldwide Education Services \J\l','Wl.l Juniper net


Lab

Troubleshooting Virtual Chassis and Interfaces (Detailed)

Overview

In this lab, you will troubleshoot interface and Virtual Chassis issues in your pod and

correct the detected problems.

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

• Troubleshoot interface issues using system CLI.

• Troubleshoot Virtual Chassis issues using system CLI.

• Correct the problems related to the interface and Virtual Chassis issues.


Part 1: Logging In Using the CLI

Step 1.1

Step 1.2


equipment.

Note






assigned device.











Quick Connect rgi' Protocol: I Telnet vi

Hostname: I x.x.x.x

Port: 123 Firewall:

D Show quick connect on startup

I None

� Save session

� Open in a tab

vi

! Connect � ! Cancel

Lab 2-2 • Troubleshooting Virtual Chassis and Interfaces (Detailed) www.juniper.net


Step 1.3


the lab2-start. configfrom the /var/home/lab/ajextj directory. Commit the


exB-1 (ttypO)

login: lab

Password:


{master:O}



{master:O} [edit]

lab@exB-1# load override ajext/lab2-start.config

load complete

{master:O} [edit]

lab@exB-1# commit


commit complete

{master:O} [edit]

lab@exB-1#

Step 1.4



your instructor.

www.juniper.net

Quick Connect L8J' Protocol: I Telnet vi Hostname: I x.x.x.x

Port: 123 Firewall:


I None

� Save session

� Open in a tab

vi

I Connect � [ Cancel

Troubleshooting Virtual Chassis and Interfaces (Detailed) • Lab 2-3


Step 1.5




srxB-1 (ttyuO)

login: lab

Password:

--- JUNOS 12.lRl.9 built 2012-03-24 12:12:49 UTC



[edit]

lab@srxB-1# load override ajext/lab2-start.config

load complete

[edit]


commit complete


lab@srxB-1>

Step 1.6

From both of the virtual routing instances attached to your assigned EX Series

switch, attempt to ping the corresponding IP address on the SRX interface ge-0/0/8.

Refer to the network diagram for this lab to determine the instance names and the

IP addresses assigned to the various virtual routing instances. Type Ctrl + c to break

out of the ping attempts when ready.

lab@srxB-1> ping address routing-instance Networkl

PING 172.23.11.10 (172.23.11.10): 56 data bytes

"C

--- 172.23.11.10 ping statistics


lab@srxB-1> ping address routing-instance Network2

PING 172.23.12.10 (172.23.12.10): 56 data bytes

"C



Question: Are the ping attempts successful?

Answer: No, the ping requests are not successful.


Step 1.7


From Networkl virtual routing instances, start a ping to the corresponding IP

address on the SRX interface ge-0/0/8.


PING 172.23.11.10 (172.23.11.10): 56 data bytes

Open another Telnet session to your SRX Series device.

From your second session to your SRX Series device, use the monitor traffic

interface ge-0/0/8 layer2-headers no-resolve size 1500

detail command while the first session is pinging the SRX ge-0/0/8 interface.

lab@srxB-1> monitor traffic interface ge-0/0/8.0 layer2-headers no-resolve size

1500 detail

Address resolution is OFF.

Listening on ge-0/0/8.0, capture size 1500 bytes

20:56:55.006516 In 00:26:88:02:74:86 > ff:ff:ff:ff:ff:ff, ethertype ARP

(Ox0806), length 60: arp who-has 172.23.11.10 tell 172.23.11.100





Step 1.8

"C

Question: What type of output do you see?

Answer: For this test, you should see ongoing ARP

traffic.

Return to the first session to your SRX Series device.

From the first session to your SRX Series device, use Ctrl+c to stop the existing

ping and then start a new ping from the Network2 routing instance to the

corresponding IP address on the SRX interface ge-0/0/8.


PING 172.23.12.10 (172.23.12.10): 56 data bytes

Return to the second session to your SRX Series device.

From your second session to your SRX Series device, continue to observe the output

from the monitor traffic interface ge-0/0/8 layer2-headers

no-resolve size 1500 detail command while the first session is pinging

the ge-0/0/8 interface.



www.juniper.net Troubleshooting Virtual Chassis and Interfaces (Detailed) • Lab 2-5




Step 1.9

"C

Question: What type of output do you see?

Answer: As previously, you should see ongoing ARP traffic.



ping and then start a ping from the ge-0/0/8 interface to the corresponding address

of your Networkl routing instance interfaces.

lab@srxB-1> ping address

PING 172.23.11.100 (172.23.11.100): 56 data bytes

ping: sendto: ping: sendto:

ping: sendto:

ping: sendto:

No route to host

No route to host

No route to host

No route to host


From your second session to your SRX Series device, observe the output from the ongoingmonitor traffic interface ge-0/0/8 layer2-headers


the routing instance interface .

. . . [NO NEW OUPUT] ...

Step 1.10

Question: What type of output do you see now?

Answer: For this particular part of the test, you should see no new output. That is, you should not

see any ongoing ARP traffic.



ping and then start a ping from the ge-0/0/8 interface to the corresponding address

on one of your Network2 routing instance interfaces.

"C

lab@srxB-1> ping address

PING 172.23.12.100 (172.23.12.100): 56 data bytes

64 bytes from 172.23.12.100: icmp_seq=O ttl=64 time=0.189 ms

64 bytes from 1(2.23.1?..100: icmp_seq=l rtl=64 time=0.214 ms



64 bytes from 172.23.12.100: icmp_seq=2 ttl=64 time=0.216 ms 64 bytes from 172.23.12.100: icmp seq=3 ttl=64 time=0.215 ms


From your second session to your SRX Series device, observe the ongoing output

from the monitor traffic interface ge-0/0/8 layer2-headers


the routing instance interface .

.. . [NO NEW OUPUT] ...

Step 1.11

"'C

Question: What type of output do you see now?

Answer: As in the previous step, you should see no

new output. That is, you should not see any ongoing

ARP traffic.

Question: What can you conclude from the ping and

monitor traffic interface results so far?

Answer: The absence of ARP Reply packets or the

absence of ARP Request packets points to incorrect

addressing (address and/or subnet mask). The

problem seems to be on the ge-0/0/8 interface on

the SRX as pinging from this interface towards the

VR addresses doesn't generate any ARP traffic.

Type Ctrl + c to stop the interface monitoring and log out of your second telnet

session to your SRX device.

lab@srxB-1> exit

srxB-1 (ttyuO)

login:

Step 1.12

Return to the open session to your SRX Series device.

From your SRX Series device, use the show interfaces ge-0/0/8 terse command to verify the IP addressing on the SRX ge-0/0/8 interface.

lab@srxB-1> show interfaces ge-0/0/8 terse Interface Admin Link Proto ge-0/0/8 up up ge-0/0/8.0 up up inet

Local

172.23.11.10/30 172.23.12.100/24

Remote



Step 1.13

Question: What is wrong with these two addresses?

Can you explain the behavior from the ping

attempts and interface monitoring?

Answer: The subnet mask /30 is incorrect. This

explains why when pinging from the SRX ge-0/0/8

there were No route to host messages. As the

/30 means that the 172.23.11.100 address is not

on this subnet, so no ARP can not be sent for the

172.23.11.100 address. For the 172.23.12.100/24

address the host portion is incorrect because this is

a duplicate of the configured address on the

interface on the Network2 routing instance

interface.

Enter configuration mode and navigate to the [edit interfaces ge-0/0/8]

hierarchy. Fix the addressing problems for this interface. Commit and exit to

operational mode after you are finished.



[edit] lab@srxB-1# edit interfaces ge-0/0/8

[edit interfaces ge-0/0/8] lab@srxB-1# show

speed lOOm;

link-mode full-duplex;

mac 00:26:88:02:74:88;

gigether-options {

no-auto-negotiation;

unit O { family inet {

address 172.23.11.10/30;

address 172.23.12.100/24;

[edit interfaces ge-0/0/8] lab@srxB-1# replace pattern 10/30 with 10/24

[edit interfaces ge-0/0/8]

lab@srxB-1# replace pattern .100 with .10


[edit interfaces ge-0/0/8] lab@srxB-1# show speed lOOm; link-mode full-duplex; mac 00:26:88:02:74:88; gigether-options {

no-auto-negotiation;

unit O { family inet {

address 172.23.11.10/24; address 172.23.12.10/24;

[edit interfaces ge-0/0/8] lab@srxB-1# commit and-quit

commit complete Exiting configuration mode

lab@srxB-1>

Step 1.14


From both of the virtual routing instances attached to your assigned EX Series

switch, attempt to ping the corresponding IP address on the SRX interface ge-0/0/8.

Refer to the network diagram for this lab to determine the instance names and the

IP addresses assigned to the various virtual routing instances. Use Ctrl +c to break

out of the ping attempts when ready.


PING 172.23.11.10 (172.23.11.10): 56 data bytes 64 bytes from 172.23.11.10: icmp_seq=O ttl=64 time=24.824 ms 64 bytes from 172.23.11.10: icmp_seq=l ttl=64 time= l.121 ms 64 bytes from 172.23.11.10: icmp seq=2 ttl=64 time=l.293 ms

"C --- 172.23.11.10 ping statistics ---3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.121/9.079/24.824/11.133 ms


PING 172.23.12.10 (172.23.12.10): 56 data bytes 64 bytes from 172.23.12.10: icmp_seq=O ttl=64 time= l.724 ms 64 bytes from 172.23.12.10: icmp seq=l ttl=64 time= l.301 ms "C

--- 172.23.12.10 ping statistics ---2 packets transmitted, 2 packets received, 0% packet loss


• Wait for the instructor before you proceed to the next part.



Part 2: Troubleshooting Virtual Chassis

In this lab part, you will troubleshoot a Virtual Chassis scenario that is not

functioning properly. When you and the team working in the same pod are ready to

proceed with this lab, ask your instructor to set up the pod for this lab. This lab will

require that you work as a team to complete these tasks.

Step 2.1

From the session to your master EX Series switch, ensure that the proper

configuration file has been loaded. Enter configuration mode and load the

lab2-part2-start. configfrom the /var/home/lab/ajext/ directory. Commit

the configuration and exit to operational mode when complete.

{master:0}



{master:0} [edit]

lab@exB-1# load override ajext/lab2-part2-start.config

load complete

{master:O} [edit]

lab@exB-1# conunit and-quit

commit complete


{master:0}

lab@exB-1>

Step 2.2

From the sessions to your SRX Series devices, ensure that the proper configuration

file has been loaded (Remember to do this on both SRX devices). Enter

configuration mode and load the lab2-part2-start. configfrom the /var/

home/lab/ajext/ directory. Commit the configuration and exit to operational mode

when complete.



[edit]

lab@srxB-1# load override ajext/lab2-part2-start.config

load complete

[edit]

lab@srxB-1# conunit and-quit

commit complete


lab@srxB-1>





[edit]

lab@srxB-2# load override ajext/lab2-part2-start.config

load complete

[edit]


commit complete


lab@srxB-2>

Step 2.3

From your assigned SRX Series device, determine if you can ping between the

devices in Network1. Do the same verification for devices in Network2.


PING 172.23.21.100 (172.23.21.100): 56 data bytes

"C

--- 172.23.21.100 ping statistics ---



PING 172.23.22.100 (172.23.22.100): 56 data bytes

"C

--- 172.23.22.100 ping statistics ---


Step 2.4

Question: Are you able to ping the remote device in

Network1 and Network2?

Answer: No, you should not currently be able to ping

the remote devices.

Return to the open session to your master EX Series switch.

From your master EX Series switch, determine the Virtual Chassis status between

the EX Series switches from the perspective of the master device.

{master:0}

lab@exB-1> show virtual-chassis status

Preprovisioned Virtual Chassis

Virtual Chassis ID: 37cd.352a.94a4

Virtual Chassis Mode: Enabled

Mstr

Member ID Status

0 (FPC 0) Prsnt

Serial No Model prio Role

BM0208124335 ex4200-24t 129 Master*

Mixed Neighbor List

Mode ID Interface

N



Step 2.5

Question: What is the current status of your Virtual

Chassis?

Answer: The Virtual Chassis has not established

with the peer. We do not see a secondary device.

Return to the open session to your backup EX Series switch.

From your backup EX Series switch, determine the Virtual Chassis status between

the EX Series switches from the perspective of the backup device.

{master:O}




Mstr

Member ID Status

0 (FPC 0) Prsnt


BM0208124240 ex4200-24t 128 Master*

Member ID for next new member: 1 (FPC 1)

Mixed Neighbor List

Mode ID Interface

N

Question: What is the current status of your Virtual

Chassis on the backup device?

Step 2.6

{master:0}

Answer: The Virtual Chassis has not established

with the master. We do not see a secondary device.


From your master EX Series switch, determine the status of the VC-ports from the

perspective of the master device.

lab@exB-1> show virtual-chassis vc-port

fpcO:

Interface Type Trunk Status Speed Neighbor

or ID (mbps) ID Interface

PIC I Port

vcp-0 Dedicated 2 Down 32000

vcp-1 Dedicated 1 Down 32000


Step 2.7

{rnaster:O}


Question: What does the status of the master's

VC-ports indicate?

Answer: The Down status indicates that the

VC-ports have been enabled locally but you are not

getting any responses from the remote end.


From your backup EX Series switch, determine the status of the VC-ports from the

perspective of the backup device.

lab@exB-2> show virtual-chassis vc-port

fpcO:

Interface

or

PIC I Port

vcp-0

vcp-1

Step 2.8

{rnaster:0}

Type

Dedicated

Dedicated

Trunk Status

ID

2

1

Disabled

Disabled

Speed

(rnbps)

32000

32000

Question: What does the status of the backup

switch's VC-port indicate?

Neighbor

ID Interface

Answer: The status of Disabled indicates the

interfaces have not been enabled.

From your backup EX Series switch, enable the VC-ports so the Virtual Chassis can

attempt to negotiate.

lab@exB-2> request virtual-chassis vc-port set interface vcp-0

{rnaster:O}

lab@exB-2> request virtual-chassis vc-port set interface vcp-1

Step 2.9

{rnaster:O}


From your master EX Series switch, determine the status of the VC-ports from the

perspective of the master device.

lab@exB-1> sh ow vir1 ual-chassis statl.1�

--------------------- ______ _, ___ --�----------- ---------






Member ID Status Serial No Model

0 (FPC 0) Prsnt BM0208124335 ex4200-24t

Unprvsnd BM0208124240 ex4200-24t

Mstr Mixed Neighbor List

prio Role Mode ID Interface

129 Master* N 0 vcp-0

0 vcp-1

Question: What does the Unprvsnd status indicate

in the output of the show virtual-chassis

status command?

Answer: Unprvsnd status means that the serial

number is not configured under the [edit

virtual-chassis J for preprovisioning.


From your backup EX Series switch, determine the serial number for the backup

routing engine so you can correct the preprovision configuration on the master

switch.

{master:O}

lab@exB-2> show virtual-chassis



Member ID

0 (FPC 0)

Status

Prsnt

Mstr

Serial No Model prio

BM0208124240 ex4200-24t 128


Step 2.10

Role

Master*

Mixed

Mode

N


Neighbor List

ID Interface

O vcp-0

O vcp-1

From your master EX Series switch, enter configuration mode and navigate to the

[edit virtual-chassis J hierarchy. Change the serial number configured for

the member 1 device. Commit and exit to operational mode when you are finished.

{master:0}



{master:0} [edit]

lab@exB-1# edit virtual-chassis

{master:0} [edit virtual-chassis]

lab@exB-1# set member 1 serial-number Serial-Number



{master:0} [edit virtual-chassis]

lab@exB-1# show member 1

role routing-engine;

serial-number BM0208124240;

{master:O} [edit virtual-chassis]



commit complete


{master:0}

lab@exB-1>

Step 2.11

Use the show virtual-chassis status command to verify the status of the

Virtual Chassis after making your configuration changes.

{master:0}





Mstr Mixed Neighbor List

Member ID

0 (FPC 0)

1 vcp-1

1 (FPC 1)

Step 2.12

Status

Prsnt

Prsnt

Serial No Model prio Role Mode ID

BM0208124335 ex4200-24t 129 Master* N 1

BM0208124240 ex4200-24t 129 Backup N 0

0

Question: Do you see both members in your Virtual

Chassis?

Answer: Yes, you should see both members in your

Virtual Chassis.


Interface

vcp-0

vcp-0

vcp-1

From your assigned SRX Series device, determine if you can ping between the

devices in Networkl, include a count of 5. Do the same verification for devices in

Network2.

lab@srxB-1> ping address routing-instance Networkl count 5

PING 172.23.21.100 (172.23.21.100): 56 data bytes

64 bytes from 172.23.21.100: icmp_seq=O ttl=63 time=0.995 ms

64 bytes from 172.23.21.100: icmp_seq= l ttl=63 time=2.154 ms

64 bytes from 172.23.21.100: icmp_seq=2 ttl=63 time=0.907 ms

64 bytes from 172.23.21.100: icmp seq=3 ttl=63 time= l.150 ms

--------- _________ ,..... _____ ---------



64 bytes from 172.23.21.100: icmp_seq=4 ttl=63 time= l.699 ms

--- 172.23.21.100 ping statistics ---5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.907/1.381/2.154/0.474 ms

lab@srxB-1> ping address routing-instance Network2 count 5

PING 172.23.22.100 (172.23.22.100): 56 data bytes 64 bytes from 172.23.22.100: icmp_seq=O ttl=64 time=117.350 ms 64 bytes from 172.23.22.100: icmp_seq=l ttl=63 time=l.434 ms 64 bytes from 172.23.22.100: icmp_seq=2 ttl=63 time=l.147 ms 64 bytes from 172.23.22.100: icmp_seq=3 ttl=63 time= l.282 ms 64 bytes from 172.23.22.100: icmp seq=4 ttl=63 time=l.343 ms


Question: Do your ping packets complete?

Answer: Yes, your ping attempts should be

successful.


From your master EX Series switch, restore the Virtual Chassis switches to

standalone mode by disabling the vc-ports as well as recycling and renumbering the

member IDs. You will need to delete the current Virtual Chassis configuration

because you will not be able to recycle member IDs in a preprovisioned Virtual

Chassis.

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

{master:O} lab@exB-1> request virtual-chassis vc-port set interface vcp-1 disable

{master:O} lab@exB-1> configure


{master:O} [edit] lab@exB-1# delete virtual-chassis

{master:0} [edit] lab@exB-1# commit and-quit


commit complete Exiting configuration mode

{master:O} lab@exB-1> reciuE"st vir·':ual-chassis reeve::.:.? memb�r-id 1



{master:0}

lab@exB-1> show virtual-chassis



Mstr

Member ID Status

0 (FPC 0) Prsnt


BM0208124335 ex4200-24t 128 Master*


{master:0}

lab@exB-1>

Step 2.13

Mixed Neighbor List

Mode ID Interface

N


From your backup EX Series switch, restore the Virtual Chassis switches to

standalone mode by disabling the vc-ports as well as recycling and renumbering the

member IDs. You will need to load the Part 2 starting configuration file

(lab2-part2-start. con fig) stored in the /var/home/lab/ajextj directory.

Commit the configuration and exit to operational mode to finish the rest of the

process.

{master:1}

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

{master:1}

lab@exB-1> request virtual-chassis vc-port set interface vcp-1 disable

{master:1}



{master:1} [edit)


load complete

{master:1} [edit)



commit complete


{master:1}

lab@exB-2> request virtual-chassis recycle member-id O

{master:1}

lab@exB-2> request virtual-chassis renumber member-id 1 new-member-id O

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/

If member-specific configuration groups are present, perform a

______ _, ___ --�----------- ---------



"commit full" to synchronize inheritance with the new member number.

Do you want to continue ? [yes, no] (no) yes

{master:1}

lab@exB-2>

exB-2 (ttyuO)

login: lab

Password:


{master:O}

lab@exB-2>

Step 2.14

{master:0}

lab@exB-2> exit

exB-2 (ttyuO)

login:

Step 2.15

{master:0}

lab@exB-1> exit

exB-1 (ttyuO)

login:

Log out of your backup EX Series switch.


From your master EX Series switch, log out.



lab@srxB-1> exit

srxB-1 (ttyuO)

login:





.,. .,.

_

.,..,.

�M FE ----�. � • Serial Console Terminal � '- Connections srxA-2 Server \ '\ '-

\ '\ '-, \ '\ '

\ '\ '� \ '\ �

\ '\ srxD-2

', '0

Server

srxA-1

srxA-2

srxB-1

srxB-2

srxC-1

srxC-2

E �

F H Workstations


/_ srx0-1 /_

/_ srx0-2 /_

/_ vr-device /_

/_ Server

/_ Gatev.ay

/_ Term Server

Note The instructor will provide address and access information.

©2013 Juniper Networl<S, Inc All ntMs reserved Jun,� \,\/orldwide Education Services lfflflW Juniper net


Virtual Chassis and Interfaces Lab (Part 1)

I MAC: 00: 26:88:02:7 4:88

srxA-1

172.23.11 .10/24 172 231 210/24

exA-1

Netv.ork1 Netv.ork2

I MAC: 00:26:88:02:6b:88

srxA-2

172.23.21.10/24 172.23 2210/24

I MAC: 00:26:88:02:6b 86

Network1

exA-2

MAC: 00 26 88:02:6b:87

Netv.ork2


--------- _________ ,..... _____ ----------





Virtual Chassis

Virtual Routers

srxA-1

Network1

VLAN: v11

Network2

VLAN: v12

17 2. 23.11.100/24 17 2. 2312.100/24

vcp-0

vcp-1

Network1

VLAN: v21

srxA-2

----

Network2

VLAN:v22

17 2. 23. 21.100/24 172 . 23. 22.100/24

VWJ Interfaces

vlan.11: 172 .23.11.1/24

vlan.12 172 2312 1/24

vlan.21 172 23.21 1/24

vlan.22: 172.23.22 1/24




I MAC: 00:26:88:02:7 4:88

srxB-1

172 2311.10/24 172.23.12.10/24

exB-1

I MAC: 00 26:88:02:74:86 I MAC: 00:26:88:02:74:87

Network1 Network2

I MAC: 00:26:88:02:6b:88

srxB-2

172 23 2110/24 172 23.22.10/24

I MAC: 00:26 88:02:6b:86

Network1

MAC: 00:26:8802:6b 87

Network2





Virtual Chassis and Interfaces Lab {Part 2)

Virtual Chassis

Virtual Routers

srxB-1

Netv.orkl

VLAN:v11

Netv.ork2

VLAN: v12

172.23.11. 100/24 172 23.12 100/24

vcp-0

vcp-1

Networkl

VLAN:v 21

srxB-2

----

Netv.ork2

VLAN v22

172.23.21.100/24 172.23.22.100/24

VLAN Interfaces

via n.11 172.23.111/24

vlan.12: 172 23121/24

vlan.21: 172 23 211/24

vlan.22 172 23.22.1/24




I MAC: 00: 26:88:02:7 4:88

srxC-1

172.23.11.10/24 172 231210/24

exC-1

Netv.orkl Netv.ork2

I MAC: 00:26:88:02:6b:88

srxC-2

172.23.21.10/24 172.23 2210/24

I MAC: 00:26:88:02:6b 86

Networkl

exC-2

MAC: 00 26 88:02:6b:87

Netv.ork2


______ _, ___ --�----------- ----------





srxC-1

Virtual Chassis

Virtual Routers

Network1 Netl'IOrk2 VLAN: v11 VLAN: v12

172.23.11.100/24 172.23.12.100/24

vcp-0

vcp-1

Network1 VLAN: v21

srxC-2

Vl.AN Interfaces

via n.11: 172.23.11.1/24

vlan.12: 172 23 12 1/24 ----

Network2 VLAN:v22

vlan.21: 172.23.21.1/24 vlan.22: 172.23.22.1/24

172.23.21 100/24 172 23 22 100/24

©2013 Juniper Networl<S, Inc All ntht, re,med JUn!Pgf Worldwide Education Services WWW 1un1per net



I MAC: 00: 26:88:02:7 4:88

srxD-1

172.23.11.10/24 172.23.12.10/24

exD-1

I MAC: 00 26:88:02:74:86 I MAC: 00:26:88:02:74:87

Netl'IOrk1 Network2

I MAC: 00:26:88:02:6b:88

srxD-2

172.23.21.10/24 172.23.22.10/24

I MAC: 00:26 88:02:6b:86

Network1

MAC: 00:26:8802:6b 87

Network2

©2013 Juniper Networl<S, Inc All nllJ>ts resmed JUn!P� Worldwide Education Services www Juniper net





Virtual Chassis

Virtual Routers

srxD-1

Netv.orkl

VLAN:v11

Netv.ork2

VLAN: v12

172.23.11.100/24 172 23.12 100/24

vcp-0

vcp-1

Networkl

VLAN:v21

srxD-2

----

Netv.ork2

VLAN v22

172.23.21.100/24 172.23.22.100/24

VLAN Interfaces

via n.11 172.23.11 1/24

vlan.12: 172 2312 1/24

vlan.21: 172 23 21 1/24

vlan.22 172 23.22.1/24




�


Overview

Lab

Troubleshooting Spanning Tree Protocols (Detailed)

In this lab, you will troubleshoot RSTP and MSTP issues within your pod and correct the

detected problems. You will need to work together with your partner group to troubleshoot

the RSTP and MSTP issues.

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

• Troubleshoot convergence issues related to RSTP deployments.

• Troubleshoot connectivity issues related to MSTP.

• Correct the problems found during your troubleshooting steps.


Part 1: Troubleshooting RSTP

Step 1.1

Step 1.2


equipment.

Note






assigned device.












Hostname: I x.x.x.x

Port: 123 Firewall:


I None

� Save session

� Open in a tab

vi


Lab 3-2 • Troubleshooting Spanning Tree Protocols (Detailed) www.juniper.net


Step 1.3




exB-1 (ttypO)

login: lab

Password:


{master:O}



{master:O} [edit]


load complete

{master:O} [edit]



commit complete


{master:0}

lab@exB-1>

Step 1.4



your instructor.

www.juniper.net

Quick Connect �'


Hostname: !x.x.x.x

Port: 123 Firewall:


!None

� Save session

� Open in a tab

vi


rroubleshooting Spanning Tree Protocols (Detailed) • Lab 3-3


Step 1.5




srxB-1 (ttyuO)

login: lab

Password:

--- JUNOS 12.1R5.5 built 2013-01-17 06:12:00 UTC



[edit]


load complete

[edit]


commit complete


lab@srxB-1>

Step 1.6

From your SRX Series device, use the show spanning-tree interface

command to determine what interfaces are participating in your RSTP topology. Use

the show spanning-tree bridge command to determine which device is

acting as the root bridge for your network.

lab@srxB-1> show spanning-tree interface

Spanning tree interface parameters for instance O

Interface Port ID Designated

port ID

ge-0/0/1.0 128:514 128:514

ge-0/0/8.0 128:521 128:521

ge-0/0/10.0 128:523 128:523

lab@srxB-1> show spanning-tree bridge

STP bridge parameters

Context ID

Enabled protocol

Root ID

Root cost

Root port

Hello time

Maximum age

Forward delay

Message age

Number of topology changes

Time since �?s� �on0 ngy c�Rn��

Designated

bridge ID

4096.002688027490

4096.002688027490

0.0019e2553181

0

RSTP

0.00:19:e2:55:31:81

20000

ge-0/0/10.0

2 seconds

20 seconds

15 seconds

1

10

Lab 3-4 • Troubleshooting Spanning Tree Protocols (Detailed)

Port State Role

Cost

20000 FWD DESG

20000 FWD DESG

20000 FWD ROOT

www.juniper.net


Topology change initiator

Topology change last recvd. from

Local parameters

ge-0/0/10.0

00:19:e2:55:31:8d

Bridge ID

Extended system ID

Internal instance ID

Step 1.7

4096.00:26:88:02:74:90

0

0

Question: Are the correct interfaces participating in

RSTP on your SRX device?

Answer: Yes, you should see that you have the

correct interfaces.

Question: What is the enabled protocol?

Answer: The enabled protocol should be RSTP.


From your EX Series switch, use the show spanning-tree interface




{master:0}

lab@exB-1> show spanning-tree interface

Spanning tree interface parameters for instance O


port ID

ge-0/0/6.0 128:519 128:519

ge-0/0/7. 0 128:520 128:520

ge-0/0/8.0 128:521 128:521

ge-0/0/9.0 128:522 128:522

ge-0/0/10.0 128:523 128:523

{master:0}

lab@exB-1> show spanning-tree bridge


Context ID

Enabled protocol

Root ID

Root cost

Root port

Hello tirre

Designated

bridge ID

32768.0019e2553c01

32768.0019e2553c01

4096.002688027490

32768.0019e2553c01

8192.002688026b90

0

RSTP

0.00:19:e2:55:31:81

40000

ge-0/0/8.0

2 seconds

Port

Cost

20000

20000

20000

20000

20000

State

FWD

FWD

FWD

FWD

BLK

Role

DESG

DESG

ROOT

DESG

ALT

www.juniper.net rroubleshooting Spanning Tree Protocols (Detailed) • Lab 3-5


Maximum age 20 seconds

15 seconds

2

Forward delay

Message age

Number of topology changes 2

Time since last topology change



Local parameters

1594 seconds

ge-0/0/8.0

00:26:88:ff:be:08

Bridge ID

Extended system ID


32768.00:19:e2:55:3c:01

0

0

Step 1.8

Note

You must compare results with the remote

team in your Pod to understand the full

RSTP topology and answer the following

questions.

Question: Which device is acting as the Root

Bridge?

Answer: After comparing your outputs you should

see that ex_K-2 device is the acting root bridge for

the network.

Question: Do you see anything that is not correct

with your devices?

Answer: You should notice that the exx-2 device is

configured for STP, which will result in convergence

issues when a link flaps on exK-2.


From your SRX device, start a ping from your local Network1 device to the remote

teams Network1 device. While this ping is running deactivate the ge-0/0/10 on

exK-2 and see if this results in packet loss.



Note

To do this step, it is best to just test in one

direction. If you choose to do this, start the

ping from the virtual routing instance

connected to exx-1. The remote team can

be responsible for deactivating the ge-0/0/

10 interface on their exx-2 switch. This will

save some time between running

commands and verifying behavior.These

steps are combined below to illustrate the

commands on the two devices.

lab@srxB-1> ping address routing-instance instance

PING 172.23.11.101 (172.23.11.101): 56 data bytes 64 bytes from 172.23.11.101: icmp_seq=O ttl=64 time=26.277 ms 64 bytes from 172.23.11.101: icmp_seq= l ttl=64 time= l.071 ms 64 bytes from 172.23.11.101: icmp_seq=2 ttl=64 time= l.215 ms 64 bytes from 172.23.11.101: icmp_seq=3 ttl=64 time= l.147 ms 64 bytes from 172.23.11.101: icmp_seq=4 ttl=64 time= l.192 ms 64 bytes from 172.23.11.101: icmp_seq=5 ttl=64 time= l.194 ms 64 bytes from 172.23.11.101: icmp_seq=6 ttl=64 time= l.167 ms 64 bytes from 172.23.11.101: icmp_seq=7 ttl=64 time= l.180 ms 64 bytes from 172.23.11.101: icmp_seq=14 ttl=64 time=3.029 ms 64 bytes from 172.23.11.101: icmp_seq=15 ttl=64 time= l.182 ms 64 bytes from 172.23.11.101: icmp_seq=16 ttl=64 time=l.228 ms 64 bytes from 172.23.11.101: icmp seq=17 ttl=64 time= l.179 ms "C --- 172.23.11.101 ping statistics ---18 packets transmitted, 12 packets received, 33% packet loss round-trip min/avg/max/stddev = 1.071/3.422/26.277/6.910 ms

lab@srxB-1>

{master:O} lab@exB-2> configure Entering configuration mode

{master:0} [edit) lab@exB-2# deactivate interfaces ge-0/0/10

{master:O} [edit) lab@exB-2# commit configuration check succeeds commit complete



Step 1.9

Question: How many ping packets were dropped

during the time between the interface going down

and the spanning tree path recalculation?

Answer: The answer might vary but the number of

packets should be fairly low. In the sample above,

you can see that we lost 6 packets during this

process.


teams Network1 device. While this ping is running re-activate the ge-0/0/10 on

ex_K-2 and see if this results in more packet loss than you saw when deactivating the

interface.

Note

To do this step, we recommend that you

test only in one direction. If you choose to

do this, start the ping from the virtual

routing instance connected to ex_K-1. The

remote team can be responsible for

activating the ge-0/0/10 interface on their

exx-2 switch. This will save some time

between running commands and verifying

behavior. These steps are combined in the

following output to illustrate the commands

on the two devices.


PING 172.23.11.101 (172.23.11.101): 56 data bytes

64 bytes from 172.23.11.101: icmp -

seq=O ttl=64 time=6.147 ms

64 bytes from 172.23.11.101: icmp -


64 bytes from 172.23.11.101: icmp -

seq=2 ttl=64 time=l .170 ms

64 bytes from 172.23.11.101: icmp -


64 bytes from 172.23.11.101: icmp -


64 bytes from 172.23.11.101: icmp -

seq=5 ttl=64 time= l. 270 ms

64 bytes from 172.23.11.101: icmp -


64 bytes from 172.23.11.101: icmp -


64 bytes from 172.23.11.101: icmp -


"C --- 172.23.11.101 ping statistics ---



lab@srxB-1>



{master:O} [edit]

lab@exB-2# activate interfaces ge-0/0/10

{master:0} [edit]



commit complete


{master:O}

lab@exB-2>

Step 1.10

Question: Did you experience more packet loss

when the ge-0/0/10 interface was brought online?

Why did you see these results?

Answer: Yes, you should see more packet loss when

enabling the interface. The reactivation of the

interface results in more packet loss because when

the interface comes back on line it has to go through

the slow STP learning and listening phases that

take about 30 seconds.

Note

The next step only applies to the group that

manages the exx-2 EX Series Switch.

From the ex_K-2 EX Series switch, enter configuration mode and change the

configure spanning tree protocol to RSTP. Ensure your configuration accounts for the

edge interface and bridge priority outlined on the network topology. Commit and exit

to operational mode when finished.

{master:O}



{master:O} [edit]

lab@exB-2# delete protocols stp

{master:O} [edit]

lab@exB-2# set protocols rstp interface ge-0/0/9 edge

{master:0} [edit]

lab@exB-2# set protC'cols rstp bridge-��iori t�, 0

--------------------- ______ _, ___ --�----------- ---------



{master:0} [edit]



commit complete


{master:O}

lab@exB-2>

Step 1.11



teams Network1 device. While this ping is running deactivate the ge-0/0/10 on

ex_K-2 and see if this results in packet loss now that all devices are running RSTP.

Note

To perform this step, we recommend that

you test only in one direction. If you choose

to do this, start the ping from the virtual



deactivating the ge-0/0/10 interface on

their ex_K-2 switch, which will save some

time between running commands and

verifying behavior.These steps are

combined in the following output to

illustrate the commands on the two

devices.


PING 172.23.11.101 (172.23.11.101): 56 data bytes

64 bytes from 172.23.11.101: icmp -

seq=O ttl=64 time=4. 070 ms

64 bytes from 172.23.11.101: icmp -

seq=l ttl=64 time=l.278 ms

64 bytes from 172.23.11.101: icmp -

seq=2 ttl=64 time=l .192 ms

64 bytes from 172.23.11.101: icmp -

seq=3 ttl=64 time=l.207 ms

64 bytes from 172.23.11.101: icmp -


64 bytes from 172.23.11.101: icmp -

seq=5 ttl=64 time=l. 208 ms

64 bytes from 172.23.11.101: icmp -


64 bytes from 172.23.11.101: icmp -

seq=ll ttl=64 time=5.252 ms

64 bytes from 172.23.11.101: icmp -


64 bytes from 172.23.11.101: icmp -


64 bytes from 172.23.11.101: icmp -


64 bytes from 172.23.11.101: icmp -


"C --- 172.23.11.101 ping statistics ---



lab@srxB-1>


{master:O} lab@exB-2> configure Entering configuration mode

{master:O} [edit]


lab@exB-2# deactivate interfaces ge-0/0/10

{master:O} [edit] lab@exB-2# commit configuration check succeeds commit complete

Step 1.12


teams Network1 device. While this ping is running, re-activate the ge-0/0/10 on

ex_K-2 and see if this results in more packet loss than you saw when deactivating the

interface now that all devices are running RSTP.

Note

To perform this step, we recommend that

you test only in one direction. If you choose

to do this, start the ping from the virtual



activating the ge-0/0/10 interface on their

exx-2 switch. This will save some time

between running commands and verifying

behavior. These steps are combined in the

following output to illustrate the commands

on the two devices.


PING 172.23.11.101 (172.23.11.101): 56 data bytes 64 bytes from 172.23.11.101: icmp_seq=O ttl=64 time=2.117 ms 64 bytes from 172.23.11.101: icmp_seq= l ttl=64 time=l.159 ms 64 bytes from 172.23.11.101: icmp_seq=2 ttl=64 time=l.150 ms 64 bytes from 172.23.11.101: icmp_seq=3 ttl=64 time=l.345 ms 64 bytes from 172.23.11.101: icmp_seq=4 ttl=64 time=l.337 ms 64 bytes from 172.23.11.101: icmp_seq=5 ttl=64 time=l.904 ms 64 bytes from 172.23.11.101: icmp_seq=6 ttl=64 time=l.205 ms 64 bytes from 172.23.11.101: icmp_seq=7 ttl=64 time=4.282 ms 64 bytes from 172.23.11.101: icmp_seq=8 ttl=64 time=l.236 ms 64 bytes from 172.23.11.101: icmp_seq=9 ttl=64 time=4.100 ms 64 bytes from 172.23.11.101: icmp_seq= lO ttl=64 time=l.250 ms 64 bytes from 172.23.11.101: icmp_seq= ll ttl=64 time= l.045 ms 64 bytes from 172.23.11.101: icmp_seq=12 ttl=64 time= l.146 ms 64 bytes from 172.23.11.101: icmp_seq=13 ttl=64 time= l.416 ms 64 bytes from 172.23.11.101: icmp_seq=14 ttl=64 time=l.291 ms 64 bytes from 172.23.11.101: icmp_seq=15 ttl=64 time= l.237 ms 64 bytes from 172.23.11.101: icmp seq=16 ttl=64 time=l.222 ms

www.juniper.net Troubleshooting Spanning Tree Protocols (Detailed) • Lab 3-11


64 bytes from 172.23.11.101: icmp -


64 bytes from 172.23.11.101: icmp -

seq=18 ttl=64 time=l.224

64 bytes from 172.23.11.101: icmp -


64 bytes from 172.23.11.101: icmp -


64 bytes from 172.23.11.101: icmp -


"C

--- 172.23.11.101 ping statistics ---22 packets transmitted, 22 packets received, 0% packet loss


lab@srxB-1>

{master:0} [edit]

lab@exB-2# activate interfaces ge-0/0/10


configuration check succeeds commit complete


{master:0} lab@exB-2>

ms

ms

ms

ms

ms

Question: Do you still see packet loss when you

deactivate and reactivate the ge-0/0/10 interface

on exx-2?

Part 2: Troubleshooting MSTP

Answer: Yes, you will see some packet loss. The

packet loss should be significantly less than when

the root bridge was using STP.

In this lab part, you troubleshoot an MSTP implementation that has some

convergence issues when links go down.

Step 2.1

From your SRX device, enter configuration mode and load the

lab3-part2-start. configfrom the /var/home/lab/ajextj directory. Commit

the configuration and return to operational mode when complete.



[edit] lab@srxB-1# load override ajext/lab3-part2-start.config

load complete



[edit)


commit complete


lab@srxB-1>

Step 2.2


From your EX Series switch, enter configuration mode and load the

lab3-part2-start. configfrom the /var/home/lab/ajextj directory. Commit

the configuration and return to operational mode when complete.

{master:O}



{master:O} [edit)


load complete

{master:0} [edit)



commit complete


{master:0}

lab@exB-1>

Step 2.3

From your EX Series switch, use the show spanning-tree interface




{master:0}

lab@exB-1> 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.0019e2553c01 20000 FWD DESG

ge-0/0/7. 0 128:520 128:520 32768.0019e2553c01 20000 FWD DESG

ge-0/0/8.0 128:521 128:521 32768.002688ffbe10 20000 FWD ROOT

ge-0/0/10.0 128:523 128:523 32768.b0c69a705490 20000 BLK ALT


Interface Port ID Designated Designated Port State Role

port ID bridge ID Cost

ge-0/0/6.0 128:519 128:519 32769.0019e2553c01 20000 FWD DESG

ge-0/0/10.C ,_�Q·:23 128:':-'.2; P1�3.hncS9=7C54° 0 2001)1) FWD ROOT ---------------- ______ _, ___ --�----------- --





port ID

ge-0/0/7. 0

ge-0/0/8.0

128:520 128:520

{master:0}

128:521 128:521

lab@exB-1> show spanning-tree bridge


Context ID

Enabled protocol

STP bridge parameters for CIST

Root ID

Root cost

Root port

CIST regional root

CIST internal root cost

Hello time

Maximum age

Forward delay

Hop count

Message age





Local parameters

Bridge ID

Extended system ID


STP bridge parameters for MSTI 1

MSTI regional root

Root cost

Root port

Hello time

Maximum age

Forward delay

Hop count





Local parameters

Bridge ID

Extended system ID



MSTI regional root

Root cost

Designated

bridge ID

32770.0019e2553c01

8194.002688ffbel0

0

MSTP

Port

Cost

20000

20000

32768.00:19:e2:55:31:81

0

ge-0/0/8.0

32768.00:19:e2:55:31:81

40000

2 seconds

20 seconds

15 seconds

18

0

4

259 seconds

ge-0/0/8.0

b0:c6:9a:70:54:8a

32768.00:19:e2:55:3c:Ol

0

0

4097.00:26:88:ff:be:10

40000

ge-0/0/10.0

2 seconds

20 seconds

15 seconds

18

5

260 seconds

ge-0/0/10. 0

b0:c6:9a:70:54:8a

32769.00:19:e2:55:3c:Ol

0

1

: 4098.b0:c6:9a:70:54:90

: 4onoo

Lab 3-14 • Troubleshooting Spanning Tree Protocols (Detailed)

State Role

FWD DESG

FWD ROOT

www.juniper.net


Root port

Hello time

Maximum age

Forward delay

Hop count





Local parameters

Bridge ID

Extended system ID


Step 2.4

ge-0/0/8.0

2 seconds

20 seconds

15 seconds

18

1

395 seconds

ge-0/0/8.0

00:26:88:ff:be:08

32770.00:19:e2:55:3c:Ol

0

2


From your SRX Series device, use the show spanning-tree interface




lab@srxB-1> show spanning-tree interface


Interface Port ID Designated Designated

port ID bridge ID

ge-0/0/1.0 128:514 128:514 32768.002688ffbel0

ge-0/0/8.0 128:521 128:521 32768.002688ffbel0

ge-0/0/10.0 128:523 128:523 32768.0019e2553181



port ID bridge ID

ge-0/0/1.0 128:514 128:514 4097.002688ffbel0

ge-0/0/8.0 128:521 128:521 4097.002688ffbel0

ge-0/0/10.0 128:523 128:523 4097.002688ffbel0



port ID bridge ID

ge-0/0/1.0 128:514 128:514 4098.b0c69a705490

ge-0/0/8.0 128:521 128:521 8194.002688ffbel0

ge-0/0/10.0 128:523 128:523 8194.002688ffbel0

lab@srxB-1> show spanning-tree bridge


Context ID

Enabled protocol

STP bridge parameters for CIST

0

MSTP

Port

Cost

20000

20000

20000

Port

Cost

20000

20000

20000

Port

Cost

20000

20000

20000

State Role

FWD DESG

FWD DESG

FWD ROOT

State Role

FWD DESG

FWD DESG

FWD DESG

State Role

FWD ROOT

FWD DESG

FWD DESG



Root ID

Root cost

Root port

CIST regional root

CIST internal root cost

Hello time

Maximum age

Forward delay

Hop count

Message age





Local parameters

Bridge ID

Extended system ID



MSTI regional root

Hello time

Maximum age

Forward delay





Local parameters

Bridge ID

Extended system ID



MSTI regional root

Root cost

Root port

Hello time

Maximum age

Forward delay

Hop count





Local parameters

Bridge ID

Extended system ID


32768.00:19:e2:55:31:81

0

ge-0/0/10.0

32768.00:19:e2:55:31:81

20000

2 seconds

20 seconds

15 seconds

19

0

2

434 seconds

ge-0/0/10. 0

00:19:e2:55:31:8d

32768.00:26:88:ff:be:10

0

0

4097.00:26:88:ff:be:10

2 seconds

20 seconds

15 seconds

4

434 seconds

ge-0/0/1. 0

b0:c6:9a:70:54:81

4097.00:26:88:ff:be:10

0

1

4098.b0:c6:9a:70:54:90

20000

ge-0/0/1. 0

2 seconds

20 seconds

15 seconds

19

3

404 seconds

ge-0/0/1. 0

b0:c6:9a:70:54:81

8194.00:26:88:ff:be:10

0

2


Step 2.5


Note

You must compare results with the remote

team in your Pod to understand the full

MSTP topology and answer the following

questions.

Question: What device is acting as the Root Bridge

for which MSTI group?

Answer: The srx_K-1 device should be acting and the

root bridge for MSTI 1 and srx_K-2 should be acting

as Root Bridge for MSTI 2.

Question: Do you see the correct interfaces in each

of the MSTI groups on all devices?

Answer: No, there is a problem on the ex_K-1 switch.

The ge-0/0/8 interface is missing from MSTI 1 and

the ge-0/0/10 interface is missing from MSTI 2.

Although the output of the previous step was not as expected, there should not be

any noticeable problems for traffic at this point.

From your SRX Series device, verify that this issue does not affect ping traffic from

your local Network1 device to the remote teams Network1 device. Limit the number

of ping attempts to 5.

lab@srxB-1> ping address routing-instance Networkl count 5 PING 172.23.11.101 (172.23.11.101): 56 data bytes 64 bytes from 172.23.11.101: icmp_seq=O ttl=64 time=2.185 ms 64 bytes from 172.23.11.101: icmp_seq= l ttl=64 time=3.323 ms 64 bytes from 172.23.11.101: icmp_seq=2 ttl=64 time= l.224 ms 64 bytes from 172.23.11.101: icmp_seq=3 ttl=64 time= l.302 ms

64 bytes from 172.23.11.101: icmp_seq=4 ttl=64 time= l.240 ms




Step 2.6

Question: Did you experience any packet loss during

the ping test?

Answer: No, you should not see any packet loss.

Question: What would happen if the ge-0/0/10

interface failed on exx-1?

Answer: The outage of the ge-0/0/10 interface

should cause an outage for the v11 vlan.

Note

The next step applies only to the group that


From the ex.K-1 EX Series switch, enter configuration mode and disable the

ge-0/0/10 interface. Commit and exit to operational mode when you are finished.

{master:0} lab@exB-1> configure


{master:0} [edit]

lab@exB-1# set interfaces ge-0/0/10 disable



commit complete


{master:0} lab@exB-1>

Step 2.7


From your SRX Series device, determine if you are still able to ping from your local

Network1 device to the remote teams Network1 device. Limit the number of ping

attempts to 5.


PING 172.23.11.101 (172.23.11.101): 56 data bytes



--- 172.23.11.101 ping statistics ---


lab@srxB-1>

Step 2.8

{master:0}

lab@exB-1>

Interface

ge-0/0/1.0

ge-0/0/6.0

ge-0/0/7. 0

ge-0/0/8.0

ge-0/0/9.0

ge-0/0/10.0

{master:0}

lab@exB-2>

Interface

ge-0/0/6.0

ge-0/0/7. 0

ge-0/0/8.0

ge-0/0/9.0

Question: Did you experience any packet loss during

the ping test?

Answer: Yes, The ping attempts should fail now that

the only interface from exX-1 for MSTI 1 is disabled.


From your EX Series switch, use the show ethernet-switching

interfaces command to display the VLANs assigned to the ethernet-switching

interfaces. Compare the results with your remote group.

Note

Outputs from both devices are displayed in

the following output to help compare the

results. You should compare your results

with your remote team.

show ethernet-switching interfaces

State VLAN members Tag Tagging Blocking

down default untagged blocked by

up vll 11 untagged unblocked

up v12 12 untagged unblocked

up v12 12 tagged unblocked

v14 14 tagged unblocked


down vll 11 tagged blocked by

v13 13 tagged blocked by

show ethernet-switching interfaces

State VLAN members Tag Tagging Blocking

up vll 11 untagged unblocked

up v12 12 untagged unblocked

up vll 11 tagged blocked by


v13 13 tagged blocked by





STP

STP

STP

STP

STP

STP

STP

www.juniper.net Troubleshooting Spanning Tree Protocols (Detailed) • Lab3-19


ge-0/0/10.0 up vll 11 tagged unblocked

v12 12 tagged blocked by STP



v21

v22

Step 2.9

21 tagged unblocked

22 tagged unblocked

Question: Can you determine why the ge-0/0/8

interface is not participating in MSTI 1 and the

ge-0/0/10 interface is not participating in MSTI 2?

Answer: You should notice that the interfaces do not include all the VLANs on ex_K-1. This problem would

explain why the interfaces are not in all the MSTI

regions.

Note

The next step applies only to the group that


From the ex_K-1 EX Series switch, enter configuration mode and add the missing

VLANs to ge-0/0/10 and ge-0/0/8. The best way to ensure that a trunk port does

not need to be updated when a new VLAN is added is to configure the VLAN

members using the all statement instead of specifying each VLAN. Commit and

exit to operational mode when you are finished.

{master:0}



{master:0} [edit]

lab@exB-1# edit interfaces ge-0/0/10

{master:0} [edit interfaces ge-0/0/10]

lab@exB-1# delete unit O family ethernet-switching vlan

{master:O} [edit interfaces ge-0/0/10]

lab@exB-1# set unit O family ethernet-switching vlan members all

{master:0} [edit interfaces ge-0/0/10]

lab@exB-1# top edit interfaces ge-0/0/8


lab@exB-1# delete unit O family ethernet-switching vlan


lab@exB-1# set unit O family ethernet-switching vlan members all

----------------------- --------- _________ ,..... _____ -------



{master:0} [edit interfaces ge-0/0/8] lab@exB-1# commit and-quit configuration check succeeds commit complete Exiting configuration mode

{master:O} lab@exB-1>

Step 2.10

From the ex�-1 EX Series switch, use the show ethernet-swi tching

interfaces command to verify the interfaces now show all the VLANs as

members.

{master:0} lab@exB-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 vll 11 untagged unblocked ge-0/0/7. 0 up v12 12 untagged unblocked ge-0/0/8.0 up vll 11 tagged unblocked

v12 12 tagged unblocked v13 13 tagged unblocked v14 14 tagged unblocked v21 21 tagged unblocked v22 22 tagged unblocked

ge-0/0/9.0 down default untagged blocked by STP ge-0/0/10.0 down vll 11 tagged blocked by STP


v13 13 tagged blocked by STP v14 14 tagged blocked by STP v21 21 tagged blocked by STP v22 22 tagged blocked by STP

Question: Do you see the missing VLANs on the

interfaces now?

Answer: Yes, you should see them now.

Step 2.11


From your SRX Series device, determine if you are able to ping from your local

Network1 device to the remote teams Network1 device. Limit the number of ping

attempts to 5.


PING 172.23.11.101 (172.23.11.101): 56 data bytes 64 bytes from 172.23.11.101: icmp_seq=O ttl=64 time=12.507 ms 64 bytes from 172.23.11.101: icmp seq= l ttl=64 time=l.308 ms



64 bytes from 172.23.11.101: icmp -

seq=2 ttl= 64 time= l.195 ms

64 bytes from 172.23.11.101: icmp seq=3 ttl= 64 time=l. 538 ms

64 bytes from 172.23.11.101: icmp -

seq=4 ttl= 64 time= l.191 ms

--- 172.23.11.101 ping statistics ---



Step 2.12

Question: Do your ping attempts complete

successfully now?

Answer: Yes, they should complete now that you

have a redundant interface in the MSTI 1 region.


lab@srxB-1> exit

srxB-1 (ttyuO)

login:

Step 2.13

{master:O}

lab@exB-1> exit

exB-1 (ttyuO)

login:

•


From your EX Series switch, log out.

Tell your instructor that you have completed this lab.




.,. .,.

_

.,..,.

�M FE ----�. � • Serial Console Terminal � '- Connections srxA-2

Server \ '\ '-

\ '\ '-, \ '\ '

\ '\ '� \ '\ �

\ '\ srxD-2

', '0

Server

srxA-1

srxA-2

srxB-1

srxB-2

srxC-1

srxC-2

E �

F H Workstations


/_ srx0-1 /_

/_ srx0-2 /_

/_ vr-device /_

/_ Server

/_ Gatev.ay

/_ Term Server




Spanning Tree Protocols Lab (RSTP Part 1)

Bridge Priority: 4K

srxA-1

ge-0/0/9

VLAN: v11 VLAN: v12

Network1 Network2

Bridge Priority: 8K

srxA-2

VLAN v11

Network1

Bridge Priority OK

ge-0/0/9

VLAN:v12

172 2312101/24

Network2





Spanning Tree Protocols Lab {MSTP Part 2)

MSTP lnsta nee 1Bridge Priority: 4K (v11. v13)

MSTP Instance 2 Bridge-Priority: Bk (v12. v14)

MSTP lnsta nee 1 (v11, v13)


ge-0/0/9

VLAN v11

Network1

srxA-1

VLAN:v12

Network2

MSTP lnsta nee 1Bridge Priority: BK (v11, v13)

MSTP Instance 2 Bridge-Priority: 4k (v12. v14)

srxA-2

VLAN: v11

Network1

MSTP Instance 1 (v11, v13)


ge-0/0/9

VLAN: v12

172.23.12.101/24

Network2



Spanning Tree Protocols Lab {RSTP Part 1)

Bridge Priority: 4K

srxB-1

ge-0/0/9

VLANv11 VLAN:v12

Network1 Network2

Bridge Priority: BK

VLAN v11

Network1

Bridge Priority: OK

ge-0/0/9

VLAN: v12

172 2312 101/24

Network2





Spanning Tree Protocols Lab (MSTP Part 2)

MSTP Instance 1Bridge Priority: 4K(v11, v13)

MSTP lnsta nee 2 Bridge-Priority: Bk (v12, v14)



ge-0/0/9

Vl.AN: v11

Network1

srxB-1

Vl.AN: v12

Network2

MSTP I nsta nee 1Brid ge Priority: BK (v11, v13)

MSTP lnsta nee 2 Bridge-Priority 4k (v12, v14)

srxB-2

Vl.AN: v11

Network1

MSTP I nsta nee 1 (v11, v13)


ge-0/0/9

Vl.AN: v12

172.23.12.101/24

Network2



Spanning Tree Protocols Lab (RSTP Part 1)

Bridge Priority: 4K

srxC-1

ge-0/0/9

Vl.AN: v11 VLAN: v12

Network1 Network2

Bridge Priority: BK

srxC-2

VLAN v11

Network1

Bridge Priority OK

ge-0/0/9

VLAN: v12

172 2312 101/24

Network2


www.juniper.net

_________ ,..... _____ ----------

Troubleshooting Spanning Tree Protocols (Detailed) • Lab 3-25



Spanning Tree Protocols Lab {MSTP Part 2)

MSTP lnsta nee 1Bridge Priority: 4K (v11. v13)

MSTP Instance 2 Bridge-Priority: Bk (v12. v14)



ge-0/0/9

VLAN v11

Network1

srxC-1

VLAN:v12

Network2

MSTP lnsta nee 1Bridge Priority: BK (v11, v13)

MSTP Instance 2 Bridge-Priority: 4k (v12. v14)

srxC-2

VLAN: v11

Network1



ge-0/0/9

VLAN: v12

172.23.12.101/24

Network2



Spanning Tree Protocols Lab {RSTP Part 1)

Bridge Priority: 4K

srxD-1

ge-0/0/9

VLANv11 VLAN:v12

Network1 Network2

Bridge Priority: BK

VLAN v11

Network1

Bridge Priority: OK

ge-0/0/9

VLAN: v12

172 2312 101/24

Network2





Spanning Tree Protocols Lab (MSTP Part 2)

MSTP Instance 1Bridge Priority: 4K(v11, v13)

MSTP lnsta nee 2 Bridge-Priority: Bk (v12, v14)



ge-0/0/9

Vl.AN: v11

Network1

srxD-1

Vl.AN: v12

Network2

MSTP I nsta nee 1Brid ge Priority: BK (v11, v13)

MSTP lnsta nee 2 Bridge-Priority 4k (v12, v14)

srxD-2

Vl.AN: v11

Network1

MSTP I nsta nee 1 (v11, v13)


ge-0/0/9

Vl.AN: v12

172.23.12.101/24

Network2


- - � -- - - -- - - - - - - - --------



�


Overview

Lab

Troubleshooting Port Security (Detailed)

In this lab, you will troubleshoot port security features and correct any detected problems.

You will need to work together with your partner pod to troubleshoot these issues.

By completing this lab you will perform the following task:

• Troubleshoot connectivity issues related to basic unicast traffic .

www.juniper.nut . -·::,1.:i: . .iLs.1co�·�i; r ort S�ou1 .ty (Uetailed) • Lab 4-1


Part 1: Troubleshooting Port Security

Step 1.1

Step 1.2


equipment. You will troubleshoot and resolve problems with port security features.

Note






assigned device.












Hostname: I x.x.x.x

Port: 123 Firewall:


I None

� Save session

� Open in a tab

vi


Lab 4-2 • Troubleshooting Port Security (Detailed) www.juniper.net


Step 1.3




exB-1 (ttypO)

login: lab

Password:


{master:O}



{master:O} [edit]


load complete

{master:O} [edit]



commit complete


{master:0}

lab@exB-1>

Step 1.4



your instructor.

www.juniper.net

Quick Connect �'


Hostname: !x.x.x.x

Port: 123 Firewall: !None vi

O Show quick connect on startup � Save session

� Open in a tab


----� -- -------------- --Troubleshooting Port Security (Detailed) • Lab 4-3


Step 1.5

srxB-1 (ttyuO)

login: lab

Password:




--- JUNOS 12.1R5.5 built 2013-01-17 06:12:00 UTC



[edit]


load complete

[edit]


commit complete


lab@srxB-1>

Step 1.6

Note

The next steps apply only to the group that

manages the srxx-2 SRX Series device,

which is hosting the multicast source as a

virtual routing instance.

From the srxJ"-2 device, use the ping and traceroute utilities to determine IP unicast

reachability to the multicast receiver device from the source routing instance. Limit

the number of ping attempts to 2 because we only want to verify reachability.

lab@srxB-2> ping address routing-instance instance count 2

PING 10.1.1.2 (10.1.1.2): 56 data bytes



lab@srxB-2>

lab@srxB-2> traceroute address routing-instance instance


1 * * *

"C

lab@srxB-2>

6m ---------------- ----- ---- ______ ¥;:7 _____ --

Lab 4-4 • Troubleshooting Port Security (Detailed) �

www.juniper.net

Step 1.7

{master:0}


Question: What could cause this lack of connectivity

in the network?

Answer: There could be many reasons for this, but

in relation to this lab it could be authentication

issues, port security related issues, firewall filters,

etc.

Note

The rest of the lab you will be moving

between the devices to effectively

troubleshoot the issues. Please make sure

you are on the correct devices as you move

through the steps.

Because the source routing instance is connected to the exK-2 switch you should

start your troubleshooting by looking at the authentication and access control

settings on the exK-2 EX Series switch.

From the exK-2, use the show dotlx interface ge-0/0/6 and show captive-portal interface ge-0/0/6 command to determine if 802.1x

could be causing the lack of connectivity from the source routing instance.

lab@exB-2> show dotlx interface ge-0/0/6

warning: dotlx-protocol subsystem not running - not needed by configuration.

{master:0}

lab@exB-2> show captive-portal interface ge-0/0/6


{master:O}

lab@exB-2>

www.juniper.net

Question: Do you see any information about dot1x

or captive portal?

Answer: No, you should note that the 802.1x

sub-system is not running so these could not be

causing the lack of reachability.

Troubleshooting Port Security (Detailed) • Lab 4-5


Step 1.8

Use the show dhcp snooping binding to determine if there are any bindings

present. You should also use the show arp inspection statistics and

show ip-source-guard commands to determine if there are any issues.

{master:0}

lab@exB-2> show dhcp snooping binding

DHCP Snooping Information:

MAC address IP address Lease (seconds) Type

00:26:88:02:6B:86 172.16.4.3 static

{master:O}

lab@exB-2> show arp inspection statistics

VLAN

vlll

Interface

ge-0/0/6.0

Interface Packets received ARP inspection pass ARP inspection failed

ge-0/0/0 0

ge-0/0/1 0

ge-0/0/2 0

ge-0/0/3 0

ge-0/0/4 0

ge-0/0/5 0

ge-0/0/6 0

ge-0/0/7 0

ge-0/0/8 0

ge-0/0/9 0

ge-0/0/10 0

ge-0/0/11 0

ge-0/0/12 0

ge-0/0/13 0

ge-0/0/14 0

ge-0/0/15 0

ge-0/0/16 0

ge-0/0/17 0

ge-0/0/18 0

ge-0/0/19 0

ge-0/0/20 0

ge-0/0/21 0

ge-0/0/22 0

ge-0/0/23 0

{master:O}

lab@exB-2> show ip-source-guard

IP source guard information:

Interface Tag IP Address

ge-0/0/6.0 0 172.16.4.3

{master:0}

lab@exB-2>

Lab 4-6 • Troubleshooting Port Security (Detailed)

MAC Address

00:26:88:02:68:86

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

VLAN

vlll

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

www.juniper.net

Step 1.9


Question: What could cause the port security

features detected to deny our packets on this

EX Series switch?

Answer: There is a static DHCP snooping entry that

can be used by DAI and ip-source-guard. The DAI

statistics are O under the failed column for our

interfaces so that does not seem to be a problem.

The ip-source-guard entry could be an issue if it

does not match with our mac-address and/or

IP address.

Return to the open session to the srxK-2 device.

From srxK-2, use the monitor traffic interface ge-0/0/6

layer2-headers no-resolve size 1500 command to monitor traffic

leaving the Source routing instance. You might need to monitor for a few minute to

see ARP traffic.

lab@srxB-2> monitor traffic interface ge-0/0/6 layer2-headers no-resolve size

1500

verbose output suppressed, use <detail> or <extensive> for full protocol decode

Address resolution is OFF.

Listening on ge-0/0/6, capture size 1500 bytes

07:34:31.250793 In 00:19:e2:55:31:81 > 00:26:88:02:6b:86, ethertype ARP


07:34:31.250877 Out 00:26:88:02:6b:86 > 00:19:e2:55:31:81, ethertype ARP

(Ox0806), length 42: arp reply 172.16.4.2 is-at 00:26:88:02:6b:86

07:35:10.805348 In PFE proto 2 (ipv4): 172.16.4.1 > 224.0.0.1: igmp query v2

"C

3 packets received by filter

O packets dropped by kernel

lab@srxB-2>

www.juniper.net

Question: Does the traffic leaving the source routing

instance seem correct based on the information on

the network diagram?

Answer: No, you should notice that the source

IP address of the traffic is incorrect. Traffic is being

sourced from 172.16.4.2 instead of 172.16.4.3.



Step 1.10

Question: What could cause this wrong source

IP address to be used on the traffic from the source

routing instance?

Answer: It could be that the wrong IP address is

configured or that there are multiple addresses

from the same subnet configured, maybe as a

result of trying to fix an initial mistake. As you might

know, the Junos OS allows multiple address on a

logical unit. When you add a second address to a

unit it doesn't overwrite the old one but it just adds

the new address.

From srxJ"-2, use the show interfaces ge-0/0/6 terse command to review

the IP addresses being applied to the source routing instance interface.

lab@srxB-2> show interfaces ge-0/0/6 terse

Interface Ad.min Link Proto

ge-0/0/6 up up

ge-0/0/6.0 up up inet

Step 1.11

Local

172.16.4.2/24

172.16.4.3/24

Remote

Now that you know there are two addresses configured on the source routing

instance interface you can source the ping and traceroute traffic from the IP address

expected by the ip-source-guard feature.

From srxJ"-2, try to ping the receiver again but this time use the source

172 .16. 4. 3 criteria instead of the default 172.16.4.2 address. Limit the number

of pings to 2 since we just want to verify reachability.

lab@srxB-2> ping address routing instance instance source 172.16.4.3 count 2

PING 10.1.1.2 (10.1.1.2): 56 data bytes



Question: Do your pings complete?

Answer: No, the ping does not complete.


Step 1.12


Question: What is the next step?

Answer: There are a few things you can try, but you

should start with a traceroute to the same address

using the source option to determine how far

through the path you can reach.

From srx_K-2, try to traceroute to the receiver and use the source 172 .16. 4. 3

criteria instead of the default 172.16.4.2 address.

lab@srxB-2> traceroute address routing-instance instance source 172.16.4.3

traceroute to 10.1.1.2 (10.1.1.2) from 172.16.4.3, 30 hops max, 40 byte packets

1 172 . 1 6 . 4 . 1 ( 172 . 1 6 . 4 . 1 ) 4 . 4 4 8 ms 2 . 0 7 5 ms 2 . 0 0 6 ms

2 172 . 1 6 . 3 . 1 ( 172 . 1 6 . 3 . 1 ) 15 . 5 0 8 ms 4 . 6 4 0 ms 7 . 6 2 3 ms

3 172 . 1 6 . 2 . 1 ( 172 . 1 6 . 2 . 1 ) 2 . 116 ms 2 . 3 9 5 ms 1 . 9 2 9 ms

4 * * *

"C

lab@srxB-2>

Step 1.13

{master:O}

Question: What can you determine from the

traceroute results?

Answer: The traceroute test with the correct source

address shows that there is a still a problem

reaching the receiver address of 10.1.1.2. The

problem seems to be on the last hop between the

srx_K-1 and the receiver. The ex_K-1 is acting as a

Layer 2 switch between these two devices and

could therefore be part of the problem.

Return to the open session to the ex_K-1 device.

From ex_K-1, use the show dotlx interface and show captive-portal

interface command to determine if 802.1x could be causing the lack of

connectivity from the source routing instance to the receiver.

lab@exB-1> show dotlx interface


{master:O}

lab@exB-1> show captive-portal interface


www.juniper.net Troubleshooting Port Security (Detailed) • Lab 4-9


{master:O}

lab@exB-1>

Step 1.14

{master:0}

Question: Do you see any information about dot1x

or captive portal?

Answer: No, you should note that the 802.1x

sub-system is not running so these could not be

causing the lack of reachability.

From ex_K-1, use the show dhcp snooping binding to determine if there are

any bindings present. You should also use the show arp inspection

statistics and show ip-source-guard commands to determine if there

are any issues.

lab@exB-1> show dhcp snooping binding

DHCP Snooping Information:

MAC address IP address Lease (seconds) Type

OO:OC:29:B5:89:7C 10.1.1.2 static

{master:O}

lab@exB-1> show arp inspection statistics

VLAN Interface vll ge-0/0/14.0

Interface Packets received ARP inspection pass ARP inspection failed

ge-0/0/0 0 0 0

ge-0/0/1 0 0 0

ge-0/0/2 0 0 0

ge-0/0/3 0 0 0

ge-0/0/4 0 0 0

ge-0/0/5 0 0 0

ge-0/0/6 0 0 0

ge-0/0/7 0 0 0

ge-0/0/8 181 181 0

ge-0/0/9 0 0 0

ge-0/0/10 0 0 0

ge-0/0/11 0 0 0

ge-0/0/12 0 0 0

ge-0/0/13 0 0 0

ge-0/0/14 2788 66 2722

ge-0/0/15 0 0 0

ge-0/0/16 0 0 0

ge-0/0/17 0 0 0 ge-0/0/18 0 0 0

ge-0/0/19 0 0 0

ge-0/0/20 0 0 0

ge-0/0/21 0 0 0

ge-0/0/22 0 0 0

ge-0/0/23 0 0 0

{master:O}



lab@exB-1> show ip-source-guard


Step 1.15

{master:0}

Question: Do you see anything that might indicate a

direction to follow?

Answer: Yes, you should notice that there are many

arp inspection failures on the ge-0/0/14 interface.

This interface connects exx-1 to the receiver device.

From ex_K-1, use the show log messages I match arp command to review

the syslog file and determine if there are any messages that might help you

understand the problem.

lab@exB-1> show log messages I match arp

Feb 8 14:31:45 exB-1 eswd[1280]: ESWD_DAI FAILED: 3 ARP_REQUEST received, interface ge-0/0/14.0[index 73), vlan vll[index 5), sender ip/mac 10.1.1.2/ OO:Oc:29:b5:89:7d, receiver ip/mac 10.1.1.1/00:00:00:00:00:00

Feb 8 14:34:05 exB-1 eswd[1280]: ESWD_DAI_FAILED: 3 ARP_REQUEST received, interface ge-0/0/14.0[index 73), vlan vll[index 5), sender ip/mac 10.1.1.2/ OO:Oc:29:b5:89:7d, receiver ip/mac 10.1.1.1/00:00:00:00:00:00






---(more)---

www.juniper.net Troubleshooting Port Security (Detailed) • Lab 4-11


Step 1.16

Question: What does the output indicate is the

issue with our traffic on the exx-1 switch?

Answer: The static DHCP snooping binding has a

different mac-address than our actual traffic. This is

the return traffic from the receiver side. Remember

connectivity is mostly a 2-way street, in this case

the traffic from the receiver is rejected thereby

preventing our traceroute from completing its full

path.

From exJ"-1, enter configuration mode and navigate to the [edit

ethernet-swi tching-options secure-access-port] hierarchy and

replace the existing (incorrect) MAC with the mac address of the receiver interface.

You can get this correct address from the syslog messages output.

{master:O}



{master:O} [edit]

lab@exB-1# edit ethernet-switching-options secure-access-port

{master:O} [edit ethernet-switching-options secure-access-port]

lab@exB-1# show

interface ge-0/0/8.0

dhcp-trusted;

interface ge-0/0/14.0

static-ip 10.1.1.2 vlan vll mac OO:Oc:29:b5:89:7c;

no-dhcp-trusted;

vlan vll {

arp-inspection;

{master:O} [edit ethernet-switching-options secure-access-port]

lab@exB-1# replace pattern old-MAC with new-MAC

{master:0} [edit ethernet-switching-options secure-access-port]



commit complete


{master:O}

lab@exB-1>


Step 1.17


Return to the open session to the srx_K-2 device.

From srx_K-2, try to ping the receiver again remember to use the source

1 72. 16. 4. 3 criteria instead of the default 172.16.4.2 address. Limit the number

of pings to 2 because we only want to verify reachability.


PING 10.1.1.2 (10.1.1.2): 56 data bytes 64 bytes from 10.1.1.2: icmp_seq=O ttl=61 time= l.951 ms 64 bytes from 10.1.1.2: icmp_seq=l ttl=61 time= l.560 ms


lab@srxB-2>

Step 1.18

{master:O} lab@exB-1> exit

exB-1 (ttyuO)

login:

Step 1.19

Question: Are your ping attempts successful?

Answer: Yes, you should now have reachability

between the source device and the receiver.

From ex_K-1, log out.

Return to the open session to srx_K-1.

From srx_K-1, log out.

lab@srxB-1> exit

srxB-1 (ttyuO)

login:

Step 1.20

www.juniper.net


From srx_K-1, log out.



lab@srxB-2> exit

srxB-2 (ttyuO)

login:

Return to the open session to exJ"-2.

From exK-1, log out.

lab@exB-2> exit

exB-2 (ttyuO)

login:



Server

srxA-1

srxA-2

srxB-1

srxB-2

srxC-1

srxC-2

�

-�

E • e Workstations


/_ srxD-1 /_

/_ srxD-2 /_

/_ vr-device /_

/_ Server

/_ Gatev.ey

/_ Term Server


©2013 Juniper Netwod<S, Inc All niht, reser;ed JUnID Worldwide Education Services WWW JU nip er net



Pod A Network Diagram:


loO.O: 172.17.1.1 loO.O: 172.17.1.2

.1 ge-Q/0/1 .2

srxA-1 srxA-2 172.16.2.0/24

.1 .1

� C)

� «)

� <'i q\ OSPF

. 2

exA-2 loO.O: 172.17.1.3

.1

172.16.4.0/24

Receiver Source


Pod B Network Diagram:


loO.O: 172.17.1.1

.1

srxB-1

.1

I 1\ 0

...../ exB-1 ...;

----� VLAN:v1

/ / ,.0/0/14

/

r----===::---1'. 2

Receiver

ge-Q/0/1

172.16.2.0/24

OSPF

loO.O: 172.17.1.2

.2

srxB-2

.1

� C)

� «) ...... <'i

......

.2

exB-2 loO.O: 172.17.1.3

.1

172.16.4.0/24

Source

©2013 Juniper Networks, Inc All nthts teseived. JUn!Per Worldwide Education Services lf\lVWW Juniper net

www.juniper.net

--�----------- ---------Troubleshooting Port Security (Detailed) • Lab 4-15


Pod C Network Diagram:


loO.O: 172.17.1.1 loO.O: 172.17.1.2

.1 ge-0/0/1 .2

srxC-1 srxC-2 1721620/24

.1 .1

� � C)

� M 0 ......

g,. ......

n\ OSPF

0

$ .2

exC-1 ;j ...._ __ ......., �

exC-2 loO.O: 172.17.1.3

.1

172.16.4.0/24

Receiver Source

©2013 Juniper Networks, Inc All nth ts reserved JUnLPgf V\/orldwide Education Services WWW Juniper net

Pod D Network Diagram:


loO.O: 172.17.1.1

.1 srxD-1

.1

l ;\ 0

$ exD-1 ..;

---- � VLAN:v1/ /

o,Oft)/14 /

r---====---i.2

Receiver

loO.O: 17 2.17 .1.2

ge-0/0/1 .2

srxD-2 17216.2.0/24

.1

� � C)

� M 0 ......

OSPF

.2

exD-2 loO.O 172.17.1.3

.1

172.16.4.0/24

Source

©2013 Juniper Netwotl(S, Inc All nth ts reserwed JUn� Worldwide Education Services WWW Juniper net


Overview

Lab

Troubleshooting Advanced Features (Detailed)

In this lab, you will troubleshoot multicast issues, as well as correct any detected

problems. You will need to work together with your partner pod to troubleshoot these

issues.

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

• Troubleshoot multicast control and forwarding issues.

---;:-:-:::-;--;-c:;-;-, ==---=-=-;-;;�;--:-;-;-;-:-;--:;=:----;-;=:-�·- --- --- -------------

www.juniper.net � irvul't:.�n1.c�t.11!::li'1t.'.'Jl.::cll !;ea':u �s (Uetailed) • Lab 5-1


Part 1: Troubleshooting Multicast

Step 1.1

Step 1.2


equipment. You will troubleshoot and resolve problems with multicast.

Note






assigned device.












Hostname: I x.x.x.x

Port: 123 Firewall:


I None

� Save session

� Open in a tab

vi


- - - - - - - - - - - - - - - - - - - -- - -- - - -c; - - - - _,..... - - - - - - -

Lab 5-2 • Troubleshooting Advanced Features (Detailed) � www.juniper.net


Step 1.3




exB-1 (ttypO)

login: lab

Password:


{master:O}



{master:O} [edit]


load complete

{master:O} [edit]



commit complete


{master:0}

lab@exB-1>

Step 1.4



your instructor.

www.juniper.net

Quick Connect �'


Hostname: !x.x.x.x

Port: 123 Firewall: !None vi


� Open in a tab


Troubleshooting Advanced Features (Detailed) • Lab 5-3


Step 1.5

srxB-1 (ttyuO)

login: lab Password:




--- JUNOS 12.1R5.5 built 2013-01-17 06:12:00 UTC

lab@srxB-1> configure Entering configuration mode

[edit] lab@srxB-1# load override ajext/lab5-start.config

load complete

[edit] lab@srxB-1# commit and-quit commit complete Exiting configuration mode

lab@srxB-1>

Step 1.6

Before we start troubleshooting multicast issues, you should verify that basic

unicast connectivity is working between the receiver and the source. Throughout this

lab you will be working as a pod group to troubleshoot multicast issues. You can choose to each manage your specific devices or you can open all session on a single

workstation and work together.

Note

The next step only applies to the group that

manages the srxK-2 SRX Series device,

which is hosting the multicast source as a

virtual routing instance.

From srxK-2, try to ping the receiver use the source 172 .16. 4. 3 criteria. Limit

the number of pings to 2 because we want only to verify reachability.


PING 10.1.1.2 (10.1.1.2): 56 data bytes 64 bytes from 10.1.1.2: icmp_seq=O ttl=61 time= l.951 ms 64 bytes from 10.1.1.2: icmp seq= l ttl=61 time= l.560 ms


lab@srxB-2>


Step 1.7


Question: Are your ping attempts successful?

Answer: Yes, you should now have reachability

between the source device and the receiver.

Note

The next few step only apply to the group

that manages the srx_K-1 SRX Series

device, which is connected to the multicast

receiver.

Now that you have established unicast reachability between the source and receiver

you should start a multicast steam and determine if multicast traffic can traverse

your network.

Return to the open session to the srx_K-1 device.

From srx_K-1, use the ssh 1ab@10 .1.1. 2 command with the password lab123

to log into the receiver.

lab@srxB-1> ssh [email protected]

[email protected]'s password:

Last login: Sun Apr 21 04:35:02 2013 from 10.1.1.1

[lab@CoSl -]$

Step 1.8

[lab@CoSl -]$ [1] 2764

[lab@CoSl -]$logout

Connection to

lab@srxB-1>

Step 1.9

From the receiver, use the . /rtpqual 224. 7. 7 .123 1111 rtp& command to

configure your receiver to generate IGMP reports for the group 224. 7. 7.123. Once

you have issued the command, log out of the receiver using the exit command .

. /rtpqual 224.7.7.123 1111 rtp&

exit

10.1.1.2 closed.

Now that the we have a receiver in our network we can verify if the IGMP report

resulted in PIM setting up the path to the RP.

From srx_K-1, use the show igmp interface ge-0/0/8 and show igmp

group I find ge-0/0/8 commands to determine if the receiver is generating

IGMP messages into your network.

lab@srxB-1> show igmp interface ge-0/0/8

Interface: ge-0/0/8.0

www.juniper.net Troubleshooting Advanced Features (Detailed) • Lab 5-5


Querier: 10.1.1.1

State: Up Timeout:

Immediate leave: Off

Promiscuous mode: Off

Passive: Off

None Version: 2 Groups:

lab@srxB-1> show igmp group I find ge-0/0/8

Interface: ge-0/0/8.0, Groups: 2

Group: 224.0.0.251

Source: 0.0.0.0

Last reported by: 10.1.1.2

Timeout: 199 Type: Dynamic

Group: 224.7.7.123

Source: 0.0.0.0



Interface: ge-0/0/1.0, Groups: 5

Group: 224.0.0.2

Source: 0.0.0.0



Group: 224.0.0.5

Source: 0.0.0.0



Group: 224.0.0.6

Source: 0.0.0.0



Group: 224.0.0.13

Source: 0.0.0.0



Group: 224.0.0.22

Source: 0.0.0.0



Interface: local, Groups: 5

Group: 224.0.0.2

Source: 0.0.0.0

Last reported by: Local


Group: 224.0.0.5

Source: 0.0.0.0



Group: 224.0.0.6

Source: 0.0.0.0



Group: 224.0.0.13

Source: 0.0.0.0



Group: 22�.0.0.22

2

- - - - - - - - - - - - - - - - - - - -- - -- - - -c; - - - - _,..... - - - - - - -



Source: 0.0.0.0



Step 1.10

Question: Is the receiver generating IGMP

messages towards your srxK-1 device?

Answer: Yes, you should see an IGMP group of

224.7.7.123 at interface ge-0/0/8 on your srxK-1

device.

From srxx-1, use the show pim rps and show pim join commands to

determine if they RP is reachable from srxK-1.

lab@srxB-1> show pim rps

Instance: PIM.master

Address family INET

RP address Type

172.17.1.2 static

Address family INET6

Mode Holdtime Timeout Groups Group prefixes

sparse O None 1 224.0.0.0/4

lab@srxB-1> show pim join

Instance: PIM.master Family: INET

R = Rendezvous Point Tree, S = Sparse, W Wildcard

Group: 224.7.7.123

Source: *

RP: 172.17.1.2

Flags: sparse,rptree,wildcard

Upstream interface: unknown (no route)

Instance: PIM.master Family: INET6

R = Rendezvous Point Tree, S = Sparse, W = Wildcard

www.juniper.net

Question: Do you have a known RP?

Answer: Yes, you should notice that the RP has

been statically configured.



Question: What is your upstream interface used to

connect to the RP?

Answer: At this point it is showing unknown. This

means that we do not have a route to the RP from

this device. This could be due to a wrong static

entry or because of a routing problem, for example

route not being advertised in IGP. The static entry

matches the topology so you should investigate a

routing issue.

Step 1.11

From srxK-1, use the show route 172 .17 .1. 2 command to determine if you

have a route to the RP.

lab@srxB-1> show route 172.17.1.2

lab@srxB-1>

Question: Do you have a route?

Answer: No, you do not have a route to that

destination. Review the OSPF database to see if this

address is being sent.

Step 1.12

From srxK-1, use the show ospf database advertising-router

1 72. 1 7. 1. 2 command to review the OSPF database entries from this neighbor.

Include the detail option if you need additional information.

lab@srxB-1> show ospf database advertising-router 172.17.1.2

OSPF database, Area 0.0.0.0

Type ID Adv Rtr

Router 172.17.1.2 172.17.1.2

Seq

Ox80000016

Age Opt Cksum Len

232 Ox22 Ox7514 48

lab@srxB-1> show ospf database advertising-router 172.17.1.2 detail

OSPF database, Area 0.0.0.0

Type ID Adv Rtr

Router 172.17.1.2 172.17.1.2

bits OxO, link count 2

Seq

Ox80000016

id 172.16.2.1, data 172.16.2.2, Type Transit (2)

Topology count: 0, Default metric: 1

id 172.16.3.2, data 172.16.3.1, Type Transit (2)

Topology count: 0, Default metric: 1

Topology deJ�t�t (�� )

Age Opt Cksum Len

235 Ox22 Ox7514 48



Type: Transit, Node ID: 172.16.3.2

Metric: 1, Bidirectional

Type: Transit, Node ID: 172.16.2.1

Metric: 1, Bidirectional

Step 1.13

Question: Is the 172.17.1.2 (srxK-2) neighbor

sending you their loopback address?

Answer: No, as shown in the detailed output you are

only receiving the networks for the directly

connected interfaces, but there is no loopback

address?


From srxK-2, use the show interfaces loO. 0 terse command to verify the

IP address assigned to the loopback interface.

lab@srxB-2> show interfaces loO.O terse

Interface Admin Link Proto Local

172.17.1.2 loO. 0 up up inet

Step 1.14

Question: What address is configured for lo0.0?

Answer: The loopback interface has to correct

172.17.1.2 address applied.

Note

The next few steps only apply to the group

that manages the srxK-2 SRX Series device

which is connected to the multicast

receiver.

Remote

--> 0/0

From srxK-2, use the show ospf interfaces command to determine if the

loopback interface is configured for OSPF.

lab@srxB-2> show

Interface

ge-0/0/1.0

ge-0/0/8.0

www.juniper.net

ospf interface

State Area

BDR 0.0.0.0

BDR 0.0.0.0

DR ID

172.17.1.1

172.17.1.3

BDR ID

172.17.1.2

172.17.1.2

Nbrs

1

1



Step 1.15

Question: Do you see the loopback interface

participating as an OSPF interface?

Answer: No, The interface is not participating in

OSPF. This explains why srxJ'-2 is not advertising

the loopback route.

From srxJ'-2, enter configuration mode and add the loopback interface to the

current OSPF area configuration. Commit and exit to operational mode when you are

finished.



[edit]

lab@srxB-2# show protocols ospf

area 0.0.0.0 {

interface ge-0/0/1.0;

interface ge-0/0/8.0;

[edit]

lab@srxB-2# set protocols ospf area O interface loO.O

[edit]


commit complete


lab@srxB-2>

Step 1.16

lab@srxB-2>

From srxK-2, use the show ospf interfaces command to determine if the

loopback interface is now showing as configured for OSPF.

show ospf interface

Interface State Area DR ID BDR ID Nbrs

ge-0/0/1. 0 BDR

ge-0/0/8.0 BDR

loO.O DR

0.0.0.0 172.17.1.1 172.17.1.2

0.0.0.0 172.17.1.3 172.17.1.2

0. 0. 0. 0 172.17.1.2 0.0.0.0

Question: Do you see the loopback interface

participating as an OSPF interface now?

Answer: Yes, you should see the loopback interface

now.

Lab 5-10 • Troubleshooting Advanced Features (Detailed) www.juniper.net

1

1

0

Step 1.17


Note

The rest of the lab you will be moving

between the devices to effectively

troubleshoot the issues. Please make sure

you are on the correct devices as you move

through the steps.


From srxK-1, use the show pim join detail command to determine if they RP

is reachable from srxK-1 now that you have a route to the RP.

lab@srxB-1> show pim join detail


R = Rendezvous Point Tree, S = Sparse, W Wildcard

Group: 224.7.7.123

Source: *

RP: 172.17.1.2


Upstream interface: ge-0/0/1.0

Downstream neighbors:



R = Rendezvous Point Tree, S = Sparse, W = Wildcard

Step 1.18

Question: Do you now have a upstream interface to

the RP?

Answer: Yes, you should see that the ge-0/0/1

interface is the interface used to reach the RP.

Question: What does the Downstream

neighbors interface show you?

Answer: This section shows you what interface is

used to reach the receiver.


From srxK-2, use the show pim join detail command to show PIM details

from t'1e perspective of the RP --------------------- ______ _, ___ --�----------- ---------





R = Rendezvous Point Tree, S = Sparse, W

Group: 224.7.7.123

Source: *

RP: 172.17.1.2


Upstream interface: Local





lab@srxB-2>

Wildcard

Wildcard

Question: Do you have a downstream interface to

the receiver?

Step 1.19

Answer: Yes, you should notice that the ge-0/0/1

interface is selected as the downstream interface.

Now that the receiver to RP control path is working correctly you should focus on the

RP to the source.

From srx_K-2, generate source traffic from the source routing instance to the reciever

multicast group address using the ping address bypass-routing

interface ge-0/0/6 ttl 10 routing-instance instance source

172 .16. 4. 3 command.

lab@srxB-2> ping address bypass-routing interface ge-0/0/6 ttl 10

routing-instance instance source 172.16.4.3

PING 224.7.7.123 (224.7.7.123): 56 data bytes

Step 1.20

Question: What do you do next?

Answer: Leave the pings running and open a second

session to srxK-2 to verify the forwarding path while

traffic is flowing.

Open a second command-line interface (CLI) session to srxK-2 from your station

using either the console, Telnet, or SSH as directed by your instructor.



Quick Connect �'

Protocol: I Telnet vi Hostname: I x.x.x.x

Port: LI Firewall: I None vi


� Open in a tab

i Connect W, i Cancel

Step 1.21

Log in as user lab with the password labl23. Use the show pim join detail

command to verify the control path.

srxB-1 (ttyuO)

login: lab

Password:

--- JUNOS 12.lRS.5 built 2013-01-17 06:12:00 UTC




Group: 224.7.7.123

Source: *

RP : 1 72 . 1 7 . 1 . 2


Upstream interface: Local



Group: 224.7.7.123

Source: 172.16.4.3

Flags: sparse,spt

Upstream interface: ge-0/0/8.0





www.juniper.net

Wildcard

Wildcard

--�----------- ---------



Step 1.22

Question: What has changed in the output since

you started to sending multicast traffic?

Answer: Before the traffic, the Pl M joins were for the

shared tree through the RP, now with the source

announcing it self the output includes the shortest

path tree (spt).

Question: What does the inclusion of the SPT

indicate?

Answer: This means that the multicast control plane

is working and the problem with the ping traffic

must be a forwarding issue.

Now that the control path is working as expected you should focus on the forwarding

path for the multicast traffic. You will need to verify the multicast route at each

device in the path until a problem reveals itself. You should start with exK-2 because

it is closet to the source of the traffic.

Return to the open session to exK-2.

From exK-2, use the show route forwarding-table destination

224. 7. 7 .123 extensive command to determine if you have a route to the

multicast receiver group address.

{master:0}

lab@exB-2> show route forwarding-table destination 224.7.7.123 extensive

Routing table: default.inet [Index OJ

Internet:

Destination: 224.0.0.0/4

Route type: user

Route reference: 0

Flags: cached, accounting,

Next-hop type: resolve

Route interface-index: 0

sent to PFE


Route type: permanent

Route reference: 0

Flags: none

Next-hop type: multicast discard

Destination: 224.7.7.123.172.16.4.3/64

Route type: user

Index: 1329 Reference: 1



Route reference: 0 Route interface-index: 72



Flags: cached, check incoming interface , accounting, sent to PFE, rt nh

decoupled

Next-hop type: indirect

Nexthop:


Next-hop type: composite

Next-hop type: unicast

Next-hop interface: ge-0/0/8.0

Index: 1356

Index: 131072

Reference: 1

Reference: 3

Alternate forward nh index: 131074

Routing table: master.anon .inet [Index 3]

Internet:



Route reference: 0

Flags: sent to PFE


Next-hop type: multicast discard Index: 1292 Reference: 1

{master:O}

lab@exB-2>

Step 1.23

Question: Do you have a route to the multicast

group address?

Answer: Yes, you should have a route to the

receiver's multicast group address.

Question: Do you see the correct Next-hop

interface?

Answer: Yes you should see that ge-0/0/8 is the

interface used to reach the next hop.

Return to the open troubleshooting session to srx_K-2.

From srx_K-2, use the show route forwarding-table destination



lab@srxB-2> show route forwarding-table destination 224.7.7.123 extensive

Routing table: default.inet [Index OJ

Internet:


Route type: user


Flags: cact:':rl, ��c0unti_r-_':", se'1': "'::.'"> f<:: ----- ---------------- --------- _________ ,..... _____ ---------






Route reference: 0

Flags: none


Destination: 224.7.7.123.172.16.4.3/64

Route type: user

Route reference: 0






decoupled


Nexthop:

Next-hop

Next-hop

Next-hop

type: composite

type: unicast

interface: ge-0/0/1.0

Index: 262143

Index: 577

Index: 262142

Reference: 2

Reference: 1

Reference: 2


Internet:



Route reference: 0

Flags: sent to PFE


Routing table: vr12b.inet [Index 21]

Internet:



Route reference: 0

Flags: sent to PFE


Routing table: vrlll.inet [Index 22]

Internet:



Route reference: 0

Flags: sent to PFE









group address?






interface?



Step 1.24

Return to the open session to srxK-1.

From srxK-1, use the show route forwarding-table destination



lab@srxB-1> show route forwarding-table destination 224.7.7.123 extensive

Routing table: default.inet [Index 0]

Internet:


Route type: user

Route reference: 0

Flags: cached, accounting,



sent to PFE



Route reference: 0

Flags: none


Destination: 224.7.7.123.172.16.4.3/64

Route type: user






decoupled


Nexthop:




Alternate forward nh index: 262144

Index: 262143

Index: 628

Index: 262142

Reference: 2

Reference: 1

Reference: 3


Internet:



Route reference: 0

Flags: sent to PFE


Routing table: vrll.inet [Index 4)

www.juniper.net



--�----------- ---------



Internet:

Destination: 224.0.0.0/4 Route type: permanent Route reference: 0 Flags: sent to PFE



Routing table: vr12.inet [Index 5] Internet:

Destination: 224.0.0.0/4 Route type: permanent Route reference: 0 Flags: sent to PFE



Step 1.25


group address?




interface?



Return to the open session to ex_K-1.

From exK-1, use the show route forwarding-table destination



{master:0} lab@exB-1> show route forwarding-table destination 224.7.7.123 extensive

Routing table: default.inet [Index OJ Internet:

Destination: 224.0.0.0/4 Route type: permanent Route reference: 0 Flags: sent to PFE Next-hop type: multicast discard

Routing table m::: s"':� · arcn

Lab 5-18 • Troubleshooting Advanced Features (Detailed)



www.juniper.net


Internet:



Route reference: 0

Flags: sent to PFE



Routing table: juniper services .inet [Index 5]

Internet:



Route reference: 0

Flags: sent to PFE



Step 1.26


group address?

Answer: No, you should not have a route to the


From exK-1, use the show route forwarding-table family

ethernet-swi tching command to review the switching table entries.

{master:0}

lab@exB-1> show route forwarding-table family ethernet-switching

Routing table: default.ethernet-switching

ETHERNET-SWITCHING:

Destination Type RtRef Next hop Type Index NhRef Net if

default perm 0 dscd 66 1

3, * intf 0 rslv 1283 1

4, * user 0 comp 1359 2

4, * intf 0 rslv 1286 1

4, OO:Oc:29:b5:89:7d user 0 ucst 1282 3 ge-0/0/14.0

4, 00:26:88:ff:be:08 user 0 ucst 1284 3 ge-0/0/8.0

5, * intf 0 rslv 1287 1

6, * intf 0 rslv 1312 1

7, * intf 0 rslv 1313 1

9, * intf 0 rslv 1353 1

10, * intf 0 rslv 1354 1



Question: Any idea what is the cause of the missing

224.7.7.123 entry on exK-1?

Answer: On Layer 2 switches there could be the

need for IGMP snooping. If this is not correctly

configured it explains the missing forwarding entry.

Step 1.27

From exK-1, use the show igmp-snooping ? command to determine what

operational mode options you can review. Then systematically go through these

options to see if you can determine if IGMP snooping is working correctly.

{master:0}

lab@exB-1> show igmp-snooping?

Possible completions:

flows Show igmp-snooping flows

membership

route

statistics

task

vlans

{master:0}

Show igmp-snooping membership

Show routing information

Show igmp-snooping statistics

Show IGMP snooping task information

VLAN information

lab@exB-1> show igmp-snooping flows

{master:O}

lab@exB-1> show igmp-snooping membership

{master:0}

lab@exB-1> show igmp-snooping route

{master:0}

lab@exB-1> show igmp-snooping statistics

Bad length: 0 Bad checksum: 0 Invalid interface: 0

Not local: 0 Receive unknown: 0 Timed out: 0

IGMP Type Received Transmited Recv Errors

Queries: 0

Reports: 0

Leaves: 0

Other: 0

{master:O}

lab@exB-1> show igmp-snooping task

Pri Task Name

0 KRT

0 next-hop

0 ESW Interfaces

0 DB manager

15 Memory

35 MLD

0 0

0 0

0 0

0 0

Pro Port So Flags

7 <WriteDisable>

58 9 <WriteDisable>


35 IGMP 40 krt inet 40 me inet 40 me bridge 40 ESP CLIENT:33001.128.0.0.1 70 MGMT.local

70 MGMT Listen./var/run/mcsnoopd_mgmt

{master:0} lab@exB-1> show igmp-snooping vlans


2


8 <WriteDisable>

33001 6 <WriteDisable> 11 <WriteDisable> 10 <Accept WriteDisable>

Question: Can you see anything that might indicate

a problem?

Step 1.28

{master:0}

Answer: Yes, the lack of any real details about IGMP

snooping indicates that the IGMP snooping has not

been enabled. You should enable IGMP snooping

for the correct VLAN.

From ex_K-1, enter configuration mode and navigate to the [edit protocols

igmp-snooping] hierarchy. Add the vll VLAN to IGMP snooping. Commit and

exit to operational mode when you are finished.

lab@exB-1> configure Entering configuration mode

{master:0} [edit) lab@exB-1# edit protocols igmp-snooping

{master:0} [edit protocols igmp-snooping) lab@exB-1# set vlan vll

{master:O} [edit protocols igmp-snooping) lab@exB-1# commit and-quit configuration check succeeds commit complete Exiting configuration mode


Step 1.29

From ex_K-1, use the show igmp-snooping ? command to determine what

operational mode options you can review. Then systematically go through these

options to see if you can determine if IGMP snooping is working correctly.



{master:O} lab@exB-1> show igmp-snooping?

Possible completions: flows Show igmp-snooping flows

Show igmp-snooping membership Show routing information

Show igmp-snooping statistics

membership route

statistics task vlans

Show IGMP snooping task information VLAN information

{master:O} lab@exB-1> show igmp-snooping flows

VLAN: vll

{master:O} lab@exB-1> show igmp-snooping membership

VLAN: vll 224.7.7.123 *

Interfaces: ge-0/0/14.0

{master:0} lab@exB-1> show

VLAN vll vll

{master:0}

route

Next-hop 1315

igmp-snooping

Group 224.0.0.0, * 224.7.7.123, * 1317

lab@exB-1> show igmp-snooping statistics

Bad length: 0 Bad checksum: 0 Invalid interface: 0

Not local: 0 Receive unknown: 0 Timed out: 0

IGMP Type Received Transmited Queries: 1 6 Reports: 2 2 Leaves: 0 0 Other: 0 0

{master:0} lab@exB-1> show igmp-snooping task

Pri Task Name Pro Port 0 KRT 0 next-hop 0 ESW Interfaces 0 DB manager

15 Memory 35 MLD 58 35 IGMP 2 40 krt inet 40 me inet

40 me bridge 40 ESP CLIENT:33001.128.0.0.1 33001 70 MGMT.local 70 MGMT Listen./var/run/mcsnoopd_mgmt

{master:0}


Recv Errors 0 0 0 0

So Flags 7 <WriteDisable>

9 <WriteDisable> 8 <WriteDisable>

6 <WriteDisable> 11 <WriteDisable> 10 <Accept WriteDisable>

www.juniper.net


lab@exB-1> show igmp-snooping vlans

VLAN Interfaces Groups MRouters Receivers RxVlans

vll 3 1 1 1 0

Step 1.30

Question: Do you see details about IGMP snooping

after making the configuration changes?

Answer: Yes, you should see that the VLAN v11 is

now participating in IGMP snooping.

From exK-1, use the show route forwarding-table family

ethernet-swi tching extensive command to review the switching table

entries to determine if you have a entry for the receiver's multicast group address.

{master:O}

lab@exB-1> show route forwarding-table family ethernet-switching extensive

Routing table: default.ethernet-switching [Index OJ

ETHERNET-SWITCHING:

Destination: default


Route reference: 0

Flags: sent to PFE

Next-hop type: discard

Destination: 3, *

Route type: interface

Route reference: 0

Flags: sent to PFE


Destination: 4, *

Route type: user






Flags: static, sent to PFE, rt nh decoupled

Nexthop:

Next-hop type: composite Index: 1359 Reference: 2

Next-hop type: unicast Index: 1282 Reference: 4






Destination: 4, *


Route reference: 0

Flags: none


www.juniper.net





Destination: 4, OO:Oc:29:b5:89:7d

Route type: user

Route reference: 0

Flags: sent to PFE, rt nh decoupled




Destination: 4, 00:26:88:ff:be:08

Route type: user

Route reference: 0





Destination: 4, eO

Route type: user

Route reference: 0


Nexthop:




Destination: 4, 224.7.7.123, *

Route type: user

Route reference: 0


Nexthop:






Destination: 5, *


Route reference: 0

Flags: sent to PFE


Destination: 6, *


Route reference: 0

Flags: sent to PFE


Destination: 7, *


Route reference: 0

Flags: sent to PFE


Destination: 9, *


Route referPnce: 0



Index: 1315

Index: 1284

Reference: 2

Reference: 5


Index: 131 7

Index: 1282

Index: 1284

Reference: 2

Reference: 4

Reference: 5







R011te interface-index: 0

www.juniper.net

Flags: sent to PFE


Destination: 10, *


Route reference: 0

Flags: sent to PFE


Step 1.31





Question: Do you see an entry for the multicast

group address?

Answer: Yes, you should see the entry now that you

turned on IGMP snooping.

From ex_K-1, log out.

{master:0}

lab@exB-1> exit

exB-1 (ttyuO)

login:

Step 1.32


From srx_.K-1, log out.

lab@srxB-1> exit

srxB-1 (ttyuO)

login:

Step 1.33

Return to the open troubleshooting session to srx_.K-2.

From srx_.K-1, log out.

lab@srxB-2> exit

srxB-2 (ttyuO)

login:



Step 1.34

Return to the open session to srxJ-2 with your multicast ping running.

From srxK-1, use Ctrl + c to cancel the ping requests and log out.

lab@srxB-2> ping 224.7.7.123 bypass-routing interface ge-0/0/6 ttl 10 routing-instance vrlll source 172.16.4.3

PING 224. 7. 7 .123 (224. 7. 7 .123): 56 data bytes "C --- 224.7.7.123 ping statistics 7012 packets transmitted, 0 packets received, 100% packet loss

lab@srxB-2> exit

srxB-2 (ttyuO)

login:

Step 1.35

lab@exB-2> exit

exB-2 (ttyuO)

login:

•

Return to the open session to exJ"-2.

From exK-1, log out.s

Tell your instructor that you have completed this lab.




.,. .,.

_

.,..,.

�M FE ----�. � • Serial Console Terminal � '- Connections srxA-2 Server \ '\ '-

\ '\ '-, \ '\ '

\ '\ '� \ '\ �

\ \

\

Server

srxA-1

srxA-2

srxB-1

srxB-2

srxC-1

srxC-2

E �

F H Workstations


/_ srx0-1 /_

/_ srx0-2 /_

/_ vr-device /_

/_ Server

/_ Gatev.ay

/_ Term Server



Pod A Network Diagram:


loO.O: 172.17.1.1 .1

srxA-1

.1

I 1\ exA-1

VLAN:vv1 ge-0/0/14

IGMPGroup: 224.7.7.123

,==.;;;;;;;;;;;;;;;;;;;;:::='.( __ 2

Receiver

ge-0/0/1

172.16.2.0/24

OSPF PIM-SM

RP· 172.17.1.2

loO.O: 17 2.17 .1.2 .2

srxA-2

.1

� b'� <D

'<"1

'<"1

.2

exA-2 loO.O: 172.17.1.3

.1

172.16.4.0/24

Source

©2013 Juniper Networks, Inc All nthts teseived. JUn!Per Worldwide Education Services lf\lVWW Juniper net

www.juniper.net

_________ ,..... _____ ----------Troubleshooting Advanced Features (Detailed) • Lab 5-27


Pod B Network Diagram:


loO.O: 172.17.1.1

.1

srxB-1

.1

n\ 0

$ exB-1 ;j

...._ __ ......., �

Receiver

ge-0/0/1

1721620/24

OSPF

PIM-SM

RP• 172.17.1.2

loO.O: 172.17.1.2

.2

srxB-2

.1

� � C)

� M 0 ......

g,. ......

.2

exB-2 loO.O: 172.17.1.3

.1

172.16.4.0/24

Source

©2013 Juniper Networks, Inc All nth ts reserved JUnLPgf V\/orldwide Education Services WWW Juniper net

Pod C Network Diagram:


Receiver

loO.O: 172.17.1.1

.1

srxC-1

.1

l ;\ 0

$ exC-1 ..;

---- �

ge-0/0/1

17216.2.0/24

OSPF

PIM-SM

RP• 172.17.1.2

loO.O: 17 2.17 .1.2

.2

srxC-2

.1

� � C)

� M 0 ......

.2

exC-2 loO.O 172.17.1.3

.1

172.16.4.0/24

Source

©2013 Juniper Netwotl(S, Inc All nth ts reserwed JUn� Worldwide Education Services WWW Juniper net



Pod D Network Diagram:


loO.O: 172.17.1.1

.1

srxD-1

.1

q\

Receiver

ge-Q/0/1

172.16.2.0/24

OSPF

PIM-SM

RP· 172.17.1.2

loO.O: 172.17.1.2

.2

srxD-2

.1

� C)

� «)

�

. 2

exD-2 loO.O: 172.17.1.3

.1

172.16.4.0/24

Source


- - � -- - - -- - - - - - - - --------www.juniper.net Troubleshooting Advanced Features (Detailed) • Lab 5-29



Documents

Advanced Junos Enterprise Switching Troubleshooting...Advanced Junos Enterprise Switching Troubleshooting 12.a Worldwide Education Services 1194 North Mathilda Avenue Sunnyvale, CA