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.
Solved! Go to Solution.
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)
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
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.
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.
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
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...
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.
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.
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).
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.
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.
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)
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.
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
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.
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.
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.
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
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.
Customer postponed the intervention onsite to tomorrow. Today I just could play with the command invert txclock without fixing