Strange Cisco Frame problem

[ewiley]

Hello,

I've got a cisco 2650 runnning as a hub for a few remote sites connected with frame-relay. The remote routers are 1720's all with integrated dsu's. I setup the 2650 with point-to-point subinterfaces and everything seems to come up just fine (all interfaces come up-up, and I can ping and traceroute). Now here's where it gets wierd. Computers at the remote sites can browse the internet and transfer data with my site (this is a fully private network with a masquerating proxy server providing the internet access). BUT when I try to access a shared printer on the remote site, or they try to access some NT domain functions (shared drives/printers) the whole serial interface (not just a sub-interface) on my hub router (the 2650) goes down. I cannot, for the life of me, figure this one out. The only clue to there being a problem is when I had the LEC test the lines.. everything from their network to the NIU tests out clean, then when they loop my dsu and test, all the test pass except "all zeros", which fails immediately. I've replaced my dsu, and double-checked my cabling, and I can't find any physical problems. My line-code is B8ZS and framing is ESF (which I confirmed with the telco as correct). My theory is that there's something with the data that's being sent to the dsu that causes the service-module to reset (when it resets, the service-mod shows loss of carrier, loss of clock, loss of frame for exactly 5 seconds each time--which leads me to think it's the service-module that's rebooting).

Any help or direction on this would be appreciated!!

Thanks!

 

[evang]

Sounds as if a device in the carrier's network is not set to B8ZS encoding.

From your router, try pinging the address at the far end of the serial link, using Extended ping (p). First time, use the default data pattern. Second time, specify the pattern 0x0000. If you get 99+% success on the first ping, and 10% or less on the second, this confirms that the line-coding setting on some carrier eqpt between the two sites is misconfigured - IOW, not B8Zs.

The first thing they should check is the CSU/DSU at each end.

 

[evang]

Sounds as if a device in the carrier's network is not set to B8ZS encoding.

Try pinging the address at the far end of the serial link, using extended ping (p). First time, use the default data pattern. Second time, specify the pattern 0x0000. If you get 99+% success on the first ping, and 10% or less on the second, this confirms that the line-coding setting on some carrier eqpt between the two sites is misconfigured - IOW, not B8Zs.

The first thing they should check is the CSU/DSU at each end.

 

[jeter]

what IOS ver are you running? I do not think this is a carrier issue unless you do not have enough bandwidth. What is your CIR? What does your serial interface look like? Do a sh int ser 0 and post it. also do a sh service-module and look at the alarms. What does your Frame look like. sh frame-relay pvc? Jeter@LasVegas.com
J.Fisher CCNA

 

[ewiley]

I totally forgot about this thread

Anyway, the fix for it turned out to be a 'new' piece of equipment that the telco was using that (for some reason) would error the line if all zeros was passed over it (I think I spent a total of about 120 hours on the phone with AT&T, Verizon and Cisco trying to figure this one out). The access shelf at my CO was switched over to an older access provider, and it worked fine. The on-site Verizon tech only tried it because he knew of some problems with some other people using ATM over it.

Also, they found that the R card at the CO was set to 'autodetect' for the framing and line coding (this was prior to us finding the problem with the access shelf). This also caused problems between the CO and the tester, so that was demonstrable. However, the testpoint at the CO did not extend to behind the access shelf, so we weren't able to discover the problem until the AT&T tech tried running me a test PVC from their location to my DSU.

This was an insanely difficult problem, but I learned a LOT about framerelay in the process!