This is a going to be a more general 'chat' around pushing packets about the network and avoiding the usual IGP routes you may or may not have messing you up. I've prepared a small topology of 6 routers. Each router is connected via multiple routes using ethernet and serial interfaces. Some interfaces have OSPF running and they are all in the backbone area 0 with no costs so it's all vanilla. This is going to look WAY too much for such a simple demo - it's part of a bigger picture.

Screen shot 2011-07-17 at 22.56.53

So here is the plan:

  • Lets build this lot up and just switch some costs to prove that we can manipulate the flow of traffic using the IGP.
  • Lets change some of the links to use a different OSPF area and show how that affects the flow of traffic.

We're only really interested in the 'journey' of the packet so lets take a look at the IP address on R1 and R6 first

R1's 'show ip interface brief'

show ip interface brief R1

R6's 'show ip interface brief'

show ip interface brief R6

So we'll just have a look at the routing table on R1

show ip route R1

See how R6 Lo0 interface 6.6.6.6 is via 10.1.123.3 and 10.1.123.2 which are R3 and R2 respectively? Thats because it costs the same for packets to get from R1 to R6 via both of these directions (oh and CEF is on). Lets do a traceroute. Now before you look at the output remember that a traceroute sends three packets out for each hop. With us load balancing across R2 and R3 we'll see and ICMP response from R2 and R3 as the packet is load balanced...fingers crossed.

trace 6.6.6.6 on R1

So we're going to change the cost for the FastEthernet1/0 interface on R2 between R2 and R4 to make it more expensive for traffic to go that way, OSPF should send an LSA update to the DR on the R1/R2/R3 segment to tell everyone else that R2 is definitely NOT the way to go. We'll see this on R1 when we look at its routing table and see that equal costed route to the Lo0 interface on R6 (6.6.6.6) is no longer shared between R2 and R3. Lets have a quick look at the cost on the interface right now using the 'show ip ospf interface fa0/0' command...useful that one.

show ip ospf interface cost

OK so it's one. If we double that then it'll remove the 'load balanced' route from R1's table. We'll increase it from '1' to '2'

change interface ospf cost

Right lets look at the routing table on R1. This is how it looked before the change...see the two routes out?

show ip route 6.6.6.6 with two routes out.

So now this is how it looks after the cost change.

shwo ip route 6.6.6.6 with one route out now

Right...just the one now. We could do a trace just to show it's only one way out.

trace to 6.6.6.6 from 1.1.1.1

OK, cost done...you see how that works? Why did we change the cost of the interface facing away from R1 and not the one closest to it? Well it uses the 'local' cost value to build the view of the world. So far as R1 is concerned it's a cost of 1 between it and R2 so even if R2 has a locally configured cost of 2 R1 won't listen to that. That cost for 2 would however be useful to R4 when it was learning about routes from R2 learned via that interface.

Right lets put the cost back and change the area between R2 and R4 to area 1 rather than area 0 and see if that affects the routing table at all. This WAS the routing table BEFORE the area change...two routes...all good. Now lets but the point to point link into area 1.

show ip route 6.6.6.6 from R1


OK so we'll just show the screen shot from R2 here but believe me when I say we moved from area 0 to area 1 on that point to point link. The adjacency comes up anyway...all good. Lets see the OSPF topology on R1.

network between R2 and R4 area change

OK so now the link between R2 and R4 is in OSPF area 1 but we've put all the other costs back...there is nothing wrong with the links...they are equal and the same.

show ip route 6.6.6.6 from R1

So check that out - OSPF really loves the same area and no matter how poor the cost, another route learned from an IA (inter area) will be less valued. It will choose a route via the same or backbone area over any other NO MATTER HOW AWFULLY costed it is. If you ran the same area link over barbed wire through a wet field it would win over an IA route learnt over a 10GE DWDM ;-)

Good luck with your studies.
View Comments
So lets just cover off one of the great things about distance vector routing protocols like RIP and EIGRP. To prevent loops in routing tables they use something called ‘split horizon’. The basic rule is this, “never pass on a route learned from one interface back through that same interface”. Scott Morris states this in this way “never tell a joke back to the person you just heard it from, it never has the same effect”. Split horizon works great for broadcast networks, but the behavior is not quite so useful in non-broadcast networks like frame relay, lets have a look at a few examples.

Broadcast network



Here is our broadcast network with three routers we’ll have say R1, R2 and R3 (see diagram below). Each router is connected to a switch using interface Fa0/0 sharing subnet 150.1.1.0/24. Each router is also configured with a loopback interface (Lo0) with an IP address significant to their hostname e.g. R1 is 1.1.1.1/24, R2 is 2.2.2.2/24 and R3 is 3.3.3.3/24.

Screen shot 2011-06-15 at 00.06.37


Now, each of the routers advertise their connected networks using RIP.

Here is the configuration for R1’s RIP process. You can see we’ve enabled version 2 and disabled auto-summary but it doesn’t matter for the purpose of this demonstration. TIP: the sh run | s rip’ command is us asking the IOS parser to look for the RIP section (s rip) in the configuration.

Screen shot 2011-06-15 at 00.06.07

R1, R2 and R3 each have a copy of the RIP database containing all of the routers. Crucially however none of the routers advertise learnt networks back out of their networks connected to the switch , they only send their directly connected networks. This is because, as the split horizon rule dictates, we are learning the other networks via a broadcast interface so it is un-necessary to send that same learned route back out. If we did that then we would be advertising routers to neighbors which we didn’t have connectivity to.

For example, what if we disabled split horizon on R2. It would advertise connectivity to R3 and R1’s loopback interfaces. Of course those RIP adverts would have a metric (hop count) of one more than the best route but what if the best route was lost? In this case the route advertised from R2 would be the new ‘best route’ and since R2 doesn’t actually have any connectivity to the R1 or R3 loopback interfaces the traffic would get to R2 and be dropped. All of this is possible because of the painfully slow convergence timers in distance vector protocols like RIP. Indeed the dead interval is 3 minutes and the flush timer 4 minutes! Now then, it’s not all bad news. RIP does also have another very clever way of telling all connected RIP hosts on the same broadcast network that something bad has happened and you must flush your RIP tabels immediately (usually because an interface has gone down). This type of ‘triggered update’ is called ‘Poison Reverse’. This ‘poisoning’ of a lost route basically advertises an immediate route update for the lost network with a metric (hop count) of 16 which means ‘inaccessible’ - job done.

Lets see the poison reverse in action here We’ll shut down the loopback0 interface on R1. Our debugs are running on R2. Watch as R1 sends out the update for the lost route to 1.1.1.0/24.

First;y here is a normal update from R1 - notice it learned it from 150.1.1.1 which is R1’s interface closest to R2.

Screen shot 2011-06-15 at 00.28.56

Now we’ve just shutdown the lo0 interface on R1. It immediately sends out an update telling us that route is dead (hop count 16).

Screen shot 2011-06-15 at 00.29.38

Now we (R2) send an update ourselves, basically passing on the bad news to all other RIPv2 (we send it to 224.0.0.9 which is the multicast address used by RIPv2)

Screen shot 2011-06-15 at 00.29.54

We also ‘hear’ the bad news from R3 who also, like us, passed it on...hey bad news does travel fast even in RIP.

Screen shot 2011-06-15 at 00.30.13

Right, this is all good fun, but what about split-horizon? Well, you know, the best place to see split horizon NOT working well for us is on a frame relay network...so lets do that instead.

Split Horizon on Frame Relay multipoint networks.


Here is the topology. In this example, R1 is the frame relay hub with R2 and R3 as spokes.

frame

The network has been configured using 150.1.123.0/24 between the two spokes and the hub. We’ve configured RIP on each of the routers and split horizon is enabled on each interface. Lets take a look at the routing table on R1.


Screen shot 2011-06-15 at 00.42.40

OK, this is perfect. We see learned routes for the loopback interfaces of both R2 and R3. Right so now we’ve enabled a routing protocol and we’re injecting the loopback interfaces into RIP then R2 should have routes to R1’s lo0 and R3’s lo0 and R3 should have routes to R1’s lo0 and R2’s lo0 right?

Well lets see. First on R2.

Screen shot 2011-06-15 at 00.46.17

Hmm - well I see R1’s lo0 network but I don’t see R3’s lo0.

What about R3?

Screen shot 2011-06-15 at 00.46.51

OK, so just like R2 I only see R1’s lo0 interface.

Well unless I fix this I won’t be able to ping all of the loopback interfaces. The answer to the problem is easy though. In our example R1 is the hub of a frame relay network. The RIP routes are being learned from R2 and R3 via one interface on R1 (S2/0.123). So, go back to what we know about split horizon. The fact that is that routes are being learned from R2 and R3 and then those routes are not sent back out of that same interface!

This behaviour is not ideal right, luckily however we can override split horizon. We need to disable split-horizon on that serial interface for the hub on R1. Lets do that now.

Screen shot 2011-06-15 at 00.50.10

Now lets take a look at the RIP database on R2 (show ip rip database)

Screen shot 2011-06-15 at 00.50.42

Cool, now I see the lo0 network from R3. Notice that it was learned from R1 though. R1 has passed it on? Of course we’re on a non-broadcast network and R3 and R2 and not directly connected with their own DLCI so R1 is the man in the middle here.

Lets take a look at R3’s routing table

Screen shot 2011-06-15 at 00.52.36

Nice one, we have a network for R2’s lo0 interface.

Thats it for this article on split horizon

Thanks for reading

View Comments
RIP is a classful routing protocol, it doesn’t do CIDR (Classless Inter-Domain Routing). So is a defaultroute a classless or classful entity? In this article we’ll get one RIP router to advertise the default route to another RIP neighbor using static routes, an IGP, redistribution and then the ‘default-information originate’ approach. Lets move on, here is the network topology. It’s a little overkill but we used this same design for a video which we’ll be posting up soon.

rip_topology_scale


We’ll begin by configuring a basic RIP setup on R1 and R5. The RIP default will be sourced from R1 and sent to R5.

Here is the basic configuration to enable the RIP process and enable it on the network segment between R1 and R5. Notice the new (ish) pipe command ’s’ this is short for section. We’ve put the loopback0 interfaces for R1 and R5 into RIP - notice the network masks both both of these? The loopback interfaces are 1.1.1.1/24 and 5.5.5.5/24 for R1 and R5 respectively and yet in the RIP process the network statements are 1.0.0.0 and 150.1.0.0. There is no netmask statement to support the 24 bits of network so how does RIP know what to advertise? Well in fact version 1 of RIP would not be able to help here but version 2 (which we have enabled) does support VLSM and can send the netmask of associated with the ‘network’ of the interface configuration along with the advertisement of the route...phew. RIP is CLASSFUL, it’s not something you want to run in a modern network necessarily. We’ve also disabled summarisation to stop RIP sending the classful route...it will do it automatically so we need to do this if we have shared networks advertised (for this example it is unnecessary)

Screen shot 2011-06-09 at 02.04.31

Screen shot 2011-06-09 at 01.57.34

Right, lets have a look at the routing table on R1 and then on R5

Screen shot 2011-06-09 at 02.05.35

Screen shot 2011-06-09 at 02.05.45

See how RIP, because of the CLASSFUL network issue has advertised the networks between R1 and R2, R1 and R4 and R5 and R4? On a production network you can see how it might get out of control sending more routes than you actually wanted to? To stop this happening we’d normally apply the ‘passive-interface’ command to stop the router sending router updates to it’s neighbors on that shared interface. If you wanted to stop the router receiving the routes you would use a distribute-list or access-list denying UDP port 520 inbound.

Right do we want a defaultroute sending from R1 to R5 (and other neighbors). First we need R1 to have a defaultroute in it’s routing table, without it RIP will not send a defaut route it HAS to already be in the routing table.

Firstly lets send the default using static routing. We’re going to put a static defaultroute into R1’s routing table and point it at the null0 interface - you wouldn’t want to do this unless you wished to blackhole traffic to networks which were not in your routing table. Remember packets trying to get to unknown networks are dropped...this may be desirable...up to you.

Screen shot 2011-06-09 at 02.14.19

Lets take a look at R1’s routing table

Screen shot 2011-06-09 at 02.14.29

Lets take a look at R5’s RIP routes in the routing table to show you that static routes don’t just jump into the RIP process - we have to redistribute between routing protocols don’t we ;-)


Screen shot 2011-06-09 at 02.15.26

Right so lets do that redistribute step now. We want to take that static route to null and pop it into RIP. Remember RIP routes are sent as full updates every 30 seconds so we’ll just wait...OK here is the ‘debug ip rip’ output.

Screen shot 2011-06-09 at 02.24.18

Great news - lets take a look at the routing table and see if the default route is in there now.

Screen shot 2011-06-09 at 02.25.04

Nice BA.

OK so I just thought of something we can do here. The redistribution line allows us to do things like add hop count (metric) into the updates...lets take a quick look at that. Remember the metric right now is 1 (we’re one hop away).

Screen shot 2011-06-09 at 02.26.37

Here is the debug on R5

Screen shot 2011-06-09 at 02.27.29

Excellent - you know what though...I told you RIP full updates are sent every 30 secs but this arrived a second after I told R1 that the redistribution should have a metric of 5. Well this is a great feature of later versions of RIP called ‘triggered updates’. This type of update is sent immediately when there is a change rather than waiting.

NOTE: there is a cisco proprietary version of triggered updates which can be used between peers across point-to-point interfaces. This type of update differs in that no updates are ever sent unless their has been a change at which point only the routes which have changed are sent. It reduces update traffic across what could be a slow circuit.

Right so the metric is reflected in the routing table? Yes indeed [120/5] shows administrative distance 120 (default) and a metric of 5.

Screen shot 2011-06-09 at 02.32.26

So that was redistribution but there is another way to get the default sent and thats using ‘default-information originate’. Using this method we get a little more control using route-maps and conditional advertising. Lets move on with this.

First we’ll tear down the static redistribution and check the route is gone from R5:

Screen shot 2011-06-09 at 02.34.28

Trust me - the route is gone from R5 - screenshot overload ;-)

Right lets configure the default originate - make a note - we still need the default route to be alive on the router, no default in table = no advertising default

Screen shot 2011-06-09 at 02.36.02

Here is the debug on R5...see the 0.0.0.0/0 coming in

Screen shot 2011-06-09 at 02.37.27

Lets do a show ip rip database on R1 to see it is redistributing the default route (default originate is still a redistribution)

Screen shot 2011-06-09 at 02.38.35

So we have the route in the table but before we close down here lets have a think back to what I was saying earlier about blackholing the traffic. Remember, if we don’t have a route with a shorter prefix than the default then we’re going to drop those packets right here. Now that may be what you want but it’s more likely that you’re advertising a default route because you want traffic to come to R1 because R1 is a gateway for your network e.g. a router before the internet. So lets think about it, if R1 is connected to the internet and we are advertising a default route to our internal routers so they send their packets to us...thats great. What if R1 loses connectivity to the internet though? All of that internal traffic is still going to be racing to R1 which is wasting bandwidth and ultimately unnecessary.

RIP default-information originate can help us out here with a technique called conditional advertising. To do this we use a route-map.

The route-map will ‘look’ for the existence of a route and if that route drops out then we’ll stop advertising the default...sound right to you? Well in our example we are going to say that the interface connected between R1 and R2 is the uplink to the internet. I’ve configured a basic OSPF neighbour relationship between R1 and R2 and R2 is sending it’s loopback0 network (2.2.2.1/32) to R1. Sp, if we see the OSPF router for 2.2.2.2/32 go away then we will suggest that our link to the internet has gone away and we will want to stop advertising the default route. OK lets get on with it then. Here is the OSPF route in R1’s routing table

Screen shot 2011-06-09 at 02.59.18

First we setup the route-map. We want to match the route for the OSPF route learned from R2 - 2.2.2.2/32. A standard access-list will match the IP address for the network. The route-map matches existence of that route.

Screen shot 2011-06-09 at 02.59.12

Lets add that route-map to the conditional default-route advertisement.

Screen shot 2011-06-09 at 03.01.53

Right - lets check...is the default route in R5’s routing table?

Screen shot 2011-06-09 at 03.03.01

Ok, lets shutdown the interface to R2. We see the OSPF go down, the route is gone.

Screen shot 2011-06-09 at 03.03.44

The route has gone from R5...job done

Screen shot 2011-06-09 at 03.04.07

Ok, that wraps it up for this tech article. We’re doing these all the time, be sure to keep checking back.

Thanks for reading

View Comments

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.

Screen shot 2011-05-08 at 23.45.30

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.

Screen shot 2011-05-08 at 23.51.09

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

Screen shot 2011-05-09 at 00.01.52

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

Screen shot 2011-05-09 at 00.03.30

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

Screen shot 2011-05-09 at 00.03.41

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...

Screen shot 2011-05-09 at 00.08.44

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

Screen shot 2011-05-09 at 00.10.14

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

Screen shot 2011-05-09 at 00.10.49

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.

Screen shot 2011-05-09 at 00.15.24

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.

Screen shot 2011-05-09 at 00.17.30

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.

Screen shot 2011-05-09 at 00.19.13

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

Screen shot 2011-05-09 at 00.20.00

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

Screen shot 2011-05-09 at 00.21.19

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...

Screen shot 2011-05-09 at 00.20.39

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

Screen shot 2011-05-09 at 00.23.14

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.

Screen shot 2011-05-09 at 00.31.51

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

Screen shot 2011-05-09 at 00.33.07

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)
Screen shot 2011-05-09 at 00.34.33

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


Screen shot 2011-05-09 at 00.36.25

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.

Screen shot 2011-05-09 at 00.37.14

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


Screen shot 2011-05-09 at 00.38.50

Now R2

Screen shot 2011-05-09 at 00.39.35

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.

Screen shot 2011-05-09 at 00.44.12

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

Screen shot 2011-05-09 at 00.44.42

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


Screen shot 2011-05-09 at 00.45.47

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.

Screen shot 2011-05-09 at 00.48.19

So lets check those EIGRP routes once more.

Screen shot 2011-05-09 at 00.49.32

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

Screen shot 2011-05-09 at 00.50.14

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.

Screen shot 2011-05-09 at 00.59.43

Now R3

Screen shot 2011-05-09 at 01.00.07

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

Screen shot 2011-05-09 at 01.01.16

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.

Screen shot 2011-05-09 at 01.03.54

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

Screen shot 2011-05-09 at 01.12.11

Now lets have a look at the routing table.

Screen shot 2011-05-09 at 01.11.22

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

Screen shot 2011-05-09 at 01.11.58

Lovely, and on that note it’s goodbye from me.
View Comments
© 2011 defaultrouteuk.com

Cisco, IOS, CCNA, CCNP, CCIE are trademarks of Cisco Systems Inc.
JunOS, JNCIA, JNCIP, JNCIE are registered trademark of Juniper Networks Inc.