The burden often associated with configuring the correct line clocking and or framing for a serial interface is much like those found with Ethernet speed & duplex settings. At least that’s the way I like to think about it. Lets face it the last thing we want to see on an Ethernet connection are errors, CRC, overruns, etc. Well the same is true when it comes to serial interfaces whether it be Layer 2 HDLC, PPP or Frame Relay encapsulation. This is especially true when your bundling serial interfaces together to from a logical groupings such as PPP or Frame Relay Multilink.
Slip Violations
If slips counters are present on the T1/E1 or PRI interface there is usually some type of clocking problem between the Telco and the Customer. Depending on the Telco the Customer equipment will usually need to synchronize or derive it’s clocking from Telco. This however is not always the case, and you will need to verify clocking with the local Telco.
Framing & Line Coding
Basically there are two types of framing and line coding. The first and lease often used is Alternate Mark Inversion or AMI signaling. The second more common is Bipolar 8 Zero Substitution or B8ZS signaling. Both are Telco specific and must be configured accordingly.
Recently I ran into a situation with one of our newer location’s where the local Telco wasn’t providing any line clocking for business or residential Customers over their optical network. This really isn’t much of a problem as long as you’re aware of it ahead of time. And as it just so happens this particular location had two DS1’s that were bundled together at Layer 2 with PPP encapsulation for a grand total of 3 Meg.
R1#show ppp multilink active Multilink1 Bundle name: 102.56.21.181 Remote Endpoint Discriminator: [2] 102.56.21.181 Local Endpoint Discriminator: [1] R1 Bundle up for 02:07:34, total bandwidth 3072, load 2/255 Receive buffer limit 24000 bytes, frag timeout 1000 ms 0/0 fragments/bytes in reassembly list 121 lost fragments, 318523 reordered 10/1205 discarded fragments/bytes, 0 lost received 0x123FC8 received sequence, 0x5EFFF sent sequence Member links: 2 active, 0 inactive (max 255, min not set) Se0/0/0:0, since 00:07:34 Se0/0/1:0, since 00:04:15 R1#
On closer inspection we can clearly see from the output above that things are not completely healthy. The two T1 controllers 0/0/0, and 0/0/1 have not been active for vary long which would clearly indicate that there is some sort of problem with the lines or possibly the clocking or both. Lets take a look at the logging more specifically the status of the Controllers.
R1#show logging | include changed Jan 13 03:52:30.397: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0:0, changed state to down Jan 13 03:52:32.365: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0:0, changed state to up Jan 13 11:10:10.328: %LINK-3-UPDOWN: Interface Multilink1, changed state to down Jan 13 11:10:10.332: %LINEPROTO-5-UPDOWN: Line protocol on Interface Multilink1, changed state to down Jan 13 11:10:12.740: %LINK-3-UPDOWN: Interface Multilink1, changed state to up Jan 13 11:10:12.744: %LINEPROTO-5-UPDOWN: Line protocol on Interface Multilink1, changed state to up Jan 13 12:49:51.658: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/1:0, changed state to down Jan 13 12:49:55.654: %LINK-3-UPDOWN: Interface Serial0/0/0:0, changed state to down Jan 13 12:49:55.658: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0:0, changed state to up Jan 13 12:49:55.662: %LINEPROTO-5-UPDOWN: Line protocol on Interface Multilink1, changed state to down R1#
Based on the above Syslog output its easy to see that there are definitely issues going on with both of the DS1 controllers line clocking. So the question becomes who’s problem is it really the Customer’s or the Telco..? This proved to be the most difficult part in the entire ordeal finding out whether or not the Local Telco was providing clocking or not. It was entirely possible that none of this was due to clocking considering that this was brand new construction.
Okay now lets make sure that the WIC card is no longer participating in the line clocking.
R1#configure terminal R1(config)#no network-clock-participate wic 0 R1(config)#
Now that the HWIC line card is no longer participating or deriving it’s clocking from the line lets move onto configuring both of the T1 controllers for internal clocking.
R1(config)# R1(config)#controller t1 0/0/0 R1(config-controller)#clock source internal R1(config-controller)#controller t1 0/0/1 R1(config-controller)#clock source internal R1(config-controller)#end R1#
Lets verify that the both T1 Controllers are configured for internal clocking.
R1#show controller t1 0/0/0 | include Clock
Framing is ESF, Line Code is B8ZS, Clock Source is Internal
Lets also verify that Controller T1 0/0/1 just make sure it’s clocking is derived internally.
R1#show controller t1 0/0/1 | include Clock
Framing is ESF, Line Code is B8ZS, Clock Source is Internal
After making the necessary clocking changes the the PPP Multilink bundle stabilized, and both the DS1’s stopped encountering slips. I was still occasionally seeing errored seconds, but the DS1’s were stable. As I mentioned above I was losing my BGP session with the neighbor from time to time and that was not longer occurring.
I hope you found this post on T1/E1 Line Clocking helpful and informative. Be sure to let me know what you think by leaving suggestions, and feedback in the comments section below. You can find out more about these and other articles be checking out recent posts and archives. To learn more about me be sure to check out the About page. And as always thanks again for visiting The Packet.
