[cisco-voip] GRE tunnel with QoS

Nick Griffin nick.jon.griffin at gmail.com
Fri Jun 5 16:41:31 EDT 2009


The reason is to verify you are getting gre packets coming in with a DSCP
value of 46, thats it. Just a verification that you'll remove later. Also, I
don't think the qos pre-classify you mentioned is 100% accurate. QoS
pre-classify just affects the order of operations and classification. I kind
of think the pre-classify command as a way for the router to look back in
time at the pre-tunneled header and act/classify accordingly. From this doc:
http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a008017405e.shtml

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<http://www.cisco.com/en/US/docs/ios/12_2t/12_2t2/feature/guide/ftqosvpn.html>(VPNs)
feature, packets can now be classified before tunneling and
encryption occur.
Where Do I Apply the Service Policy?

You can apply a service policy to either the tunnel interface or to the
underlying physical interface. The decision of where to apply the policy
depends on the QoS objectives. It also depends on which header you need to
use for classification.

   -

   Apply the policy to the tunnel interface without *qos-preclassify* when
   you want to classify packets based on the pre-tunnel header.
   -

   Apply the policy to the *physical* interface without
*qos-preclassify*when you want to classify packets based on the
post-tunnel header. In
   addition, apply the policy to the physical interface when you want to shape
   or police all traffic belonging to a tunnel, and the physical interface
   supports several tunnels.
   -

   Apply the policy to a *physical* interface and enable
*qos-preclassify*on a tunnel interface when you want to classify
packets based on the
   pre-tunnel header.



On Fri, Jun 5, 2009 at 1:51 PM, Pilkington, Christopher J. <
CPilkington at emblemhealth.com> wrote:

> What's the purpose of permitting gre any any, if you are permitting ip
> any any, or am I missing something?
>
> We typically do:
>
> interface Tunnel0
>  ip address w.x.y.z 255.255.255.252
>  qos pre-classify
>  tunnel source a.b.c.d
>  tunnel destination e.f.g.h
>  ...
>
> qos pre-classify promotes the tunneled packet headers to the GRE
> wrapper.  Then we can apply the service policy to the Serial...
>
> -Chris
>
> -----Original Message-----
> From: cisco-voip-bounces at puck.nether.net
> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Nick Griffin
> Sent: Friday, June 05, 2009 2:27 PM
> To: Eric Pedersen
> Cc: cisco-voip at puck.nether.net
> Subject: Re: [cisco-voip] GRE tunnel with QoS
>
> I've done this with ipsec/gre tunnels, and verified the TOS values are
> kept intact on the GRE packet. You can always use an ACL on the remote
> location to match on your DSCP value when it comes in from the service
> provider cloud, the catch is at that point the traffic will be GRE, so
> you would do something like:
>
> ip access-list extended TEST
> permit grep any any dscp ef
> permit ip any any <---- Don't forget about the ip any any
>
> interface serx/y
> ip access-group TEST in
>
> if you are sending traffic out the cloud with DSCP value 46, they should
> arrive at the remote location with the DSCP value of 46 and that type
> acl entry should increment. If not they're stripping it, or your not
> sending it.
>
> Don't forget about TCP MSS and IP MTU.
>
> HTH,
>
> NIck Griffin
>
>
>
> On Fri, Jun 5, 2009 at 11:57 AM, Eric Pedersen <eric.pedersen at sait.ca>
> wrote:
>
>
>        Thanks for the links Wes; I was unable to find information on
> what the default behaviour is.  I like it when configuration tasks are
> "None".
>
>
>
>        I have not tested it yet - I will be doing that next week.
>
>
>
>        From: Wes Sisk [mailto:wsisk at cisco.com]
>        Sent: June 4, 2009 21:09
>        To: Eric Pedersen
>        Cc: cisco-voip at puck.nether.net
>        Subject: Re: [cisco-voip] GRE tunnel with QoS
>
>
>
>        I've not tested it but:
>
>
>
> http://www.cisco.com/en/US/docs/ios/11_3/feature/guide/greqos.html
>        Configuration Tasks
>         None; this feature occurs by default.
>
>
> http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a
> 008017405e.shtml<http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a%0A008017405e.shtml>
>
>        Do you have indication that it is not working?
>
>        /Wes
>
>        On Thursday, June 04, 2009 8:54:37 PM, Eric Pedersen
> <eric.pedersen at sait.ca> <mailto:eric.pedersen at sait.ca>  wrote:
>
>
>
>        I want to set up a GRE tunnel to a remote site over our
> provider's MPLS VPN service.  They classify our voice traffic based on
> dscp. Does someone have an example of how to set this up so that when
> packets are tunneled, their DSCP values are copied to the GRE packet
> headers?
>
>
>
>        Thanks,
>
>        Eric
>
>
>
> ________________________________
>
>
>
>
>        _______________________________________________
>        cisco-voip mailing list
>        cisco-voip at puck.nether.net
>        https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
>
>
>        _______________________________________________
>        cisco-voip mailing list
>        cisco-voip at puck.nether.net
>        https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
>
>
>
> Confidentiality Note: This electronic message transmission is intended only
> for the person or entity to which it is addressed and may contain
> information that is privileged, confidential or otherwise protected from
> disclosure. If you have received this transmission, but are not the intended
> recipient, you are hereby notified that any disclosure, copying,
> distribution or use of the contents of this information is strictly
> prohibited. If you have received this e-mail in error, please contact  me at
> 315/438-8474 and delete and destroy the original message and all copies.
>
> Go Paperless * Reduce Clutter * Save Trees
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20090605/dd86be6a/attachment.html>


More information about the cisco-voip mailing list