QOS on GRE Interface

[Vinayaka Raman]

All sites have an internet link and a policy shaper applied on WAN link.

we have a GRE tunnel created from the site to HQ

70 percent of the traffic is via physical interface (direct to internet) 

remaining 30 percent of the traffic is via tunnel (internal networks)

I wanted to prioritize traffic that flows via tunnel (eg voice, window auth traffic, file share, remote desktop etc)

should i just create one more service policy and apply on tunnel interface ?

What should be the tunnel bandwidth?

little confused between qos management between physical and tunnel interface

[hkkalra]

Hi, 

These has been alot of speculations about using QoS configuration on both the Physical and GRE interfaces. As per Cisco TAC they don't recommend using this kind of setup (telling from my own experience). There are a couple of options you can use in this case. Personally i prefer using qos pre-classify. As once the traffic going out of the physical interface is GRE encapsulated QoS process is not able to apply the qos classifications on the traffic. And thus we can modify our QoS that we apply on the physical interface to also have the classifications for the traffic going through the tunnel and then use "qos pre-classify" command under the tunnel interface. This would make sure that QoS classifications are applied on the traffic before it is GRE encapsulated. 

For more details please look into the following link:

http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-policing/10106-qos-tunnel.html

Regards,

HK

[ahmad82pkn]

I know i am replying to some old thread, but need to ask, even if i have prioritized Voice over Data , or allocated 50% for Voip lets say and 50% for data. but its all on outgoing direction.

Now when traffic enter remote Site office, how will QOS work there? when my carrier hand over traffic to my remote site router and it accepts the traffic, i think Prioritization will have no influence? am i correct?

if yes, then what can be achieved with QOS on GRE?

[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

For ingress QoS, what you ideally rely on is the "other side's" egress QoS, which works very, very well if you have p2p, either logical or physical.

If you have some kind of logical multipoint (i.e. possible multiple senders) ingress, then you would reply on the egress physical interface QoS to your device (often not available for ISP connections).

Lastly, you can try managing ingress flow transmission rates, for traffic types that have flow management, but selectively dropping packets and/or pacing return/outbound ACKs.

[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

For starters, if you share raw Internet with a tunnel, you cannot (well) manage ingress QoS.

For egress, you can manage QoS for both raw Internet and the tunnel.  You can also manage the tunnel traffic, at the physical interface or you can manage the tunnel traffic itself.  If you need to manage both, one method, as HK describes, you can use the pre-classify command (configured on the tunnel).  (NB: pre-classify creates a shadow copy of of the tunnel packet headers before they are encapsulated.  Unfortunately, this does exclude some advanced classification.)  You could also have a policy that marks the tunnel traffic, either before it gets to the tunnel or as it enters the tunnels, and just manage the physical interface using markings.