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.
http://go.microsoft.com/?linkid=9656621
