Category: Cisco

Cisco: IP Policy Routing with IP SLA and EEM

Considering the same environment like in the post Cisco: Policy Routing with IP SLA, there is another way to achieve the same behavior using again IP SLA and EEM (Embedded Event Manager).

For those of you who are not so familiar with EEM please read http://www.cisco.com/en/US/products/ps6815/products_ios_protocol_group_home.html. You will find a nice explanation and some examples how to use EEM to achieve the desired result.

Now, going back to our example, please conside the same topology like in the previous post:

We start by configuring again the IP SLA (explanation in this post):

ip sla 5
icmp-echo 172.82.100.1 source-interface GigabitEthernet0/0
timeout 1000
frequency 2
ip sla schedule 5 life forever start-time now

We have the path measured. Instead of tracking this and applying the route based on tracking, we have now a different approach. We use EEM to check the conditions of IP SLA, and according to the result we configure the necessary IP routing. For EEM to work we need to know and Object name and the OID associated with it. In my example I will use the SNMP Object name rttMonCtrlOperTimeoutOccurred with OID value: 1.3.6.1.4.1.9.9.42.1.2.9.1.6

According to Cisco’s explanation “This object is set to true when an operation times out, and set to false when an operation completes under rttMonCtrlAdminTimeout. When this value changes, a reaction may occur, as defined by rttMonReactAdminTimeoutEnable”

As a summary, we will check the IP SLA with EEM using a certain SNMP Object. When a change occur in the monitored IP SLA, EEM will apply a certain configuration defined by us:

event manager applet IP-SLA-5-TIMEOUT
event snmp oid 1.3.6.1.4.1.9.9.42.1.2.9.1.6.5 get-type exact entry-op eq entry-val 1 exit-op eq exit-val 2 poll-interval 5
action 1.0 syslog msg “172.82.100.1 not reachable – primary line NOK”
action 1.1 cli command “enable”
action 1.2 cli command “configure terminal”
action 1.3 cli command “ip route 0.0.0.0 0.0.0.0 10.10.10.1”

EEM is based on a SNMP event. It is monitoring the OID value explained above. You may notice that at the end of the OID value, has been added another value .5 This is important as it defines the relation between EEM and IP SLA. In my case this number is 5, as the IP SLA session is defined, but in your case it may be different. This is checking if the TruthValue is 1 (true) or 2(false), on a 5 second interval and it’s applying the defined configuration. The EEM triggers on value 1 (true), so when the timeout occurs in IP SLA.

You might wonder, what will happen when the primary line is working. Well nothing in this conditions, because EEM is not configure for the case when the primary line is OK. In other words, EEM will not retract the backup default IP route. For this we need another EEM to be configured with a small modification:

event manager applet IP-SLA-5-OK
event snmp oid 1.3.6.1.4.1.9.9.42.1.2.9.1.6.5 get-type exact entry-op eq entry-val 2 exit-op eq exit-val 1 poll-interval 5
action 1.0 syslog msg “172.82.100.1 is reachable – primary line OK”
action 1.1 cli command “enable”
action 1.2 cli command “configure terminal”
action 1.3 cli command “no ip route 0.0.0.0 0.0.0.0 10.10.10.1”

Now the EEM is triggered on the value 2 (false), so when no timeout occurs in IP SLA.

You might be interested in another EEM configuration, which send an e-mail notification when a certain condition occur. Check it here.

Cisco: Policy Routing with IP SLA

Let’s assume that you have a Cisco router with 2 ISP connection. The first one it’s a 10Mbps connection with a decent latency and the second one it’s a 2Mbps connection with quite high latency.

Since you don’t want to load balance over this 2 connections for the obvious reasons described above, you decide to to use the 10Mbps connection as the primary link and the 2Mbps one as a backup, just in case that the primary link fails.

You have no dynamic routing protocol, just a default route pointing to the primary link peer router. To understand better, please have a look to the topology below:

Of course, the easiest method would be to configure the a secondary default route through 2Mbps line but with a higher metric so it would be less preferred.  In this case when the main line goes done the backup default route comes into play. But what if the main line doesn’t go down? Just there is no reachability to Internet or some branch offices? This method will not work very well.

The solution that I propose is first to configure an IP SLA to monitor a certain destination (IP address) that you know if should always be UP. Like a server in your remote datacenter. In my example I will monitor the IP address 172.82.100.1 which is a server reachable over main provider:

ip sla 5
icmp-echo 172.82.100.1 source-interface GigabitEthernet0/0
timeout 1000
frequency 2
ip sla schedule 5 life forever start-time now

I believe you have an idea what IP SLA does. In this example it ping every 2 second the IP address 172.82.100.1 and it wait for reply (timeout) 1000ms before declare the host down.

Next we have to track this IP SLA for reachability:

track 1 ip sla 5 reachability

Pretty simple. I have a track number 1 which tracks IP SLA session 5 for reachability.

Now, most of the people (including I, in the beginning ) make a common mistake in setting the backup default route in the way that they set it based on the track 1:

ip route 0.0.0.0 0.0.0.0 10.10.10.1 track 1

This is not going to work. Why? Because track 1 check that the IP is reachable! When it is reachable, it will add the backup default route to the routing table and we will have 2 default routes: one through primary line and one through secondary (backup) lines. That’s bad because we need the backup route there only when the primary line fails to transport traffic to 172.82.100.1 in my example. We need somehow that this backup route to be applied when IP SLA 5 is NOT true. Here is is how:

track 2 list boolean and
object 1 not

In this track 2 we tell to track object 1 but to have the condition that this is not true. Now we can see the backup route:

ip route 0.0.0.0 0.0.0.0 10.10.10.1 track 2

and this will work correctly.

Small hint: You saw that in the IP SLA I’ve specified the interface from which I want to ping 172.82.100.1. This is not just a preferred method, but it’s mandatory! If you follow the steps above, when the backup default route will be in place, 172.82.100.1 will be reachable again, making the track 1 being true and setting the track 2 to think that the primary link is UP again, so it will retract the backup route through 10.10.10.1. Pinging with the source of the primary P2P link interface, you achieve the result that you want IP SLA 5 to be true only when pinging 172.82.100.1 through the first line. Remember that we are not using dynamic routing protocols.

In case  you didn’t catch this until now Gi0/0 is the 10Mbps link and the Serial0/0 is the 2 Mbps.

Another method to obtain the same result will be to used EEM with IP SLA which I will present in some future posts.

Cisco: Prioritize Voice traffic with LLQ



In one of my previous posts I was explaining how to mark packets closer to network edge. Starting from that point, we are sure the packets are market with the correct value, so on the router device we can directly match those packets and prioritize using Low Latency Queueing.

I believe you already know why queueing is so important for Voice packet especially, but also for all other kind of real time protocol (e.g. Video over IP), but just a small reminder. Most of the interfaces are using FIFO method for queuing. This is the most basic queue method and as you probably know means First In First Out. In human terms, first packet how arrive on the interface will be send first. Nothing wrong with this theory until this point and I can assure you that most of the time you don’t have to do anything to improve this technique. But what if you have real time protocols (e.g. voip services) and data transfer over the same physical interface? With FIFO the packets are sent out the interface as they arrive, but this is not very good for the delay sensitive traffic like voice. If a TCP packet in HTTP flow can wait it’s turn to be sent out, with not visible impact for user, than a delayed voice packet will cause deprecation in voice call.

With this problems need to be solved we arrive at LLQ, which is an ehanced version of Priority Queueing (PQ) in a Class-Based Weighted Fair Queueing (CBWFQ).

Before we start let’s have a look to the topology we will use (the same like in Cisco: Mark voice packets at the network edge post):

After marking the packets on the Access Switch,now we want to prioritize voice packets on the core router:

1) Match packets market with EF in a class-map

class-map VOICE
match dscp 46

2) Configure a policy-map unde which you match the traffic in the class-map VOICE and enable LLQ. The parameter “priority” is the one telling policy-map to enable priority queueing under that class. The value after the “priority” keyword can be a value in kbps or percentage from the total bandwidth. In the example below I assume that I have a 10Mbps bandwidth and I’ll configure LLQ class to use 10% from it, meaning 1000kbps

policy-map MYPOLICY
class VOICE
priority 1000

or with percentage

policy-map MYPOLICY
class VOICE
priority percent 10

I have to tell you that after the bandwidth or percent value you can add a burst value in bytes. If you don’t add this value, it will be calculated automatically. I chose this method when I’m doing simple config, but if you want to fine tune the values you can calculate it yourself and add it. Be careful that a higher value will influence the Tc value in the process.

3) Apply the policy to the WAN interface of the Core router (I assumed that the Core router is your direct connection to provider backbone) direction outbound. You cannot apply this type of queueing direction inbound. Keep this in mind.

interface s0/0
service-policy output MYPOLICY

If you insist on applying it inbound, you’ll get an error message:

Core(config-if)#service-policy input MYPOLICY
Low Latency Queueing feature not supported in input policy.

To check that your queueing policy is applied:

show policy-map interface s0/0

Service-policy output: MYPOLICY

queue stats for all priority classes:

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

Class-map: VOICE (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: EF
Priority: 10% (1000 kbps), burst bytes 25000, b/w exceed drops: 0

Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any

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

How to use a Cisco router as Frame-Relay switch


For this tutorial you can use  a low cost Cisco router and of course you need some serial interfaces available on this router. I will use a 7206 with 3 serial interfaces. This router I will call R6 and the rest of the three routers connected to R6, will be R2, R5 and R9. In this way it will be easier for you to understand how the frame-relay routing is achieved.

If we have a look to R6’s (the router used as frame-relay switch) interfaces:

r6-c7206#sh int desc
Interface                      Status         Protocol       Description
Fa0/0                            up                down
Fa0/1                             up                down
Se5/0:1                         up                up                    TO_R2
Se5/1:2                         up                up                    TO_R5
Se6/0                            down          down
Se6/1                             up                up                    TO_R9

you’ll notice that we have 3 active serial interfaces, each being connected to one of the three routers R2, R5 and R9.

Very important, before you begin define a scalable range for your DLCI numbers, otherwise you will have a complete mess when troubleshooting is needed. I like to define them after formula Rx0Ry. In the middle you have the number zero. In this idea, we will have something like R20R5 and from this resul the DLCI 205 for the Frame-Relay connection between R2 and R5. Below you have the DLCI numbers used in this tutorial:

R2 -> R5: DLCI 205
R2 -> R9: DLCI 209
R5 -> R2: DLCI 502
R5 -> R9: DLCI 509
R9 -> R2: DLCI 902
R9 -> R5: DLCI 905

Now that we have defined the DLCI numbers lets configure R6 router as frame-relay switch.

First of all, you need to enable frame relay switching on the router:

r6-c7206#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
r6-c7206(config)#frame-relay switching

This command enable the switching  of packets based on the data?link connection identifier (DLCI) inside your router.

Next, we have to configure the frame-relay routing on the physical interface. We will start with interface S5/0:1 where R2 router is connected and apply the following configuration

interface Serial5/0:1
description TO_R2
no ip address
encapsulation frame-relay
! the frame-relay switch is the DCE and the other end is the DTE
frame-relay intf-type dce
frame-relay route 205 interface Serial5/1:2 502
frame-relay route 209 interface Serial6/1 902

With frame-relay route command we tell to frame-relay switch where to forward the packets based on the DLCI number. If we take a look to the first frame-relay route command, than the path to DLCI 502 is interface Serial5/1:2. If you feel confuse, please check again above the interface connection to the router and the assigment scheme for DLCI numbers.

The same like for interface S5/0:1, we will configure the interfaces connected to R5 and R9:

interface Serial5/1:2
description TO_R5
no ip address
encapsulation frame-relay
frame-relay intf-type dce
frame-relay route 502 interface Serial5/0:1 205
frame-relay route 509 interface Serial6/1 905

interface Serial6/1
description TO_R9
no ip address
encapsulation frame-relay
frame-relay intf-type dce
frame-relay route 902 interface Serial5/0:1 209
frame-relay route 905 interface Serial5/1:2 509

Having a look to S5/1:2, first frame-relay route command, here we configure the path back from R5 to R2, by telling the frame-relay switch to chose interface S5/0:1 to send packets to DLCI 205 (R2).

This is the basics of how to configure a Cisco router as a frame-relay switch. If you need help, please don’t hesitate to use the comment form below.

Cisco: Mark voice packets at the network edge

You know how Cisco always advise to mark the packet as close to the your network edge as you can? Even more you can find a lot of example where Cisco show how to trust the packets directly on the access switch, but not all the time you can do this.

First because not everybody has devices that mark correct packets (like Cisco IP Phones) but we still have to deal somehow with packet marking as maybe your provider treat packets different on their backbone based on their marking.

In this idea what I’m taking care the most are the voice packets as usually this has to be prioritized on the network. Let’s face it, if you have a TCP connection and some FTP packet are retransmitted you don’t notice this too much, but if you have delay on your phone conversation with your boss, that it’s not so good.

Please have a look at the topology below:

In this scenario we have a Voice server and some IP Phones (I know they look like Cisco IP phone, but pretend they are not) connected to the access switch. Let’s assume that  we cannot trust marking on this packets as they arrive from this devices.

Here we run into one of the two issues. First if we trust the marking on the access port, than we don’t know what we are stuck with. If we don’t trust them, then the packets header DiffServ (TOS) bits are rewrite with a value of zero making no difference between voice packets and regular ones.

My solution is the following. I’m not saying that’s the only solution or the best, but it’s working:

On the access switch:

1. enable globally:

mls qos

2. configure and access-list that match the voice packet; this is a very general list:

access-list 101 permit udp any any range 16384 32767
access-list 101 permit udp any range 16384 32767 any
access-list 101 permit udp any any range 5060 5061
access-list 101 permit udp any range 5060 5061 any

3. match the access-list in a class-map

class-map match-all VOIP
match access-group 101

4.configure a policy-map with the class-map above and set the DSCP value to EF (decimal 46) or COS or whatever you need

policy-map ASTERISK
class VOIP
set dscp ef

5.on the access port configure the service-policy direction inbound

int x/y
service-policy input ASTERISK

6.on all trunks from your access switch to your first Layer 3 device trust this DSCP  value (or what you have set, as now we are sure what values we set) with:

mls qos trust dscp

Let me know if it’s working!

Other articles that you might be interested in: