Friday, August 13, 2010

Injecting a default route into OSPF

This post will build off the BGP Basics post that I did earlier this month. Here is what we are looking to achieve this time:

• The ISP router will advertise a default route to his neighbor R1 (acme.com's internet gateway)
• R1 will then advertise to R2 and R3 via OSPF the default route
• R2 and R3 will be able to access the 172.16.1.0/21 network even though they have no specific route to this network

Here we go:



• Starting with the ISP router, we are going to remove the default route that we added in on the last post

ISP#
!
no ip route 0.0.0.0 0.0.0.0 Null0

We still have the default-originate statement under the router bgp 64004 statement so we should be good. Over on R1 we should see that he has an entry that looks like this:

R1#
!
show ip route
!
B* 0.0.0.0/0 [20/0] via 10.10.1.2, 00:16:27

• Next we are going to look at R2 and R3 to see what routes they have. They should look something like this (taken from R2)



• On R1 we are going to add a statement to the OSPF process that will advertise the default route.

R1#
!
router ospf 1
!
default-information originate

On R2 and R3 we see this entry for the default route and we also see a gateway of last resort set (from R2):



• Now if we were to go back to the ISP router and pull the default-originate statement from BGP (or down the serial 0/0 interface) what do you think we will see on R1?

- Answer: R1 will no longer have a route to 0.0.0.0 from the ISP router. Because of this R2 and R3 have lost their default route and gateway of last resort. The reason for this is because the route will not be advertised to other OSPF neighbors unless it's in R1's table.

Now that we have established this we can restore the default route and test the theory that we can reach things from R2 and R3 that are not in their route table.

• The network 172.16.3.0 exists off the ISP router and specifically 172.16.3.1. If we ask R2 about this network is tells us it has no idea what we are talking about:

R2#show ip route 172.16.3.1
% Network not in table

When we ping it here is what we see:

R2#ping 172.16.3.1
!
Sending 5, 100-byte ICMP Echos to 172.16.3.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/30/44 ms

A traceroute shows that it gets to the ISP router just fine:

R2#traceroute 172.16.3.1
!
Tracing the route to 172.16.3.1

1 192.168.2.1 24 msec 20 msec 20 msec
2 10.10.1.2 24 msec * 20 msec
[stop]

No comments:

Post a Comment