Experience the most powerful remote phone technology possible with multiple phones visible and controllable in a single application/window, all updating in real-time and responding instantly to your commands. Not only is this the best application for CCIE Voice study, it’s used by thousands of Cisco Voice Engineers globally including several systems with 10,000+ phones.

In addition to the best remote phone experience possible, it’s now even more intuitive with the new phone keypad, here are the main highlights from PhoneView Version 2:

• Fastest (1 Second screen refresh)
• Most Reliable
• Only solution that does not depend on phones web server to control devices
• Unique ability to fix ITL issues in all circumstances
• Easier to use (with a new phone keypad)

We have included a comparison table below giving details of how PhoneView compares with other software companies offering remote control offerings:

The best part, Version 2 is still free for IPexpert students to use on proctor labs rack equipment, just use the license key which is provided when you book a Proctorlabs rack rental session.

If you have your own lab equipment and wish to use PhoneView Version 2, we are pleased to offer a $200 discount for IPexpert students, just use IPEXPERTLAB coupon code at check-out when purchasing the lab edition.

To find out more and download PhoneView Version 2 today visit http://www.unifiedfx.com

Vik Malhi- CCIE 13890
Instructor – IPexpert, Inc.

Print Friendly

Before we look into the 4 options for SRST- just a quick reminder. SRST (Survivable Remote Site Telephony) is an licensed IOS feature that is used to provide call control for phones when the UCM is unavailable. We are going to concentrate on SCCP SRST- SIP SRST has only one option (voice register) and therefore there is no discussion to be had when it comes to which option to use for SIP SRST.

An example of when SRST is going to be useful… Let’s assume we have two offices in our enterprise- our headquarters in San Jose and remote office in Dallas. The UCM cluster resides in San Jose and there are phones and gateways in Dallas. In the event that the phones in Dallas cannot connect to the UCM cluster in San Jose due to a network outage, the Dallas gateway is able to provide call control support using one of 4 options. The option you choose will depend on what features need to be preserved and what type of customization is required.

Option (1): call-manager-fallback

This is the most simple confguration and requires the least amount of time. Individual phone customization is limited and most services/features such as hunt groups, barge, intercom, paging, hardware conference bridge, etc are not supported.

This is the only option that does not use Unified CME for the purposes of SRST.  I would suggest that you only use this option if you are directed to configure the STST gateway ensuring that Unified CME is not being used.

Option (2): telephony-service & srst mode auto-provision none

A quick explanation of what a learned ephone and learned ephone-dn is….

When a SCCP phone has lost connectivity to UCM and an SRST Reference has been added to the Device Pool, the phone will attempt to register to the SRST gateway. The SRST gateway will request the configuration file from the phone and automatically build the configuration in IOS to support the phone and assigned dn’s based on the contents of the configuration file (Simple Network Auto Provisioning a.k.a SNAP). The ephone-dn and ephone configuration is not manually built- instead the IOS gateway builds this configuration. These ephone-dn’s and ephones are known as learned ephone-dns/ephones.

With this option the learned ephones and ephone-dn’s do not show up in the running config- same as option (1) above. This means that per phone and dn customization is not supported. The DN’s on the phone are going to be built based on what is inside the configuration file of the phone and you are not able to change it. For example you could not add BLF speed dials, monitor lines, watch lines, etc, etc since this configuration is not part of the configuration file. Most features such as barge, intercom, paging, etc are not supported. However hardware conferencing and hunt groups are supported with this option.

Given the choice I would suggest you want the highest degree of flexibility when deciding which SRST option to use- and this option should be avoided unless you have been directed to configure the SRST gateway ensuring that learned ephones and learned ephone-dn’s do not show in the running config.

Option (3): telephony-service & srst mode auto-provision dn

This is the same as option (2) except the ephone-dn configuration is going to show up in the running configuration. So this is a useful option when you need per DN customization. Two examples of why you would want to change the DN and not the phone are (a) calling name (which is not part of the configuration file) and (b) support of different call-forwarding destinations based on DN.

Again- this option does not give you the highest degree of flexibilty (in terms of feature support) and is not preferred unless you have been directed to configure the SRST gateway ensuring that learned ephone configuration does not show up in the running configuration.

Option (4): telephony-service & srst mode auto-provision all

Definitely the most preferred and flexible option. All features that are supported inside CME are supported- such as pickup, barge, intercom, paging, etc, etc. You can tweak the ephone and ephone-dn configuration as much as you want. Use this option if there are no restrictions. The negative aspect of this option is that you have the overhead of having static ephone configuration within the IOS . So once the phone has registered to the SRST gateway that cofiguration is saved within IOS. If you change the user’s phone you would need to change the ephone configuration inside the gateway (on top of the UCM changes that are required). This overhead is not really a factor in an 8 hour lab exam.

Vik Malhi- CCIE 13890
Instructor – IPexpert, Inc.

Print Friendly

This is the third and final part of the series of blogs covering all aspects of QoS related to the Catalyst 3750. (Part 1 covered classification and marking and  Part 2 covered Ingress queueing).

In this article we will focus on Egress Queuing, Dropping and Scheduling. Whereas on the ingress side traffic is being placed onto the backplane of the switch (ring), on the egress side traffic is being sent to the destination or egress port.

Congestion can occur when multiple devices (ingress ports) are sending data to a single device (egress port). Congestion on the egress side is much more of an issue when compared with ingress congestion.

Congestion management and avoidance on the egress side has three distinct phases- (1) queueing, (2) dropping and (3) scheduling/dequeuing.

Egress Queuing

The first step on the egress side of the switch is to map each frame to one of 4 egress queues and assign a threshold value that is used by Weighted Tail Drop (WTD). We’ll talk about WTD in a little while but for now just consider that each frame is placed in Q1 thru Q4 based on DSCP or COS depending on the QoS label. “QoS label”- what’s this? At the ingress switchport we can either trust/set layer 2 or layer 3 markings using “mls qos trust cos” or “mls qos trust dscp” at the ingress port or alternatively a service-policy. This marking is then copied across internally within the switch and forms the QoS label. This is used for all future QoS-related actions on the frame whilst inside the switch. This includes deciding which queue/threshold the frame is placed into on both the ingress and egress side.

To find out which queue each type of traffic is utilizing use one of the following two commands:

As mentioned earlier there are 4 queues on the egress side. The sizes of the queues (the percentage of the per port buffer space allocated to each queue) are defined within the queue set. An interface can belong to either queue set 1 or 2. The default is queue set 1. The queue set allows you to configure the egress queuing parameters using an additional layer of granularity than doing so in global configuration. An egress port to another switch or router may require a different set of properties to, say, an egress port connected to a phone or computer. Let’s take a look at how the buffer space is allocated once AutoQoS has been configured on one of the interfaces on the switch.

By default all interfaces belong to queue set 1- if we wanted an egress port to have the buffer spaces between Q1-4 allocated 16%:6%:17%:61 then we should configure the port with queue-set 2 as shown below:

You are able to modify the buffer sizes of the queues by changing the parameters in the queue set- below is an example of queue set 1 being modified so that all of the queues are of equal size.

Weighted Tail Drop on the Egress side

Like the buffer space allocation, the WTD percentages are defined within the queue set and an interface belongs to either queue set 1 or 2. WTD provides a way to begin dropping lower priority traffic ahead of higher priority traffic in the event that a particular queue is becoming increasingly utilized.

The idea of WTD is to decrease the chance of a specific queue from becoming congested. Let’s take an example whereby both DSCP 0 and DSCP 8 are being placed into egress queue 4. Our ordinary traffic (best effort) is being marked with DSCP 0 and our scavenger class traffic is being marked with DSCP 8. Rather than wait for Q4 to become completely full (no more buffers available for Q4) and then indiscriminately drop both traffic types, we are able to begin dropping frames that have QoS label DSCP 8 much sooner than we begin dropping frames with QoS label DSCP 0. This helps us since our worst type of traffic will not be responsible for causing the congestion for a particular queue.

All traffic is mapped to Queue x and Threshold y where x = 1, 2, 3 or 4 and y = 1, 2 or 3. Take a look at the example below (these tables are the actual tables having run AutoQos):

You can see that DSCP 0 is being mapped to Q4T3 and DSCP 8 is being mapped to Q4T1.

Let’s take a look at the parameters of Q4 that are applied to queue set 1.

First of all Q4 has 54% of the port buffer space allocated to it. Of that 54% only 67% has been reserved. So in reality we are only reserving two thirds of the buffers that we could have done for Q4. The other one third is our tax. This is our contribution to the “common pool” which the switch can assign to any other queue on any other port if needed. Queue 4 will be considered full when 67% of the allocated queue memory is being used (the terms buffer and memory are interchangeable). So to summarize this paragraph: allocated memory = 54% of interface memory and we are only reserving 67% of this for Q4.

Q4T1 is configured at 20% which means that when memory or buffer utilization of Q4 has reached 20% of the allocated queue memory/buffer (54% of the total memory for this port) we will begin dropping packets that are being mapped to Q4T1.

Q4T2 is configured at 50%- when Q4 has reached 50% of the allocated queue memory/buffer utilization we will begin dropping packets that are being mapped to Q4T2.

When do we start dropping packets that are being mapped to Q4T3? We are reserving 67% of the memory that has been allocated for Q4 but we are saying that the maximum memory that this queue can have is 400%- above and beyond our reserved 67% we would need to ask the taxman for some temporary funds to stave of the threat of a packet being discarded. In other words when Q4 has reached 100% of it’s memory utilization (67% of 54% of the total) Q4 will try and grab unallocated memory from the common pool (up to 400% of the allocated memory for the queue). If there is enough memory in the common pool then all is well and good and the packet is not discarded. If however there is no spare memory in the common pool then the packet will be discarded.

Confused? You are not alone. Let’s look at WTD without using the common pool buffer. Look at the table below and we have made some changes. You are going to feel a whole lot better (I gave you the bad news first).

Q4 has 25% of the buffers allocated to it. We are reserving all of the buffer allocation and paying nothing to the taxman (common pool). Now that I mention it, this would be nice in the real world too!! We are setting the maximum memory to 100% which means that we will not attempt to grab any memory from the common pool once we are in the queue-full state. If our reserved/allocated memory is being utilized then we will drop the packet as opposed to attempt to grab some of the unreserved / common pool buffers.

Traffic being mapped to Q4T1 will be placed into Q4 so long as the buffer is not already 50% full.

Traffic being mapped to Q4T2 will be placed into Q4 so long as the buffer is not already 75% full.

Traffic being mapped to Q4T3 will be placed into Q4 so long as the buffer is not already completely full. And by full we mean our share of the total port memory (25%).

Egress Scheduling: 1P3Q3T or 4Q3T

The scheduler determines the algorithm of how the switch removes traffic from the 4 queues. The total amount of bandwidth being sent to the egress port is the aggregate of the quantity of traffic removed from each of the 4 queues. Whereas WTD can be categorized as a congestion avoidance mechanism (we do our best to stop lesser packets from filling up our queues), scheduling can be categorized as managing the congestion within the queues. Once a packet has made it into one of the 4 queues, the threshold value has no significance.

Unlike the buffers and threshold settings, the properties of the scheduler are defined within each interface (as opposed to the queue set). Like the ingress scheduler, SRR is used- the difference is that the “S” can stand for shaped as well as shared. In shaped mode, the egress queues are guaranteed a percentage of the bandwidth and they are rate-limited to that amount. Shaped traffic does not use more than the allocated bandwidth even if the link is idle. In shared mode, the queues share the bandwidth among them according to the configured weights. The bandwidth is guaranteed at this level but not limited to it. For example, if a queue is empty and no longer requires a share of the link, the remaining queues can expand into the unused bandwidth and share it among them.

Let’s take a look at a few examples. Once mls qos has been enabled on the switch the output below shows the default egress scheduler implementation for each interface.

First of all the Priority Queue is disabled- we will talk about this later but for now the significance of the PQ being disabled is that the SRR values for Q1 come into play. If there is zero “shaped” value configured for a particular queue then the “shared” value will be applicable for that particular queue. So by looking at the output above Q1 is shaped to 25 and queues 2-4 are shared at a value of 25. We discount the share value of Q1 since Q1 has been configured with a non-zero shape value.

The meaning of the “25” being applied to Q1 is very different to the “25” being applied to Q2, Q3 and Q4. In shaped mode the value is absolute which means that it is in effect a percentage and the values for Q2, Q3 and Q4 make no difference to how much bandwidth Q1 is being shaped to. Now onto one of the more common mistakes- the “shape 25 0 0 0” means that Q1 is shaped to 4% of the egress port bandwidth (4Mbps for a 100Mbps interface) since the 25 is an inverse ratio (1/25).

The “share 25 25 25 25” should be read as “share xx 25 25 25” since the Q1 share value is not used. The 25 assigned to Q2-4 is in this case a weight as opposed to an absolute value. In other words it is the relative and not the independent value that is meaningful. So each of queues 2, 3 and 4 have a minimum of 25/(25+25+25) of the remaining (96%) bandwidth. In other words Q2, Q3 and Q4 each have a third of the bandwidth not being assigned to Q1. In this situation “share 1 33 33 33” may make the configuration more readable.

A couple of clarifications- if Q1 is idle then the 4% being assigned to Q1 can be used by another queue if needed. If Q1 is becoming over-subscribed and the other 3 queues are empty then Q1 cannot be allocated bandwidth that has been assigned to one of the other queues since it is being rate-limited or shaped to 4%. Contrast this with the other queues that are all operating in shared mode. If Q2 is becoming over-subscribed and the other 3 queues are empty then Q2 can be allocated 100% of the egress port bandwidth since the “share” only specifies a minimum bandwidth guarantee.

Let’s take a look at the egress scheduler when AutoQos has been configured on an interface:

Once the Priority Queue has been enabled on an interface then the SRR shape and share values for Q1 are irrelevant. The scheduler will service the PQ until it is empty. Once the PQ has been completely serviced then Q2-4 will be serviced. Q1 is always the PQ on this platform (Q4 for the 3550).

The “shape 25 0 0 0” has no significance since Q1 has the PQ enabled and hence the “25” being allocated to Q1 is not used. This is an important point-  there is no rate-limiting of the Priority Queue taking place! If you wanted to rate limit Q1 to a specific value then you must disable the priority queue. If you have the PQ enabled then you may want to make your config more readable by setting the shape value of Q1 to 0.

The “share 10 10 60 20” defines the weights assigned for Q2-4. The “10” assigned for Q1 has no meaning since the PQ is enabled for this interface. So Q2 thru 4 have the bandwidth split 10/(10+60+20):60/(10+60+20):20/(10+60+20) or 1/9^th:6/9^th:2/9^th for Q2:Q3:Q4 respectively. It might be wise to make the values of Q2-4 add up to 100 since now you will now be dealing in effect with percentages and make the value for Q1 equal to “1” since the PQ is being used (you cannot set a share value to zero).

Finally- you are also able to limit the bandwidth of an individual egress port as shown below:

When you configure this command to 85 percent, the port is idle 15 percent of the time. The line rate drops to 85 percent of the connected speed, which is 85 Mb/s for our 100Mbps interfaces.

Phew- that’s about it regarding the Catalayst 3750 QoS features. Sorry it took me so long to get the series completed but better late than never. Good luck with your studies!

Vik Malhi

Instructor, IPexpert Inc

Print Friendly

This is the second posting that discusses the QoS aspects of the Catalyst 3750- the first part can be found here: “Campus QoS- part 1- classification and marking on the Catalyst 3750”.

In this article we will focus on Ingress Queuing and Scheduling. Congestion on the ingress side of the switch is far less likely to occur than on the egress side since the throughput of the internal ring of the switch is likely to be far greater than the aggregate rate at which traffic is being received. 

Nonetheless, ingress queuing and scheduling could be a factor in specific instances where there are speed mismatches and also at points of aggregation in the distribution and core layer.

COS/DSCP Queue Maps

The first step post classification and marking is mapping incoming traffic to specific queues. There are two queues on the ingress side (versus 4 on the egress). This mapping is done based on the layer 2 (COS) or layer 3 (IPP or DSCP) marking. When mls qos has been enabled on the switch the following map tables are used to determine which traffic is placed into which ingress queue.

Which input-q mapping is used depends on whether the layer 2 or layer 3 marking of the incoming traffic has been trusted (or marked by the switch in the service-policy). If you have used “mls qos trust cos” on the receiving interface then the cos-input-q table is used. In all likelihood the layer 2 and layer 3 map tables should be equivalent. Whenever layer 2 is trusted, the layer 3 is built from the layer 2 using cos-dscp-map tables as shown below:

It therefore makes sense (in this instance) that COS 0, 1, 2, 3, 4, 5, 6, 7 input-q maps should mimic DSCP 0, 8, 16, 24, 32, 40, 48, 56.

Whilst on the subject of cos-dscp maps, let’s take a look at what the AutoQos macro does for us.

Having issued the above command within one or more interfaces, we will take another look at the cos-input-q, dscp-input-q and cos-dscp map tables.

By looking above the first thing to point out is that COS 5 no longer maps to DSCP CS5 but rather EF (46). I would expect COS 5 input-q and DSCP 46 input-q maps to be equivalent.

Looking at the cos-input-q maps above we can see COS 3 (our VOIP control) and COS 5 (Real Time Media) maps to Q2 Threshold profile 3 (Q2T3). This is indeed reflected in the dscp-input-q maps (VOIP control is CS3 and VOIP media is EF or in decimal 24/46).

Weighted Tail Drop

Before talking about the threshold values, let’s take a quick look at the properties of the two queues on the ingress side. The default buffer size, thresholds and bandwidth (we’ll come to thresholds and bandwidth in a second so for the time being let’s focus on buffer size) is shown below:

The buffers that are allocated to each interface are divided 90:10 between Q1:Q2. In other words Q1 is a lot bigger than Q2! This makes sense since by default the vast majority of our traffic is placed into Q1.

When AutoQoS has been run let’s take a look at how this changes:

We can see the buffers are divided up two thirds: one third. More traffic utilizes Q2 when AutoQoS has been invoked.

Up to now we have shown certain types of traffic are placed into Q1 and certain types of traffic are placed into Q2. In the context of VOIP, our control and media traffic is placed into Q2. This mapping of traffic into specific queues is either based on layer 2 or 3 markings depending on what was used during classification and marking. We have also shown the sizes of the two queues can be manipulated.

Upon closed inspection you can see in the dscp/cos-input-q maps that we assign specific COS/DSCP values a Queue # as well as a Threshold #. The Threshold is the percentage of how full a particular queue is. When we assign a COS/DSCP value to a Q#T# we are saying that the frame will only be placed into the Q so long as it is not already occupied up to a certain percentage, This certain percentage is what T# is.

So for example, going back to dscp-input-q maps from earlier (after AutoQoS has done its magic):

You can see that incoming traffic marked with DSCP value CS1 (8) which is typically used for Scavenger class traffic (such as Microsoft Automatic updates;) is going to be placed into input Q1 so long as Q1 is not full beyond what Threshold 1 is set to.

Threshold 1 has been set to 8 percent. So incoming traffic with DSCP 8 will be placed into Q1 so long as Q1 is not more than 8% full. Whilst Q1 is 8% full (or more) then all frames with DSCP 8 (on this receiving interface) will be dropped.

Compare this with DSCP 0 which is placed into Q1T3.  T3 is not configurable and is an implicit 100%. This means that incoming traffic with DSCP 0 will be placed into Q1 unless it is totally full. And remember Q1 is (post AutoQoS) assigned 67% of the buffers.

So you can see that even though DSCP 0 and DSCP 8 are both being placed into input Q1, DSCP 0 traffic (Best Effort) has more importance since this type of traffic can be buffered should there be a congested shared bus. Contrast this with our Scavenger class traffic which can only be buffered up to a certain point (8% of the 67% allocated to Q1) before it is dropped. This is done so that our Scavenger class traffic cannot be the cause of congestion- aka congestion avoidance.

Scheduling

The last thing we are going to talk about is the algorithm for de-queuing which is otherwise known as scheduling. In the context of the input side of the switch, bandwidth represents the amount of traffic we can place onto the internal ring of the switch. This is finite. If both Q1 and Q2 are occupied then the composition of the traffic that is taken from Q1 and Q2 and placed onto the ring is subject to the configuration of the shared round robin scheduler. In the example below 90% of the traffic being placed onto the ring is taken from Q1 and 10% is taken from Q2 (with a small caveat to follow!). So let’s just make up some numbers and say that during every transmit interval we are able to place 1000 Ethernet frames onto the ring and both Q1 and Q2 are non-idle to the point where there are more than 1000 Ethernet frames in both queues, then 900 frames will be taken from Q1 and 100 frames will be taken from Q2. The bandwidth 90:10 is actually a weight not a percentage but since 90+10 = 100 it is in effect become a percentage. However we could have coinfigured 9:1 or 18:2, etc, etc to achieve the same thing.

The significance of shared round robin is important to understand- shared implies that if a particular queue does not require the configured bandwidth then this bandwidth can be released and shared by other queues. Going back to our earlier example- if Q1 is idle and Q2 has more than 1000 frames, then the SRR scheduler will apportion the bandwidth that has been assigned to Q1 to Q2 and thus Q2 receives 100% of the bandwidth. You can think of shared round robin as defining a minimum bandwidth guarantee when all queues are congested. However, unlike it’s sibling shaped round robin (used on the egress side), there is no maximum bandwidth defined using shared round robin. The maximum is 100% of the interface bandwidth.

Back to the caveat mentioned in the above discussion. Notice the following line that is highlighted below:

There is an additional consideration when considering ingress bandwidth. 10% of the bandwidth has been assigned as priority bandwidth to Q2 and the remaining 90% is shared according to the weighting defined above (90:10). So back to our example: 1000 frames every transmit interval- 10% comes from Q2 (100 frames). This is guaranteed to be placed onto the ring even if the ring is over-subscribed. That is what we mean by priority bandwidth (as opposed to a strict priority queue which we will talk about on the egress side). The remainder of the bandwidth that is placed onto the ring is not guaranteed and will be buffered in the queues should the ring be congested. This non-priority bandwidth is split according to the weighting 90:10. So the amount of traffic taken from Q2 is 10% of 1000 frames + 10% of 900 frames = 190 frames. The amount of traffic taken from Q1 is 90% of 900 frames = 810 frames. It should be mentioned again that all bandwidth can be shared if a particular queue is idle- this is not affected by the priority bandwidth.

Only one queue can be assigned up to 40% of ingress priority bandwidth- the default is 10% to Q2. This can be changed- in the example below we are assigned 40% to Q1.

That’s about it for now- look out for part 3 which will talk about egress queuing and scheduling.

Vik Malhi
Instructor, IPexpert Inc

Print Friendly

Documentation

The first thing to point out is where to find information. There are two documents that I would like to reference- the Catalyst 3750 Configuration guide and the Catalyst 3750 configuration example (document 91862) which can be found here and are available to you in the lab.

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_44_se/configuration/guide/swqos.html

http://www.cisco.com/en/US/products/hw/switches/ps5023/products_tech_note09186a0080883f9e.shtml

Incidentally the 3750 and 3560 are identical from a QoS perspective- the 3750 does contain Cisco Stackwise technology which allows for up to 9 switches to function as a single logical unit but this is largely irrelevant given the scope of our discussion.

Overview of QoS Features

The software-based QoS features are summarized in the picture below.

We have QoS features (classification/marking, WTD, queuing and scheduling) on the ingress side that ultimately determine the makeup of the traffic that is placed onto the shared bus or internal ring of the switch. We also have a similar set of QoS features on the egress side (without the classification and marking). The QoS features on the egress side are much more important since the likelihood of the link to the endpoint connected to the egress interface becoming over-subscribed is far greater than the likelihood of the shared bus (32Gbps bandwidth) becoming over-subscribed.

In this particular blog we will focus on Classification and Marking- subsequent blogs released on this site will deal with the other QoS features on the Catalyst 3750.

Classification & Marking

By default, when multilayer switching has not been enabled on the Catalyst 3750, the incoming layer 2 and layer 3 markings (COS, DSCP) are honored- in effect the port is trusted. For example, a router receiving traffic originating from an IP Phone connected to the Catalyst 3750 will see DSCP set to 46/24 for RTP and SCCP/SIP traffic respectively.

When “mls qos” has been enabled the opposite is true- all markings are set to Best Effort. The DSCP and COS value for all traffic is set to 0. The output shows the default COS- the DSCP is derived from the COS in this instance.

You are able to change the default COS value per interface using the commands below:

In this case the port is not trusted but all traffic is marked with a value of COS 5.

The DSCP for all traffic originating from Fastethernet 1/0/23 will now be marked to DSCP 46 as the COS-DSCP map tables will determine the markings in the Layer 3 header.

You can trust the Layer 2 markings (COS) as shown below:

This is only going to be effective for 801.1Q trunks since the COS (802.1p) is an extension of 802.1Q which is used for VLAN tagging. It would be effective for phone ports which use the command “switchport voice vlan xx” since this is a pseudo-trunk in that the 802.1Q (and 802.1p) extension is used specifically for phone traffic (on vlan xx).

Trusting layer 2 is not the correct strategy for access ports and for 802.1Q trunks between a WAN router and a switch (traffic coming in from the WAN does not contain the COS since typically Layer 2 is different over the WAN e.g. Frame Relay). In this instance trusting the layer 3 is the way forward- configuration shown below:

Which trust option you have used will affect other QoS features of the Catalyst 3750. Mapping traffic to the appropriate queue (for ingress and egress) will be dependent on whether the frame’s QoS label was set at layer 2 (trust cos) or layer 3 (trust dscp). If an interface has been configured with the command “mls qos trust cos” then all traffic originating from this specific port will be placed into ingress and egress queues based on Layer 2 (cos-input-q and cos-output-q). Similarly if an interface has been configured with the command “mls qos trust dscp” then all traffic originating from this specific port will be placed into ingress and egress queues based on Layer 3 (dscp-input-q and dscp-output-q). Queuing will be discussed in further detail in a subsequent blog.

An additional command that can run in tandem with either “mls qos trust cos” or “mls qos trust dscp” is the “mls qos trust device cisco-phone” command which sets a conditional trust boundary on a specific interface. In other words the Layer 2 or Layer 3 setting for the particular interface will only be trusted if the endpoint connected directly into the switchport is a Cisco IP Phone (discovered using CDPv2 or LLDP-Med).

Rather than rely on the endpoint connected to the switch for marking L2/L3, it is possible to use MQC on the actual switch for this purpose. In other words, rather than trust cos/dscp, you have the option to use a service-policy in tandem with ACL or some other classification mechanism. Service-policy’s can only be applied for incoming traffic- traffic being received on an interface as opposed to traffic being sent to an interface.

Before discussing MQC as a tool for classification and marking, let’s take a look at what happens when you run AutoQos.

When auto qos voip cisco-phone has been configured on a specific interface, QoS is enabled and a bunch of QoS-related commands (deemed to be best-practice) are configured on the switch. Specifically you will see the following configuration within the interface that was configured with the autoqos command:

By looking at the interface you can see that the policy-map “AutoQoS-Police-CiscoPhone” is applied to all traffic being received from the endpoint connected to Fa1/0/2. Upon closer inspection you can see that traffic with DSCP 46 (RTP) and DSCP 24 or 26 (SCCP/SIP) is being policed:

The AutoQoS macro classifies RTP and Control traffic based on the incoming DSCP value from the endpoint (a phone in this case). Notice that for Control traffic we are matching on the old (af31) as well as the newer DSCP value (cs3) that control traffic should use as per the QoS baseline. This has to be done within a single match statement- multiple match statements within a class is not allowed.

Within the policy-map we must either trust or set the layer 2 or 3 markings otherwise the default DSCP/COS (0) will be used. AutoQoS uses “set dscp ef” for the RTP class but “trust dscp” would be equivalent in this case since the incoming DSCP is already ef. As well as MQC-based marking, the policy-map is used for policing RTP and Control traffic to 320k and 32k respectively. Any traffic that is in excess of these thresholds are remarked to DSCP 0 as per the command below (AutoQoS default command shown):

Finally let’s go back and take a look at what AutoQoS did within the interface again:

Notice above that we are trusting DSCP as well as applying a service-policy within the same interface. Well- given that we are also writing / trusting DSCP within MQC, which one out of the trust and service-policy takes effect? The answer is for traffic that matches a particular class-map then the service-policy wins every time. For traffic that does not match a particular class-map then the trust setting takes effect (which assumes there is no class class-default within the policy-map). Based on these facts, it is clear that the “trust dscp” within interface Fa1/0/23 is indeed redundant for RTP and Control traffic since these types of traffic will match classes within the attached policy-map. It is probably simper to use trust or service-policy but not both.

MQC also has the flexibility to classify based on ACL (as opposed to incoming Layer 3 markings). For example in the configuration below we are policing web traffic from a server connected to Fa1/0/4 to 500k.

Anyhow- enough about classification and marking, please lookout for blogs on the other QoS features available on the Catalyst 3750 over the next few days/weeks.

Vik Malhi,
Instructor – IPexpert, Inc.

Print Friendly

Assuming the worst case scenario whereby the CUE module contains  unwanted prior configuration and possibly an incorrect license, you should look into tackling the set up of the CUE module in between gaps in time such as those experienced when  restarting services, reloading gateways, fixing database replication issues, etc, etc. Addressing the CUE module sooner rather than later is going to ease the time pressures that you will most certainly feel during the second half of the big day.

As a suggestion you could begin configuration of CUE once you have completed the configuration of the gateway that houses the CUE module. This will most probably be during the first couple of hours. Initial steps involve configuring network connectivity for the integrated-service-engine as shown below:

interface integrated-service-engine 1/0

ip unnumbered Vlan400

service-module ip address 10.10.202.2 255.255.255.0

service-module ip default-gateway 10.10.202.1

no shut

!

ip route 10.10.202.2 255.255.255.255 integrated-service-engine1/0

Session into the CUE at some point in the next hour and verify the license (I’m assuming here that the module is already configured with previous configuration).

site-c-gw# service-module integrated-service-engine 1/0 session

cue# sh soft license

Installed license files:

-        Application mode: CCME

If you need to change the license (the above example shows a CME license installed) then now is the time to FTP the license to the CUE module and restore factory defaults.

cue# software install clean url ftp://<FTP-SERVER>/ccm-license.pkg user joe passw blow

cue# offline                  ! confirmation required (not shown)

cue# restore factory default

cue# reload

At this moment in time you can check back in 5-10 minutes and hopefully your CUE module will show a message prompting you to begin the command line initialization wizard. If you have enough information it is wise to complete the CLI wizard (since this involves yet another reload). You will need details of the NTP server, timezone, DNS server and administrator username/password in order to complete the initialization.

You can now rest assured that you will no longer have the pain of performing these rudimentary steps when the time comes for you to complete the voicemail section (which maybe you are not ready to perform at this early stage).

In summary- try and get the CUE module cleaned up with full network connectivity before lunch. I’ve heard of many stories of candidates not being able to complete the voicemail tasks due to the incessant rebooting that comes with the territory. There is still a strong possibility of yet another reload by the way (especially for CTI integration with UCM) but at least the burden has been eased with some forward planning.

Vik Malhi – CCIE #13890
Managing Partner / Instructor – IPexpert, Inc.
Mailto: vmalhi@ipexpert.com

Print Friendly

PhoneView is the hottest IP telephone remote control and estate management tool on the market today. Currently managing CISCO sites of up to 30,000 phones and proven in global enterprise environments, it is a vital tool for IP telephony management functions, professionals and students.

This special lab edition of the PhoneView application is specifically designed for (but not restricted to) students preparing for the CCIE Voice lab exam.

Candidates studying for the CCIE Voice that do not own their own hardware have historically used Proctor Labs rack rental sessions to gain the hands-on experience necessary to adequately prepare for the grueling CCIE Voice lab exam.

More than 500 engineers who have cleared the CCIE Voice exam have prepared in this way with Proctor Labs.

Typically candidates use physical phones that connect to the remote racks via EzVPN through a supported router. The PhoneView application will enhance the end user experience since the Cisco 7962 and 7960 phones that are located in the Proctor Labs racks can be remotely controlled via the PhoneView application. This can either reduce (or potentially eliminate) the need for customers to invest in the out of date 79XX phones that are required to study for the lab.

A single instance of PhoneView software can be used to manage multiple phones connected to multiple clusters. Multiple instances of software and/or multiple windows/tabs are not necessary each time one wishes to remotely manage a new device. This makes the PhoneView software much more scalable and usable to solve real world problems. Proctor Labs customers will be able to see all of their CUCM and CUCME devices (both SIP and SCCP also applicable for SRST) in a single window. Currently users are not able to hear the audio when calling into applications such as Voicemail or Contact Center but this capability is just around the corner!

The ability to create macro’s to perform certain keystrokes is a great time saving tool and will make your testing of certain services / features much more efficient. For example the user can create a macro to enter the Received Calls Log of one of the 7962 phones housed in Proctor Labs, for example, to check for the globalized / + number). Therefore this can be done with one command as opposed to having to press directories, wait for refresh, scroll down to received calls, wait for refresh, select received calls and wait for another refresh.

The application can be used to control phones connected to all versions of CUCM including the most recent version (CUCM 8.5) as well as all versions of CUCME. PhoneView also supports all of the latest IP Phone models such as the 69xx, 89xx & 99xx range and is compatible with Windows XP, Vista and Windows 7.

For a brief demo video on how you can use Phoneview in the Proctor Labs environment please click here: https://proctorlabs.com/swf/demo/PLDemo.html

To get your free full function lab copy of PhoneView go to:

http://www.unifiedfx.com/IPExpert

Vik Malhi – CCIE #13890
Managing Partner / Instructor – IPexpert, Inc.

Print Friendly

I would like to start off by mentioning a couple of important points to existing CCIE’s who already possess their number in different track- you cannot copy the same formula that served you so well in yesteryear. You will have to prepare slightly differently for this particular beast. The Voice lab is (in the main) a group of silo’s and contains a series of non-overlapping topics. We can’t redistribute Unity Express into Contact Center for example. The next point is that the documentation is more dispersed and not as informative in comparison to the IOS Configuration Guide and other related documentation that is useful in most of the other tracks. I think for this reason the value of hands-on lab practice cannot be overstated. Being book-smart will only carry you so far.

Before giving you a few ideas on how to go about organizing your time in the preceding months, I’m going to make some base assumptions because ultimately all candidates’ circumstances are different. If at all possible you should consider discarding all forms of employment and family:-) I’m guessing that in most cases this is not at all possible. This leads me into stating something obvious that is often overlooked – BE REALISTIC!  Being realistic might mean you have no more than 15 hours per week to dedicate to this pursuit. Well- if I’m speaking to you right now then organization and efficiency is even more important since your study time is at a premium.

Try and get some lab gear together from your employer or purchase what is affordable from sites such as Ebay. Remember you do not need to mimic  the full CCIE Voice rack. For the bits you are missing you can use rack rental sessions. For example you may not need a Contact Center and/or Presence Server or Unity Express module if it is difficult to obtain- that’s ok. You can learn almost everything you require in these areas during 5 or 6 rack sessions  and this might be the more economical way. Some people choose to solely use rack rental sessions – the advantage here is that you don’t waste time acquiring and proctoring a rack and you are able to devote every hour of your practice time to what counts.

When beginning your preparation for the CCIE Voice Lab you should consider taking a modular approach to your new way of life. Don’t spend time doing full 8 hour mock labs early on. If you do this you will end up spending a small amount of time in many topics. It’s better that you spend more time on fewer topics initially. Week 1 might entail working on Infrastructure and phone registration (in other words DHCP, VLAN, NTP, TFTP and UCM/CME phone registration). Now you don’t need to be on a router and/or switch to be actively studying. Go through the Infrastructure section from as many labs as possible and consider all permutations. Take notes- make checklists of things to watch out for and focus on troubleshooting steps to take if things do not go according to plan. Spend time looking at walk through videos of solutions since you will benefit from an instructor making silly mistakes and useful verification steps that only hands-on experience can give you. Looking ahead through as much material as possible from the beginning is a good thing! You do not need to “save the labs” for the element of surprise- take a look as much material as possible. Diversity is key! Always persevere with your own scenarios- you should continuously be asking yourself “what is the impact if I change this command to be xyz”.

Below is a example of what I hope is a realistic study plan to take a candidate that has a job and a family life (which will temporarily diminish but not to the extent that it is permanent) to the point of passing the CCIE Voice Lab. In this study plan I am proposing that you spend 3 hours on 3 different week days going through the relevant sections of the Video On Demand, Walk Thru Solutions and Workbook Labs and Detailed Solutions Guide for specific topics each week. At the weekend I am suggesting you spend one day going through the selected topics from a chosen lab either in our Volume 1 (or even Volume 2) Workbook. It doesn’t matter if you have already looked at the lab beforehand- in fact it is probably better that you do so because you don’t want to spend your premium hours at the weekend getting stuck on one problem when time is so scarce. I am allocating 12 hours on one day at the weekend- this might be divided up as 2 hours prep time, 8 hours lab time and further hours review time. With this plan you get one day free at the weekend – I warn you that this day maybe the toughest day given the amount of tasks your spouse has in store for you!

It is important that you complement everything you do with some bed time reading of the necessary SRNDs and other useful documentation (such as the CME Admin Guide, UCM Features and Services Guide, UCM System Guide, Catalyst 3750 Software Configuration Guide- QOS Section). You can do this in your days marked as “OFF” or at work (ssshh!). Remember that you are not alone in this pursuit- gain the advantage of other candidates’ experiences and thoughts from the mailing list which you can subscribe to at www.OnlineStudyList.com.

Remember the aim of what I have proposed is to give you ideas on how to create a realistic study plan. The optimum is to spend 12 hours a day everyday preparing for the lab but most people are not in this position. If you are then edit the study plan and it may take you 12 weeks and not the 22 shown above. Conversely, if you think that this plan is unachievable then it might mean you are looking at 30 weeks.

One final point to reiterate before I depart- don’t hide material from yourself in the name of preserving an unknown lab on which to practice. I understand why you would want to do this but you really need to appreciate as many different permutations as possible as early as possible. Don’t worry- the lab has enough challenge and I promise that you will not find it easy at any point. If it was you wouldn’t be here.

Vik Malhi, Managing Partner of IPexpert Inc

Print Friendly

Before talking about the tools that can be used to monitor the activity on the CUC ports it is important to remember where the logic of how CUC will treat an incoming call is defined.

When a call arrives into the CUC server on a registered port then one of two Call Routing Rule tables are used to determine how to handle the call. If the incoming call does not contain a Redirecting Number then the “Direct  Routing Rule” table is used. If the incoming call does contain a Redirecting Number then this means that CUCM forwarded the call into the CUC server and hence the “Forwarded Routing Rules” table is used.

Upon closer inspection of the Direct Routing Rules table, we can see that there are two pre-defined rules. The “Attempt Sign In” rule is used if the Calling Number is recognized by CUC as a known Subscriber or Call Handler DN in which case the prompt to enter a PIN is typically played back to the caller. If the Calling Number is unknown to CUC then the “Opening Greeting” rule is invoked and the caller is transferred to the Opening Greeting Call Handler. Subsequent management of the call is determined by the Transfer Rules configured for the Opening Greeting Call Handler.

It is important to note that Routing Rules are processed top-down and therefore it makes sense that the more specific Routing Rules are placed at the top of the table (similar to an ACL). A CUC administrator would add to the pre-defined Routing rules to trigger specific Call Handlers or features such as Live Record when specific Calling or Forwarding numbers have been match (Port and schedule can also be used as criteria when dictating how CUC will handle an incoming call).

When troubleshooting CUC it is important that you are able to determine the Calling/Redirecting number of the incoming call and what procedure within CUC is triggered based on that information. You have two highly useful tools as options- Remote Port Status Monitor (rPSM) and the RTMT Port Monitor. The former is not natively a supported application when installing CUC 7.x whereas RTMT is.

The Remote Port Status Monitor (rPSM) tool  offers a comprehensive view of exactly what information has been received by CUC and what action CUC is performing as defined by the Call Routing rules. For example a user calling into the pilot of CUC (which is considered a direct call since there is no redirecting number) should invoke the pre-defined call routing rule  called “Attempt Sign-in”.

CUC does not allow this tool to be used unless the it is enabled and the IP Address of the client machine running rPSM is entered as shown below.

When launching the tool from the client machine you are prompted to enter the IP Address of the CUC server. From the Options menu you can select the View Raw Port output option (you can also log all output to flle). Below is a snippet taken from the tool.

The information below shows amongst other things the port the call arrived on, the Calling/Called number. Note there is a lack of a Redirecting number and hence the Direct Routing rules are invoked.

CallData, 2, CallerId=5002, CalledId=5600, RedirectingId=, Origin=16, Reason=1,
CallGuid=BA0378455D7D47F8B62DB2FC0105ED8B, CallerName=, LastRedirectingId=, 
LastRedirectingReason=1024, PortDisplayName=PhoneSystem-PG-001

The AttemptSignIn rule has been triggered.

 Application, 2, 5002, AttemptSignIn

The Calling Number has been recognized as a known extension.

Application, 2, 5002, SubSignIn

The caller is prompted to authenticate.

 Application, 2, 5002, -->SubAuthenticate
 Application, 2, 5002, -->SubAuthenticatePW

Authentication succeeded.

Display, 2, 5002, Subscriber sign-in successful. Alias - hqphn2.
Extension - 5002. Caller Id - 5002.

In the example below the tool can be used to spot an incorrect Calling number being sent to CUC due to the “use Calling Party External Number Mask” option being selected on the Hunt Pilot used to access the voicemail server. In this case “AttemptSignIn” does not return any matching extension and the next Direct Routing rule (transfer to Opening Greeting Call Handler) is processed.

CallData, 2, CallerId=+12123945002, CalledId=5600, RedirectingId=, Origin=16, Reason=1,
CallGuid=C5BD986297274AF1BE52BD210151A574, CallerName=, LastRedirectingId=,
LastRedirectingReason=1024, PortDisplayName=PhoneSystem-PG-001

Application, 2, +12123945002, AttemptSignIn
State, 2, +12123945002, State - AttemptSignIn.cde!Dummy
State, 2, +12123945002, Event is [NULL]
Application, 2, +12123945002, PHTransfer
State, 2, +12123945002, State - PHTransfer.cde!LoadInfo
State, 2, +12123945002, Event is [TrueEvent]
Application, 2, +12123945002, PHGreeting
State, 2, +12123945002, State - PHGreeting.cde!PlayGreeting
Display, 2, +12123945002, Call answered if needed
Display, 2, +12123945002, Playing greeting for Call Handler:  Opening Greeting

You can find further information on rPSM here: http://www.ciscounitytools.com/Applications/CxN/PortStatusMonitorCUC7x/Help/Connection%20Remote%20Port%20Status
%20Monitor.html

The next tool that can be used to troubleshoot the activity on the CUC ports is the RTMT Port Monitor. If you do not already have this installed then it can be downloaded from the CUC Admin interface by navigating to System Settings > Plugins.

The port monitor can be used in the same way as the rPSM tool and it doesn’t need to be downloaded from an external site which means that this might be your only option if you are sitting the CCIE Voice Lab.

After you launch RTMT then select Port Monitor from the Unity Connection menu.

You should see the CUC ports that are registered to UCM. In this case we have two SCCP ports registered to UCM with DN’s 5601 and 5602. Both of the ports are idle at this stage.

If you set the polling rate to a lower value to ensure the screen refreshes every couple of seconds as opposed to every 5 seconds.

In the example below a user has called 5050 which is provisioned as a CTI Route Point in UCM. This has Call Forward All set to voicemail. The CUC server is receiving the call and the Forwarding Routing rules are used since there is a Redirecting number present. Judging by the Port Monitor output shown below there is a Routing rule which sends any incoming call with a Redirecting number of 5050 to the Live Record handler- this gives the ability for a user to conference in CUC (using extension 5050) and have a recording of a conversation made with a 3rd party sent to the user’s voicemail box.

Another example of how Port Monitor may be used is MWI troubleshooting. After a caller has left a message in the mailbox for extension 1002, you are able to see CUC dial the “MWI On” DN (for SCCP integrations) on the voicemail port with DN 5602. For MWI to work the VM port with DN 5602 must have a CSS that is able to see the MWI DN partition and the MWI DN’s themselves must have a CSS that has visibility of the phone DN partition. Were there to be a problem with MWI in this situation the fact that CUC is dialing out suggests that the problem is inside the UCM as opposed to CUC.

For more information on using RTMT take a look at the Cisco document which can be found here:  http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/service/7_1_2/rtmt/rtprtmn.html

Vik Malhi

Managing Partner IPexpert Inc

Print Friendly

debug gatekeeper main 10: This command can be used on a gatekeeper and will show you how the gatekeeper will process an ARQ message received from an H323 gateway (including UCM).  Cisco have published a decision tree that depicts the logic of how gatekeeper will handle an ARQ- this debug correlates to that decision tree.

debug gatekeeper call 10: This command can be used in tandem with “main 10″ and is primarily used to show the bandwidth requested in the ARQ message being sent from gateway to gatekeeper.

debug ras: Whereas the two commands above are useful to determine the logic of the steps used to get to ACF from ARQ, the debug ras command is used to see a high level view of all RAS messaging that is sent between GW and GK. The nice thing about this command is that it is not too expansive and shows ip addresses of source/destination devices in decimal.

debug h225 asn1: If all else fails then use this command. This will show the entire H225 and RAS message in ASN.1 format (they are very big messages!). This is useful to see information that is contained within a 225/RAS message such as the Calling/Called #, Source/Destination IP Address/Port #, Release Cause, etc, etc.

debug h245 asn1: This command will display the Terminal Capability Set, Master Slave Determination (MSD) and Open Logical Channel (OLC) messages once a call through an H323 gateway has been answered by the Called Party.

debug voip dialpeer: Very useful (perhaps the most useful within IOS gateways along with debug isdn q931) command that shows which inbound and outbound dial-peer has been matched after a call to the IOS gateway has been made.

debug voip ccapi inout: This debug command will show you what dial-peers are being matched on the IOS gateway and the state that the gateway is in during the processing of a particular call. It is also useful to see what codecs are being selected for each of the two call legs that represent the call.

debug voice translation: This command will display details of matching voice translation profiles that are invoked from within a dial-peer or voice-port during call processing.

debug sccp events: This command will let you know whether your media resources present on the IOS gateway are successfully registering to UCM/CME and also if they are being invoked during call processing.

debug ccsip messages: Very useful command to display SIP messages sent between the IOS gateway and SIP phones, SIP Providers and also Unity Express.

Vik Malhi – CCIE #13890
Managing Partner / Instructor – IPexpert, Inc.
Mailto: vmalhi@ipexpert.com

Print Friendly