Two OSPF ABR's between backbone and totally NSSA/Stub area

Answered Question
Jan 30th, 2008
User Badges:

I'm testing in lab environment this topology before to try with production environment: two OSPF ABR's R1 and R2 between backbone area and area 80 configured as totally stub area. Inside of this area 80 I have a router R3 with direct serial links to R1 and R2.


Well, R3 learns two default routes with the same metric to reach area 80 external networks. All seems to work fine.


Now let's assume R1 link to area 0 goes down. The problem which is making me crazy is R3 still learns two default routes pointing to R2 and... ¿¿¿R1???


Taking a view to R1 routing table (router which lost it's link to backbone area), this router installs a default route pointing to R3, but if R3 maintain a default route to R1..., we have a loop for ip flows load balanced to R1.


I have tested this issue with totally NSSA area and occurs the same thing.


Is this the usual behavior for NSSA/Stub areas with more than one ABR, if one of the ABR losts it's link to backbone area?


Thanks.


Correct Answer by Kevin Dorrell about 9 years 2 months ago

On R1, you have both S0/0 and the loopback in area 0. If you take down F0/0, you still have the loopback up in area 0, and so R1 is still an ABR, and so still generates the default route.


You could put the loopback in area 80. I think that would do the trick.


Kevin Dorrell

Luxembourg


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.3 (3 ratings)
Loading.
Konstantin Dunaev Wed, 01/30/2008 - 05:37
User Badges:
  • Bronze, 100 points or more

cisco says:

"The ABR for the stub area originates a summary LSA with a link ID of 0.0.0.0. It does this even if it does not have a default route." it could mean that ABR always injects the default router into totally-stub.

Also Cisco recomends that the topology of area 0 should be built in the way to prevent to be discontinuous, eg. wiht help of virtual-links.


as a workaround may be it'is possible to use a normal area and use "default-information originate" command on R1 and R2 to inject the default route only in case when they self have a default route.

Kevin Dorrell Wed, 01/30/2008 - 05:39
User Badges:
  • Green, 3000 points or more

Is that link the only presence that R1 has for area 0? I can understand that if R1 thinks it still has connectivity to area 0,(either as a link or a virtual link) then it will continue to inject the default route. That is why a discontiguous backbone is bad news.


But if the last link to area 0 has gone down, I don't see why it should generate a default route. But you say that R1 has a default route through R3, and that is what I don't understand.


Do you perhaps have a virtual link between R1 and R2 traversing area 80, but the only real path between them is back through R3?


Perhaps you could post some configs?


Kevin Dorrell

Luxembourg


aravindhs Wed, 01/30/2008 - 06:07
User Badges:

Hi,


Like Kevin says, if all the interfaces on Area 0 are down, (show ip ospf int brief) the default route IA* won't be propagated to the R3 router. Are R1 and R2 connected and have any other interfaces in Area0 ? Please check and let us know..


cheers

arav

Konstantin Dunaev Wed, 01/30/2008 - 06:48
User Badges:
  • Bronze, 100 points or more

Hello,


that is true, I've just configured the same topology and if the router looses all interface in area 0 then it will stop announce the default route to the tatally stub areas.

jmfranco Wed, 01/30/2008 - 07:52
User Badges:

Hi again and thanks four all your answers.


R1 and R2 only have one interface in backbone area. I think if R1 (or R2) interface in backbone area goes down, R1 stops to be ABR and it will be an internal router in area 80, stopping to announce default route to area 80. There is one strange thing: When I disconnect area 80 R1 interface, R1 "show ip ospf" output shows R1 is in area BACKBONE 0 as INACTIVE ¿¿¿???.


I will try to test more time and I will post configs ASAP (tomorrow I will be out of my office)


Thanks for your posts.


jmfranco Fri, 02/01/2008 - 01:17
User Badges:

Hello again.


I have been testing, but it doesn't work fine. When I drop R1 link to backbone area, these are R1 and R3 routing tables:


Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area

* - candidate default, U - per-user static route, o - ODR

P - periodic downloaded static route


Gateway of last resort is 10.211.248.1 to network 0.0.0.0


10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks

C 10.211.248.0/30 is directly connected, Serial0/0

C 10.211.248.4/30 is directly connected, Serial0/1

C 10.211.248.8/30 is directly connected, Serial0/2

C 10.211.248.254/32 is directly connected, Loopback0

O*IA 0.0.0.0/0 [110/65] via 10.211.248.1, 1d16h, Serial0/0

[110/65] via 10.211.248.9, 1d16h, Serial0/2

R3#10.211.248.1

Trying 10.211.248.1 ... Open



User Access Verification


Password:

R1>en

Password:

R1#sh ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area

* - candidate default, U - per-user static route, o - ODR

P - periodic downloaded static route


Gateway of last resort is 10.211.248.2 to network 0.0.0.0


10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks

C 10.211.248.0/30 is directly connected, Serial0/0

O 10.211.248.8/30 [110/128] via 10.211.248.2, 1d16h, Serial0/0

C 10.211.248.252/32 is directly connected, Loopback0

O 10.211.248.254/32 [110/65] via 10.211.248.2, 1d16h, Serial0/0

O*IA 0.0.0.0/0 [110/129] via 10.211.248.2, 00:00:18, Serial0/0


You can see R3 maintains two default routes and R1 install in its routing table a default route to R3.


I post my configs and network diagram.


Anybody can test my scenary?







Attachment: 
Konstantin Dunaev Fri, 02/01/2008 - 01:52
User Badges:
  • Bronze, 100 points or more

hm,

what I see from the first look, it's the absence of R2's loopback interface 10.211.248.253/32 in R1' routing table, of course, it's not necessary to have the router-id reachable, but it looks strange.

Correct Answer
Kevin Dorrell Fri, 02/01/2008 - 02:12
User Badges:
  • Green, 3000 points or more

On R1, you have both S0/0 and the loopback in area 0. If you take down F0/0, you still have the loopback up in area 0, and so R1 is still an ABR, and so still generates the default route.


You could put the loopback in area 80. I think that would do the trick.


Kevin Dorrell

Luxembourg


jmfranco Fri, 02/01/2008 - 04:03
User Badges:

Hi Kevin.


You are right, it's the trick. I moved R1 and R2 loopback interfaces to area 80, and now it works fine.


Refered to this, i see problems if ABR's are ABR for more than one area. Ok you put ospf router-id interface in one area, but about other areas, I think the problem will be the same.


Thanks.


Kevin Dorrell Fri, 02/01/2008 - 04:17
User Badges:
  • Green, 3000 points or more

JM,


There are a couple points to make about this.


Firstly, it should not be a problem if the ABR has more than one area. The important thing is that the loopbacks should not be in area 0, otherwise the router will continue to generate the default route even though it has lost its link to the backbone.


Having said that, once the router loses its connectivity to area 0, then it will not be able to pass routes from one (non-zero) area to another any more. That will have to be done by its partner. But I think we would want it that way anyway.


Secondly, don't worry about the router-id. The concept of the router-id is widely misunderstood, and it is misunderstood because it looks like an IP address. It isn't an IP address at all - it is a random number. I like to call my routers 1.1.1.1, 2.2.2.2, 3.3.3.3, etc, even though those "IP addresses" do not appear anywhere in my topology.


The reason why we seem to use a loopback address is simply that we are looking for a random 32-bit number (note "number", not "address") that is guaranteed to be unique in the topology. And a loopback address seems to fit the bill.


Kevin Dorrell

Luxembourg


Actions

This Discussion