02-09-2013 03:30 AM - edited 03-04-2019 06:59 PM
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??
02-09-2013 06:35 PM
Post the following output:
1. sh dsl interface;
2. sh int dial0
02-10-2013 06:15 AM
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.
02-10-2013 01:32 PM
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
02-10-2013 02:53 PM
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.
02-10-2013 04:13 PM
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
02-10-2013 11:30 PM
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
02-11-2013 09:31 AM
" 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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide