Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

3troubleshootingjunos

.pdf
Скачиваний:
21
Добавлен:
09.06.2015
Размер:
32.13 Mб
Скачать

Troubleshooting JUNOS Platforms

 

 

Reproduction

 

 

 

 

 

 

 

T1 and E1 Fault Isolation

 

 

When you confirm the s ttings on both ends but problems persist, you might want to

 

 

involve the lco for line and loop testing. Before suspecting the transmission line, you

 

 

should first perform local loopback testing at each end. You also should attempt

 

for

 

 

emote loopback requests to the far-end internal CSU.

 

 

RFC 2495

 

 

F additional information on E1 or T1 interface alarms and error conditions, you

 

 

sh uld consult RFC 2495, Definitions of Managed Objects for the DS1, E1, DS2, and

Not

E2 Interface Types.

 

 

 

Interface Troubleshooting • Chapter 5–51

Troubleshooting JUNOS Platforms

Not

Reproduction

 

 

 

Ping Testing with Patt

rns

You can use ping testing to

st a circuit, or, alternatively, to diagnose a problem with

the transmission circuit for E1 and T1. By changing the payload pattern, you can

detect problems with ones density and zero suppression code settings.

Testing the MTU

Y u sh uld set ping tests with patterns for payload with the size parameter to generate

rames cl

se to the interface’s MTU.

C ntinued

n next page.

for

Chapter 5–52 • Interface Troubleshooting

Troubleshooting JUNOS Platforms

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

5555: alternating ones and zeros.

 

JUNOS platforms also support BERT testing, as previously descr bed

n E1 and T1

 

interfaces. Because BERT testing is a far more definitive es , y

sh

uld c nsider

 

BERT testing when you suspect marginal performance or n erm

ent

perati n.

 

for

Reproduction

Not

 

 

 

 

 

 

 

Interface Troubleshooting • Chapter 5–53

Troubleshooting JUNOS Platforms

SONET/SDH HasReproductionEmb dd OAM

SONET/SDH transmission syst ms incorporate a multitude of Operation,

Administration, and Maint nance (OAM) functionalities at the line, section, and path

layers. Interpretation of the SONET/SDH errors is helpful in determining the source of

for

the p oblem within the SONET/SDH network. The information within the various

SONET/SDH counters is plentiful and, when properly interpreted, enables problem

localization. The following pages cover the commands available for SONET/SDH

tr

ublesh ting in the CLI.

L

calizing Errors

Not

 

Using the output from these commands, you can tell very easily where the problem lies on SONET/SDH links.

Continued on next page.

Chapter 5–54 • Interface Troubleshooting

Troubleshooting JUNOS Platforms

Path Level Visibility

Because JUNOS platforms function as path-terminating equipment (PTE), they have end-to-end visibility. The difficulty is learning what the various alarms indicate. Using show commands, you can easily determine the nature of SONET alarms and error indications. Note that to change framing to SDH, you must configure framing under the [edit chassis] hierarchy level:

chassis {

 

Reproduction

 

 

fpc 0 {

 

 

pic 0 {

 

 

framing sdh;

}

}

 

 

 

}

 

 

Not

for

 

 

 

Interface Troubleshooting • Chapter 5–55

Troubleshooting JUNOS Platforms

 

 

 

 

Reproduction

 

 

 

 

 

 

 

 

 

Monitoring SONET/SDH Int rfaces

 

 

The monitor int rface command can provide useful troubleshooting

 

 

information for the SONET/SDH int rface.

 

 

The statistics in the second column are the cumulative statistics from the last time the

 

for

 

 

 

 

 

clear inte faces statistics command cleared them. The statistics in the

 

 

thi d column a e the statistics from the last execution of the monitor interface

 

 

c mmand.

 

 

 

 

 

 

If the raming errors increase, check the FCS and scrambling configuration. If the

 

 

c n igurati

n is correct, check the cabling to the router, and have the carrier verify the

Not

integrity

the line.

If the input errors increase, check the cabling to the router, and have the carrier verify

 

 

he integrity of the line.

Chapter 5–56 • Interface Troubleshooting

Not

Troubleshooting JUNOS Platforms

DisplayingReproductionSONET/SDH Interface Status

If the first line shows Physical link is Up, it means that the physical link is healthy and can pass pack ts. If the first line shows Physical link is Down, it 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,

foruse the show interface so-x/y/z extensive command. Look at the active ala ms and active defects for the SONET/SDH interface, and troubleshoot the SONET/SDH media accordingly.

Interface Troubleshooting • Chapter 5–57

Troubleshooting JUNOS Platforms

SONET Path TraceReproduction

SONET and SDH framing ov rh ad 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 that is terminating the path layer. The slide shows the JUNOS Software default coding of the path t ace field, which is coded to identify the router and SONET interface name. This info mation can prove invaluable when the goal is to confirm the correct patching of a t ansmission line, or when you suspect that a loopback might be in effect. In this example the transmitted an received path trace information confirms that San J se is receiving its own transmitted path trace, which indicates that a

l pback is in place somewhere in the SONET transmission path.

Not

You can specify a custom path trace message with a set sonet-options

forpath-trace message statement at the [edit interfaces

sonet-interface-name] hierarchy. Note that custom path trace messages are not supported for ATM interfaces, which always use the default path trace coding.

Continued on next page.

Chapter 5–58 • Interface Troubleshooting

Troubleshooting JUNOS Platforms

SONET Path Trace (contd.)

In SONET framing mode the path trace is 64 bytes, while in SDH mode the standards define a 16 byte trace. The difference in size can result in a truncated path trace when operating in SDH mode. The following is additional information from the ITU-T G.707 specification (G.707, ITU-T, March 1996) on the use of the J1 byte:

 

“This byte is used to transmit repetitively a path access point identifier so that a path

 

receiving terminal can verify its continued connection to the intended tra smitter. A

 

16-byte frame is defined for the transmission of an access point ide tifier. This

 

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 etworks of

 

different operators, the format defined in clause 3/G.831 shall be used unless

 

otherwise mutually agreed by the operators oviding the ransp rt. W thin a national

 

network or within the domain of a single operator, this pa h access p nt dentifier may

 

use a 64-byte frame.”

 

for

Reproduction

Not

 

 

 

Interface Troubleshooting • Chapter 5–59

Troubleshooting JUNOS Platforms
SONET/SDH NetworkReproductionEl m nts
The regenerators are consid s -terminating equipment (STE). STEs are responsible only for th ir particular s of the SONET/SDH span, as opposed to the entire SONET/SDH network path from one device designated as PTE to the other.
forThey a e esponsible 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 ame arriving from its directly connected neighbor is good, while not having any kn wledge of the rest of the span. STEs look only at the section overhead bytes the SONET/SDH frame, even though they can rewrite the other overhead bytes if an alarm generates.
The add/drop multiplexers (ADMs) are considered line terminating equipment (LTE). Not LTEs have more knowledge of the SONET/SDH network than STEs, but they do not
perform final processing of the SONET/SDH payload as PTEs do (although they can 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.
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.

Chapter 5–60 • Interface Troubleshooting