Daniels quest for CCIE

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 0×10 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.

First start by looking at the diagram above. This is a scenario I ran into while
doing my mock lab. It is pretty obvious that we will have issues with OSPF since area 0
is discontigous. You should be able to spot this by just looking at the diagram.

So what are the tools we have to repair discontigous areas? The most common and
straightforward is to use a virtual-link. However in this scenario it is not allowed.
First lets look what issues we will have in this topology. I have prepared the
topology and initial configs with OSPF for you which can be downloaded here, final configs are also included.

We start by looking at the routing table of R1.

We can only see the loopback of R2. Why is that? R1 is an ABR. It has an
interface in area 0 and in another area. It will not install interarea routes
received on a non backbone interface.

This is the database on R1. We can see that all IA routes are indeed in
the database but they are not being installed into the RIB. To test our
thesis from the last OSPF post, lets shutdown Fa0/0 on R1. This should in
theory mean that R1 is no longer an ABR and that it can install routes
received on a non backbone area.

It works. So our knowledge of OSPF seems good. So this is an option we
can use, although we would not have reachability to R2′s loopback. The techniques
I show here would generate no points for the OSPF section but having reachability
in IGP is critial so if you can’t do something the right way, cheat!
What I mean by that is that if you don’t have reachability you will loose points
later in BGP, MPLS, multicast and maybe even IPv6 and security section. So you
see a lot of points are at stake and if we can’t solve a task the right way do it
some other way. Use static routes if you must!

We were not allowed to use a virtual-link but lets try that anyway to
see that we can install all the routes.

Yes, now we have reachability. We would loose 2 or 3 points probably for doing
this but could potentially save us 10-15 points later. I ended up having to do
this on my mock since I had problems configuring the solution below.

So if we can’t use a virtual link, where does that leave us? We need a link
between R1 and R4 that is located in area 0. How about a tunnel? Yes, that is
definately an option. However we are not allowed to introduce any new
IP addresses into the network. How do we solve that? IP unnumbered, we have to
borrow an IP from another interface. Lets setup the tunnel.

We source the tunnel from a physical interface and the destination is the other
side of the FR connection. Why source from the physical interface? We don’t have
reachability to loopbacks yet since our IGP is broken, therefore we have to use
the physical address. Why unnumbered from the Ethernet interfaces? They are located
in area 0. We must have an IP that is located in area 0 to repair the discontigous network.

So now we have an adjacency both over serial0/0 and over the tunnel. The tunnel
interface is point-to-point and has a very high cost. Notice that the IP for
the tunnel is 0.0.0.0/0.

Now look at the routing table of R1.

We can see that prefixes are reached via 155.1.34.4. This is the IP of Fa0/0
on R4 which was derived from the IP unnumbered. So what is interesting here
is that the adjacency between R1 and R4 is not in the same subnet, so we
are bypassing that check. We can also see that we need to recurse routing
lookups since the routes are pointing at 155.1.34.4.

This route is reached via the tunnel. If we look at the OSPF database on R1
we see a router LSA for R4 and there is the P2P link.

Router Interface address is 0.0.0.16. This is interesting, normally this is
the IP address of the interface. We are now using unnumbered. I’m not sure
why it is choosing 16. RFC says the following:

“For unnumbered point-to-pointlinks, the Link Data field should be set to
the unnumbered interface’s MIB-II [Ref8] ifIndex value.

If we look at the SNMP MIB, must enable SNMP first.

So this value should be 10. Seems like Cisco is not really following
the RFC (RFC2328) here. We can enable that behaviour with interface-id snmp-if-index.

Now we have the expected value of 10.

You can read more at Cisco.

So this should give you a look into OSPF. I have also attached a packet capture so that you can look at the LS Update going over the tunnel interface. We can see that the source of the
packet is 155.1.14.4 which is R4 IP addess and the destination is 155.1.14.1.
In there we have the other IP packet which has a source of 155.1.34.4 and a destination
of 224.0.0.5.