cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4002
Views
8
Helpful
32
Replies

Meaning of data pattern 0x0000 to troubleshoot one dirty line

maghisi-2007
Level 1
Level 1

I've one customer connected through one 2048Mb E1 leased line with csu/dsu with V35 interface. Circuit is always getting errors. Downs never occured. I've already replaced the cisco and the cisco cable @ customer site and I've already used a new port on another router at my node, without fixing. But, I couldn't say for sure it was a link trouble as Ptt run more than one end-2-end test with the instruments, without getting errorr or clock slips.

Anyway, I found that by running an extended ping with data pattern 0x0000, after a size of 160bytes I start to lose packets. While with the default data pattern or with data pattern 0xffff the ping run perfectly. I'd like to know if data pattern 0x0000 is showing me a clock issue or linecode problems. By looking at the clock the router is detecting it seem to be stable.

1 Accepted Solution

Accepted Solutions

Today we enable the parameter V38-Scrambler on both the csu/dsu and now the ping with data pattern 0x0000 can work fine and the circuit is currently empty of errors

View solution in original post

32 Replies 32

paolo bevilacqua
Hall of Fame
Hall of Fame

Yes, certain patterns can cause errors due to poor equipment. Have telco replace the v.35 "modem" as minimum. You can can procure an E1 interface, you would also be able to bypass it totally and access the real circuit performance data.

Ok thanks. I can arrange one modem replacement at my node for tomorrow. But exactly pattern 0x0000 is showing clock issues or linecode issues? In the first case I can try to replace the modems at both sites and then investigate about clock. In the second case I'll have to check linecode parameters (perhaps a worse thing by considering that Telecomitalia surely will go on with normal troubleshooting procedures before passing the fault to its specialists)

Hi,

with the external dce-3 you cannot check anything. linecode is always hdb3 and clock is taken from dce-3.

My theory is that they use the device so they can actually hide real circuit performances from you and claim that "all is good" as always they do.

A payload of all zeros can cause these problems because there is not enough "0 1 alternating density".

However a circuit properly provisioned must have no problems no matter the data you send on it.

I agree with you that also with this pattern the ping must work because I tested with other circuits which are working fine can support this pattern too. Manage a test of only the E1 portion is difficult because in this period Ptt engineers hardly have the V35 data tester and so they'll surely need time to get a data tester for E1 coax interfaces. Anyway, I personally checked the bert tests and I could see by myself they could run fine. Only patten 2 -23 was used. Perhaps by using different patterns something could come out but we thought that this one, which is the longest one, could be the best. However tomorrow I'll replace the Csu/dsu at my node with one surely working fine that I was successfully using for another customer in the past

Hi All,

0x00000 pattern actually related to transmission technolgy. No Service Provider actually hides anything. Actually, All 0s are transmitted on VC-12 payload or ALL 1s bits are transmitted on VC-12 payload incase of failure happens at CE side.Such instances generates AIS alarms. AIS stands for Alarm Indication Signal.

I believe that you have wrongly interpreted the problem.Pls share the syptoms in details for further diagnosis.

Hi,

maghisi is correct. Either the circuit works with no errors, or does it dot, and there is nothing that can be done on the router about that.

As a sidenote, what happens with telecomitalia and many other telco in the world, is that by default you must use their v.35 interface, this way you have no access to circuit performance statistics, like slips seconds, severely errored seconds, etc, all these parameters are defined by the ITU.

Now the real issue is with the circuit in itself, how it is provisioned, eg telecomitalia usually uses hdsl but that is not always the case, for sure before admitting to a fault in the physical layer, it takes a lot of effort to convince them to just second-line troubleshooting.

Hi,

Since you have shared that in extended ping with 0xffff pattern, its works well.

Can you try with inverse clock-transmit on your router serial interface?

try and share your feedback.

Well, line is getting errors. Never went down. I can only check the node site. Currently after 24 hours I got:

953 input errors, 752 CRC, 0 frame, 85 overrun, 0 ignored, 116 abort

Telecomitalia is just providing the last mile towards cust site. Another provider is giving us the other part of the tail. We successfully performed 2 end to end test with the data tester by using pattern 2-23 and I could also correctly see loop connectors placed back of the Csu/dsu @ cust site. I've already replaced the Wic-2t and the cisco cable @ cust site and I changed the node port (so also the cable changed). I'm attaching the serial port config at the node and the one @ cust site (even if it's taken by one basic config we downloaded at the day of the installation as we don't manage the cust's router config and for this reason I don't have its current passwords).

If the command invert txclock can cause one down I must wait till tomorrow before using it as I can make intrusive test just from 11AM GMT to 12AM GMT, since the connection is not down and the customer can get outage only during that hour

attachment

is your PE also connected via interim interface converter? who provides clock for the line itself (not towards CPE and not towards your PE)?

If telco's interface converter generates clock on V.35 side, but in turn recovers its own clock from the line and your PE does the same, then you'll see problems.

Well, Csu/Dsu are needed to convert the E1 coax cables into V35 but this is a normal configuration. Originally both were configured to get the clock from the network but since with the command sh controllers s2/0 | i clock I got some different values on the PE sides (but just sloght differences), I configured the Csu/Dsu at the node with internal clock and the situation became better even if the errors never disappeared.

The routers as usual takes the clock from the Csu/Dsu and about in which way the clock is running into the 2 Ptt networks I don't know and I believe it's one thing to investigate if the problem should go on

This sounds like clock setup on this line isn't sure thing. You need to ensure that there one and only one device (interface converter) providing clock to the line (telco usually don't provide clock sync for E1 circuits) and one device in each router-converter pair. Any other clock configuration will result in problems.

Sorry, but the suggestions about clock setting are not applicable to this problem.

As explained already, the converter takes clock from line and gives to router via V.35. There is no setting that you can change about that. Beside, the suggestion that there is no clock on E1 circuits is very wrong. There is clock absolutely indeed.

The circuit (last mile or other portion)is simply defective. It may take time, but eventually evene telecomitalia can manage to have it working.

Well, since yesterday I agreed with the cust another test window for today, I started first of all to replace th csu/dsu at my node with one surely working perfectly but I didn't fix anything.So, I came back to the old one and I played with the CRC parameter by setting it "as used as CCITT" (that I think it means one sort of autosensing mode) and then by setting it off. Since the ping with data pattern 0x0000 went on failing I came back to the original value of CRC forced on. Then, I tried the command "invert txclock". I'm not sure it was correct set it on the PE because the PE is acting as frame-relay switching but anyway I cannot telnet the CPE and so I hadn't another choice. Since also in this case I didn't fix anything, I came back to the original serial port config.

Now I believe that I'll contact again local Ptt by asking them new checks performed by their engineering department. Perhaps they'll ask me to try with a couple of test router (one at the node and the other one at cust site) before formally opening a new trouble ticket...

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco