I think Chris's solution for the marking is a fantastic one. To address Cliff's concern regarding other traffic between the specified IP addresses also being marked as CS3, it should be possible to customize Chris's access-list in a way similar to Sergio's suggestion.
Now if we may look at two options for the complete QoS configuration. Option 1: a. Use access-lists or NBAR to classify signaling traffic for marking purposes. Create a marking policy-map. Associate the policy-map to appropriate router interfaces in the inbound direction. Do this on the three routers at the three sites. b. Use 'ip qos dscp cs3 signaling', 'mgcp ip qos dscp cs3 signaling' and Chris's route-map to mark the various signaling traffic generated on the routers themselves. We need the route-map related configurations on BR2 and HQ routers. c. Configure LLQ and FRTS as per the provided questions. Note that we create a class-map for signaling traffic separate from the one we created for marking. Option 2: a. Configure LLQ and FRTS as per the provided questions with minor modifications. The modifications will be to use NBAR for matching traffic under the signaling class-map and to 'set ip dscp cs3' under the signaling class of the LLQ policy-map as indicated in more detail in my original posting below. It is like hitting two birds with a single stone. b. Create a policy-map to mark signaling traffic to CS3 using the signaling class-map created in (a) and apply it in the outbound direction to the HQ router interface where servers are connected. c.(optional) Use 'ip qos dscp cs3 signaling' and 'mgcp ip qos dscp cs3 signaling' as necessary. In option 2, all signaling will be marked to CS3 before leaving the router even without step c. Assuming a similar question is on the real exam, I don't know if the proctors could sometimes be expecting to see specific commands evenif the requested task could be completed without those commands. I think both options do the job. However, time is of the essence during the lab exam and I think the second option takes a lot less time than the first one. While I appreciate Chris's solution for the RAS traffic marking dilemma and it might be something to consider for production systems, I wonder if there could be any reason not to go with option 2 for the lab exam. Thanks, Ameha From: [email protected] To: [email protected]; [email protected]; [email protected] CC: [email protected] Subject: Re: [OSL | CCIE_Voice] QoS - H323 RAS signal marking Date: Tue, 14 Apr 2009 18:28:17 -0400 Interesting. That actually makes it much easier! ----- Original Message ----- From: Sergio Polizer To: [email protected] ; [email protected] ; [email protected] Cc: [email protected] Sent: Tuesday, April 14, 2009 6:13 PM Subject: RE: [OSL | CCIE_Voice] QoS - H323 RAS signal marking By default, locally-generated packets are not inspected by outgoing access-lists. AFAIK, The local policy routing is the way for mark GK pkts. E.g.: ip access-list extended acl-mark-gk permit udp any range 1718 1720 any permit ip any any ! route-map LOCAL_TRAFFIC match ip address acl-mark-gk set ip precedence flash ip local policy route-map LOCAL_TRAFFIC > From: [email protected] > To: [email protected]; [email protected] > Date: Tue, 14 Apr 2009 16:48:16 -0400 > CC: [email protected] > Subject: Re: [OSL | CCIE_Voice] QoS - H323 RAS signal marking > > That won't work > > 1. any voice media streams that are terminated on the Gatekeeper would end > up being set to IP Precedence 3 instead of to EF > > 2. the requirement is to set the signaling to CS3 > > I actually thought about this and came up with an out of the box solution. > Instead of picking up the traffic and marking it on the inbound interface > IAW best practice, simply classify and mark on the interfaces outbound from > the router. > > Still want to hear Vik and Mark's thoughts though..... They are very quiet > lately.... > > Cliff > > ----- Original Message ----- > From: "Chris Parker" <[email protected]> > To: "Ameha Negash Haile" <[email protected]> > Cc: <[email protected]> > Sent: Tuesday, April 14, 2009 11:16 AM > Subject: Re: [OSL | CCIE_Voice] QoS - H323 RAS signal marking > > > I found one interesting solution to this: > > access-list 101 permit ip host <GK IP> host <CME IP> > access-list 101 permit ip host <GK IP> host <CCM PUB IP> > access-list 101 permit ip host <GK IP> host <CCM SUB IP> > ! > route-map ras permit 10 > match ip address 101 > set ip precedence 3 > set ip tos 0 > ! > ip local policy route-map ras > > Chris > > > Ameha Negash Haile wrote: > > > > Hello, > > > > > > > > First of all, thanks for the lots of great stuff on this list. I have > > been reading the various postings for very long. Now I have got some > > thought and I like to get your opinions on it. > > > > > > > > The question reads as “Mark SCCP, MGCP, H323 and SIP signaling traffic > > to CS3. Configure only on routers and CallManager.” > > > > > > > > The configuration on CallManager is straight forward. Regarding the > > configuration on routers, the solutions I have seen use access lists > > to capture interesting traffic (including h323 ras traffic at UDP port > > 1719), create policy-map to mark the traffic to CS3, and apply service > > policy in the inbound direction of voice VLAN interfaces on the > > various routers. > > > > > > > > As the above doesn't take into account traffic generated from the > > routers themselves, commands like 'ip qos dscp cs3 signaling' under > > VoIP dial-peers and 'mgcp ip qos dscp cs3 signaling' on MGCP gateways > > are also used. I haven't seen any similar command for H323 RAS traffic > > generated from BR2 router and destined to the Gatekeeper on the HQ > > router as well as H323 RAS traffic generated from the gatekeeper > > (destined to the BR2 router or the CallManager gatekeeper controlled > > intercluster trunk). > > > > > > > > To provide a comprehensive solution that includes H323 RAS signaling > > traffic, what I think needs to be done is, combine the marking and > > queuing in the policy-map that is applied on the serial WAN interface > > in the outbound direction. While this takes care of the H323 RAS > > traffic between BR2 router (H323 gateway) and HQ router (H323 > > gatekeeper), to take care of the H323 RAS traffic from the gatekeeper > > to CallManager, we need to create a policy-map for marking and apply > > it on the server vlan interface in the outbound direction. > > > > > > > > A sample configuration for the portion from HQ to BR2 will be like: > > > > > > > > ! > > > > Class-map match-any Voice > > > > match ip dscp ef > > > > class-map match-any Signal > > > > match protocol h323 > > > > match protocol skinny > > > > match protocol mgcp > > > > match protocol sip > > > > ! > > > > ! Here we have accounted for all signaling traffic specified > > > > ! in the question. If we want, we may add 'match ip dscp > > > > ! cs3' and 'match ip dscp af31' before the ‘match protocol’ commands. > > > > ! The 'match protocol' commands will be used to capture leftovers. > > > > ! > > > > policy-map LLQ-Mark-HQ-BR2 > > > > class Voice > > priority 96 > > compress header ip rtp > > class Signal > > bandwidth 40 > > > > set ip dscp cs3 ! We do the marking here. > > class class-default > > fair-queue > > > > ! > > > > policy-map MQC-768 > > > > class class-default > > > > shape average 729600 7296 0 > > > > service-policy LLQ-Mark-HQ-BR2 > > > > ! > > > > map-class frame-relay FRTS-768 > > > > service-policy output MQC-768 > > > > frame-relay fragment 960 > > > > ! > > > > interface Serial0/1.10 point-to-point > > > > bandwidth 768 > > > > ip address 10.10.10.3 255.255.255.0 > > > > frame-relay interface-dlci 310 > > > > class FRTS-768 > > > > ! > > > > > > > > By doing this, I believe we make sure all signaling traffic from HQ to > > BR2 will be marked to CS3 before leaving the HQ router. We do the same > > on the BR2 router also for traffic going to HQ. > > > > > > > > In my opinion, if we don't do the above, in addition to > > not properly marking H323 RAS traffic to CS3, we also miss H323 RAS > > traffic from the class-map Signal and the LLQ bandwidth guarantee > > won’t apply to it. I say this because what I have seen was that H323 > > RAS traffic is by default marked as 'DSCP 0', not even AF31. If this > > is the case, during congestion, RAS packets can be dropped big time!! > > > > > > > > I will appreciate your ideas on this. > > > > > > > > Thanks, > > > > Ameha Haile > > > > > > > > P.S. By the way, I find using 'match protocol' commands in class-map > > easier than using access groups and access lists. I don't have to > > worry about source ports and destination ports although knowing them > > is good. Could there be any other reasons, which I might be missing, > > to use one method over another for matching traffic? > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > Create a cool, new character for your Windows Live™ Messenger. Check > > it out <http://go.microsoft.com/?linkid=9656621> > > Descubra quais produtos Windows Live tem mais a ver com você! Faça o teste! _________________________________________________________________ Internet Explorer 8 helps keep your personal info safe. http://go.microsoft.com/?linkid=9655581
