7604 qos pre-classify on tunnel interface

[paul.harkins]

Hi,  I saw a post from back in 2011 that said the 7604 platform doesn't support qos pre-classify on tunnel interfaces,  Is this still the case or have things moved on??  I ask as ive IOS 15.3 and still cant see it so was looking for confirmation of someone that I need to find an alternative solution as I cant find it stated in any documentation.

Thanks

[Joseph W. Doherty]

Alas, I don't know the answer to your question, but as I've seen some engineers misunderstand pre-classify, I just wanted to confirm you do understand its purpose (which is providing a "shadow" copy of a tunnel's IP header before encapsulation for examination at the physical interface).

[paul.harkins]

Yep, that's what I want to achieve, so we can put the data into the correct CoS queues as it passes through the network.

[Joseph W. Doherty]

So you cannot analyze it, and DSCP mark it, at the tunnel interface?

[paul.harkins]

I can tag the traffic entering the tunnel interface, no issues, what I cant do is analyse it, without qos pre-classify, as it traverses the network, it all is seen as GRE traffic.

[Joseph W. Doherty]

Yea, I understand that, i.e. you're limited to looking at packet's ToS, once it's been encapsulated.

However, since the tunnel and pre-classify are on the same device, it's often a bit rare to need to analyze the encapsulated packet when it can be analyzed at the tunnel interface. Further, often you can do deeper analysis at the tunnel interface than you can against the "shadow" copy at the physical egress interface. The advantage of doing analysis at the physical egress interface, you only need to configure the policy at the physical interface rather than at numerous tunnel interfaces. Other than that, is there another reason the physical egress analysis is important? (I'm just curious.)

[paul.harkins]

The scenario I have is a isolated network, in its own vrf, that is tunnelled across a multinational WAN (core is AVPN). It breaks out again in an isolated network in its own vrf.
The traffic traverses a congested WAN link that is too expensive to upgrade.
The traffic inside the tunnel is made up of several types, some of which are critical. We tag these accordingly based on service type.
At the moment we are suffering loss of critical packets because of congestion on the congested link.
If we can queue according to the COS profile we have on the link we will preserve the critical traffic (GRE traffic sits in a default queue and we cant move it due to other concerns). The most elegant way of doing this is to use the qos pre-classify. I can do it another way but its not very clean as it involves tagging only the GRE traffic from the router that terminates the tunnel so gets messy.

[Joseph W. Doherty]

One part that's unclear, you're hoping to use pre-classify on traffic that's been encapsulated on another device?

Also a bit unclear, if traffic is being tagged for its service type before it's encapsulated, aren't those markings being copied to the encapsulated packet's ToS?

[paul.harkins]

Once a packet enters a GRE tunnel it becomes a GRE packet unless you use qos pre-classify, then the tagging it originally had is added to the IP header.

[Joseph W. Doherty]

Huh?

Unless, what you're trying to do is retag an encapsulated packet's ToS based on the shadow header. I.e. have the original packet's and encapsulated packet's ToS different. The would be another use for pre-classify.

Of course, you can retag an encapsulated packet any time, but not with visibility into the original packet's header.

[paul.harkins]

I think we've got a little away from my original question.... Does anyone have an answer to that??

[Joseph W. Doherty]

Perhaps we did, although your OP did mention finding an alternative solution, if needed. Just trying to get a jump on that.

If no one does post the information you hoping to obtain about using pre-classify on a 7600, post another question for an alternative solution.