This is a follow up post to my last OSPF post about repairing area 0.
In the comments section Ray asked me what we can do if we have a
scenario where we have another area that is discontigous. In this
example we are using area 1. Area 1 is used everywhere but between
R1 and R4 is the backbone area. The routes will therefore be
interarea. What if we were told to make these routes appear as
intra area? First look at the topology. Download .net file and
initial and final configs here.
First we start by confirming that routes received on R1
are coming in as interarea routes.
Yes they are. This is expected behaviour. So what can we do to
make them appear as intraarea? Using a virtual link does not help
since it always belongs to area 0. We could use the tunnel technique
that was used in the previous post. Let’s try that. Same procedure as
last time. Source tunnel from physical interface. Use IP unnumbered
from an interface in area 1.
The tunnel is up and we have a new adjacency.
The IP address is 0.0.0.0/0 and located in area 1. Lets look at the
router LSA for area 1.
The address is 0.0.0.16 just as the last time. This should be 10 according
to the SNMP MIB but as one of my friends Patrick pointed out 16 in decimal
is 0x10 in hex. Maybe it is encoded in hex?
So now lets check the routing table.
Problem solved. Routes are now received as intraarea. So there you have it,
another OSPF problem solved.
Fun! Will it stream traffic through the tunnel?
Yes, note however that the tunnel will still have to send traffic through the physical interface so it is not really taking a different path but it has an extra IP header due to GRE encapsulation.
great post Daniel!