I've got four T1 lines that are bonded together apart of a PPP multilink group. It's the same on both sides, with the actual serial interfaces not having IP addresses and the multilink interface doing all the L3 talking. A few days ago one of the T1 lines went down. I checked out the controller on side A and all was good. I checked out the controller on side B and all was good. The physical line -being the controller and the link were Up, but the protocol on the serial interface was down. I opened a ticket with the LEC, and they found nothing wrong. I did BERT tests for five minutes on both ends, with the far end looped towards me, and absolutely no bit errors. I also changed the DS1 cards on both ends thinking it could be the controllers. At this point, I've done everything including rebuilding the channel groups to re-establish the Serial interfaces but got no results. The only errors I can find are done via sh int serial1/0/1:1, which shows input errors, a few CRCs, a few frames and a whole lot of Aborts; everything on the output side is 0. I know the Aborts and the errors are bad, but I've checked the config so many times and verified it's not the circuit that I cant figure out whats wrong.
Here's the config on the A side:
no ip address
encap ppp
no fair-queue
ppp multilink
multilink-group 2
on the B side:
no ip address
encap ppp
no fair-queue
ppp multilink group 1
Also: on the B side I don't see any errors on the sh int serialx/x/x:x
Help is appreciated. Thanks
If that's not real successful but you can get the circuit to see the loop, take that T1 out of the bundle and set it up as a separate, individual T1. Use HDLC, not PPP, encapsulation (I've seen HDLC work when PPP wouldn't). Give it an IP address of 1.1.1.1 and 1.1.1.2 on the two ends, mask 255.255.255.252. Ping the far side. Does it work? If so, do an extended ping (just "ping" with no IP address on the tail end, and then answer the individual extra questions). See below (copied from the Inet-access mailing list):
router#ping
Protocol [ip]:
Target IP address: blah.blah.blah.blah
Repeat count [5]: 1000
Datagram size [100]: 1500
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]: y
Data pattern [0xABCD]: 0xAAAA
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 1000, 1500-byte ICMP Echos to blah.blah.blah.blah, timeout is 2
seconds:
Packet has data pattern 0xAAAA
Reply data will be validated
!!!!!!!!!!!!!!!!!!!!!!!!!!
Do this with at least the following patterns:
0x0000 (all zeros)
0xAAAA (alternating 1's and 0's)
0xFFFF (all 1's)
Frequently if some part of the circuit isn't configured properly one of
these tests will largely fail. At that point you can tell the telco "but
the circuit can't pass all zeros from Z to A (replace with whichever test
fails), it must be a circuit problem!"