If you are using COS-Q mapping, the frame *must*
carry COS to be prioritized on ingress. If using
DSCP-Q (available on certain 10G modules) then we
can prioritize on the ingress port based on DSCP,
which of course would always be carried in an IP packet.
An input service-policy is applied in the PFC/DFC
- ie, 'long after' the packet was ingress queued.
Clearly ingress/egress service policies, trust
statements, etc affect how egress queueing is
handled and what's carried in the final packet.
In the vast majority of cases, input queuing just
isn't that useful as queueing only happens when
there's congestion - and congestion is more
likely by far on egress where you can have n-to-1 traffic patterns.
Tim
At 12:39 PM 8/20/2010, P.A contended:
Yeah I have the same config, but donât think
that incoming packets will be mapped to the
priority queue. I think all the config below is
going to do is set the internal dscp with the
policy to be used on the outgoing queue. From
what I understand from the link below all
incoming packets 1st are assigned to an incoming
queue before anything else. So unless the packet
already has a COS marking it will not use the priority queue.
-----Original Message-----
From: Peter Rathlev [<mailto:pe...@rathlev.dk>mailto:pe...@rathlev.dk]
Sent: Friday, August 20, 2010 2:47 PM
To: P.A
Cc: cisco-nsp
Subject: Re: [c-nsp] incoming queue
Hi Paul,
(I've Cc'ed the list again since other people's eyes can spot errors I
might have made.)
On Fri, 2010-08-20 at 12:51 -0400, P.A wrote:
> Actually Peter, I have come to determine that even now with the
> correct cos 5 mapped to the incoming priority queue, unless itâs a
> trunk it will not pass any packets to that queue.
>
> See,
>
<http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/qos.html#wp1740736>http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/qos.html#wp1740736
A service policy is applied outside of this diagram (afterwards). Take a
look at figure 41-6 on the same page (anchor wp1744018 on same URL). As
far as I know a service-policy will always override port trust (and
CoS/DSCP mappings).
And I see there's even a very simple way to trust DSCP via a policy-map.
I tested this configuration successfully:
! *** Router ***
policy-map Trust-DSCP-pmap
class class-default
trust dscp
exit
!
exit
!
interface GigabitEthernet1/1
description Towards test host
switchport
switchport access vlan 3
switchport mode access
mtu 9216
load-interval 30
mls qos trust cos
spanning-tree portfast edge
service-policy input Trust-DSCP-pmap
exit
!
And it works fine, everything comes through with correct DSCP/ToS.
Removing the service-policy makes everything CoS 0 / DSCP 0; trust DSCP
always lets things through. (Verified with "ping -Q <tos> ..." and a
tcpdump on the other end.)
Thus you can "trust DSCP" on an access port and still be able to
configure a priority-queue on input (i.e. have "mls qos trus cos" on the
interface).
This test was on a PFC3B, module is a WS-X6748-GE-TX without DFC and the
system is running SXI/AIS. The WS-X6748-GE-TX doesn't have a
priority-queue on input (it's 1q8t) so I couldn't test that part, but I
can see no reason why it wouldn't work exactly the same way on other
modules and other software. I tested it on a WS-X6516-GBIC (1p1q4t) and
SXF/AES, but I don't have a host on that box to verify with. It didn't
complain about the configuration though.)
P.S.: If you want to trust only some DSCP values (or for some other
reason want to keep the class-map model) you can bundle DSCP values:
class-map match-any Trust-DSCP-cmap
match ip dscp 0 1 2 3 4 5 6 7
match ip dscp 8 9 10 11 12 13 14 15
match ip dscp 46 63
exit
!
policy-map Trust-DSCP-pmap
class Trust-DSCP-cmap
trust dscp
exit
!
class class-default
set ip dscp 0
exit
!
!
interface GigabitEthernet1/1
[...]
service-policy input Trust-DSCP-pmap
exit
!
This trusts only DSCP 0-15, 46 and 63.
--
Peter
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
<https://puck.nether.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.net/pipermail/cisco-nsp/
Tim Stevenson, tstev...@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.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
