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.
Nice explanation. When I did this mock lab I couldn’t come up with a solution very quick to make the adjacency work over the gre tunnel. That’s why I have skipped it after a few minutes and used a virtual-link as you said 😉
Thanks Jochen. How did you do on the mock? I need to move to alternate solutions faster instead of digging to deep and then come back if there is time left. I didn’t score too great but for the TS I would have passed if I didn’t do some stupid mistakes. Config I would still not have passed but been a lot closer with better time management and missed some points I were pretty sure I had.
The lab is a lot about accuracy, every mistakes is very costly.
Really nice man..keep it coming..i have a question though…It is classic example of a partitioned area and i knew the solution was via either Virtual-link or tunnel but what if i am given a discontiguous area…Area1Area0Area1…in this case there will be reachability but what if the task is to display the Inter area routes in Area 1 internal router as Intra area routes? the solution is same but i can’t enable it correctly through GRE tunnel. Virtual link is working fine.
How would running a virtual-link solve this since a virtual-link is always belonging to area 0? It could work with a tunnel if you use an IP from area 1. I’ll lab it up and get back to you.
Why wont it work? Create a virtual link between ABR and Area 1 border router and see for your self…Virtual link in easy wording should be between a border router and ABR! Plus its not a problem of reachability so what i did was create a virtual link between area 1 border routers and ABR’s.
Absolutely. I need to work on my accuracy too. TS wen’t very well, but I screwed up in the config section big time. I got a bit frustrated in the beginning, which did cost me a lot of points in the core topics. Next time I need to remember that CCIE is also a mind game and calm down 🙂
TS 18/22
– Task 1: Modified config to much and changed it to back-to-back FR instead of FR hybrid switching like in the solution guide (haven’t heared about it anywhere before).
– Task 3: Fixed prefix list, but default route wasn’t originated. Replaced prefix list by standard ACL and default was originated. But it seems like the verification script was just looking for the prefix list and I lost those points.
Config 38/75
– Lost points due to OSPF VL
– Didn’t implement EIGRP load balancing,
– Misunderstood way to much in the IGP and BGP stuff
Seems we ran in to similar stuff. I also did back to back FR. Forgot that LMI was a prerequisite. Also lost all points since I removed EEM applet instead of just the one culprit. The applet made no sense but I guess we should remove as little as possible. What bugs me is that there is no good way of just unregistering the applet without removing the watchdog or so.
The EIGRP load balancing part I spent a lot of time because I misread the task. I read it as that both bandwidth and delay were fixed for both interfaces. That would leave us with nothing to manipulate to get the right traffic share. I’m surprised I didn’t do better in IGP but I know some stuff to watch out for next time. The switchport protected which created hub and spoke type scenario kind of stumped me. Had to leave it out to get things working and lost a lot of points there later in BGP etc.
I’ll do another mock in maybe 2 weeks and see if I have improved. Hit me up on chat some day and we can discuss.
Yes. I think I see what you mean now. So that is a solution as well then. Could you draw a quick diagram so I can see your topology?
Sorry for late reply…I am happy i find this blog to discuss things…Yes, it is a solution i saw in IPexpert blog article. I have a meeting so can’t draw the diagram but in the blog you can see the exact network portion
http://www.netcraftsmen.net/component/content/article/68-network-infrastructure/965-discontiguous-non-area-0-areas-in-ospf.html (For design perspective awesome article)
http://blog.ipexpert.com/2010/11/03/ospf-split-areas/ (Good explanation of the same problem set solution).
HTH
RAY
Cool. In Markos example he changed the area though on the loopbacks. If we put them in area 0 then yes that would be a solution. However I don’t think that would be common for the lab. Good to know all the tools though.
Pingback:Troubleshooting Discontiguous/Partitioned Area 0 in OSPF | dtechquest