QoS shaping on GRE tunnel

[Vasilii Mikhailovskii]

Hello, everybody.

Today I've faced an issue with shaping on GRE tunnel.

I'm using 2821 with c2800nm-advipservicesk9-mz.124-24.T8.bin IOS.

The issue is: shaping service-policy on GRE interface (simple GRE, no IPSec) doesn't work.

policy-map QOS_TUNNEL_3M

class class-default

    shape average 2800000 56000 0

sh policy-map int tu101

  Service-policy output: QOS_TUNNEL_3M

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

      1014015 packets, 836978150 bytes

      30 second offered rate 3809000 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) 326/31948

      shape (average) cir 2800000, bc 56000, be 0

      target shape rate 2800000

in a couple of minutes:

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

      1177550 packets, 966953038 bytes

      30 second offered rate 3491000 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) 386/37828

      shape (average) cir 2800000, bc 56000, be 0

      target shape rate 2800000

I've noticed that "Hierarchical Queueing Framework" states:

Some QoS deployments include a service policy with queueing features applied at the tunnel or a virtual interface and a service policy with queueing features applied at the physical interface. In Cisco IOS Release 12.4(20)T, you can apply a service policy with queuing features only at one of these interfaces. When migrating to Cisco IOS Release 12.4(20)T, a router configuration containing service policies at both interfaces will only keep the one applied to the physical interface.

The only issue I could imagine is that GRE been sourced from SVI interface.

Any ideas?

PS: I have never had any similar issues on GRE interfaces before.

[paul driver]

Hello

Have you enabled pre classify on the Gre?

In tunnel

qos pre-classify

The qos pre-classify command

When packets are encapsulated by tunnel or encryption headers, QoS       features are unable to examine the original packet headers and correctly       classify the packets. Packets traveling across the same tunnel have the same       tunnel headers, so the packets are treated identically if the physical       interface is congested. With the introduction of the       Quality of       Service for Virtual Private Networks (VPNs) feature, packets can now be       classified before tunneling and encryption occur.

res

Paul

Please don't forget to rate any posts that have been helpful.

Thanks.

[Vasilii Mikhailovskii]

I tried both - with and without - no difference.

[paul driver]

Humm

Could be you not genrating enough traffic

I have labbed this up and here are the results

sh policy-map interface  tun 1

Tunnel1

  Service-policy output: TST

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

      157156 packets, 194411078 bytes

      30 second offered rate 7483000 bps, drop rate 4758000 bps

      Match: any

      Queueing

      queue limit 64 packets

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

      (pkts output/bytes output) 76968/75914796

      shape (average) cir 2800000, bc 56000, be 0

      target shape rate 2800000

7476000 bps, drop rate 4747000 bps = 2729000

res

Paul

Please don't forget to rate any posts that have been helpful.

Thanks.

[Vasilii Mikhailovskii]

Any other ideas?

---

pdriver, in my case drop rate is zero.

[paul driver]

Hello
"
The only issue I could imagine is that GRE been sourced from SVI interface."

Is traffic actually routing over the tunnel - Can you post the config of the physical and tunnel interfaces also


Res
Paul

Sent from Cisco Technical Support iPad App