01-14-2014 01:38 AM - edited 03-04-2019 10:04 PM
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.
01-14-2014 01:54 AM
Hello
Have you enabled pre classify on the Gre?
In tunnel
qos pre-classify
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.
01-14-2014 02:21 AM
I tried both - with and without - no difference.
01-14-2014 04:26 AM
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.
01-15-2014 01:11 AM
Any other ideas?
---
pdriver, in my case drop rate is zero.
01-15-2014 11:42 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide