BGP has a number of metric affecting values, one of the most often ignored is origin although it can have a serious effect on your routing table. Imagine getting two routes from two eBGP neighbors. ISPA is connected to CUSTOMER_Z using OSPF and redistributes those learned networks into BGP then advertises those to it's other upstream peers. ISP_B on the other hand is also connected to the same CUSTOMER_Z however ISPB decides to bring those OSPF networks into the BGP RIB using the 'network' statement. The upstream BGP peers will receive two routes into their RIB one with an origin of i (the one from the ISP_B) and one with origin ? (the one from ISP_A).

BGP uses a number of 'tiebreakers' to decision the best route to a destination and here are the first 5; Weight (Cisco proprietary), Local Preference, AS-PATH length, Origin, MED. So origin comes right after AS-PATH length and actually is the second highest decision maker for your outbound traffic...it really matters.

So in this tech guide we're going to build a small 3 mode network. The diagram below shows two BGP autonomous systems. 65001 contains R1 and R2 and they are connected with the network 12.1.1.0/24. R3 is in another AS with number 65002. The network between R2 and R3 is 13.1.1.0/24


Screen+shot+2011-05-19+at+13.59.24


Here is the output from R1 showing first the ip routing table and then a 'show run' for the interface connected to R2

Screen+shot+2011-05-19+at+14.03.20


Here is the same output for R2. Note that R2 is connected to R1 via Fa0/0 and R3 via Fa0/1

Screen+shot+2011-05-19+at+14.03.05


Finally the same output for R3

Screen+shot+2011-05-19+at+14.01.46


OK so we have IP comms between R1, R2 and R3. Now we're going to configure the BGP relationships.

First we'll add the neighbor statement on R1 for R2 (remember we already enabled the BGP process by issuing the 'router bgp 65001' global configuration command.

Screen+shot+2011-05-19+at+14.03.53


Now we do the same for the other side of this neighborship on R2 pointing to R1

Screen+shot+2011-05-19+at+14.04.21


Note that both have the same AS# because they are iBGP neighbors. We see now that the neighbor relationship is 'Established'

Screen+shot+2011-05-19+at+14.04.31


OK so now lets setup the eBGP relationship between R2 and R3. Firstly on R2

Screen+shot+2011-05-19+at+14.05.24


Now on R3

Screen+shot+2011-05-19+at+14.05.46


Note the difference in AS# between that configured in the 'router bgp' and the 'remote-as' this is an eBGP relationship. We get this console message on R2 - the neighborship is Established.

Screen+shot+2011-05-19+at+14.06.12

So lets create our first 'network' to advertise via BGP from R3. We'll just use a loopback interface, here it is loopback0.

Screen+shot+2011-05-19+at+14.07.07

We bring this into BGP using the 'network' statement. 

Screen+shot+2011-05-19+at+14.07.24

Now on R2 we can see that R3 has indeed sent us a route for 150.1.1.0/24. Notice the origin for the route is 'i' or internal. Thats because we brought the route into the BGP RIB (Routing Information Base) using the 'network' keyword.

Screen+shot+2011-05-19+at+14.07.40



So what happens if we bring the network in via a redistribution? We'll create another loopback interface on R3 called loopback1 and redistribute that connected interface into the BGP RIB.

Firstly the interface configuration

Screen+shot+2011-05-19+at+14.08.22

Now we add the necessary configuration to the bgp routing process. Firstly we need to be careful here. simply redistributing all connected interfaces will also bring our loopback 0 interface in...so lets use a route-map. We'll match the network for loopback 1 using an access-list

Here is the access list (we could use the 'host' keyword instead of 0.0.0.0)

Screen+shot+2011-05-19+at+14.10.11

Now the route-map. We're matching access-list 1 which is 200.1.1.0/24 which is the network we configured for interface loopback 1. Any other match is denied and dropped i.e. it won't be redistributed.



Screen+shot+2011-05-19+at+14.33.59

So lets have a look at the routing table on R2 to see if we now how two routes, the first from 150.1.1.0 and now a second for 200.1.1.0.

Screen+shot+2011-05-19+at+14.34.48

We do! Thats great. Now look at the origin. The first was an 'i' for internal which you remember was brought in using the 'network' keyword. Now the new network 200.1.1.0 has an origin of '?' which means incomplete. The reason for this is we don't know the source of the route so our knowledge of it's origin is...well incomplete. All we know is that someone brought it in from somewhere.

So there is one more origin type and that is 'e' or EGP. Now EGP is a legacy protocol and I've never come across it. To create the 'e' origin type therefore we'll have to 'fudge' it. We're going to use a route-map again to set this.

First lets create another loopback interface on R3 for this EGP candidate route.

Screen+shot+2011-05-19+at+14.37.34


OK, so now lets edit the existing route-map to add in our EGP configuration. What we'll do is again using an access-list match the interface lo2. If it matches then change the origin to e and set the source AS# for the EGP to 65003.

Screen+shot+2011-05-19+at+14.40.30

OK, now thats done we'll wait for a while till the BGP routes settle (or we can force it with a 'clear ip bgp *' at either side of the peering).

Screen+shot+2011-05-19+at+14.42.13


There we go...all three origin types. If these were duplicated routes learned from different sources with the same AS_PATH length we'd choose i first, then e then ?.

So what about R1? You're right we didn't even use this yet...lets take a look at it's routing table...

Screen+shot+2011-05-19+at+16.52.09

Nothing? Of course - is the next hop in my routing table? No of course not so the route goes into the BGP RIB but is inaccessible. So we need to set the 'next-hop-self' on R2 to change the next hop to R2's fa0/0 interface.

Screen+shot+2011-05-19+at+16.50.34


OK lets see the routing table now.

Screen+shot+2011-05-19+at+16.52.16

Looks good - of course R3 has no way of knowing how to get to 12.1.1.0/24 yet but you know how to do that now right? Of course you do...

Thanks for reading.

View Comments
We're going to continue our last post on EIGRP discovery with an EGP protocol discovery (eBGP).

Screen+shot+2011-05-12+at+11.48.53

To present this in a demonstration we've done as before and created a two node network and will setup an eBGP adjacency between the two nodes. The link between the nodes will be using the 10.1.12.0/24 network.So we'll start up by setting the addressing on the interfaces as per the diagram. First R1:

Screen+shot+2011-05-12+at+11.18.41






Now R2:

Screen+shot+2011-05-12+at+11.19.05

OK, so maybe we do a ping to confirm connectivity:

Screen+shot+2011-05-12+at+11.19.25






So we're going to need a network to advertise into BGP so lets have a loopback on R2 with IP address 2.2.2.2/24:
Screen+shot+2011-05-12+at+11.20.38
Great all done for interfaces and networks, lets crack on and configure the BGP on router R2. We're going to configure the BGP session with AS#123. We'll set the BGP router-id as the loopback address (this is shown for completeness but is not an essential configuration step). We're going to add the loopback interface in as a network to advertise. Remember the BGP 'network' statement doesn't work int he same way as most IGPs. The 'network' statement in BGP is saying "Here is a network I want to advertise to my neighbors".
Screen+shot+2011-05-12+at+11.32.49


So the 'neighbor' statement is saying here is my BGP neighbor IP address (in our case R1 with 10.1.12.1 and it's remote-as number is 100.

Right, lets move on to R1 now and configure the BGP session there. We'll want to use AS#100 (remember R2 pointed to remote-as 100) and then add in the neighbor statement. In this example we're not really interested in sending any networks from R1 to R2 so there are no network statements of redistributions etc.
Screen+shot+2011-05-12+at+11.33.49
OK! we'll we've put the configuration in and almost immediately we'd commited the neighbor statement to the running config the router went away and tried to establish the BGP session. The router has dumped a log to the console which includes a lot of HEX formatted 'guff' (thats a technical term).

To troubleshoot the issue lets dissect the debug/log. We see that we have a BGP notification saying that the 'peer in wrong AS'. So R1 ha been told here by R2 that the AS number it is using doesn't match it's configured AS#. The router tells you that the AS# is 2 bytes long and...it is ;-) AS#'s are valid between the range of 0 and 64511 (64512 to 65535 are reserved for private use.

Anyway back to the story, the remote side AS# is contained in the log dump as the first 2 bytes after the word '2 bytes' ;-)

as_num

The HEX following the message is 007B and the BGP AS# is DECIMAL so we'll need to convert it...where is that scientific calculator?
Screen+shot+2011-05-12+at+11.35.04
So we'll use the MAC calculator. Click the '16' button because HEX is base 16...why can't they just say HEX? So lets pop in the HEX we got in the log message 007B. So now click the 10 button because DECIMAL is base 10...of course ;-) and we get...drum roll please
Screen+shot+2011-05-12+at+11.34.53
Right so the remote AS# is 123...of course...why didn't I just click on R2 and do a show running-config ;-) We'll this is a scenario of course and it's all about the 'win'.

So lets go onto R1 and change that neighbor line to reflect the correct AS# of 123 not 1 as we had originally set it.
Screen+shot+2011-05-12+at+11.34.24
Great, and the BGP session has come up. Tell you what lets just have a look in the routing table to see if that loopback0 interface from R2 is in there?
Screen+shot+2011-05-12+at+11.34.34

So thats it, BGP is up and routing updates are being received. 
Job well done.



View Comments
Sometimes you find yourself in a bad place, you've forgotten the AS number you configured on your router in LA, you locked out VTY access to the directly connected interface and you've lost your documentation. So you're in Massapequa, NJ and you've got your MPLS VLAN up to the LA office but you can't get onto the loopback interface. You need to bring the EIGRP neighborship up and get that good stuff flowing ;-)

This techguide will show you how to discover the remote side AS number for EIGRP. Lets talk a little about EIGRP so we get some background. We'll it's got it's own protocol (88) number and uses RTP (reliable transport protocol) for delivery. The EIGRP traffic is distributed using IP multicast on address 224.0.0.10 for discovery with updates as unicast and queries as multicast. The initial setup 'are you there' messages are sent as multicast.

So knowing this information we can see that by capturing the traffic between two EIGRP neighbors we should be able to discover the AS number since the AS number will be sent in the discovery as part of the setup process (subsequent updates and replies will also contain the AS#).

To prove it out we've got a basic topology:

Screen+shot+2011-05-11+at+11.38.11


R1 is directly connected to R2 using a fast ethernet connection.

We've configured the interfaces already using the network 10.1.12.0/24 with 10.1.12.1/24 for R1 (see below)

Screen+shot+2011-05-11+at+11.00.17

and 10.1.12.2/24 for R2

Screen+shot+2011-05-11+at+11.00.34


Right - lets put the EIGRP configuration in:

First R1

Screen+shot+2011-05-11+at+10.58.13


Then R2


Screen+shot+2011-05-11+at+10.59.31


So, we've basically built the basic configuration, nothing fancy. We've added the interface Fa0/0 in for both routers so EIGRP will be enabled onto those. We've also added in the Loopback0 interface of each (just because we did - it has no part to play for this post and can be ignored). You should however give some attention to the chosen EIGRP AS #. Notice that the router R2 has AS# 12345 where R1 is as AS #1. We've done this o illustrate the point that we don't know the remote AS. We need to use an AS number to make EIGRP work int he first place...you can choose any AS number here so long as it isn't 12345 ;-) Think back to the original example where we discussed LA and NJ...you are not supposed to know the AS# otherwise what is the point of debugging the problem?

Right, how do we catch the traffic? Well the router clearly sees all the traffic we need so it makes sense to use the router to collect and show the packets right? OK we all probably know and use 'debug ip packet' but hopefully not on production systems unless you know what you are doing. Here is a screenshot for the command.


Screen+shot+2011-05-11+at+11.11.29

Notice the access-list on the end? We could use this to tune down the traffic which the router will be examining. Indeed using 'debug ip packet' on a production system would be suicidal without some sort of filtering. For our demo here however we're not going to need this filtering because we don't have any traffic. You *should* definately note however that there is a missing or 'hidden' command here called 'dump'. IOS has a few of these little easter eggs hiding in the code. Normally it's because they are either really dangerous in the wrong hands or else they are not very well tested and therefore shouldn't be used by mortals. In this case I feel the dump keyword is missed off because if you thought debug ip packet created too much console information to be healthy then adding dumps of data to the console is never going to be the best plan.

So we turn on debugging and ask it to also crack open and dump the data inside the packet like a typical pcap...HEX and all that good stuff.

Screen+shot+2011-05-11+at+11.11.58


OK so here is a dump of data. We see the sources are our local Fa0/0 (s=10.1.12.1) and Loopback0 (s=1.1.1.1) interfaces. OK so where is the R2 traffic?

Screen+shot+2011-05-11+at+11.13.36

Here's one s=10.1.12.2 great. So where is the AS number man...I bet the big red circle gives it away for you. The first few bytes are header so things like destination MAC for EIGRP mulicast group 224.0.0.10 (0100.5e00.000a) followed by source MAC of R2 (c201.0cab.0000)...etc.

So we have the HEX value of 3039 remember EIGRP uses values from 0 to 65535 which is a 32 bit number (same number of bits as an IP address). So lets pop 3039 into a HEX to DEC calculator and we get 12345...thats IT!

Job done - all we need to do now is change the AS number we used in R1 (AS#1) with the one we just 'discovered' (AS#12345). Now because we can't simply rename the AS number we need to tear down the original and rebuild it. If you had a lot of config below the 'router eigrp' function you are best to do a 'show run | b router eigrp' and copy the config then all you need to do is paste it in.

Screen+shot+2011-05-11+at+12.15.27

Job done - enjoy

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
Whats the big deal about a defaultroute? The defaultroute is the last resort path your IP traffic takes to get out of your local network if it doesn’t have a more specific route in it’s routing table.

Well you know, the current internet routing table is hitting around 370,000 entries or so today. Having all of those routes sat on your PC is not going to be a good thing for your RAM or CPU when you have to store and lookup those routes. So what do we do, we have a default route pointing at a gateway device on our network. So, that gateway might be a layer 3 switch where the gateway address is a virtual switch interface (VSI). Do you think your switch was built to hold 370k+ routes? No sir you are correct. Most likely therefore your first hop gateway device will also have a default gateway configured pointing to an upstream device like your firewall. So, that firewall, is that likely to be fantastic enough to hold these routes to the internet? You guessed right, no way. So your firewall has a default route to another upstream gateway like you CPE (Customer/Provider Edge) router. Now finally this is the most likely place you’ll not find a default route. If you are taking a full BGP feed from your ISP then you don’t need a default route because your router learns all of the networks out there. So do you need a full routing table here? If you are connected to one ISP with one link...nope you do NOT need the full routing table and a default route from the next hop (the ISP neighbor router) is enough.

Now we see the defaultroute and it’s importance it’s important to understand why it’s a bad thing for network security. If you give your devices access to a network which contains a default route then it’s something which an attacker can use to ‘get around’. Without a route to a destination packets are dropped - just think about that - network security without a firewall - awesome.

So if we want a default route how can we have one?

We’re going to start our ramble into default routes using the humble and powerful but ultimately high maintenance static route.

  • Static route - easiest to configure but least scalable. In this example we’ll walk through a defaultroute to get traffic via from the source interface of Loopback0 on R1 to the destination interface of Loopback0 on R4.

  • Here is the topology:

  • Screen shot 2011-05-03 at 22.48.25


  • Some topology information:
  • R1 Fa1/0 10.1.13.1/24 <-> R3 Fa1/0 10.1.13.3/24
  • R1 Fa0/0 10.1.12.1/24 <-> R2 Fa0/0 10.1.12.2/24
  • R3 Fa0/0 10.1.34.3/24 <-> R4 Fa0/0 10.1.34.4/24
  • R2 Fa1/0 10.1.24.2/24 <-> R4 Fa1/0 10.1.24.4/24
  • R1 Loopback0 1.1.1.1/32
  • R2 Loopback0 2.2.2.2/32
  • R3 Loopback0 3.3.3.3/32
  • R4 Loopback0 4.4.4.4/32
Screen shot 2011-05-03 at 23.02.10

Screen shot 2011-05-03 at 23.02.22

Screen shot 2011-05-03 at 23.02.34

Screen shot 2011-05-03 at 23.02.45

I’ve configured R2, R3 and R4 to ‘know’ how to reach the loopback interface of R1. This is key to the topology and you should try to think of R2 and R3 as intermediate systems rather like those of the internet. On the internet there are man hops in the network between you and your destination...just look at this traceroute for an example. I’ve removed the IP information from the first 4 hops to anonymise the result but you can see that my packets hop across 9 nodes before they get to the www.google.com server. In our example we’re going to hop twice to get to R4.

Screen shot 2011-05-03 at 23.11.21

So lets start with showing the routing table on R1

Screen shot 2011-05-03 at 23.03.55

So we see that there are 3 networks listed 1.0.0.0/32 is the loopback0 interface and the other two are the Fast Ethernet ports. Each interface is listed as code ‘C’ which means connected (Juniper call this ‘direct’). If we try to ping the remote loopback interface on R4 we get a fail because R4 doesn’t know how to get to the R4 network of 4.4.4.4/32.

Screen shot 2011-05-03 at 23.18.29

Simple enough so far and hopefully no worries.

So we want to get to google.com and in our wisdom we’ve put into two links to the internet. We’re going to use the link between R1 and R2 as ‘way out’ and we’re going to trust that R2 knows how to get to google.com. Lets put in our default route now, point it at R2.

Screen shot 2011-05-03 at 23.20.49

The first command we put in adds the default route. The IP address of 0.0.0.0 and netmask of all zeros means any IP address basically. It can sometimes be shown as 0.0.0.0/0. The last IP address is the address of the next hop from us. R1 has a connected network link between it’s Fa0/0 interface and R2 using network 10.1.12.0/24. R2’s IP address on this link is 10.1.12.2 so we point our defaultroute at that.

The result of the ‘show ip route’ now has a new route at the bottom prefaced with the code of ’S*’ which means a static route. So now we have a defaultroute pointing at the next hop on R2. R2 knows how to get to the Lo0 interface of R4...lets try a ping now.

Screen shot 2011-05-03 at 23.28.35
  • Great stuff we did it - we can now ping - lets see the path we took.
Screen shot 2011-05-03 at 23.30.13

So, as we know our packets went via R2. But hey you’ve bought two uplinks to the internet, one via R2 and one via R3...can we have two default routes? Well if your have one ISP and two uplinks to that ISP then the answer is yes. If you have two uplinks but are using different ISP’s on each link then the answer is a vague maybe and we’re not getting into the reasons why here.

So lets add another default route into R1 via R3.
Screen shot 2011-05-03 at 23.32.23

This time the ‘show ip route’ has two lines under 0.0.0.0/0. This is IOS telling you there are two equal cost routes to the destination. This means your packets can take either way to get there. We do a traceroute...

Screen shot 2011-05-03 at 23.34.17

Check out how the ICMP packets are telling us that sometime the first hop is 10.1.13.3 then 10.1.12.2? This is your packets being ‘load balanced’ in a round robin way. The second hop is either the network between R3 and R4 10.1.34.4 or the network between R2 and R4 10.1.24.4. Perfect. Just what we wanted...right? So what happens no if the link between R1 and R3 fails...we’ll administratively shutdown the interface for the demo.

Screen shot 2011-05-03 at 23.37.12
Screen shot 2011-05-03 at 23.37.34

Now lets ping the R4 loopback0 interface. What has happened now is that every other packet is failing to get to the 4.4.4.4 address. Thats because we effectively load balanced the traffic and now one of those links is down...hence the loss.

Screen shot 2011-05-03 at 23.42.56

So what can we do? Well in most cases you wouldn’t use static routes you’d be using dynamic routing protocols, some sort of first hop redundancy protocol and certainly be tracking upstream connectivity to failover and load balance properly but we’ll leave that for another time. For our brief demo we’ll concentrate on weighted static routes sometimes called ‘floating static routes’.

Floating static routes allow you to put a ‘primary route’ into the table but in situations where that route is no longer available a second route with a higher metric can be brought into service. Here we’re testing everything is good...and we’ve brought the link between R1 and R3 back up for this.

Screen shot 2011-05-03 at 23.47.38

The second configuration command basically takes out with a ‘no’ the second load balanced default route to R4 via R3. So now lets see the routing table...

Screen shot 2011-05-03 at 23.48.57

Ok you can see we’ve got one route now via 10.1.12.2. Lets add in our floating static route. Now by default a static route to a next hop gets a metric of 1. You can see the metric in the above ‘show ip route’ as the [1/0] after the route 0.0.0.0/0. We’ll add a ‘floating’ route with a metric of 200 but it can be anything between 2 and 255.

Screen shot 2011-05-03 at 23.50.42

So the route is in but crucially you WON’T see this in the routing table. It will still look like it did before we added the floating route...see...

Screen shot 2011-05-03 at 23.51.12

The floating route is only used when the lower metric route is lost from the table. To demonstrate it we’ll shutdown the interface on R1 connected to the link between R1 and R2.

Screen shot 2011-05-03 at 23.52.47

Check out the ‘show ip route’ now. You see that the defaultroute now points to 10.1.13.3 which before was not shown. R1 has realised that the next hop of the previous route is no longer valid so it drops that route from the table. The new defaultroute has a metric of 200 which is what we configured earlier. job done.

Thanks for reading.
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.