Policy-Map - Offered rate to high

[Heinz Kern]

I´m facing a confuse problem. maybe the solution is simple but i can´t find it.

the show policy map shows an offered rate far above the target shape rate

show policy-map interface tunnel 204

Tunnel204

  Service-policy output: BA-DBNA-BRANCH-OUT-2M

    Class-map: class-default (match-any)

      20511 packets, 782918464 bytes

      30 second offered rate 17882000 bps, drop rate 0 bps

      Match: any

      Queueing

      queue limit 64 packets

      (queue depth/total drops/no-buffer drops) 0/0/0

      (pkts output/bytes output) 20515/7366846

      shape (average) cir 1940000, bc 19400, be 0

      target shape rate 1940000

      Service-policy : BA-DBNA-BRANCH-OUT

        queue stats for all priority classes:

          queue limit 64 packets

          (queue depth/total drops/no-buffer drops) 0/0/0

          (pkts output/bytes output) 17550/6619020

        Class-map: BA-DBNA-VOIP (match-any)

          17550 packets, 770242200 bytes

          30 second offered rate 17630000 bps, drop rate 0 bps

          Match: mpls experimental topmost 5

            17484 packets, 770240136 bytes

            30 second rate 17630000 bps

          Match: ip dscp ef (46)

            66 packets, 2064 bytes

            30 second rate 0 bps

          Priority: 60% (1164 kbps), burst bytes 29100, b/w exceed drops: 0

the tunnel-interface as well as the physical interface show the correct statistics when doing a show interface

show interfaces gigabitEthernet 0/1

GigabitEthernet0/1 is up, line protocol is up

  Hardware is CN Gigabit Ethernet, address is e05f.b903.30f1 (bia e05f.b903.30f1)

  Description: 01-00-246387-1011 - 2M

  MTU 1578 bytes, BW 100000 Kbit/sec, DLY 100 usec,

     reliability 255/255, txload 1/255, rxload 1/255

  Encapsulation 802.1Q Virtual LAN, Vlan ID  1., loopback not set

  Keepalive set (10 sec)

  Full Duplex, 100Mbps, media type is RJ45

  output flow-control is unsupported, input flow-control is unsupported

  ARP type: ARPA, ARP Timeout 04:00:00

  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: 0

  Queueing strategy: Class-based queueing

  Output queue: 0/1000/0 (size/max total/drops)

  30 second input rate 170000 bits/sec, 62 packets/sec

  30 second output rate 162000 bits/sec, 55 packets/sec

     234536 packets input, 78663340 bytes, 0 no buffer

     Received 22658 broadcasts (0 IP multicasts)

     0 runts, 0 giants, 0 throttles

     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

     0 watchdog, 18509 multicast, 0 pause input

     212201 packets output, 74583997 bytes, 0 underruns

     0 output errors, 0 collisions, 2 interface resets

     7440 unknown protocol drops

     0 babbles, 0 late collision, 0 deferred

     1 lost carrier, 0 no carrier, 0 pause output

     0 output buffer failures, 0 output buffers swapped out

show interfaces tunnel 204

Tunnel204 is up, line protocol is up

  Hardware is Tunnel

  Description: to AT-DBN-T2-R1 Tunnel2042499 primary

  Internet address is 12.221.144.206/30

  MTU 17916 bytes, BW 1940 Kbit/sec, DLY 50000 usec,

     reliability 255/255, txload 20/255, rxload 29/255

  Encapsulation TUNNEL, loopback not set

  Keepalive not set

  Tunnel source 12.121.144.206 (GigabitEthernet0/1.2499), destination 12.121.144.205

   Tunnel Subblocks:

      src-track:

         Tunnel204 source tracking subblock associated with GigabitEthernet0/1.2499

          Set of tunnels with source GigabitEthernet0/1.2499, 1 member (includes iterators), on interface <OK>

  Tunnel protocol/transport GRE/IP

    Key disabled, sequencing disabled

    Checksumming of packets disabled

  Tunnel TTL 255, Fast tunneling enabled

  Tunnel transport MTU 1554 bytes

  Tunnel transmit bandwidth 8000 (kbps)

  Tunnel receive bandwidth 8000 (kbps)

  Tunnel protection via IPSec (profile "DBNA-KEYRING")

  Last input 00:00:00, output never, output hang never

  Last clearing of "show interface" counters never

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 1

  Queueing strategy: fifo (QOS pre-classification)

  Output queue: 0/0 (size/max)

  30 second input rate 228000 bits/sec, 109 packets/sec

  30 second output rate 156000 bits/sec, 58 packets/sec

     232495 packets input, 59455529 bytes, 0 no buffer

     Received 0 broadcasts (0 IP multicasts)

     0 runts, 0 giants, 0 throttles

     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

     223872 packets output, 74714660 bytes, 0 underruns

     0 output errors, 0 collisions, 0 interface resets

     89 unknown protocol drops

     0 output buffer failures, 0 output buffers swapped out

does anybody have an idea? platform is 2900

thx

[Heinz Kern]

there is a far more easy setup with the same problem:

show policy-map interface tunnel 204

Tunnel204

  Service-policy output: BA-DBNA-BRANCH-OUT-2M

    Class-map: class-default (match-any)

      5983 packets, 149595053 bytes

      30 second offered rate 15750000 bps, drop rate 0 bps

      Match: any

      Queueing

      queue limit 64 packets

      (queue depth/total drops/no-buffer drops) 0/0/0

      (pkts output/bytes output) 5905/1905042

      shape (average) cir 1940000, bc 19400, be 0

      target shape rate 1940000

config:

policy-map BA-DBNA-BRANCH-OUT-2M

class class-default

  shape average 1940000 19400 0

[milan.kulik]

Hi,

IMHO,offered rate is the rate the matching packets are received.

So it's not the rate the route would be "offering" to the packet flows, it's just a confusing Cisco term.

See http://www.cisco.com/en/US/customer/docs/ios/12_2/qos/command/reference/qrfcmd10.html#wp1049822

Best regards,

Milan

[Joseph W. Doherty]

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

If I'm reading your stats correctly, looks like the offered rate has slipped a decimal for is display, i.e. 10x too much.

If you have support, bring it to TAC or try a later IOS release, if available.

[Heinz Kern]

thanks for the answers

@ milan: i don´t think that you are correct. a show int tunnel shows the true bandwidth and it is suitable (approx 120kbps). a "sho policy-map int tunnel " shows several Mbit/s. i don´t see a reasonable answer for that

@ joseph: i already opened a case. but i wanted  to prevent that

[Joseph W. Doherty]

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

@ joseph: i already opened a case. but i wanted  to prevent that

Why prevent opening a TAC case, that's why we pay for support?

I suspect its a cosmetic bug.  However if you're impatient with TAC, besides trying a newer release, you might also try older too, as bugs are sometimes introduced.

Offered rate should be the "ingress" rate to the CBWFQ class.  The aggregate of all class offered rates, less their drop rates, should be the reflected on the interface's rate (of course, ingress or egress depending on input or output policy - also accounting for multiple policies on "interfaces" like subinterfaces or tunnels).

I believe I've noticed that the rates are not always exactly "sync'ed", but they shouldn't be as far off as your stats show.

BTW, what exact platform and IOS are you seeing this on?

[Heinz Kern]

tac-case always takes such a lot of time. perhaps routing is a bit better...but wlan is really a mess

platform is 2900 with 15.1.4