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:[email protected]] 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 _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
