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> > > _________________________________________________________________ Faça já uma busa e ganhe um wink do Messenger. Está esperando o que? É grátis! http://www.ibud.com.br/
