Meaning of data pattern 0x0000 to troubleshoot one dirty line

[maghisi-2007]

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.

[julian.andrews]

Clarification: An E1 (i.e. standard unstructured 2048k and not two T1s bolted together) private circuits do NOT provide a network clock. The CSU/DSE/Modem or DCE devices which are normally set for recovered clock for sub-2048k circuits are in this case set for Master or Internal clock at ONE end, the rest of the devices are slave/recovered timing. Unfortunately, these internal clocks are generally not as accurate as network clock but needs must. Trial and error to determine which device has the better clock source. The accuracy should be at least 2048k +/- 50 ppm.

Back to your particular problem. A similar issue was investigated by my colleague. The Telco tested their circuit fine, error free many times; many router permutations tried nothing seemed to work. In the end, it was resolved by re-configuring both routers and the V.35 device at the one end (the other was G.703 unbalanced) to Framed 1984k (T/S1-31) with the V.35 device set for internal clock and the two routers slave to it. Problem gone! The only trouble is that we do not know why this fixed worked. Of course, there is no guarantee that this fix will work for you but you have tried most things. Perhaps, there is someone out there who could explain why. For reference: the unframed E1 circuit remained the same except for the re-configuring of the V.35 equipment - no re-routes or change of transmission technology.

[paolo bevilacqua]

Hi Julian,

you are are correct the "converter" device recovers clock from the line to present to the V.35 interface. Just like a native E1 interface on the router would do.

Thanks for sharing the experience for that particular circuit. For you reference, unframed E1 is not easility available from the telco mentioned in this thread.

[ilya.varlashkin]

If both PE and CE sides have converters, each of them taking clock from the line then effectively there's no device providing the clock. Unstructured E1 circuits at least in DK, FR and DE generally do not sync from telco's SDH equipment (unlike STM circuits) and user should provide clock on one side (either on the router or on one of the interface converters).

[umeshjoshi99]

Hi,

I believe, you need to verify the clock, speed and bandwidth should match with the G-703 modem settings. Please ask telco to reset the G-703 modem or replace the same from telco.

[paolo bevilacqua]

As mentioned above there are no parameters to set on the router when using v.35, eg bandwitch is informational only.

And the modem has been reported to have been replaced already.

[maghisi-2007]

Circuit must be unframed working at the speed of 2048Mb. I can try by setting its speed to 1984K (31 channels) but even if it should work fine I'm not sure I can take this speed as customer asked for a 2048Mb. I tested other 2048Mb circuits and they can answer fine to any kind of extended ping I run,so, I assume that also this one must be able, if it's working fine, to support ping with data pattern 0x0000. The csu/dsu used for these other circuits which are OK, are configured in the same manner of the ones for this tail. However, if customer agrees, tomorrow one engineer will go to cust site to perform the following actions:

-activate on the CPE the command invert txclock

-if this command shouldn' improve nothing, we'll try to activate it also on the PE and if nothing should change we'll disable this command either on the CPE either on the PE

-then, we'll try to play with the Csu/dsu configuration because we can try to activate one parameter (now disable) called Scramble V38 (I don't know exactly what it does but sometimes Telecom left it on for other circuits)

[paolo bevilacqua]

ITU V.38 part 3 defines an optional scrambler for 48/56/64 kbps circuits.

It is possible that the DCE-3 is able to apply scrambling to higher data rates also.

Since scrambling ensures 0/1 density no matter the payload pattern, it can be beneficial to try it, having configured on both sides of the circuit.

[maghisi-2007]

Thanks for the information. In fact I want to test on both site as one Telecom engineer told me that it's not possible to apply it only on one modem

[ilya.varlashkin]

Either he told you incorrectly or you've misunderstood him. You can't have two devices on the same circuit both synchronised from the line or both running on internal clock. There must be one and only one device providing clock between interface converters.

However, both interface converters can provide clock to the routers and that's quite common.

[paolo bevilacqua]

Ilya, we are talking about scrambling per ITU V.38, not about clock.

unlike clock, scrambling is usually applied to both directions of a circuit.

[ilya.varlashkin]

Paolo,

I saw the note about V.38. Although it's possible that inconsistent scrambling configuration applied on the converters, I have had impression that scrambling is not used on european E1 circuits but only on structured E3 circuits. I'm not saying that scrambling is impossible on E1, but it would be very unusual since HDB3 line coding is reasonably robust.

[maghisi-2007]

Telecomitalia csu/dsu can have enable this scrambling option. Usually it's kept disable but i can remember one circuit for which in the past I had to enable it. ANyway it's true that usually it's not used

[paolo bevilacqua]

Yes, hdb3 is perfectly capable of carrying any pattern, and as I mentioned before, according the the standard, V.38 scrambling would apply only to DS0 or sub-DS0, not E1 framed or unframed.

However this is a strange case and I think anything that might help should be tried.

[maghisi-2007]

Customer postponed the intervention onsite to tomorrow. Today I just could play with the command invert txclock without fixing

[maghisi-2007 · Accepted solution]

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