Question for network geeks

[PsyOps]

Where I work I have several ISDN T-1s. When they are idle (no traffic on them) the B channels show no input errors, CRCs, etc... When I run traffic over them the B channels that are up/up start counting input and CRC errors.

Does anyone know what might cause this problem?

Thanks.

 

[EmptyTimCup]

Where I work I have several ISDN T-1s. When they are idle (no traffic on them) the B channels show no input errors, CRCs, etc... When I run traffic over them the B channels that are up/up start counting input and CRC errors.

Does anyone know what might cause this problem?

Thanks.

I'd start with a packet capture session and look for the mac address with all the errors .... unplug and plug back in your connections (basic I know but you have to start somewhere)

Fluke has different tools ... test Layer 1

 

[donmagicyourmom]

crc errors are layer 1 so i'd just go with replacing cables or try a different interface on your router

 

[PsyOps]

I'd start with a packet capture session and look for the mac address with all the errors .... unplug and plug back in your connections (basic I know but you have to start somewhere)

Fluke has different tools ... test Layer 1

This is on a PRI serial interface which has no MAC associated with it. I am running the BERT from the controller on a loop downstream. No other traffic is on this circuit except the BERT.

 

[PsyOps]

crc errors are layer 1 so i'd just go with replacing cables or try a different interface on your router

They can be, but as I understand PRI T-1s layer 1 problems would show up on the controller, which shows no errors at all. In this case, I would think if there were a layer 1 issue the CRCs would be pretty constant regardless of whether traffic was on it or not. But, in this case, the errors only show up when I run traffic over it. But I am still considering other layer 1 issues like timing and framing (even though no frame errors are occurring).

 

[PsyOps]

A T1 is a T1, start with the basics. Continuity, line coding and framing. You should be able to test clean on those regardless if it is ISDN or not.

BERT- is that clean and on what patterns? From what to what, like testing from and to?

What are the T1's riding to/from you?

More details?

Actually that's not completely accurate. For example, on a Cisco router you can have either a WIC T-1 card that streams your data at a rate of 1.536Mb/s; there’s no channelization or a PRI which channelizes the DS-1 and the data is handled completely different. From a framing and timing standpoint it would be handled the same; but if you run a bert from your router controller there are a couple different ways to run the bert: either a straight bert or you can specify the number of timeslots you want to test.

The strange part about this is, when I run the straight BERT (no timeslots specified) each B channel amasses huge input and CRC errors. When I specify 24 timeslots (since this is a full T-1) the B channels experience very few errors. And these errors only show up when traffic is passing over the channels. When we have a customer connecting in and only raise 2 or 3 B channels, only those channels experience errors.

But, all that said, I think I found the problem. I get these errors with a loop right on the interface; no cable or anything. We have a spare router with identical setup and configs that I ran the same test and it ran clean. I think we have a bad PRI card. Or it could be the backplane, but unlikely.

 

[EmptyTimCup]

Glad you found the issue

 

[CrashTest]

Glad you found the problem, however a T1 is a T1 is a T1.

You are correct about that but it's confusing sometimes because of the 2 types of signalling. Boils down to whether you have CAS or CCS signalling. CAS is signalling inside the data stream (bit robbing). CCS is signalling outside the data stream (ISDN D-Channel)

 

[PsyOps]

Glad you found the issue

I hope.

 

[PsyOps]

Glad you found the problem, however a T1 is a T1 is a T1. How your terminating equipment (example:Cisco Router) deals with that T1 doesn't change that a T1 is a T1.

I get you now. From a transmission line, you're right. From an endpoint it's not. And given that I can run a BERT from the router controller and select the timeslots there is a difference in how it handles the traffic. If I were to remove the cable from the router and just connect a Fireberd to the line it would run a straight T-1 test, with no channelization. And the weird part about it is, the BERT itself (on the controller) passes; but the B channels get errors. So there is something going wrong when the PRI muxes the channels.

 

[PsyOps]

You are correct about that but it's confusing sometimes because of the 2 types of signalling. Boils down to whether you have CAS or CCS signalling. CAS is signalling inside the data stream (bit robbing). CCS is signalling outside the data stream (ISDN D-Channel)

And the D channel gets hardly any errors on it compared to the B channels.