OSPF Inter/Intra-Area Route

jpl861 · ‎07-20-2014

Hi,

I am currently doing some lab work here and came up with a weird OSPF output and I'm not sure if this is correct or not.

I have few routers, R1, R5, R6, R4.

R5, R1, and R4 are in Area0. R5 is an internal OSPF router in area 0 and R5 and R4 are the ABRs. R5's connection to R1 is a GRE tunnel (DMVPN) and R4's connection to R5 is via a point-to-point ethernet link. R1, R4, and R6 share the same ethernet segment in area1. R6 is just an internal area1 router.

After checking the routing table, R1's route to loopback address of R5 is via R4 in area1. So it goes from R1 out to LAN segment to R4 in area1 then out to point-to-point link to R5 in area0.

R1#sh ip route 150.1.5.5
Routing entry for 150.1.5.5/32
Known via "ospf 1", distance 110, metric 21, type intra area
Last update from 155.1.146.4 on FastEthernet0/1.146, 00:06:01 ago
Routing Descriptor Blocks:
* 155.1.146.4, from 150.1.5.5, 00:06:01 ago, via FastEthernet0/1.146
Route metric is 21, traffic share count is 1

R1#trace 150.1.5.5

Type escape sequence to abort.
Tracing the route to 150.1.5.5

1 155.1.146.4 48 msec 48 msec 12 msec
2 155.1.45.5 52 msec 20 msec 40 msec

My first question, shouldn't R1's route to R5's loopback should be via the tunnel which is in area0 (backbone) and should be intra-area route? Next question is, route via R4 is through area1 so this should be inter-area?

Am I missing something? Thanks in advance.

JL

jpl861 · ‎07-20-2014

I tried to change the router from 3700 to 7200 as I'm using GNS3, the result is different which is what I expected.

R1#sh ip route 150.1.5.5
Routing entry for 150.1.5.5/32
Known via "ospf 1", distance 110, metric 1001, type intra area
Last update from 155.1.0.5 on Tunnel0, 00:12:06 ago
Routing Descriptor Blocks:
* 155.1.0.5, from 150.1.5.5, 00:12:06 ago, via Tunnel0
Route metric is 1001, traffic share count is 1

I understand that the metric via GRE tunnel to R5 is way higher than the metric over R4 in area1 but from what I read, intra-area should be prioritized over inter-area. Not sure why R1 is treating the connection to R4 in 155.1.146.0/24 segment as intra-area to reach 150.1.5.5 using 3700s. Not sure if it's a bug or something.

jpl861 · ‎07-20-2014

I just discovered that it was because of the virtual-link configured between R1 and R6 and capability transit was enabled.

Can someone explain this better?

I understand why R6 picked R4 as the next hop but I am quite confused on why R1 who sits in area0 together with R5 and R5's loopback would choose the transit area1 due to the virtual-link.