One of the things that I think is key from separating a good network engineer from a great network enginner is their ability to control the paths which data travels.
As we all know, each routing protocol has built-in best path algorithms, but sometimes, these just aren’t enough. There may be many reasons for an administrator to need to override these routing protocols, in order to do this, you must understand the best path calculation for each routing protocol.
Understanding Best-Path Selection
Key to understanding which route will be installed in the routing table, is understanding how each routing protocol will select it’s candidate to be presented to the routing table.
Once routes are presented from the routing process, to the routing table, the router will select the route with the lowest administrative distance to be installed into the routing table.
[table id=2 /]
Once a route is installed into the routing table, the router will evaluate whether there are any routing policies installed. If a policy based route (PBR) is installed, the router will forward traffic based on that policy. If there is no PBR, the router will forward traffic out the route which has the most specific prefix.
We have two considerations for path manipulation:
- How our router will forward packets.
- How adjacent routers will forward packets.
The easiest part is manipulating how our router will forward packets, the two simplest ways to do this are via PBR and route-maps. After we configure our path manipulation, we have to consider how we want other routers in the topology to forward our traffic. The easiest way to do this is to place route-maps on our outbound routes. In the future, I may start begin referring to routes as NLRI (network layer reach ability information), but mostly just when talking about BGP.
Before we go any further, and delve into actually configuring a solution, we need to understand how each routing protocol selects candidate routes for the routing table. This is extremely important since we need to know what to change to manipulate administrative distances and metrics.
- RIP has a default administrative distance of 120.
- RIP utilizes hop-count to determine its metric, with 1 being the lowest, and 15 being the highest.
- RIP will not present a route to the routing table with a hop-count of higher than 15.
- By default, RIP will only route on classful boundaries, it is important that you enable ip classless at the global configuration level and no auto-summary on the router configuration level. This will ensure that RIP includes the complete prefix, instead of just the classful boundary in its routing update.
- When redistributing routes into RIP, Cisco recommends using a low hop-count (such as 1).
- EIGRP Internal Routes have an administrative distance of 90; external, or redistributed routes have an administrative distance of 170.
- EIGRP Utilizes K-Values for Calculation, by default, the only two used for metric calculation are bandwidth and delay. Cisco recommends not changing this. Note: changing K-values on one EIGRP neighbor will cause neighbor-relationship issues with neighboring routers.
- K1 – Bandwidth (Enabled by Default)
- K2 – Load (Disabled by Default)
- K3 – Delay (Enabled by Default)
- K4 – Reliability (Disabled by Default)
- K5 – MTU (Disabled by Default)
- The bandwidth used for the metric calculation is the lowest bandwidth on any interface in the path.
- The delay is the total time (in tens of microseconds) a packet takes to travel across an interface.
- The full metric formula is:
- metric = ([K1 * bandwidth + (K2 * bandwidth) / (256 – load) + K3 * delay] * [K5 / (reliability + K4)]) * 256
- The simplified metric formula, when using the default K-Values is:
- metric = bandwidth + delay
- When redistributing routes into EIGRP, you must specify the bandwidth, delay, reliability, load and MTU for EIGRP to calculate a metric for these routes.
- OSPF has a default administrative distance of 110.
- OSPF utilizes bandwidth in its metric calculation.
- By default, the reference bandwidth is 100MBps, meaning that any interface with a speed above that, will be seen the same as a 100MBps interface in the eyes of OSPF. It is important to change the reference bandwidth to the highest speed interface installed on your router.
- Reference bandwidth should also be changed on all routers within the same OSPF area.
- All redistributed routes will receive a metric of 20, except for BGP routes, which receive a metric of 1
BGP has the most robust best-path selection process out of all of the routing protocols. BGP will utilize what is referred to as Path Attributes. BGP has about 13 different attributes it evaluates before selecting a best route. BGP will run through this process until there is a definitive winner. This means that if a path wins and evaluation anywhere along the process, it is selected as the best path.
- First and foremost is the Weight, this is generally proprietary to Cisco’s implementation of BGP, the weight attribute is configured by the administrator and is only locally significant.
- The path with the highest LOCAL_PREF attribute. BGP assumes a default value of 100 when no LOCAL_PREF has been specified by the administrator.
- Path Type; BGP will prefer routes learned through the network or aggregate command, before routes learned through redistribution.
- AS_PATH; the AS_PATH defines which autonomous systems the route has past through before it got to us, the route with which traverses the least amount of autonomous systems is preferred.
- Origin Type; this informs BGP whether the route was originated from an IGP, EGP or INCOMPLETE. IGP has the lowest origin code, EGP follows, followed by INCOMPLETE. BGP will prefer the route with the lowest origin code.
- Multi-Exit Discriminator (MED) – BGP will prefer the path with the lowest MED, the MED is used when routes are received from neighbors with the same ASN. If the router received matching routes from neighbors that are not in the same ASN, this will be ignored.
- BGP Neighbor Type; prefer eBGP over iBGP
- Lowest IGP metric; self-explanatory
- Determine whether we need to present two candidates to the routing table (is BGP multi-path enabled?)
- Prefer the path which was received first (oldest path)
- Prefer the path which was received from the neighbor with the lowest BGP router-ID.
- We’ll skip this; not used unless you are in a BGP RR environment. (I’m also not too sure what the hell it means)
- Prefer the path with the lowest neighbor IP address.
The best part about BGP is that it gives us, administrators, the most robust solution to manipulate and engineer traffic in the way we desire. It’s also somewhat confusing, and hard to remember, but don’t be too intimidated, (other than if you’re taking your tests) you can always reference the Cisco support page.
Why Manipulate Paths?
- Despite routing protocols having their respective best-path selection algorithms, there may be instances where the router does not take the actual best path.
- There may be instances where we need to separate network traffic, and route traffic differently based off of it’s source/destination address.
Methods of Manipulation
- Offset Lists; specific to RIP, these will change the outgoing (or incoming) hop-count on a route(I mean, technically you could use them for EIGRP).
- Route-Maps; these are powerful, using these we can change the administrative distance, metric, or other attributes to a route.
- Policy-Based Routing; policy based routing is essentially static routing, however, we can get extremely granular and specify where we are going to forward traffic based off of the traffic type, source/destination IP address, etc.
- IP-SLAs; these are often not considered a method for path manipulation, but can definitely be used as such. IP-SLAs allow us to configure tracked objects and make decisions based off the reach ability, reliability or response time of a path.
- Route Filtering; this will be key in manipulating how we want other routers which we are not directly in control of, to forward traffic.
Example #1: RIP Offset List
This example is going to be extremely simple, given the network topology, we’re going to create an access-control list and apply an offset list to our routes going outbound on a specific interface.
Our objective for this lab is extremely simple, we are going to make sure that R1 utilizes path 1 to forward traffic to the 10.10.10.0/24 network. As we all know, RIP only utilizes hop-count for it’s metric, so although Path 1 has a higher bandwidth, both paths would be seen equally from R1. Due to the fact that both paths would be seen equally, R1 would load balance. This is not a desired action whatsoever, as the traffic share ratio would be 1:1, and RIP would not do what EIGRP does where it will calculate the percentage of packets to be routed out each interface (this is more specific to EIGRPs ability of unequal cost load balancing).
We are not going to make any changes on R1, all changes will be made from R2.
This lab will be utilizing 4 Cisco IOSv 15.6(2)T routers in GNS3. I have posted all the lab files (including diagrams) on the “Lab Files” page, which can be found in the menu bar at the top.
First, verify that the hop-count for the “10.10.10.0/24” network on R1 is 2, also verify that your routing table has two entries for this network:
The first step; creating the access list. For this, we can simply use a standard ACL which matches the network for interface “Loopback 1”.
Router(config)#access-list 1 permit 10.10.10.0 0.0.0.255
After creating the access list, you need to go into router configuration mode for the RIP process on R2; the lab already should have RIP enabled and all the interfaces configured. (I’ll post the initial configs in case GNS3 didn’t export them for some reason). For this network, we’re going to offset the hop-count by 3, going out interface G0/0, which leads to path 2.
Router(config-router)#offset-list 1 out 3 GigabitEthernet0/0
Once completed, do a “show ip protocols”; you will see something along the lines of “Outgoing routes in GigabitEthernet0/0 will have 3 added to metric if on list 1”
If you know somebody at Cisco that could please fix the English on that statement, that would be great. That just perturbs me.
This simply means that if the network is in the access-list 1, and being sent out interface GigabitEthernet0/0 we will report the hop-count as 3 to R3; thus ensuring that path 1 is the preferred path to this network. To verify this, console into R1 and do a traceroute to the 10.10.10.0/24 network, you should see it traverse through R4.
That was pretty simply, though when using RIP, remember to keep in mind that RIP will not present a route to the routing table if it has a hop-count of higher than 15. This means you can’t offset the route too much, especially if your network has alot more hops than this lab does.
The syntax for the offset list is as follows:
offset-list [acl-name] [in | out] [0-16] [interface-name]
The 4th argument is the hop count which you want to offset, and the final argument is optional (though pretty pointless if you don’t do it, for RIP anyway.)
Example #2: EIGRP Policy-Based Routing and Offset Lists
In this example, we’re going to go with pairing a few things together to get granular control over the path traffic takes. As we all know, EIGRP utilizes bandwidth and delay in it’s calculations, important to know here is that it will use the default interface bandwidth and delay, unless otherwise specified. Sure, it’s absolutely easy to change that, but that’s not the point of this lab. The point of this lab is to show you different ways in which you could manipulate the path for which you want data to travel.
For this lab, we are going to a 6 router topology. All links will be connected via gigabit ethernet, so EIGRP will calculate the same metric for all paths. Given the topology, ensure that voice traffic will always flow over the most desirable path. You will need to do so without configuring interface bandwidth or delay, and you do not have control over any router other than R2. (Well, you can console into all the other routers just to verify, but you cannot configure anything on them).
The first thing we will need to do is create access-lists for the voice and user networks, we will reference these throughout multiple parts of our lab.
ip access-list standard User-Network
permit 10.10.25.0 0.0.0.255
ip access-list standard Voice-Network
permit 10.10.24.0 0.0.0.255
The first part we’re going to do is create multiple IP SLAs and tracked object. These will give us the ability to monitor the reachability of a network over a certain path. Our first tracked object will monitor the interface on R1 over path 3, the second will monitor the interface on R1 over path 1.
ip sla 1
icmp-echo 10.10.10.9 source-interface GigabitEthernet0/0
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 10.10.10.1 source-interface GigabitEthernet0/1
ip sla schedule 2 life forever start-time now
After defining the IP-SLAs, next create the tracked objects which are linked to these SLAs, these will allow us to define specific actions based on the state of the tracked object.
track 1 ip sla 1
track 2 ip sla 2
We have set our IP-SLAs to change their state to failure if they are not able to ping the destination within a 6000 millisecond timeframe.
To view the statistics of your IP SLAs:
show ip sla summary
show ip sla statistics
To view the state of our tracked objects:
For our route-map, we are going to utilize sequence numbers. Sequence numbers are used in access-lists, but also route-maps. Think of route-maps as ACLs for how we want to manipulate routing. If a packet does not match anything defined in the match claw within a sequence, then the router will proceed to the next entry in the route map. If nothing is matched, it will route based off of the routing table.
For our route-map, we’re simply going to match the source IP, and set the next-hop (there are plenty of other things we could do as well, but just trying to show you examples). For our “set ip next-hop” clause, we are going to utilize the “verify-reachability” argument. This will allow us to link the action to a tracked object, the route map will only set this as the next-hop if the tracked object state is “UP”. We will use multiple set entries to set the backup next-hop to R5.
route-map RM-EIGRP-PBR permit 5
match ip address Voice-Network
set ip next-hop verify-availability 10.10.10.22 1 track 1
set ip next-hop 10.10.10.18
route-map RM-EIGRP-PBR permit 10
match ip address User-Network
set ip next-hop verify-availability 10.10.10.14 1 track 2
set ip next-hop 10.10.10.18
Something to note about route-maps is that multiple match clauses, on the same line are viewed as logical OR statements.
Match statements on different lines are viewed as logical AND statements
After you define the route-map, you must apply it to the interface on which we are going to match the inbound traffic, this would be GigabitEthernet0/2. Do this with the command (from interface configuration level):
ip policy route-map RM-EIGRP-PBR
At this point, if you were to ping R1 with traffic sourced from the User network, it would take Path 1, and voice would take path 3. If you want to see R2 forwarding this traffic, enable the below command and send traffic from R3 to R1 sourced from one of our loopback interfaces.
debug ip policy
For manipulating our metrics, we’re simply going to do what we did earlier with RIP, and use offset lists. These offset lists will reference the ACLs we already created earlier.
This is extremely simple. On G0/3, we’re going to offset the voice and user networks by +1000, on G0/0 we’re going to offset the User network by +2000 and on G0/1, we’re going to offset the voice network by +2000. Note that for outbound updates on G0/3, we will have to create a new ACL which contains both the User and Voice networks.
ip access-list standard User-and-Voice-Network
permit 10.10.24.0 0.0.0.255
permit 10.10.25.0 0.0.0.255
Next, hammer down into the router subconfiguration mode for the EIGRP proccess and apply those offset lists:
offset-list User-Network out 2000 GigabitEthernet0/0
offset-list User-and-Voice-Network out 1000 GigabitEthernet0/3
offset-list Voice-Network out 2000 GigabitEthernet0/1
Please note that as part of my initial configuration, I emplaced a route-filter on R1 to ensure that the transport routers (R4,R5,R6) do not receive routes for the User or Voice network from R1.
Now that that is done, you can console into R1 and do a show ip route, you will notice that there is no longer 3 entries in the routing table. You will notice that the user network is seen best out of G0/0, and that the voice network is seen best out of G0/1.
Next, let’s verify our PBR by shutting down G0/0 on R6. Once complete, just wait a few seconds and do a “show track”, you should see a changed state for the tracked object. This should also come up as a syslog message.
Just verify that our PBR is working by pinging from Lo2 on R3 to anything on R1. Keep the “debug ip policy” running on R2. This is what your output should look like. On R2, you should see the router setting the gateway, or next-hop to 10.10.10.18
I hope you liked these two examples, and the discussion on path manipulation. Even if this example doesn’t exactly make the most sense, I think it still shows the variety of possibilities we have when configuring path control. There’s alot you could do with path manipulation and it isn’t limited to outbound routes either. We could easily manipulate inbound routes based on a number of properties.
One cool thing that I want you guys to see real quick is that you can tag routing updates with a a value in either decimal format, or dotted decimal format. This is great for EIGRP because by doing this, on the origin router, I can basically tell any other routers within the topology who originated these routes and then filter or modify metrics based off of that.
Hint: I really like the AS_PATH attribute in BGP, because it just makes sense that I want to see who originated these routes.