Not For Reproduction: Troubleshooting JUNOS Platforms
Not For Reproduction: Troubleshooting JUNOS Platforms
Not For Reproduction: Troubleshooting JUNOS Platforms
Troubleshooting JUNOS
tio
Platforms
uc
9.a
d
ro
ep
Student Guide
rR
fo
ot
USA
408-745-2000
www.juniper.net
n
tio
uc
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 Software has no
d
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
ro
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.
ep
rR
fo
ot
N
Contents
n
Installation and Handling Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18
Platform Architecture and Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-28
tio
Interface Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-61
uc
Troubleshooting Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-6
Troubleshooting Tools: The JUNOS Software CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14
Troubleshooting Tools: The Craft Interface Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-27
Troubleshooting Tools: System Logs and Protocol Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . 3-30
d
Troubleshooting Tools: Interactive UNIX Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44
Troubleshooting Tools: Core Files for Diagnostic Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 3-53
Troubleshooting Tools: The JTAC Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-62
ro
Best-Practices Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-67
Lab 1: JUNOS Troubleshooting Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-79
ep
Chapter 4: JUNOS Platforms Hardware Troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
Hardware Troubleshooting Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3
Power On, Power Off, and Boot Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5
Using the CLI to Troubleshoot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14
rR
Contents • iii
Appendix B: Packet Flow Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B-1
RTOS Packet Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-3
ABC Chipset Packet Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-5
LMNR Chipset Packet Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-12
n
tio
d uc
ro
ep
rR
fo
ot
N
iv • Contents
Course Overview
This course provides students with the foundational knowledge required to troubleshoot
Juniper Networks platforms running JUNOS Software. This two-day course provides a brief
overview of the device families that run JUNOS Software and discusses the key architectural
components of the devices. Additional key topics include discussions of the JUNOS Software
troubleshooting toolkit, basic hardware and interface troubleshooting using the command-line
interface (CLI), and Juniper Networks Technical Assistance Center (JTAC) processes, guidelines,
and support resources.
n
Through demonstrations and hands-on labs, you will gain experience in troubleshooting and
monitoring the JUNOS Software and basic device operations.
tio
Objectives
After successfully completing this course, you should be able to:
uc
• Describe current JUNOS platforms offerings.
• Describe general installation procedures.
• Explain the architecture of JUNOS platforms.
d
• Describe the function of JUNOS platform components.
• Describe layered troubleshooting methodology.
•
•
ro
Use various troubleshooting tools.
Explain JTAC recommendations for current troubleshooting best practices.
ep
• Troubleshoot JUNOS platforms using visual indicators.
• Troubleshoot JUNOS platforms using the CLI.
• Troubleshoot JUNOS platform interfaces.
• Describe recommended JTAC troubleshooting processes and guidelines.
rR
Intended Audience
This course benefits individuals responsible for maintaining and monitoring devices running
JUNOS Software.
fo
Course Level
The Troubleshooting JUNOS Platforms course is a two-day introductory course.
Prerequisites
ot
Students should have taken the Introduction to JUNOS Software (IJS) course, and should have
basic networking knowledge, and an understanding of the OSI model and the TCP/IP protocol
suite.
N
. Course Overview • v
Course Agenda
Day 1
Chapter 1: Course Introduction
Chapter 2: Overview of JUNOS Platforms
Chapter 3: Troubleshooting Tool Kit for JUNOS Platforms
n
Lab 1: JUNOS Troubleshooting Tools
Day 2
tio
Chapter 4: JUNOS Platforms Hardware Troubleshooting
Lab 2: Chassis Hardware Troubleshooting
Chapter 5: Interface Troubleshooting
uc
Lab 3: Interface Troubleshooting
Chapter 6: JTAC Processes, Guidelines, and Support Resources
Appendix A: JUNOS Platform Details
d
Appendix B: Packet Flow Details
ro
ep
rR
fo
ot
N
vi • Course Agenda
Document Conventions
n
Franklin Normal text. Most of what you read in the Lab
tio
Gothic Guide and Student Guide.
uc
• Noncommand-related Exiting configuration
syntax mode
GUI text elements: Select File > Open, and then
click Configuration.conf in
• Menu names
d
the Filename text box.
• Text field entry
History.
CLI Input Text that you must enter. lab@San_Jose> show route
GUI Input Select File > Save, and enter
config.ini in the Filename
ot
field.
N
n
CLI policy my-peers
Variable assigned.
Click on my-peers in the dialog.
tio
GUI
variable
uc
the variable’s value as shown in the
GUI ping 10.0.1.1
lab guide might differ from the
Undefined
value the user must input. Select File > Save, and enter
filename in the Filename field.
d
ro
ep
rR
fo
ot
N
n
The Troubleshooting JUNOS Platforms Student Guide was developed and tested using software
Release 9.5R1.8. Previous and later versions of software might behave differently so you
tio
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
uc
training@juniper.net.
Technical Publications
You can print technical manuals and release notes directly from the Internet in a variety of
d
formats:
• Go to http://www.juniper.net/techpubs/.
ro
• 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
ep
account representative.
support/, or at 1-888-314-JTAC (within the United States) or 408-745-2121 (from outside the
United States).
fo
ot
N
Additional Information • ix
n
tio
d uc
ro
ep
rR
fo
ot
N
x • Additional Information
Troubleshooting JUNOS Platforms
n
tio
Chapter 1: Course Introduction
d uc
ro
ep
rR
fo
ot
N
Troubleshooting JUNOS Platforms
n
tio
d uc
ro
ep
This Chapter Discusses:
• Objectives and course content information;
• Additional Juniper Networks, Inc. courses; and
rR
n
tio
d uc
ro
ep
Introductions
This slide asks several questions for you to answer during class introductions.
rR
fo
ot
N
n
tio
d uc
ro
ep
Course Contents
The slide lists the topics we discuss in this course.
rR
fo
ot
N
n
tio
d uc
ro
ep
Prerequisites
The slide lists the prerequisites for this course.
rR
fo
ot
N
n
tio
d uc
ro
ep
General Course Administration
This slide documents general aspects of classroom administration.
rR
fo
ot
N
n
tio
d uc
ro
ep
Training and Study Materials
This slide describes Education Services materials that are available for reference both
in the classroom and online.
rR
fo
ot
N
n
tio
d uc
ro
ep
Additional Resources
This slide describes additional resources available to assist you in the installation,
configuration, and operation of Juniper Networks products.
rR
fo
ot
N
n
tio
d uc
ro
ep
Satisfaction Feedback
Juniper Networks uses an electronic survey system to collect and analyze your
comments and feedback. Depending on the class you are taking, please complete the
rR
survey at the end of the class, or be sure to look for an e-mail about two weeks from
class completion that directs you to complete an online survey form. (Be sure to
provide us with your current e-mail address.)
Submitting your feedback entitles you to a certificate of class completion. We thank
you in advance for taking the time to help us improve our educational offerings.
fo
ot
N
n
tio
d uc
ro
ep
Juniper Networks Education Services Curriculum
Juniper Networks Education Services can help ensure that you have the knowledge
and skills to deploy and maintain cost-effective, high-performance networks for both
rR
enterprise and service provider environments. We have expert training staff with deep
technical and industry knowledge, providing you with instructor-led hands-on courses
as well as convenient, self-paced eLearning courses.
You can access the latest Education Services offerings covering a wide range of
platforms at http://www.juniper.net/us/en/training/technical_education/.
fo
ot
N
n
tio
d uc
ro
ep
JNTCP
The Juniper Networks Technical Certification Program (JNTCP) consists of
platform-specific, multitiered tracks that enable participants to demonstrate, through
rR
n
tio
d uc
ro
ep
Certification Levels
Each JNTCP track has one to four certification levels. Associate-level and
Specialist-level exams are computer-based exams composed of multiple choice
rR
n
tio
d uc
ro
ep
Prepping and Studying
This slide lists some options for those interested in prepping for Juniper Networks
certification.
rR
fo
ot
N
n
tio
d uc
ro
ep
Any Questions?
If you have any questions or concerns about the class you are attending, we suggest
that you voice them now so that your instructor can best address your needs during
rR
class.
fo
ot
N
n
tio
Chapter 2: Overview of JUNOS Platforms
d uc
ro
ep
rR
fo
ot
N
Troubleshooting JUNOS Platforms
n
tio
d uc
ro
ep
This Chapter Discusses:
• The Juniper Networks platforms running JUNOS Software;
• Installation procedures for JUNOS platforms;
rR
n
tio
d uc
ro
ep
JUNOS Platforms Overview
The slide highlights the topics we cover in this chapter. We discuss the highlighted
topic first.
rR
fo
ot
N
n
tio
d uc
ro
ep
JUNOS Platform Categories
The categories of Juniper Networks JUNOS platforms are as follows:
• Multiservice routers (T Series, M Series, and J Series);
rR
n
these products as a network access layer, as campus aggregation devices (within
high-density data centers), or as core switches.
tio
Juniper Networks SRX Series Services Gateways are the next generation security
services gateways based on the Dynamic Services Architecture. The SRX Series
gateways enable secure deployment of a wide range of business and residential
applications and services ranging from small to large enterprises, at service provider
premises and within data centers. The gateways offer native support for firewalls,
uc
virtual private networks (VPNs), switching and carrier-class Ethernet routing, and
intrusion detection and prevention (IDP).
The Juniper Networks BX7000 Multi-Access Gateway operates within the
environmental constraints of the cell site and features such common uplink types as
d
copper, Ethernet, and DSL, to support both legacy and next-generation mobile
technologies. ro
Performance and Reliability
ep
All Juniper Networks JUNOS platforms deliver deterministic forwarding performance
with services enabled. All products employ the essential concept of separate
forwarding and control planes. By performing all complex, computation-intensive tasks
on an appropriately sized control plane, these products ensure that tasks go
unhindered by any degree of forwarding requirements. Likewise, this separation
rR
JUNOS Software
fo
A significant aspect of the JUNOS product line is that all JUNOS platforms run JUNOS
Software with support for all features. Even the small enterprise-class J Series routers
run the same JUNOS Software—repackaged to include the real-time operating system
(RTOS) software and related interface drivers instead of the high-end M Series and
ot
n
tio
d uc
ro
ep
T Series Core Routers
T Series Core Routers provide Gigabit Ethernet, SONET/SDH, and other high-speed
interfaces for large networks and network applications, such as those that ISPs
rR
ranging from access layer to core. The platforms provide SONET/SDH, ATM, Ethernet,
and channelized interfaces. ASICs, which are an integral part of device design, enable
the routers to forward data at the wire rate.
N
n
tio
d uc
ro
ep
Total Chassis Throughput
Juniper Networks T Series routers range from the T320, designed for a small network
core, to the T1600, capable of offering 3.2 Tbps. The T1600 is a multichassis-capable
rR
core router that you can upgrade in-service from existing T640 routers. The scale and
density of the T1600 allows service providers to increase capacity without adding
equipment to the network, saving on valuable floor space, rack space, and power
consumption.
fo
Range of Interfaces
T Series routers provide edge interfaces as well as the core functions required for
consolidated point of presence (POP) solutions. All T Series routers, from the T320 to
the T1600 and TX Matrix, support a wide range of interfaces, ranging from DS-3 to
ot
OC-768, including Asynchronous Transfer Mode (ATM), SONET, Ethernet, and both
fixed and tunable dense wavelength-division multiplexing (DWDM) interfaces.
N
n
tio
d uc
ro
ep
M Series Multiservice Edge Routers
The M Series portfolio ranges from 7 Gbps platforms to 320 Gbps platforms. You can
deploy M Series routers in various roles within your network. The M Series portfolio
rR
uniquely combines IP/MPLS capabilities with service richness, stability, reliability, and
security. The M Series routers allow service providers to consolidate multiple networks
on a single IP/MPLS infrastructure. You can deploy the M Series platforms as a
multiservice edge router, a small or a medium core router, a route reflector, or a
peering device. It can also be deployed in multicast, mobile, or data center
applications. The M10i and higher-end M Series routers offer RE and Control Board
fo
redundancy.
ot
N
n
tio
d uc
ro
ep
J Series Performance and Services
J Series routers maintain performance even when you enable advanced services such
as Network Address Translation (NAT), access control lists, and stateful firewalls.
rR
Modular JUNOS Software provides key routing and security features such as stateful
firewalls, IPsec, MPLS, and IPv6, defending against infrastructure attacks and fully
protecting the processing resources.
J Series routers provide a large selection of connectivity options including T1 and E1,
Serial, Fast Ethernet, Gigabit Ethernet, DS3, E3, ISDN, ADSL2+, and G.SHDSL. The
product options include hardware encryption acceleration, power supplies, DRAM,
compact flash, and feature licenses. All J2320, J2350, J4350, and J6350 routers ship
ot
with four fixed 10/100/1000 Ethernet ports. You can add more modular LAN and
WAN interfaces.
N
n
tio
d uc
ro
ep
MX Series Ethernet Services Routers Hardware
MX Series routers (MX960, MX480, and MX240) provide Ethernet switching
capabilities without sacrificing the carrier-class routing features customers expect
rR
but the Ethernet switching separates Layer 2 and Layer 3 forwarding with the
intelligence to bridge when possible and route when needed. The platforms support
Dense Port Concentrator (DPC) interface cards, offering enhanced queuing
capabilities, QoS, L2 switching, and L3 routing services.
n
tio
d uc
ro
ep
EX Series Ethernet Switches
The EX Series Ethernet Switches offer flexible, powerful, and modular platforms that
deliver the performance, scalability, and high availability required for today’s
rR
high-density data center, campus aggregation, and core switching environments. The
platforms range from the EX2200 to the EX8216 systems, which could include fixed
ports and modular line cards of up to 10 Gbps.
The EX8200 line Switch Routing Engines (SREs) process all Layer 2 and Layer 3
protocols and manage individual chassis components, while the switch fabric module
provides the central crossbar matrix through which all data traffic passes. The SRE
and switch fabric modules work together to fulfill all RE and switch fabric functions.
ot
The EX Series Ethernet switches run the same JUNOS Software that Juniper Networks
routers run. By utilizing a common operating system, Juniper Networks delivers a
consistent implementation and operation of control plane features across all
N
n
tio
d uc
ro
ep
SRX Series Services Gateway
Juniper Networks SRX Series Services Gateways are the next-generation solution for
securing the ever increasing network infrastructure and application requirements for
rR
both enterprise and service providers. Designed from the ground up to provide flexible
processing scalability, input-output scalability, and services integration, the
SRX Series devices meet the network and security requirements of data center
consolidation, managed services deployments, and aggregation of security solutions.
Running JUNOS Software, which incorporates the Juniper Networks routing heritage
and service provider reliability, the SRX Series also offers the high feature and service
fo
n
tio
d uc
ro
ep
SRX5600 and SRX5800
SRX5600 and SRX5800 are next-generation services gateways based on new
architecture that provides unprecedented scalability and service integration. The
rR
devices are ideally suited for large enterprise and service provider networks. Based on
the Dynamic Services Architecture, the SRX5600 uses the same services processing
cards (SPCs) and input/output cards (IOCs) as the SRX5800. The SRX5800 can
support a more than 120 Gbps firewall and 30 Gbps IDP traffic. The SRX5600 can
support up to a 60 Gbps firewall and 15 Gbps IDP traffic.
fo
ot
N
n
tio
d uc
ro
ep
SRX3400 and SRX3600 Cards and Modules
The SRX3400 and SRX3600 offer native support for firewalls, VPNs, switching,
carrier-class Ethernet routing, and IDP. Each device is flexible and scalable, with
rR
multiple, interchangeable physical interface cards and security cards, including the
midplane, RE, SPCs, network processing cards (NPC), Switch Control Board (SCB), IOC,
Common Form-Factor Modules (CFMs), and DPCs. The SRX3600 can support an
approximately 10 Gbps firewall and 5 Gbps IDP traffic. The SRX3400 can support a
10 Gbps firewall and 2 Gbps IDP traffic. SRX3000 cards and SRX5000 cards are not
interchangeable.
fo
ot
N
n
tio
d uc
ro
ep
SRX650, SRX240, and SRX210
The SRX650, SRX240, and SRX210 provide full firewall and Unified Threat
Management (UTM), encompassing antivirus, IDP, Web filtering, and antispam to
rR
secure branch offices with a wide range of interfaces for WAN connectivity.
The SRX210 Power over Ethernet (PoE) feature simplifies IP phone, camera, and
wireless support by delivering power to those devices without any need for external
power.
The maximum firewall performance for the SRX650 is 7 Gbps, while it is 1.5 Gbps for
fo
n
tio
d uc
ro
ep
BX Series Multi-Access Gateway
The BX7000 Multi-Access Gateway effectively addresses the backhaul evolution
challenge for mobile operators with the most operationally efficient approach. The
rR
BX7000 is a compact platform that enables ease of its deployment in a cell site
cabinet with limited rack space. Additionally, it is available in an environmentally
hardened form factor for deployment scenarios where cabinets could have additional
exposure to natural elements.
fo
ot
N
n
tio
d uc
ro
ep
Deployment of JUNOS Platforms
The slide summarizes our review of all JUNOS platforms.
rR
fo
ot
N
n
tio
d uc
ro
ep
Installation and Handling Guidelines
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Follow Site Preparation Guidelines
To ensure a smooth installation, each platform has an associated hardware guide that
provides installation instructions. The hardware guide provides critical details such as
rR
maximum component and system power draw, system weights, and the clearances
needed for serviceability and proper cooling. We also provide an installation checklist
form to help ensure that you are ready to press your new platform into service the day
that it arrives.
For hardware manuals, go to: http://www.juniper.net/techpubs/hardware/index.html.
fo
Core Router.
Removing the power supplies, FPCs, fan trays, REs, and CBs can make a given
platform considerably lighter. For example, a T640 chassis and midplane alone
weighs only 205 pounds (93 kg). When fully loaded, the same chassis weighs 565
pounds (256 kg).
Continued on next page.
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Powering On JUNOS Platforms
You can equip each device can be equipped with two redundant, load-sharing power
supplies of the same type; in most cases these power supplies can be either AC or DC.
rR
Be sure to connect each power source properly. For example, each power supply
requires a dedicated power source. For sites with an AC power source, each power
supply has one power cord that plugs into a grounded 100–240 VAC power
receptacle. For sites with a DC power source, power normally travels around the site
through a main conduit to frame-mounted DC power distribution panels, one of which
might be located at the top of the rack where you intend to install the router. A pair of
fo
cables (–48 V and RTN) connects each DC supply to the power distribution panel. The
rear enclosure has grounding studs. After connecting all cables, turn one power
supply on first and then the second supply to avoid a large power spike.
Although the specifics of each power supply and PEM vary by platform, you should
ot
note that after a power supply powers on, it can take up to 60 seconds for status
indicators—such as LEDs on the power supply and show chassis commands—to
indicate that the power supply is functioning normally. You should ignore error
indicators that appear during the first 60 seconds.
N
n
tio
d uc
ro
ep
Graceful Shutdowns and Rebooting
JUNOS Software runs on a multitasking, multi-user operating system based on
FreeBSD. As with any UNIX system, you should always gracefully shut down the system
rR
before removing power (as opposed to performing an abrupt hard power off, in which
you simply remove the power from the system). Failing to shut down in a graceful
manner can result in file system corruption that prolongs the next boot, and in the
worst of cases, it might actually prevent a successful boot. Note that on some
platforms the chassis has a button that gracefully shuts down the RE when depressed
for 3–5 seconds. Once the system properly halts, you can safely remove power.
fo
The request system halt command gracefully stops the software and prepares
the device to shut down. Note that you must either cycle power or press the Enter key
on the terminal attached to the device’s console port to effect the reboot of a device
that has executed a shutdown command.
ot
n
System going down IMMEDIATEL
tio
shutdown: [pid 15049]
Shutdown NOW!
The request system reboot command causes the device to reboot. Reboot
uc
requests record to the system log files, which you can view with the show log
command. The reboot command takes a variety of arguments that you can use to
schedule the reboot, generate a system message, or specify the media from which to
boot. Media options include compact-flash and disk. The device always attempts to
boot from removable media when such media is present and you perform a power
d
cycle (cold boot).
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
FPC Handling
Some Flexible PIC Concentrators (FPCs) are heavy and can receive damage with
improper handling. The following figures illustrate some common forms of FPC abuse
rR
n
tio
d uc
ro
ep
General Handling: Electrostatic Damage
The field-replaceable units (FRUs) associated with JUNOS platforms contain
electrostatic discharge (ESD) sensitive parts; some components can receive damage
rR
• When handling any component that you remove from the chassis, make
sure the equipment end of your ESD strap attaches to one of the
electrostatic discharge points on the chassis.
N
• Avoid contact between the component and your clothing. ESD voltages
emitted from clothing can still damage components.
• When removing or installing a component, always place it
component-side up on an antistatic surface, in an antistatic card rack, or
in an electrostatic bag. If you are returning a component, place it in an
electrostatic bag before packing it.
n
tio
d uc
ro
ep
FRU Types
FRUs are platform components that you can replace at the customer site. Replacing
FRUs requires minimal routing node downtime. Generally speaking, the three types of
rR
n
tio
d uc
ro
ep
Typical Platform FRUs
All JUNOS platforms consist of a chassis and one or more FRUs. The slide shows the
primary FRUs associated with the T640.
rR
fo
ot
N
n
tio
d uc
ro
ep
Platform Architecture and Components
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
JUNOS Software Innovation
The modular design of the architecture of JUNOS platforms results in a clean
separation of the control plane and the forwarding plane, facilitating rich packet
rR
processing through ASIC construction. The control plane is where routers talk to each
other to determine topology and to set up services. The Routing Engine, which boasts
dedicated hardware, represents the control plane. Running on top of the Routing
Engine is the industry’s most proven and scalable operating system, JUNOS Software.
The operating system might be the single most critical component of a
high-performance device. JUNOS Software is a modular fault-protected operating
fo
system that can handle thousands of VPNs and BGP sessions and other types of
routing and signaling control information. Once the Routing Engine determines routing
topology and services, it pushes that information down to the forwarding plane, or
PFE. The forwarding plane consists of programmable ASICs, which deliver very rich
packet processing on a per customer basis, and it enables unparalleled forwarding
ot
performance.
Smaller JUNOS platforms, for example J Series Services Routers, continue the practice
of separation of forwarding and control planes, implementing this separation entirely
N
n
tio
d uc
ro
ep
Architectural Philosophy
Architecturally, all JUNOS platforms share a common design that separates the
router’s control plane and forwarding plane. JUNOS platforms consist of the following
rR
FPC.
• Packet Forwarding Engine: The PFE is responsible for forwarding transit
packets through the router using an ASIC-based switching path. Because
N
n
RE and PFE Synchronization
tio
The PFE receives the forwarding table from the RE. In the majority of cases, the PFE’s
forwarding table and the RE’s forwarding table synchronize over the 100 Mbps fxp1
Ethernet link, which interconnects the two entities. This synchronization ensures that
a change in topology produces identical forwarding tables in the RE and PFE. In the
uc
case of the M320 platform, a 100 Mbps Ethernet switch provides a dedicated link to
each FPC. These 100 Mbps links then present to the M320 RE as a single Gigabit
Ethernet uplink named bcm0. Forwarding table updates are a high priority for the
JUNOS Software kernel and it performs them incrementally.
d
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
T Series Architecture
The T Series architecture cleanly separates control operations from packet forwarding
operations. This design eliminates processing and traffic bottlenecks, permitting the
rR
n
tio
d uc
ro
ep
Logical Platform View of M Series
We designed the M Series architecture with scale and stability in mind, including the
modular and fault-protected design of JUNOS Software. M Series architecture offers a
rR
Similar to the T Series, the M Series device architecture includes FPCs, which could
house Physical Interface Cards (PICs). The M Series devices (with the exception of the
M120 and M320) use a shared memory architecture.
ot
N
n
tio
d uc
ro
ep
J Series Routers
The J Series brings deterministic forwarding performance and carrier-class stability to
small enterprise and remote offices. These routers continue the practice of separation
rR
of the forwarding plane and control plane, but they feature the economical innovation
of implementing this separation entirely in software. J Series routers use an RTOS to
simultaneously implement JUNOS Software, packet forwarding, and advanced
services, each in separate real-time threads. This practice enables these routers to
perform each of these functions with guaranteed and deterministic performance, with
no risk of one function degrading the performance of any other function.
fo
J Series routers use Physical Interface Modules (PIMs) instead of FPCs. A PIM is like
an FPC with built-in PICs of a common media type. The PIMs have numerous
low-speed WAN interfaces such as ISDN, xDSL, and serial, as well as LAN and
high-speed uplink interfaces such as DS-3. All J Series routers include two embedded
ot
n
tio
d uc
ro
ep
MX Series Architecture
Similar to core routers, MX Series devices are packet based and deploy distributed
memory architecture. The architecture includes RE redundancy, the control plane, the
rR
SCB, and the DPCs. The control plane of the platform’s chassis consists of Gigabit
Ethernet links between the SCBs or REs and each DPC. Each SCB has a connection to
every DPC in the chassis, which in turn means that each RE has a redundant
connection to each DPC. The switch fabric failover and the RE failover are
independent from each other.
fo
The host subsystem consists of an RE functioning together with an SCB. The router
can have one or two host subsystems. If it has two host subsystems installed, one
functions as the master and the other functions as the backup. If the master host
subsystem (or either of its components) fails, the backup can take over as the master.
To operate, each host subsystem requires an RE installed directly into an SCB. If you
ot
configured the REs for graceful switchover, the backup RE automatically synchronizes
its configuration and state with that of the master RE. Any update to the master RE
state replicates on the backup RE. If the backup RE assumes mastership, packet
forwarding continues through the router without interruption.
N
n
tio
d uc
ro
ep
SRX Series Architecture
SRX Series devices deploy Dynamic Services Architecture that includes the
management and control necessary to incorporate individual blades into a powerful
rR
collective solution. Rather than housing disparate cards, the Dynamic Services
Architecture adds each blade into a growing pool of resources. The SRX Series device
can utilize these resources as necessary for optimal processing of traffic.
At the heart of the Dynamic Services Architecture is the switch fabric and SCB. The
SCB transforms the chassis from a simple blade enclosure into a highly effective
fo
mesh network. The purpose of the SCB is to allow all blades in the chassis to send
traffic at extremely high bandwidth.
The RE tightly couples with the functionality of the SCB and we can consider it the
central nervous system of the architecture. The RE is the control plane of the chassis
and provides overall management and communications to and from system
ot
administrators, as well as calculating route tables for routing network traffic. JUNOS
Software, which includes key chassis functionality, also runs on the RE. In the case of
networking and security, functionalities such as advanced routing, switching,
N
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
JUNOS Software
The primary copy of JUNOS Software resides on the flash memory of the JUNOS
device. A backup copy is available on the hard disk when you issue a request
rR
that control the interfaces on the device. It also handles a few of the chassis
components, system management, and user access to the device. These routing and
software processes run on top of a kernel that interacts with the PFE. JUNOS Software
directs all routing protocol packets from the network to the RE.
ot
Command-Line Interface
The RE provides the command-line interface (CLI). The CLI runs on top of the kernel;
N
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Custom ASICs
ASICs enable the router to achieve data forwarding rates that match current fiber-optic
capacity. The router achieves these rates by distributing packet processing tasks
rR
task optimally.
Real-Time Threads
ot
n
tio
d uc
ro
ep
The Midplane
The system midplane is the component of the PFE that distributes power and
electrical signals to each card in the system. Typically the midplane is passive in
rR
JUNOS platforms.
component of the PFE using the Internet Processor II ASIC. Each System Control Board
on M Series routers provides the same function, despite each having different names.
On the M7i and M10i, the FPC and Control Board components combine onto a single
board named the Compact Forwarding Engine Board (CFEB). On the M7i and M10i,
the Fixed Interface Card (FIC) or High-Availability Chassis Manager (HCM) perform
ot
chassis control functions, such as PIC online and offline and chassis monitoring,
respectively. The M Series System Control Board—FEB, CFEB, or Switching and
Forwarding Module (SFM)—also houses the buffer management ASICs on all models.
N
n
• Management of ASICs and PFE components: The System Board monitors
various system components for failures and alarm conditions. It collects
tio
statistics from all sensors in the system and relays them to the RE, which
sets the appropriate alarm. For example, if a temperature sensor exceeds
the first internally defined threshold, the RE issues a high temp alarm.
The System Board handles the power on and power off of PFE
components with diagnostic errors reported to the RE over the 100 Mbps
uc
fxp1 interface.
• Environmental monitoring: The System Board monitors the various
temperature sensors to control fan speed and over-temperature alarm
generation.
d
• SONET clock: The System Board generates a Stratum 3 clock reference
used to clock SONET interfaces.
ro
• Transfer of exception and control packets: The Internet Processor ASIC
passes exception packets to a microprocessor on the System Board,
which processes almost all of them. JUNOS Software sends the
ep
remaining packets to the RE for further processing. If the System Board
detect errors originating in the PFE, the software logs them and makes
them available to the CLI.
rR
n
tio
d uc
ro
ep
Physical Interface Cards
As with the M Series routers, PICs provide T Series PFEs with a large range of
fiber-optic and electrical transmission interfaces to the network.
rR
designed the latter FPC type specifically for native T Series PICs. Packets that ingress
and egress on the same PFE complex (for example, on PICs 0 and 1 or PICs 2 and 3 of
a given FPC) do not leave that PFE. The SIBs switch packets between PFEs across the
T Series switch fabric as needed.
Continued on next page.
ot
N
n
of a SIB failure, SIB 0 automatically becomes active. There might be a slight
performance degradation when using SIB 0 because each FPC has only one
tio
high-speed line to SIB 0 (two high-speed lines interconnect the FPCs of SIB 1 and
SIB 2).
The Midplane
uc
The midplane distributes power and electrical signals to the components and cards
that make up the PFE and the switch fabric.
d
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
The M320 FPC and Switch Fabric
As with the T Series platforms, the M320 FPCs contain from one to two complete PFE
complexes. As was also the case with T Series, packets that ingress and egress on the
rR
same PFE complex (for example, on PICs 0 and 1 or PICs 2 and 3 of a given FPC) do
not leave that PFE. The SIBs switch packets between PFEs across the crossbar switch
fabric as needed.
The M320 also makes use of a shared memory switch fabric for communications
between and across FPCs and PFEs. In addition, inter-FPC communications require
fo
transit of the T Series-based crossbar switch fabric, which the system’s four SIBs form.
You can configure an M320 with one to four active SIBs. Adding and activating more
SIBs enables you to maintain line-rate forwarding performance for larger numbers of
higher-bandwidth PICs (see the M320 Hardware Guide for a detailed performance
breakdown). The M320 platform can operate with a SIB in standby mode for fault
ot
tolerance, but it does not have the space for a fifth SIB. Thus, if you configure an
M320 to have a bandwidth requirement for four SIBs and you have a SIB failure, the
router performance declines until you replace the affected SIB.
N
n
tio
d uc
ro
ep
Internet Processor II
The Internet Processor ASIC, which first shipped with the M40 in September 1998,
heralded a breakthrough technology that facilitated longest-match traffic forwarding
rR
for virtually all packet sizes at or very near line rate. Performance tests in the lab, test
networks, and on the Internet itself all demonstrated 40 Mpps of 40-byte packets with
80,000 prefixes in the routing table!
Building on this tradition, the Internet Processor II ASIC continues to deliver
best-of-class functionality for network core and edge applications. While the Internet
fo
Processor II ASIC still delivers a 40 Mpps forwarding rate, the new ASIC adds rich
packet processing features that include firewall filtering, sampling, logging, counting,
and enhanced load balancing. The Internet Processor II ASIC maintains high
performance in the presence of value-added feature sets and enhanced services.
All T Series routers make use of the latest Internet Processor ASIC technologies. In
ot
On ABC chipset platforms, the C chip—actually the Cf chip (f is for filtering)—is the
Internet Processor II chip. On LMNR chipset platforms, the R chip is the Internet
Processor II chip.
n
tio
d uc
ro
ep
I-Chip Overview
Inheriting all the features of the LMNR chips, the I-chip is the Juniper Networks
next-generation Internet processor delivering PFE on a chip. Each I-chip can send
rR
20 Gbps of bandwidth to the fabric and can receive 17 Gbps of bandwidth from the
fabric. The I-chip’s flexibility comes through programmability, a rich instruction set,
and silicon development. Various Juniper Networks platforms deploy the I-chip,
including the M120, the MX Series, and the SRX Series.
fo
New Capabilities
The I-chip provides industry-leading scalability, allowing significant headroom in
multiple dimensions, including VLANs, logical interfaces, routes, counters, number
and size of firewall filters, and policing and shaping technologies. It provides complete
ot
classification. The data structures used in the I-chip allow it to scale multicast traffic
at port speed without compromising performance.
n
tio
d uc
ro
ep
Deterministic Performance
The J Series Routing Engine and software PFE both implement on the primary x86
architecture microprocessor. A real-time operating system kernel mediates access to
rR
the underlying hardware. The real-time kernel ensures that operating system services
delivery occurs in a constant, load-independent, amount of time. This process ensures
that the forwarding and services real-time threads deliver predictable packet
forwarding performance.
fo
n
tio
d uc
ro
ep
J Series Virtual Packet Forwarding Engine
The J Series software PFE maintains many of the benefits of the microkernel and
ASIC-based PFE found on M Series and T Series platforms at a fraction of the cost. A
rR
UNIX socket provides the internal link between the RE and PFE and allows reuse of the
JUNOS Software control plane from the M Series and T Series platforms on the
J Series platform.
fo
ot
N
n
tio
d uc
ro
ep
General FPC Characteristics and Features
FPCs install into the backplane from the front of the chassis. You can install an FPC
into any FPC slot; it does not require any specific order. If an FPC does not occupy a
rR
slot, you must install a blank FPC carrier to shield the empty slot so that cooling air
can circulate properly through the card cage. FPCs can support from one to four PICs,
depending upon specifics. For example, an OC192 interface on an M120 router goes
into a Type 3 FPC, which has only one slot—such a high-speed interface consumes all
available FPC bandwidth. Most FPCs support four PIC connectors; current exceptions
are the T320 and the M320, which support two PIC connectors per Type 3 FPC, the
fo
M120 as mentioned, and the M40e Type 2 FPCs, which also support only a single PIC.
When you install an FPC into a running system, the FPC requests its operating
software from the Routing Engine, runs its diagnostics, and enables its PICs on the
FPC slot. FPCs are hot-swappable on all platforms except the M7i and the M10i
ot
because these routers have FPCs that combine with the system board components to
create a CFEB. The CFEB on the M7i and the M10i is hot-insertable but not
hot-removable.
N
Note that when you remove or install an FPC on an M Series router, the system must
re-partition the shared memory pool; this process results in about 200 milliseconds of
disruption to all packets associated with the affected PFE. T Series platforms contain
from one to two complete PFEs on each FPC, and therefore removal or insertion of
FPCs does not affect packet forwarding on other FPCs.
Continued on next page.
n
Industry-Leading Throughput
tio
ABC chipset-based routers have an aggregate slot throughput of 6.4 Gbps. LMNR
chipset-based platforms increase aggregate slot throughput to a respectable 20 Gbps
for the M120, 40 Gbps for the M320 and the T320, and 80 Gbps for the T640.
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
MX Series Dense Port Concentrators
All DPCs come in either a small form-factor pluggable transceiver (SFP) or a 10-gigabit
small form-factor pluggable transceiver (XFP), which uses the most optimal port
rR
density with cost efficiency. Each DPC has connections to the switch fabric providing
line-rate connectivity for each port on the card.
DPCs provide multiple physical interfaces and PFEs on a single board that installs in a
slot in the MX Series router. A DPC receives incoming packets from the network and
sends outgoing packets to the network. Each DPC contains four PFEs. The PFEs on a
fo
DPC have purpose-built ASICs that perform packet processing and forwarding. Each
PFE consists of one I-chip for Layer 3 processing and one Layer 2 network processor.
Multiple PFEs contribute to the system’s full packet forwarding redundancy and
resiliency.
The three types of DPCs are switching and routing (DPCE-R), switching and limited
ot
scaling for Layer 3 (DPCE-X), and enhanced queuing (DPCE-Q). The DPCs support a
wide range of Layer 2 and Layer 3 Ethernet functionality, including 802.1Q VLAN, link
aggregation, circuit cross-connect, Virtual Router Redundancy Protocol (VRRP),
N
Layer 2 to Layer 3 mapping, and port monitoring. Additionally, the DPCs support
filtering, sampling, load balancing, rate limiting, class of service, and other key
features necessary for deployment of dependable, high-performance Ethernet
services.
n
tio
d uc
ro
ep
Service Processing Cards
SPCs are blades that provide the capacity to perform the heavy lifting of processing
network packets. The chassis must have at least one SPC to operate. You realize the
rR
true elegance of this design when your system has more than one SPC installed.
Rather than the chassis having two or more “brains”, as in traditional network
architecture, the addition of a new SPC essentially results in a larger system that can
perform many more tasks at a given time. To ensure the highest level of reliability, the
SPCs and REs are separate—both physically and logically. This separation of the
control and data planes ensures that a fault on any of the SPCs does not result in
fo
catastrophic failure of the entire chassis. You can see the importance of this concept
in a security situation such as a denial of service (DoS) attack. When the attack
launches, your efforts to contact the system do not simply become part of network
traffic. Because the control plane remains separate from traffic flow, you can
immediately respond to network-threatening situations to divert the attack, while all
ot
n
tio
d uc
ro
ep
PIC Overview
PICs provide the physical connection to various network media types. PICs receive
incoming packets from the network and transmit outgoing packets to the network.
rR
During this process, each PIC performs appropriate framing and signaling for its
media type. Before transmitting outgoing data packets, the PIC adds media-specific
framing to the packets received from the FPCs. You can install up to four PICs into
slots on each FPC. PIC types can intermix within the same FPC. The number of ports
on a given PIC varies with the PIC and platform type. For example, M40e PICs are
available with as many as 48 Fast Ethernet ports.
fo
IP services PICs enable a hardware assist for complex packet processing functions.
Examples include the tunnel services and multilink services PICs. With the tunnel
services PIC, routers can function as the ingress or egress point of an IP over IP
unicast tunnel, a generic routing encapsulation (GRE) tunnel, or a Protocol
ot
Independent Multicast sparse mode (PIM-SM) tunnel. The multilink PIC uses the
Multilink Point-to-Point Protocol (MLPPP) and Multilink Frame Relay (MLFR, FRF 1.5) to
group up to eight T1 or E1 links per bundle, yielding a service offering ranging from
1.5 Mbps through 12 Mbps (T1) or 2 Mbps through 16 Mbps (E1).
N
Media-Specific ASIC
Each PIC has an ASIC that performs control functions tailored to the PIC’s media type.
For instance, an ATM PIC and a Fast Ethernet PIC each contain unique ASICs—or
field-programmable gate arrays (FPGAs)—that are specifically suited to the particulars
of each medium.
PIC Status
n
Each PIC supports one or more status LEDs that accommodate quick verification of
the PIC, and in some cases, the port’s operational status.
tio
Hot-Pluggable in Most Platforms
You can replace or install PICs without removing the associated FPC on most
platforms.
uc
Note that you should always take care to take a PIC offline before removing it from its
FPC to minimize system disruption. You should expect small amounts of packet loss
on all PICs sharing the affected FPC when hot-swapping PICs on M Series platforms
(excludes the M320, which is based on a T Series PFE). This momentary disruption is
d
the result of the FPC undergoing a logical reset in reaction to the insertion and
removal of a PIC. Failing to take a PIC offline before removing it from its FPC can result
ro
in damage to the system or a PFE reset.
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Craft Interface
The Craft Interface is the collection of mechanisms on some JUNOS platforms that
allows you to view system status messages and troubleshoot the router. The Craft
rR
Interface is located on the front of the chassis and typically consists of various system
status LEDs and FPC (or PIC) online and offline buttons. On supported platforms the
Craft Interface includes an LCD screen that provides status reporting for the entire
system.
The M7i’s FIC and the M10i’s HCM card provide PIC offline and online functionality.
fo
ot
N
n
tio
d uc
ro
ep
Craft Interface—No LCD Display Example
The slide illustrates a typical view of the SRX5800 Craft Interface. Although the Craft
Interface does not have the LCD display, system component LEDs provide enough
rR
n
tio
d uc
ro
ep
System Status LEDs
The system status LEDs include the following:
• FPC LEDs: Two LEDs exist—one green for OK and one red for fail. These
rR
lights indicate the status of each FPC. Each LED pair on the Craft
Interface aligns with the corresponding FPC module slot.
• Routing Engine or Host LEDs: A red fail LED and a green OK LED on the
Craft Interface indicate the status of the Routing Engines or Host
modules.
fo
and hold the offline button near the FPC (or PIC) until the green OK LED extinguishes.
For systems with fixed FPCs, like the M7i and M10i, the online and offline buttons help
prepare a PIC for removal from the system.
N
n
tio
d uc
ro
ep
Red Alarm
The red alarm LED indicates a system failure likely to cause an interruption in service.
Examples of red alarms include the following:
rR
Yellow Alarm
The yellow alarm LED indicates a system warning not likely to interrupt service, but if
left uncorrected, might eventually cause a service interruption. Examples of yellow
alarms include the following:
ot
• Maintenance alert;
• FPC with recoverable errors; and
N
n
tio
d uc
ro
ep
LCD Display
The Craft Interface on selected platforms supports a four-line LCD screen with six
navigation buttons. The LCD screen operates in one of two display modes. The default
rR
or idle mode, displays the current system status until alarm mode preempts it. The
following list contains the basic status information in the LCD display:
• Router’s name on the first line;
• Number of days, hours, minutes, and seconds that the system has been
running on the second line; and
fo
• Status messages on the fourth line, which are various system status
messages that cycle at 3-second intervals.
You can alter the idle mode display by specifying a message of your choosing with the
set chassis display message operational mode command. The Craft
ot
Interface display cycles between the user-defined and standard display every
2 seconds unless you also configure the permanent argument. The user-defined
message only persists for 5 minutes, however. You can view the LCD display, along
N
n
tio
d uc
ro
ep
Interface Overview
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Permanent Interfaces
Each JUNOS platform has several permanent interfaces. One, the management
Ethernet interface, provides an out-of-band method for connecting to the device. You
rR
can connect to the management interface over a network using utilities such as SSH
and Telnet, and SNMP can also use the management interface to gather statistics
from the router. The out-of-band management interface requires configuration to
operate. The names of out-of-band management interfaces vary depending on the
platform. For example, most JUNOS platforms use fpx0 for out-of-band management,
while the EX Series uses me0.
fo
traffic arriving on the out-of-band interface cannot egress on a PFE port, and vice
versa. This design isolates the out-of-band network from transient traffic and
preserves bandwidth on the internal fxp1 or bcm0 control interface.
N
Platforms with redundant REs use a third interface (fxp2 or em0) to interconnect the
REs for heart-beat and internal communications exchanges.
Internal interfaces like fxp1 and fxp2 do not require any configuration. You should not
attempt to configure or modify these interfaces.
n
tio
d uc
ro
ep
Transient Interfaces
Each FPC can support from two to four PICs, depending on the platform. PICs provide
the actual physical interfaces to the network. These physical interfaces are the
rR
device’s transient interfaces. We refer to them as transient because you can hot-swap
FPCs and PICs on most platforms at any time. From the point of view of the PFE, you
can place any FPC into any slot, and you can generally place any combination of PICs
in any location on an FPC. These characteristics makes PFE interfaces transient.
You can use a transient interface for networking or to provide hardware-assisted
fo
services within the device. Service examples include IPsec, stateful firewall, and GRE
tunneling. You must configure each of the transient interfaces based on the slot in
which you installed the FPC, the location in the FPC in which you installed the PIC, and
the port to which you connect.
Continued on next page.
ot
N
n
The slide shows an example of a channelized interface name that makes use of the
colon (:) delimiter to identify a time slot within the channel bundle.
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Logical Interfaces
Each physical interface descriptor can contain one or more logical interface
descriptors. These descriptors allow you to map one or more logical (sometimes
rR
The unit number and the circuit identifier are different in meaning. The circuit
identifier identifies the logical tunnel or circuit, while the unit identifies a logical
partition of the physical interface.
Although not required, we generally consider it best practice to keep the unit number
ot
and circuit identifier identical. This practice can greatly aid in troubleshooting when
you have many logical circuits.
N
Point-to-Point Encapsulations
PPP and Cisco HDLC encapsulations support only a single logical interface, and its
logical unit number must be zero. Frame Relay and ATM encapsulations support
multiple logical interfaces, so you can configure one or more logical unit numbers.
Continued on next page.
Addressing Issues
A JUNOS platform can have more than one address on a single logical interface.
Issuing a second set command does not overwrite the previous address but simply
adds to that address. Use of the CLI’s rename command is an excellent way to
correct addressing mistakes.
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Interface Media Types
The slide shows the list of interface media types.
rR
IP Services PICs
IP Services PICs provide value-added services such as tunneling or the management
of multilink bundles. IP Services PICs do not have ports or media associated with
them, but they do have two-letter interface type designations as shown in the following
fo
list:
• es: Encryption interface;
• gr: Generic route encapsulation tunnel interface;
• ip: IP-over-IP encapsulation tunnel interface;
ot
n
• mtun;
tio
• ipip;
• tap; and
• PIMe/PIMd.
uc
In most cases these interfaces require a corresponding services PIC to operate. The
tap interface is no longer operational, but FreeBSD continues to support it.
d
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Identifying Transient Interfaces
The interface’s FPC slot number, the PIC slot number, and the PIC’s physical port
number in the form of media-type-fpc-slot/pic-slot/port-number,
rR
Each platform has labels that clearly identify the FPC slot number and PIC number.
Furthermore, each PIC has a label to identify the number associated with that PIC’s
physical ports.
n
tio
d uc
ro
ep
This Chapter Discussed:
• Juniper Networks platforms running JUNOS Software and their typical
applications;
rR
n
tio
d uc
ro
ep
Review Questions
1.
rR
2.
3.
fo
4.
ot
N
n
tio
uc
d
ro
ep
rR
fo
ot
N
n
tio
Chapter 3: Troubleshooting Tool Kit for JUNOS
Platforms
d uc
ro
ep
rR
fo
ot
N
Troubleshooting JUNOS Platforms
n
tio
d uc
ro
ep
This Chapter Discusses:
• Warnings and caveats regarding potentially disruptive commands and
techniques;
rR
n
tio
d uc
ro
ep
Caveats and Warnings
The slide lists the topics we cover in this chapter. We discuss the highlighted topic
first.
rR
fo
ot
N
n
tio
d uc
ro
ep
Potential Disruptions
Troubleshooting a communications network involves the use of numerous tools. As
with all tools, a potential exists for disruption or harm should you not use a given tool
rR
chapter.
The goal of this chapter is to prepare you to work with a JTAC engineer, who, in an
effort to resolve a problem, might request that you perform one or more of the actions
we document.
ot
N
n
tio
d uc
ro
ep
Generalized Content
In an effort to appeal to the wide range of customers that deploy, operate, and
troubleshoot JUNOS platforms, the materials in this course are somewhat generalized.
rR
We always recommend that you consult the specific documentation for your particular
hardware platform and software release before taking any specific actions. You should
always defer to the specifics documented in a particular manual in the event of a
conflict between the information presented in this course and that found in your
manuals.
fo
JUNOS platforms. These guides provide operational information helpful for the most
basic tasks associated with running a network using Juniper Networks products. The
guides do not directly relate to any particular release of JUNOS Software and make
excellent reference companions to this course. The material in this course augments
N
n
tio
d uc
ro
ep
Troubleshooting Methodology
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Begin with a Visual Inspection
The slide provides a few general troubleshooting tips. For example, it is generally a
good idea to begin hardware or platform troubleshooting with a visual inspection. This
rR
approach uses the keep it simple philosophy of life. If you happen to notice a black
smear that is indicative of smoke or fire damage near a component, you have most
likely brought yourself closer to the source of a problem with little effort.
It might seem pretty basic, but how can you spot signs of anomalous behavior if you
are not confident of what behavior you expect in the first place? Put another way, how
can you know if 30% CPU utilization on a system’s Control Board is a sign of a
problem, or an indication of normality, if the first time you display the component's
ot
Many problems are transient by nature, and in some cases, testing causes more
disruption then the problem itself. If a transient condition has already cleared,
conducting disruptive testing benefits you very little. It is better to plan on long-term
monitoring with testing occurring when the problem next manifests.
Continued on next page.
n
Each Hypothesis Should Be Testable
tio
It does little good to dream up possible causes for a problem if you cannot definitively
test whether the hypothesis is valid. You should try to formulate possible causes that,
when tested, tend to eliminate possible causes for the problem, regardless of the
actual outcome of the test. For example, conducting a local loopback on an interface
uc
eliminates the transmission line as a possible cause when the test fails. At the same
time, this test eliminates the interface as a possible cause should the test succeed.
d
Operators often overlook a potential source for a problem because of their subjective
experiences. While leveraging your memory and past actions against a current
ro
problem is a good thing, you should never close your mind to new possibilities.
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
General Problem-Solving Flow Diagram
Before embarking on your troubleshooting effort, be sure to have a plan in place to
identify potential problems, isolate the likely causes of those problems, and then
rR
n
tio
d uc
ro
ep
Modern Communications Networks Are Layered
Modern communications networks are complex. In 1977, the International Standards
Organization developed a standard way of viewing these functions in the form of the
rR
Open Systems Interconnection (OSI) model. While the specifics of the OSI model are
now more or less irrelevant given that TCP/IP is generally favored, the concept of a
layered communications architecture is still quite valid.
Understanding the role that each layer plays and how each layer depends upon the
services of the layers that lie below it, can greatly simplify the task of locating the
fo
system. The net result is that many common symptoms, for example, no route, can tie
to failures that can occur at numerous layers. In these cases, you must question
whether the route is missing because of a Physical Layer fault, a malfunction of the
Data Link Layer, a failed Layer 3 adjacency, or other network layer problem—or if it is
an upper-layer problem like a policy that is rejecting the route in question.
Continued on next page.
n
at that layer so you can take the appropriate corrective actions. For example, knowing
that the issue relates to mismatched T1 and DS1 framing (Physical Layer) allows you
to correct the problem by configuring both devices for compatible framing to actually
tio
resolve the fault.
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
No HTTP Connectivity: A Rather Generic Symptom
The slide helps illustrate the layered approach to troubleshooting by providing a typical
communications topology and a rather generic symptom.
rR
As far as what layers can account for this problem, the best answer is all of them.
Specifically, a fault at the Physical, Data Link, Network, Transport, or Application
Layers might exist.
Examples of possible faults and their scope include the following:
fo
channel identifiers [VCI]) could all be possible faults. This layer operates
on a link-by-link basis.
• Network Layer: Incompatible addressing, subnet masks, filters, or interior
N
n
tio
d uc
ro
ep
Understanding Control and Forwarding Plane Separation
When troubleshooting JUNOS platforms, you must understand the separation of the
control and forwarding planes, regardless if the separation occurs in hardware or
rR
software. Generally speaking, problems with a routed network come down to either a
control plane issue or a forwarding plane issue. It is extremely rare to find a fault in
both planes simultaneously because of the completely different role that each plane
plays.
The control plane primarily deals with the installation of routes in the forwarding table.
fo
path. Problems in the forwarding plane tend to take the form of bad hardware (for
hardware-based platforms), policers, or firewall filters that prevent or impair
communications despite valid routes existing in the control plane. (We can argue that
N
the last two items—policers and filters—are really control plane problems that manifest
themselves in the forwarding plane.)
While application-specific integrated circuits (ASICs) and higher-end platform packet
forwarding engines are complex, they tend to work. Thus, the majority of problems you
encounter when troubleshooting high-end platforms relate to the control plane of the
device, which is why the slide suggests that you begin fault analysis by examining the
control plane first.
n
tio
d uc
ro
ep
Troubleshooting Tools: The JUNOS Software CLI
The slide highlights the topics we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
The JUNOS Software CLI
The JUNOS Software command-line interface (CLI) is the primary mechanism for
troubleshooting and operational analysis. Using the CLI, it is easy to determine
rR
hardware, software, protocol, and general operational status. The following are some
key CLI features:
• Support for piped output to functions like count or match for all
commands and in all modes (configuration or operational mode);
• The ability to restart software processes and take hardware online or
fo
offline;
• The ability to control redundant hardware; and
• Various network utilities like ping and traceroute, and the ability to
monitor local traffic in a manner similar to tcpdump.
ot
N
n
tio
d uc
ro
ep
Key Operational Mode Commands
Depending on the type of problem with which you are dealing, numerous JUNOS
Software CLI commands might exist that can assist you in problem determination. The
rR
slide calls outs the main classes of operational mode commands that prove
particularly useful in most troubleshooting situations:
• The various show chassis commands are well suited to assisting you
in performing operational and fault analysis of hardware-related issues;
• The family of show system commands are useful in detecting
fo
• The show route commands are invaluable when testing the control
plane to determine what routes are present, from where the router
learned of them, and where they direct matching traffic;
N
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Restarting Software Processes
You can restart most JUNOS Software processes from the CLI. This capability
leverages the modular nature of JUNOS Software and avoids the need for a system
rR
process to reread its configuration file but does not terminate the process.
When restarting a process, the default behavior is a soft kill, or graceful shutdown, in
which the process receives a signal that it should terminate but is given time to clean
up its state first. In contrast, a hard kill is equivalent to issuing a kill -9 pid, in
that it terminates the process immediately.
ot
The init process restarts any process that has failed, so after killing a process, a
new instance of that process starts. However, if a process fails repeatedly in rapid
succession, the init process disables it to prevent thrashing. Once init disables a
N
process, you must reboot, or force init to reread its configuration before it allows
that process to restart. Issuing a commit with the hidden full switch passes the
init process a SIGHUP that causes it to restart all configured processes, regardless
of previous thrashing behavior. However, if the process still thrashes, init disables it.
n
tio
d uc
ro
ep
Bouncing a Component of rpd
Currently, the routing protocol process (rpd) is responsible for handling all routing
protocol functions. If you detect a problem in the OSPF protocol, for example, then a
rR
restart routing command might resolve the issue. The problem is that
restarting routing affects all routing protocols, which include BGP, IS-IS, RIP, and so
forth.
When the goal is to minimize overall disruption (which it always is), you might consider
the technique shown on the slide, which involves deactivating a particular protocol,
fo
rather then restarting all routing functionality. The downside to this approach is that
configuration privileges are necessary.
The example on the slide shows the operation bouncing BGP by deactivating the bgp
stanza and issuing a commit. During the process, the OSPF protocol remains
untouched and continues to operate as before. After the commit and a
ot
rollback 1, the user issued another commit that restored the bgp stanza to its
previous (active) state. The BGP protocol now initializes, just as if you had restarted
the rpd process. Rather than using the rollback function, you can also issue an
N
n
tio
d uc
ro
ep
Performing a Full Commit
JUNOS Software optimizes the process of committing a candidate configuration so it
does not disrupt processes when their portion of the configuration has not changed.
rR
While a great idea to be sure, the situation is rare in which a particular process fails to
wake up with a commit, and as a result, the modified configuration does not go into
effect.
By including the hidden full switch, when issuing a commit, you force all processes
to reread their configuration, which ensures the honoring of changes. A commit
fo
full also signals the init process with a kill -1 (SIGHUP) that forces it to reread its
configuration.
Shaking It Up
ot
n
tio
d uc
ro
ep
Hardware Restart
The slide shows how you can use the JUNOS Software CLI to take a Compact
Forwarding Engine Board (CFEB) (in some models), Flexible PIC Concentrator (FPC), or
rR
PIC offline and online. In some cases, you can clear problems by bouncing a piece of
hardware, which means taking the device offline and then bringing it back online
again.
The commands shown on the slide have the same effect as if you depressed the CFEB
offline button on the physical router to bring it offline.
fo
ot
N
n
tio
d uc
ro
ep
Hardware Mastership
On platforms that support hardware redundancy, the determination of a component’s
status as either master or standby is a function of software defaults and explicit
rR
configuration. The slide shows that you can use the CLI to determine mastership
status and to effect a change in status of a redundant component.
Although many hardware faults and some software faults trigger a mastership change
automatically (when so configured), instances exist in which a marginal failure does
not result in the affected components relinquishing their mastership role. In cases
fo
such as this one, or when you must perform routine maintenance on a redundant
component, you might want to force a change in mastership by using the CLI. Note
that depending upon what is being switched—Routing Engine (RE) versus system
Control Board—and the specific configuration (such as graceful restart enabled),
switching mastership status might result in a disruption to packet forwarding.
ot
Login to Other RE
N
On systems equipped with redundant REs, you can establish a login to the other RE
using an internal communications path. In most cases, you should ensure that the
software replicates configuration changes made on the active RE to the configuration
file used by the backup RE. When you issue a commit synchronize command,
the software uses the same internal path used for RE-to-RE logins to synchronize the
configuration file to the backup REs.
n
tio
d uc
ro
ep
Network Utilities and Applications: Part 1
As you might expect, JUNOS Software supports standard network utilities like ping and
traceroute. As shown on the slide (for the case of ping) these utilities support a rich
rR
set of optional switches that can prove especially useful when troubleshooting. The
following are some of the key switches:
• atm: Generates special Asynchronous Transfer Mode (ATM) pings that
use Operation, Administration, and Maintenance (OAM) cells.
• count: Limits the number of ping attempts.
fo
n
when testing a class-of-service (CoS) issue.
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Network Utilities and Applications: Part 2
JUNOS Software offers support for Telnet, SSH or SCP, and FTP. As with the ping and
traceroute utilities, these applications support switches that are useful in
rR
• port: The port switch allows you to specify a destination port other than
the default port normally associated with that service.
• routing-instance: This switch supports VPN and routing instance
context for applications like Telnet and FTP. A classic use would be to
ot
n
tio
d uc
ro
ep
Network Utilities and Applications: Part 3
The monitor traffic command provides CLI-based access to the tcpdump utility.
This command monitors only traffic originating or terminating on local the RE. This
rR
capability is the best way to monitor and diagnose problems at Layer 2 with JUNOS
Software because tracing, which is similar to debug on equipment from other
vendors, does not function for Layer 2 protocols. We cover tracing on subsequent
pages that deal with system logging.
Note that protocol filtering functions (for example, matching on only UDP traffic sent
fo
from a specific port) are currently not supported for real-time monitoring because in
real-time mode, the Layer 2 headers are stripped at ingress, which prevents filtering
on protocol types. As a workaround, you can write the monitored traffic to a file and
then read the file with a tcpdump-capable application like Ethereal. We provide an
example of how to achieve protocol filtering with the JUNOS Software monitor
ot
n
tio
d uc
ro
ep
Troubleshooting Tools: The Craft Interface Panel
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
The Craft Interface
The craft interface panel for systems that support the LCD status screen is an
excellent troubleshooting and operational analysis tool because it provides
rR
component and system alarm status in a manner that is easy to interpret. When
working remotely you can issue a show chassis craft-interface command
to obtain an ASCII representation of the LEDs and messages that the craft interface
displays.
fo
ot
N
n
tio
d uc
ro
ep
Displaying Messages on the LCD Screen
Displaying messages on the craft interface panel's LCD screen can be helpful when
you want to identify a system or communicate in some way with a person that is local
rR
to that machine. By default, the custom user message alternates with the normal LCD
message display (system status messages that alternate every few seconds). Use the
permanent switch with the set chassis display operational mode command
to force only the display of the custom message.
Note that the custom message times out after five minutes, and the display returns to
fo
the default system status message rotation. This command is applicable only to
platforms that have an LCD screen.
ot
N
n
tio
d uc
ro
ep
Troubleshooting Tools: System Logs and Protocol Tracing
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Syslog
Syslog operations use a UNIX syslog-style mechanism to record system-wide,
high-level operations, such as interfaces going up or down or users logging in to or out
rR
of the router. You configure these operations by using the syslog statement at the
[edit system] hierarchy level and the options statement at the [edit
routing-options] hierarchy level.
The results of tracing and logging operations go in files that the router stores in the
/var/log directory. You use the show log file-name command to display the
fo
Tracing Operations
Tracing operations allow you to monitor the operation of routing protocols by decoding
ot
the sent and received routing protocol packets. In many ways, tracing is synonymous
with the debug function on equipment made by other vendors. Note that because of
the design of some hardware-based Juniper Networks platforms, you can enable
N
n
tio
d uc
ro
ep
Syslog Options Example
The example on the slide shows various syslog configurations that result in messages
written to local log files and to a remote host. General syslog configuration options
rR
You can configure support for explicit priority in syslog messages. This configuration
alters the normal syslog message format by adding a numeric priority value. The
explicit priority value can simplify the task of parsing log files for important messages.
N
For example, you can search for all messages at priority 7. The presence of explicit
priority also accommodates the use of tools that designers developed to parse the
logs generated by equipment from other vendors.
Continued on next page.
n
2 critical Critical conditions, such as hard disk errors
tio
consequences than errors in the emergency, alert, and critical
levels
uc
5 notice Conditions that are not errors but might warrant
special handling
d
7 debug Software debugging messages; specify this level only when so
directed by a technical support representative
ro
The following are examples of a syslog message, both with and without an explicit
priority, respectively:
ep
Aug 21 12:36:30 router1 chassisd[522]: %DAEMON-6 CHASSISD_PARSE_COMPLETE:
n
tio
d uc
ro
ep
Process and Miscellaneous Log Files
The primary system log file is the messages file. However, some of the processes that
run under JUNOS Software maintain their own log files named after their respective
rR
process. No requirement exists to configure the router to keep these logs. Note that in
many cases, the software also writes the entries found in these logs to the main
messages file. Key process log files include the following:
• apsd: The automatic protection switching process handles events
relegated to SONET Automatic Protection Switching (APS). View this log
fo
• commits: This log file records the commit activities on the router in the
form of date and time, user, and mode.
• cosd: The class of service process monitors class-of-service events in
the chassis.
Continued on next page.
n
• eccd: The error correction control process deals with memory errors. If
you suspect bad or failing memory, check this log.
tio
• mastership: The mastership log records events related to hardware
redundancy.
• mgdd: The management process controls the CLI process. No log file
associated with this process exists.
uc
• sampled: The sampling process handles tasks related to packet
sampling. Check this log when troubleshooting or monitoring a sampling
configuration.
• snmpd: The SNMP process handles tasks related to SNMP. Check this
d
log when troubleshooting or monitoring SNMP. Note that wherever
possible, the SNMP ifIndex values are persistent across reboots or in
ro
the event of hardware additions and deletions that result from PIC or FPC
insertion and removal. This persistence is the default behavior and is
achieved by storing SNMP indexes in the /var/db/dcd.snmp_ix file.
ep
• vrrpd: The virtual router redundancy protocol (VRRP) process handles
the activities related to this protocol. Check this log when troubleshooting
or monitoring VRRP.
rR
n
tio
d uc
ro
ep
Interpreting System Log Entries
When using the standard syslog format, each log entry written to the messages file
consists of the following fields:
rR
When you add the explicit-priority statement, the syslog message format
alters to include a numeric priority value. In this case the value 0 is for the most
significant and urgent messages (emergency), while 7 denotes debug level messages.
N
Consult the System Log Messages Reference documentation for a full description of
the various message codes and their meanings—better yet, use the CLI’s help
function to obtain this information. The example shows the operator obtaining help on
the meaning of the CHASSISD_IFDEV_DETACH_FPC: ifdev_detach(1)
message code. Based on the output, it becomes relatively clear that the message
code relates to the chassisd processing disconnecting the interfaces associated
with a given FPC, and that this process is considered an event rather than an error.
n
tio
d uc
ro
ep
Hear Tracing and Think Debug
Tracing is the JUNOS Software term for what other vendors sometimes call debug. In
most cases when you enable tracing (through configuration), you create a trace file
rR
that stores decoded protocol information. You analyze these files using standard CLI
log file syntax like show log logfile-name. Because of the design of Juniper
Networks routing platforms, you can enable detailed tracing in a production network
without significantly impacting performance. Even so, you should always remember to
turn tracing off once you complete your testing to avoid unnecessary resource
consumption.
fo
portion of the configuration hierarchy, would result in tracing of the specified routing
protocol’s events. Specified routing protocol tracing operations track the flagged
routing operations and record them in the specified log file.
N
n
maximum size, trace-file.0.gz is renamed trace-file.1.gz,
and trace-file is compressed and renamed trace-file.0.gz.
tio
This renaming scheme continues until it reaches the maximum number
of allowable trace files. The software then overwrites the oldest trace file.
If you do not specify a maximum number of trace files with the files
option, the default number of files to keep is ten. If you specify a
maximum file size, you also must specify a maximum number of trace
uc
files with the files option. You can use xk, xm, or xg to specify
kilobytes, megabytes, or gigabytes, respectively. The default range is
128 KB.
• flag flag: Specifies a tracing operation to perform. You can specify
d
multiple flags.
• files number: Specifies the maximum number of trace files. When a
ro
trace file named trace-file reaches its maximum size, JUNOS
Software renames it trace-file.0, then trace-file.1, and so
forth, until it reaches the maximum number of trace files. The software
ep
then overwrites the oldest trace file. The default is ten files.
Including the traceoptions statement at the [edit interfaces
interface-name] hierarchy level allows you to trace the operations of individual
router interfaces. You can also trace the operations of the interface process, which is
rR
n
tio
d uc
ro
ep
Protocol Tracing
You trace the operations of a specific protocol by including the traceoptions
statement at the [edit protocols protocol-name] hierarchy. In most cases
rR
you should be selective in what you trace because selecting the all keyword can
overwhelm you with endless minutia. The sample OSPF stanza on the slide reflects a
typical tracing configuration that provides details about important events like hello
message or OSPF link-state advertisement (LSA) details. In most cases you should use
the detail switch with a given protocol flag for the added information often needed
in troubleshooting scenarios.
fo
Sample Output
The slide shows a sampling of the results obtained with the tracing configuration. As
ot
with any log file, you simply enter a show file trace-file-name command to
view the decoded protocol entries. The sample trace output reflects the receipt of an
OSPF hello message from 10.222.100.1 and goes on to show some of the hello
protocol parameters.
N
n
tio
d uc
ro
ep
Viewing Logs and Traces
By default, log and trace files are stored in /var/log. To view stored log files, use
the command show log. Recall that the CLI automatically pauses when it has more
rR
than one screen’s worth of information, and that at this more prompt, you can enter a
forward slash (/) character to conduct a forward search. As a hint, enter h when at a
more prompt for a context help screen of available commands:
Jan 7 18:22:40 Parsing config file
---(Help for CLI automore)---
fo
n
codes to display all messages ranging from level 0 (emergency) to level 4 (warning).
Note that searching by message priority requires enabling syslog priority with the
tio
explicit-priority keyword.
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Monitoring Logs and Trace Files
Use the monitor CLI command to view real-time log information. You can monitor
several log files at one time. You can identify the messages from each log by
rR
filename, where filename is the name of the file that displays entries. This line
displays initially and when the CLI switches between log files.
Using Esc+q enables and disables syslog output to screen; using monitor stop
ceases all monitoring. Note that you can use the CLI’s match functionality to monitor a
file in real time, while displaying only entries that match your search criteria. To make
fo
If you do not delete or disable all trace flags, tracing continues in the background, and
the output continues to write to the specified file. The file remains on the Routing
Engine hard disk until it is either deleted manually or overwritten according to the
N
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Troubleshooting Tools: Interactive UNIX Shell
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Interactive Shell Support
Based on a FreeBSD operating system, the JUNOS Software CLI supports an escape to
a UNIX shell. While the possibilities can seem endless, we stress that designers highly
rR
customized JUNOS Software, and did not design it to act as a Web server or as some
type of UNIX device. You can do serious damage to the Juniper Networks platform if
you do not observe great care and caution when operating in a shell. Access to an
interactive shell is controllable through login class permissions. Once at a shell, you
can su to root, if you know the root password, or if you have not set it.
fo
Juniper Networks does not officially support use of the shell because the CLI offers all
that you should need in normal circumstances. For advanced troubleshooting
activities, or for advanced functionality like automated shell scripts (for which Juniper
Networks support is not expected or sought), the shell can be a real boon.
Users who wish to add production scripting functionality to their networks should
ot
consider operational scripts, commit scripts, and event scripts. The coverage of these
scripts is outside of the scope of this course.
Continued on next page.
N
n
kernel parameters like TCP window sizes, the number of available
protocol sockets, and so forth; and
tio
• Establish a connection to the embedded hosts (controllers) within the
PFE complex to access diagnostic and log data held in NVRAM.
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Interactive Shell Case Study: tcpdump
The slide shows how writing monitored traffic to a file allows the use of protocol
filtering and standard protocol analysis tools like tcpdump. Note that in real-time
rR
mode, protocol filtering does not function because the Layer 2 headers are stripped in
hardware before the monitoring of traffic occurs. To work around this problem, JUNOS
Software writes pseudo-Layer 2 headers when writing monitored traffic to a file. The
presence of these headers accommodates protocol filtering actions.
On the slide, we start by issuing a monitor traffic interface se-1/0/0
fo
command using the hidden write-file switch and a target file name of
dump-file. Note that the write-file switch is hidden because failing to stop the
traffic monitoring could result in the /var file system becoming full. While this
condition should not crash the router, it impacts the router’s ability to conduct
on-going logging and tracing activities.
ot
After the traffic monitoring ceases, we escape to a UNIX shell and invoke tcpdump
with the –r switch to tell it to read the contents of the named file.
Continued on next page.
N
n
19:00:22.938474 Out IP 10.0.13.1 > 224.0.0.5: OSPFv2, Hello, length: 48
. . .
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
What Is Listening on TCP Port 6154?
In some cases, you must determine exactly what process has opened a TCP or UDP
port to listen for connections. Such an event might stem from a curious operator who
rR
By escaping to a shell and using the standard BSD netstat and fstat commands,
you can determine what process is listening on a given port using the steps outlined
on the slide. You begin by issuing a netstat –Aa command that displays all
listening and connected sockets (the –a switch), along with the related protocol
control block (PCB) information (the –A switch). In this example, the grep utility saves
ot
some parsing work by matching only lines containing the value 6154. The result of this
command is the PCB information needed for the subsequent fstat command. Once
again, grep matches only the lines of interest.
N
The output of the fstat command makes it clear that the culprit is the fwdd
process, which is the packet forwarding engine forwarding process.
n
tio
d uc
ro
ep
Connecting to PFE Components
You can use the internal connectivity between the RE and PFE, along with the Trivial
Network Protocol (TNP), to establish connections to embedded hosts (controllers)
rR
within the PFE complex. The term embedded host refers to a PFE component with its
own microprocessor and microkernel. Examples include system Control Boards and
FPCs.
In most cases, the only reason to connect to a PFE component is to access diagnostic
information in the form of log entries or core files retained in the affected component's
fo
NVRAM. On most platforms you use virtual terminal (vty) connectivity over an
Ethernet communications channel. The use of vty requires that you specify the
correct tnp address. Some platforms also support console (asynchronous) access
using a serial type of connection known as a cty.
By parsing entries in the syslog, you can determine what PFE component has reported
ot
a crash, and therefore to which embedded host you must connect to obtain crash and
log data for submission to JTAC.
Continued on next page.
N
n
fpc2 Connect to Flexible PIC Concentrator 2
fpc3 Connect to Flexible PIC Concentrator 3
tio
fpc4 Connect to Flexible PIC Concentrator 4
fpc5 Connect to Flexible PIC Concentrator 5
fpc6 Connect to Flexible PIC Concentrator 6
fpc7 Connect to Flexible PIC Concentrator 7
user@host> start shell pfe network fpc1
uc
Older Versions of Software
If you are running older versions of JUNOS Software, whether connecting by vty or
d
cty, you might need to be at a root shell prompt to forge a connection from the RE to
a PFE component. When using a vty connection, you should first issue the show
tnp addresses CLI command so that you know which address to specify. You can
ro
also use the tnpdump command, which is an alias to the show tnp addresses
command at the shell prompt.
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Shell Case Study: Display NVRAM
The example on the slide begins by issuing the show tnp addresses command to
obtain the list of tnp endpoints for the platform in question (an M10i router). In this
rR
example the goal is to connect to the M10i router’s CFEB, which is currently using tnp
address 2.
Armed with the knowledge of the CFEB’s tnp address, we escape to a shell and issue
an su to the root so as to execute a vty 2 command. The slide shows that the
connection is successful by virtue of receiving the login banner from the CFEB. Once
fo
n
tio
d uc
ro
ep
Troubleshooting Tools: Core Files for Diagnostic Analysis
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Complexity of Modern Computers and Operating Systems
The complexity of modern computers and operating systems leads to equally complex
bugs! It is very difficult to diagnose transient software failures (for example, a random
rR
crash or reboot), because so many potential causes for these types of faults exist. In
most cases, a crash is the result of a programming error or the failure to anticipate a
particular set of events and the software interaction that ensues. However, a crash
can also stem from hardware-related causes. In the latter case, a memory error might
corrupt a memory pointer or result in an illegal instruction.
fo
result of this analysis is generally a very good idea of the sequence of events that led
to the crash, and armed with this information, you can take corrective actions. For
example, you can perform a software patch or hardware Return Materials
Authorization (RMA).
N
While it might sound bad, it is actually quite beneficial that JUNOS Software has the
ability to dump various types of core files for diagnostic use. In most cases, core files
generate automatically as a result of a failure, but you can also generate cores on
demand. JUNOS Software can generate core files relating to the JUNOS Software
kernel itself, to the processes that run above that kernel, or to the embedded host
modules within the PFE.
n
tio
d uc
ro
ep
Core Files Are Critical
Today’s internetworking software is exceedingly complex. As a result, equally complex
bugs that result from unforeseen circumstances can result in a fatal error within a
rR
software process. Most of these software faults relate to illegal memory operations
caused by the process attempting to read or write data from a memory area outside
the boundaries allocated for that process. In some cases, faulty hardware, such as
failing memory, can cause stack or register corruption, which leads to a fatal error in a
software process. You can use core and log file analysis to determine if hardware
errors have led to software problems.
fo
In a monolithic operating system, such a fault results in a crash of the entire operating
system. In contrast, the protected memory environment of JUNOS Software ensures
that faulty processes do not affect other aspects of the operating system.
Even so, it can be very difficult to diagnose the exact set of events that lead up to a
ot
process crash without a core file for forensic analysis. A core file represents the set of
memory locations and stack data that was in place at the time of the fault. A software
engineer then runs a copy of the binary image that left the core file (with debug
N
symbols included) against the actual core file using a debugger to enable problem
diagnosis.
Continued on next page.
n
management or automatic protection switching processes (chassid or
apsd), is capable of leaving a core when a panic occurs.
tio
• PFE cores: Various components in the PFE contain their own
microprocessors that run a microkernel. Examples include the CFEB on
M7i and M10i platforms, FPCs, the Forwarding Engine Boards (FEB) on
the M120, and others. Each of the PFE’s embedded hosts is capable of
uc
dumping a core file when a crash (panic) occurs.
d
Depending upon the JUNOS Software version, you might need to explicitly configure
core file storage. When enabled, the process that generates the core determines the
actual location of a core file.
ro
Core files created by a kernel panic are stored in the /var/crash location when you
enable the system dump-on-panic option (hidden) at the [edit system]
hierarchy. The software enables this option by default.
ep
Core files generated by a process are stored in the /var/tmp directory. This behavior
is the default in all JUNOS Software releases.
When a PFE component dumps a core, the resulting stack trace writes into that
component's NVRAM. If you enable chassis dump-on-panic (hidden) at the
rR
[edit chassis] hierarchy, a copy of the core is also stored in the /var/crash
directory on the RE. We recommend this option, and it is the default.
You can use the CLI command show system core-dumps to quickly determine if
any core files are stored on the RE.
fo
ot
N
n
tio
d uc
ro
ep
Forcing Process Cores
In certain rare situations, a software engineer might want to obtain a core file from a
process that appears to be running normally. Note that forcing software processes to
rR
write cores might impact system, performance, and operation. Only perform these
steps under the guidance of JTAC.
Two Methods
fo
In most cases, you obtain a running core file by using the hidden request system
core-dump process-name CLI command. By default, this process forks off a copy
of the running process (a running core), which has the upside of leaving the original
process free to do its process duties. The downside is that if the process in question is
large (for example, rpd) it might tax system memory, because the system must
ot
support two instances of that process. A system that is low on memory begins paging
to the swap file, and this procedure can slow things down to the extent that keepalives
are lost or rpd scheduler slips begin to occur. For the routing process (rpd), you can
specify whether a fatal (the process is stopped and then restarted) or running core
N
should be generated. For most processes, a running core is the only option. Note that
either type of core can be disruptive, and that a running core does not generate a .tar
archive with context.
Continued on next page.
n
The slide shows an example of the recommended gcore syntax. The –s argument
tells gcore to suspend the process during the dump. You must also specify the full
path and binary name of the processes, as well as the PID of the currently running
tio
processes.
You can use the which command to obtain the path of a process, and the output of a
ps ax command to obtain the PID associated with that process. You should change
into the /var/tmp directory before running gcore because it writes the core file to
uc
the current working directory by default. Note that using gcore from a root shell never
produces a .tar archive with context information.
The following output shows an operator using gcore to obtain an rpd core:
d
root@host% cd /var/tmp
root@host% ls *core*
ls: No match.
root@host% which rpd
/usr/sbin/rpd
ro
root@host% ps ax | grep rpd
ep
2275 ?? S 0:09.08 /usr/sbin/rpd -N
2280 ?? I 0:00.40 /usr/sbin/vrrpd -N
root@host% gcore -s /usr/sbin/rpd 2275
root@host% ls *core*
core.2275
rR
The procedures outlined on these pages are for the generation of core files from
processes only. The forcing of a JUNOS Software kernel core is beyond the scope of
this class because it requires that you enter complex sysctl syntax at a root shell.
You can issue a write coredump command when connected to an embedded host
to force a PFE component to write a core file, as shown in the case of an M10i router’s
fo
CSBR platform (266Mhz PPC 603e processor, 256MB memory, 512KB flash)
n
CSBR0(host vty)# [Jan 23 18:32:58.005 LOG: Info] Coredump finished!
tio
CSBR0(host vty)# exit
uc
root@host% ls -l /var/crash
total 507780
-rw-r--r-- 1 root wheel 259885052 Jan 23 18:32 core-CSBR0.core.0
-rw-rw-r-- 1 root wheel 5 Sep 9 2004 minfree
root@host%
d
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Transferring Core Files to Juniper Networks
You should always submit core files to JTAC for fault analysis. The following are the
recommended procedures for transferring core files to JTAC:
rR
n
confirm the current transfer setting and use the image or binary
command to enable binary transfer mode as needed. Enabling
tio
hash-mark printing provides transfer progress indication.
9. Upload the file using a put or mput command.
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Troubleshooting Tools: The JTAC Knowledge Base
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
The JTAC Knowledge Base and Problem Report Search Tools
Customers with support contracts can access the JTAC Knowledge Base and Problem
Report search tool to assist themselves in problem diagnosis. The graphic on the slide
rR
shows the current Customer Support Center (CSC) welcome page that greets the user.
The Knowledge Base contains various entries on technology, troubleshooting, and
recommended procedures. The Problem Report database, on the other hand,
contains a listing of known bugs along with their status and any known workarounds.
fo
ot
N
n
tio
d uc
ro
ep
JTAC Knowledge Base Case Study: Part 1
The next set of pages illustrates how the JTAC Knowledge Base and the Problem
Report search tool can help you find your own answers. The stage is set with the
rR
rather common question of “just how hot is too hot for a typical J Series platform?”
The slide shows a user just about to search the Knowledge Base for the keywords
temperature threshold.
fo
ot
N
n
tio
d uc
ro
ep
JTAC Knowledge Base Case Study: Part 2
The slide shows a portion of the results returned from the Knowledge Base search.
The highlights suggest that ID number 1971 is quite promising in that it seems to deal
rR
n
tio
d uc
ro
ep
JTAC Knowledge Base Case Study: Part 3
The contents of ID number 1971 are helpful, and with your newfound wisdom, you are
well on your way to J Series Guru status.
rR
Note that you can provide feedback to the maintainers of the CSC to indicate whether
particular entries were helpful to you.
fo
ot
N
n
tio
d uc
ro
ep
Best-Practices Case Study
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Deploying an Out-of-Band Management Network
Relying on in-band methods to manage your network might seem like a good idea up
until the point that a circuit or hardware outage prevents you from accessing your
rR
interface. Put another way, if a packet arrives on fxp0 it can never egress on a PFE
interface, and vice versa. Because of this behavior, we do not recommend running a
routing protocol over the fpx0 interface in most cases. Instead, we recommend a
static route flagged with no-readvertise. This flag ensures that the static route
used for out-of-band connectivity does not advertise over any routing protocol.
ot
because of thrashing.
Continued on next page.
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Recommended System Log Settings
Wherever possible, you should place the following system logging recommendation
into effect:
rR
• Log CLI commands and configuration changes: We have all seen the joke
about what to do if you break something while no one is watching—just
walk away. While this advice is perhaps sound, it is futile when the
system configuration logs interactive CLI commands. When combined
N
with unique user logins, the logging of all commands issued on the
machine provides an excellent audit trail of who did what, and when.
n
tio
d uc
ro
ep
Synchronize Router Clock
We recommend using the Network Time Protocol (NTP) to synchronize all routers to a
common, and preferably accurate, time source. By synchronizing all routers, you
rR
ensure that time stamps on log messages are both accurate and meaningful, which is
especially important when conducting security-related forensics where you must
correlate events that might have occurred on numerous machines.
The basis for the NTP protocol is a series of timing hierarchies, with a Stratum 1
(atomic) timing source at the very top. While accuracy is desirable, you do not need to
synchronize to Stratum 1 reference to benefit from having synchronized views as to
the time of day. JUNOS Software cannot provide its own timing source because it does
ot
not support the definition of a local, undisciplined clock source (for example, the local
crystal oscillator). If needed, you can always obtain a commodity UNIX device of some
type with a configuration that provides a timing reference based on its local clock.
Again, remember that any synchronization, even if based on an inaccurate local clock,
N
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Enable Core Dumps
Based on feedback from JTAC, system and chassis dump-on-panic is now enabled
by default. Depending upon the JUNOS Software version, you might need to use
rR
hidden configuration commands to enable core dumps. Note that a change in chassis
dump status normally requires a reboot of the PFE before placing the settings into
effect. You can place the change into effect immediately by issuing a set coredump
enable command on each PFE component that contains an embedded host. The
chassis dump-on-panic statement enables core dumps on all PFE components
(at reboot).
fo
n
tio
d uc
ro
ep
Confirming Dump Settings
Because core dumps are so critical when dealing with transient software failures, it is
worthwhile to confirm the current settings for both system and chassis dumps.
rR
Waiting until after a crash to find out that you needed a reboot to enable a PFE core
file is no way to begin the day.
The first code example shows the operator using the shell to obtain kernel parameters
via the sysctl command. The output pipes to grep with the match criteria of
coredump. In this example it is clear that we enabled kernel core dumps.
fo
n
tio
d uc
ro
ep
Best-Practices Case Study: Part 1
This sequence of slides illustrates a basic configuration that reflects the current
best-practices recommendations made by JTAC. Can you provide insight as to how the
rR
various configuration stanzas can help you when performing fault analysis?
fo
ot
N
n
tio
d uc
ro
ep
Best-Practices Case Study: Part 2
The slide continues the case study started on the previous page.
rR
fo
ot
N
n
tio
d uc
ro
ep
This Chapter Discussed:
• Warnings and caveats regarding potentially disruptive commands and
techniques;
rR
n
tio
d uc
ro
ep
Review Questions
1.
rR
2.
3.
fo
4.
ot
N
n
tio
d uc
ro
ep
Lab 1: JUNOS Troubleshooting Tools
The slide shows the objective for this lab.
rR
fo
ot
N
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
Chapter 4: JUNOS Platforms Hardware
Troubleshooting
d uc
ro
ep
rR
fo
ot
N
Troubleshooting JUNOS Platforms
n
tio
d uc
ro
ep
This Chapter Discusses:
• An overview of hardware troubleshooting tools;
• Power on, power off, and boot media options;
rR
n
tio
d uc
ro
ep
Hardware Troubleshooting Overview
The slide lists the topics we cover in this chapter. We discuss the highlighted topic
first.
rR
fo
ot
N
n
tio
d uc
ro
ep
Troubleshoot Using the Craft Interface
You can use the Craft Interface to troubleshoot chassis problems. Some Juniper
Networks platforms use LEDs on the Craft Interface to indicate the status of various
rR
chassis components. The M40e, M320, T320, T640, and TX Matrix platforms use the
LCD to display general system status and a listing of any alarms that are currently
active.
The various system logs maintained by JUNOS Software and the various processes
that run on top of the JUNOS kernel contain a wealth of information regarding the
operational status of a given system. The information stored in system logs is normally
more detailed than that displayed on the Craft Interface. Do not forget to leverage the
CLI pipe function to simplify the task of parsing through large log files for symptoms of
abnormal operation or hardware failure.
n
tio
d uc
ro
ep
Power On, Power Off, and Boot Media
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Powering On JUNOS Platforms
Each device can be equipped with two redundant, load-sharing power supplies of the
same type, either AC or DC. Be sure to connect each power source properly. For
rR
example, each power supply requires a dedicated power source. For sites with an AC
power source, each power supply has one power cord, which plugs into a grounded
100–240 VAC power receptacle. For sites with a DC power source, power is normally
carried around the site through a main conduit to frame-mounted DC power
distribution panels, one of which might be located at the top of the rack where you
intend to install the device. A pair of cables (–48 V and RTN) connects each DC supply
fo
to the power distribution panel. Grounding studs are provided at the rear enclosure.
After connecting all cables, turn one power supply on first and then the second supply
to avoid a large power spike.
Although the specifics of each power supply and Power Entry Module (PEM) vary by
ot
platform, note that after a power supply is powered on, it can take up to 60 seconds
for status indicators—such as LEDs on the power supply and show chassis
commands—to indicate that the power supply is functioning normally. You should
ignore error indicators that appear during the first 60 seconds.
N
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Hardware Controls the Boot Sequence
At power on, as the device begins the boot process, it first attempts to start the image
of software from the removable media if it is installed in the Routing Engine. If this
rR
attempt fails or if no media is present, the device next tries to boot from the image of
software on the flash disk and then finally from the hard disk.
This sequence is controlled by hardware that waits for a special signal from the JUNOS
Software kernel, indicating a successful boot. If the hardware does not receive the
signal after a few minutes, it forces the system to boot from the next available device
fo
n
tio
d uc
ro
ep
Three Forms of Boot and Storage Media
JUNOS platforms generally support three forms of boot and storage media:
• Removable media: Depending on the platform model, your device might
rR
A JUNOS platform typically boots either from the flash disk or from the hard disk.
(While it is possible to boot the device from the removable media disk, you typically do
not do so.) We refer to these disks as the boot media. The disk from which the device
N
boots is named the primary boot medium, and other disks are secondary boot media.
Depending on the platform, the primary boot medium is generally the flash disk, and
the secondary boot medium is generally the hard disk.
Continued on next page.
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Choose the Boot Device at Boot Time
At times you might want to manually choose to boot from alternative media even
though the flash file system is bootable. You can tell the system to boot from a given
rR
of a software fault in the flash file system (a fault that leaves the flash medium
bootable but unusable from a JUNOS Software CLI perspective).
To select an alternative medium at the time of boot, watch for the boot loader screen
shown on the slide. When prompted, enter a space to access the boot loader
command prompt. From the prompt you can get some help with the ? key. As indicated
ot
in the initial help screen, typing reboot causes the device to reboot from the next
device on the boot list. This device should be the hard disk because the flash disk is
normally the first boot device. When needed, you can manually select the device to
N
use when the reboot command executes by first using the nextboot command
with the desired medium type specified as an argument.
n
tio
d uc
ro
ep
Craft Interface Liquid Crystal Display
As supported JUNOS platforms boot, the current status of the boot process displays on
the Craft Interface LCD.
rR
after conclusion of the testing period. Depending upon the platform, the Craft
Interface might also support LEDs for host module (Routing Engine and Control Board
combination) or Switch Interface Board (SIB) status.
ot
on the Craft Interface (when present) or use the command show chassis
alarms.
n
tio
d uc
ro
ep
Power Supply and Power Entry Module LEDs
Depending upon the platform and power supply model, one or more status LEDs on
each power supply or Power Entry Module (PEM) might exist that you can use to
rR
determine if a power supply is functioning normally. Note that for some platforms you
must wait at least 60 seconds after applying power to a power supply before you can
expect to see meaningful status indications. The self-test button present on some
power supplies should never be used on a production system; this button is for
engineering and Juniper Networks Technical Assistance Center (JTAC) use only.
fo
ot
N
n
tio
d uc
ro
ep
Using the CLI to Troubleshoot
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Displaying Chassis Inventory
The output of the show chassis hardware command displays the hardware
components installed in the platform. This command is useful when troubleshooting
rR
or upgrading your device. The (edited) sample shown on the slide is from a T640
router with redundant Routing Engines (RE).
The following are the show chassis hardware command output fields:
• Item: Shows information for the chassis component about the
backplane, the power supplies, the maxicab (the connection between the
fo
Routing Engine and the backplane), the System Control Board (SCB), and
each of the FPCs and their PICs.
• Version: Displays the revision level of the chassis component.
• Part number: Displays the part number of the chassis component.
ot
• Description: For the power supplies, it displays the type of supply; for
the PICs, it displays the type of PIC.
Continued on next page.
n
Item Version Part number CLEI code FRU model number
Midplane REV 07 710-009120 CHAS-BP-M320-S
tio
FPM Display REV 05 710-009351 CRAFT-M320-S
CIP REV 05 710-005926 CIP-M320-S
PEM 0 Rev 05 740-009149 PWR-M-AC-S
PEM 1 Rev 05 740-009149 PWR-M-AC-S
PEM 2 Rev 05 740-009149 PWR-M-AC-S
uc
PEM 3 Rev 05 740-009149 PWR-M-AC-S
Routing Engine 0 REV 07 740-014082 RE-A-2000-4096-S
Routing Engine 1 REV 07 740-014082 RE-A-2000-4096-S
. . .
d
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Listing Alarm Conditions
The show chassis alarms command lists all of the alarm conditions that
currently exist in the device. You can disable some alarms; however, you cannot
rR
major); and
• Description: Displays information about the alarm.
N
n
tio
d uc
ro
ep
Displaying Environmental Information
The show chassis environment command displays environmental information
about the device chassis, including the temperature, and information about the fans,
rR
power supplies, and Routing Engine. The truncated example is from a T640 platform.
The following are the output fields:
• Power: Displays information about each power supply. The status can be
OK, Testing (during initial power-on), Failed, or Absent. For the
M120, M320, and T Series platforms, information displays about the
fo
PEM.
• Temp: Displays the temperature of air flowing through the chassis.
• Fans: Displays information about the fans. The status can be OK,
Testing (during initial power-on), Failed, or Absent. Measurement
ot
n
tio
d uc
ro
ep
CPU Temperature
In addition to the ambient temperature surrounding the system components, you can
see the actual CPU temperature of the Routing Engine.
rR
fo
ot
N
n
tio
d uc
ro
ep
Displaying Craft Interface
The show chassis craft-interface command shows all current messages.
The capture shown is from a T640. Output fields include the following:
rR
• Front Panel System LEDs: Displays the status of the Front Panel
System LEDs. A dot (.) indicates the LED is not lit. An asterisk (*)
indicates that the LED is lit.
N
n
the LED is lit. When neither a dot nor an asterisk displays, no board is
present in that slot.
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Displaying System Control Board Status
The show chassis (feb | scb | | cfeb | sfm slot | ssb slot )
command displays information about the system controller boards—either Forwarding
rR
Engine Board (FEB), Compact Forwarding Engine Board (CFEB), SCB, SFM, or System
and Switch Board (SSB). The following are the output fields:
• Intake temperature: Displays the temperature of the air passing by
the controller in both Celsius and Fahrenheit;
• Exhaust temperature: Displays the temperature of the air flowing
fo
n
Engine (PFE)-generated ICMP error messages or traffic that requires direction to the
host RE for processing. Examples of exception traffic include Internet Control Message
tio
Protocol (ICMP) echo exchanged packets with expired time to live (TTL), which is one of
the IP options, or traffic that is sampled or counted (or both) as part of a firewall filter.
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Displaying FPC Status
The show chassis fpc command displays the status of the installed FPCs. The
sample is from a T640 platform. The following are the output fields:
rR
interrupts.
• Memory DRAM: Displays the total DRAM (in megabytes) available to the
FPC’s processor.
N
n
tio
d uc
ro
ep
Displaying the Status of a Specific FPC
The show chassis fpc detail command shows detailed information about the
FPCs installed in the system. Adding an FPC number, as in the example on the slide,
rR
limits the output to the specified FPC. The sample output fields are as follows:
• State: Displays the state of the FPC slot:
– Dead: Indicates that the slot is held in reset because of errors.
– Diag: Indicates that the slot is being ignored while the FPC is
fo
running diagnostics.
– Dormant: Indicates that the slot is held in reset.
– Empty: Indicates that no FPC is present.
– Online: Indicates that the FPC is online and running.
ot
– Present: Indicates that the chassis process detects the FPC but
it is either not supported by the current version of JUNOS Software
or it is in the wrong slot. The output also states either Hardware
N
n
• Total SRAM: Displays the amount of SRAM in use by the FPC’s CPU.
• Total SDRAM: Displays the total amount of memory used for storing
tio
packets and notifications.
Please note that depending on the platform, the output field details might vary.
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Displaying PIC Status
The show chassis fpc pic-status command displays information for all PICs.
The following are the output fields:
rR
• State: Indicates the state of the FPC slot, which can be one of the
following:
– Dead: Indicates that the FPC is held in reset because of errors.
– Diag: Indicates that the slot is being ignored while the FPC runs
fo
diagnostics.
– Dormant: Indicates that the slot is held in reset.
– Empty: Indicates that no FPC is present.
– Online: Indicates that the FPC is online and running.
ot
– Present: Indicates that the chassis process detects the FPC but
it is either not supported by the current version of JUNOS Software
or it is in the wrong slot. The output also states either Hardware
N
n
fpc_slot_number pic-slot pic_slot_number command.
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Displaying Routing Engine Status
The show chassis routing-engine command displays information about the
Routing Engine. The following are the output fields:
rR
• Slot: Indicates the slot number for the RE on systems that support RE
redundancy;
• Current state: Indicates the current state of the RE on systems that
support RE redundancy;
fo
processes;
– Background: Displays the percentage of CPU time in use by
background processes;
– Kernel: Displays the percentage of CPU time in use by kernel
processes;
Continued on next page.
n
• Start time: Displays the time at which the Routing Engine started
running;
tio
• Uptime: Displays how long the Routing Engine has been running;
• Last reboot reason: Provides a reason for the last reboot; and
• Load averages: Displays the Routing Engine load averages for the
uc
last 1, 5, and 15 minutes.
For systems with redundant REs installed, you can specify the RE slot number or see
information about all REs installed in the system, as in the following example taken
from an M320 platform:
d
user@host> show chassis routing-engine
Routing Engine status: ro
Slot 0:
Current state Master
Election priority Master (default)
Temperature 44 degrees C / 111 degrees F
ep
CPU temperature 51 degrees C / 123 degrees F
DRAM 3584 MB
Memory utilization 11 percent
CPU utilization:
rR
User 0 percent
Background 0 percent
Kernel 3 percent
Interrupt 0 percent
Idle 97 percent
Model RE-A-2000
fo
Serial ID 1000702757
Start time 2009-02-06 07:56:24 PST
Uptime 11 days, 1 hour, 20 minutes, 36 seconds
Last reboot reason Router rebooted after a normal shutdown.
Load averages: 1 minute 5 minute 15 minute
ot
n
CPU utilization:
User 47 percent
tio
Background 0 percent
Kernel 24 percent
Interrupt 1 percent
Idle 29 percent
uc
Model RE-A-2000
Serial ID 1000699981
Start time 2008-12-30 16:07:53 PST
Uptime 48 days, 17 hours, 9 minutes, 2 seconds
Last reboot reason 0x1:power cycle/failure
d
Use the show chassis routing-engine bios command to display the
revision level of the RE’s BIOS:
ro
user@host> show chassis routing-engine bios
Routing Engine BIOS Version: 1.5
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Displaying PFE Errors
The show pfe statistics error command displays information about errors
that might occur within the PFE’s application-specific integrated circuits (ASIC) or
rR
internal communications paths. To clear PFE statistics, use the CLI’s hidden clear
pfe statistics command.
The slide provides a sample display for error statistics taken from an M10i platform.
The key reason for issuing the show pfe statistics error command is to
determine if a system has a chronic error condition versus a transient burst of errors,
fo
as might be caused by incorrect FPC removal. Put another way, PFE errors are
primarily of concern when you observe the error counts to be incrementing when the
system is in an otherwise stable state (for example, you are not removing or inserting
any FRUs.
ot
N
n
tio
d uc
ro
ep
Restarting Hardware Components
You can restart or take an FPC online and offline from the CLI with a request
chassis fpc slot-number [restart | online | offline] command.
rR
n
5 Empty
6 Empty
tio
7 Empty
uc
Slot State (C) Total Interrupt DRAM (MB) Heap Buffer
0 Present 39
1 Online 37 1 0 1024 2 49
2 Online 38 1 0 1024 2 49
3 Online 40 1 0 1024 2 49
d
4 Online 39 1 0 1024 2 49
5 Empty
6 Empty
7 Empty
ro
user@host> show chassis fpc
ep
Temp CPU Utilization (%) Memory Utilization (%)
Slot State (C) Total Interrupt DRAM (MB) Heap Buffer
0 Online 37 0 0 0 0 0
1 Online 37 1 0 1024 2 49
2 Online 38 1 0 1024 2 49
rR
3 Online 40 1 0 1024 2 49
4 Online 39 1 0 1024 2 49
5 Empty
6 Empty
7 Empty
fo
ot
N
n
tio
d uc
ro
ep
Viewing Boot Messages
The slide shows an example of an operator displaying the contents of the boot log by
issuing a show system boot-messages command. JUNOS Software writes this
rR
file during the system boot, and the file contains the various boot-up messages
generated during the last power cycle and boot or reboot.
In some cases, JUNOS Software reports hardware errors and device malfunctions at
boot time. The truncated capture on the slide does not show any abnormal events.
fo
ot
N
n
tio
d uc
ro
ep
Displaying System Storage
The show system storage command displays the amount of storage available on
the flash and rotating disks. This command displays statistics about the amount of
rR
free disk space in the various file systems used by the device. Values display in
512 byte blocks. This command is equivalent to the UNIX df command.
The highlights on the slide indicate the device names used by the flash and rotating
storage devices. In this case, the flash medium is device ad0s1a, while the hard disk
is device ad2s1f. You can also see that JUNOS Software makes use of FreeBSD’s
fo
virtual file system support to mount images of jbundle components on memory virtual
disks. These RAM disk devices always indicate being 100% full because of their
read-only nature.
Continued on next page.
ot
N
n
• s1 = Slice 1 for PC BIOS partition 1.
tio
• a = The root (/) partition. A b partition type is for swap space, while a
c partition type is used in dedicated mode (native BSD slice mode).
Other partition types are for general use, such as the e designation for
the /config partition.
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Displaying Uptime
The show system uptime command displays the current time and information
about how long the device, its software, and routing protocols have been running. The
rR
• Protocols started: Displays the date and time when the routing
protocols last started and how long they have been running;
• Last configured: Displays the date and time a configuration last
activated (either by booting the device or issuing the commit command
in configuration mode);
ot
• user: Displays the number of users logged into the device; and
• load averages: Displays the load averages for the last 1 minute, 5
minutes, and 15 minutes.
Continued on next page.
Display Users
The show system users command displays the currently logged in users, and
displays what they are doing. The example on the slide shows that the root user is
logged in at a c-shell while the lab user is in the CLI. Knowing that folks are actively
logged into the device might factor in to a decision to perform disruptive actions like
software upgrades. Note that the terminal name for a console port begins with d,
while virtual terminal (vty) ports, such as result from Telnet or SSH connections, use
p-style tty connections. This information is helpful when the goal is to disconnect a
user with the request system logout user command because you must specify
n
both the user name and the related terminal port, unless you use the all keyword.
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Parsing System Logs
The slide shows examples of how you can use the CLI to rapidly locate signs of trouble
within a given log file. The syslog samples shown on the slide come from the
rR
messages file. The samples illustrate how you can use the CLI match function,
which allows you to easily and effectively parse the system log files.
fo
ot
N
n
tio
d uc
ro
ep
Case Study
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Hardware Troubleshooting Flow Chart
Troubleshooting is an artfully applied science. The intent of this statement is to
highlight that even though many aspects of fault isolation have a basis in
rR
straightforward facts and physics, a certain degree of artistic license that determines
how a particular technician decides to approach a problem always remains. Put
another way, two individuals working with the same sets of tools and a common
symptom might approach the act of fault analysis in completely different ways. For
example, one person might always start with visual inspection while another opts to
begin with interface loopback tests. In the end, it is hard to say that one approach is
fo
better than another, assuming that both individuals arrive at a similar conclusion, in a
similar amount of time, with similar levels of minimal disruption.
The determination that troubleshooting is a mix of science and artwork is important
because most agree that art is a subjective concept that must come from within the
ot
artist; although artistic skills and concepts can be taught, the receipt of such
edification does not imply the student will actually create master artworks.
Continued on next page.
N
n
command, while the sample chart calls out the terse and detail switches).
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Hardware Case Study A: Part 1
The slide sets the stage for a sample hardware troubleshooting case study. We begin
with the general description of the problem, which in this case indicates that you see
rR
high speed link (HSL) errors as reported in the system log file. The HSL interconnects
the FPC, the PFE, the SIB, and the midplane of the M320 router. In addition to HSL
error messages, SIB 3 goes offline and becomes unusable for forwarding the traffic. In
fact, for a short time, all FPCs that are still trying to use SIB 3 to send traffic through
the switch fabric generate destination errors as illustrated on the slide.
fo
ot
N
n
tio
d uc
ro
ep
Hardware Case Study A: Part 2
Faulty hardware components can cause HSL errors either on the FPC, the midplane,
or the SIB. Therefore, following the methodology of troubleshooting, you can eliminate
rR
n
tio
d uc
ro
ep
Hardware Case Study A: Part 3
To find the defective hardware, you decide to identify the SIB and the FPC that
interconnect with the faulty HSL. The show chassis fabric topology
rR
command illustrates that the faulty HSL interconnects FPC2 with SIB3. Next you
decide to replace the SIB and bring it online. If the new SIB comes online without HSL
errors, then you found the cause of the problem—the previous SIB in slot 3 was faulty.
If the error persists, follow step 4 on the following slide.
fo
ot
N
n
tio
d uc
ro
ep
Hardware Case Study A: Part 4
Now you must check the FPC. Specifically, you replace the FPC and bring it online.
Once you bring the new FPC online, you check for HSL errors. If the new FPC comes
rR
online without HSL errors, then the cause of the problem was the faulty FPC and you
solved the problem. Otherwise, you must replace the midplane. Finally, the problem
should be solved.
fo
ot
N
n
tio
d uc
ro
ep
Hardware Case Study B: Part 1
The slide sets the stage for another sample hardware troubleshooting case study. You
replaced the PIC in slot 2 within FPC 4 in an M320 router. Now you want to obtain the
rR
new PIC’s serial number. You are aware of the CLI show chassis hardware
command that lists serial numbers for all the hardware components of the router.
However, when you issue the command, you do not see the new PIC’s serial number.
How else can you obtain the new PIC’s serial number?
fo
ot
N
n
tio
d uc
ro
ep
Hardware Case Study B: Part 2
First try a search for the necessary information in the technical documentation.
Remember the use of the Ctrl+click to select multiple products to search—this
rR
technique is useful if you become overwhelmed with results from a wide-open search
but are still not exactly sure in which category your result will appear.
If you do not find the information, remember to search the JTAC Knowledge Base. The
slide illustrates the result of a Knowledge Base search.
fo
ot
N
n
tio
d uc
ro
ep
Hardware Case Study B: Part 3
Browsing through the Knowledge Base, you locate useful information in KB11755.
Once you read the details of that Knowledge Base entry, you realize that it reflects
rR
your situation and provides you with instructions on how to find the newly installed
PIC’s serial number.
fo
ot
N
n
tio
d uc
ro
ep
Hardware Case Study B: Part 4
Following the directions from the Knowledge Base, you use the show log
inventory command. To locate the information faster, you narrow down the
rR
displayed information to the installation date of the new PIC—June 3. The output of the
command provides the information you need.
fo
ot
N
n
tio
d uc
ro
ep
This Chapter Discussed:
• An overview of hardware troubleshooting tools;
• Power on, power off, and boot media options;
rR
n
tio
d uc
ro
ep
Review Questions
1.
rR
2.
3.
fo
4.
ot
N
n
tio
d uc
ro
ep
Lab 2: Chassis Hardware Troubleshooting
The slide lists the objective of this lab.
rR
fo
ot
N
n
tio
Chapter 5: Interface Troubleshooting
d uc
ro
ep
rR
fo
ot
N
Troubleshooting JUNOS Platforms
n
tio
d uc
ro
ep
This Chapter Discusses:
• Physical and logical interface properties;
• Deactivating and disabling interfaces;
rR
• Configuring loopbacks and the bit error rate test (BERT); and
• Using operational mode commands to monitor and troubleshoot a variety
of interfaces and media types.
fo
ot
N
n
tio
d uc
ro
ep
Interface Configuration Overview
The slide lists the topics we cover in this chapter. We discuss the highlighted topic
first.
rR
fo
ot
N
n
tio
d uc
ro
ep
Physical Properties
The following list provides details of the interface physical properties:
• Clocking: Refers to the interface clock source—either internal or external;
rR
9192 bytes;
• Data Link Layer protocol and keepalives: You can change the Data Link
Layer protocol for the particular media type—for example, Point-to-Point
Protocol (PPP) to Cisco High-Level Data Link Control (or Cisco HDLC)—and
ot
Logical Properties
The following list provides details of the interface logical properties:
• Protocol family: Refers to the protocol family you want to use—iso,
inet, or mpls;
• Addresses: Refers to the address associated with the particular family
(for example, IP address using family inet);
• Virtual circuits: Refers to the virtual circuit identifier, such as a data-link
n
connection identifier (DLCI), Virtual Path Identifier (VPI), Virtual Channel
Identifier (VCI), or Virtual Local Area Network (VLAN) tag; and
tio
• Other characteristics: Some other configurable options include Inverse
ARP, traps, and accounting profiles.
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Deactivating an Interface
In a configuration, you can deactivate statements and identifiers so that they do not
take effect when you issue the commit command. Any deactivated statements and
rR
identifiers have the inactive: tag. They remain in the configuration but are not
active when you issue a commit command.
To deactivate a statement or identifier, use the deactivate configuration mode
command: deactivate (statement | identifier). To reactivate a statement
or identifier, use the activate configuration mode command: activate
fo
(statement | identifier).
ot
N
n
tio
d uc
ro
ep
Disable Versus Deactivate
In some portions of the configuration hierarchy, you can include a disable
statement to disable functionality. One example is disabling an interface by including
rR
n
tio
d uc
ro
ep
Interface Configuration Examples
The slide shows three configuration examples for common interface types. You can
use cut and paste in conjunction with the load merge terminal command to
rR
modify these configurations for use in your router. Piping the output of a show
command to display set is an excellent way to see the commands that created a
given configuration stanza.
Note that each configuration example makes use of at least one logical unit, and that
you specify a protocol family and related logical properties at the unit level. The
fo
commands used to configure the Asynchronous Transfer Mode (ATM) interface shown
on the slide are shown in the following output:
[edit interfaces]
user@host# show at-0/2/1 | display set
ot
n
tio
d uc
ro
ep
General Interface Troubleshooting
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Understanding the Demarcation
Understanding the demarcation is important when troubleshooting a given problem.
The model in North America is based on the customer providing, and thereby being
rR
responsible for, the CSU/DSU function. The telco in this environment does not have
any means of verifying the local-loop or tail without getting the subscriber to set a loop
back to the provider.
In Europe, the telco supplies the CSU/DSU device and is responsible for the
verification and testing of the local-loop in addition to whatever segments might exist
fo
and
• Point-to-multipoint (SONET/SDH, T3 and E3, T1 and E1, Frame Relay or
Asynchronous Transfer Mode-virtual circuit (ATM-VC).
Tools Available
The following pages discuss the troubleshooting tools available in JUNOS Software.
n
tio
d uc
ro
ep
Displaying Interface Status at a Glance
Use the show interfaces terse command to display a terse listing of all
interfaces installed in the device along with their administrative and Data Link Layer
rR
status. The table on the slide explains the meaning of the Admin and Link status
indications.
When an interface is administratively disabled, the physical interface has an Admin
status of down and a Link status of up, and the logical interface has an Admin
status of up and a Link status of down. The physical interface has a Link status of
fo
up because the physical link is healthy (no alarms). The logical interface has a Link
status of down because the Data Link Layer cannot establish end to end.
When an interface is not administratively disabled and the Data Link Layer between
the local device and the remote device is not functioning, the physical interface has an
Admin status of up and a Link status of up while the logical interface has an Admin
ot
status of up and a Link status of down. The physical interface has a Link status of
up because the physical link is healthy (no alarms). The logical interface has a Link
status of down because the Data Link Layer cannot establish end to end.
N
If the Data Link Layer between the local device and the remote device is up and
running, both the physical and logical interfaces have an Admin status of up and a
Link status of up, as shown in the case of the so-0/1/2 interface on the slide.
n
tio
d uc
ro
ep
Standard Interface Status
Use the show interfaces command without the terse or detailed switches to
display standard information about the named interface (or all interfaces when you do
rR
not identify a specific interface). The slide provides sample output for an OC-3C
SONET interface. The callouts on the slide help illustrate how interfaces partition into
physical devices and logical units in JUNOS Software.
Each physical and logical interface is referenced by two index numbers within JUNOS
Software. An interface index is assigned to each interface at boot time depending
fo
upon the order in which that interface activates. The SNMP ifIndex is used to
identify and reference that interface when performing SNMP MIB walks. Note that the
indexes assigned to the physical interface device (ifd) differ from the index used to
identify the logical device (ifl). Wherever possible, the SNMP ifIndex values are
persistent across reboots or in the event of hardware additions and deletions that
ot
result from PIC or Flexible PIC Concentrator (FPC) insertion and removal.
The output of a show interfaces command also includes a section on the
device-level configuration and its operational flags.
N
n
connect with the remote endpoint;
• Loopback: Device is in physical loopback;
tio
• Loop-Detected: The Data Link Layer received frames that it sent and
suspects a physical loopback;
• No-Carrier: Where the media supports carrier recognition, this flag
indicates that no carrier is currently visible;
uc
• No-Multicast: Device does not support multicast traffic;
• Present: Device is physically present and recognized;
• Promiscuous: Device is in promiscuous mode and sees frames
d
addressed to all physical addresses on the medium;
• Quench: Device is satiated because it overran its output buffer;
ro
• Recv-All-Multicasts: No multicast filtering (promiscuous); and
• Running: Device is active and enabled.
ep
One or more flags help communicate the status of the interface. These flags include
the following:
• Admin-Test: Interface is in test mode, which means that some sanity
checking, such as loop detection, is disabled;
rR
n
whether the link protocol is up;
• Loose-LMI: Frame Relay will not use Local Management Interface (LMI)
tio
to indicate whether the link protocol is up;
• Loose-NCP: PPP does not use Network Control Protocol (NCP) to
indicate whether the device is up; and
• No-Keepalives: Link protocol keepalives are disabled.
uc
The output also summarizes the device-level traffic load, which displays in both bits
and packets per second, as well as any alarms that might be active. The final portion
of the command output displays the configuration and status of each logical unit
defined on that device. In this example, a single unit is present with support for the
d
inet protocol family.
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Displaying Input and Output Errors for the Interface
Use the show interfaces extensive command to display input errors
(extensive output only) on the interface. Use the clear interfaces
rR
match code discarded because they were not recognized or were not of
interest. Usually, this field reports protocols that JUNOS Software does
not handle, such as Cisco Discovery Protocol (CDP), Spanning Tree
Protocol (STP), or any protocol type that JUNOS Software does not
understand. (On an Ethernet network, numerous possibilities exist.)
ot
n
the interface. The following list explains the less obvious counters:
• HS link CRC errors: Displays the count of errors on the high-speed
tio
links between the application-specific integration circuits (ASICs)
responsible for handling the router interfaces.
• Carrier transitions: Displays the number of times the interface
has gone from down to up. This number should not increment quickly,
uc
increasing only when the cable is unplugged, the far-end system powers
on and off, or a similar problem occurs. If it does increment quickly
(perhaps every 10 seconds), then either the transmission line, the
far-end system, or the PIC is broken.
d
• Errors: Displays the sum of the outgoing frame aborts and FCS errors.
• Drops: Displays the number of packets dropped by the output queue of
ro
the I/O Manager ASIC. If the interface is saturated, this number
increments once for every packet that the ASIC’s random early detection
(RED) mechanism drops.
ep
• Aged packets: Displays the number of packets that remained in
shared packet SDRAM for so long that the system automatically purged
them. The value in this field should never increment. If it does, it is most
likely a software bug or possibly due to malfunctioning hardware.
rR
fo
ot
N
n
tio
d uc
ro
ep
Monitoring an Interface
The slide depicts a typical output from the monitor interface command. You
must set your terminal session to VT100 for the screen to display correctly. This
rR
command provides real-time packet and byte counters as well as displaying error and
alarm conditions.
fo
ot
N
n
tio
d uc
ro
ep
Loopback Testing
The physical path of a leased line usually consists of a number of segments or spans
interconnected by devices that repeat and regenerate the signal. When a fault occurs
rR
on the circuit that takes the form of either a break or signal corruption due to noise, it
is possible to localize the problem by testing the line on a segment-by-segment basis
or an end-to-end basis, as needed.
Each circuit is symmetric in that a transmit path from one device connects to the
receive path on the remote side, and vice versa. Looping is the process of connecting
fo
the transmit path of a router or intermediate device to the receive path. If this device
is one of the routers, the loop is either detected if the looped segment is operational,
or not detected if a break occurs. The device achieves this detection by detecting its
own Data Link Layer keepalive packets (for example, the magic number when the
encapsulation is PPP).
ot
If a loop is set back towards a device and the device does not detect it, you can
assume that the problem lies somewhere between the device and where the loop was
set by the telco or provider. The next step is to set a loop somewhere closer to the
N
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Supported Loopback Types
Most PICs supported on JUNOS platforms support local (internal) loopback tests.
Where possible, it is best to perform local loopbacks using an external loopback plug
rR
because this setup also tests the PIC’s transmit and receive circuitry. Point-to-point
style interfaces (nonbroadcast types of technologies like SONET or
T1/DS1), also support remote loopbacks. Note that configuring an interface for a
remote loopback results in a line loop on the local device; it does not generate a
remote loopback request to the remote device. Line loops can be remotely signalled
for PICs with integral channel service unit (CSU) functionality (T1 or E1, and T3 or E3),
fo
but the generation of the remote loopback code requires telco interaction or test
equipment. Again, configuring a remote loopback in JUNOS Software does not signal
the remote end to perform a loopback; it creates a local line-loop condition.
For local loopback the PIC’s transmit clocking should be set to internal, which is the
ot
default setting. A remote loopback (or line loop) allows telco testing on the local loop
(also referred to as the tail) and also allows testing from the remote device.
N
n
tio
d uc
ro
ep
Configuring Loopbacks
Interface loopbacks require configuration in JUNOS Software for most PICs and
interface types. A small number of channelized DS3 and OC12 interfaces support the
rR
ability to initiate far-end alarm and control (FEAC)-based or T1 inband and FDL-based
loopbacks using operational mode commands. Note that configuration is never
necessary to effect an external local-loopback with a loopback plug, or when relying
on the telco to provide a line loopback (which appears as a remote loopback to the
attached router). The slide shows an example of a local-loopback configuration and
the operational mode status display that confirms that the loopback is in place.
fo
Note that when the telco provides a line loopback, no indication exists that a loopback
is in place, unless the configured Layer 2 protocol has built-in loopback detection—for
example, PPP. The routers used in this example are running Frame Relay with
LMI-based keepalives disabled. As a result, a remote loopback goes undetected at the
ot
remote device, which is now talking to itself as indicated by the time-to-live (TTL)
expiration messages shown (we cover the use of ping to test loopbacks on a
forthcoming page):
N
n
[edit interfaces so-0/1/1]
tio
user@London# run show interfaces so-0/1/1 | match loop
Link-level type: Frame-Relay, MTU: 4474, Clocking: Internal, SONET mode,
Speed: OC3, Loopback: None, FCS: 16,
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Layer 2 Protocols and Loopbacks
Many Layer 2 protocols make use of a keepalive mechanism that, among other things,
can detect the presence of a loopback. Whether local or remote, the detection of a
rR
loop condition results in a link down declaration for that interface. When the interface
is marked as down at the Data Link Layer, the related interface route is removed from
the routing table, which prevents ping testing for the duration of the loopback. (We
describe ping testing over a loopback on subsequent pages.)
In most cases you can work around this issue by configuring the interface with a
fo
no-keepalives statement, but, as shown on the slide, this workaround only works
for the frame-relay, atm, and cisco-hdlc encapsulation types. Even with
keepalives (LCP) disabled, PPP still detects the presence of a loopback when the
Network Control Protocol (NCP) attempts to negotiate Layer 3 parameters. The only
way around this conditions is to change the interface’s encapsulation type for the
ot
n
tio
d uc
ro
ep
Equipment from Other Vendors
On equipment from some other vendors, you can test the operation of a WAN link by
issuing pings to the router’s local IP address. The top of the slide shows this mode of
rR
operation.
address does not exit the interface, and as such, cannot be used to ascertain the
operational status of the line.
The next slide covers testing the line on JUNOS platforms.
ot
N
n
tio
d uc
ro
ep
Looping Line and Keeping Interface Up
In the example on the slide, we looped the line externally. This loop might be a hard
loop, a telco loop, or a remote interface loop for the purposes of this example.
rR
Because some Data Link Layer protocols detect the looped condition, and disable the
interface as a result, you must use either ATM Adaptation Layer 5 (AAL5), Frame Relay,
or Cisco HDLC encapsulation with keepalives turned off. PPP encapsulation generally
does not work, because the looped condition prevents the NCP from completing its
initialization, thereby preventing a declaration of up for the interface.
fo
If the line has a usable transmit and receive path, the packet returns to the local
device as a result of the loop condition. Upon receiving this packet, the device once
again sends the packet out the WAN interface a second time. The packet’s TTL field
decreases during this process. This operation continues until the packet’s TTL
reaches zero, or until a line error causes packet corruption and the resulting silent
packet discard.
Continued on next page.
n
initial ping request, all at wire speed.
Setting the TTL to a lower value is useful when trying to determine marginality of a
tio
line. That is, a TTL of 1 requires only a single transmission and reception of the
packet, which is similar to the type of test performed by other vendors when pinging a
local WAN interface.
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
BERT Tests Require a Loop
The pattern received through a loop is verified against the pattern sent. End-to-end
testing is difficult to coordinate. By changing the position of the loop downstream from
rR
the device performing the test, you can locate the problem area easily. Common
points for looping the line are the telco demarcation point (also named demark), the
remote end, and the midpoint (with help from the carrier).
You can configure any of the following interfaces to execute a BERT test when the
interface receives a request to run this test: E1, E3, T1, T3, the channelized DS-3,
fo
OC-3, OC-12, STM-1, the channelized DS-3 IQ, E1, and OC-12 IQ.
BERT Parameters
You must configure the various parameters that influence a BERT test under the
ot
interface subject to testing. These options include the test duration (10 seconds is the
default), the test pattern, and the error rate to include in the bit stream by including
the bert-period, bert-algorithm, and bert-error-rate statements,
N
respectively.
Continued on next page.
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Checking BERT Results
You can check the results of your BERT test using the show interfaces
extensive command. The slide shows the formatting and fields associated with the
rR
results of a BERT test. Most of the fields are self-explanatory, but a few fields could
use some additional explanation.
The Error bit count field displays the number of erroneous echo replies
received from the remote end. The LOS field indicates pattern synchronization status.
A working BERT test requires that the receiver be in sync with the transmitter. In this
fo
example, pattern synchronization was lost once during the test; furthermore, the loss
of synchronization lasted for 239 seconds according go the LOS seconds field. The
display also shows that no bits were received, and as a result, that no errors were
detected. The lack of received bits is likely the result of the lack of test pattern
synchronization.
ot
Note that for a BERT test to be meaningful you must be able to inject and detect
errors. Only by purposely injecting an error—and then witnessing that the injected error
is detected—can you be sure that the test results are valid.
N
n
tio
d uc
ro
ep
Media-Specific Interface Troubleshooting
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Media Types and Interface Naming
JUNOS platforms support several flavors of Ethernet. The following are the relevant
media types:
rR
Link Mode
When troubleshooting LAN topologies, consider the link mode:
ot
• Full duplex;
• Half duplex; or
N
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Configuring Loopback Mode
To place an Ethernet interface in loopback mode, issue a set gigether-options
loopback at the [edit interfaces ge-interface-name] hierarchy. You
rR
use a similar command for Fast Ethernet interfaces. When the interface loops, you
can monitor traffic and expect to see all traffic that travels out—that is, an Address
Resolution Protocol (ARP) request—coming right back in:
user@host> monitor traffic interface fe-0/0/0
verbose output suppressed, use <detail> or <extensive> for full protocol decode
fo
expected for point-to-point interfaces), you must add a static ARP entry that matches
the media access control (MAC) address for the looped interface for the target IP
address. This addition is necessary so that the interface accepts returning traffic
N
n
tio
d uc
ro
ep
Pinging a Locally Connected Device
A reply received from the device typically provides verification that the link and
interface are operating correctly.
rR
meet all relevant specifications. If the cabling specifications are not met, the input
errors on the interface will increase.
Continued on next page.
N
Generic Tips
The following are a few generic tips:
• Ensure that encapsulation types are equivalent to other devices on link.
• Use the show interfaces extensive command to check the
status the of interface.
• Use the monitor interfaces command to receive real-time
statistics.
n
• Use the monitor interface interface-name command to
display real-time statistics about a physical interface. The output updates
tio
every second. The output of this command also shows the amount that
each field has changed since you started the command or since you
cleared the counters by using the c key. This command also checks for
and displays common interface failures, such as SONET/SDH and T3
alarms, loopbacks detected, and increases in framing errors. If the
uc
framing errors are increasing, this increase indicates that frames are
being corrupted. If the input errors are increasing, check the cabling to
the device and have the carrier verify the integrity of the line.
d
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Checking the Port
To troubleshoot T3 and E3, set up a physical loopback between the transmit and
receive ports. If the T3 interface is functioning properly, you should see a
rR
Loop-Detected flag in the device flags section of the show interface output.
Also, the monitor interface command should show that the input packet count
matches the output packet count. For Cisco HDLC encapsulation, the input keepalive
packet count should also match the output keepalive packet count.
If you do not see the Loop-Detected flag, the PIC port might be bad. To isolate the
fo
problem, move the T3 link to another T3 interface on the router and verify whether the
new port works. To move the configuration of the existing T3 interface to the new
interface, use the rename command under the [edit interfaces] hierarchy in
configuration mode:
ot
[edit interfaces]
user@host# rename t3-1/0/0 to t3-1/0/1
Continued on next page.
N
n
HDLC-encapsulated payload. A subrate value of 1 corresponds to
44.2 / 588, which is 75.17 Kbps, or 0.17 percent of the
HDLC-encapsulated payload.
tio
• For Digital Link CSUs, specify the subrate value as the data rate you
configured on the CSU in the format xKb or x.xMb. For a list of specific
rate values, use the command completion feature in the command-line
interface (CLI). The range is 358 Kbps through 33.7 Mbps for E3
uc
interfaces and 301 Kbps through 44.2 Mbps for T3 interfaces.
• For Kentrox CSUs, specify the subrate as a number from 1 through 69
that exactly matches the value configured on the CSU. A subrate value of
69 corresponds to 34.995097 Mbps, or 79.17 percent of the
d
HDLC-encapsulated payload (44.2 Mbps). A subrate value of 1
corresponds to 999.958 Kbps, which is 2.26 percent of the
ro
HDLC-encapsulated payload.
• For T3 interfaces configured with Larscom CSUs, specify the subrate
value as a number from 1 through 14 that matches the value configured
ep
on the CSU exactly. E3 interfaces do not support the subrate option with
Larscom CSUs.
• For Verilink CSUs, specify the subrate as a number from 1 through 28
that exactly matches the value configured on the CSU. To calculate the
rR
n
interface-name t3-options] hierarchy level.
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Displaying Active Alarms
If the first line shows Physical link is Up, it means that the physical link is
healthy and can pass packets. If the first line shows Physical link is Down, it
rR
means that the physical link is unhealthy and cannot pass packets. To display more
extensive information about the T3 interface if the physical link is down, use the show
interface t3-x/y/z extensive command. Look at the active alarms and
active defects for the T3 interface, and troubleshoot the T3 media accordingly.
fo
ot
N
n
tio
d uc
ro
ep
Important DS-3 Alarms
The following list provides descriptions of the important DS-3 alarms:
• AIS: An incoming alarm indication signal (AIS) indicates a problem with
rR
interface, and have the carrier verify the integrity of the line.
• IDLE: An idle alarm indicates that the line is not provisioned for service.
Have the carrier ensure line-provisioning for service.
N
n
polarity (see ANSI T1.231 Section 7.1.1.1.1).
• EXZ: An excessive zeros (EXZ) alarm indicates the occurrence of any zero
tio
string length equal to or greater than three for B3ZS, or greater than four
for HDB3 (see ANSI T1.231 Section 7.1.1.1.2).
• LCV: The Line Code Violation (LCV) parameter (also known as CV-L) is a
count of both BPVs and EXZs occurring over the accumulation period. An
uc
EXZ increments the LCV by one, regardless of the length of the zero string
(see ANSI T1.231 Section 7.4.1.1).
• PCV: For all DS-3 applications, the P-bit Code Violation (PCV) error event
is the same as a P-bit parity error event. In other words, the P-bit code on
d
the DS-3 M-Frame does not match that code calculated locally (see ANSI
T1.231 Section 7.1.1.2.1).
•
ro
CCV: For C-bit parity and SYNTRAN DS-3 applications, the C-bit Code
Violation (CCV) is the count of coding violations reported through the
C-bits. For C-bit parity, it is a count of C-bit parity errors occurring in the
accumulation interval. For SYNTRAN, it is a count of CRC-9 errors
ep
occurring in the accumulation interval (see ANSI T1.231 Section
7.1.1.2.2).
For detailed definitions of the DS-3 performance parameters (LES, PES, PSES, CES,
CSES, SEFS, UAS), see RFC 2496.
rR
fo
ot
N
n
tio
d uc
ro
ep
Responding to Loop Requests
For T3 interfaces, the T3 FEAC signal sends alarm or status information from the
far-end terminal back to the near-end terminal and to initiate T3 loopbacks at the
rR
Remote Loopbacks
Issue the CLI operational mode command test interface
N
n
tio
d uc
ro
ep
T1 and E1 Approach Is Similar to T3 and E3
The tests listed on this page and the following pages are very similar to those
discussed in the T3 and E3 section.
rR
Ping Testing
You can use ping tests for data integrity testing. Alternatively, you also can perform
BERT testing on T1 or E1 interfaces.
fo
If the device on one side of a link differs from the device on the opposite side, the link
has difficulty coming up. You should match all settings between endpoints.
Continued on next page.
n
user@host# set fcs 32
Also by default, E1 and T1 interfaces transmit the value 0x7E in the idle cycles. To
tio
have the interface transmit the value 0xFF (all ones) instead, include the
idle-cycle-flag statement at the [edit interfaces interface-name
e1-options] or [edit interfaces interface-name t1-options]
hierarchy level, specifying the ones option:
uc
[edit interfaces interface-name t1-options]
user@host# set idle-cycle-flag ones
Channelized T1 and E1 applications also require the appropriate setting of time slots
(or channels) that carry user data. A T1 interface can support up to 24 channels while
d
an E1 interface supports up to 30 user channels. (Two of the 32 channels used in an
E1 interface are for framing and alarm reporting.)
ro
T1 and E1 Specifics
ep
While T3 and T1 troubleshooting have many similarities, a few pronounced differences
exist. We describe the different methods for troubleshooting T1 and E1 interfaces on
the following pages.
rR
fo
ot
N
n
tio
d uc
ro
ep
T1 Buildout
A T1 interface has five possible setting ranges for the T1 line buildout: 0–132,
133–265, 266–398, 399–531, or 532–655 feet. By default, the T1 interface uses
rR
the shortest setting (0–133). To have the interface drive a line at one of the longer
distance ranges, include the buildout statement with the appropriate value at the
[edit interfaces interface-name t1-options] hierarchy level:
[edit interfaces interface-name t1-options]
user@host# set buildout 532-655
fo
T1 Byte Encoding
By default, T1 interfaces use a byte encoding of 8 bits per byte (nx64). You can
configure an alternative byte encoding of 7 bits per byte (nx56). To have the interface
ot
use 7 bits per byte encoding, include the byte-encoding statement at the [edit
interfaces interface-name t1-options] hierarchy level, specifying the
nx56 option:
N
T1 Data Inversion
By default, data inversion is disabled. To enable data inversion at the HDLC level,
include the invert-data statement at the [edit interfaces
interface-name t1-options] hierarchy level:
[edit interfaces interface-name t1-options]
user@host# set invert-data
T1 Framing
n
By default, T1 interfaces use extended superframe (ESF) framing format. You can
tio
configure superframe (SF) as an alternative. To have the interface use the SF framing
format, include the framing statement at the [edit interfaces
interface-name t1-options] hierarchy level, specifying the sf option:
[edit interfaces interface-name t1-options]
uc
user@host# set framing sf
T1 Line Encoding
d
By default, T1 interfaces use B8ZS line encoding. You can configure alternate mark
inversion (AMI) line encoding if necessary. You should use AMI coding in conjunction
with the nx56 byte encoding to prevent problems with ones-density:
ro
[edit interfaces interface-name t1-options]
user@host# set line-encoding ami
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
E1 Framing
E1 is a standard WAN digital communication format designed to operate over copper
facilities at a rate of 2.048 Mbps. Widely used outside North America, it is a basic
rR
reporting methods.
To configure E1-specific physical interface properties, include the e1-options
statement at the [edit interfaces interface-name] hierarchy level. By
N
default, E1 interfaces use the G.704 framing mode; the alternative is unframed.
Continued on next page.
Time Slots
n
JUNOS Software refers to the first time slot as 1. Some vendors refer to this time slot
as time slot 0.
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
E1 Media and Alarms
Active alarms and active defects can render an interface unable to pass packets.
When a defect persists for a certain amount of time, it receives promotion to alarm
rR
status. Based on the router configuration, an alarm can trigger a red or yellow alarm
on the Craft Interface. E1 alarms include the following:
• LOS: Loss of signal;
• LOF: Loss of frame;
fo
n
payload bits of a DS-1 frame (see ANSI T1.231 Section 6.1.1.2.3.). A
controlled slip might occur when a difference exists between the timing
tio
of a synchronous receiving terminal and the received signal. A controlled
slip does not cause an out-of-frame defect.
• OOF: An out-of-frame defect is the occurrence of a particular density of
framing error events (see ANSI T1.231 Section 6.1.2.2.1). For DS-1 links,
uc
JUNOS Software declares an out-of-frame defect when the receiver
detects two or more framing errors within a 3 msec period for ESF signals
and 0.75 msec for D4 signals, or two or more errors out of five or fewer
consecutive framing bits. For E1 links, JUNOS Software declares an
out-of-frame defect when three consecutive frame alignment signals
d
arrive with an error (see ITU-T G.706 Section 4.1 [26]).
E1 framing alarms include the following:
ro
• TS16 Alarm Indication Signal Failure: For E1 links, JUNOS Software
declares this signal failure when time slot 16 is received as all 1s for all
frames of two consecutive multiframes (see ITU-T G.732 Section 4.2.6).
ep
JUNOS Software never declares this condition for DS-1.
• Loss of Multiframe Failure: JUNOS Software declares this failure when
two consecutive multiframe alignment signals (bits 4 through 7 of TS16
of frame 0) are received with an error. JUNOS Software clears this failure
rR
n
tio
d uc
ro
ep
T1 and E1 Fault Isolation
When you confirm the settings on both ends but problems persist, you might want to
involve the telco for line and loop testing. Before suspecting the transmission line, you
rR
should first perform local loopback testing at each end. You also should attempt
remote loopback requests to the far-end internal CSU.
RFC 2495
fo
n
tio
d uc
ro
ep
Ping Testing with Patterns
You can use ping testing to test a circuit, or, alternatively, to diagnose a problem with
the transmission circuit for E1 and T1. By changing the payload pattern, you can
rR
detect problems with ones density and zero suppression code settings.
Common Patterns
Sending ping packets with the payload containing certain bit patterns might provide
pointers as to what type of problem exists, depending on the ping failure rate
associated with a particular pattern.
Patterns commonly used for this purpose include the following:
• FFFF: all ones;
• 0000: all zeros; and
n
• 5555: alternating ones and zeros.
JUNOS platforms also support BERT testing, as previously described on E1 and T1
tio
interfaces. Because BERT testing is a far more definitive test, you should consider
BERT testing when you suspect marginal performance or intermittent operation.
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
SONET/SDH Has Embedded OAM
SONET/SDH transmission systems incorporate a multitude of Operation,
Administration, and Maintenance (OAM) functionalities at the line, section, and path
rR
Localizing Errors
Using the output from these commands, you can tell very easily where the problem
lies on SONET/SDH links.
ot
n
pic 0 {
framing sdh;
tio
}
}
}
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Monitoring SONET/SDH Interfaces
The monitor interface command can provide useful troubleshooting
information for the SONET/SDH interface.
rR
The statistics in the second column are the cumulative statistics from the last time the
clear interfaces statistics command cleared them. The statistics in the
third column are the statistics from the last execution of the monitor interface
command.
If the framing errors increase, check the FCS and scrambling configuration. If the
fo
configuration is correct, check the cabling to the router, and have the carrier verify the
integrity of the line.
If the input errors increase, check the cabling to the router, and have the carrier verify
the integrity of the line.
ot
N
n
tio
d uc
ro
ep
Displaying SONET/SDH Interface Status
If the first line shows Physical link is Up, it means that the physical link is
healthy and can pass packets. If the first line shows Physical link is Down, it
rR
means that the physical link is unhealthy and cannot pass packets. To display more
extensive information about the SONET/SDH interface when the physical link is down,
use the show interface so-x/y/z extensive command. Look at the active
alarms and active defects for the SONET/SDH interface, and troubleshoot the
SONET/SDH media accordingly.
fo
ot
N
n
tio
d uc
ro
ep
SONET Path Trace
SONET and SDH framing overhead includes support for a path trace via the J1 byte in
the path overhead. The path trace information is typically used to identify the device
rR
that is terminating the path layer. The slide shows the JUNOS Software default coding
of the path trace field, which is coded to identify the router and SONET interface
name. This information can prove invaluable when the goal is to confirm the correct
patching of a transmission line, or when you suspect that a loopback might be in
effect. In this example the transmitted and received path trace information confirms
that San_Jose is receiving its own transmitted path trace, which indicates that a
fo
not supported for ATM interfaces, which always use the default path trace coding.
Continued on next page.
N
n
16-byte frame is identical to the 16-byte frame defined in 9.2.2.2 for the description of
the byte J0. At international boundaries, or at the boundaries between the networks of
different operators, the format defined in clause 3/G.831 shall be used unless
tio
otherwise mutually agreed by the operators providing the transport. Within a national
network or within the domain of a single operator, this path access point identifier may
use a 64-byte frame.”
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
SONET/SDH Network Elements
The regenerators are considered section-terminating equipment (STE). STEs are
responsible only for their particular section of the SONET/SDH span, as opposed to
rR
the entire SONET/SDH network path from one device designated as PTE to the other.
They are responsible for simple regeneration of the SONET/SDH signal out to the next
SONET/SDH equipment in the span. An STE only checks to ensure the incoming
SONET/SDH frame arriving from its directly connected neighbor is good, while not
having any knowledge of the rest of the span. STEs look only at the section overhead
bytes of the SONET/SDH frame, even though they can rewrite the other overhead
fo
add and remove payloads). The SONET/SDH span from one LTE to another is referred
to as a line span. LTEs mainly concern themselves with the line overhead bytes of the
SONET/SDH frame.
N
JUNOS platforms are considered SONET/SDH PTEs. SONET/SDH PTEs are basically
the endpoints of a typical SONET/SDH run. Because the SONET/SDH frame can
traverse many regenerators and SONET/SDH multiplexers, the PTE is the final
destination where the SONET/SDH frame terminates and the payload it carries
receives processing. Hence, we consider the SONET/SDH span between two SONET/
SDH PTEs a SONET/SDH path. PTEs pay particular attention to the path overhead
bytes of the SONET/SDH frame.
Continued on next page.
n
unless you have access to the LTE or the STE, you can tell, at least from the PTE’s
perspective, that the problem is either somewhere upstream or local. With that said,
the basic troubleshooting commands used to see any SONET/SDH line errors are
tio
monitor interfaces so-0/0/1 and show interfaces so-0/0/1
extensive.
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Local Fiber Break
When a local fiber break occurs between Router B and add/drop multiplexer (ADM) B,
the following alarms occur:
rR
so forth.
• LOS: A loss of signal (LOS) alarm indicates a physical link problem with
the connection to the router receive port. Check the connection between
the router port and the first SONET/SDH network element (ADM in the
example on the slide).
ot
• LOF: A loss of frame (LOF) signal indicates detected errors in the A1 and
A2 framing bytes. Check the connection between the router port and the
first SONET/SDH network element.
N
n
• REI: JUNOS Software sends a remote error indicator (REI) upstream to
signal an error condition. It sends an REI-L to the upstream LTE when
errors are detected in the B2 byte. It sends an REI-P to the upstream PTE
tio
when errors are detected in the B3 byte. Work with the SONET/SDH
network provider to locate the source of the error condition. (Locate the
section that causes the BIP-B1 errors.)
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Why So Many Alarms on the PTE?
The reasons why a broken cable should trigger an LOL and LOS alarm are obvious, but
some might get confused when they also see AIS counters incrementing in the
rR
SONET/SDH line and SONET/SDH path. If no fiber plugs into the port, where do the
AIS-L and AIS-P come from? In previous discussions, we mentioned that PTEs also
have an LTE and STE component. Therefore, you must examine all SONET/SDH
overhead.
When JUNOS Software raises the LOS alarm, the STE component sends SONET/SDH
fo
frames up to the LTE component. These frames have the K2 byte (in the section
overhead) and the H1 and H2 bytes (in the line overhead) set to indicate AIS-L and
AIS-P, respectively. When the LTE component sees the frame, it looks at the line
overhead and finds the AIS-L signal in the K2 byte, and so the counter for AIS-L starts
to increment. The frame is then handed to the PTE component, and the H1 and H2
ot
problem.
n
tio
d uc
ro
ep
Remote Defect Indicators (Line and Path)
Regenerator A (RA) notices that it receives no light, and after a very short time, it
raises, at a minimum, an LOS alarm. RA rewrites clean section overhead bytes, but it
rR
writes all 1s in certain parts of the K2 byte residing in line overhead (bits 6–8), in the
H1 and H2 bytes (pointer bytes used to find the path overhead and SONET/SDH
payload envelope), and in the entire SONET/SDH payload envelope.
When ADM B receives the SONET/SDH frame, it sees clean section overhead, and
because ADM B is an LTE, it also looks in the line overhead bytes and notices the 1s in
fo
the K2 byte (indicating an alarm indication signal, or AIS, in the SONET/SDH line
span). If this alarm persists for a certain number of frames, it raises the AIS-L alarm
and sends a remote defect indicator (RDI-L) back toward Platform B (in bits 5–7 of the
SONET/SDH G1 byte). (Note that ADM A does not look at the path overhead because it
is not a PTE.)
ot
Finally, when Platform A receives the SONET/SDH frame, it looks at all overhead bytes
because it is a PTE. It sees good section overhead, but when it looks in the line
overhead, it notices all 1s in the H1 and H2 bytes (indicating AIS in the SONET/SDH
N
path). Hence, it eventually raises an AIS-P alarm (when it receives enough frames in
this state) and sends an RDI-P back toward JUNOS platform B. If the SONET/SDH path
is clean all the way back to Platform B, it sees the RDI-P and raises this alarm in
addition to the RDI-L it saw from ADM B.
n
tio
d uc
ro
ep
Remote Defect Indicator (Path)
ADM B is an LTE that has the STE component built in. When the break shown on the
slide occurs, the STE portion of ADM B notices the lack of light and eventually raises
rR
an LOS alarm by setting the appropriate bytes of the LOH with 1s. The SONET/SDH
frame then traverses the internal components of ADM B.
ADM B’s LTE portion notices the AIS-L and sends an RDI-L back to ADM A. Note that
the RDI-L does not go back to Platform A; it terminates at ADM A. Basically, it is a
SONET/SDH line span error, so it only remains within that line span. Moving forward,
fo
the section overhead and line overhead bytes (with the exception of the pointer bytes,
at which PTEs look) are set back to normal, and the SONET/SDH frame travels out to
Regenerator B (RB). Note that errors from section overhead and line overhead do not
get passed on because section overhead and line overhead are rewritten clean as
they leave ADM B.
ot
RB sees good section overhead, so it sends the SONET/SDH frame out to Platform B.
Note that it rewrites the section overhead in this process.
When Platform B receives the SONET/SDH frame, it notices clean section overhead
N
and line overhead, except for all 1s in the pointer bytes and thus, raises the AIS-P
alarm. Because AIS-P is raised, Platform B sends an RDI-P back towards Platform A. As
it passes through ADM B and ADM A, both ADM A and ADM B rewrite clean section
overhead and line overhead as usual, but the RDI-L is not considered clean as it
leaves ADM A towards Platform A.
n
tio
d uc
ro
ep
Marginal Line
This example discusses the result of bit errors caused by a marginal line between
Regenerator B and Regenerator C (RC). When RC receives the frame, it does a parity
rR
check on the B1 byte in the section overhead. It logs the occurrence of BIP-B1 errors
before sending the SONET/SDH frame out to ADM A. However, as usual, it rewrites the
section overhead; thus, the B1 byte should be clean.
Because B1 parity errors occurred, it is most likely that the rest of the SONET/SDH
frame is also corrupt. When ADM A receives the SONET/SDH frame, it sees clean
fo
section overhead (thus, a good B1 byte). However, when it runs a parity check on the
B2 byte in the line overhead, it likely sees BIP-B2 errors and raises an REI-L toward
Platform A (REI-L is conveyed using the M0 and M1 byte in the line overhead).
When ADM A sends the SONET/SDH frame out to ADM B, it rewrites the section
overhead and line overhead; thus, the B1 and B2 bytes are clean as the frame gets to
ot
ADM B. ADM B is an LTE, so it sees good B1 and B2 bytes (but does not look at the B3
byte in the path overhead) and forwards the frame to Platform B.
When the SONET/SDH frame reaches Platform B, the STE component runs a parity
N
check on the B1 bytes and see it as good. It passes the frame internally up to its LTE
component where the LTE component finds a good B2 byte when performing the
parity check. However, when the PTE portion finally receives the SONET/SDH frame, it
looks in the path overhead and calculates a bad B3 byte. When this calculation
happens, it logs a BIP-B3 error and sends an REI-P back toward Platform A (certain
bits of the G1 byte indicate REI-P).
n
tio
d uc
ro
ep
Port Types
Point-to-multipoint and nonbroadcast multiaccess (NBMA) technologies exhibit unique
characteristics and therefore require additional sophistication in your troubleshooting
rR
approach. You must differentiate whether the problem exists on the physical level or
the logical level when dealing with point-to-multipoint and NBMA interfaces.
Encapsulation
fo
We discuss the JUNOS Software tools shown on the slide on the following pages.
N
n
tio
d uc
ro
ep
Router Is Normally DTE
When you configure an interface with Frame Relay encapsulation, the router is
assumed to be data terminal equipment (DTE). That is, JUNOS Software assumes the
rR
Back-to-Back Connections
N
For back-to-back Frame Relay connections, either disable the sending of keepalives
on both sides of the connection, or configure one side of the connection to function as
a DCE (the default is a DTE line discipline).
Continued on next page.
Encapsulation Configuration
As shown on the slide, except in the case of circuit cross-connect, you should specify
the Frame Relay encapsulation configuration at the interface device level. Configure
the specification of the connection type (point-to-point versus point-to-multipoint), and
the DLCI at the logical device level. The slide shows a typical point-to-point
configuration for a DTE device.
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
PVC Management Protocol
For LMI—a permanent virtual circuit (PVC) management protocol—interoperability, you
might need to configure the LMI type to be either conformant to the ANSI T1-617
rR
Annex D, or alternatively, to the ITU-T Q933 Annex A variant. The ANSI type is the
default management type when encapsulation is set on the physical interface as
Frame Relay. JUNOS platforms do not support the Frame Relay Forum’s LMI
specification, which is a default for equipment made by other vendors; thus, watch for
interoperability issues. To alter the management protocol, issue the following
commands:
fo
[edit]
user@host# set interfaces so-0/1/1 encapsulation frame-relay
user@host# set interfaces so-0/1/1 lmi-type itu
ot
n
tio
d uc
ro
ep
Inverse ARP Operation
When a Frame Relay interface comes up, the Frame Relay switch announces the
configured DLCIs to the router. Once these DLCIs become active, some vendors might
rR
attempt to map the remote Network Layer address (that is, the IP address) to the local
DLCIs.
On the slide, Platform 1 learns about DLCIs 501 and 502 from the local Frame Relay
switch. If the remote DLCIs are active, Platform 1 sends an Inverse ARP request over
the active DLCIs to learn the IP addresses of the remote devices. Platform 1 then
fo
maps these Layer 2-to-Layer 3 addresses for use when routing packets between sites.
Inverse ARP is not used on point-to-point interfaces.
With Inverse ARP you can resolve the IP addresses of directly connected Frame Relay
peers. Thus, in the partial-mesh topology illustrated on the slide, reachability
problems between Platform 2 and Platform 3 might exist. Note that these two stations
ot
are not directly connected through the Frame Relay cloud. You can resolve this
problem in one of two ways: by configuring a full-mesh topology or by configuring a
point-to-point operation on the logical interfaces. In the latter approach, each
N
point-to-point link receives a unique IP number, whereas in the full-mesh scenario, all
routers comprising the Frame Relay mesh share a common IP subnet. Defining Frame
Relay connections as point-to-point eliminates the need for Inverse ARP and allows
packets exchanged between Platform 2 and Platform 3 to route through Platform 1.
n
tio
d uc
ro
ep
Physical Interface Troubleshooting
To troubleshoot Frame Relay, verify whether the problem is on the physical port or the
virtual circuit. You can troubleshoot using loops to determine where the problem lies.
rR
To verify the physical port, use the show interfaces extensive command and
ensure that no SONET/SDH, E3 and T3, or E1 and T1 alarm is present. If more than
one logical interface is configured, they will typically all be down if the port, cable, or
CSU/DSU device is faulty.
fo
n
tio
d uc
ro
ep
Physical Interface Troubleshooting
The approach for troubleshooting ATM is similar to that for Frame Relay—verify
whether the problem is on the physical port or the virtual circuit. To verify the physical
rR
port, use the show interfaces extensive command, and ensure that no
SONET/SDH, E3 or T3, or alarm is present. If more than one logical interface is
configured, they will typically all be down if the port, cable, or CSU/DSU device is
faulty.
You also can use loopback testing to determine where the problem lies.
fo
n
user@host# show
atm-options {
tio
vpi 0 {
maximum-vcs 200;
}
ilmi;
uc
}
unit 0 {
vci 100;
oam-period 10;
oam-liveness {
d
up-count 3;
down-count 3;
}
family inet {
address 10.0.16.1/24;
ro
}
ep
}
rR
fo
ot
N
n
tio
d uc
ro
ep
ATM Pings
An ATM ping can be either end to end or local segment.
rR
You can configure ILMI to communicate with directly attached ATM switches to enable
querying of the IP addresses and port numbers of the switches. To display ILMI
statistics, use the command show ilmi interface interface-name. The
router uses VC 0:16 to communicate with the ATM switch. This VPI and VCI pair is well
N
known.
To enable ILMI communications between the router and its directly attached ATM
switches, include the ilmi statement at the [edit interfaces
interface-name atm-options] hierarchy level:
[edit interfaces interface-name atm-options]
user@host# set ilmi
n
tio
d uc
ro
ep
Command Enhancements
The JUNOS Software show interfaces command has several features that make
dealing with multipoint interfaces easier:
rR
• show interfaces brief: Includes VPI, VCI, and DLCI values for
logical interfaces, including status and keepalive settings.
• show interfaces detail: Includes multipoint VPI and VCI to IP
address mappings.
fo
ot
N
n
tio
d uc
ro
ep
ATM Ping: End-to-End or Segment
You can use the atm option with the ping command to verify that the virtual circuit is
functional through the use of segment or end-to-end F5 (VC level) OAM cell flows. The
rR
key point is that these pings do not involve IP or ICMP, and, as such, are used to test
the ATM layer itself. As shown on the slide, a segment-level ATM ping is returned by the
device terminating that VC segment; typically this device is the ingress ATM switch
port, as shown in the case of Platform 2. In contrast, the end-to-end switch causes
the OAM cells to loop by the device, which terminates the VC, as shown in the case of
Platform 1 and Platform 3.
fo
ot
N
n
tio
d uc
ro
ep
Case Study
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Interface Troubleshooting Flowchart
The purpose of the interface troubleshooting flow chart shown on the slide is simply to
provide a set of high-level steps and decision points designed to get you started on the
rR
path of interface and transmission line troubleshooting. Note that reasonable people
might disagree on the exact ordering of the steps or on the particulars of the CLI
commands that could be used to help isolate an interface or circuit problem.
fo
ot
N
n
tio
d uc
ro
ep
Interface Case Study A: Background
The slide sets the stage for a sample interface troubleshooting case study. We begin
with a general description of the problem, which, in this case, indicates that the
rR
SONET link between the London and Tokyo devices appears to be down. In this
example the link-level protocol is cisco-hdlc with keepalives disabled. You can
assume that no chassis hardware problems or JUNOS Software faults exist.
Feeling Lucky?
fo
Based on this description you would be pretty lucky if you already knew the cause of
the problem. After all, it could be the SONET transmission link or the PIC or port at
either end, right? We suggest that you follow the general steps outlined on the sample
interface troubleshooting flow chart to get things started. Put another way, it might be
ot
n
tio
d uc
ro
ep
Interface Case Study A: Course of Action
The slide provides examples of troubleshooting steps based on the sample interface
troubleshooting flow chart. In this case, you begin by displaying the interface status for
rR
the so-0/1/1 interface at the Tokyo station. The results indicate that the interface is
up administratively but down at the link level.
You next display the status of the so-0/1/1 interface to determine if any media alarms
or errors are present. As called out by the comments, SONET alarms and defects are
present in the form of RDIs at the line and path levels. This media-specific alarm
fo
indicates that errors are occurring in the Tokyo-to-London direction. The fact that
Tokyo is receiving RDI indications implies that it can receive information sent from
London.
Note that at this time, the remote device (London) is displaying the following interface
alarms:
ot
n
tio
d uc
ro
ep
Interface Case Study A: Configuration
The next step is to conduct a loopback test designed to eliminate either the local
device or the transmission line and the remote device as possible sources for this
rR
problem. You can configure a local loopback at either end with similar results;
because you are at the Tokyo station, you decide to configure a local loopback there
first. Note that this loopback should succeed, assuming that the PIC and port are OK,
because of the specifics of the link-level protocol currently in effect (cisco-hdlc
with no-keepalives).
fo
After configuration, the local loopback status of the so-0/1/1 interface displays again.
The output confirms that the interface is now up at the link level. With the interface
up, you can test the loopback’s ability to pass data with ping traffic destined to the
remote end of the circuit (London’s address), as shown on the slide. The TTL expired
error message actually helps because it confirms that traffic is passing over the local
ot
loopback.
Continued on next page.
N
n
[edit]
user@Tokyo# commit and-quit
tio
commit complete
Exiting configuration mode
Note that because this loopback is internal and local, you have not fully tested the
so-0/1/1 interface at Tokyo; it would be best to attach an external loopback plug to
another device to conduct an external local loopback test. This technique has the
uc
added advantage of not requiring configuration to effect, and then again to remove, to
the loopback.
d
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
What Do These Results Indicate?
The results of your testing thus far indicate that the problem is not in Tokyo’s
so-0/1/1 interface. Thus, you now must perform a similar test at the London station to
rR
test at the London station also passes. This test eliminates the London station and
leaves the SONET transmission line as the most likely reason for the outage. Based on
this information, you should decide to escalate the problem to the transmission or
telco group.
ot
N
n
tio
d uc
ro
ep
Interface Case Study B: Background
The slide sets the stage for a second interface troubleshooting case study. We begin
with a general description of the problem, which, in this case, indicates that the
rR
SONET link between the San Jose and Montreal devices is not passing traffic, despite
both ends indicating an Up status at the Data Link Layer. The slide notes that
keepalives are disabled at both ends. In this example you can assume that a local
loop has been conducted at both ends with the expected results, which tends to
identify the SONET transmission facility as the culprit. The problem is that the SONET
transmission line retuned as no trouble found (NTF), which leaves you scratching your
fo
head.
Note that in this example, you are not permitted to view the interface-related
configuration at either end.
ot
Feeling Lucky?
Based on this description, you would be pretty lucky if you already knew the cause of
N
the problem. While the symptoms indicate that the SONET transmission link is not the
problem, the fact that both ends pass a local loopback tends to indicate that each
router has a functional interface, yet for some reason the two ends do not want to
communicate.
Continued on next page.
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Interface Case Study B: Course of Action—Part 1
Suspecting a Layer 2 configuration mismatch, you begin by displaying extensive
interface information for the so-0/1/1 interfaces at the San Jose and Montreal
rR
stations while you attempt to ping the local router’s address from the remote end of
the circuit. The results indicate detection of input errors at both ends. Policed discards
occur at the San Jose station. These errors indicates receipt of traffic for an
unconfigured protocol. In the case of Montreal, Layer 2 channel errors are detected.
This error indicates receipt of traffic for an unconfigured logical interface.
fo
n
tio
d uc
ro
ep
Interface Case Study B: Course of Action—Part 2
You decide to use the JUNOS CLI monitor traffic utility to attempt reverse engineering
of the Layer 2 encapsulation currently in effect at both ends of the circuit, because
rR
you cannot view the configuration directly. In this example, you first establish a second
login to the tested device (using an out-of-band connection), so that you can monitor
the egress traffic that results from local ping attempts at the remote end of the circuit.
The first such test that is conducted at the San Jose station, confirms that ping traffic
leaves the so-0/1/0 interface with a rather basic form of encapsulation. Although the
fo
encapsulation type is not explicitly called out, the use of an EtherType code to identify
IP traffic indicates that this interface is configured for Cisco HDLC encapsulation. A
similar test conducted at the Montreal station clearly shows that its egress traffic
makes use of Frame Relay encapsulation.
With these results you can conclusively determine that the Layer 2 encapsulation
ot
parameters are mismatched between the two stations. Note that this mismatch would
have resulted in a link-down status if keepalives were not disabled.
Continued on next page.
N
n
Link flags : No-Keepalives
user@Montreal> show interfaces so-0/1/0 | match link
tio
Physical interface: so-0/1/0, Enabled, Physical link is Up
Link-level type: Frame-Relay, MTU: 4474, Clocking: Internal, SONET mode,
Link flags : No-Keepalives DTE
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Interface Case Study C: Background
The slide sets the stage for a third interface troubleshooting case study. We begin with
a general description of the problem, which, in this case, indicates that the Ethernet
rR
link between the San Jose and Montreal devices appears to be in Down state.
Note that in this example, you are not permitted to view the interface-related
configuration at either end.
fo
ot
N
n
tio
d uc
ro
ep
Interface Case Study C: Course of Action
Several reasons might exist for an Ethernet links to be in the Down state. The reasons
include:
rR
n
tio
d uc
ro
ep
Interface Case Study C: Check the Ethernet Interface Details
Suspecting a Layer 2 configuration mismatch, you begin by displaying media interface
information for the ge-0/1/0 interfaces at the San Jose and Montreal stations. The
rR
show command indicates that the interface’s autonegotiation is enabled, which is the
default behavior. Also, you see that the negotiation status is Incomplete.
fo
ot
N
n
tio
d uc
ro
ep
Interface Case Study C: Solution
To fix the problem, you ensure that both local and remote devices can successfully
autonegotiate the connection parameters. If that does not solve the problem, you
rR
explicitly configure San Jose and Montreal stations to operate in the desired mode
with autonegotiation disabled. In our case the autonegotiation succeeded. Now the
interface status is Up, as illustrated:
user@San_Jose> show interfaces ge-0/1/0 media
Physical interface: ge-0/1/0, Enabled, Physical link is Up
fo
. . .
Autonegotiation information:
Negotiation status: Complete
Link partner:
Link mode: Full-duplex, Flow control: Symmetric/Asymmetric, Remote
fault: OK
Local resolution:
Flow control: Symmetric, Remote fault: Link OK
n
tio
d uc
ro
ep
This Chapter Discussed:
• Physical and logical interface properties;
• Deactivating and disabling interfaces;
rR
n
tio
uc
d
ro
ep
Review Questions
1.
rR
2.
3.
fo
4.
ot
N
n
tio
d uc
ro
ep
Lab 3: Interface Troubleshooting
The slide shows the objective for this lab.
rR
fo
ot
N
n
tio
uc
d
ro
ep
rR
fo
ot
N
n
tio
Chapter 6: JTAC Processes, Guidelines, and
Support Resources
d uc
ro
ep
rR
fo
ot
N
Troubleshooting JUNOS Platforms
n
tio
d uc
ro
ep
This Chapter Discusses:
• Support entitlement and opening a support case;
• Support resources;
rR
n
tio
d uc
ro
ep
Opening a Support Case
The slide lists the topics we cover in this chapter. We discuss the highlighted topic
first.
rR
fo
ot
N
n
tio
d uc
ro
ep
Support Entitlement
Juniper Networks offers support only to customers with valid maintenance contracts.
Therefore, you must provide a chassis serial number when opening a support case so
rR
that JTAC can verify your support status. Use a show chassis hardware
command to obtain your chassis serial number:
user@host> show chassis hardware
Hardware inventory:
Item Version Part number Serial number Description
fo
n
tio
d uc
ro
ep
Opening a Case
Customers can open support cases using the Case Manager (from within the CSC), or
over the telephone. Note that you should always follow up a Priority 1 case with a
rR
phone call to JTAC, even when you opened the case using the Case Manager or e-mail.
by capturing the output of relevant CLI commands. You might consider also capturing
the output of a request support information command; this command is
actually a macro that executes a large number of operational mode commands. While
the output is lengthy, adding this information might prevent the need to follow up with
additional command output once your case is under analysis.
ot
N
n
tio
d uc
ro
ep
Case Management
Case management details and procedures are provided at https://www.juniper.net/
support/guidelines.html. This document defines case priority levels, escalation
rR
to end customers.
• Priority 4 (Low): No impact to business operations. Examples of Priority 4
issues include information requests.
Continued on next page.
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Access Support Services
You must have a valid CSC login to access Juniper Networks support services over the
Web. Point your browser to https://www.juniper.net/support/csc/ to display the CSC
rR
login screen. Note that below the login, you can click links to request an account or to
manage the passwords associated with your existing CSC account.
fo
ot
N
n
tio
d uc
ro
ep
Support Services
The slide highlights the topics we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
The Customer Support Center
The slide displays the top of the main CSC welcome page. From this page you can
easily link to case management, technical research, software downloads, and so
rR
forth.
fo
ot
N
n
tio
d uc
ro
ep
Using Case Manager
Many customers prefer to open and manage their cases with the point-and-click ease
offered by the Case Manger tool. In addition to opening a case, the Case Manager
rR
provides a handy way of tracking the status of your open cases, Return Materials
Authorization status, and so forth.
fo
ot
N
n
tio
d uc
ro
ep
Research Problems
When you access the CSC, you are privy to a wealth of technical support information in
the form of the JTAC Knowledge Base, the PR (bugs) database, technical bulletins, and
rR
white papers that provide configuration examples and technology primers. You can
access the research area of the CSC at
https://www.juniper.net/customers/csc/research/index.jsp.
fo
ot
N
n
tio
d uc
ro
ep
The I2J Tool
The I2J tool is a utility that converts Cisco IOS configurations to the equivalent JUNOS
Software configuration. The slide shows an example of the I2J tool in use to convert
rR
The warnings regarding unsupported protocols, like AppleTalk and IPX, should not
come as a great surprise:
Lines that could not be converted are in red. Lines with warnings or comments
are in blue.
ot
Lines that have previously elicited an error or warning are in magenta and
their error or warning is suppressed.
FPC / PIC / Port numbers MUST ALWAYS be changed to match your Juniper Networks
hardware. 1:interface Ethernet0 This interface was converted to a FAST ethernet
N
n
tio
d uc
ro
ep
Software Download
Customers with valid support contracts can download the latest version of JUNOS
Software from https://www.juniper.net/customers/csc/software/index.jsp.
rR
Encryption = Weapon
The use of software with strong encryption might be subject to arms-related export
restrictions. You might have to complete an encryption agreement form before being
fo
n
tio
d uc
ro
ep
Technical Documentation Download
You can download technical documentation for all JUNOS products from
http://www.juniper.net/techpubs/. You do not need a CSC login.
rR
fo
ot
N
n
tio
d uc
ro
ep
How to Use FTP to Send Files to JTAC
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Transferring Core Files to Juniper Networks
You should always submit core files to JTAC for fault analysis. The slide outlines the
recommended procedures for transferring core files to JTAC:
rR
n
8. Upload the compressed and renamed core or memory image file using a
put or mput command.
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Transferring Core Files to Juniper Networks: Part 1
The slide illustrates the recommended procedures for transferring a core file to JTAC
using FTP. The example begins with a user escaping to a root shell and then changing
rR
into the /var/tmp directory. We assume that the user already has knowledge that a
process has left a core file in this directory.
In this example, the SNMP process has left a core file with context in the form of a
compressed .tgz archive. Manual compression of the file (using gzip file-name)
is not necessary in this case.
fo
The user modified the original permissions on the core file with a chmod 444
command to ensure that all users will have the read access required to perform stack
trace analysis on the file.
The user renamed the file to reflect the assigned case number; in this example the
ot
sequence number is set to 01 to indicate the first core file submitted in conjunction
with this case. Note that when renaming the file you should preserve any .tgz or .gz
extensions so that the recipient knows whether the file is compressed, a tar archive,
or both.
N
The slide ends with the successful establishment of an anonymous FTP session to the
Juniper Networks FTP site.
n
tio
d uc
ro
ep
Transferring Core Files to Juniper Networks: Part 2
This slide continues the example started on the previous slide. Note that the user’s
FTP client defaults to a binary transfer mode, which is confirmed in the FTP server’s
rR
output. Thus, the user does not have to switch into binary/image mode manually in
this example.
After connecting to the Juniper Networks FTP site, the user changes into the
/pub/incoming directory and uses the mkdir command to create a new directory
that is named according to the assigned case number. The user then changes into this
fo
directory and makes use of the mput command to upload the file. The mput
command supports wildcards (meta characters), which makes the exact specification
of the file name unnecessary. The user confirms that the
2004-12345-snmpdcore-01.tgz file should transfer, and the FTP client
confirms successful upload. After the file transfers, the user breaks the FTP session
ot
n
tio
d uc
ro
ep
This Chapter Discussed:
• Support entitlement and opening a support case;
• Support resources;
rR
n
tio
d uc
ro
ep
Review Questions
1.
rR
2.
3.
fo
4.
ot
N
n
tio
Appendix A: JUNOS Platform Details
d uc
ro
ep
rR
fo
ot
N
Troubleshooting JUNOS Platforms
n
tio
d uc
ro
ep
This Appendix Discusses:
• Primary components and characteristics of multiservice routers
(M Series and T Series);
rR
• End-of-life products.
ot
N
n
tio
d uc
ro
ep
Components and Characteristics of Multiservice Routers
The slide highlights the topics we cover in this appendix. We discuss the highlighted
topic first.
rR
fo
ot
N
n
tio
d uc
ro
ep
M7i and M10i Multiservice Edge Router Overview
The M7i and M10i Multiservice Edge Routers build on the proven performance and
success of the M5 and M10 platforms by offering integrated IP services and Ethernet
rR
interface support, or Routing Engine (RE) and Packet Forwarding Engine (PFE)
redundancy, in the case of the M7i and M10i, respectively.
The M7i and M10i forward packets at an aggregate throughput rate of 6.4 Gbps and
12.8 Gbps, respectively.
The M7i is the Juniper Networks high-performance customer premise equipment
fo
(CPE) offering, targeting campuses and large offices needing very secure,
dependable, high-speed WAN connectivity. The M7i delivers unprecedented
processing power for secure connectivity and the simultaneous support of multiple
services in a single platform. Combined with modular flexibility and easy-to-manage
JUNOS Software, the M7i is the choice for consolidating multiple platforms and
ot
support. You can order the M7i Compact Forwarding Engine Board (CFEB) with both
an integral Smart IP Services PIC and an Adaptive Services PIC (AS PIC) to support
additional service offerings such as Network Address Translation (NAT). Note that the
integral AS PIC is not a field-replaceable unit (FRU); to add AS PIC functionality, order a
new CFEB or install an AS PIC in one of the M7i’s four PIC slots.
Continued on next page.
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
M7i and M10i Hardware Components
The hardware components for the M7i and M10i are the following:
• Sheet metal chassis.
rR
• Two power supplies (AC or DC): The maximum chassis power is 274 watts
for the M7i and 427.2 watts for the M10i with a full complement of PICs
(8) and full redundancy. Power supplies can be either AC or DC (but not
both simultaneously); when two are installed, power is load-balanced.
fo
• Fan assemblies.
• Routing Engines: The RE maintains the routing tables and controls the
routing protocols, as well as the JUNOS Software processes that control
the router's interfaces, the chassis components, system management,
and user access to the router. These routing and software processes run
ot
on top of a kernel that interacts with the PFE. The M10i supports
redundant REs.
• Compact Forwarding Engine Boards: The CFEB provides PFE
N
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
M7i and M10i Craft Interface
The M7i and M10i Craft Interface provides connections for access to the local RE. You
can achieve access using any of the following:
rR
terminal-type command.
The M7i platform’s Fixed Interface Card (FIC) or the M10i platform’s High-Availability
Chassis Manager (HCM) card supports PIC online and offline buttons and alarm LEDs.
N
You should take PICs offline before removing them from the chassis using the
respective PIC online and offline button located on the FIC or HCM. After inserting a
PIC into the chassis, press and hold the online and offline button to activate power to
that PIC. When installed, the Adaptive Services PIC shares PIC slot 1/2/0 with the
internal Tunnel Services PIC. The two PICs contend for the approximate 1 Gbps of
bandwidth associated with the M7i platform’s 1/2/0 PIC slot.
n
tio
d uc
ro
ep
Side-to-Side Cooling
The M7i, M10i, and M20 incorporate side-to-side cooling using one to four fan trays.
The M20’s cooling system consists of the following subsystems:
rR
• Front cooling subsystem: Three front fan trays that cool the Flexible PIC
Concentrators (FPCs) and the System and Switch Board (SSB). These fan
trays are on the left front side of the chassis.
• Rear cooling subsystem: One rear fan tray that cools the RE. This fan tray
is immediately to the right of the RE.
fo
• Power supply integrated fan: A built-in fan that cools each power supply.
In the case of the M20, the four fan trays work together to provide side-to-side cooling.
The fan trays plug directly into the router midplane. Each front fan tray is a single FRU
that contains three fans. The rear fan tray is a FRU that contains two fans. Both front
ot
hot-insertable, and it connects directly to the router midplane. The failure of any one
fan does not effect the operation of the remaining fans, which can continue to run
indefinitely in the face of a single fan failure.
Continued on next page.
n
if the high-temperature condition persists.
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
M40e Multiservice Edge Router Overview
Like the M40, the M40e is specifically for the specialized needs of high-growth
Internet backbone providers, with its 40+ Gbps forwarding rate and enhanced
rR
redundancy.
The M40e is primarily for the edge aggregation market. The M40e provides RE and
PFE redundancy and the ability to hot-swap PICs. The M40e can support true OC48C
(STM16) PICs when equipped with FPC2. In contrast, an OC48C interface is a
quad-wide PIC and FPC combination on the M40 and M20 platforms. Note that
fo
n
tio
d uc
ro
ep
FPC1 and FPC2
The M40e supports two types of FPCs. The platform can operate with any combination
of FPC1s and FPC2s installed. The best way to determine the FPC type is by the
rR
n
tio
d uc
ro
ep
M120 Multiservice Edge Router Major Components
The major components of the M120 from the front view are the following:
• ESD point: Consists of two electrostatic discharge (ESD) points (banana
rR
• FPCs: The FPC slots on the router are two-PICs wide and two PICs tall,
allowing four Type 1 or Type 2 PICs and one Type 3 PIC to share power
circuits and a CPU and still fit in a quarter rack. Up to four FPCs install
vertically in the front of the router. Additionally, the M120 has slots for
ot
two compact FPCs (cFPCs). These cFPCs contain an entire PFE and Type
3 PIC in a PIC-sized form factor.
• Fan tray: All chassis fans are redundant. In a failure situation, the Control
N
n
REs in the router. The REs install into the rear of the chassis, directly into
the Control Board, in vertical slots labeled CB0 and CB1.
tio
• Control Boards (CBs): Each CB works with an installed RE to provide
control and monitoring functions for the router. These functions include
determining RE mastership, controlling power and reset for the other
router components, connecting the FEBs, monitoring and controlling fan
speed, and monitoring system status. You can install one or two CBs in
uc
the router.
• Forwarding Engine Boards (FEBs): The FEBs provide route lookup and
forwarding functions from the PICs and cFPCs. The midplane architecture
allows any FEB to carry traffic for any FPC. Depending on the bandwidth
d
and streams of the FEB, it can carry the traffic of multiple FPCs. To
provide redundancy, the FPC-FEB connections combine with 20 Gbps of
ro
bandwidth between each pair of cards. System software configuration
determines which FPCs a given FEB supports and configures switches on
the FEB or FPC accordingly. In addition, in the event of a FEB failure, a
standby FEB can quickly take over packet forwarding.
ep
• Power Entry Modules (PEMs): The M120 is configurable with either two
AC power supplies or two DC power supplies. If one power supply fails or
you remove it, the remaining power supply instantly assumes the entire
electrical load. Each AC power supply has two AC appliance inlets that
rR
require a dedicated AC power feed. For 100-120 VAC, both inlets are in
use. For 200-240 VAC, only one inlet is in use. Each AC power supply can
draw up to 28 amps at 100 VAC. DC power supplies can draw up to 60
Amps at -48 VDC.
fo
ot
N
n
tio
d uc
ro
ep
M120 FPCs
M120 FPCs are classified identically to T Series FPCs, as types 1, 2, or 3, and have the
same performance capabilities. In addition, the M120 supports the new cFPCs, which
rR
is an entire Type 3 FPC and PIC combination, leveraging the space savings of the I 2.0
chip over the LMNR chipset. As a result, it consumes approximately the same space
as a traditional PIC. The M120 has two cFPC slots for uplinks. Sample interface types
available as cFPCs are the OC192 and 10 Gigabit Ethernet.
fo
ot
N
n
tio
d uc
ro
ep
M120 Cooling
The diagram on the slide shows the airflow pathways in the M120. During normal
operation, the fans in each fan tray function at less than full speed. The CB constantly
rR
n
tio
d uc
ro
ep
M320 Multiservice Edge Router Overview
The M320 is a high performance, 10-Gbps-capable, distributed-architecture edge
router. It offers up to 16 OC192c (STM64) PICs per chassis (32 per rack) or up to
rR
64 OC48c (STM16) ports per chassis (128 per rack) with up to 320 Gbps throughput.
The M320 is ideal for medium-sized backbone cores requiring predictable
performance for feature-rich infrastructures, and it also supports provider edge
services in 10 gigabit points of presence with the ability to support up to 32 Type 1
and Type 2 PICs and up to 16 Type 3 PICs for 10 Gbps uplinks. In addition, this
platform is ideal where switching fabric and RE redundancy are necessary. All major
fo
n
tio
d uc
ro
ep
Front-to-Rear Cooling
The cooling systems on the M40e and M320 consist of two separate subsystems—
front and rear. The front cooling subsystem consists of an upper impeller and a lower
rR
fan tray; it cools the FPCs, the PICs, and the midplane. The front impeller and fan tray
are both hot-insertable and hot-removable.
The rear cooling subsystem consists of a pair of impellers that cool the Switching and
Forwarding Modules (SFMs), RE, Miscellaneous Control Subsystem (MCS), the Packet
Forwarding Engine Clock Generators (PCGs), and the power supplies. Each rear
fo
impeller is hot-insertable and hot-removable. The upper and lower impellers are not
interchangeable.
Systems with front-to-back cooling generally support metal-screen air filters that might
become contaminated with dirt or other debris. You should inspect and clean these
filters periodically. You should never run the system with the air filters removed,
ot
because it might ingest foreign objects, causing damage to the system. In many
cases, the air filters also provide electromagnetic interference (EMI) shielding.
N
n
tio
d uc
ro
ep
M320 Hardware Components
The hardware components for the M320 include the following:
• Four AC or DC power supplies: The maximum chassis power is
rR
3150 watts (65 A at -48 VDC) when fully loaded. Each AC supply provides
power to all components. In the DC power configuration, the DC power
supplies in slots PEM0 and PEM2 are load-sharing and provide power to
the FPCs in slots FPC3 through FPC7. The DC power supplies in slots
PEM1 and PEM3 are load-sharing and provide power to the FPCs in slots
fo
FPC0 through FPC2, Switch Interface Boards (SIBs), CBs, and REs. All DC
power supplies provide power to the fan trays. The DC power supplies are
fully redundant. The DC power supplies in slots PEM0 and PEM1 can
provide full power to the router. Likewise, the DC power supplies in slots
PEM2 and PEM3 can also provide full power. The DC power supply in
ot
PEM2 serves as the backup to the DC power supply in slot PEM0, and the
DC power supply in PEM3 serves as the backup to the DC power supply in
slot PEM1.
N
n
switch fabric, and all are in use in normal operation. The failure of a SIB
results in a a 25% reduction of switching capacity, which is handled
gracefully.
tio
• Connector Interface Panel (CIP).
• Flexible PIC Concentrators: Up to eight Type 1, Type 2, or Type 3 FPCs; you
can mix FPC types can be mixed.
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Three Types of FPCs
The M320 associates with FPC Type 1, Type 2, and Type 3. The different FPC types
accommodate the reuse of existing M Series PICs as well as the use of native T Series
rR
PICs. The M320 supports any combination of FPC1, FPC2, or FPC3 in a single chassis.
The M320 uses the same LMNR chipset as the T640 and T320 platform.
fo
ot
N
n
tio
d uc
ro
ep
Distinguishing M320 FPC Types
The M320 supports three types of FPCs. The platform can operate with any
combination of FPC types installed. The best way to determine the FPC type is by the
rR
The offline buttons for FPC1 are on the FPC faceplate. PICs compatible with an FPC2
have an offline button on their faceplate. PICs compatible with an FPC3 have a plastic
ejector handle at the top of their faceplate.
n
tio
d uc
ro
ep
The T640 Core Router Overview
Each half-rack T640 core router supports 32 10-Gbps ports or 128 OC48c (STM16)
ports, and each slot handles 80 Gbps of aggregate throughput, fulfilling the need for
rR
The T640 is for the core of large service provider networks. It targets roles requiring a
high density of 10 Gbps interfaces.
The T640 system is the first Juniper Networks product based on the T640 Series set
N
of ASICs. The ASIC set allows for the building of a distributed system providing up to
320 Gbps of forwarding capacity in half of a 7 foot rack. Each slot in a T640 core
router chassis can contain up to two T640 PFEs. Each PFE provides 20 Gbps of
forwarding capacity. With eight FPC slots in the chassis, 320 Gbps of forwarding
capacity per router are available.
Continued on next page.
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
T640 Major Components
The major components of the T640 from the front view are the following:
• ESD point: Consists of two electrostatic discharge points (banana plug
rR
• Fan tray: All chassis fans are redundant. In a failure situation, the Control
Board is responsible for increasing the speed of the remaining fans to
provide the necessary cooling.
Continued on next page.
n
component of the base chassis. The second is necessary for redundant
configurations. Each RE operates in a protected memory environment
tio
that limits the effect of a software process failing.
• Control Board: Provides control and monitoring functions for the chassis.
A CB associates with each RE to provide control redundancy. The active
CB always associates with the active RE. One CB is necessary for chassis
uc
operation and is a standard part of the LCC. The second is necessary for
redundant system configurations where a second RE is present.
• SONET Clock Generator: The T640 provides SONET clocking through the
SCGs. The SONET clocks generate on each SCG and distribute to all
d
receiver modules along with a signal mux select, indicating which clock is
active and, therefore, which clock is the master.
•
ro
Power supplies: The T640 uses a distributed power entry mechanism to
allow for modularity, lower current, and easier hot-swapping. Each Power
Entry Module (PEM) requires two 65 amp DC feeds. One PEM is
necessary for chassis operation and runs the router indefinitely. The
ep
second PEM is necessary for redundancy. Both PEMs are a standard part
of the chassis. They are hot-swappable and load-sharing. A fully loaded
T640 can draw up to 6,500 watts (68 A at -48 VDC per input; note that
each PEM has two inputs).
rR
fo
ot
N
n
tio
d uc
ro
ep
The T320 Core Router
The T320 core router is the industry’s most compact 10 Gbps routing platform, fitting
three chassis to a rack. While fully leveraging the T Series architecture and
rR
leading-edge T Series ASICs, the T320 offers significant gains in form factor, power
consumption, and bandwidth density. Designed for a breadth of applications, the
T320 is ideal for multiservice transit, peering, metro Ethernet aggregation, data center
aggregation, and carrier-of-carrier VPNs.
As an entry point into the T Series routing family, the T320 delivers unprecedented
fo
n
tio
d uc
ro
ep
T320 Major Components
The major components of the T320 from the front view are the following:
• ESD point: Consists of two ESD points (banana plug receptacles)—one in
rR
port. Each FPC contains data memory, which is managed by the Queuing
and Memory Interface ASICs.
• Craft Interface: Allows you to view status and troubleshooting information
at a glance and to perform many system control functions.
ot
• Fan tray: All chassis fans are redundant. In a failure situation, the CB is
responsible for increasing the speed of the remaining fans to provide the
necessary cooling.
Continued on next page.
n
• Routing Engine: The T320 contains up to two identical REs. One RE is
necessary for LCC operation and is a standard component of the base
tio
chassis. The second is necessary for redundant configurations. Each RE
operates in a protected memory environment that limits the effect of a
software process failing.
• Control Board: Provides control and monitoring functions for the chassis.
uc
A CB associates with each RE to provide control redundancy. The active
CB always associates with the active RE. One CB is necessary for chassis
operation and is a standard part of the LCC. The second is necessary for
redundant system configurations where a second RE is present.
d
• SONET Clock Generator: The T320 provides SONET clocking through the
SCGs. The SONET clocks generate on each SCG and distribute to all
receiver modules along with a signal mux select, indicating which clock is
ro
active and, therefore, which clock is master.
• Power supplies: The T320 uses a distributed power entry mechanism to
allow for modularity, lower current, and easier hot-swapping. Each Power
ep
Entry Module requires a single 65 amp DC feed. One PEM is necessary
for chassis operation and runs the router indefinitely. The second PEM is
necessary for redundancy. Both PEMs are a standard part of the chassis.
They are hot-swappable and load sharing. A fully loaded T320 can draw
rR
n
tio
d uc
ro
ep
T Series FPC Types
T Series platforms associate with FPC Type 1, Type 2, and Type 3. The different FPC
types accommodate the reuse of existing M Series PICs in the newer T Series
rR
platforms.
The T320 supports any combination of FPC1, FPC2, or FPC3 in a single chassis. In all
cases each T320 FPC supports a maximum of two PICs. The Type 1 FPC supports
legacy M Series PICs and is rated at 3.2 Gbps of aggregate throughput. As noted on
the slide, the FPC1 is supported only in the T320. The T320 FPC2 is rated at 10 Gbps
fo
installed. The T640 does not support FPC1. The T640 FPC2 contains a single PFE
complex, while the FPC3 contains two complete PFEs.
N
n
tio
d uc
ro
ep
T Series PIC Numbering
The slide details typical port numbering for common T Series PICs.
rR
fo
ot
N
n
tio
d uc
ro
ep
Components and Characteristics of Ethernet Services Routers and
Switches
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Chassis Description
The MX960 Ethernet Services router is an Ethernet-optimized edge router that
provides both switching and carrier-class Ethernet routing. The MX960 has a capacity
rR
of up to 480 gigabits per second (Gbps), full duplex. The MX960 enables a wide range
of business and residential applications and services, including high-speed transport
and VPN services, next-generation broadband multiplay services, and high-volume
Internet data center internetworking. The MX960 is 16 rack units (RU) tall. You can
stack three routers in a single floor-to-ceiling rack, for increased port density per unit
of floor space. The router provides 14 slots that you can populate with up to
fo
12 interface cards and two Switch Control Boards (SCBs) in nonredundant fabric
configurations. Fully populated, the MX960 provides up to 480 Gigabit Ethernet or up
to 48 10-Gigabit Ethernet ports. Two types of Dense Port Concentrator (DPC) interface
cards are available, both of which consist of four PFEs and enable a throughput of
10 Gbps:
ot
Hardware Features
The midplane is in the center of the chassis and forms the rear of the DPC card cage.
The DPCs and SCBs install into the midplane from the front of the chassis, and the
power supplies install into the midplane from the rear of the chassis. The power
supplies and cooling system components also connect to the midplane.
The MX960 chassis provides redundancy and resiliency. The hardware system is fully
redundant, including power supplies, fan trays, REs, and SCBs.
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Power and Cooling
In the AC power configuration, the router contains three or four AC power supplies,
located vertically at the rear of the chassis in slots PEM0 through PEM3 (left to right).
rR
Each AC power supply provides power to all components in the router. When three
power supplies are present, they share power almost equally within a fully populated
system.
Four AC power supplies provide full power redundancy. If one power supply fails or you
remove it, the remaining power supplies instantly assume the entire electrical load
fo
without interruption. Three power supplies provide the maximum configuration with
full power for as long as the router is operational.
In the DC power configuration, the router contains either two or four DC power
supplies located at the lower rear of the chassis in slots PEM0 through PEM3 (left to
right). You can upgrade your DC power system from two to four power supplies. The DC
ot
power supplies in slots PEM0 and PEM2 provide power to the lower fan tray, DPC slots
6 through 11, and SCB slots 1 and 2. The DC power supplies in slots PEM1 and PEM3
provide power to the upper fan tray, DPC slots 0 through 5, and SCB slot 0.
N
Four power supplies provide full redundancy. If a DC power supply fails, its redundant
power supply takes over without interruption.
The cooling system components work together to keep all router components within
the acceptable temperature range. The router has two fan trays located in the front of
the router that install horizontally above and below the DPC card cage. Each fan tray
contains six fans. The fan trays are interchangeable and are hot-insertable and
hot-removable.
n
tio
d uc
ro
ep
Types of Line Cards
Three types of DPCs are available for MX Series routers: DPCE-X, DPCE-R, and DPCE-Q.
The DPCE-X builds upon the Juniper Networks leadership position in providing
rR
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
MX960 Component Placement
The slide shows the placement of the hardware components on the front of the
device.
rR
fo
ot
N
n
tio
d uc
ro
ep
Chassis Description
The MX480 Ethernet Services router is an Ethernet-optimized edge router that
provides both switching and carrier-class Ethernet routing. The MX480 has a capacity
rR
of up to 240 Gbps, full duplex. The MX480 enables a wide range of business and
residential applications and services, including high-speed transport and VPN
services, next-generation broadband multiple services, and high-volume Internet data
center internetworking.
The MX480 is eight RU tall. You can stack five routers in a single floor-to-ceiling rack,
fo
for increased port density per unit of floor space. The router provides eight slots that
you can populate with up to six DPC cards and two SCBs in nonredundant fabric
configurations.
Fully populated, the MX480 provides up to 240 Gigabit Ethernet or up to 24 10-Gigabit
Ethernet ports. Six types of DPC cards are available, each of which consists of four
ot
Hardware Features
The midplane is in the center of the chassis and forms the rear of the DPC card cage.
The DPCs and SCBs install into the midplane from the front of the chassis, and the
power supplies install into the midplane from the rear of the chassis. The power
supplies and cooling system components also connect to the midplane.
The MX chassis provides redundancy and resiliency. The hardware system is fully
redundant, including power supplies, REs, and SCBs.
n
tio
d uc
ro
ep
Power and Cooling
In the AC power configuration, the router contains three or four AC power supplies,
located vertically at the rear of the chassis in slots PEM0 through PEM3 (left to right).
rR
Each AC power supply provides power to all components in the router. When three
power supplies are present, they share equally within a fully populated system.
Four AC power supplies provide full power redundancy. If one power supply fails or you
remove it, the remaining power supplies instantly assume the entire electrical load
without interruption. Three power supplies provide the maximum configuration with
fo
and SCB slots 0 and 1. The DC power supplies in slots PEM1 and PEM3 provide power
to the fan tray and DPC slots 2 through 5.
Four power supplies provide full redundancy. If a DC power supply fails, its redundant
N
n
tio
d uc
ro
ep
Chassis Description
The MX240 Ethernet Services router delivers increased port density over traditional
carrier Ethernet platforms as well as performance of 200+ Gbps throughput,
rR
Hardware Features
ot
The midplane is in the center of the chassis and forms the rear of the DPC card cage.
The DPCs and SCBs install into the midplane from the front of the chassis, and the
power supplies install into the midplane from the rear of the chassis. The power
N
n
tio
d uc
ro
ep
Power and Cooling
The MX240 supports either the low-line (110V) AC power configuration or the high-line
(220V) AC power configuration.
rR
In the low-line AC power configuration, the MX240 contains either two non-redundant
AC power supplies—located horizontally at the rear of the chassis in slots PEM0 and
PEM2 (left to right)—or four redundant AC power supplies, located in slots PEM0
through PEM3 (left to right). The low-line configuration requires two power supplies,
and the third and fourth power supplies provide redundancy. Each AC power supply
fo
provides power to all components in the router. When two power supplies are present,
they share power almost equally within a fully populated system. If one power supply
in a redundant configuration fails or you remove it, the remaining power supplies
assume the entire electrical load without interruption. Two power supplies provide the
maximum configuration with full power for as long as the router is operational.
ot
n
router is operational.
Each DC power supply has a single DC input (-48 VDC and return) that requires a
tio
dedicated 40 A (-48 VDC) circuit breaker for the maximum router hardware
configuration. The DC power supply is PEM0 must receive power from dedicated
power feeds derived from feed A, and the DC power supply in PEM2 must receive
power from dedicated power deeds derived from feed B. This configuration provides
uc
the commonly deployed A and B feed redundancy for the system. Four power supplies
provide full redundancy. If a DC power supply fails, its redundant power supply takes
over without interruption.
The cooling system components work together to keep all router components within
d
the acceptable temperature range. The router has one fan tray and one air filter that
install vertically in the rear of the router. The fan tray contains six fans. The fan tray is
hot-insertable and hot-removable.
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Switch Control Board
The slide displays a picture of the RE and SCB board as well as a graphic
representation of the RE. The three RJ45 connectors on the RE contain the aux port,
rR
n
tio
d uc
ro
ep
Fabric Redundancy
You can install up to three SCBs in the router. Two SCBs are necessary to run the
router and the third functions as the backup. The third installed SCB provides fabric
rR
redundancy, but no additional control or routing functions. If the master fails or you
remove it, the backup restarts and becomes the master. In a nonredundant fabric
configuration the loss of an SCB will not bring down the system but will cause a
degradation in forwarding rate.
fo
RE Redundancy
You can install one or two REs in the router. The REs install into the front of the chassis
in vertical slots directly into the SCBs labeled 0 and 1. If two REs are present, one
functions as the master and the other acts as the backup. If the master RE fails or you
ot
remove it, and the backup configuration is appropriate, the backup takes over as the
master.
N
n
tio
d uc
ro
ep
Switch Control Board
You can install one or two SCBs in the router. If two SCBs are present, one functions as
the master SCB and the other as its backup. If the master fails or you remove it, the
rR
RE Redundancy
You can install one or two REs in the router. The REs install into the front of the chassis
fo
in vertical slots directly into the SCBs labeled 0 and 1. If two REs are present, one
functions as the master and the other acts as the backup. If the master RE fails or you
remove it, and the backup configuration is appropriate, the backup takes over as the
master.
ot
N
n
tio
d uc
ro
ep
Switch and Control Board
You can install one or two SCBs in the router. If two SCBs are present, one functions as
the master SCB and the other as its backup. If the master fails or you remove it, the
rR
RE Redundancy
You can install one or two REs in the router. The REs install into the front of the chassis
fo
in vertical slots directly into the SCBs labeled 0 and 1. If two REs are present, one
functions as the master and the other acts as the backup. If the master RE fails or you
remove it, and the backup configuration is appropriate, the backup takes over as the
master.
ot
N
n
tio
d uc
ro
ep
DPC Media Types
All DPCs come as either SFPs or XFPs which use the most optimal port density with
cost efficiency.
rR
Line Rate
Each DPC has connections to the switch fabric providing line-rate connectivity for each
port on the card.
fo
the network and sends outgoing packets to the network. Each DPC contains four PFEs.
The PFEs on the DPC have purpose-built ASICs that perform packet processing and
forwarding. Each PFE consists of one I-chip for Layer 3 processing and one Layer 2
N
network processor.
n
tio
d uc
ro
ep
DPC Types
The DPCs are optimal for Ethernet density and can support up to 40 Gigabit Ethernet
or 4 10-Gigabit Ethernet ports.
rR
DPC-R Features
The DPCs support a wide range of Layer 2 and Layer 3 Ethernet functionality, including
802.1Q virtual LAN (VLAN), link aggregation, circuit cross-connect, Virtual Router
fo
n
tio
d uc
ro
ep
High Performance EX8200 Platform
EX8200 Series Ethernet switches come in two types, EX8208 and EX8216. The
EX8200 Series switches are modular in nature and are designed for ultra high-density
rR
n
tio
d uc
ro
ep
Redundant Power and Cooling
EX8200 switches provide high availability and redundancy for all major hardware
components—including RE modules, switch fabric modules (SFMs), fan trays (with
rR
redundant fans), and load-sharing 2000 watt AC, 3000 watt AC, and 3000 watt DC
power supplies.
EX8200 switches deploy proven Juniper Networks technology, which includes REs,
switch fabric, and PFEs. The RE modules are hot-insertable and hot-removable and
install in the front of the chassis. The SFMs are also hot-insertable and hot-removable,
and install in the rear of the chassis. The EX Series deploys the industry-proven JUNOS
Software.
ot
N
n
tio
d uc
ro
ep
EX4200 Virtual Chassis Technology
The Juniper Networks EX4200 Ethernet Switches with virtual chassis technology
combine the high availability and carrier-class reliability of modular systems with the
rR
10-Gigabit Ethernet uplink ports. Different models can mix in a virtual chassis
configuration to provide a variety of port and density options.
ot
N
n
tio
d uc
ro
ep
Flexible Uplink Modules
You can deploy a single 24-port or 48-port switch initially; as requirements grow,
Juniper Networks virtual chassis technology allows up to 10 EX4200 switches to
rR
interconnect over a 128 Gbps backplane, which you can manage as a single device,
delivering a scalable, pay-as-you-grow solution for expanding network environments.
Flexible Gigabit Ethernet and 10-Gigabit Ethernet uplink options enable high-speed
connectivity to aggregation-layer or core-layer switches which connect multiple floors
or buildings.
fo
ensure maximum uptime. In addition, the base EX4200 switch models offer Class 3
Power over Ethernet (PoE), delivering 15.4 watts on the first eight ports to support
networked devices such as telephones, video cameras, and wireless LAN (WLAN)
access points for low-density converged networks. Full PoE options delivering
N
15.4 watts on all 24 or 48 ports are also available, making them ideal for high-density
IP telephony deployments.
JUNOS Software
The EX4200 switches leverage the modular JUNOS Software, ensuring consistent
implementation and operation.
n
tio
d uc
ro
ep
Fixed Configuration
The EX3200 fixed-configuration switches from Juniper Networks offer a
high-performance standalone solution for access-layer deployments in branch and
rR
Uplink Modules
The EX3200 line also supports optional 4 port Gigabit Ethernet and 2 port 10-Gigabit
fo
Featuring complete Layer 2 and Layer 3 switching capabilities, the EX3200 switches
satisfy the wiring closet connectivity requirements of today’s high-performance
businesses. Four platform configurations are available offering 24 and 48 10, 100,
N
and 1000BASE-T ports with either full or partial PoE. The base 24-port and 48-port
EX3200 switches deliver a full 15.4 watts of Class 3 PoE on the first eight ports for
supporting networked devices such as telephones, video cameras and WLAN access
points in converged networks. The EX3200 switches with full PoE deliver 15.4 watts
on all 24 or 48 ports to support high-density IP telephony and other converged
network environments.
Continued on next page.
JUNOS Software
The EX3200 switches run the same JUNOS Software used by Juniper Networks
routers to power the world’s largest and most complex networks.
By utilizing a common operating system, Juniper Networks delivers a consistent
implementation and operation of control-plane features across all products—functions
ranging from chassis management to Spanning Tree to OSPF. To maintain that
consistency, the JUNOS Software adheres to a highly disciplined development process
that utilizes a single source code, follows a single quarterly release train, and employs
n
a highly available modular architecture that prevents isolated failures from bringing an
entire system down.
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Primary Components and Characteristics of Security Services Gateways
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Feature Integration
The feature integration on SRX Series Services Gateways is enabled by JUNOS
Software. The SRX line is equipped with a robust list of features that include firewall,
rR
Intrusion Detection and Prevention (IDP), denial of service (DoS) protection, Network
Address Translation (NAT), and quality of service (QoS).
Scalability
fo
JUNOS Software
The SRX Series runs on the proven JUNOS Software which is based on a modular
N
design offering a single-source operating system for the network. Unlike any other
product on the market, it provides one operating system, enhanced through one
release, and developed based on a single modular architecture.
n
tio
d uc
ro
ep
SRX5600 and SRX5800 Details
The SRX5600 uses the same SPCs and IOCs as the SRX5800.
As the brain behind the SRX Series services gateway, the SPCs process all available
rR
services on the gateway. Without the need for dedicated hardware for specific
services or capabilities, no instances occur in which a piece of hardware is taxed to
the limit while other hardware sits idle. All of the processing capabilities of the SPCs
process all configured services on the gateway. The same SPCs are supported on both
the SRX5600 and SRX5800. To provide the most flexible solution, SRX Series services
fo
gateways employ the same modular architecture for SPCs and IOCs. You can equip the
SRX Series services gateway with one or several IOCs, with each IOC supporting 40
gigabit interfaces (4 x 10 Gigabit Ethernet or 40 x 1 Gigabit Ethernet).
ot
N
n
tio
d uc
ro
ep
SRX3400 and SRX3600 Modules
The SRX3600 and SRX3400 support common form-factor modules (CFM). A
single-wide module format and a double-wide module format are available. All
rR
single-wide CFMs can insert in any single-wide slot in the front and rear of the chassis.
Similarly, all double-wide CFMs can insert in any double-wide slots. DPC, SPC, and
Network Processing Card (NPC) modules are in single-wide CFM format. The SCB, the
RE, and the CB are not in CFM format, and thus have assigned slots within the
chassis. With the interchangeability among DPC, SPC, and NPC, you have more
flexibility and scalability when deploying your networks based on the requirements in
fo
the field. For example, if you need more ports and a bigger oversubscription ratio, then
you can load more slots with DPCs; on the other hand, if you need a smaller
oversubscription ratio for better QoS behavior, or if you need more security services,
then you can load more slots with SPCs. With this arrangement, only the onboard
network interface ports are in use. SRX5600 and SRX5800 cards are not
ot
n
tio
d uc
ro
ep
SRX5800 Major Components
The slide presents a pictorial view of the SRX5800 and its major components.
rR
fo
ot
N
n
tio
d uc
ro
ep
SRX5600 Major Components
The slide presents a pictorial view of the SRX5600 and its major components.
rR
fo
ot
N
n
tio
d uc
ro
ep
SRX Major Components
The slide presents a pictorial view of the SRX3600 and its major components.
rR
fo
ot
N
n
tio
d uc
ro
ep
SRX3400 Front View
The slide presents a pictorial view of the SRX3400 and its major components from the
front.
rR
fo
ot
N
n
tio
d uc
ro
ep
SRX3400 Rear View
The slide presents a pictorial view of the SRX3400 and its major components from the
rear.
rR
fo
ot
N
n
tio
d uc
ro
ep
SRX210 Major Components
The slide presents a pictorial view of the SRX210 and its major components.
rR
fo
ot
N
n
tio
d uc
ro
ep
End-of-Life Products
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
End-of-Life Products
The following slides are from earlier versions of this course. We include them for the
benefit of customers with older products.
rR
fo
ot
N
n
tio
d uc
ro
ep
M5 and M10 Overview
The M5 and M10 routers deliver high performance and highly-flexible interfaces in a
space-efficient and power-efficient design. These routers use the same architecture,
rR
ASICs, and JUNOS Software as the already proven M Series routers. This
Internet-tested core technology is now available at your network edge, along with
value-added services, such as packet filtering and sampling.
The oversized forwarding performance of the Internet Processor II ASIC provides
wire-speed forwarding with plenty of headroom. In fact, the M5 and M10 routers
fo
forward packets at an aggregate throughput rate of 6.4 Gbps and 12.8 Gbps,
respectively.
The M5 and M10 are ideal for edge applications involving the aggregation of
dedicated access circuits. They are also ideal for core applications in locations where
space and power are at a premium, such as smaller metro points of presence. The
ot
n
tio
d uc
ro
ep
M5 and M10 Hardware Components
The hardware components for the M5 and M10 are the following:
• Sheet metal chassis.
rR
• Two power supplies (AC or DC): The maximum chassis power is 340 watts
for the M5 and 434 watts for the M10. Power supplies can be either AC
or DC (but not both simultaneously); when two are present, power is
load-balanced.
fo
• Fan assembly.
• Routing Engine: The RE maintains the routing tables and controls the
routing protocols, as well as the JUNOS Software processes that control
the router's interfaces, the chassis components, system management,
and user access to the router. These routing and software processes run
ot
n
tio
d uc
ro
ep
M5 and M10 Craft Interface
The M5 and M10 Craft Interface supports PIC online and offline buttons, alarm LEDs,
an alarm cutoff and lamp test button, and the ports used to connect to the routing
rR
engine. Ensure that you take PICs offline before removing them from the chassis using
the PIC online and offline buttons located below each respective PIC. After inserting a
PIC into the chassis, press and hold the online and offline button to activate power to
that PIC.
You can achieve access to the local RE using any of the following:
fo
This port is disabled by default and you must activate it with a set
system ports auxiliary type terminal-type command.
Note that you must remove power to the chassis before removing or installing the FEB.
You can swap the RE with power still applied, but doing so results in a system reboot.
n
tio
d uc
ro
ep
M20 Overview
The M20 is a high-performance routing platform built for a variety of Internet
applications, including high-speed access, public and private peering, hosting sites,
rR
and network applications. The primary application for the M20 is currently edge
aggregation of dedicated access circuits.
The M20 leverages proven M Series ASIC technology to deliver wire-rate performance
and rich packet processing, such as filtering, sampling, and rate limiting. It runs the
same JUNOS Software and supports the same interfaces as other M Series routers,
fo
providing a seamless upgrade path that protects your investment. Its compact design
(14 inches or 35.56 cm high) delivers market-leading performance and port density
while consuming minimal rack space. You can install as many as five M20 units into a
single 19-inch equipment rack.
ot
N
n
tio
d uc
ro
ep
M20 Hardware Components
The hardware components for the M20 include the following:
• Sheet metal chassis.
rR
• Two power supplies (AC or DC): The maximum chassis power draw is
1200 watts. Power supplies can be either AC or DC, but you cannot mix
power supply types. When two power supplies are present, power is
load-balanced between them.
fo
Although the M20 supports RE and system board redundancy, hot PIC swapping is not
available. To replace or install a PIC, you must first remove the target FPC from the
system. Removing or inserting an FPC results in an approximately 100 millisecond
period of packet loss. Be sure to gracefully remove the FPC by depressing the FPC
offline button until the green OK light extinguishes. Upon insertion, the FPC
automatically comes back online.
n
tio
d uc
ro
ep
M40 Overview
The M40 was the first platform shipped by Juniper Networks. Although it is still
supported, newer platforms, such as the M40e, are eclipsing the original M40 due to
rR
improvements in redundancy, form factor, and support for newer PIC types.
fo
ot
N
n
tio
d uc
ro
ep
M160 Overview
The M160 was the first full-performance OC192c (STM64) platform on the market. By
providing aggregate forwarding rates of 160 Mbps and aggregate throughput
rR
exceeding 160 Gbps, this platform enables you to grow networks rapidly and reliably
while taking advantage of increased optical bandwidth.
An ASIC-based packet forwarding path enables full wire-rate forwarding over 10 Gbps
circuits. Key to this performance is the Internet Processor II ASIC and the custom
made SONET processing ASIC used in the OC192c (STM64) interface.
fo
The M160 offers a complete range of flexible and dense interfaces, allowing you to fit
M160 routers into existing environments seamlessly. The platform supports up to 32
OC48c (STM16) PICs per chassis (64 per standard rack) or up to eight OC192c
(STM64) PICs per chassis (16 per rack).
ot
The M160 provides a scaleable solution using the same JUNOS Software and the
same ASICs, and supporting the same value-added services as all other M Series
routers.
N
n
tio
d uc
ro
ep
M160 Hardware Components
The hardware components for the M160 include the following:
• Two DC-only Power Entry Modules: The maximum chassis power is 3150
rR
watts (65 A at -48 VDC) when fully loaded. When both PEMs are present,
power to the chassis is load-balanced between them.
• Sheet metal chassis.
• Redundant cooling.
fo
• One or two host modules: RE and MCS work in pairs for host module
redundancy. The MCS provides control of chassis power, environmental
control systems, online and offline of system components and Stratum 3
synchronization reference.
ot
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
This Appendix Discussed:
• Primary components and characteristics of multiservice edge routers
(M Series and T Series);
rR
• End-of-life products.
ot
N
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
Appendix B: Packet Flow Details
d uc
ro
ep
rR
fo
ot
N
Troubleshooting JUNOS Platforms
n
tio
d uc
ro
ep
This Appendix Discusses:
• Real-time operating system (RTOS) packet flow;
• ABC chipset packet flow; and
rR
n
tio
d uc
ro
ep
RTOS Packet Flow
The slide highlights the topics we cover in this appendix. We discuss the highlighted
topic first.
rR
fo
ot
N
n
tio
d uc
ro
ep
Packet Processing
The J Series Routing Engine (RE) and software Packet Forwarding Engine (PFE) are
both implemented on the primary x86 architecture microprocessor. An RTOS kernel
rR
mediates access to the underlying hardware. The real-time kernel ensures that
operating system services go out in a constant, load-independent, amount of time.
This process ensures that the forwarding and services real-time threads deliver
predictable packet forwarding performance.
While the software handles packet forwarding decisions with the virtual PFE, the Intel
fo
n
tio
d uc
ro
ep
ABC Chipset Packet Flow
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
ABC ASICs
The slide displays the application-specific integrated circuits (ASICs) that make up an
ABC chipset router’s PFE. We detail the function of each ASIC on subsequent slides. In
rR
ABC chipset platforms the ASICs that comprise the PFE are in the PICs, FPCs, and the
System Board. The M7i and M10i routers combine Flexible PIC Concentrators (FPCs)
and System Board functionality into the Compact Forwarding Engine Board (CFEB).
The CFEB makes use of a combined I/O manager ASIC, Distributed Buffer Manager
ASIC, and Internet Processor II ASIC to reduce cost and power consumption while also
improving reliability. This ASIC set is sometimes referred to as the ABC ASIC in keeping
fo
with the internal ASIC designation of A, B, and C for the Distributed Buffer Manager, I/
O Manager, and Internet Processor II ASICS, respectively.
ot
N
n
tio
d uc
ro
ep
ABC Chipset Packet Flow: Part 1
When a packet arrives on an input interface of the router, the PIC controller ASIC
performs all the media-specific operations such as Physical Layer framing and Data
rR
Link Layer FCS (CRC) verification. The PIC then passes a serial stream of bits to the
I/O Manager ASIC on the FPC.
fo
ot
N
n
tio
d uc
ro
ep
ABC Chipset Packet Flow: Part 2
The I/O Manager ASIC parses the bit stream to locate the Layer 2 and Layer 3
encapsulation and chops the packet into 64-byte chunks named J-cells. These J-cells
rR
n
tio
d uc
ro
ep
ABC Chipset Packet Flow: Part 3
The Distributed Buffer Manager 1 ASIC receives J-cells from each FPC’s I/O Manager
ASIC and writes them into the shared memory bank. The shared memory bank is
rR
n
tio
d uc
ro
ep
ABC Chipset Packet Flow: Part 4
The Internet Processor II ASIC determines the ultimate destination for every packet
arriving on a transit interface. The Internet Processor ASIC consults a copy of the
rR
forwarding table, which contains destination prefixes and their corresponding next
hops. The RE constructs the forwarding table and the JUNOS Software kernel
maintains it.
After the Internet Processor II ASIC determines the packet’s egress interface and
forwarding next hop, it amends the notification cell with this information and passes
fo
the notification cell to the second Distributed Buffer Manager ASIC. The second
Distributed Buffer Management ASIC then passes the notification cell to the I/O
Manager ASIC on the egress FPC (as identified by the modified contents of the
notification cell). The Distributed Buffer Manager 2 ASIC acts as an agent for the FPC’s
I/O Manager ASIC. Once the I/O Manager ASIC receives a notification cell indicating
ot
that a packet is waiting for servicing, it issues read requests to the Buffer Manager 2
ASIC for the J-cells associated with the packet. As the I/O Manager receives the J-cells,
it transmits them to the PIC Controller ASIC, which in turn transmits them out the
appropriate port.
N
In the case of a multicast packet, multiple outgoing interfaces might exist, in which
case the notification cell is directed to multiple FPCs or to the same FPC multiple
times—once for each outgoing interface served by that FPC.
n
tio
d uc
ro
ep
ABC Chipset Packet Flow: Part 5
When the egress FPC is ready to service the packet, the I/O Manager ASIC issues read
requests for the 64-byte J-cells that comprise the packet. In response, the Distributed
rR
Buffer Manager 2 ASIC retrieves the J-cells from shared memory and feeds them to
the I/O Manager ASIC. The I/O Manager ASIC reassembles the packet, decrements
the packet’s TTL, adds the Layer 2 framing, and then sends the bit stream to the
egress PIC.
The I/O Manager ASIC is responsible for class-of-service (CoS)-related queuing,
fo
scheduling, and congestion avoidance operations at packet egress. Note that the
packet itself never queues on the FPC; rather, a pointer to the packet, in the form of a
notification cell, queues on the egress FPC. Each output port on a given PIC
associates with four forwarding classes (or queues). You configure schedulers to
provide each forwarding class with some share of the port’s bandwidth.
ot
Note that traffic classification, which associates traffic with one of the defined
forwarding classes, occurs at the ingress FPC. Once identified at ingress, the traffic is
handled in accordance with the parameters configured for that traffic class by the I/O
N
Manager on the egress FPC. The I/O Manager implements the random early detection
(RED) algorithm during egress processing to avoid tail drops and the resulting risk of
global synchronization of TCP retransmissions. A full coverage of JUNOS Software CoS
capabilities is beyond the scope of this class.
n
tio
d uc
ro
ep
LMNR Chipset Packet Flow
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
LMNR Chipset PFE
The term Packet Forwarding Engine is used as a collective noun to describe the
collection of components that work together to perform longest-match lookups and
rR
• Media-Specific ASIC: Each PIC type is equipped with one or more ASICs
specifically designed to handle the needs of a particular medium. For
example, a SONET PIC is equipped with an ASIC that handles SONET
framing and alarm generation.
ot
• Layer 2 and Layer 3 Processing ASIC: After the PIC performs the
medium-specific functions, the bit stream travels to the Layer 2 and
Layer 3 processing ASIC, which removes Layer 2 encapsulation, parses
N
the Layer 3 header, and segments the bit stream into 64-byte chunks.
Continued on next page.
n
of data between LMNR chipset PFEs by facilitating the exchange of
64-byte chunks across the LMNR chipset cross-bar switch fabric.
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
The LMNR Chipset Switch Fabric
LMNR chipset platforms use a nonblocking cross-bar switch fabric to switch traffic
between the system’s FPCs. The Switch Interface Board (SIB) instantiates the switch
rR
fabric and contains the F16 ASIC. SIBs interface to each FPC through high-speed lines
(HSLs) that terminate on the SIB’s F16 ASIC. The F16 ASIC provides a 16x16 matrix of
high-speed I/O lines. Each HSL can support 10 Gbps of half-duplex traffic. By
connecting each FPC to two of the F16’s HSLs, 10 Gbps of full-duplex capacity
(20 Gbps aggregate throughput) occurs between that FPC and SIB. Each FPC
connects to multiple SIBs to provide the speed-up needed for a nonblocking switch
fo
Redundant Fabric
The slide illustrates the specifics of a T320 platform’s switch fabric. In this case, each
FPC (or PFE) has four HSL connections to both SIB 1 and SIB 2. This switch fabric
provides the T320 FPC with 40 Gbps of aggregate capacity. To accommodate SIB
failures, each T320 FPC also connects to a third SIB (SIB 0) using a single HSL. In
normal operation, SIB 1 and 2 are active while SIB 0 functions in hot standby mode.
SIB 0 automatically becomes active in the event of SIB 1 or SIB 2 failure. However,
because each FPC interconnects to SIB 0 through a single HSL, switch fabric speedup
reduces. The reduction in speedup results in a graceful degradation of the T320
n
platform’s switch fabric that might result in some packet loss. The T640 platform
makes use of five SIBs in a similar configuration, with the exception that all FPCs
tio
attach to all SIBs using two HSLs. The result is that a T640 platform’s switch fabric
remains nonblocking despite the presence of a possible SIB failure. Multiple SIB
failures results in graceful degradation of the T640 switch fabric capacity.
Note that the M320 platform is similar to the T320 platform in that the failure of one
uc
of its four SIBs results in graceful degradation of forwarding capacity.
d
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
LMNR Chipset Packet Flow: Part 1
A tour of packet flow through an LMNR chipset routing node begins with the arrival of
traffic on the incoming PIC interface.
rR
The media-specific ASIC on the ingress PIC handles the required Physical Layer
signaling, framing, and medium-specific alarm generation. The PIC passes the stream
of bits to the Layer 2 and Layer 3 ASIC on the FPC along with an indication that the
frame arrived without errors (no CRC error detected).
fo
ot
N
n
tio
d uc
ro
ep
LMNR Chipset Packet Flow: Part 2
The Layer 2 and Layer 3 Packet Processing ASIC performs Layer 2 and Layer 3
parsing. The Layer 2 and Layer 3 ASIC also divides the packets into 64-byte J-cells. The
rR
The Layer 2 and Layer 3 Processing ASIC also performs BA traffic classification to
associate traffic with a forwarding class for egress queuing and scheduling
operations. Examples of BA classification include IP precedence and DiffServ code
points.
ot
N
n
tio
d uc
ro
ep
LMNR Chipset Packet Flow: Part 3
The Switch Interface ASIC extracts the route lookup key (comprised of the first 64
bytes of data in the Layer 3 packet), places it in a notification cell, and passes the
rR
notification to the LMNR chipset Internet Processor. The Switch Interface ASIC then
passes the remaining data cells to the Queuing and Memory Interface ASICs. These
ASICs manage the shared memory switch fabric associated with each LMNR chipset
PFE. Note that the shared memory fabric facilitates the switching of packets within a
specific PFE complex, such as the switching that occurs when the source and
destination PICs share a PFE.
fo
ot
N
n
tio
d uc
ro
ep
LMNR Chipset Packet Flow: Part 4
The Queuing and Memory Interface ASICs pass the received J-cells to the PFE’s
memory for buffering in the shared memory fabric within the PFE. Note that the
rR
cross-bar switch fabric is used only to exchange packets between PFE complexes.
While the J-cells write into shared memory, the LMNR chipset Internet Processor II
ASIC performs a route lookup operation on the key data. The modified notification cell
then forwards to the Queuing and Memory Interface ASIC.
In addition to queuing notifications, the Queuing and Memory Management ASIC also
fo
packets from the queue before it is completely full. The drop probability is
programmable, and this process is part of the TCP congestion control
mechanism.
N
n
tio
d uc
ro
ep
LMNR Chipset Packet Flow: Part 5
At this stage of the packet’s processing, the Queuing and Memory Interface ASIC
sends the notification cell to the Switch Interface ASIC that faces the switch fabric,
rR
unless the destination is a port on the same PFE. In this case, the notification travels
to the Switch Interface ASIC that faces the Layer 2 and Layer 3 Processing ASIC.
Packets exchanged between ports on a common PFE do not transit the switch fabric.
The Switch Interface ASIC sends bandwidth requests through the switch fabric to the
destination PFE for those destinations that reside on another PFE. The Switch
fo
Interface ASIC also issues read requests to the Queuing and Memory Interface ASIC to
begin reading data cells out of memory when the egress PFE (and the switch fabric)
indicates it is ready to handle a given J-cell.
ot
N
n
tio
d uc
ro
ep
LMNR Chipset Packet Flow: Part 6
The destination Switch Interface ASIC returns bandwidth grants through the switch
fabric to the originating Switch Interface ASIC in response to received bandwidth
rR
requests.
Upon receipt of each bandwidth grant, the originating Switch Interface ASIC sends a
cell through the switch fabric to the destination PFE.
fo
ot
N
n
tio
d uc
ro
ep
LMNR Chipset Packet Flow: Part 7
The destination Switch Interface ASIC receives cells from the switch fabric. Once
again, the Switch Interface ASIC extracts the route lookup key and forwards the
rR
notification cell to that PFE’s Internet Processor II ASIC for a second longest-match
lookup operation. Note that this notification cell is modified to reflect the new memory
locations for the related J-cells, because the memory locations for each chunk varies
by PFE.
The LMNR chipset Internet Processor II ASIC in the destination PFE performs a second
fo
route lookup and forwards the notification to the Queuing and Memory Interface ASIC.
The results of this route lookup include details regarding the egress PFE PIC, port, and
required encapsulation.
ot
N
n
tio
d uc
ro
ep
LMNR Chipset Packet Flow: Part 8
The Queuing and Memory Interface ASIC is responsible for performing CoS functions
for egress traffic. These CoS functions include the selection of notification cells from
rR
the head of each queue for submission to the Switch Interface ASIC, RED-related
discards, and policing and rate shaping.
The Queuing and Memory Management ASIC forwards a modified notification cell (the
cell now includes next-hop information) to the Switch Interface ASIC when the CoS
algorithms dictate that a given packet should receive service.
fo
The Switch Interface ASIC sends read requests to the Queuing and Memory Interface
ASIC to read the data cells out of memory and passes the cells to the Layer 2 and
Layer 3 Packet Processing ASIC.
ot
N
n
tio
d uc
ro
ep
LMNR Chipset Packet Flow: Part 9
The Layer 2 and Layer 3 Packet Processing ASIC reassembles the data cells into
packets. The Layer 2 and Layer 3 processing ASIC then adds appropriate Layer 2
rR
encapsulation and sends the resulting bit stream to the egress PIC.
The Layer 2 and Layer 3 Processing ASIC is responsible for CoS-related queuing,
scheduling, and congestion avoidance operations at packet egress. Each output port
on a a given PIC associates with four forwarding classes (or queues). You configure
schedulers to provide each forwarding class with some share of the port’s bandwidth.
fo
Note that traffic classification, which associates traffic with one of the defined
forwarding classes, occurs at the ingress FPC. Once identified at ingress, the traffic is
handled in accordance with the parameters configured for that traffic class by the
Layer 2 and Layer 3 Processing ASIC on the egress FPC. The Layer 2 and Layer 3
Processing ASIC implements the RED algorithm during egress processing to avoid tail
ot
A full coverage of JUNOS Software CoS capabilities is beyond the scope of this class.
n
tio
d uc
ro
ep
LMNR Chipset Packet Flow: Part 10
The final steps in egress packet processing begin when the egress PIC sends the
packet out into the network with the appropriate Physical Layer signaling and
rR
medium-specific framing. The egress PIC also calculates and adds a cyclic
redundancy check (CRC) to the frame as needed for each particular medium.
fo
ot
N
n
tio
d uc
ro
ep
Exception Packets
Exception packets require some form of special handling. Examples of exception
traffic include the following:
rR
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
This Appendix Discussed:
• RTOS packet flow;
• ABC chipset packet flow; and
rR
n
tio
d uc
ro
ep
rR
fo
ot
N
n
APS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Automatic Protection Switching
ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Address Resolution Protocol
tio
AS PIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adaptive Services PIC
ASIC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .application-specific integrated circuit
ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Asynchronous Transfer Mode
BERT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . bit error rate test
BPV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . bipolar violation
uc
CB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Control Board
CDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cisco Discovery Protocol
CE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . customer edge
CFEB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Compact Forwarding Engine Board
d
CFM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .cubic feet per minute
CIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Connector Interface Panel
ro
CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .command-line interface
CoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . class of service
CoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . class-of-service
CPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . customer premises equipment
ep
CRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . cyclic redundancy check
CSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Customer Support Center
DCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . data circuit-terminating equipment
DLCI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .data-link connection identifier
DoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . denial of service
rR
HA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .high availability
ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Control Message Protocol
IDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . initial domain part
IGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . interior gateway protocol
ILMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Integrated Local Management Interface
IOC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .input/output card
JNTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Juniper Networks Technical Certification Program
JTAC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Juniper Networks Technical Assistance Center
LCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Link Control Protocol
n
NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Address Translation
NBMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . nonbroadcast multiaccess
tio
NCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Control Protocol
NSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .nonstop active routing
NTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Time Protocol
OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operation, Administration, and Maintenance
uc
PCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . protocol control block
PCG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Packet Forwarding Engine Clock Generator
PE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . provider edge
PEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Privacy-Enhanced Mail
PFE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Packet Forwarding Engine
d
PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Physical Interface Module
PoE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Power over Ethernet
ro
POP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . point of presence
PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Point-to-Point Protocol
PVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . permanent virtual circuit
RDI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . remote defect indication
ep
RE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing Engine
RED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . random early detection
REI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . remote error indication
RMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Return Materials Authorization
rpd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . routing protocol process
rR
n
Chapter 2: Overview of JUNOS Platforms
1.
tio
To safely power off an M Series router, you must perform a graceful shutdown of JUNOS
Software before removing power. Use the request system reboot command, which
causes the device to reboot.
uc
2.
The RE is the brains of the platform; it is responsible for performing routing updates and system
management. The RE runs various protocol and management software processes inside a
protected memory environment. The PFE is responsible for forwarding transit packets through
d
the router using an ASIC-based switching path.
3. ro
The Craft Interface is the collection of mechanisms on some JUNOS platforms that allow you to
view system status messages and troubleshoot the router. The Craft Interface is located on the
front of the chassis and typically consists of various system status LEDs and FPC (or PIC) online
ep
and offline buttons. On supported platforms the Craft Interface includes an LCD screen that
provides status reporting for the entire system.
4.
Interface name at-0/1/1.100 references a logical unit 100 of the ATM interface in FPC 0, PIC
rR
1, and port 1.
The three ways in which the CLI can help to perform fault analysis are: (1) deployment of key
commands; (2) process restart and bringing hardware online and offline; and (3) deployment of
network and diagnostic utilities.
n
You can reset the OSPF process without affecting other routing protocols by deactivating OSPF
in the configuration mode and then committing the configuration file. This approach requires
you to have configuration privileges.
tio
Chapter 4: JUNOS Platforms Hardware Troubleshooting
1.
uc
The correct procedure for powering off a JUNOS platform is as follows: First shutdown the
JUNOS Software using the CLI request system halt command. Next, turn off the power
supplies.
d
2.
You can use the JUNOS Software CLI to display information about the chassis and the PFE using
ro
the show chassis ... and show pfe ... commands to display information about the system
and software processes using the show system ... commands and to display system log files.
3.
ep
The two ways of determining if chassis alarms are present are using the show chassis
alarms command; and the show chassis craft-interface command.
4.
The following command searches the messages file for all lines matching fail and error:
rR
When you deactivate an interface, JUNOS Software completely ignores that specific interface
and does not apply it when you issue a commit command. When you disable an interface, it
activates when you issue a commit command but is treated as being down or administratively
disabled.
ot
2.
You can check the results of your BERT test using the show interfaces extensive
command.
N
3.
When troubleshooting T3 or E3 interface problems you must ensure that the two ends of the
circuit have the following compatible parameters: clocking, frame checksum, HDLC payload
scrambling (if using Cisco HDLC encapsulation), T3 line buildout, and T3 C-bit parity mode.
4.
You use the monitor interface interface-name command to display real-time
statistics about a physical interface. The output updates every second. The output of this
command also shows the amount that each field changes from the time you start the command
or from the time you clear the counters by using the c key.
n
Chapter 6: JTAC Processes, Guidelines, and Support Resources
tio
1.
You need a chassis serial number when opening a case. The serial number will help JTAC staff
to determine the support status.
2.
uc
When you access the CSC, you have a wealth of technical support information in the form of the
JTAC Knowledge Base, the PR database, technical bulletins, and white papers that provide
configuration examples and technology primers.
d
3.
The I2J tool converts Cisco IOS configuration into a JUNOS Software configuration. It is a good
ro
idea to inspect the output, ensuring that you obtained the desired results.
4.
You should use FTP to transfer files to JTAC when the size of those files is larger than 10 MB.
ep
rR
fo
ot
N