The other point that also worth bearing in mind is this one concerning command "mls qos", http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_50_se/command/reference/cli1.html#wp5046030 .
In essence, with 'mls qos' turned on, the default port trust state on all ports is untrusted. It is easy to forget this especially when you focus your attention to a single port on the switch under time limitation. mls qos ... ... Defaults QoS is disabled. There is no concept of trusted or untrusted ports because the packets are not modified (the CoS, DSCP, and IP precedence values in the packet are not changed). Traffic is switched in pass-through mode (packets are switched without any rewrites and classified as best effort without any policing). *When QoS is enabled with the mls qos global configuration command and all other QoS settings are set to their defaults, traffic is classified as best effort (the DSCP and CoS value is set to 0) without any policing. No policy maps are configured. The default port trust state on all ports is untrusted. The default ingress and egress queue settings are in effect.* Regards, --Somphol. On Mon, Aug 12, 2013 at 12:19 PM, Somphol Boonjing <somp...@gmail.com>wrote: > This might be worth revisiting. Forgive me if this is not entirely a > new insight. > > In short, be aware that as soon as the command "service-policy input XXX" > in entered into the configuration, the "mls qos trust cos/dscp" will be > removed. Likewise, if the command "mls qos trust cos/dscp" is re-entered, > the command "service-policy input XXX" will be automatically removed. > > > > http://www.cisco.com/en/US/products/hw/switches/ps5023/products_tech_note09186a0080883f9e.shtml > > - > > If any other QoS Classification methods, such as port based or VLAN > based, are configured on the port gi 1/0/3, those configurations are > removed when you apply the policy-map. For example, the port Gi 1/0/13 is > configured to trust CoS as shown here: > > interface GigabitEthernet1/0/13 > description **** Access Port **** > switchport access vlan 10 > switchport mode access > switchport voice vlan 100 > mls qos cos 3 > mls qos trust cos > spanning-tree portfast > > - > > When you apply the policy-map to the interface, it removes the *trust* > command. > > > Distribution1(config)#*int gi 1/0/13* > Distribution1(config-if)#*service-policy input sample-policy1* > Distribution1(config-if)#*do show run int gi 1/0/13* > Building configuration... > > Current configuration : 228 bytes > ! > interface GigabitEthernet1/0/13 > description **** Access Port **** > switchport access vlan 10 > switchport mode access > switchport voice vlan 100 > service-policy input sample-policy1 > *!--- It replaces the mls qos trust or mls qos > !--- vlan-based command.* > mls qos cos 3 > *!--- This command is not removed.* > spanning-tree portfast > end > > > > Regards, > --Somphol. > > > > > > > On Mon, Jul 8, 2013 at 12:42 PM, <jainpiyush2...@ymail.com> wrote: > >> Steve, you absolutely make sense that traffic for cue can be marked on >> router (site c) on which cue module is connected when it goes out on wan >> link.. and then on the trunk port on hq switch we would have trust >> statement. >> >> However the question in lab expect us to mark the cue traffic on hq >> switch on the port connected to sub cucm.. so the above solution won't >> work.. right? >> >> >> Thanks and regards, >> Piyush Jain >> >> Sent from my android device. >> >> >> >> -----Original Message----- >> From: sbar...@mystictraveler.net >> To: LorenzLGRC <lorenzl...@gmail.com>, Piyush Jain < >> jainpiyush2...@ymail.com> >> Cc: "ccie_voice@onlinestudylist.com" <ccie_voice@onlinestudylist.com> >> Sent: Mon, 08 Jul 2013 6:23 AM >> Subject: RE: [OSL | CCIE_Voice] Access list for cue traffic marking >> >> Maybe I am missing something so please forgive me, and to recap, the >> question was LAN QoS and CUE (not WAN). >> >> The example below (which is pretty much out of the SRND) will correctly >> mark the traffic, but only going out the serial port. It seems to me that >> you would want to mark the traffic inbound from the CUE module to the >> router in which it resides so that no matter how the traffic exits the >> router it will be handled correctly. Can you mark the traffic as it leaves >> the AIM module and is passed to the router? >> >> As far as the policy map on the serial port, wouldn't we want to see all >> traffic correctly prioritized not just the CTI-QBE to answer the question >> correctly if we were to look at the WAN QoS? >> >> I assume for traffic leaving on an LAN port to a switch, the switch would >> have the appropriate trust statements and since we marked on the packets as >> they transition from the AIM to the router prioritization and re-marking >> would not be an issue? >> >> Steve >> >> -------- Original Message -------- >> Subject: Re: [OSL | CCIE_Voice] Access list for cue traffic marking >> From: LorenzLGRC <lorenzl...@gmail.com> >> Date: Sun, July 07, 2013 5:25 am >> To: Piyush Jain <jainpiyush2...@ymail.com> >> Cc: "ccie_voice@onlinestudylist.com" <ccie_voice@onlinestudylist.com> >> >> Hello, >> you can use something like this: >> >> access-list 101 permit tcp host a.b.c.d any eq 2748 >> ! >> class-map match-all cti-qbe >> match access-group 101 >> ! >> policy-map cti-qbe >> class cti-qbe >> set dscp af31 >> bandwidth 20 >> ! >> interface Serial0/1 >> service-policy output cti-qbe >> >> >> >> >> On Sun, Jul 7, 2013 at 6:06 AM, Piyush Jain <jainpiyush2...@ymail.com>wrote: >> >>> Hi Guys, >>> >>> I am trying to understand how we can mark CUE traffic on HQ Switch to >>> implement LAN QOS. >>> >>> I have come up with the below solution. >>> >>> ip access-list extended name CUE >>> permit tcp host 142.100.64.12 host 142.1.66.253 eq 2748 >>> >>> >>> class-map match-any CUE-CLASS >>> match access group name CUE >>> >>> policy-map CUE-POLICY >>> class CUE-CLASS >>> set ip dhcp CS3 >>> >>> int fa 1/0/4 >>> description ***** CONNECTED TO SUB CUCM ******* >>> service policy input CUE-POLICY >>> >>> In above config, 142.100.64.12 is SUB CUCM, 142.1.66.253 is CUE on SC >>> router. >>> Explanation: Since we are applying service policy in incoming direction >>> on switch port connected to CUCM, so the source port number (of CUCM) can >>> be anything but destination port number (i.e for CUE) should be 2748 (JTAPI >>> port). >>> >>> Any advice or inputs are most welcome. >>> >>> Cheers !! >>> Piyush Jain >>> >>> >>> _______________________________________________ >>> For more information regarding industry leading CCIE Lab training, >>> please visit www.ipexpert.com >>> >>> Are you a CCNP or CCIE and looking for a job? Check out >>> www.PlatinumPlacement.com >>> >> >> ------------------------------ >> _______________________________________________ >> For more information regarding industry leading CCIE Lab training, please >> visit www.ipexpert.com >> >> Are you a CCNP or CCIE and looking for a job? Check out >> www.PlatinumPlacement.com >> >> >> _______________________________________________ >> For more information regarding industry leading CCIE Lab training, please >> visit www.ipexpert.com >> >> Are you a CCNP or CCIE and looking for a job? Check out >> www.PlatinumPlacement.com >> > >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
