Voice Translation-Rule

Some time ago I setup SIP trunking , I had to configure voice translation rules on the CUBE. Here’s are a few I setup that might help you (numbers changed). Once the numbers were translated they would match dial-patterns and be routed respectively.

Using regular expression.

Number 1 translates an incoming call to a 4 digit extension.

voice translation-rule 1
rule 1 /^02081234567/ /1111/

R1#test voice translation-rule 1 02081234567
Matched with rule 1
Original number: 02081234567 Translated number: 1111

Number 2 takes any number and adds a 9 to the beginning.

voice translation-rule 2
rule 1 /^.*/ /9\0/

R1#test voice translation-rule 2 02081234567
Matched with rule 1
Original number: 02081234567 Translated number: 902081234567

Number  3 translates a dialed number beginning with +44 or + to 90 or 900.

voice translation-rule 3
rule 1 /^\+44/ /90/
rule 2 /^\+/ /900/

R1#test voice translation-rule 3 +442081234567
Matched with rule 1
Original number: +442081234567 Translated number: 902081234567

R1#test voice translation-rule 3 +1123456789
Matched with rule 2
Original number: +1123456789 Translated number: 9001123456789

Number 4 translates a 4 digit number beginning with 5, drops the 5 and appends a country code and an area code.

voice translation-rule 4
rule 1 /^5\(…$\)/ /00442081234\1/

R1#test voice translation-rule 4 5678
Matched with rule 1
Original number: 5678 Translated number: 00442081234678

Number 5 translates any number beginning with 901* to 0044 and any number beginning with 900* drops the 9.

R1#test voice translation-rule 5 9020812345678
Matched with rule 1
Original number: 9020812345678 Translated number: 004420812345678

R1#test voice translation-rule 5 90012345678910
Matched with rule 2
Original number: 90012345678910 Translated number: 0012345678910

RH

QoS Pre Classify

It’s worth making some notes on this subject to clear up a few misconceptions I found online.

Firstly I setup a lab to confirm what i’m about to say, the reason we use this command is to allow QoS to correctly classify or view the packets based on the original header, if the packet is encapsulated  it’s  treated the same as any other encapsulated packet. The original header and its QoS value is now unknown to the forwarding device.

So by enabling this command we can apply the classification before the encapsulation or tunneling happens.

Apply the command “qos pre-classify” to a tunnel interface, a crypto-map or a virtual tunnel interface.

Classification based on layer3 and layer4 information is the exact reason we would consider using this feature, classification based on TOS or DSCP values do not need to use this feature, that’s because of TOS byte preservation inherently built into IPSEC.

Once you’ve added the pre-classify command, apply a service-policy to the physical interface outbound, then all IP packets will be classified pre-encapsulation on any tunnels egressing that physical interface. In other words you will see hits on the policy-map individual classes.

A really great resource I found online is this QoS values calculator check it out………….

Cisco IOS IP SLA (UDP-Jitter for VOIP)

RH

QOS – Part III – Service-Policy

The last item on our list is the service-policy, this is the part where we apply our policy-map to an interface and specify the direction for the policy.

To help you visualise how the command is used and which direction see the picture below.

QOS is being applied to traffic coming from inside our network going outbound to the WAN.

Your interface will look something like this.

interface FastEthernet0/0
 description WAN_interface
 bandwidth 20000
 ip address 10.100.100.2 255.255.255.252
 ip nbar protocol-discovery
 service-policy output QOS_Egress

To confirm the QOS is working you would use the command “show policy-map interface fastethernet 0/0” this will give you a whole bunch of information, see below for an example of how this might look.

Service-policy output: QOS_Egress

queue stats for all priority classes:

queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 331150787/112001702019

Class-map: voice_traffic (match-all)
266055005 packets, 57655712122 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp ef (46)
Priority: 7% (1400 kbps), burst bytes 35000, b/w exceed drops: 0
QoS Set
dscp ef
Packets marked 266055059

Class-map: voip_signal (match-any)
78149834 packets, 7487646866 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match:  dscp cs3 (24) af31 (26)
78149834 packets, 7487646866 bytes
5 minute rate 0 bps
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 78149832/7487645664
bandwidth 3% (600 kbps)
QoS Set
dscp af31
Packets marked 78149834

Class-map: class-default (match-any)
9073254895 packets, 3302249852254 bytes
5 minute offered rate 998000 bps, drop rate 0 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/16751970/0
(pkts output/bytes output) 569664615/3424829483864
QoS Set
dscp default
Packets marked 9071570170
shape (average) cir 16000000, bc 160000, be 160000
target shape rate 16000000

As you can see it gives lots of information on how your QOS is performing, the default-class shows some drops that means its had to drop some packets when the link was congested and in fact means your QOS policy is doing its job if the drops were excessive you would increase the values or decrease whichever suits your network.

If you just want to view an indivdual class then you would use the command “show policy-map interface fastethernet 0/0 output class web_traffic” for example.

When using the “service-policy input QOS_Egress” you will receive an error stating that you cannot apply this to the interface, this is becuase CBWFQ is a mechanism for traffic queuing in the outbound direction, never for the inbound direction.

I hope my 3 part blog has gone some way to helping you understand QOS.

RH

QOS – Part II – Policy-Map

My last blog covered class-map’s, which were used to identify traffic to our device, the next part of QOS covers what the device does with the traffic after its been identified. This is called a policy-map.

So you create your policy with the following command

R1#conf t
R1#(config)policy-map QOS_Egress

Next you need to reference each class-map then tell the device what to do with that traffic. Here’s an example

class voice_traffic
priority percent 7
set ip dscp ef
class voip_signal
bandwidth percent 3
set ip dscp af31
class SQL_App
bandwidth 20000
set ip dscp 26
class telnet_traffic
bandwidth percent 3
set ip dscp af21
class citrix_traffic
bandwidth percent 10
set ip dscp af41
class my_desktop
bandwidth percent 40
set ip dscp 18
class web_traffic
police rate percent 15
set ip dscp 10
class class-default
set ip dscp default
shape average percent 80

I’ve used some different actions on my policy map, “priority” and “bandwidth” are worth some discussion.

The idea with priority is just as it sounds, that’s your most important traffic class hence why it’s used for voice, so in my policy-map I’ve reserved 7% bandwidth, on a 20mbps circuit that would mean when the link is saturated, any voice traffic upto 1400kbps would be given priority over all other traffic. The difference that priority has over bandwidth is built-in policer, provides low latency, manages delay and jitter.

For your environment you may need more or less than 7% depending on what codecs you use between your IP phones.

Bandwidth defines the minimum bandwidth guarantee to that class, this can be specified in percentage of the interface bandwidth or in kbps. With CBWFQ the excess bandwidth is divided up amongst the remaining classes if it’s not already being used by the default-class.

Traffic shaping can be applied to the default-class as a way of ensuring your link is never fully utilized by unimportant traffic, what it does in this case is only ever allows maximum outbound traffic for the default-class to reach 80% of the interface rate.

Police means the maximum rate that is always applied to that class, the difference between police and shape is that police will drop packets and shape will buffer them, policing the traffic is alot more complicated than what I’ve explained, this is just simple terms.

DSCP values are set on my policy-map for  inbound traffic to my WAN, so in advance I would speak with my WAN provider and break up all the different DSCP values into classes like gold, silver, bronze then once the WAN provider receives a layer 3 packet with a DSCP value assigned it can decide how to process the packet when the link is congested.

There are lots of variations you can use with policy-maps, you can use nested policy-maps aswell, but this is just a brief overview of what you can achieve with QOS.

Remember you need to have end to end QOS, that means determining trust boundaries. For example from IP phone to IP Phone would be end to end QOS, if you don’t mark the packets coming from your IP Phone then the router will classify them as default traffic, by default your IP phone will send voice traffic marked as EF, You need to connect it to a switchport that at the very least has the command “trust cos”

RH

QOS – Part I – Class-Maps

Quality Of Service is one of my favourite subjects the more I learn about it, the more I realise what i don’t know!

So the idea with QOS is you can classify different types of traffic using a class-map, then you can create a policy-map and specify what to do with that traffic, Next you apply the service-policy to an interface either inbound or outbound.

QOS really comes into its own in a  VoIP system, when your WAN link bandwidth is saturated you need to make sure that your VoIP traffic skips to the front of the queue giving the user the clear and uninterrupted call they expect. Remember that QOS only works when its deployed end to end.

My assumption here is you know what DSCP values are.

So lets look at a class-map this is the first part of our configuration, what a class-map does is identify traffic to your router, traffic can be identified at layer 3, layer 4 or layer 7.

This class-map matches DSCP EF (expedited forwarding) which is what voice traffic is marked, this is the most important and should be given top priority. I’ve included is voice_signal traffic which is marked as cs3 or af31, next matches applications, this is used in conjunction with NBAR, below we’ve matched some well known ones SQL, Telnet & Citrix. I’ve thrown in a class-map that can match ip address’s specified in access-list 10 and an extended access-list for matching tcp traffic.

Your router will parse each line sequentially, this is the same with your policy-map.

class-map match-all voice_traffic
 match ip dscp ef
class-map match-any voip_signal
 match ip dscp cs3 af31
class-map match-any SQL_App
match protocol sqlserver
class-map match-all telnet_traffic
  match protocol telnet
class-map match-all citrix_traffic
  match protocol citrix
class-map match-any my_desktop
 match ip access-group 10
class-map match any web_traffic
 match ip access-group 101
!
access-list 10 permit 192.168.1.10  
access-list 101 permit tcp any any eq www

Now you have your class-map your router can now identify traffic that passes through it.

So part 1 of this blog has covered identifying traffic to your router next we will cover policy-maps which decide what the router does with the traffic, so the class-map identifies the traffic and the policy-map defines the action for that traffic.

See you soon for my next part!

RH

Cisco IOS IP SLA (UDP-Jitter for VOIP)

Thank Cisco for IP Service Level Agreement…… you will, I promise!

There are many uses for IP SLA  and one use for this technology is to monitor traffic for a certain IP application, you can use it to simulate traffic and have it report back with information such as latency, jitter, packet loss etc. I will cover other uses for IPSLA in future blogs.

I will give you a real world example so you can understand just what it can do. This SLA measures UDP-Jitter for VOIP.

SITE A

ip sla 10
udp-jitter 10.1.0.1 5000 source-ip 10.1.0.15 source-port 17386 codec g711ulaw                                                                                     tos 184
owner dave.smith@cisco.com
tag site A to site B UDP VOIP
frequency 150
ip sla schedule 10 life forever start-time now

That’s one side done, the other router you specify 10.1.0.1 has to be setup to respond, so this is actually called a responder funnily enough

SITE B

ip sla responder
ip sla responder udp-echo ipaddress 10.1.0.15 port 17386

Now that you have both ends setup, our schedule states that the frequency is every 150 seconds, so wait this time and you will start to see statistics. the command you would use is “show ip sla statistics 10” this will bring up all the information based on your UDP-Jitter setting and in our case we are simulating a voice packet with G711 codec.

IPSLAs Latest Operation Statistics

IPSLA operation id: 10
Type of operation: udp-jitter
Latest RTT: 147 milliseconds
Latest operation start time: 06:29:19
Latest operation return code: OK
RTT Values:
Number Of RTT: 1000             RTT Min/Avg/Max: 146/147/151 milliseconds
Latency one-way time:
Number of Latency one-way Samples: 1000
Source to Destination Latency one way Min/Avg/Max: 116/116/118 milliseconds
Destination to Source Latency one way Min/Avg/Max: 30/31/34 milliseconds
Jitter Time:
Number of SD Jitter Samples: 999
Number of DS Jitter Samples: 999
Source to Destination Jitter Min/Avg/Max: 0/1/2 milliseconds
Destination to Source Jitter Min/Avg/Max: 0/1/3 milliseconds
Packet Loss Values:
Loss Source to Destination: 0
Source to Destination Loss Periods Number: 0
Source to Destination Loss Period Length Min/Max: 0/0
Source to Destination Inter Loss Period Length Min/Max: 0/0
Loss Destination to Source: 0
Destination to Source Loss Periods Number: 0
Destination to Source Loss Period Length Min/Max: 0/0
Destination to Source Inter Loss Period Length Min/Max: 0/0
Out Of Sequence: 0      Tail Drop: 0
Packet Late Arrival: 0  Packet Skipped: 474
Voice Score Values:
Calculated Planning Impairment Factor (ICPIF): 2
MOS score: 4.32
Number of successes: 21
Number of failures: 0
Operation time to live: Forever

The main parts you will probably look at here are MOS (mean opinion score) and ICPIF (planning impairment factor) Jitter and of course RTT. The TOS option is for adding a QOS value for my example i’ve used 184 which is DSCP 46 or EF, which is what you would normally use for VoIP. This of course only matters if you have QOS setup in the first place.

As you can see there’s lots of information here but what’s even better if you use a tool such as PRTG or MRTG you can output this data to a very nice graph where you can monitor it over a long period of time. Here’s an example.

Look out for my QOS blog next!

RH