Fractional T1 trouble

I'm troubleshooting a fractional T1 (16 timeslots) that is having some strange problems. Using extended ping, I gathered the following information:

-Small pings up to 1000 bytes with the default data pattern go across the line with no problems.

-Starting at around 1400 bytes, pings with the default data pattern fail at a rate of about 3 - 5%.

-Pings sized at 1000 bytes with a data patern of 0x0000 fail at a rate of about 3 to 5%

-500 byte pings with a data pattern of 0x0000 go through with no problem.

-1000 byte pings with a data pattern of 0xFFFF go through with no problem.

-Strangley, no errors show in the counters for the interfaces on either side of the link.

The MTU is set at 1500 bytes at both sides. I changed the queueing from WF to FIFO with no change in results. I verified that the settings of the (external) DSU on one side of the link is set correctly (ESF, B8ZS,

16 timeslots), but I can access the other end's DSU.

From what I've seen, this could be an issue with incorrect linecoding

specified somewhere along the path of the circuit. But why would the

0x0000 pings fail only for larger packets, and not the smaller sized? Any insight would be greatly appreciated.
Reply to
Mark Williams
Loading thread data ...

Is your provider also configured for B8ZS, ESF? Do the interfaces show errors?

- Mooron

Reply to
mooron

No errors show in the interfaces. One side of the link shows some output drops, but they don't correspond with the ping failures.

Reply to
Mark Williams

Oh yeah, you did mention there were no errors.

Post a snipit of the configuration, maybe it's something dumb.

Also, do a show service module if it's a router that has them.

Your provider could be dropping frames. That would be the next thing to look at if there are no problems with your configuration.

- Mooron

Reply to
Mooron

I'm using Kentrox external CSU/DSUs on both ends of the link. I've verified that the configuration is correct on one side of the link, but I cannot manage the CSU on the other side.

The interface configuration on one side:

interface Serial0/0 description DO-DVS WAN Link 1 bandwidth 1024 ip address 165.196.38.254 255.255.255.128 no ip directed-broadcast no ip proxy-arp no ip mroute-cache no fair-queue invert txclock no cdp enable

The other side:

interface Serial0/1 description DVS-DO WAN Link 1 bandwidth 1024 ip address 165.196.38.253 255.255.255.128 no ip proxy-arp invert txclock no fair-queue

Our service provider conducted some loop testing and didn't find any problems; I tried to explain the symptoms to them but I got the "It's OK at layer 1" message.

Reply to
Mark Williams

I was wondering if the clocks might be set wrong.

Reply to
Mooron

There's not alot you are going get out of the serial interfaces at this level. Almost always when faced with problems in this setup, its some sort of cockup on the CSU/DSU setup. All the router's serial interfaces know is that they can send out data, and may get garbled data coming back.

I urge you to get into the config of the CSU on the other side of the link and verify its setup. You most likely will find something not set the same there. Ie. number of channels, channel order, framing, encoding, etc. Clocking isn't that important at this point, although good to verify the setup on. Bad clocking will still most likely bring the circuit up, but may have problems later.

They won't be able to tell anything about the CSU setup at that level of testing, just that there seems to be a T carrier that can push bits out over it.

Reply to
Doug McIntyre

I went on site to look at the other end's CSU/DSU, and everything looked fine. The linecoding was set to B8ZS, framing ESF, and the timeslot configuration matched.

Reply to
Mark Williams

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.