Is this right? So you don't want:
[Phone1] -> DHCP(ef) -> [SWITCH1 (dscp-cos-map)] -> COS 5 -> [SWITCH2] -> COS5 -> [SWITCH3 (cos-dscp-map 5->46 )] -> DSCP(ef) -> [Phone2] You want DSCP end 2 end [Phone1] -> DHCP(ef) -> [SWITCH1] -> DSCP(ef) -> [SWITCH2] -> DSCP(ef) -> [SWITCH3] -> DSCP(ef) -> [Phone2] /Ralph 2011/2/23 Jason Boyers <[email protected]>: > SCCP will have both a source and destination TCP port of 2000 (please do > verify this!) If you do a sniffer capture, you will notice that RTP traffic > between CME and a phone (like when using a wave file on CME with B-ACD) uses > UDP port 2000 on the CME. The phone side will be in the standard UDP > 16384-32767 range. So, for RTP traffic, the ACL should likely have two > lines, one with a source port range of 16384-32767 and one with a > destination port range of 16384-32767. > > When looking at QoS configurations for switchports, there are several things > to keep in mind. I'll address two here. First, when you configure "mls > qos," that automatically enables SRR or WRR on the ports with the default > percentages and thresholds. Additional configurations of SRR or WRR would > be used to change the defaults. > > For the individual interface trust configurations, remember that if the port > is an access port, there will not be any CoS markings in the frame to > trust. On a trunk port, you would generally trust CoS (if you need to trust > anything.) However, as mentioned, you normally want to trust DSCP on trunks > between switches. The reason is that the frames have already had their > CoS-DSCP mappings on ingress to the switch. Thus, they have an appropriate > DSCP marking that you have already determined. Let's say that you are > trusting an end device's DSCP markings. And, let's say that they send a > packet with DSCP AF31. On egress (with the default map,) that will be > mapped to CoS 3. On ingress, if you trust CoS, that will be remarked to > DSCP CS3. Thus, your trust of the end device marking is negated by trusting > CoS on the trunk. > > Jason Boyers - CCIE #26024 (Wireless) > Technical Instructor - IPexpert, Inc. > Mailto: [email protected] > > > On Wed, Feb 23, 2011 at 8:37 AM, Phil Priest <[email protected]> wrote: >> >> Hi, >> >> >> >> Looking into in further SCCP traffic would either have a source port of >> 2000 or a destination port of 2000 depending on the direction of the flow. >> So I am thinking this below is correct. Would be good to get some >> clarification on this as well as the other voice control ports… >> >> >> >> Phil >> >> >> >> >> >> ip access-list extended ACL-SCCP >> permit tcp any any eq 2000 >> permit tco any eq 2000 any >> >> >> >> >> >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Stalder >> Dominic >> Sent: 23 February 2011 12:09 >> To: Leigh Jewell >> >> Cc: [email protected] >> Subject: Re: [CCIE Wireless] "Exam Best Practices" - Port Configurations >> >> >> >> Hei Leigh >> >> Thanks for the detailed answers. >> >> > 1. Switches: I would configure 'mls qos trust dscp'. My thinking is here >> > we 'mls qos trust cos' on trunks connected to WLC's. >> >> I thought than on trunk ports from switch to switch it would be good to >> trust CoS? But I will check the link you send later on. >> >> > 2. WAN/Internet: You ACL for matching SCCP may not be correct. You are >> > matching on src/dst of port 2000. From my information only the destination >> > is 2000 and as such you ACL would need to look more like: >> >> I always used the ACL like you said: >> >> ip access-list extended ACL-SCCP >> permit tcp any any eq 2000 >> permit tco any eq 2000 any >> >> But then I saw, that Jasons DSG Lab 2 has configured SRC 2000 <-> DST >> 2000. I will internaly check this with our Voice guys. >> >> > I have a blog <http://leigh-cciewireless.blogspot.com/> I am using as a >> > study aid. Would you be ok if I add in the best practise example configs >> > you >> > have built ? I think they will be a great reference and something to come >> > back to at a later point to refresh. >> >> The mail has no copyright, so just add it, no problem ;-) >> >> Best regards >> Dominic >> >> ________________________________ >> >> Von: Leigh Jewell <[email protected]> >> Datum: Wed, 23 Feb 2011 22:59:45 +1100 >> An: Dominic Stalder <[email protected]> >> Cc: "[email protected]" >> <[email protected]> >> Betreff: Re: [CCIE Wireless] "Exam Best Practices" - Port Configurations >> >> This is exactly what I have been working on as well. Here are my thoughts: >> >> 1. Switches: I would configure 'mls qos trust dscp'. My thinking is here >> we 'mls qos trust cos' on trunks connected to WLC's. The switch maps the cos >> to a dscp and at that point through the network we trust dscp. This is >> according to the QoS SRND >> <http://www.cisco.com/univercd/cc/td/doc/solution/esm/qossrnd.pdf> . >> >> 2. WAN/Internet: You ACL for matching SCCP may not be correct. You are >> matching on src/dst of port 2000. From my information only the destination >> is 2000 and as such you ACL would need to look more like: >> >> ip access-list extended ACL-SCCP >> permit tcp any any eq 2000 >> permit tco any eq 2000 any >> >> 3. CME - if the CME is marking the packets correctly I would put on the >> switch port 'mls qos trust dscp' this will ensure the packets are not >> written down to zero. >> >> 3. WiSM - you can't access the port-channels so you can't configure >> 'spanning-tree portfast' >> >> 4. WLC (LAG) - the command should be 'mls qos trust cos'. >> >> 5. WLC (non-LAG): referring to the WLC best practise guide >> <http://www.cisco.com/en/US/tech/tk722/tk809/technologies_tech_note09186a0080810880.shtml> >> , STP is not recommended to be enabled. >> >> 6. WLC Service Port: The service port can't mark traffic. If you want to >> mark it you will need to do a service input policy. I can't see a need to >> mark it. >> >> 7. LAP (local) & LAP (HREAP): both of these look good; >> >> 8. Auton AP or IOS AP: The BVI interface on an AP is the management >> interface and is always the native VLAN (untagged). From the AP perspective, >> the untagged VLAN is VLAN 1. >> >> 9. Wired IP Phone: This one I have been struggling with. The fact they >> would say not to use AutoQoS to me would suggest that they want SRR (for >> 3560) or WRR (6500). Don't forget the hardware list means the phone could be >> either on a 3560/2960 or 6500. Then there are the different modules in the >> 6500 which have different queues and as such different QoS configurations. I >> need to work on this one some more. >> >> 10. Portfast & BPDU guard: If they use the wording something like 'fast >> and secure' - fast would imply port-fast while secure would be the bpdu >> guard feature. >> >> 11. Priority Queue out: any port that would carry voice traffic would be >> good to put this on. Even if you did it for other ports that didn't carry >> voice it would have no determental affect I can think of. >> >> I have a blog <http://leigh-cciewireless.blogspot.com/> I am using as a >> study aid. Would you be ok if I add in the best practise example configs you >> have built ? I think they will be a great reference and something to come >> back to at a later point to refresh. >> >> Cheers, >> Leigh >> >> >> On 20 February 2011 02:13, Stalder Dominic <[email protected]> >> wrote: >> >> Hi there >> >> I have been once at the lab exam and I think, there are tasks in the >> infrastructure section, that will be the same in EVERY lab exam, so I >> thought that we can start here some “exam best practices” conversations, so >> we can get these points for sure ;-) If someone is interested, just take >> part and help others to pass the exam. I would like to start with default >> port configurations: >> >> - Trunking vs. Access >> - Spanning Tree portfast and bpduguard >> - QoS >> - etc. >> >> I know there can be variations in the questions, but as a general >> guideline and as a discussion base. But anyway, these are my proposals (some >> of the information I took out of the DSG from Jason!) for the different port >> types (by the way, sorry for the strange format, but I copied this out of my >> Wiki post, I hope you can read anyway): >> >> >> --- Switches --- >> >> <configuration start> >> port-channel load-balance src-dst-ip >> ! >> mls qos >> mls qos map cos-dscp 0 8 16 24 32 46 48 54 >> mls qos map dscp-cos 46 to 5 >> mls qos map dscp-cos 24 to 3 >> ! >> interface fastethernet x/x >> switchport trunk encapsulation dot1q >> switchport mode trunk >> switchport trunk native vlan x (if specified by the question) >> switchport trunk allowed vlan x,y,z >> priority-queue out >> mls qos trust cos >> ! >> <configuration end> >> >> >> >> --- WAN / Internet --- >> >> <configuration start> >> ip access-list extended ACL-RTP >> permit udp any range 16384 32767 any range 16384 32767 >> ! >> ip access-list extended ACL-SCCP >> permit tcp any eq 2000 any eq 2000 >> permit tcp any eq 2002 any eq 2002 >> ! >> class-map MAP-RTP >> match access-group name ACL-RTP >> ! >> class-map MAP-SCCP >> match access-group name ACL-SCCP >> ! >> policy-map POLICY-VOICE >> class MAP-RTP >> set dscp ef >> class MAP-SCCP >> set dscp cs3 >> ! >> interface fastethernet x/x >> no switchport >> ip address x.x.x.x y.y.y.y >> service-policy POLICY-VOICE in >> priority-queue out >> ! >> <configuration end> >> >> >> >> --- CME --- >> *If the question says, the CME already tags the packets with the right QoS >> marking, what do we have to configure on the port concerning QoS? >> >> <configuration start> >> interface fastethernet x/x >> switchport mode access >> switchport access vlan x >> spanning-tree portfast >> spanning-tree bpduguard enable >> priority-queue out >> <configuration end> >> >> >> >> --- WiSM --- >> *For the WiSM I would use the '''wism''' commands, but is it possible / >> necessary to add the '''spanning-tree portfast trunk''' or '''spanning-tree >> bpduguard''' commands (actually I don't have access to a 650x with WiSM >> module)? >> >> <configuration start> >> wism service-vlan z >> ! >> wism module x controller 1 native-vlan x (if management is not tagged) >> wism module x controller 1 allowed-vlan y,z >> wism module x controller 1 qos-trust cos >> ! >> wism module x controller 2 native-vlan x (if management is not tagged) >> wism module x controller 2 allowed-vlan y,z >> wism module x controller 2 qos-trust cos >> <configuration end> >> >> >> >> --- WLC (LAG) --- >> >> <configuration start> >> interface fastethernet x/x >> channel-group 1 mode on >> ! >> interface port-channel 1 >> switchport trunk encapsulation dot1q >> switchport mode trunk >> switchport trunk native vlan x (if specified by the question) >> switchport trunk allowed vlan x,y,z >> spanning-tree portfast trunk >> spanning-tree bpduguard enable >> priority-queue out >> mls qos cos >> ! >> <configuration end> >> >> >> >> --- WLC (Connected to different switches, for example 4402 with 2 ports >> connected to both core switches) --- >> *I do not add '''spanning-tree bpduguard enable''' because I assume that >> on the WLC the STP is enabled >> *General question, I think it is necessary to enable the STP on WLCs that >> are connected to different switches, isn't it? >> >> <configuration start> >> interface fastethernet x/x >> switchport trunk encapsulation dot1q >> switchport mode trunk >> switchport trunk native vlan x (if specified by the question) >> switchport trunk allowed vlan x,y,z >> priority-queue out >> mls qos cos >> ! >> <configuration end> >> >> >> >> --- WLC (Service Port) --- >> *Are here any QoS commands needed, and if so, what will be trusted? >> >> <configuration start> >> interface fastethernet x/x >> switchport mode access >> switchport access vlan x >> spanning-tree portfast >> spanning-tree bpduguard enable >> ! >> <configuration end> >> >> >> >> --- LAP (Local) --- >> >> <configuration start> >> interface fastethernet x/x >> switchport mode access >> switchport access vlan x (always needed for management interface) >> spanning-tree portfast >> spanning-tree bpduguard enable >> priority-queue out >> mls qos trust dscp >> ! >> <configuration end> >> >> >> >> --- LAP (H-REAP) --- >> >> <configuration start> >> interface fastethernet x/x >> switchport trunk encapsulation dot1q >> switchport mode trunk >> switchport trunk native vlan x (always needed for management interface) >> switchport trunk allowed vlan x,y,z >> priority-queue out >> mls qos cos >> ! >> <configuration end> >> >> >> >> --- AAP (Multiple VLANs) --- >> *The management interface does not always have to be the native VLAN, does >> it? >> >> <configuration start> >> interface fastethernet x/x >> switchport trunk encapsulation dot1q >> switchport mode trunk >> switchport trunk native vlan x (if specified by the question) >> switchport trunk allowed vlan x,y,z >> spanning-tree portfast trunk >> spanning-tree bpduguard enable >> priority-queue out >> mls qos cos >> ! >> <configuration end> >> >> >> >> --- AAP (Single VLAN, for example if used for a WGB bridge and only one >> VLAN is transported) --- >> >> <configuration start> >> interface fastethernet x/x >> switchport mode access >> switchport access vlan x >> spanning-tree portfast >> spanning-tree bpduguard enable >> priority-queue out >> mls qos dscp >> ! >> <configuration end> >> >> >> >> --- Wired IP Phone--- >> *The questions says, you have to configure a port for future use of an >> wired IP phone? >> *You must not use Auto-QoS, this would give us something like this: >> >> <configuration start> >> interface fastethernet x/x >> srr-queue bandwidth share 10 10 60 20 >> priority-queue out >> mls qos trust device cisco-phone >> mls qos trust cos >> auto qos voip cisco-phone >> service-policy input AutoQoS-Police-CiscoPhone >> <configuration end> >> >> *I don' think, that srr-queue and service-policy configuration is expected >> in the CCIE Wireless track for a wired IP phone port (what do people say, >> that already passed?) >> *So I think this configuration could give the points we want (I add >> '''spanning-tree bpduguard enable''' because the IP phone will not send any >> BPDUs): >> >> <configuration start> >> interface fastethernet x/x >> switchport mode access >> switchport access vlan x >> switchport voice vlan y >> spanning-tree portfast >> spanning-tree bpduguard enable >> priority-queue out >> mls qos trust device cisco-phone >> mls qos trust cos >> ! >> <configuration end> >> >> >> >> And here are some general questions, I would like to know more about: >> *Would it be OK to add ''priority-queue out'' on every port? >> *On which ports would you use '''spanning-tree portfast''' and >> '''spanning-tree bpduguard enable'''? >> >> So I hope this can be used as a discussion base and I hope I get some >> interesting reactions on this ;-) Please feel free to criticize it. >> >> Regards >> Dominic >> >> _______________________________________________ >> For more information regarding industry leading CCIE Lab training, please >> visit www.ipexpert.com <http://www.ipexpert.com/> >> >> >> >> _______________________________________________ >> For more information regarding industry leading CCIE Lab training, please >> visit www.ipexpert.com >> > > > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > > _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
