[OSL | CCIE_Voice] Qos Marking
hi, on making marking on the routers, do i make a policy match the protocols sip,h323..etc and set the dscp or do i make under the voip dialpeers and in the mgcp or do i have to have both Please advise
Re: [OSL | CCIE_Voice] Qos Marking
Marwa, I think that we have to both because: - Policy-map marks the pkts that goes through the router - With ip qos dscp cs3 signaling and mgcp ip qos dscp cs3 signaling marks pkts thats are originated at router and are not inspect by the output policy-maps. Sergio From: marwa_ah...@seegypt.com To: ccie_voice@onlinestudylist.com Date: Sun, 3 May 2009 11:17:40 +0200 Subject: [OSL | CCIE_Voice] Qos Marking hi, on making marking on the routers, do i make a policy match the protocols sip,h323..etc and set the dscp or do i make under the voip dialpeers and in the mgcp or do i have to have both Please advise _ Deixe suas conversas mais divertidas. Baixe agora mesmo novos emoticons. É grátis! http://specials.br.msn.com/ilovemessenger/pacotes.aspx
[OSL | CCIE_Voice] QoS - Marking on endpoints
Vik, What is the best configuration on switches in networks that we have to do the marking in the endpoints. Should we let the qos disable or turn it enable and apply trust configurations in the ports ? Thanks in advance, Silvio _ Windows Live Messenger. O melhor em multitarefa. http://www.microsoft.com/windows/windowslive/messenger.aspx
Re: [OSL | CCIE_Voice] QOS Marking
Hi Hany, There is a good vLecture regarding to Campus QoS on IPexpert website. Even so, your specific question is not clear for me also. My best guess is that you just have to configure voice and vlan in the interfaces, and let the qos being disable. Could be good if someone could clarify it a little more. Hany Hanna hhanna1000 at gmail.com Fri Jan 9 23:17:28 EST 2009 Previous message: [OSL | CCIE_Voice] Requested circuit/channel not available onPSTN GW ? Next message: [OSL | CCIE_Voice] Ephones still registering with gatekeeper with no-reg!! Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] What if I need to mark QOS only on routers R1, R2, R3. No marrking to be done on the switches. Should qos be just disabled on the switches? -- next part -- An HTML attachment was scrubbed... URL: http://onlinestudylist.com/pipermail/ccie_voice/attachments/20090109/4e4a79b3/attachment.htm _ Organize seus contatos! O jeito mais fácil de manter a sua lista de amigos sempre em ordem! http://www.microsoft.com/windows/windowslive/events.aspx
[OSL | CCIE_Voice] QOS Marking
What if I need to mark QOS only on routers R1, R2, R3. No marrking to be done on the switches. Should qos be just disabled on the switches?
[OSL | CCIE_Voice] QOS marking question from passed guys.
Hi, QOS marking can be done on several places: Servers traffic marking : on ccm enterprise parameters : DSCP for SCCP Phone Configuration ,DSCP for Cisco CallManager to Device Interface on 6500: match base on acl ports on router's uplink to switch : (match protocol ... ) IOS : h323 dial-peers , mgcp ip qos ,sccp qos dscp ) ---so where is the best place for marking traffic ? (between marking base on 6500 and uplink of router which on is a valid config or both of them? (from lab point of view) --- what is DSCP for Cisco CallManager to Device Interface this parameter do? I cannot find clear info on what is this parameter marking from ccm help --- which types of traffic marks by ccm and witch does not ? ( h323 signalling ,sccp,sip ,h323 ras, rtp, sip, mgcp ??) do I need to write acl on 6500 and mark them on server ports? --- ipphones mark data vlan to dscp 0 , do I need to remark on data vlan and voice vlan again? (I see in some Doc that they match sip and h323 and then mark them again ) ANy useful tips that clear these doubts ? I'm a bit confused ,which methods I should mix and put as marking solution. Jeremy
Re: [OSL | CCIE_Voice] qos marking ideas !!!
Hi, How are you? I been trying to figure this out as well. One thing that I can point out in your configuration is that the HQ router incoming from 6500. If you mark all the traffic with DSCP 0 for the class-default then you will be marking the Voice Payloads as well I think. So just leaving the class class-default blank should not touch the voice payload everything else will have their original DSCP values. Cheers, Onur. On Fri, May 9, 2008 at 3:42 AM, Djokic Sinisa [EMAIL PROTECTED] wrote: hi team.. i'm new on this list and have some concerns about QoS.. so, maybe someone can help.. so, the thing is that i want to mark signalig traffic ( h323, sccp, mgcp, ras, sip ) on HQ-RTR, RSB-RTR and RSC-RTR, and NOT trust markings on the switches or to remark on them.. so, this is idea how to do it, but i have some concerns as you would see and doubts about it.. so, if anyone has idea how to do it i'd appreciated it.. so here it is.. *for HQ-RTR* ! ip access-list extended CONTROL-HQ permit tcp any range 2000 2002 any ccm-to-phones we need cover both directions i think - it all goes over the same subinf on HQ-RTR permit tcp any any range 2000 2002 phones-to-ccm we need cover both directions i think - it all goes over the same subinf on HQ-RTR permit tcp any eq 2428 any ccm-to-mgcp-gw permit tcp any any eq 2428 mgcp-gw-to-ccm6608-to-ccm, for RSB-RTR-to-ccm it goes on RSB-RTR permit udp any eq 2427 any ccm-to-mgcp-gw permit udp any any eq 2427 mgcp-gw-to-ccm6608-to-ccm, for RSB-RTR-to-ccm it goes on RSB-RTR permit tcp any any eq 1720 permit udp any eq 1719 any ccm-to-gk vice-versa gk-to-ccm i'm not shure should i do it and how to do it permit tcp any any eq 1718 ccm-to-gk permit udp any any eq 5060 ccm-to-sip-gwvice versa handles ip qos command under dial-peer permit tcp any any eq 5060 ccm-to-sip-gwvice versa handles ip qos command under dial-peer ! class-map match-any CONTROL-HQ match access-group name CONTROL-HQ ! policy-map MARK class CONTROL-HQ set dscp cs3 class class-default *I SUPPOSE IT MUST be default one as well, beacuse if not we may have undesired data traffic with wrong marking traversing our WAN* set dscp default *but it so, there must be class for RTP as well or it would be remarked and that's bad* ! interface FastEthernet0/0.XY - VOICE ONE service-policy input MARK ! interface FastEthernet0/0.XY - DATA ONE *SHOULD i put in on data subinterface as well - the same reason as above, should i take care of potentially uneamted traffic form data vlan* service-policy input MARK *this makes sence to put only in HQ ethernet ingress subinterfaces - input..* *i'm not shure should it be put on data as well..i think yes..* *for RSB-RTR* ip access-list extended CONTROL-RSB permit tcp any any range 2000 2002 phones-to-ccm ! class-map match-any CONTROL-RSB match access-group name CONTROL-RSB ! policy-map MARK class CONTROL-RSB set dscp cs3 class class-default *I SUPPOSE IT MUST be default one as well, beacuse if not we may have undesired data traffic with wrong marking traversing our link* set dscp default *the only place i can think of this have sense to put is in input direction on interface Vlan XY '( voice ) as well as in input direction on interface Vlan XY ( data )..* *mgcp ip qos dscp cs3 control handles mgcp originating from router* *no H323 from-and-to-RSB when srst is working, then wan is down* *no RAS from-and-to RSB* *no SIP from-and-to RSB* ! *for RSB-RTR* ip access-list extended CONTROL-RSB permit tcp any any range 2000 2002 phones-to-ccm ALTHOUGH i don't se point to mark SCCP on RSC since doesn't traverse WAN ! class-map match-any CONTROL-RSB match access-group name CONTROL-RSB ! policy-map MARK class CONTROL-RSB set dscp cs3 class class-default *I SUPPOSE IT MUST be default one as well, beacuse if not we may have undesired data traffic with wrong marking traversing our link* set dscp default *ip qos dscp cs3 signaling handles h323 and ras originating from router* *no mgcp from-and-to-RSC when srst is working, then wan is down* *no RAS from-and-to RSB* *SIP from-and-to RSB we
Re: [OSL | CCIE_Voice] QoS marking based on port
Hi Greg, I've been putting this on the agenda too - and was planning to use ethereal to grab all port numbers sent out by the UCM/Unity... - I believe it's only there that you need to classify based on the port numbers. Maybe yes, your idea about netstat may even be a better alternative one... Another thing relating to this, is the CCME, which terminates RTP and recreates it (example: call CCME phone/VTA to UCM phone). It looks like the CCME is setting up this new RTP stream with the TOS you set on the voip dialpeer towards UCM/IPIP, so there you loose the AF41 classification in case you have a video call. cheers, Juan From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gregory Jost (grjost) Sent: Thursday, April 17, 2008 4:07 PM To: ccie_voice@onlinestudylist.com Subject: [OSL | CCIE_Voice] QoS marking based on port There's a shroud of mystery around protocol port mappings. It's documented one way, taught another, but no one really knows what the proctor is looking for. To me, the definitive answer would be to look at the open ports on servers (netstat -a from CMD), and the open ports on the routers (sh ip sockets). This will show the exact ports being used by the active devices, including src/dst and udp/tcp (IP 17 and 6 respectively); however, this may not be what the proctor is looking for. For example, if you're using UDP for SIP, there will not be an open TCP port. If the proctor sees that you've only included udp 5060 for SIP, he may deduct points. For something like this, there should be a right way; otherwise, we should be able to just remember the port numbers and use tcp/udp src/dst for all signaling traffic. It doesn't make sense to me that we can be overkill with some, but not with others. Since my lab is next week, I'm going to just memorize it per IPExpert and hope for the best, instead of trying to make sense of it. I think it's worth bringing up to the proctors though. Anyone have any thoughts or suggestions on this? Greg Jost Network Consulting Engineer Unified Communications Practice Cisco Systems, Inc. 214-274-1922
Re: [OSL | CCIE_Voice] QoS marking based on port
this thread covers it pretty well. http://www.certificationtalk.com:81/showflat.php?Cat//Board/voice4twelve/Number/27122/page/0/view/collapsed/sb/5/o//fpart/1 here is ACL that Mark Snow posted... --snippet-- set port qos 2/42 port-based set qos acl ip POD12_SERVER dscp 26 tcp any range 2000 2002 any set qos acl ip POD12_SERVER dscp 26 tcp any any range 1024 4999 set qos acl ip POD12_SERVER dscp 26 tcp any any range 11000 11999 set qos acl ip POD12_SERVER dscp 26 tcp any any eq 1718 set qos acl ip POD12_SERVER dscp 26 udp any any eq 1719 set qos acl ip POD12_SERVER dscp 26 tcp any any eq 1720 set qos acl ip POD12_SERVER dscp 26 udp any eq 2427 any set qos acl ip POD12_SERVER dscp 26 tcp any eq 2428 any commit qos acl POD12_SERVER set qos acl map POD12_SERVER 2/42 --snippet-- I'll add SIP set qos acl ip POD12_SERVER dscp 26 udp any any eq 5060 set qos acl ip POD12_SERVER dscp 26 tcp any any eq 5060 I've personally verified ports 2000, 1719, 1720, 2427, 2428 from Mark's post in wireshark. I don't know about 1718 - Cisco docs list it as gateway discovery (multicast?) - easy enough to addalthough, I'm fairly confident CCM doesn't support this method. Justin On Thu, Apr 17, 2008 at 10:07 AM, Gregory Jost (grjost) [EMAIL PROTECTED] wrote: There's a shroud of mystery around protocol port mappings. It's documented one way, taught another, but no one really knows what the proctor is looking for. To me, the definitive answer would be to look at the open ports on servers (netstat –a from CMD), and the open ports on the routers (sh ip sockets). This will show the exact ports being used by the active devices, including src/dst and udp/tcp (IP 17 and 6 respectively); however, this may not be what the proctor is looking for. For example, if you're using UDP for SIP, there will not be an open TCP port. If the proctor sees that you've only included udp 5060 for SIP, he may deduct points. For something like this, there should be a right way; otherwise, we should be able to just remember the port numbers and use tcp/udp src/dst for all signaling traffic. It doesn't make sense to me that we can be overkill with some, but not with others. Since my lab is next week, I'm going to just memorize it per IPExpert and hope for the best, instead of trying to make sense of it. I think it's worth bringing up to the proctors though. Anyone have any thoughts or suggestions on this? Greg Jost Network Consulting Engineer Unified Communications Practice Cisco Systems, Inc. 214-274-1922
Re: [OSL | CCIE_Voice] QoS marking based on port
I think you should use a final ACE statement set qos acl ip POD12_SERVER trust-dscp any in order to not mark-down any RTP traffic like MOH, ANN, CFB or MTP to DSCP 0 (the default ACL). See the ACL flowchart: http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/catos/7.x/configuration/guide/qos.html#wp1084547 Cordialmente, Gustavo Sánchez From: Justin Steinberg [mailto:[EMAIL PROTECTED] Sent: Jueves, 17 de Abril de 2008 10:13 a.m. To: Gregory Jost (grjost) Cc: ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] QoS marking based on port this thread covers it pretty well. http://www.certificationtalk.com:81/showflat.php?Cat//Board/voice4twelve/Number/27122/page/0/view/collapsed/sb/5/o//fpart/1 here is ACL that Mark Snow posted... --snippet-- set port qos 2/42 port-based set qos acl ip POD12_SERVER dscp 26 tcp any range 2000 2002 any set qos acl ip POD12_SERVER dscp 26 tcp any any range 1024 4999 set qos acl ip POD12_SERVER dscp 26 tcp any any range 11000 11999 set qos acl ip POD12_SERVER dscp 26 tcp any any eq 1718 set qos acl ip POD12_SERVER dscp 26 udp any any eq 1719 set qos acl ip POD12_SERVER dscp 26 tcp any any eq 1720 set qos acl ip POD12_SERVER dscp 26 udp any eq 2427 any set qos acl ip POD12_SERVER dscp 26 tcp any eq 2428 any commit qos acl POD12_SERVER set qos acl map POD12_SERVER 2/42 --snippet-- I'll add SIP set qos acl ip POD12_SERVER dscp 26 udp any any eq 5060 set qos acl ip POD12_SERVER dscp 26 tcp any any eq 5060 I've personally verified ports 2000, 1719, 1720, 2427, 2428 from Mark's post in wireshark. I don't know about 1718 - Cisco docs list it as gateway discovery (multicast?) - easy enough to addalthough, I'm fairly confident CCM doesn't support this method. Justin On Thu, Apr 17, 2008 at 10:07 AM, Gregory Jost (grjost) [EMAIL PROTECTED] wrote: There's a shroud of mystery around protocol port mappings. It's documented one way, taught another, but no one really knows what the proctor is looking for. To me, the definitive answer would be to look at the open ports on servers (netstat -a from CMD), and the open ports on the routers (sh ip sockets). This will show the exact ports being used by the active devices, including src/dst and udp/tcp (IP 17 and 6 respectively); however, this may not be what the proctor is looking for. For example, if you're using UDP for SIP, there will not be an open TCP port. If the proctor sees that you've only included udp 5060 for SIP, he may deduct points. For something like this, there should be a right way; otherwise, we should be able to just remember the port numbers and use tcp/udp src/dst for all signaling traffic. It doesn't make sense to me that we can be overkill with some, but not with others. Since my lab is next week, I'm going to just memorize it per IPExpert and hope for the best, instead of trying to make sense of it. I think it's worth bringing up to the proctors though. Anyone have any thoughts or suggestions on this? Greg Jost Network Consulting Engineer Unified Communications Practice Cisco Systems, Inc. 214-274-1922
Re: [OSL | CCIE_Voice] QoS marking based on port
BTW Port 1718 This doc says UDP: http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note0 9186a00801a62b9.shtml#topic1 This doc says TCP: http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/port/4_2/42plrev2.pdf Maybe it can be either... Greg Jost Network Consulting Engineer Unified Communications Practice Cisco Systems, Inc. 214-274-1922 From: Gregory Jost (grjost) Sent: Thursday, April 17, 2008 12:44 PM To: Gregory Jost (grjost); Justin Steinberg Cc: ccie_voice@onlinestudylist.com Subject: RE: [OSL | CCIE_Voice] QoS marking based on port Correction!!! Near the bottom... At any rate, marking on UDP (not TCP) 1719 should take care of this Greg Jost Network Consulting Engineer Unified Communications Practice Cisco Systems, Inc. 214-274-1922 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gregory Jost (grjost) Sent: Thursday, April 17, 2008 12:18 PM To: Justin Steinberg Cc: ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] QoS marking based on port There are various flavors of this. There isn't any partial credit, and no one knows the right answer. Per sh IP sockets and netstat -a: udp any any eq 5060 udp any any eq 1719 udp any any eq 1718 Router shows udp port tcp any eq 1720 any tcp any range 2000 2002 any udp any eq 2427 any udp any eq 2428 any Per Mark Snow: tcp any range 2000 2002 any tcp any any range 1024 4999 tcp any any range 11000 11999 tcp any any eq 1718 udp any any eq 1719 tcp any any eq 1720 udp any eq 2427 any tcp any eq 2428 any Per IPExpert bootcamp notes last week: Udp any any range 1718 1720 Udp any range 1718 1720 any Tcp any any range 1718 1720 Tcp any range 1718 1720 any Udp any eq 2427 any Tcp any eq 2428 any Tcp any any eq 5060 Tcp any eq 5060 any Udp any any eq 5060 Udp any eq 5060 any Documentation: http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/port/4_2/42plrev2.pdf Discrepancies: 1. 1718 shows udp on router, not tcp HQ#sh ip sockets | include 1718 ProtoRemote Port LocalPort In Out Stat TTY OutputIF 17 --listen--224.0.1.41 1718 0 0 1 0 Note: Proto 17=udp, Proto 6=tcp 2. tcp 1024-4999. This is pre-2000.2.7 OS ephemeral. At any rate, marking on TCP 1719 should take care of this 3. tcp 11000-11999 This is dynamic for H.245 (per call I think), so it wouldn't show unless there is an active call. I didn't have this in my notes from the class. I need to verify in lab. Greg Jost Network Consulting Engineer Unified Communications Practice Cisco Systems, Inc. 214-274-1922 From: Justin Steinberg [mailto:[EMAIL PROTECTED] Sent: Thursday, April 17, 2008 10:13 AM To: Gregory Jost (grjost) Cc: ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] QoS marking based on port this thread covers it pretty well. http://www.certificationtalk.com:81/showflat.php?Cat//Board/voice4twelve /Number/27122/page/0/view/collapsed/sb/5/o//fpart/1 here is ACL that Mark Snow posted... --snippet-- set port qos 2/42 port-based set qos acl ip POD12_SERVER dscp 26 tcp any range 2000 2002 any set qos acl ip POD12_SERVER dscp 26 tcp any any range 1024 4999 set qos acl ip POD12_SERVER dscp 26 tcp any any range 11000 11999 set qos acl ip POD12_SERVER dscp 26 tcp any any eq 1718 set qos acl ip POD12_SERVER dscp 26 udp any any eq 1719 set qos acl ip POD12_SERVER dscp 26 tcp any any eq 1720 set qos acl ip POD12_SERVER dscp 26 udp any eq 2427 any set qos acl ip POD12_SERVER dscp 26 tcp any eq 2428 any commit qos acl POD12_SERVER set qos acl map POD12_SERVER 2/42 --snippet-- I'll add SIP set qos acl ip POD12_SERVER dscp 26 udp any any eq 5060 set qos acl ip POD12_SERVER dscp 26 tcp any any eq 5060 I've personally verified ports 2000, 1719, 1720, 2427, 2428 from Mark's post in wireshark. I don't know about 1718 - Cisco docs list it as gateway discovery (multicast?) - easy enough to addalthough, I'm fairly confident CCM doesn't support this method. Justin On Thu, Apr 17, 2008 at 10:07 AM, Gregory Jost (grjost) [EMAIL PROTECTED] wrote: There's a shroud of mystery around protocol port mappings. It's documented one way, taught another, but no one really knows what the proctor is looking for. To me, the definitive answer would be to look at the open ports on servers (netstat -a from CMD), and the open ports on the routers (sh ip sockets). This will show the exact ports being used by the active devices, including src/dst and udp/tcp (IP 17 and 6 respectively); however, this may not be what the proctor is looking for. For example, if you're using UDP for SIP, there will not be an open TCP port. If the proctor sees that you've only included udp 5060
Re: [OSL | CCIE_Voice] QOS marking on the router
Service Policies only queue and mark on the outbound, on the inbound they can only mark... (there are no input queues on a router...) Jonathan On Fri, Mar 28, 2008 at 4:44 PM, jason sung [EMAIL PROTECTED] wrote: Thanks JD. I think you are correct. I keep forgetting this basic logic. I was jotting down small tips to read during the flight. CUE works the same. On Fri, Mar 28, 2008 at 3:37 PM, Devildoc [EMAIL PROTECTED] wrote: If you mark the control traffic comming from the LAN (i.e. Cat6500 switch), then you'll need to apply the policy on the FastEthernet trunk in the inbound direction on the router. When you apply a policy to an interface, it is from the perspective of the router that the policy is being serviced. In this case, the router sees the traffics comming into it, so it must be applied on the inbound. JD Date: Thu, 27 Mar 2008 21:50:12 -0500 From: [EMAIL PROTECTED] To: ccie_voice@onlinestudylist.com Subject: [OSL | CCIE_Voice] QOS marking on the router If I am trying to mark my control traffic on the router. Do I apply the policymap to inbound or oubound side of the fastEthernet. I think outbound but I have heard people say inbound. Watch Cause Effect, a show about real people making a real difference. Learn more.
Re: [OSL | CCIE_Voice] QOS marking on the router
If you mark the control traffic comming from the LAN (i.e. Cat6500 switch), then you'll need to apply the policy on the FastEthernet trunk in the inbound direction on the router. When you apply a policy to an interface, it is from the perspective of the router that the policy is being serviced. In this case, the router sees the traffics comming into it, so it must be applied on the inbound. JD Date: Thu, 27 Mar 2008 21:50:12 -0500From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: [OSL | CCIE_Voice] QOS marking on the router If I am trying to mark my control traffic on the router. Do I apply the policymap to inbound or oubound side of the fastEthernet. I think outbound but I have heard people say inbound. _ Watch “Cause Effect,” a show about real people making a real difference. Learn more. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause
[OSL | CCIE_Voice] QOS marking on the router
If I am trying to mark my control traffic on the router. Do I apply the policymap to inbound or oubound side of the fastEthernet. I think outbound but I have heard people say inbound.
