Influencing traffic using your IGP

A basic starter showing a few of the more simple ways to manipulate your traffic

The topology has been set as shown here. The customers preferred path between R1 and R5 is via R2 and R3 NOT R4. The customer has no control over R5 or the links connected to it and you are asked to influence the traffic coming from R1’s loopback interface (1.1.1.1) to R5’s loopback interface 5.5.5.5. The customer is clear that you are to use no static route to meet the requirement.



R1 f0/0 <-> f0/0 R2 (10.12.1.0/24)
R2 f1/0 <-> f1/0 R3 (10.23.1.0/24)
R1 f1/0 <-> f1/0 R4 (10.14.1.0/24)
R4 f0/0 <-> f0/0 R5 (10.45.1.0/24)
R5 f1/0 <-> f0/0 R3 (10.35.1.0/24)

Starting with a clean sheet, this is the routing table for R1. You can see that OSPF has been configured throughout the topology and that each router has advertises it’s loopback 0 interface.



The routing table here shows that the route to R5’s loopback is via the next hop of 10.14.1.4 or R4’s FastEthernet1/0 interface. So what are the options (this list is not exhaustive and is to show some of the more obvious ones).

• Influence the OSPF calculation by manipulating bandwidth
• Influence the OSPF calculation by adding a ‘cost’
• Change the next-hop using a route-map
• Use default route and filter out the network route
• Introduce a lower metric routing protocol to override the OSPF metric
• Create a tunnel to bypass the normal routing table

Influence the OSPF calculation by manipulating bandwidth

Now normally OSPF uses the SPF Djikstra algorithm to calculate the best path through a network. To include some sort of capacity indicator into this OSPF uses
a ’reference bandwidth’. The default reference bandwidth is 100Mbps and so for a Fast Ethernet interface running at the default speed of 100Mbps would create an
OSPF cost of 1 (100/100=1). Our screenshot above clearly has a metric of 3 for 5.5.5.0 via 10.14.1.4. This is because the traffic has hopped from R1-R4 then R4 to R5 then R5 to R5’s loopback interface (yes thats a hop too). So if we want the traffic to go via R2 instead then we need to make R4’s interface bandwidth lower. Lets choose a bandwidth of 10000 or 10Mbps. By the way, you can change the denominator and accumulator in this equation! The relative OSPF bandwidth is changed under the
OSPF process using the ‘auto reference-bandwidth’ command (remember the default is 100)

First take a look at the default bandwidth figure - denoted here as BW



Now we’ll change the interface closest to R5, remember the cost is additive for the path.



Now lets take a look back at R1’s routing table for the R5 loopback interface.



Now the path is via R2’s Fa0/0 interface. Why? Because we made OSPF add a cost of 10 for the route between R4 and R5 so now the route via R2 and R3 has a lower metric of just 4.

Influence the OSPF calculation by adding a ‘cost’

We’ve reset the bandwidth on the R4 interface and R1 now has a preference back to R4 with a cost of 3. One of the quicker and neater ways to influence OSPF is to use the interface level ‘ip ospf cost’ command. This command overrides the reference bandwidth and interface bandwidth calculation. In this case, whichever is the lowest cost wins.

Lets change the cost via R4 on R1. First lets just check we’ve got the right metric via R4...



Now lets apply the interface cost command to make R4 a really bad choice...



Confirm the routing table once more to be sure we’re preferring R2 again...



Great...all going well so far.

Change the next-hop using a route-map

Route-maps are really really powerful tools and you are going to use more and more of them especially if you are keen on the CCIE lab exam. For our little lab we’re going to use a route-map to match some traffic and force it to bypass the normal routing table. Now normally when packets are routed they lookup the next hop int eh table etc etc. With a route-map we can force the next-hop to be different from the norm. So long as the next-hop is in the routing table we can send that traffic anywhere.

Lets do it. First of all we blow away the config from the previous lab.

Lets create teh access-list we are going to use to catch the traffic we need for the next hop. We just want traffic from our loopback0 interface going to R5’s loopback, everything else should take the normal route.



Next we create the route-map statement which uses our access-list to match the traffic then the ‘next-hop’ statement to force the next hop for that traffic.



One final thing. Because we are trying to influence traffic sourced on our router we need one other command. For traffic passing through our router this is not necessary and instead we use the interface level ip policy route-map’ command.



So lets have a look at the routing table, it should be normal with the route to R5’s loopback still going via R4...



Yep looks good....so what if we do a traceroute to R5?



Yeah thats right...is it what YOU expected? Hopefully you’ve been following along. Recall that we setup the route-map ONLY to match traffci from our loopback going to R5’s loopback? Well that traceroute just picked up the closest route to R5’s loopback. We’ll run the command again but this time source it from R1’s loopback...



Awesome, you see it went via R2! Lets check the access-list to make sure we are hitting that...



9 matches? How come? Well traceroute will send 3 ICMP per hop you can see that in the output where 10.12.1.2 got 4 millisec, 12 millisec and 4 millisenc responses. Anyway...it worked for us ;-) Lets move on.

• Use default route and filter out the network route

I’m really proud f myself for thinking up this crazy ‘fix’. So lets have a quick time out to think this through. In the routing table, the route with the best match will be active. That is to say, if you have a more specific route to somewhere then that route will take precedence. So what am I talking about here? Well we want to go via R2 right? ut the specific route for 5.5.5.0/24 is being advertised from R4. So here is what I propose. Lets filter out the network 5.5.5.0/24 from coming into the routing table of R1 (remember we can’t filter the route from the OSPF table but we can stop it being placed into the active routing table). At the same time lets inject a default route from R2 so that R1 gets a defaultroute for all networks it doens’t know about pointing at R2. All being well because R1 won’t have a route to 5.5.5.0/24 anymore it should use the default? Clear? Lets go!

First off lets create the default route on R2. Now remember, we don’t already have a default route int he table so we use the ‘always’ keyword here to advertise teh default route even though we don’t already have one.



Lets just check we have that route in R1’s table.



Yeah you can see we have it right at the bottom, we also still have the 5.5.5.0 route via R4 so lets remove that now with a ‘distribute-list’. The distribute list works on matching values from an access-list. We create a standard access-list 2 and tell it to DENY 5.5.5.0/24 but permit everything else. The second line is important because without it the distribute list would block all routes coming in (remember the default action of an access-list is DENY)


So we’re denying 5.5.5.0/24 and permitting everything else...did it work?




Well we’ve got rid of the route to 5.5.5.0/24 and we only have the default now...so lets see what path we take to get to R5’s loopback now.



Perfect, lets move on.

Introduce a lower metric routing protocol to override the OSPF metric

OK so OSPF has a distance of 110 by default on the router. That means it has a precedence over any routing protocols with a higher distance. So who is lower? Well in the IGP world the most obvious choice here is EIGRP with an AD of 90. So lets crack on and put EIGRP between R2 and R1 and try to influence the traffic.

First lets enable EIGRP on R1




Now R2



Great, we see the adjacency come up. There won’t be any routes in the table yet however because we didn’t add any network statements yet except their shared subnet. So lets now redistribute the OSPF route for 5.5.5.0/24 into EIGRP. Remember, the plan here is to advertise a route using EIGRP between R2 and R1 which will override the OSPF route being advertised from R4 to R1 (and R2 to R1).

So lets create an access-list to match the route we want to redistribute from OSPF into EIGRP. Then we’ll create a route-map then we’ll go into the EIGRP process and redistribute. The numbers after the redistribution are the all important EIGRP K values. We need to seed them with numbers or else the route will NOT go into EIGRP.



So lets make sure we’re redistributing now with a ‘show ip route 5.5.5.0 on R2



Perfect! Now R1 should have an EIGRP route in it;’s table for 5.5.5.0 with a distance of 90.




Hmm, no routes from EIGRP?! Whats gone wrong here?! Well, actually nothing went wrong here. The thing about EIGRP is it has two distances, one for internal routes and one for external. Anything redistributed into EIGRP gets the external distance and guess what, that distance is 170...man thats 60 more than OSPF so it’s not int he table. What can we do? OK so distance is only relevant to the local router so lets be kind to ourselves and just change the distance for EIGRP external routes on R1. The first number is the distance for internal routes and the second for external routes. What we are saying here therefore is every EIGRP route has a distance of 90 on this router.



So lets check those EIGRP routes once more.



Perfect...and a traceroute just to be sure...



Excellent, lets move on.

Create a tunnel to bypass the normal routing table

We love tunnels, tunnels are good, tunnels save time and are cool (unless you get cyclical routing but lets not worry too much about that yet). Lets recap on what we are trying to do here. Get traffic to bypass R4 from R1’s loopback to R5’s loopback. So how about we create a tunnel from R1 to R5? Well that would be good because it’s a tunnel but unless we do something about the next-hop like we did earlier then the tunnel will go across R4. We could do some great service provider stuff using VFR’s and MPLS but again, maybe it’s overkill. We don’t even have control over R5 so we can’t even create a tunnel if we wanted to.

So the best we could do here is create a tunnel from R1 to R3 then we could set the cost of the link to the same as R4 and then maybe get some awesome equal cost load balancing going on...hey 50% is better than none. Lets give it a shot.

First on R1 lets create the tunnel interface. You could choose the loopback interfaces as the source and destination - I’ve chosen the interface for brevity and OSPF cost reasons.



Now R3



So a ping from R3 to the ip address of R1’s tunnel0 interface?



Great, now we’ll put the network into OSPF - ouch recursive! We get this because I’m learning about 10.23.1.0/24 from the tunnel interface but also I need to learn how to build the tunnel interface by finding the route to 10.23.1.0/24...I can’t do both. It’s the whole chicken and egg thing! So we setup an access list like before denying 10.23.1.0/24 from being learnt via the tunnel interface.



OK all stable now and tunnel is up so lets set the OSPF cost to match the route via R4.



Now lets have a look at the routing table.



Great two equal cost routes as expected, one via R4 and one via Tu0...what about a ping then?



Lovely, and on that note it’s goodbye from me.