The voip dial-peer marking will only affect CME to CUE traffic (inbound) and
not CUE to CME traffic (outbound); since the best solution is to mark the
outbound and not the inbound traffic, the service-engine module interface is
the closest place to mark the traffic as it enters the CME.
The other place is the WAN interface but that is only if the traffic exits
the CME router. So I will still mark it on the service-engine module
interface.
I meant to say, 'outbound' in the first email.
Tech Guy
----- Original Message -----
From: "Cliff McGlamry" <[email protected]>
To: "Tech Guy" <[email protected]>; "Mark Snow" <[email protected]>; "Chris
Parker" <[email protected]>
Cc: <[email protected]>
Sent: Tuesday, April 14, 2009 11:23 PM
Subject: Re: [OSL | CCIE_Voice] QoS - H323 RAS signal marking
I don't think so. It connects via a dial peer.
You can define the dscp values for both media and signalling within the
dial
peer. So it isn't needed.
----- Original Message -----
From: "Tech Guy" <[email protected]>
To: "Mark Snow" <[email protected]>; "Chris Parker" <[email protected]>
Cc: <[email protected]>
Sent: Tuesday, April 14, 2009 10:27 PM
Subject: Re: [OSL | CCIE_Voice] QoS - H323 RAS signal marking
Since the SIP traffic from the CUE is also 0 by default; I think it is
also
proper to apply the service-policy inbound on the Service-Engine module;
alternatively one can skip this and the traffic will be marked if it
exists
any of the interfaces outbound; but it will not hurt to mark it at the
Service-Engine interface.
In summary, it appears that the concensore is that:
1. Use policy-map/service policy outbound for all remotely generated
traffic.
2. Use ip local policy route-map for all locally generated traffic.
Is that about right?
Tech Guy
----- Original Message -----
From: "Mark Snow" <[email protected]>
To: "Chris Parker" <[email protected]>
Cc: <[email protected]>
Sent: Tuesday, April 14, 2009 9:14 PM
Subject: Re: [OSL | CCIE_Voice] QoS - H323 RAS signal marking
You guys have it - a local policy route to match traffic generated BY
the router (not a policy route on an egress interface since as someone
pointed out that just like and egress ACL, egress policy routes only
deals with traffic sent Through the router).
Just make the ACL to identify interesting traffic is granular enough
to not specify media traffic (although that would only be an issue if
there were a CUBE doing media flow-through on the same box).
Cheers!
--
Mark Snow
CCIE #14073 (Voice, Security)
Senior Technical Instructor - IPexpert, Inc.
Telephone: +1.810.326.1444
Fax: +1.309.413.4097
Mailto: [email protected]
--
Join our free online support and peer group communities:
http://www.IPexpert.com/communities
--
IPexpert - The Global Leader in Self-Study, Classroom-Based, Video-On-
Demand and Audio Certification Training Tools for the Cisco CCIE R&S
Lab, CCIE Security Lab, CCIE Service Provider Lab , CCIE Voice Lab and
CCIE Storage Lab Certifications.
--
On Apr 14, 2009, at 7:51 PM, Chris Parker wrote:
Here's the cap with the traffic from the GK to UCM. It does appear to be
tagged as CS3.
Cliff McGlamry wrote:
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>
<GK-CS3.pcap>
