Low Latency Queueing Problem With PPPOE(OA?)
Alrighty, I have a simple setup on a 1760 with the latest 12.4T and a WIC-1ADSL. Everything does "work", it authenticates, creates the vi1 interface, gets an IP, passes traffic, however with congestion I can not get LLQ or CBWFQ working.
Below are some relavent configs, please dont question the bandwidth alotments or the fact im priority queueing two seperate classes, I assure you its done for a reason, and im setting my DSCPs abnormally on the LAN side.
I have attempted applying it to several interfaces in hopes of finding the correct location, First was the ATM PVC as reccomended by cisco...
And while indeed it does apply and count traffic passing through:
Under congestion it doesnt prioritize any traffic, it just WFQ's:
Next as per suggestions from other people, I applied it to the dialer interface:
Which again successfully applied the policy-map and counts traffic passing:
And successfully changed the queueing strategy for the interface:
However in the end has no effect because it will NOT clone itself onto the virtual-access interface:
And no policy-map is being applied to the vi1 interface.
So heres the question. Is LLQ possible (have you actually got this working?) on ADSL PPPOE (with an ATM interface) like this. Is there anything blatantly obvious im missing? I would really appreciate your opinions as far as to what next step to try with this stuff.
My best guess as to the problem is that the ATM interface doesnt have an IP or perform any real layer 3 processing, its probablly just seeing PPPOE traffic cross it, and every other interface on top of it like di0 or vi1 are just virtual so they cant experience congestion.
you show policy-map and your queue look good. what makes you think that it's not working?
I ran a few tests, same policy map on a wic-1dsu-t1 using timeslots 1-8. Under load from the solarwinds WANkiller tool, the serial queued traffic and prioritized EF / control traffic while the 512k atm failed to prioritize under identical conditions. Jitter, latency (and under high load, drops) for voice across the serial was negligible under load while across the atm it went off the chart. I believe the output from the show policy-map to be cosmetic only, in reality i dont believe the atm interface is properly queueing based on configured CBWFQ, it seems to just WFQ and indiscriminatly drop if enough stress is put on it. The serial appears to properly handle congestion when configured with wred and strict priority queueing.
Im open to more testing suggestions.
|reply to nosx |
change your atm to point to point and retest...
I went through and moved the relavent pvc configuration to a point-to-point subinterface:
Latency wasnt improved from the original test with the PVC under the main interface, and as an added bonus I noticed something else: the show policy-map int command SHOWS the policer will discard traffic if i send it above the CAR, however when i fire up iperf on both sides of the router eventhough the policer reports its discarding packets, they are still arriving at the recv location (I policed a 400kbps stream of udp down to 48kbps). "(total drops/bytes drops) 6580/486958" however at the remote site it shows that indeed it recieved around 9981 of the 10k packets sent lol
huh? it discards all traffic? I do not think so... it should only discard above the CAR which is what you are getting...
|reply to nosx |
I'll be interested to see if you can dig any more info up on this. I thought I remember someone mentioning once that the WIC-1ADSL module was not really capable of handling queuing in hardware, although it is configurable. I never could find any hard documentation reflecting this statement though.
If you apply the service-policy to the Dialer interface instead of the ATM PVC does that resolve the issue? Is it possible that the ATM interface is slicing up the cells prior to that queuing policy which is causing it to behave inappropriately or in an unexpected manner? The config suggestions I have always seen for this module for queuing show the service-policy on the Dialer interface and not the physical interface configuration.--
Ignorance is temporary...stupidity lasts forever!
Da Geek Kid,
Yes I misspoke, I was using the word discard to reference the traffic killed by the strict priority queue policer.
My understanding was that the dialer was just like a virtual template, applying something to it has no effect until a virtual-access interface is cloned from it. You can apply anything you want to it, but if the virtual access doesnt accept the configuration when it clones, it will have no useful effect. The Virtual-access interface will not accept CBWFQ/LLQ policy-maps. Furthermore virtual interfaces such as dialers, VTs, VAs, etc dont have queues, they are just FIFO with near unlimited bandwidth, and dont get congested (thus appear not to properly shape, queue, or police effectively). If i check the ATM interface after applying just a policer policy, the policer claims to be dropping traffic but the traffic is still transmitted, and the ATM interface shows that its tail dropping cells indicating the traffic sent through is far above the policer value and congesting it. Im very displeased with the WIC-1ADSL and am wondering if the WIC2-1ADSL? provides better hardware support for this sort of thing? The fact that the interface is ATM could in itself prevent the use of CBWFQ/LLQ. At work I havent seen an ATM interface with a shaping service-policy applied, just a VBR-NRT? statement. Next best solution is to stick a wic-1enet in and just shape the ethernet down to 512k. I know shapers do function on ethernet interfaces, but it would mean setting up an external DSL modem and not having reliable link failure detection, instead requiring reliance on the SLA? features (didnt Cisco renamed that?) to detect link failure.
|reply to nosx |
so I am looking @ this doc
and it says to use 12.3T and yet it states to use Y train for ADSL
IMHO -- I'd try 12.3(7)XR7 IP/ADSL PLUS... let me know if it's better...
|reply to nosx |
hi, i was having troubles with a virtual template too, it shutdown the interface when i assing a policy into it.
solution, shut & no shut.
now i have to solve something with a fast ethernet interface.
by the way what terminal emulator do you use? the one with the line numbers, very cool.
angel [dot] sanchez [at] rstlogic [dot] com