3troubleshootingjunos

Reproduction

Troubleshooting M thodology

The slide highlights the topic we discuss next.

Not

for

Reproduction

Begin with a Visual Ins

ection

The slide provid s a f w g

ral troubleshooting tips. For example, it is generally a

good idea to b gin hardware or platform troubleshooting with a visual inspection. This

approach uses the keep it simple philosophy of life. If you happen to notice a black

for

smear that is indicative of smoke or fire damage near a component, you have most

likely b ought yourself closer to the source of a problem with little effort.

Kn w What Constitutes Normal Status

It might seem pretty basic, but how can you spot signs of anomalous behavior if you

Not

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

CPU usage is during a troubleshooting operation?

Always Confirm the Symptom

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.

Operators often overlook a potential s urce f

a pr blem because of their subjective

experiences. While leveraging your memo y and past actions against a current

problem is a good thing, you should never cl

se y ur mind to new possibilities.

Not

for

Reproduction

Modern Communications N tworks Are Layered

Modern communications tworks are complex. In 1977, the International Standards

Organization develop d a standard way of viewing these functions in the form of the

Open Systems Interconnection (OSI) model. While the specifics of the OSI model are

for

now mo e less i relevant given that TCP/IP is generally favored, the concept of a

laye ed communications architecture is still quite valid.

Unde standing the role that each layer plays and how each layer depends upon the

services

the layers that lie below it, can greatly simplify the task of locating the

elusive p

ssible cause of problems. Put simply, it is a waste of time to troubleshoot a

ailed Layer 3 connectivity when the Link Layer protocol (Layer 2) running over that

Not

circuit is in a down state because the underlying Physical Layer is experiencing a loss

of light alarm.

Matching Symptoms to the Root-Cause Layer Is Job Number 1

A chain is only as strong as the weakest link, and so, too, is a layered communications

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.

Once you correctly identify the root-cause layer, the next step is to isolate the problem

at that layer so you can take the appropriate corrective actions. For example, k owi g

that the issue relates to mismatched T1 an DS1 framing (Physical Layer) all ws you

to correct the problem by configuring both devices for compat ble fram ng to actually

resolve the fault.

for

Reproduction

Not

Reproduction

No HTTP Connectivity: A Rath

Generic Symptom

The slide helps illustrate the lay

approach to troubleshooting by providing a typical

communications topology and a rath r generic symptom.

As far as what layers can account for this problem, the best answer is all of them.

for

Specifically, a fault at the Physical, Data Link, Network, Transport, or Application

Laye s might exist.

Examples

possible faults and their scope include the following:

•

Physical Layer: Broken wires or glass, power levels, framing, transmission

line, or router or interface hardware could all be possible faults. This layer

Not

operates on a link-by-link basis.

•

Data Link Layer: Mismatched framing, lack of keepalives, or invalid

connection identifiers (data-link connection identifiers [DLCI] or virtual

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

gateway protocol (IGP) parameters that prevent adjacency formation

could all be possible faults. This layer operates end to end involving both

routers and end systems (hosts).

•

Transport Layer: Invalid ports, maximum transmission unit (MTU), lack of

Reproduction

Understanding Control and Forwarding Plane Separation

When troubl shooting JUNOS platforms, you must understand the separation of the

control and forwarding plan s, regardless if the separation occurs in hardware or

software. Generally speaking, problems with a routed network come down to either a

for

cont ol 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 c

nt ol plane primarily deals with the installation of routes in the forwarding table.

This function relies on routing protocols, configuration, authentication of routing

peers, and so forth. The most common symptom of a control plane problem is the lack

Not

of one

more routes.

Reproduction

Troubleshooting Tools: The JUNOS Software CLI

The slide highlights the topics we discuss next.

Not

for