Showing results for 
Search instead for 
Did you mean: 
Join Customer Connection to register!

QoS policy to protect GRE traffic

We are using a Cisco ISR 1812 router IOS 124-15.T11 adv ip services loaded.

This router has a 3Mbps/1Mbps cable ISP connection to a Physical FE port.  We have also built an IPSEC+GRE tunnel back to the Central Office where the Corporate Web server sits.  I want to know if there is a way to control Internet use by way of a QoS policy to protect GRE traffic from being starved out by the user Internet traffic.

So far this is all I can come up with.

class-map match-all Intranet
match input-interface Tunnel0
class-map match-all Internet
match input-interface FastEthernet1
policy-map QoS_Control
class Intranet
  bandwidth 1000
class Internet
  shape average 2000000

interface Tunnel0
Tunnel to Corp 1
bandwidth 1544
ip address
ip tcp adjust-mss 1378
load-interval 30
tunnel source Loopback0
tunnel destination

interface FastEthernet0
description trunk port
no ip address
no ip redirects
no ip mroute-cache
load-interval 30
speed 100
service-policy output QoS_Control
interface FastEthernet0.1
description User VLAN 1 LAN
encapsulation dot1Q 1 native
ip address
no ip redirects
ip accounting output-packets
ip nat inside
no ip virtual-reassembly
no ip mroute-cache
interface FastEthernet0.2
description User Vlan 2 LAN
encapsulation dot1Q 2
ip address
no ip redirects
no ip mroute-cache

interface FastEthernet1
description Internet Access WAN
bandwidth 3000
ip address dhcp
no ip redirects
ip nat outside
ip inspect firewall out
ip virtual-reassembly
load-interval 30
duplex auto
speed auto
crypto map s2s

This is just a real basic setup that I wanted to try to see if it works.  This policy map would be applied outbound to the LAN side.  So outbound traffic to users would be shaped to 2Mbps with bursts allowed without starving out the entire pipe and killing our Intranet server access.

Let me know what if anyone has any better ideas here.

Should this work?

Calin C.

Hi there!

The syntax and structure is fine, but I didn't saw too often somebody to shape or police the traffic on the LAN interface. Usually  this is done outbound to the WAN.

"bandwidth" parameter is used for CBWFQ, so, queueing. The packets arrive on your router in the orderd delivered by the remote end, in this way you give priority to the packets from the tunnel interface direction inbound.

I would do it somehow different:

1. ACL for the interesting traffic which will be put into VPN Tunnel

2. Match the ACL into one class-map (let's name it VPN)

3. Match the class-map VPN into one policy-map

-in the policy-map you will have 2 classes:

1st - VPN with a bandwidth or priority (since this is the important traffic for you, you might want to give it some priority queueing) with a value of 1Mbps

2nd - class-default (which is there but you don't see it) in which you match all other traffic which isn't falling into the VPN class; you don't have do to anything else as it's matched automatically; you can shape this traffic to avoid packet drops on the provider side

4. Apply the policy-map outbound on the WAN interface.

Let me know if you understood my explanation and if you need more help.


Calin thanks for your response, however an outbound policy on the WAN interface doesn't do much as its inbound traffic on the WAN that's my problem.  I am trying to keep large downloads inbound on the WAN from eating up all the available bandwidth so I am simply shaping Internet traffic to users outbound on the LAN side as this would be the direction of the traffic from the Internet to a user through the router.

My issue is making sure that the GRE traffic does not make its way into the shaping policy and I am trying to make sure that it isn't.  I just implemented this yesterday and wil check today with some testing to see how it goes.  I have never used the match interface commands before and to me this makes sense seeing how I want traffic sourced from GRE to be given a share of bandwidth.

Rising star


if you're concern about traffic inbound from corporate central office (where corporate servers sits), then you could apply qos outbound on the central router towards the remote router and also you could also apply qos outbound on the remote router towards the central office  router.

In your configuration above, you are applying service policy on the physical instead of the tunnel interface, you need the qos preclassify enable on the physical to classify pre-tunnel IP header or else you pre-tunnel IP header will not get classify before encryption..