issue with totally stubby area

liven

ok I went into an interface and did this:

R3(config-router)#area 34 stub no-summary



which worked:


but then about 40 seconds later I got this (the dead timer is set to 40):


*Mar 1 02:52:27.247: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.4.1 on Serial0/1 from DOWN to DOWN, Neighbor Down: Dead timer expired Dead timer expired




these commands were entered on a router number 3

which connects to AREA 34. Area 34 is supposed to be the totally stubby area.

So why did it work until the dead timer expired? I know it has something to do with LSA's and all of that, but what do I need to do to prevent the dead timers from expiring?


here is R3 interface that connects to R4


!
interface Serial0/1
ip address 172.16.34.3 255.255.255.0
serial restart-delay 0
clock rate 128000
!
!
router ospf 1
log-adjacency-changes
area 23 virtual-link 172.16.2.97
area 34 stub no-summary
network 1.1.1.1 0.0.0.0 area 555
network 172.16.3.0 0.0.0.255 area 23
network 172.16.23.0 0.0.0.255 area 23
network 172.16.34.0 0.0.0.255 area 34
!










here is R4 that connects to R3


!
interface Serial0/0
ip address 172.16.34.4 255.255.255.0
ip ospf hello-interval 20
serial restart-delay 0
!


router ospf 1
log-adjacency-changes
network 172.16.4.0 0.0.0.255 area 34

networker050184

Did you specify the area as a stub on the other routers in the area? If not you are probably suffering from a mismatched stub area bit causing the relationship to die. The relationship stays up until the dead timer expires because the stub bit is set in the hello and the router waits until the dead time for a valid hello before resetting the relationship.

EDIT: Looks like you added the config while I was typing! As I said you need to specify the area as a stub on R4.

liven

like this:


!
router ospf 1
log-adjacency-changes
area 34 stub
network 172.16.4.0 0.0.0.255 area 34
network 172.16.34.0 0.0.0.255 area 34

networker050184

liven wrote: »

like this:


!
router ospf 1
log-adjacency-changes
area 34 stub
network 172.16.4.0 0.0.0.255 area 34
network 172.16.34.0 0.0.0.255 area 34

Yep. You have to have the are identified as a stub, but the no-summary option only needs to be specified on the ABR.

liven

hmmm

still not showing the default route.... on R4....


I even restarted the ospf process...

I wonder if it is a dynamips thing.

networker050184

It may have something to do with your virtual link. Try connecting R3 directly to area 0. The rest of your config looks good though....

liven

Well the thing is the area that connects all the other areas is 23....


it goes


r1 (area 0) <-> r2 (area 20 and 23) <-> r3 (area 23 and 34) <-> r4 (area 34)


the transit area is area 23....

networker050184

You have virtual link on R3 that connects area 23 to area 0. Try using a gre tunnel instead of a virtual link and see if that works. I have never tried this scenario with a virtual link. Maybe searching through the docs will reveal something. I'll try to lab it up later if I have time and remember....

cowood2676

Below is an example:

R1(config)# router ospf 1
R1(config-router)# network 172.16.20.144 0.0.0.7 area 0
R1(config-router)# network 172.16.20.16 0.0.0.7 area 2
R1(config-router)# area 2 stub no-summary

In a totally stubby area, no interarea/summary or external LSAs are propagated by the ABR into the area. To reach networks and hosts outside their area, routers use a default route, which the ABR advertises into the area. On the ABR you must have a network back to the network that is not in the stub area, as seen above;R1(config-router)# network 172.16.20.144 0.0.0.7 area 0

All routers inside a stub or totally stub area must be configured as stub routers. When
an area is configured as a stub, interfaces that belong to that area will exchange Hello packets with the stub flag. The flag is a bit in the Hello packet that neighbors must agree on to be neighbors.

kalebksp

r1 (area 0) <-> r2 (area 20 and 23) <-> r3 (area 23 and 34) <-> r4 (area 34)

Which router is the ABR between area 0 and area 23?

liven

ok when I do a:


show ip ospf


R1

Routing Process "ospf 1" with ID 172.16.1.1
Start time: 00:44:44.360, Time elapsed: 06:40:50.772
Supports only single TOS(TOS0) routes
Supports opaque LSA
Supports Link-local Signaling (LLS)
Supports area transit capability
It is an autonomous system boundary router



R2

Routing Process "ospf 1" with ID 172.16.2.97
Start time: 00:52:59.532, Time elapsed: 06:34:05.376
Supports only single TOS(TOS0) routes
Supports opaque LSA
Supports Link-local Signaling (LLS)
Supports area transit capability
It is an area border router


R3

R3#show ip ospf
Routing Process "ospf 1" with ID 172.16.3.1
Start time: 01:10:15.024, Time elapsed: 06:01:46.680
Supports only single TOS(TOS0) routes
Supports opaque LSA
Supports Link-local Signaling (LLS)
Supports area transit capability
It is an area border router


R4

Routing Process "ospf 1" with ID 172.16.4.1
Start time: 00:00:13.244, Time elapsed: 03:53:37.672
Supports only single TOS(TOS0) routes
Supports opaque LSA
Supports Link-local Signaling (LLS)
Supports area transit capability
Router is not originating router-LSAs with maximum metric

liven

ok the only way I can get this to work is to make the transit area, area 0...

it make me wonder can you have a totally stubby area hanging off of a virtual link in OSPF?



original configuration ( I am using <-> to indicate a serial connection between devices):


R1 (area 0) <-> R2 (area 0 and area 23, 23 being the transit area) <-> R3 (area 23 and area 34) <-> R4 (area 34)... And area 34 is supposed to be the totally stubby area....


I changed it to be like this:


R1 (area 23) <-> R2 (area 0 and area 23, 0 being the transit area) <-> R3 (area 0 and area 34) <-> R4 (area 34)

BOOM!!! It works....

This is an exercise out of the cisco CCNP lab book for the BSCI... The lab states that there is a "hidden" issue in the topology that has to be change to get this to work....

So my question is: Can a totally stubby area be the end point of a virtual link? If not I figured it out... If so I either had a misconfig, or an issue with dnyamips....

Either way I am tired... I have been working on this lab for way to long.

thanks for everyones help and suggestions.

kalebksp

Area 0 can't be a transit area, a transit area is an area between area 0 and another area.

I pulled out my copy of the BSCI Lab Portfolio and took a look. You were on the right path, the "hidden issue" is that a virtual link needs to be created through area 23. My guess is that there was some issue with the virtual-link. The configuration on R3 looked right, the command "area 23 virtual-link 172.16.3.1" should have been on R2. You can also verify that the virtual link has been established with "show ip ospf virtual-links".

unclerico

FYI, a transit area cannot be a stubby area.

liven

kalebksp wrote: »

Area 0 can't be a transit area, a transit area is an area between area 0 and another area.

I pulled out my copy of the BSCI Lab Portfolio and took a look. You were on the right path, the "hidden issue" is that a virtual link needs to be created through area 23. My guess is that there was some issue with the virtual-link. The configuration on R3 looked right, the command "area 23 virtual-link 172.16.3.1" should have been on R2. You can also verify that the virtual link has been established with "show ip ospf virtual-links".

Ok I will go back and give the lab a second look tonight.

I originally had the virtual link setup and once I did that I was able to get connectivity through all parts of they network.

I had virtual link command on R2 and R3... I thought that was necessary.

However I am sure that I made mistake. I will probably blow away the old configuration and re-lab it. Then see what the problem was.

Thanks everyone.

liven

unclerico wrote: »

FYI, a transit area cannot be a stubby area.

I knew this, I was just not sure if a totally stubby area could be connected to a transit area via a virtual link.


Like I mentioned in the earlier post, I need to relab all of this and give it another shot. Then see what I was do wrong.

Thanks again for the comments I appreciate them.

liven

well finally got it working last night....


I realized I had jacked up the hello and dead timers on router 4....

Once I got them fixed, and fixed the virtual link everything worked correctly.



I want to thank everyone for helping and suggestions.