Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

IPSEC Tunnel Protection and per-tunnel QOS shaping doesnt do any shaping.

 

I am having a small brain implosion as to why this will not work.

 

I have tried the QOS policy on the tunnel interfaces and on the ATM interface. No shaping occurs. The interfaces transmit at their leisure.

 

Please can someone having a better day than me tell me what I am doing wrong?

 

Below is the relevant (and standard) config. without the service-policy command applied anywhere. Any help appreciated.

---------------------------------------------------------------------------------

 

class-map match-any APPSERVERS
 match access-group name TERMINALSERVERS
class-map match-any VOICE
 match protocol sip
 match protocol rtp
 match  dscp ef
!
!
policy-map QOSPOLICY
 class VOICE
    priority 100
 class APPSERVERS
    bandwidth percent 33
 class class-default
    fair-queue 16
policy-map TUNNEL
 class class-default
    shape average 350000
  service-policy QOSPOLICY
!
!
interface Tunnel0
 bandwidth 350
 ip address 172.20.58.2 255.255.255.0
 ip mtu 1420
 load-interval 30
 qos pre-classify
 tunnel source Dialer0
 tunnel destination X.X.X.X
 tunnel mode ipsec ipv4
 tunnel path-mtu-discovery
 tunnel protection ipsec profile IPSECPROFILE
!
interface Tunnel1
 bandwidth 350
 ip address 172.21.58.2 255.255.255.0
 ip mtu 1420
 load-interval 30
 delay 58000
 qos pre-classify
 tunnel source Dialer0
 tunnel destination Y.Y.Y.Y
 tunnel mode ipsec ipv4
 tunnel path-mtu-discovery
 tunnel protection ipsec profile IPSECPROFILE
!
!
interface ATM0/0/0
 no ip address
 load-interval 30
 no atm ilmi-keepalive
!
interface ATM0/0/0.1 point-to-point
 pvc 0/38
  encapsulation aal5mux ppp dialer
  dialer pool-member 1
 !
!
interface Dialer0
 bandwidth 400
 ip address negotiated
 

---------------------------------------------------------------------------------------------------------

 

Thanks,

 

Paul

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Paul, One of the reasons

Paul, 

One of the reasons could be due to VTI overhead. 

That being said I'm not sure that's the way to go with your QoS: 

https://tools.cisco.com/bugsearch/bug/CSCsz63683/?reffering_site=dumpcr

 

My suggestion: give it a try with 15.2 M/T and open a TAC case with folks handing QoS rather than VPN ;-)

 

M. 

4 REPLIES
Cisco Employee

Paul,  What's the version and

Paul, 

 

What's the version and platform. Is there QoS elsewhere configured on the path (Dialer interfaces?)

Try without HQoS, just flat shaper before you move on. 

 

M.

New Member

 Hi mate, This is an 1841

 

Hi mate,

 

This is an 1841 with 12.4 (20) but Ive tried it on 15.1 on a 1941 also. I get some measure of traffic reduction but I cannot fathom what it is actually doing.

In the lab with the 1841 and a flat shaper I get this:

policy-map SHAPE
 class class-default
    shape average 600000

 

interface Tunnel0
 bandwidth 700
 service-policy output SHAPE

R1#sh policy-map int
 Tunnel0

  Service-policy output: SHAPE

    Class-map: class-default (match-any)
      18664 packets, 26423115 bytes
      30 second offered rate 452000 bps, drop rate 0 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 45/0/0
      (pkts output/bytes output) 18659/27808530
      shape (average) cir 600000, bc 2400, be 2400
      target shape rate 600000
R1#sh policy-map int
 Tunnel0

  Service-policy output: SHAPE

    Class-map: class-default (match-any)
      19044 packets, 26964413 bytes
      30 second offered rate 451000 bps, drop rate 0 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 45/0/0
      (pkts output/bytes output) 19039/28378426
      shape (average) cir 600000, bc 2400, be 2400
      target shape rate 600000

 

It just holds the data rate around 450 kbps. ??

 

Here are the types of results I get when the HQoS is applied to the Tunnel interface in the lab:

policy-map QOS
 class IP2
    drop
 class IP3
    priority 300
 class class-default
policy-map TUNNEL
 class class-default
    shape average 600000
  service-policy QOS

interface Tunnel0
 bandwidth 700
 service-policy output TUNNEL

 

R1#sh policy-map int
 Tunnel0

  Service-policy output: TUNNEL

    Class-map: class-default (match-any)
      14843 packets, 20884436 bytes
      30 second offered rate 362000 bps, drop rate 75000 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/3942/0
      (pkts output/bytes output) 14009/15858326
      shape (average) cir 600000, bc 2400, be 2400
      target shape rate 600000

      Service-policy : QOS

        queue stats for all priority classes:
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/3942/0
          (pkts output/bytes output) 6464/9540288

        Class-map: IP2 (match-all)
          385 packets, 533940 bytes
          30 second offered rate 28000 bps, drop rate 28000 bps
          Match: access-group 102
          drop

        Class-map: IP3 (match-all)
          10411 packets, 14628188 bytes
          30 second offered rate 191000 bps, drop rate 75000 bps
          Match: access-group 103
          Priority: 300 kbps, burst bytes 7500, b/w exceed drops: 3942


        Class-map: class-default (match-any)
          4047 packets, 5722308 bytes
          30 second offered rate 143000 bps, drop rate 0 bps
          Match: any

          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 7545/6318038

 

This is after 10 minutes of running transfers to all endpoints to utilise the classes in the policy.

So why dont we see shaping that moves towards the configured values?

Thanks.

 

 

Cisco Employee

Paul, One of the reasons

Paul, 

One of the reasons could be due to VTI overhead. 

That being said I'm not sure that's the way to go with your QoS: 

https://tools.cisco.com/bugsearch/bug/CSCsz63683/?reffering_site=dumpcr

 

My suggestion: give it a try with 15.2 M/T and open a TAC case with folks handing QoS rather than VPN ;-)

 

M. 

New Member

 That's some good searching

 

That's some good searching right there brother.

That bug could be exactly why Im seeing those results on my production routers since 50% of them run IOS 12.4(20)T, 12.4(22)T and 12.4(24)T.

Ill try an upgrade on one of them somewhere quiet and re-test. If that fails, Ill TAC

Many thanks for your help.

204
Views
0
Helpful
4
Replies