Part 5: Monitor System Logs for Interface Related Information
Step 5.1
Monitor the system log and look for interface related entries. During this time the instructor will disconnect various cables:
lab@router> monitor start messages
♦ What type of information can you glean from the following log message?
*** messages ***
Aug 31 10:14:35 router mib2d[555]: SNMP_TRAP_LINK_DOWN: ifIndex 13, ifAdminStatus up(1), ifOperStatus down(2), ifName fe-0/0/0
Aug 31 10:14:35 router mib2d[555]: SNMP_TRAP_LINK_DOWN: ifIndex 15, ifAdminStatus up(1), ifOperStatus down(2), ifName fe-0/0/2
♦ What about these log entries?
Aug 31 10:16:12 router mib2d[555]: SNMP_TRAP_LINK_DOWN: ifIndex 21, ifAdminStatus up(1), ifOperStatus down(2), ifName so-0/1/1
Aug 31 10:16:12 router mib2d[555]: SNMP_TRAP_LINK_DOWN: ifIndex 20, ifAdminStatus up(1), ifOperStatus down(2), ifName so-0/1/0
Aug 31 10:16:13 router mib2d[555]: SNMP_TRAP_LINK_DOWN: ifIndex 25, ifAdminStatus up(1), ifOperStatus down(2), ifName so-0/1/0.0
Aug 31 10:16:16 router /kernel: so-0/1/1: Asserting SONET alarm(s) LOS
Aug 31 10:16:17 router /kernel: so-0/1/0: Asserting SONET alarm(s) LOS
Aug 31 10:16:17 router /kernel: so-0/1/0: Asserting SONET alarm(s) LOL
Aug 31 10:16:17 router /kernel: so-0/1/1: Asserting SONET alarm(s) LOL
. . .
Aug 31 10:19:08 router /kernel: so-0/1/1: Clearing SONET alarm(s) LOL LOS
Aug 31 10:19:08 router /kernel: so-0/1/0: Clearing SONET alarm(s) LOL LOS
Step 5.2
Search through your system log for all messages related to a particular interface:
lab@router> show log message | match <interface-name>
♦ How could you count the number of physical transitions on a SONET interface?
Part 6: Perform Loopback Testing (Optional)
Step 6.1
This portion of the lab is optional. Your instructor will inform you if the classroom equipment can support loopback testing. If the classroom equipment supports only fast ethernet interfaces, this section should be skipped. Based on the number of POS/ATM interfaces available, you may have to coordinate access with other classmates.
Unlike some vendors, JUNOS software does not send pings addressed to a local WAN interface out that interface. In other words, pinging the local address of a WAN interface does not generate traffic on the line. Many technicians have become accustomed to “testing the WAN link” by issuing such a ping. The following steps will illustrate how similar results can be achieved using a Juniper Networks router.
In order to succeed, the interface must stay “up” in the presence of the loopback. This requires that you use cisco-hdlc, frame-relay, or AAL 5 encapsulation and, that you
disable keep-alives. PPP encapsulation will not work, even with keep-alives disabled, as the IPCP and NCP protocols will fail to initialize resulting in the interface being declared down. The following example is based on a POS link between Denver and Sao Paulo using addresses 10.0.8.1 and 10.0.8.2 respectively and has Sao Paulo providing the remote loopback.
We begin with the so-0/1/0 configuration from Sao Paulo: [edit interfaces so-0/1/0]
lab@saopaulo# show no-keepalives; encapsulation cisco-hdlc; sonet-options { loopback remote; } unit 0 { family inet { address 10.0.8.2/24; } }
Step 6.2
We will now confirm that Denver’s so-2/2/0 is still up, and verify the operation of the WAN by pinging the remote address:
lab@Denver> show interfaces terse | match so-2/2/0 so-2/2/0 up up
so-2/2/0.0 up up inet 10.0.8.1/24
Good, the interface is up, despite the remote loopback on Sao Paulo. Now for a local ping test:
lab@Denver> ping 10.0.8.1 count 2 PING 10.0.8.1 (10.0.8.1): 56 data bytes
64 bytes from 10.0.8.1: icmp_seq=0 ttl=255 time=0.579 ms 64 bytes from 10.0.8.1: icmp_seq=1 ttl=255 time=0.449 ms
--- 10.0.8.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.449/0.514/0.579/0.065 ms
And now for the remote ping that is intended to test the transmission facility:
lab@Denver> ping 10.0.8.2 count 2 PING 10.0.8.2 (10.0.8.2): 56 data bytes
36 bytes from 10.0.8.1: Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0054 406d 0 0000 01 01 553a 10.0.8.1 10.0.8.2
36 bytes from 10.0.8.1: Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0054 406f 0 0000 01 01 5538 10.0.8.1 10.0.8.2
--- 10.0.8.2 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
♦ Do these results strike you as unexpected?
In fact, these are the expected results. The local ping never left the chassis, while the ping to the “far end” is getting looped back and re-routed back out the so-2/2/0 interface until its TTL finally expires. With the default TTL of 255, each one of these TTL expiration messages indicates 254 or so successful line-rate receptions of this packet.
Part 7: Test An ATM Network With The atm-ping Command (Optional)
Step 7.1
This portion of the lab is optional. Your instructor will inform you if the classroom equipment can support atm-ping testing. If the classroom equipment supports only fast ethernet interfaces, this section should be skipped. Depending on the number of ATM interfaces available, you may have to coordinate access with other classmates.
You will now use the atm-ping command to validate an ATM transmission facility without requiring or relying on IP related parameters. This test makes use of ATM F5 (VCI level) OAM cells.
In this example, we will focus on an ATM link between Denver and Montreal. We start by looking at the at-0/2/0 interface configuration on Montreal:
[edit interfaces at-0/2/0] lab@Montreal# show
atm-options { vpi 0 maximum-vcs 256; } unit 0 { vci 0.100; }
It should be noted that Montreal’s ATM interface is devoid of any IP related configuration.
Step 7.2
Denver’s at-0/2/1 interface is also lacking IP related configuration: [edit interfaces at-0/2/1]
lab@Denver# show atm-options { vpi 0 maximum-vcs 200; } unit 100 { vci 0.100; }
We now issue the atm-ping to validate the underlying ATM transmission facility: lab@Denver> ping atm interface at-0/2/1 vci 100 segment count 5 53 byte oam cell received on (vpi=0 vci=100): seq=1
53 byte oam cell received on (vpi=0 vci=100): seq=2 53 byte oam cell received on (vpi=0 vci=100): seq=3 53 byte oam cell received on (vpi=0 vci=100): seq=4 53 byte oam cell received on (vpi=0 vci=100): seq=5
--- atmping statistics ---
5 cells transmitted, 5 cells received, 0% cell loss
♦ In this example we used segment level F5 OAM cells. Considering that there is no ATM switch between Denver and Montreal, would there have been any reason to use end-to- end F5 OAM cells?
Part 8: Run BERT Tests (Optional Demonstration)
Step 8.1
Certain Juniper Networks PICs contain built in test pattern generation designed to provide Bit Error Rate Test (BERT) capabilities. PICs that support BERT testing would include T1, E1, T3, and E3 interfaces. Your instructor will inform you if such interfaces are available in the
classroom, and if desired will conduct a BERT testing demonstration. A typical BERT test configuration would look similar to this example: [edit]
lab@Denver# show interfaces t3-0/1/2 disable; t3-options { bert-algorithm pseudo-2e20-o151; bert-error-rate 6; bert-period 60; } unit 0 { family inet { address 10.0.2.4/24; } }
The interface must be disabled before the BERT test can be started. This example will inject errors at a rate of 1X10-6 to validate the results. The test will run for 60 seconds, and we assume there is a remote loopback in place.
Step 8.2
To start the test, we issue the operational mode test command as shown: lab@Denver> test interface t3-0/1/2 t3-bert-start
Once the test completes, the results can be displayed using show interface.
STOP