Re: [OSL | CCIE_Voice] Access list for cue traffic marking
The other point that also worth bearing in mind is this one concerning command mls qos, http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_50_se/command/reference/cli1.html#wp5046030 . In essence, with 'mls qos' turned on, the default port trust state on all ports is untrusted. It is easy to forget this especially when you focus your attention to a single port on the switch under time limitation. mls qos ... ... Defaults QoS is disabled. There is no concept of trusted or untrusted ports because the packets are not modified (the CoS, DSCP, and IP precedence values in the packet are not changed). Traffic is switched in pass-through mode (packets are switched without any rewrites and classified as best effort without any policing). *When QoS is enabled with the mls qos global configuration command and all other QoS settings are set to their defaults, traffic is classified as best effort (the DSCP and CoS value is set to 0) without any policing. No policy maps are configured. The default port trust state on all ports is untrusted. The default ingress and egress queue settings are in effect.* Regards, --Somphol. On Mon, Aug 12, 2013 at 12:19 PM, Somphol Boonjing somp...@gmail.comwrote: This might be worth revisiting.Forgive me if this is not entirely a new insight. In short, be aware that as soon as the command service-policy input XXX in entered into the configuration, the mls qos trust cos/dscp will be removed. Likewise, if the command mls qos trust cos/dscp is re-entered, the command service-policy input XXX will be automatically removed. http://www.cisco.com/en/US/products/hw/switches/ps5023/products_tech_note09186a0080883f9e.shtml - If any other QoS Classification methods, such as port based or VLAN based, are configured on the port gi 1/0/3, those configurations are removed when you apply the policy-map. For example, the port Gi 1/0/13 is configured to trust CoS as shown here: interface GigabitEthernet1/0/13 description Access Port switchport access vlan 10 switchport mode access switchport voice vlan 100 mls qos cos 3 mls qos trust cos spanning-tree portfast - When you apply the policy-map to the interface, it removes the *trust* command. Distribution1(config)#*int gi 1/0/13* Distribution1(config-if)#*service-policy input sample-policy1* Distribution1(config-if)#*do show run int gi 1/0/13* Building configuration... Current configuration : 228 bytes ! interface GigabitEthernet1/0/13 description Access Port switchport access vlan 10 switchport mode access switchport voice vlan 100 service-policy input sample-policy1 *!--- It replaces the mls qos trust or mls qos !--- vlan-based command.* mls qos cos 3 *!--- This command is not removed.* spanning-tree portfast end Regards, --Somphol. On Mon, Jul 8, 2013 at 12:42 PM, jainpiyush2...@ymail.com wrote: Steve, you absolutely make sense that traffic for cue can be marked on router (site c) on which cue module is connected when it goes out on wan link.. and then on the trunk port on hq switch we would have trust statement. However the question in lab expect us to mark the cue traffic on hq switch on the port connected to sub cucm.. so the above solution won't work.. right? Thanks and regards, Piyush Jain Sent from my android device. -Original Message- From: sbar...@mystictraveler.net To: LorenzLGRC lorenzl...@gmail.com, Piyush Jain jainpiyush2...@ymail.com Cc: ccie_voice@onlinestudylist.com ccie_voice@onlinestudylist.com Sent: Mon, 08 Jul 2013 6:23 AM Subject: RE: [OSL | CCIE_Voice] Access list for cue traffic marking Maybe I am missing something so please forgive me, and to recap, the question was LAN QoS and CUE (not WAN). The example below (which is pretty much out of the SRND) will correctly mark the traffic, but only going out the serial port. It seems to me that you would want to mark the traffic inbound from the CUE module to the router in which it resides so that no matter how the traffic exits the router it will be handled correctly. Can you mark the traffic as it leaves the AIM module and is passed to the router? As far as the policy map on the serial port, wouldn't we want to see all traffic correctly prioritized not just the CTI-QBE to answer the question correctly if we were to look at the WAN QoS? I assume for traffic leaving on an LAN port to a switch, the switch would have the appropriate trust statements and since we marked on the packets as they transition from the AIM to the router prioritization and re-marking would not be an issue? Steve Original Message Subject: Re: [OSL | CCIE_Voice] Access list for cue traffic marking From: LorenzLGRC lorenzl...@gmail.com Date: Sun, July 07, 2013 5:25 am To: Piyush Jain
Re: [OSL | CCIE_Voice] Access list for cue traffic marking
This might be worth revisiting.Forgive me if this is not entirely a new insight. In short, be aware that as soon as the command service-policy input XXX in entered into the configuration, the mls qos trust cos/dscp will be removed. Likewise, if the command mls qos trust cos/dscp is re-entered, the command service-policy input XXX will be automatically removed. http://www.cisco.com/en/US/products/hw/switches/ps5023/products_tech_note09186a0080883f9e.shtml - If any other QoS Classification methods, such as port based or VLAN based, are configured on the port gi 1/0/3, those configurations are removed when you apply the policy-map. For example, the port Gi 1/0/13 is configured to trust CoS as shown here: interface GigabitEthernet1/0/13 description Access Port switchport access vlan 10 switchport mode access switchport voice vlan 100 mls qos cos 3 mls qos trust cos spanning-tree portfast - When you apply the policy-map to the interface, it removes the *trust* command. Distribution1(config)#*int gi 1/0/13* Distribution1(config-if)#*service-policy input sample-policy1* Distribution1(config-if)#*do show run int gi 1/0/13* Building configuration... Current configuration : 228 bytes ! interface GigabitEthernet1/0/13 description Access Port switchport access vlan 10 switchport mode access switchport voice vlan 100 service-policy input sample-policy1 *!--- It replaces the mls qos trust or mls qos !--- vlan-based command.* mls qos cos 3 *!--- This command is not removed.* spanning-tree portfast end Regards, --Somphol. On Mon, Jul 8, 2013 at 12:42 PM, jainpiyush2...@ymail.com wrote: Steve, you absolutely make sense that traffic for cue can be marked on router (site c) on which cue module is connected when it goes out on wan link.. and then on the trunk port on hq switch we would have trust statement. However the question in lab expect us to mark the cue traffic on hq switch on the port connected to sub cucm.. so the above solution won't work.. right? Thanks and regards, Piyush Jain Sent from my android device. -Original Message- From: sbar...@mystictraveler.net To: LorenzLGRC lorenzl...@gmail.com, Piyush Jain jainpiyush2...@ymail.com Cc: ccie_voice@onlinestudylist.com ccie_voice@onlinestudylist.com Sent: Mon, 08 Jul 2013 6:23 AM Subject: RE: [OSL | CCIE_Voice] Access list for cue traffic marking Maybe I am missing something so please forgive me, and to recap, the question was LAN QoS and CUE (not WAN). The example below (which is pretty much out of the SRND) will correctly mark the traffic, but only going out the serial port. It seems to me that you would want to mark the traffic inbound from the CUE module to the router in which it resides so that no matter how the traffic exits the router it will be handled correctly. Can you mark the traffic as it leaves the AIM module and is passed to the router? As far as the policy map on the serial port, wouldn't we want to see all traffic correctly prioritized not just the CTI-QBE to answer the question correctly if we were to look at the WAN QoS? I assume for traffic leaving on an LAN port to a switch, the switch would have the appropriate trust statements and since we marked on the packets as they transition from the AIM to the router prioritization and re-marking would not be an issue? Steve Original Message Subject: Re: [OSL | CCIE_Voice] Access list for cue traffic marking From: LorenzLGRC lorenzl...@gmail.com Date: Sun, July 07, 2013 5:25 am To: Piyush Jain jainpiyush2...@ymail.com Cc: ccie_voice@onlinestudylist.com ccie_voice@onlinestudylist.com Hello, you can use something like this: access-list 101 permit tcp host a.b.c.d any eq 2748 ! class-map match-all cti-qbe match access-group 101 ! policy-map cti-qbe class cti-qbe set dscp af31 bandwidth 20 ! interface Serial0/1 service-policy output cti-qbe On Sun, Jul 7, 2013 at 6:06 AM, Piyush Jain jainpiyush2...@ymail.comwrote: Hi Guys, I am trying to understand how we can mark CUE traffic on HQ Switch to implement LAN QOS. I have come up with the below solution. ip access-list extended name CUE permit tcp host 142.100.64.12 host 142.1.66.253 eq 2748 class-map match-any CUE-CLASS match access group name CUE policy-map CUE-POLICY class CUE-CLASS set ip dhcp CS3 int fa 1/0/4 description * CONNECTED TO SUB CUCM *** service policy input CUE-POLICY In above config, 142.100.64.12 is SUB CUCM, 142.1.66.253 is CUE on SC router. Explanation: Since we are applying service policy in incoming direction on switch port connected to CUCM, so the source port number (of CUCM) can be anything but destination port number (i.e for CUE) should be 2748 (JTAPI port). Any advice or inputs are most welcome. Cheers !! Piyush Jain
Re: [OSL | CCIE_Voice] Access list for cue traffic marking
Hello, you can use something like this: access-list 101 permit tcp host a.b.c.d any eq 2748 ! class-map match-all cti-qbe match access-group 101 ! policy-map cti-qbe class cti-qbe set dscp af31 bandwidth 20 ! interface Serial0/1 service-policy output cti-qbe On Sun, Jul 7, 2013 at 6:06 AM, Piyush Jain jainpiyush2...@ymail.comwrote: Hi Guys, I am trying to understand how we can mark CUE traffic on HQ Switch to implement LAN QOS. I have come up with the below solution. ip access-list extended name CUE permit tcp host 142.100.64.12 host 142.1.66.253 eq 2748 class-map match-any CUE-CLASS match access group name CUE policy-map CUE-POLICY class CUE-CLASS set ip dhcp CS3 int fa 1/0/4 description * CONNECTED TO SUB CUCM *** service policy input CUE-POLICY In above config, 142.100.64.12 is SUB CUCM, 142.1.66.253 is CUE on SC router. Explanation: Since we are applying service policy in incoming direction on switch port connected to CUCM, so the source port number (of CUCM) can be anything but destination port number (i.e for CUE) should be 2748 (JTAPI port). Any advice or inputs are most welcome. Cheers !! Piyush Jain ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
Re: [OSL | CCIE_Voice] Access list for cue traffic marking
Guys , Get the biggest relief in your life. If you see this CUE QOS question just give it up. No one has ever scored that CUE Switch QOS and many people tried different things. My only advice give it up completely and never waste ur time or energy solving it. That particular lab is very long and if you have 2 hours left then try to play with it and enjoy. Knowing that the guys who passed this lab still didn't score that question in particular. In order for that question to be solved that needs to be consulted to a very knowledgable Routing and Switching . SP and Voice simultaneously even though the Cisco grading would be different than the real realistic world. To conclude , Never waste ur time or energy solve this stupid question trust me. Your passing score is 80% and this stupid question could be about 4% of the whole test. I know for fact that every minor mark counts in the total but its really up to the destiny. To me CCIE Test is no longer a test that you are real knowledgable or not. I definitely believe 100% CCIE test is like a gambling game , Jackpot or a roulette in LAS VEGAS. Don't have the faith that this thing is graded fairly with a standard. On 7 July 2013 02:25, LorenzLGRC lorenzl...@gmail.com wrote: Hello, you can use something like this: access-list 101 permit tcp host a.b.c.d any eq 2748 ! class-map match-all cti-qbe match access-group 101 ! policy-map cti-qbe class cti-qbe set dscp af31 bandwidth 20 ! interface Serial0/1 service-policy output cti-qbe On Sun, Jul 7, 2013 at 6:06 AM, Piyush Jain jainpiyush2...@ymail.comwrote: Hi Guys, I am trying to understand how we can mark CUE traffic on HQ Switch to implement LAN QOS. I have come up with the below solution. ip access-list extended name CUE permit tcp host 142.100.64.12 host 142.1.66.253 eq 2748 class-map match-any CUE-CLASS match access group name CUE policy-map CUE-POLICY class CUE-CLASS set ip dhcp CS3 int fa 1/0/4 description * CONNECTED TO SUB CUCM *** service policy input CUE-POLICY In above config, 142.100.64.12 is SUB CUCM, 142.1.66.253 is CUE on SC router. Explanation: Since we are applying service policy in incoming direction on switch port connected to CUCM, so the source port number (of CUCM) can be anything but destination port number (i.e for CUE) should be 2748 (JTAPI port). Any advice or inputs are most welcome. Cheers !! Piyush Jain ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
Re: [OSL | CCIE_Voice] Access list for cue traffic marking
Hi, Forgive me to chime in and most likely this won't answer the original question outright. Hesham's response is fairly inspiring in a way. It inspires me think a lot harder about this area. - Take another closer look at what is available, it is intriguing to see Layer 3 information such as IP Address header is now being inspected at a Layer 2 port through access-list and MQC. This is similar to the fact that Switch are now able to mare/re-mark DSCP which is at the IP header level. In all cases, it is likely to be a very simple IP header inspection and won't be able to do the full Layer 7 inspection. - Traffic classification when apply to Switch port, it will be subject to being [1] a very simply packet filtering tool such as access-list [2] different based on the direction.i.e. access-list to catch incoming traffic to device connecting to the switch vs the access-list to catch outgoing traffic from that device is going to be asymmetric. - If I would want to test the knowledge of traffic flow, while I can put the actual wording of the requirement differently, the core of the question would be Do you know all or some of the *incoming* traffic that flow from such as such to the rest of the infrastructure OR to a certain component of the infrastructure? With a simple twist, the question can be slightly changed to ask. Do you know all or some of the *outgoing* traffic that flow from such as such to the rest of the infrastructure OR to a certain component of the infrastructure? Now, replace such as such with: - CUCM Publisher - CUCM Subscriber - CUE - CUC Server - UCCX Server - CUPS Server - H323 Gateways - H323 Gatekeepers - IOS-based Media Resources - DHCP Server - TFTP Server - IP Phones - Attendant Console workstation - Agent Desktop workstation - CUPC Client Based on these basic ingredient, I guess someone can make a large set of exam bank out of it. This sort of question will be hard to crack if someone comes across a variation of it for the first time in the lab.It would be even harder to crack if someone try to memorize a set of access-list without really understand why it is the way it is. i.e. when to use access-list 101 tcp any any host x.x.x.x 2000 vs access-list 101 tcp host x.x.x.x 2000 any any. I don't dispute the probability of unreasonableness of the grading process itself, but this could also be a sound explanation of why it is very hard to crack. Regards, --Somphol. On Sun, Jul 7, 2013 at 8:38 PM, Hesham Abdelkereem heshamcentr...@gmail.com wrote: Guys , Get the biggest relief in your life. If you see this CUE QOS question just give it up. No one has ever scored that CUE Switch QOS and many people tried different things. My only advice give it up completely and never waste ur time or energy solving it. That particular lab is very long and if you have 2 hours left then try to play with it and enjoy. Knowing that the guys who passed this lab still didn't score that question in particular. In order for that question to be solved that needs to be consulted to a very knowledgable Routing and Switching . SP and Voice simultaneously even though the Cisco grading would be different than the real realistic world. To conclude , Never waste ur time or energy solve this stupid question trust me. Your passing score is 80% and this stupid question could be about 4% of the whole test. I know for fact that every minor mark counts in the total but its really up to the destiny. To me CCIE Test is no longer a test that you are real knowledgable or not. I definitely believe 100% CCIE test is like a gambling game , Jackpot or a roulette in LAS VEGAS. Don't have the faith that this thing is graded fairly with a standard. On 7 July 2013 02:25, LorenzLGRC lorenzl...@gmail.com wrote: Hello, you can use something like this: access-list 101 permit tcp host a.b.c.d any eq 2748 ! class-map match-all cti-qbe match access-group 101 ! policy-map cti-qbe class cti-qbe set dscp af31 bandwidth 20 ! interface Serial0/1 service-policy output cti-qbe On Sun, Jul 7, 2013 at 6:06 AM, Piyush Jain jainpiyush2...@ymail.comwrote: Hi Guys, I am trying to understand how we can mark CUE traffic on HQ Switch to implement LAN QOS. I have come up with the below solution. ip access-list extended name CUE permit tcp host 142.100.64.12 host 142.1.66.253 eq 2748 class-map match-any CUE-CLASS match access group name CUE policy-map CUE-POLICY class CUE-CLASS set ip dhcp CS3 int fa 1/0/4 description * CONNECTED TO SUB CUCM *** service policy input CUE-POLICY In above config, 142.100.64.12 is SUB CUCM, 142.1.66.253 is CUE on SC router. Explanation: Since we are applying service policy in incoming direction on switch port connected to CUCM, so the source port number (of CUCM) can be anything but destination port number (i.e for CUE) should be 2748 (JTAPI port). Any advice or inputs are most welcome.
Re: [OSL | CCIE_Voice] Access list for cue traffic marking
Maybe I am missing something so please forgive me, and to recap, the question was LAN QoS and CUE (not WAN).The example below (which is pretty much out of the SRND) will correctly mark the traffic, but only going out the serial port. It seems to me that you would want to mark the traffic inbound from the CUE module to the router in which it resides so that no matter how the traffic exits the router it will be handled correctly. Can you mark the traffic as it leaves the AIM module and is passed to the router? As far as the policy map on the serial port, wouldn't we want to see all traffic correctly prioritized not just the CTI-QBE to answer the question correctly if we were to look at the WAN QoS?I assume for traffic leaving on an LAN port to a switch, the switch would have the appropriate trust statements and since we marked on the packets as they transition from the AIM to the router prioritization and re-marking would not be an issue?Steve Original Message Subject: Re: [OSL | CCIE_Voice] Access list for cue traffic marking From: LorenzLGRC lorenzl...@gmail.com Date: Sun, July 07, 2013 5:25 am To: Piyush Jain jainpiyush2...@ymail.com Cc: "ccie_voice@onlinestudylist.com" ccie_voice@onlinestudylist.com Hello,you can use something like this:access-list 101 permit tcp host a.b.c.d any eq 2748 ! class-map match-all cti-qbe match access-group 101 ! policy-map cti-qbe class cti-qbe set dscp af31 bandwidth 20 ! interface Serial0/1 service-policy output cti-qbeOn Sun, Jul 7, 2013 at 6:06 AM, Piyush Jain jainpiyush2...@ymail.com wrote: Hi Guys, I am trying to understand how we can mark CUE traffic on HQ Switch to implement LAN QOS. I have come up with the below solution. ip access-list extended name CUEpermit tcp host 142.100.64.12 host 142.1.66.253 eq 2748 class-map match-any CUE-CLASS match access group name CUE policy-map CUE-POLICYclass CUE-CLASS set ip dhcp CS3 int fa 1/0/4description * CONNECTED TO SUB CUCM *** service policy input CUE-POLICY In above config, 142.100.64.12 is SUB CUCM, 142.1.66.253 is CUE on SC router.Explanation: Since we are applying service policy in incoming direction on switch port connected to CUCM, so the source port number (of CUCM) can be anything but destination port number (i.e for CUE) should be 2748 (JTAPI port). Any advice or inputs are most welcome.Cheers !!Piyush Jain ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
Re: [OSL | CCIE_Voice] Access list for cue traffic marking
Steve, you absolutely make sense that traffic for cue can be marked on router (site c) on which cue module is connected when it goes out on wan link.. and then on the trunk port on hq switch we would have trust statement. However the question in lab expect us to mark the cue traffic on hq switch on the port connected to sub cucm.. so the above solution won't work.. right? Thanks and regards, Piyush Jain Sent from my android device. -Original Message- From: sbar...@mystictraveler.net To: LorenzLGRC lorenzl...@gmail.com, Piyush Jain jainpiyush2...@ymail.com Cc: ccie_voice@onlinestudylist.com ccie_voice@onlinestudylist.com Sent: Mon, 08 Jul 2013 6:23 AM Subject: RE: [OSL | CCIE_Voice] Access list for cue traffic marking Maybe I am missing something so please forgive me, and to recap, the question was LAN QoS and CUE (not WAN). The example below (which is pretty much out of the SRND) will correctly mark the traffic, but only going out the serial port. It seems to me that you would want to mark the traffic inbound from the CUE module to the router in which it resides so that no matter how the traffic exits the router it will be handled correctly. Can you mark the traffic as it leaves the AIM module and is passed to the router? As far as the policy map on the serial port, wouldn't we want to see all traffic correctly prioritized not just the CTI-QBE to answer the question correctly if we were to look at the WAN QoS? I assume for traffic leaving on an LAN port to a switch, the switch would have the appropriate trust statements and since we marked on the packets as they transition from the AIM to the router prioritization and re-marking would not be an issue? Steve Original Message Subject: Re: [OSL | CCIE_Voice] Access list for cue traffic marking From: LorenzLGRC lorenzl...@gmail.com Date: Sun, July 07, 2013 5:25 am To: Piyush Jain jainpiyush2...@ymail.com Cc: ccie_voice@onlinestudylist.com ccie_voice@onlinestudylist.com Hello, you can use something like this: access-list 101 permit tcp host a.b.c.d any eq 2748 ! class-map match-all cti-qbe match access-group 101 ! policy-map cti-qbe class cti-qbe set dscp af31 bandwidth 20 ! interface Serial0/1 service-policy output cti-qbe On Sun, Jul 7, 2013 at 6:06 AM, Piyush Jain jainpiyush2...@ymail.com wrote: Hi Guys, I am trying to understand how we can mark CUE traffic on HQ Switch to implement LAN QOS. I have come up with the below solution. ip access-list extended name CUE permit tcp host 142.100.64.12 host 142.1.66.253 eq 2748 class-map match-any CUE-CLASS match access group name CUE policy-map CUE-POLICY class CUE-CLASS set ip dhcp CS3 int fa 1/0/4 description * CONNECTED TO SUB CUCM *** service policy input CUE-POLICY In above config, 142.100.64.12 is SUB CUCM, 142.1.66.253 is CUE on SC router. Explanation: Since we are applying service policy in incoming direction on switch port connected to CUCM, so the source port number (of CUCM) can be anything but destination port number (i.e for CUE) should be 2748 (JTAPI port). Any advice or inputs are most welcome. Cheers !! Piyush Jain ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
[OSL | CCIE_Voice] Access list for cue traffic marking
Hi guys, I am trying to understand how we can mark cue traffic on ha switch.. I have come up with the below acl. Ip access-list extended Thanks and regards, Piyush Jain Sent from my android device. ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
[OSL | CCIE_Voice] Access list for cue traffic marking
Hi Guys, I am trying to understand how we can mark CUE traffic on HQ Switch to implement LAN QOS. I have come up with the below solution. ip access-list extended name CUE permit tcp host 142.100.64.12 host 142.1.66.253 eq 2748 class-map match-any CUE-CLASS match access group name CUE policy-map CUE-POLICY class CUE-CLASS set ip dhcp CS3 int fa 1/0/4 description * CONNECTED TO SUB CUCM *** service policy input CUE-POLICY In above config, 142.100.64.12 is SUB CUCM, 142.1.66.253 is CUE on SC router. Explanation: Since we are applying service policy in incoming direction on switch port connected to CUCM, so the source port number (of CUCM) can be anything but destination port number (i.e for CUE) should be 2748 (JTAPI port). Any advice or inputs are most welcome. Cheers !! Piyush Jain ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
