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: <a href="http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a008017405e.shtml">http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a008017405e.shtml</a><br>
<br><span class="content"><h3><a name="qoscomm">The qos pre-classify command</a></h3>
<p>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 <a href="http://www.cisco.com/en/US/docs/ios/12_2t/12_2t2/feature/guide/ftqosvpn.html">Quality of Service for Virtual Private Networks</a> (VPNs) feature, packets can now be classified before tunneling and encryption occur.</p>
</span><span class="content"><h2><a name="whereapply">Where Do I Apply the Service Policy?</a></h2>
<p>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.</p>
<ul><li>
<p>Apply the policy to the tunnel interface without <b>qos-preclassify</b> when you want to classify packets based on the pre-tunnel header.</p>
</li><li>
<p>Apply the policy to the <i>physical</i> interface without <b>qos-preclassify</b>
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.</p>
</li><li>
<p>Apply the policy to a <i>physical</i> interface and enable <b>qos-preclassify</b> on a tunnel interface when you want to classify packets based on the pre-tunnel header.</p>
</li></ul></span><br><br><div class="gmail_quote">On Fri, Jun 5, 2009 at 1:51 PM, Pilkington, Christopher J. <span dir="ltr"><<a href="mailto:CPilkington@emblemhealth.com">CPilkington@emblemhealth.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">What's the purpose of permitting gre any any, if you are permitting ip<br>
any any, or am I missing something?<br>
<br>
We typically do:<br>
<br>
interface Tunnel0<br>
ip address w.x.y.z 255.255.255.252<br>
qos pre-classify<br>
tunnel source a.b.c.d<br>
tunnel destination e.f.g.h<br>
...<br>
<br>
qos pre-classify promotes the tunneled packet headers to the GRE<br>
wrapper. Then we can apply the service policy to the Serial...<br>
<br>
-Chris<br>
<div><div></div><div class="h5"><br>
-----Original Message-----<br>
From: <a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a><br>
[mailto:<a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a>] On Behalf Of Nick Griffin<br>
Sent: Friday, June 05, 2009 2:27 PM<br>
To: Eric Pedersen<br>
Cc: <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
Subject: Re: [cisco-voip] GRE tunnel with QoS<br>
<br>
I've done this with ipsec/gre tunnels, and verified the TOS values are<br>
kept intact on the GRE packet. You can always use an ACL on the remote<br>
location to match on your DSCP value when it comes in from the service<br>
provider cloud, the catch is at that point the traffic will be GRE, so<br>
you would do something like:<br>
<br>
ip access-list extended TEST<br>
permit grep any any dscp ef<br>
permit ip any any <---- Don't forget about the ip any any<br>
<br>
interface serx/y<br>
ip access-group TEST in<br>
<br>
if you are sending traffic out the cloud with DSCP value 46, they should<br>
arrive at the remote location with the DSCP value of 46 and that type<br>
acl entry should increment. If not they're stripping it, or your not<br>
sending it.<br>
<br>
Don't forget about TCP MSS and IP MTU.<br>
<br>
HTH,<br>
<br>
NIck Griffin<br>
<br>
<br>
<br>
On Fri, Jun 5, 2009 at 11:57 AM, Eric Pedersen <<a href="mailto:eric.pedersen@sait.ca">eric.pedersen@sait.ca</a>><br>
wrote:<br>
<br>
<br>
Thanks for the links Wes; I was unable to find information on<br>
what the default behaviour is. I like it when configuration tasks are<br>
"None".<br>
<br>
<br>
<br>
I have not tested it yet - I will be doing that next week.<br>
<br>
<br>
<br>
From: Wes Sisk [mailto:<a href="mailto:wsisk@cisco.com">wsisk@cisco.com</a>]<br>
Sent: June 4, 2009 21:09<br>
To: Eric Pedersen<br>
Cc: <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
Subject: Re: [cisco-voip] GRE tunnel with QoS<br>
<br>
<br>
<br>
I've not tested it but:<br>
<br>
<br>
<br>
<a href="http://www.cisco.com/en/US/docs/ios/11_3/feature/guide/greqos.html" target="_blank">http://www.cisco.com/en/US/docs/ios/11_3/feature/guide/greqos.html</a><br>
Configuration Tasks<br>
None; this feature occurs by default.<br>
<br>
<br>
<a href="http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a%0A008017405e.shtml" target="_blank">http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a<br>
008017405e.shtml</a><br>
<br>
Do you have indication that it is not working?<br>
<br>
/Wes<br>
<br>
On Thursday, June 04, 2009 8:54:37 PM, Eric Pedersen<br>
</div></div><div class="im"><<a href="mailto:eric.pedersen@sait.ca">eric.pedersen@sait.ca</a>> <mailto:<a href="mailto:eric.pedersen@sait.ca">eric.pedersen@sait.ca</a>> wrote:<br>
<br>
<br>
<br>
I want to set up a GRE tunnel to a remote site over our<br>
provider's MPLS VPN service. They classify our voice traffic based on<br>
dscp. Does someone have an example of how to set this up so that when<br>
packets are tunneled, their DSCP values are copied to the GRE packet<br>
headers?<br>
<br>
<br>
<br>
Thanks,<br>
<br>
Eric<br>
<br>
<br>
<br>
________________________________<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
</div>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.<br>
<br>
Go Paperless * Reduce Clutter * Save Trees<br>
</blockquote></div><br>