Slip Errors Between Avaya and C8300

[b-krull]

Hello,

Our call center has an Avaya phone switch that connects to a pair of Cisco C8300s via fiber:

Route1 = Avaya -> Media Converter -> Fiber -> Media Converter -> C8300 T1 -> CUCM  

Route2 = Avaya -> Media Converter -> Fiber -> Media Converter -> C8300 T1 -> CUCM

The problem we have is that Route2 is showing slips while Route1 is clean.  To troubleshoot, we verified Route2 is using the same config as Route1. We have also swapped the connection from Route1 to Route2 and it appears the slip errors stay with the Route2 C8300.  This points to an issue with the C8300 versus connectivity as the slips follow the device versus the connection

We installed a new C8300 for Route2 and we had the same issue as before.  This office location is overseas, so for the moment, I was hoping others could help point me in the right path to resolve this.

Thank you!

[chrihussey]

If these are T1 connections, suggest checking the clocking options at the far end to make sure they are identical between the two. If that is an issue, you could try to adjust them for the T1 on your side to see if that helps. Short of that, you could have the line tested end to end to make sure it's not a facility problem. 

[b-krull]

Thank you for your reply.  What I dont understand is that if I simply swap the 8300's, the problem follows the 8300.  For example, when the clean Route1 is swapped with slipping Route2, it shows no slips with either connection; however, Route2 is showing slips on both. 

Why is Route2 showing slips when it is a new unit with the same config as Route1?

[chrihussey]

Sorry, but a little confused and need clarification. You have an 8300 with two T1s, route 1 & 2, and route 2 is showing slips. If you swap the T1 connections on that 8300 what happens.? Also, what happens when you swap the 8300 and do the same? Thanks.

[b-krull]

We have two 8300s, each with their own T1.

[chrihussey]

OK I think I understand now. You said the configurations between the 8300s are identical so I'll assume both are correctly clocking off the incoming T1 lines. Aside from that,  I don't have any 8300 with T1s, but the commands are there which are just like the 4XXX series routers. Perhaps if not already there have you tried configuring:

!

network-clock synchronization automatic
network-clock input-source 1 controller T1 #/#/#

!

Short of that, you may have a faulty network module. Perhaps swap the two between the routers to see if it follows the module or router. 

[Elliot Dierksen]

As others have noted, this is a clocking issue. The Avaya needs to provide clocking on each of the circuits, and the 8300's need to be configured to receive clock from the line.

[b-krull]

Hi Elliot, if it's a clocking issue on the circuit, wouldn't that affect both 8300s equally?  Im only getting slip errors on one 8300 - no matter which circuit

[Jonathan Schulenberg]

Two details aren’t clear while reading this thread

• Where in the path are you swapping the connections? To blame the Cat8k chassis it would have to be the RJ48 connection directly into the two NIM cards; same media converter, same patch cable. Are you confident that is exactly the “swap” the on-site tech is performing?
• The OP also mentions a third Cat8k chassis which also showed these symptoms. Did that chassis also have a new NIM card for the T1 or did you reuse that component? If the latter, you haven’t fully isolated this.

[b-krull]

Good morning Jonathan,

It may very well be onsite related as I dont have eyes into the system.  This issue has been ongoing for several months with the second 8300.  For layer 1, I initially tried swapping the NIM cards when I was onsite.  The problem remained with the second 8300.  I then replaced the NIM on the second 8300 - no difference.  The only thing left was the chassis so we replaced the entire 8300 with the same results.  The programming is the same on the first and second 8300's currently in use.  If the clocking is wrong, why am I not seeing it on the first 8300?

I will be at a location later this week where I can remote into the devices.  There has to be a human error involved somewhere.

[Elliot Dierksen]

Yes, but the config of the different 8300's could be different as it pertains to clocking.

[b-krull]

I am finally able to SSH into the devices.  Route2 was showing 100 slips over the past 24 hours.  I again confirmed that the configs are both the same for Route1 and Route2 and includes the command 'network-clock synchronization automatic'.  Both 8300's are set to Line Primary.  After more digging, I found there was a bug, ID CSCvb01800, that was for a similar issue on the ISR 4331.  https://amyengineer.com/tag/network-clock-synchronization-automatic/

The recommendation was to add these two commands: no network-clock input-source 1 controller t1 0/1/0 and no network-clock sync participate 0/1.  I wasnt choosing the input-source to begin with but I tried the no network-clock sync participate 0/1.  The article stated this is a hidden setting.  After I did that, I havent seen any slip errors over the past 24 hours.  Does this make sense to anyone?

[chrihussey]

No it doesn't make sense. However, I have a bunch of 4xxx series routers with PRIs on my network and all run clean except for one that shows slips trickling in at about 10 or more every 15 minutes. The PRI is on an really long copper run in a remote area and the carrier isn't easy to work with so I never really pursued it. After reading your post I made the suggested changes and it has been running clean for the past 30 minutes. It makes no sense, but it seems to be working in this case too. All the other routers have the full configs and don't show slips so I'm not going to mess with them.

In my effort to help you, you have helped me. Thanks.

[Jonathan Schulenberg]

Backplane clock synchronization is used to share the same source across multiple clocking domains. In the ISR 4k and Cat 8k hardware architecture, each NIM is its own clocking domain - so arguably you don't need that feature in this deployment since each chassis only has a single T1 on a single NIM. The symptom you're describing would make sense if the router was choosing the internal clocking source and synchronizing it toward the NIM instead of the other way around though. Here's another source to support Amy's blog: Configuring the Cisco Fourth-Generation T1/E1 Voice and WAN Network Interface Module - Network Synchronization for the Cisco 4000 Series ISRs.

[Elliot Dierksen]

I don't see as many T1/E1 connections now as I did in the days of yore, but that is a super helpful link. Thanks @Jonathan Schulenberg !