Archive for the ‘Uncategorized’ Category

A true benefit of MPLS technology is the ability to provide Quality of Service (QoS) guarantees over an IP backbone. QoS on an MPLS backbone is used to provide predictable, guaranteed performance metrics required to transport real time and mission-critical traffic. The providers have an overall QoS architecture that is used to deliver a subset of QoS services to each customer. The provider will have multiple classes of service that the customers must align with in order to leverage the providers’ MPLS offering. The providers must have an MPLS QoS architecture that provides end-to-end guarantees for each class of service for each customer. Cisco, for instance, has defined two models that can be used independently or together to provide the end-to-end guarantees for each customer. Cisco defines these as the point-to-cloud and point-to-point models.

The point-to-cloud or “hose” model allows the provider to provision an ingress committed rate (ICR) and egress committed rate (ECR) for each VPN. The ICR and ECR dictate how much bandwidth is allowed to enter and exit the service provider backbone within a VPN. The best way to describe the scenario is with an example. Let’s say we have a VPN with four sites. Each of these sites can communicate with any of the other sites, forming an any-to-any mesh. The sites are labeled “Site 1” through “Site 4.” I will use Site 1 as the basis for discussion. The ICR can be set to only allow Site 1 to inject 50Mbps of traffic into the cloud. This traffic can be destined to any of the other three sites. The ECR can be set to only allow 30Mbps traffic to exit the cloud to Site 1 from the other three sites. These parameters can be set for each class of service. The provider’s backbone will provide bandwidth and delay guarantees for the traffic thresholds as configured for the ICR and ECR. This model allows the provider’s QoS to be transparent to the customer. The customer can dictate the amount of traffic that is sent to each of the provider’s classes of service. The customer does not have to match the provider’s classifications and the customer markings are preserved.

The point-to-point or “pipe” model allows the provider to build virtual QoS pipes between the customer edge routers that are used to provide bandwidth and delay guarantees. This is analogous to legacy ATM and Frame Relay PVC meshings. However, the provider is responsible for the virtual mesh. Once the virtual QoS tunnels are established the provider can offer traffic engineering across the virtual mesh. Each tunnel would have its own QoS characteristics so that the CE-to-CE QoS guarantees are established prior to transmission of data. This is a more granular approach to QoS and adds complexity to the provider’s configuration. The pipe model is not as scalable as the hose model as it requires CE-to-CE pipes for each customer. (From MPLS QoS models by Robbie Harrell)

Best practices for MPLS interoperability of customer QoS with provider QoS

When planning an internal QoS architecture that will utilize an MPLS VPN as the WAN backbone, it is beneficial to consider the provider’s architecture. Service providers have enabled QoS with their MPLS VPN services. This allows the provider to offer multiple classes of service with SLA guarantees. The service provider’s QoS architecture dictates how a customer’s applications are serviced over their backbones. It doesn’t matter what your QoS architecture is, it will have to be modified to match the provider’s ability to deliver within their service parameters. The reality is that the provider has one QoS architecture and the customers can have many different ones. The provider is not going to adapt their architecture to the client’s — therefore it makes sense to understand what the providers offer before engaging in an internal QoS plan.

  • Most providers support only three or four classes of service. Some provide five classes of service, but the majority fall into the first group. Limit your number of classes of traffic to 3-4. You can put any applications you want into these three or four classes, the provider doesn’t care. They will tell you what the performance guarantees are for each class. It is up to you to decide which applications require what guarantees.
  • Providers use DSCP for classification and marking. In most cases when you deploy a MPLS VPN WAN, you will need to classify and mark your QoS traffic before you hand it off to the provider. Some providers offer managed services and they will handle the edge router configurations, others provide templates. The customer is responsible for identifying important traffic and initiating a classification scheme. Use DSCP markings rather than IP precedence at the WAN router edge. Most providers follow some form of assured forwarding markings for their classes and you can easily match the providers. If you don’t know the provider’s markings beforehand, use the DSCP standards. (FromMPLS: Interoperability of customer QoS with provider QoS by Robbie Harrell)

 

Using MPLS with VoIP  Back to top ↑

Meeting QoS guarantees that ensure reliable voice transmissions can be the biggest challenge of deploying voice over IP (VoIP) traffic. Implementing MPLS can help enterprises rise to that challenge because the protocol offers network engineers a great deal of flexibility and the ability to send voice and data traffic around link failures, congestion and bottlenecks.

MPLS is useful as an enabler for VoIP because it provides ATM-like capabilities with an IP network. Unlike the expensive ATM links that would be required to support VoIP, MPLS provides guaranteed services utilizing IP quality of service on the carrier’s backbone. This service and the ability to converge VoIP onto the data network present a tremendous opportunity to reduce operational costs and consolidate infrastructures.

Real-time services are application services that are susceptible to delay, packet loss and jitter. VoIP and video over IP are considered real-time applications. While other applications such as SAP are vulnerable to delay, VoIP and video over IP (with corresponding voice) are the real focus, because if you cannot deliver these applications with a high degree of confidence that the packets will not be dropped, experience delay or jitter, then you cannot deploy these application services. (From Carrier MPLS support for VoIP by Robbie Harrell)

Before VoIP came along few companies ever created a full mesh because there was a cost associated with each permanent virtual circuit (PVC). Instead, companies required traffic in a hub-and-spoke topology to pass from one remote office to another through the hub site, using both its inbound and outbound bandwidth. This was generally OK, because one remote office never talked to another before VoIP.

 

 

However, packets don’t fly directly between any two sites. In reality, your packets are probably riding some good old-fashioned frame-relay or ATM network to get from your office to your carrier’s closest MPLS POP. As someone with a keen interest in low-latency, you’ll want to ask some pointed questions about where the MPLS POP actually is located and what the Layer 2 path to get there looks like, because your packets could be taking a scenic route that won’t show up on traceroutes.

Another significant difference between PVCs and MPLS is that the technology really provides no mechanical equivalent of committed information rate (CIR), Committed Burst Size (BC) or Excess Burst Size (BE), etc. However, your WAN provider may like those concepts so much that it tries to replicate the functionality with some truly bizarre policing and remarking configurations. Make sure you understand how they’ve implemented QoS and exactly how they treat your packets that exceed the committed data rate (CDR) and what the thresholds are.

Finally, while it was possible for a provisioned PVC or SVC to change its path through the carrier’s backbone, it’s much more likely to actually happen with traffic-engineered paths in MPLS. You should keep track of how much delay your circuits have, and if you see this number suddenly and mysteriously change, there’s a good chance your packets are taking a different path as a result of a failure or the availability of a better path. (From MPLS — what voice managers need to know by Tom Lancaster)

Scenario#41 – Mailbox in use

Posted: September 29, 2012 in Uncategorized

VOICE ON BITS

A customer reported an issue regarding a user where if she tried to listen to her voicemail messages she would get “Mailbox is in use”.

This issue normally happens if any TUI session or VoiceView sessions are open in any other phones having access to that GDM or the ports have become stuck or busy.
To resolve the issue, login to CLI of CUE module and issue this command:

voicemail mailbox unlock owner Natasha

OR

voicemail mailbox unlock telephonenumber 6311

 

View original post

Good stuff Here for sure.

VOICE ON BITS

One of our customer reported an issue with ring back tone when calling their Contact center.

I made a test call and observed that as a caller when you call their main Contact center number all you hear is dead silence and then when agent picks up the phone you could hear them talk. There was no ring back tone and no automated messages before an agent picks up the call.

The call flow was something like this:

PSTN > ISDN30 > H323 Dial-peer > SIP Trunk > 3rd-party Contact Center Equipment

First I thought it could be the third-party equipment which was not sending back the ring back tone so I asked them to confirm this. They came back saying they are definitely sending ring back and there was no issue with their equipment.

Looking at Q931 debugs I could see ALERTING message with payload but wasn’t sure why…

View original post 708 more words

On CUPC > Help > Show Server Health, sometimes you would see failed items with the message “invalid credential”, such as “Presence”, “Desk Phone”, or “Voicemail”.

This is very confusing. Since you already logged into CUPC, why it’s giving you “invalid credential”? What kind of credential it was failing on?

Before we can move further, please take a look at “CUPS and CUPC, father and son? or not“.

CUPS and CUPC’s relationship is not as tight as you thought. CUPC has many features, but CUPS is only relevant in two of them (configuration repository and presence).

When you type username and password on CUPC login window, that is majorly for “Configuration Repository”. If you typed in the wrong password, CUPC won’t be able to download configuration from CUPS. No other functions CUPC can perform without configuration.

However, sucessfully downloading configuration does not guarantee other functionalities. To use other fucntions, a 2nd authentication might be required (either explicitly or implicitly).

Presence – Invalid Credential

For presence feature, 2nd authentication is required on SIP layer. This authentication is implicit. For more details on “Digest Authentication”, please see http://www.ietf.org/rfc/rfc3261.txt.

Why is it implicit? Why does it fail?

To make it implicit is Cisco development’s decision. If they made it explicit, you’d have to provide digest credential (2nd password) after login. This could be annoying since SSO (Single Sign On) was what we preferred.

So Cisco development made CUPS/CUPC worked this way:
1) You (system admin) configure digest credential on CUCM Admin > User Management > End User page.
2) CUPS synchronizes digest credentials from CUCM to CUPS.
3) CUPS transmits digest credential to CUPC during logon.
4) CUPC uses that degest credential to authenticate with SIP proxy.

Step 3 and 4 look funny because it’s like a door keeper gives the key to you and asks you open the door with the key. But keep in mind:
a) The “door keeper” acutally verified your identify (username/password), before giving you the key.
b) The key was encrypted during transmission.
c) The key door keeper gave you might be for a different door (SIP proxy could be on a different server other than the logon server)
d) This is a compromise (or balance) between inconvenience of SSO and SIP protocol requirements.

If there’s no digest credential configured on CUCM (ie. it’s blank), you’ll get “Invalid Credential” for presence. To fix it, take one of the following options:

Option 1: Go to CUCM Admin > User Management > End User, configure a dummy value for “digest credential”. It could be any value. Why? See workflow explained above.

Option 2: Go to CUPS Admin > Cisco Unified Presence > Proxy Server > Incoming ACL. (on CUPS 7.x, it’s “System > Security > Incoming ACL”. Configure an address pattern that covers your CUPC machines. For example, a “all” pattern matches all machines.

This option is considered less secure, because any machine in that address pattern (subnet) would be able to connect to SIP proxy without digest authentication challenge.

Option 3: Go to System > Service Parameters > Cisco UP SIP Proxy. Set “Authentication Module” to “off”. This is the least secure option, which turns off SIP authentication at all.

Desk Phone – Invalid Credential

This usually happens when CUCM was configured to use “LDAP Authentication”.

To control desk phone from CUPC, CTI protocol was used. Before a CTI client (CUPC) can control the phone, it needs to authenticate with CTI server (CTIManager). This authentication is implicit. CUPC would use the same logon username/password to authenticate with CTIManager. CTIManager, in turn, would authenticate that with LDAP.

Question: Why the authentication would fail?
Answer: In short, this is a bug on CUCM.

Question: Any workaround for that before we can upgrade CUCM?
Answer: On CUCM, change LDAP authentication port to 3268 and restart CTIManager.

Question: Why it would fix the problem?
Answer: When LDAP referral happens, CTIManager would fail on authentication. Using 3268 (Global Catalog) port eliminate LDAP referals.

Question: Why it only affects CUPC?
Answer: CUPC is the only application (so far) that uses end user credential to authenticate with CTIManager.

Voicemail – Invalid username/password or account locked

Depending on what Unity edition you’re running (Unity or Unity Connection), the cause could be different.

Before moving on, please take a look at “How to test IMAP connection“.

On Exchange 2007, it’s because IMAP login was disabled on TCP (port 143) by default.

On Unity Connection, make sure you reset “Web Application Password” instead of VoiceMail password.

 (R) 2012

VoIP Basics Reference Sheet

As of IOS 12.4(23)T you no longer need to rely on a “reload in” command to save you from potentially locking yourself out of a remotely managed router.

You can enter configure mode with “config terminal revert time x” and IOS will save the running configuration to a backup file on flash to revert to after x minutes.

When your changes are successful and you want to cancel the revert you simply exit configuration mode and feed the router “config confirm” to commit your changes persistently. Though obviously you will still need to write your running configuration to NVRAM as per usual!

What is the advantage of this? Well for one you don’t have to wait  for the router to reload to get access again and secondly any other services this router is providing eg Voice gateway, transcoding etc will be unaffected.

 

Lets take a look at how this behaves on the CLI:

 

Enable Configuration archiving

 

Router(config)#archive
Router(config-archive)#path flash:backups
Router(config-archive)#maximum 14
Router(config-archive)#exit
Router(config)#exit

 

Enter Configure mode with a reversion timer

Router#conf terminal revert timer 2

 

Rollback Confirmed Change: Backing up current running config to flash:backups-0

Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#
*Apr 11 02:38:30.571: %ARCHIVE_DIFF-5-ROLLBK_CNFMD_CHG_BACKUP: Backing up current running config to flash:backups-0

*Apr 11 02:38:30.5711: %ARCHIVE_DIFF-5-ROLLBK_CNFMD_CHG_START_ABSTIMER: User: console: Scheduled to rollback to config flash:backups-0 in 2 minutes

 

Make a configuration change

Router(config)#host
Router(config)#hostname RevertMe
RevertMe(config)#

 

Take note of reversion warnings

*Apr 11 02:39:30.571: %ARCHIVE_DIFF-5-ROLLBK_CNFMD_CHG_WARNING_ABSTIMER: System will rollback to config flash:backups-0 in one minute. Enter “configure confirm” if you wish to keep what you’ve configured

 

 

Reversion takes place

Rollback Confirmed Change: rolling to:flash:backups-0

 

 

Total number of passes: 1
Rollback Done

*Apr 11 02:40:30.571: %ARCHIVE_DIFF-5-ROLLBK_CNFMD_CHG_ROLLBACK_START: Start rolling to: flash:backups-0
*Apr 11 02:40:30.575: Rollback:Acquired Configuration lock.
*Apr 11 02:40:33.091: %PARSER-6-EXPOSEDLOCKRELEASED: Exclusive configuration lock released from terminal ’0′ -Process= “Policy Manager”, ipl= 0, pid= 21

Router(config)#

 

 

Alternatively Commit your changes

Router(config)#hostname RevertMe
RevertMe(config)#exit
*Apr 11 02:46:08.615: %SYS-5-CONFIG_I: Configured from console by consoleonf
RevertMe#configure confirm
*Apr 11 02:46:10.899: %ARCHIVE_DIFF-5-ROLLBK_CNFMD_CHG_CONFIRM: User: console: Confirm the configuration change
RevertMe#copy running-config startup-config
Building configuration…
[OK]
RevertMe#

Layer 2 QoS vs. Layer 3 QoS

Posted: May 13, 2012 in Uncategorized
Tags: , ,

So here lately, I have had a chance to dive back into QoS on both the Layer 2 and Layer 3 platforms. So I must admit, I did have to utilize the ol’ Google search engine..

But I will share:

The fundamental: layer-2 has frames while packets are at layer-3, if that is clear, read on 

Layer-2 802.1Q frames have a 2-byte field called Tag Control Information. The three most significant bits of this 2-byte field represents the CoS (Class of Service) value. Layer-2 QoS is represented by this CoS value which is from 0 to 7 (thus 8 values). In addition to 802.1Q and Cisco proprietary ISL (Inter-Switch Link), no other layer-2 frames can have CoS (and hence QoS) values!

Layer-3 IP packets can carry either an IP precedence (IPP) value or a Differentiated Services Code Point (DSCP) value. QoS supports the use of either value because DSCP values are backward-compatible with IP precedence values.

IP precedence values range from 0 to 7.
DSCP values range from 0 to 63

Both IPP and DSCP use the bits in the ToS (Type of Service) byte in the IPv4 header. IPP uses the 3 Most Significant Bits (MSB) while DSCP uses the 6 MSBs of the ToS byte (kudos to IPv4 designers for keeping the ToS byte in there!!!)

So, remember: layer-2 QoS deals with CoS, while at layer-3 we deal with IPP and|orDSCP.