[c-nsp] internal DSCP

[Tim Stevenson]

Hi Paul, please see inline below:

At 12:40 PM 8/12/2010, P.A averred:

>Tim thanks for your response, I think I'm starting to get it.
>
>So basically if you do ingress marking with an ACL by default it will not
>use that marking on egress unless you use an egress acl for remarked packets
>using 'platform ip features sequential'?

No. It *WILL* use that remarked value to rewrite the packet regardless.

The issue is, the fwding engine does certain things in parallel. In 
this case, there is no signalling in the ASIC of the remarked DSCP 
value to the logic that does egress ACL classification/enforcement 
(remember, the INGRESS fwd engine does both ingress & egress policy 
enforcement). So that match will be based on the original value.

However, the egress interface will always use the remarked DSCP/COS 
to enqueue the packet, and the packet will always be tx'd using that 
remarked value.

This knob is SPECIFIC only to the case where you want to remark on 
ingress AND match on the remarked value, not the original value, in 
an egress ACL.

It doesn't affect/change the egress q'ing behavior nor what is 
rewritten into the packet.



>What about for the following, would the set dscp value be used?
>
>class-map match-any voip_traffic
>   match protocol rtp audio
>
>Policy Map incoming_voip_policy
>   Class voip_traffic
>     trust dscp
>    police cir percent 20 conform-action set-dscp-transmit ef ....


This will work exactly as you expect. What would NOT work, without 
the knob, is if you then have an egress ACL on the egress L3 
interface that tries to match on the remarked DSCP value (eg, match 
on packets that were marked down by the policer).

Note that recirculation incurs a performance hit, it requires 2 
passes thru the fwding engine.

Hope that helps,
Tim



>thanks, Paul
>
>-----Original Message-----
>From: Tim Stevenson [<mailto:tstevens at cisco.com>mailto:tstevens at cisco.com]
>Sent: Thursday, August 12, 2010 2:34 PM
>To: P.A; cisco-nsp at puck.nether.net
>Subject: Re: [c-nsp] internal DSCP
>
>Hi PA,
>
>Not sure where your quotes are coming from. The 2nd one is a bit
>misleading IMO, it sort of mangles the concepts of PFC classification
>& egress port QoS.
>
>It refers to a specific behavior around matching remarked DSCP in an
>egress ACL. That is not possible w/o a recirculation.
>
>This section of the cfg guide should help:
><http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configu>http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configu
>ration/guide/qos.html#wp1766015
>
>The point is, if you remark DSCP on ingress, an egress ACL will not
>match on the remarked DSCP without first recirculating the packet.
>
>Regardless of that, the remarked DSCP (or derived COS) will
>definitely be used to map the packet to an egress port queue and that
>remarked DSCP will be carried in the final packet.
>
>Hope that helps,
>Tim
>
>
>
>At 08:41 AM 8/12/2010, P.A averred:
>
>
>
> >I have a questing about internal DSCP on a 6500 that I'm not really sure
> >about. I know that it's used to identify the priority of a  frame/packet as
> >it transits the switch but I have read on some sites that the internal DSCP
> >is copied to the frame/packet as it leaves the switch. On other sites that
> >when the packet arrives at the egress port the original ToS will be used.
>So
> >im confused to which is true, see below.
> >
> >
> >
> >"Upon output, the internal DSCP settings are copied to the IP header. If
>the
> >outbound frame is being given a trunking header (ISL or 802.1Q) then the
> >appropriate CoS bits are also set."
> >
> >
> >
> >"7.12 Egress ACL Support for Remarked DSCP
> >
> >When a frame transits the switch, classification performed by the PFC can
> >change the ToS priority setting (IP Precedence or DSCP) in the packet. When
> >the packet arrives at the egress port however, the default action will
> >result in the original ToS priority (not the PFC remarked ToS priority)
>that
> >was present on the arriving packet to be used for classification purposes."
> >
> >
> >
> >_______________________________________________
> >cisco-nsp mailing list  cisco-nsp at puck.nether.net
> ><<https://puck.nether.net/mailman/listinfo/cisco-nsp>https://puck.n 
> ether.net/mailman/listinfo/cisco-nsp>https://puck.nether.net
>/mailman/listinfo/cisco-nsp
> >archive at
> ><<http://puck.nether.net/pipermail/cisco-nsp/>http://puck.nether.ne 
> t/pipermail/cisco-nsp/>http://puck.nether.net/piperma
>il/cisco-nsp/
>
>
>
>
>Tim Stevenson, tstevens at cisco.com
>Routing & Switching CCIE #5561
>Distinguished Technical Marketing Engineer, Cisco Nexus 7000
>Cisco - <http://www.cisco.com>http://www.cisco.com
>IP Phone: 408-526-6759
>********************************************************
>The contents of this message may be *Cisco Confidential*
>and are intended for the specified recipients only.
>




Tim Stevenson, tstevens at cisco.com
Routing & Switching CCIE #5561
Distinguished Technical Marketing Engineer, Cisco Nexus 7000
Cisco - http://www.cisco.com
IP Phone: 408-526-6759
********************************************************
The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.