hi i have a question regarding the random drop counter and drop probability on a T3 interface that is terminating T1s.
I have fair-queue enabled on the interface ser10/0/0/1:1 and random detect, this interface is also being rate-limited to 768K in/out.
This interface has extremely brusty traffic, it constantly goes from
30 second input rate 3000 bits/sec, 3 packets/sec
30 second output rate 14000 bits/sec, 3 packets/sec
30 second input rate 423000 bits/sec
30 second output rate 774000 bits/sec
I'm trying to eliminate global sync and letting the most important packets through.
sh queueing int ser10/0/0/1:1
Interface Serial10/0/0/1:1 queueing strategy: VIP-based fair queueing
Serial10/0/0/1:1 queue size 0
pkts output 14386, wfq drops 496, nobuffer drops 0
WFQ: aggregate queue limit 192 max available buffers 192
Packet drop strategy: VIP-based random early detection (DWRED)
Exp-weight-constant: 9 (1/512)
Mean queue depth: 0
Queue size: 0 Maximum available buffers: 192
Output packets: 14386 WRED drops: 496 No buffer: 0
Class Random Tail Minimum Maximum Mark Output
drop drop threshold threshold probability Packets
0 0 0 48 96 1/5 13609
1 0 0 54 96 1/7 414
2 0 0 60 96 1/9 0
3 0 0 66 96 1/10 0
4 0 0 72 96 1/10 0
5 0 0 78 96 1/10 0
6 0 0 84 96 1/0 0
7 0 0 90 96 1/0 0
according to the above, wfq droped 496, and it also says WRED droped 496 but on WRED random drop counters its all zeros, is there a reason for this?
I had to manual configure the drop probability because by default it was all 1/0, although it listed WRED dropping packets, shouldn't the default be 1/10?
thanks in advance, P
I'm not sure, but since it is DWRED, you may have to log on to the VIP to extract detailed counters.
Does show interfaces random-detect show anything inteersting?
System image file is "disk0:s72033-advipservicesk9_wan-mz.122-18.SXF14.bin"
cisco WS-C6509 (R7000) processor (revision 3.0) with 983008K/65536K bytes of memory.
Processor board ID SCA061300KT
SR71000 CPU at 600Mhz, Implementation 0x504, Rev 1.2, 512KB L2 Cache
Last reset from power-on
SuperLAT software (copyright 1990 by Meridian Technology Corp).
X.25 software, Version 3.0.0.
TN3270 Emulation software.
2 FlexWAN controllers (4 Serial).
4 Virtual Ethernet/IEEE 802.3 interfaces
96 FastEthernet/IEEE 802.3 interfaces
4 Gigabit Ethernet/IEEE 802.3 interfaces
4 Serial network interfaces
One of the DWRED experts I exchanged email with said this could be a counter anomaly, and it might be useful to see the configuration.
This is probably best pursued as a TAC case to ensure that there is no inadvertent public exposure of your configuration information.
Phillip, its your basic standard sub serial with frame-relay encaps and fair-queue.
I know for a fact its working but the counter is not incrementing. On another note i have a route-map on a vlan interface that does the same thing the route-map counter never increments but again its working because packets are going to the next hop address. the strange thing is when i remove the policy map from the interface and/or reapply it the counter interments then stops. I beginging to think its a 6500 thing, the 6500 is a bit wierd somethings.
route-map voip_on_wired_T3, permit, sequence 10
ip address (access-lists): 185
ip next-hop x.x.x.x
Policy routing matches: 0 packets, 0 bytes
no ip redirects
no ip proxy-arp
ip route-cache same-interface
ip route-cache flow
ip policy route-map voip_on_wired_T3
ip ospf priority 10
service-policy input trust-dscp
A report from a Distinguished Technical Marketing Engineer:
If the PBR is taking place in hardware, it is not goingto show up in the show route-map output, only thing that will cause thosecounters to increment is software switched packets. "Show queuing ..." isnot useful on FlexWAN, you need to use show policy map,
And I add:
for details on show policy-map.
This is one of the problems when you have several architecturally diverse platforms sharing a common code base (IOS).
Phillip for PBR, i suspected as much. Doing show policy-map will not work as i just added fair-queue to the flexwan t1 port. I believe this would only be useful for actual policy maps and not for the command fair-queue under the interface.
"This is one of the problems when you have several architecturally diverse platforms sharing a common code base (IOS)"
I couldn't of said it better myself, thanks Paul
"The strange thing is when i remove the policy map from the interface and/or reapply it the counter interments then stops."
This is not atypical - In general, any packet passing through the "processor path" increments those kinds of counters. Once the processor updates the FlexWAN (or other auxilliary "switching processor") to have the appropriate forwarding information, the route processor will not see another packet unless the FlexWAN (or whatever) cache is somehow invalidated. Some of the "switching processor" cards are more capable about updating certain classes or counters than other cards.
Since the specifics of a switching path may behavior vary by architecture, configuration, version, etc., it is best to address these classes of questions to an expert in the specific architecture by way of the TAC.
So, this question has wandered to a lot of different places - what, exactly, are you trying to do?
One additional note:
FlexWAN best practice QoS configs:
Be careful that some configs outside of the recommended practices may relegate your traffic to the slower software switching path.