OSPF failover failure over DMVPN

[tahscolony]

We have a few locations with DMVPN tunnels back to a pair of 4451 routers. They use OSPF for internal routes, the remote router uses Area 1, the head end routers are Area 0.  They route fine when both routers are active, but today we discovered that if the Inside interface were to go down, none of the connected area 1 routers are reachable.

Only thing we can think is that the routers are not getting a notice that the routes have changed on the router that dropped an interface since they are using a Loopback for the router-id for OSPF.  Wouldn't the router with the dropped interface update the area 1 router with a new database or in some way tell it the routes no longer exist so that it pulls the routes from the other connected router?

We always tested failover by dropping the outside interface, or rebooting the router, so this was the first time the inside was taken down from a loose cable.

[MHM Cisco World]

What you meaning of Inside interface? Is it interface interconnect both hub router?

Can you do

Show ip ospf  neighbor 

Check if hubs are one DR and other BDR

MHM

[Torbjørn]

I am also struggling a bit to understand the topology here. Can you provide a topology diagram that includes interfaces and the areas?

[tahscolony]

The end router is DMVPN with two tunnel1 destination addresses.

Neighbor ID Pri State Dead Time Address Interface
10.195.10.18 0 FULL/ - 00:00:08 10.255.255.3 Tunnel1
10.195.10.19 0 FULL/ - 00:00:08 10.255.255.4 Tunnel1

sh ip route

Gateway of last resort is 10.255.255.3 to network 0.0.0.0

O*E2 0.0.0.0/0 [110/0] via 10.255.255.3, 01:29:41, Tunnel1

This ^^ apparently did not change from 10.255.255.3 to 10.255.255.4  so it was returning traffic to it's primary router which had a downed inside interface that connects to the core.  The head end routers are MPLS.

sh ip ospf
Routing Process "ospf 10" with ID 10.255.255.231
Start time: 00:01:41.078, Time elapsed: 50w5d

router ospf 10
router-id 10.255.255.231
passive-interface default
no passive-interface Tunnel1
network 10.30.15.0 0.0.0.255 area 1
network 10.255.255.0 0.0.0.255 area 1
network 192.168.231.0 0.0.0.255 area 1
network 192.168.234.0 0.0.0.255 area 1
network 192.168.235.0 0.0.0.255 area 1

Here is the headend router that dropped the interface.

10.195.10.19 1 2WAY/DROTHER 00:00:38 192.168.1.119 GigabitEthernet0/0/1
10.255.255.231 0 FULL/ - 00:00:07 10.255.255.231 Tunnel1

[MHM Cisco World]

This defualt route  inject into ospf via Hub ospf' 

This defualt route must redistrubte via staitc route toward Core' if Inside down this route will no more inject into opsf and remove.

For redundacy you can make both hub inject defualt route but each one with different metric and this force spoke to elect one.

MHM

[Ruben Cocheno]

@tahscolony 

The OSPF database should have been updated. A small diagram and the OSPF config might be helpful here.

[tahscolony]

I have an 8200 running DMVPN with static public routes only to the two 4451-X routers that are the DMVPN hubs. This router is area 1. The two DMVPN hubs are connected to our core as Area 0. They are MPLS configured Inside/Outside. The interface connecting to our core went down due to a bad cable.  When that happened it should have reconverged area 1 so that the 8200 would change it's default route to use the other head end router.  The 8200 acted as if nothing had changed when the Area 0 neighbor dropped.