nosx
join:2004-12-27
00000
kudos:5 | 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.
policy-map OUT_WAN_5Q
class CLASS_5_CONTROL
priority 64
class CLASS_4_REALTIME_EF
priority 48
class CLASS_3_AF4X_AF3X
bandwidth 256
class CLASS_2_AF2X_AF1X
bandwidth 64
class class-default
bandwidth 8
random-detect
I have attempted applying it to several interfaces in hopes of finding the correct location, First was the ATM PVC as reccomended by cisco...
interface ATM0/0
bandwidth 512
bandwidth receive 3008
no ip address
no atm ilmi-keepalive
bundle-enable
dsl operating-mode auto
max-reserved-bandwidth 100
hold-queue 224 in
pvc 0/35
vbr-nrt 512 512 1
tx-ring-limit 3
service-policy output OUT_WAN_5Q
max-reserved-bandwidth 100
pppoe-client dial-pool-number 1
And while indeed it does apply and count traffic passing through:
Cisco_1760#show policy-map int atm0/0 vc 0/35
ATM0/0: VC 0/35 -
Service-policy output: OUT_WAN_5Q
Class-map: CLASS_5_CONTROL (match-any)
1142 packets, 129362 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp cs6 (48) cs7 (56)
1142 packets, 129362 bytes
5 minute rate 0 bps
Queueing
Strict Priority
Output Queue: Conversation 40
Bandwidth 64 (kbps) Burst 1600 (Bytes)
(pkts matched/bytes matched) 847/93507
(total drops/bytes drops) 0/0
Class-map: CLASS_4_REALTIME_EF (match-any)
2 packets, 156 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp cs5 (40) ef (46)
2 packets, 156 bytes
5 minute rate 0 bps
Queueing
Strict Priority
Output Queue: Conversation 40
Bandwidth 48 (kbps) Burst 1200 (Bytes)
(pkts matched/bytes matched) 0/0
(total drops/bytes drops) 0/0
Class-map: CLASS_3_AF4X_AF3X (match-any)
8070 packets, 1097623 bytes
5 minute offered rate 2000 bps, drop rate 0 bps
Match: ip dscp cs4 (32) af41 (34) af42 (36) af43 (38)
8070 packets, 1097623 bytes
5 minute rate 2000 bps
Match: ip dscp cs3 (24) af31 (26) af32 (28) af33 (30)
0 packets, 0 bytes
5 minute rate 0 bps
Queueing
Output Queue: Conversation 43
Bandwidth 256 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 8070/1097623
(depth/total drops/no-buffer drops) 0/0/0
...
Under congestion it doesnt prioritize any traffic, it just WFQ's:
Cisco_1760#show queue atm 0/0 vc 0/35
Interface ATM0/0 VC 0/35
Queueing strategy: weighted fair
Output queue: 0/512/64/0 (size/max total/threshold/drops)
Conversations 0/4/32 (active/max active/max total)
Reserved Conversations 3/5 (allocated/max allocated)
Available Bandwidth 72 kilobits/sec
Next as per suggestions from other people, I applied it to the dialer interface:
interface Dialer0
bandwidth 512
bandwidth receive 3008
ip address negotiated
ip access-group ACL_PROTECT_WAN_IN in
no ip unreachables
ip mtu 1492
ip nat outside
ip virtual-reassembly max-reassemblies 512 timeout 16
encapsulation ppp
dialer pool 1
...
ppp ipcp route default
ppp multilink interleave
ppp multilink fragment delay 4
max-reserved-bandwidth 100
service-policy output OUT_WAN_5Q
Which again successfully applied the policy-map and counts traffic passing:
Cisco_1760#show policy-map int dialer0
Dialer0
Service-policy output: OUT_WAN_5Q
Class-map: CLASS_5_CONTROL (match-any)
685 packets, 69059 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp cs6 (48) cs7 (56)
685 packets, 69059 bytes
5 minute rate 0 bps
Queueing
Strict Priority
Output Queue: Conversation 136
Bandwidth 64 (kbps) Burst 1600 (Bytes)
(pkts matched/bytes matched) 0/0
(total drops/bytes drops) 0/0
Class-map: CLASS_4_REALTIME_EF (match-any)
2 packets, 156 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp cs5 (40) ef (46)
2 packets, 156 bytes
5 minute rate 0 bps
Queueing
Strict Priority
Output Queue: Conversation 136
Bandwidth 48 (kbps) Burst 1200 (Bytes)
(pkts matched/bytes matched) 0/0
(total drops/bytes drops) 0/0
Class-map: CLASS_3_AF4X_AF3X (match-any)
9108 packets, 1030672 bytes
5 minute offered rate 2000 bps, drop rate 0 bps
Match: ip dscp cs4 (32) af41 (34) af42 (36) af43 (38)
9108 packets, 1030672 bytes
5 minute rate 2000 bps
...
And successfully changed the queueing strategy for the interface:
Cisco_1760#show queueing int dialer0
Interface Dialer0 queueing strategy: fair
Input queue: 1/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: Class-based queueing
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/0/128 (active/max active/max total)
Reserved Conversations 3/3 (allocated/max allocated)
Available Bandwidth 72 kilobits/sec
However in the end has no effect because it will NOT clone itself onto the virtual-access interface:
...
%SYS-5-CONFIG_I: Configured from console by DBM on vty0
Class Based Weighted Fair Queueing will be applied only to the Virtual-Access interfaces associated with an MLP bundle.
Class Based Weighted Fair Queueing will be applied only to the Virtual-Access interfaces associated with an MLP bundle.
%DIALER-6-BIND: Interface Vi1 bound to profile Di0
%LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up
...
Cisco_1760#show queueing int virtual-access1
Interface Virtual-Access1 queueing strategy: none
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. |
|
2 edits | you show policy-map and your queue look good. what makes you think that it's not working? |
|
nosx
join:2004-12-27
00000
kudos:5 | 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... |
|
nosx
join:2004-12-27
00000
kudos:5 | I went through and moved the relavent pvc configuration to a point-to-point subinterface:
Cisco_1760(config)#int atm0/0.35 point-to-point
Cisco_1760(config-subif)# pvc 0/35
Cisco_1760(config-if-atm-vc)# vbr-nrt 512 512 1
Cisco_1760(config-if-atm-vc)# tx-ring-limit 3
Cisco_1760(config-if-atm-vc)# service-policy output OUT_WAN_5Q
Cisco_1760(config-if-atm-vc)# max-reserved-bandwidth 100
Cisco_1760(config-if-atm-vc)# pppoe-client dial-pool-number 1
Cisco_1760(config-if-atm-vc)#end
Cisco_1760#show policy-map int atm0/0
Cisco_1760#show policy-map int atm0/0.35
ATM0/0.35: VC 0/35 -
Service-policy output: OUT_WAN_5Q
Class-map: CLASS_5_CONTROL (match-any)
7 packets, 782 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp cs6 (48) cs7 (56)
7 packets, 782 bytes
5 minute rate 0 bps
Queueing
Strict Priority
Output Queue: Conversation 40
Bandwidth 64 (kbps) Burst 1600 (Bytes)
(pkts matched/bytes matched) 6/654
(total drops/bytes drops) 0/0
...
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... |
|
 rolandeCertifiablePremium,Mod
join:2002-05-24
Prosper, TX
 ·AT&T U-Verse
Host:
Linksys
AT&T U-verse
| 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!
»www.thewaystation.com/
»blog.thewaystation.com/ |
|
nosx
join:2004-12-27
00000
kudos:5 | Da Geek Kid,
Yes I misspoke, I was using the word discard to reference the traffic killed by the strict priority queue policer.
Rolande,
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. |
|
1 edit | 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.
best regards
Angel
angel [dot] sanchez [at] rstlogic [dot] com |
|
