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 Visual Network Index (VNI)

Cisco Visual Network Index (VNI) is an interactive tool that can help you to forecast and analyze the growth and use of IP networks worldwide. Cisco VNI intiative includes distinct elements to provide a comprehensive view of the changing IP network landscape:

Cisco VNI Forecast is a model for the estimation of future global IP traffic growth.

This can help you to estimate global IP traffic growth using data sources like Application Type, Country and Region, Segment or Network. You can access this VNI Forecast Widget and using the Wizard Editor you can create your own forecast. If you have more experience, there is also an advanced editor to predict IP traffic growth. I’m going with the Wizard to show you what I mean and why I like this tool.

IP traffic estimation by Application Type. You can select what applications to check from Web/Email, File Sharing, Internet Gaming, Business Internet, IP WAN and many more. Following the Step by Step wizard you can end with the following graph:

I have checked all the applications in the diagram above.

Estimated IP traffic by country and region:

IP traffic estimation by segment:

And finally Estimation by Networks:

If you want to help Cisco and improve this estimations you can download 2 applications: Pulse which can be installed on a PC (too bad that there is no version for Linux or Mac) or GIST for mobile devices like Blackberry or Iphone.

To see how the statistics gathered from this software look, check on Ciscovnipulse.com. It’s a real nice interactive map where you can find useful information. I don’t know if this numbers are accurate, as they rely on volunteer users which install Cisco VNI software, but certainly they are trying to make a good job together. If this forecasts are true or not will see in the future.

Cisco IP Routing Overview – Part IV

Fourth part from IP Routing Overview.

All this material is produced by RouteHub Group consultants, so all the copyrights and greetings have to be directed to them. If was free shared on the Internet so, I hope that I’m not breaking any copyright rules here. All that i want is to make this material more visible on the Internet. This is true also for the more to come materials from them.

If you are curious who is RouteHub Group, I have found this simple explanation on their site: RouteHub Group is a Premium Cisco Consulting provider of Cisco Products, Solutions, Training, and Professional Services for small, medium, and large-sized businesses.

[flv w=640 h=505]https://ipnet.xyz/vid/routehub/Cisco-IP-Routing-part4.flv[/flv]

Please find below:

1st part

2nd part

3rd part

of this presentation

Cisco IP Routing Overview – Part III

Third part from IP Routing Overview.

All this material is produced by RouteHub Group consultants, so all the copyrights and greetings have to be directed to them. If was free shared on the Internet so, I hope that I’m not breaking any copyright rules here. All that i want is to make this material more visible on the Internet. This is true also for the more to come materials from them.

If you are curious who is RouteHub Group, I have found this simple explanation on their site: RouteHub Group is a Premium Cisco Consulting provider of Cisco Products, Solutions, Training, and Professional Services for small, medium, and large-sized businesses.

[flv w=640 h=505]https://ipnet.xyz/vid/routehub/Cisco-IP-Routing-part3.flv[/flv]

Please find below:

1st part

2nd part

4th part

of this presentation

Cisco: The basics about VRF implementation

VRF, meaning Virtual Routing and Forwarding, is a technology implemented in the IP network routers that allows multiple instances of a routing table to exist on the same router in the same time. Since each VRF is independent, the same IP subnet can exist in 2 different VRFs. Basically you can overlap one IP address in 2 VRFs but without conflicting with each other. Even this is possible, I would not suggest doing so, unless you have a very good reason to do it.

Another meaning of VRF is VPN Routing and Forwarding which is a key element in Cisco’s MPLS (Multiprotocol Label Switching) VPN technology. Internet service providers often take advantage of VRF to create separate virtual private networks (VPNs) for customers. Some advantages of  using this technology is than an ISP can provision scalable IP  MPLS VPN services, generate reports (e.g. audit for services), Service Level Agreements (SLA) contracts and more…

To summarize, virtual networks enable administrators to split a physical link into multiple virtual links completely isolated one from the others. Typically, a virtual network will be dedicated to traffic from a specific application or from a specific users / customers.


Now that we clarify the basic of what is and how it works, let’s see where is VRF used the most. As you maybe guess already, this is in the MPLS VPN environment, due to the fact that in today’s business granularity is very important and VRF help network engineers to isolate and provide security for its customers in an ISP environment or to separate services in an Intranet environment. As you probably already know, MPLS functionality is based on P (Provider) routers, PE (Provider edge) routers and CE (Customer edge) routers. Each of these routers must be configured in order for MPLS to work within an enterprise’s architecture. I describe a little bit the MPLS technology, so you can understand better the topology presented below and then following configuration example:

VRF Implementation As you can see from the topology, one PE router can hold and manage multiple virtual routing table, one for each customer that an ISP have. If you are running in a private environment (e.g. Intranet), you can use MPLS VPN to separate services (e.g. office, development…) The  basic functionality is the same and I’ll show you below how to implement VRFs.

The actual configuration of VRFs  is not a complicate task to achieve. There are two main components to a VRF: The route distinguisher(RD) and the route target(RT).

The route distinguisher (RD) is a number which help identify a VPN in a provider’s network and allow for overlapping IP space.

The route target (RT) indicates the VPN membership of a route and allows VPN routes to be imported or exported into or out of your VRFs. The RT functions a little like a routing policy — determining how routes are distributed throughout the particular VPN.

The RD / RT is a 8-byte (64-bits) number which can be written down as follow:

16-bit AS number: your 32-bit number
(e.g.) 65000:100

or

32-bit IP address: your 16-bit number
(e.g) 192.168.0.1:10

Usually the first method is used more often.

For some very basic VRF configuration follow the steps:
1.
Enters VRF configuration mode and assigns a VRF name.

Router(config)#ip vrf vrf-name

2. Creates a VPN route distinguisher (RD) following one of the 16bit-ASN:32bit-number or 32bit-IP:16bit-number explained above

Router(config-vrf)#rd route-distinguisher

3. Creates a list of import and/or export route target communities for the specified VRF.

Router(config-vrf)# route-target {import | export | both} route-distinguisher

4. (Optional step) Associates the specified route map with the VRF.

Router(config-vrf)# import map route-map

5. Specifies an interface and enters interface configuration mode.

Router(config)# interface type number

6. Associates a VRF with an interface or subinterface.

Router(config-vrf)# ip vrf forwarding vrf-name

To check your configuration, you can use ping or traceroute tools under Cisco CLI, but remember that you have to use “vrf vrf-name” parameter:

Router# ping vrf vrf-name IP-address

Also you can check the virtual routing table:

Router# show ip route vrf vrf-name

In some of the following posts, I will present a VRF implementation following a real environment topology, but until then I hope you understood the basics of VRF functionality. It’s not hard to implement (from case to case it might be due to local topologies and technology) but it can help you to have a more granular connections and makes troubleshooting more easy, especially in the environments which have a lot of IP addresses under management.