DSL errors but no CRC errors on interface, HOW?

[SlevinKelevra]

Hi,

Im a bit mad actually because there is something i do not understand and ofcourse there will always be things like that but since this is my profession i just have a need to understand it. I see the following on one of our customers router. I see DSL errors (alot!) but when i do a show interface of the ATM controller 0 errors. How is this possible every error on the underlying layers has to create an error in the upper layers right?

Can someone help me figuring this out, im so confused.

Controller DSL output

Line 0 statistics

        Current 15 min counters

                CRC : 475       LOSW Defect : 241       ES : 33 SES : 0 UAS : 502 ç

        Previous 15 min counters

                CRC : 80        LOSW Defect : 42        ES : 6  SES : 0 UAS : 64

        Current 24 hr counters

                CRC : 3047      LOSW Defect : 944       ES : 241        SES : 5 UAS : 3778               <=== over 3000

Interface output ATM (AAL5)

  Last input 00:00:00, output 00:00:00, output hang never          <===== never cleared

  Last clearing of "show interface" counters never

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 129

  Queueing strategy: Per VC Queueing

  30 second input rate 30000 bits/sec, 24 packets/sec

  30 second output rate 35000 bits/sec, 25 packets/sec

     61235 packets input, 8748570 bytes, 0 no buffer

     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

     0 input errors, 17 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

  Last input 00:00:00, output 00:00:00, output hang never

  Last clearing of "show interface" counters never

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 129

  Queueing strategy: Per VC Queueing

  30 second input rate 30000 bits/sec, 24 packets/sec

  30 second output rate 35000 bits/sec, 25 packets/sec

     61235 packets input, 8748570 bytes, 0 no buffer

     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

     0 input errors, 17 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort            <=== only 17??

[Leo Laohoo]

Post the following output:

1.  sh dsl interface;

2.  sh int dial0

[SlevinKelevra]

There is no dialer interface on that router, it has a ATM interface with a DSL controller, this is only the partial output. You want to have the full i can arrange that ofcourse (not at work at the moment). The first output is the answer to your question sh dsl interface, only in this cisco ios (it is sh controllers dsl 0).

Can you explain what you are looking for, the dsl snr/attenuation value's are not that great hence the crc errors. My question is that ATM is a transparant protocol, it does not matter how many ATM nodes are in between crc errors will always be seen on the router, because unlike ethernet it does not drop the packet if it does not comply to the crc check.

[4023672]

Hello

I can understand you question and i will explain.
Follow my thought.
You have a router, running a software, interfaces with asics made by Cisco. But the modem Dsl built-in is from another manufacter.
So IOS in is native form dont see the errors, you need to invoke the controller to see the statistics, using the old command " show dsl interface" or the new that invokes the controller " show controllers vdsl" in the isgr2.

I believe this is why you dont see errors in the sh int atm output, you will only see errors in this interface using sh int atm, when is errors at the protocol level. To see the physical or data-link level you need to invoke commands like sh dsl int, or sh controllers vdsl.

Chefes

Sent from Cisco Technical Support iPad App

[SlevinKelevra]

Ok, for now i stick to that answer, although i still think it's a bit shady it's the only one that makes kinda sense and i asked alot of people.

That said will you go with me on this?

so the ATM errors are on ATM path, that means

CPE [ATM Interface] -------- DSLAM ----- ATM Backbone ---- [ATM interface PE]

<-------------------------------------------ATM errors ------------------------------------------------>

<---------DSL Errors ----------> although not seen by the ATM interface if they occur on the DSL layer

Is this than always the case or do they also coexist with each other, because i have seen that also

plenty of times, errors on the DSL path are shown also on the ATM interface.

[4023672]

Remco

I agree with you when you say is a little shady.
I believe that you must compare the Layers of the OSI model.

If you got a error in the physical Layer, when the frame is built it contains the checksum, and If the checksum ins't identical you got a frame discard by CRC, right? But this CRC this a data-link verification.
But imagine that the packet:

Packet -checksum. X. --------------------- packet - checksum Z
Frame- checksum. Y. -------------------- frame -checksum y
Bits --------------------- bits

Imagine by someway that the L2 checksum is validated, but the L3 isn't. Where that error will appear?
Interface Atm or dsl? Atm, because is a L3 interface.
Does this sound right for you?

Cheers


Sent from Cisco Technical Support iPad App

[Giuseppe Larosa]

Hello Remco,

to answer your question the starting point is to note that the ATM layer is the payload carried within the DSL layer in the DSL frames.

With DSL the payload bit stream is split in multiple substreams and each of them is used to feed the modulator of a tone/subcarrier.

What is most important to note is that the payload bits are coded in a bigger bit block before sending to the tone modulator providing some self correction capabilities.

So it is not a surprise that errors at the DSL layer are not all reported at the upper ATM layer for this built-in self correction capability.

Another important aspect that improves the recovery capability from bit errors is inter-leaving: given the bursty nature of line noise the payload bits are not sent sequentially but a sort of matrix of bits is built and then instead of passing the rows of bits to the modulator, the columns of bits are taken. In this way a short burst of noise will likely cause single bit errors  in different rows that can be recovered by the self error correction mechanisms described before.

The price to pay for inter-leaving is more latency but it is a good tradeoff.

So a SES that is a severly errored second may happen without causing an ATM CRC error at upper layer.

A SES is defined when the bit error rate at line level is over a certain level in a second time interval.

Hope to help

Giuseppe

[SlevinKelevra]

" What is most important to note is that the payload bits are coded in a bigger bit block before sending to the tone modulator providing some self correction capabilities. "

That is absolutely true, but i always thought that these were the FEC errors, those errors are corrected after being "bad".

CRC errors are real errors, which could not be corrected.

I am aware of the interleaving method, its like a hash algoritm, where if i send you a block of text in plain old words, like

" my name is Remco" and i just send it like this and there is an error on the line this could cause the word Remco to be completely vanished, but if i scramble it like Rye mcm eso mi e (something like that) and the block eso is gone, your probably can tell what i mean if you arrange it back in order.

These are just my 2 cents about it ^^

But i want to think you all for participating, i am still not convinced entirely but it was good sparring discussion and it did clear up some things for me.