[c-nsp] incoming queue

P.A razor at meganet.net
Fri Aug 20 15:39:34 EDT 2010


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:peter at 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

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





More information about the cisco-nsp mailing list