dwred random counter question

[paul amaral]

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

to

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

[Phillip Remaker]

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?

[paul amaral]

no it doesn't, all zeros for counters.

[Phillip Remaker]

Which platform and IOS version is this?

[paul amaral]

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.
Bridging software.
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

[Phillip Remaker]

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.

[paul amaral]

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
  Match clauses:
    ip address (access-lists): 185
  Set clauses:
    ip next-hop x.x.x.x
  Policy routing matches: 0 packets, 0 bytes

interface Vlan1

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
!

[Phillip Remaker]

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:

See also

http://www.cisco.com/en/US/tech/tk543/tk760/technologies_tech_note09186a0080108e2d.shtml

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).

[paul amaral]

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

[Phillip Remaker]

"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?

[Phillip Remaker]

One additional note:

FlexWAN best practice QoS configs:

http://www.cisco.com/en/US/docs/routers/7600/install_config/flexwan_config/flexqos.html

Be careful that some configs outside of the recommended practices may relegate your traffic to the slower software switching path.