Cisco Advanced Routing Lab: Redistribution, Default Routes, and Virtual Tunnels

Today, I felt like challenging myself a little bit, so I created a large, somewhat complex network in GNS3 to try putting several concepts together into one, cohesive network. As usual, we'll start with the network diagram:



R1, R2, R3 and R4 are the network core. These routers all live in Area 0 (in the center of the diagram). R1 also participates in Area 1 and shares routes via BGP with R5. R5 participates in an entirely separate OSPF domain with R6 (my idea was that R5 and R6 would be "Internet" hosts for this lab). Just like R1, R2 also participates in Area 1, providing a redundant link to this area. R3 participates in OSPF area 3 and is one of the endpoints for the virtual tunnel to Area 4. R4 also belongs to Area 2. R7, 8 and 9 are pretty straightforward, existing only in Area 1. Likewise, R10 and R11 only live in Area 2; there's nothing complex about their configurations, either. R12, however, is the boundary between Area 2 and the RIP network including R13. R14 and R15 are routers belonging to Area 3, but R16 is a little more tricky. R16 participates in both Area 3 and Area 4.

However, OSPF requires ALL OSPF areas connect to the backbone (area 0) by at least one router. If you notice, there is no direct link between Area 4 and Area 0 in this network diagram, so in order to have Area 4 share routes with the rest of the network, you need to create a "virtual link" between R16 and R3. If ever you find yourself with an OSPF area that doesn't connect to the backbone, it might be worth rethinking your network design so that all of your areas do connect to Area 0. Speaking in broad generalities, there's usually something flawed with your design if you can't connect various OSPF areas directly to the backbone, but if for some reason you can't, it's pretty easy to connect R16 and R3 via a virtual tunnel. First, on R3:
R3(config)#router ospf 42
R3(config-router)#area 0.0.0.3 virtual-link 10.254.254.16


...and on R16:
R16(config)#router ospf 42
R16(config-router)#area 0.0.0.3 virtual-link 10.254.254.3


That's it! There are several options -- such as the various timers -- that you can adjust to account for various network performance issues across the virtual tunnel, but that's essentially all there is to creating the tunnel. Inside the OSPF config on each tunnel endpoint, you list the area ID of the OSPF area that the tunnel will be transiting, and you give the IP address of the other router's OSPF router-ID. In this network, I am using 10.254.254.<router number> for the loopback0 IP address, so R3 is 10.254.254.3 and R16 is 10.254.254.16.

The next "interesting" feature of this lab is the redistribution between OSPF Area 2 and the RIP network on R12. On R13, I created several 172.16.x.y networks on loopback interfaces...:
R13#sho ip int brie
Interface         IP-Address    OK? Method Status...
FastEthernet0/0   unassigned    YES unset  admin...
FastEthernet1/0   10.128.12.2   YES manual up ...
FastEthernet2/0   unassigned    YES unset  admin...
FastEthernet3/0   unassigned    YES unset  admin...
Loopback0         10.254.254.13 YES manual up...
Loopback1         172.16.1.1    YES manual up...
Loopback2         172.16.2.1    YES manual up...
Loopback3         172.17.1.1    YES manual up...
Loopback4         172.17.3.1    YES manual up...

RIPv1 is classful, while we are using classless routing, so the first thing to do is make sure that we are using RIPv2 on both R12 and R13:
R12(config)#router rip
R12(config-router)#version 2

Next, on R12, I want to tell RIP to redistribute OSPF routes, but to add a metric that is sufficiently large that R12 and R13 will prefer local routes to routes that have been imported from OSPF:
R12(config-router)#redistribute ospf 42 metric 3

Since RIP, being a distance-vector protocol, uses hop count as a metric (with a maximum of 15 hops), we start routes imported from OSPF with a hop count of 3 (the "42" is the OSPF process ID I used in the lab -- "router ospf 42"). Now, we'll do the same thing with OSPF:
R12(config-router)#router ospf 42
R12(config-router)#redistribute rip metric 50000 subnets

Again, we are setting the OSPF metric for routes important from RIP to an arbitrarily large value, so that OSPF will prefer local routes to imported routes; the exact value may require some tweaking on your network. I am also using the "subnets" option to tell OSPF to import just the specific subnets that RIP is advertising. Otherwise, any subnets from Class A IP space will be imported as /8 networks; any subnets from Class B IP space will be imported as /16 subnets; and any subnets from Class C IP space will be imported as /24 subnets (in other words, the two 172.16.x.y/24 subnets on R13 would be imported as a single 172.16.0.0/16, the two 172.16.x.y/24 subnets would be imported as a single 172.17.0.0/16, and the 10.254.254.13/32 subnet would be imported as 10.0.0.0/8 -- not at all what we wanted!).

On R1, we are advertising all of the subnets hosted in all of the OSPF areas as well as the RIP network to R5 via BGP:
router bgp 2358
no synchronization
bgp router-id 100.64.0.2
bgp log-neighbor-changes
network 10.0.0.4 mask 255.255.255.252
network 10.0.0.8 mask 255.255.255.252
network 10.0.1.4 mask 255.255.255.252
... network 172.16.0.0
network 172.17.0.0
network 192.168.9.0
neighbor 100.64.0.1 remote-as 2112
no auto-summary
!
It would also be possible to simply import OSPF into BGP, rather than list all of the subnets individually. However, this raises an interesting point: how do you import the routes that R5 is sharing via BGP into the network? The whole point of BGP is to share extremely large routing tables between routers. You don't want to import the entire Internet's routing tables into OSPF, so what is the best way to share external routes with the other routers in your internal network?

In this case, I used a simple, one-line statement to have the other routers send traffic destined for external networks to R1:
R1(config)#router ospf 42
R1(config-router)#default-information originate always
Since R5 is sharing its routes with R1, R1 knows how to reach the external subnets. By adding the "default-information originate" command to R1's OSPF config, it is essentially telling the other routers within the network that is the default gateway -- that traffic destined for unknown networks should be sent to it. R5 has the exact same statement in its OSPF config, so that R6 can reach the networks R5 has received via BGP.