Troubleshooting Physical errors in a Frame Relay Environment

[navneet_78]

I have 3 tunnels built on my serial 0 Interface. I can see that there are muliple errors on the Physical se0 interface.

571 input errors, 258 CRC, 261 frame, 0 overrun, 0 ignored, 52 abort.

There are no output drops or interface resets. Also I see 4 Carrier transitions, what does that mean?

The Ckt vendor says they see everything is fine till the Demarc. What possibly might be the issue.

I did a show controllers and could see that the Router is getting clocking from the CSU. Do i need to check the cabling between them??

Awaiting your reply.

Regards

Navneet

[wochanda]

These outputs are telling you the data you're receiving on your serial interface is corrupted. Carrier transitions are when the link goes down/up.

To troubleshoot this problem, you're first going to want to look at your controller statistics. Depending on your hardware, the commands might be different, try this if you have a T1:

'show controllers t1'

'show service-module'

Also, if it is a T1, you can easily do a loopback test. To do this, make a plug where you loop 1-4 and 2-5, and plug it into your interface. Set the encapsulation to HDLC, and send pings to your interface for a few minutes. If the errors increment, its probably hardware failure.

If they dont increment, tell your provider you've done loopback tests to your equipment and its clean, so they need to troubleshoot the issue from their end.

[navneet_78]

Thnx for the Reply.

Is there any way for me to find out if there is any problem between the Router and the CSU?? I do a telnet session into the device, iam not physically present at the site.

Also does a faulty CSU/DSU lead to CRC errors??

Awaiting your reply.

Regards

Navneet

[navneet_78]

Would really appreciate if someone please reply to the above query.

Thanx in advance.

Regards

Navneet

[pciaccio]

From the routers perspective since you have an external CSU all the router can see is if it loses carrier detect and DSR from the CSU. You may want to swap out the CSU or see what the CSU tells you (via logs or SNMP), if you have a smart CSU. A faulty CSU can cause CRC errors. You need to look towards the CSU or line to determine where your issue lies...

[scottmac]

Try another cable or two between the smartjack/NIU and the router.

If the span is greater than ~10-12 feet, you may want to try "premises cable" which is the spec for T1 (UTP/Cat3/4/5/5e/6) is OK for short runs, but it not technically an approved media for T1).

Remember, the signal is not really "T1/DS1" until after the smartjack/NIU ... it's usually delivered as HDSL .. which works just fine over UTP.

Prem cable is individually shielded pair inside a shielded jacket. You also have to make sure the grounding to the shield is correct, or it will also perform poorly.

If you want to see what prem cable looks like, check out www.anixter.com, catalog, do a search for "premises cable."

Prem cable should support T1/DS1 out to ~655 feet; UTP is dead cable after ~25-50 meters (carrying T1/DS1).

Good Luck

Scott

[josephbruce]

When the ckt vendor stated the ckt was good to the dmrk, the question is ....

Who owns the external CSU?

Also Telco's will state good to the dmrk when they loop the NIU (or CSU if telco owned).

If telco owns the CSU, replace the cable from CSU to router. If problems still persist, (carrier transistions) call back telco and have them run an ESF payload loop to the CSU. If that is clean, then request they replace the CSU.

If you own the CSU, then you should be able to access the CSU and determine where the drops are coming from (either telco drops or your equipment). If errors from telco, have them loop up the CSU (ESF payload - line loopbacks not as effective for testing). If Telco is good to this loop, it is your equipment and not a telco issue.