Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

DMVPN with OSPF routing table problem

I have a customer running DMVPN network. OSPF is the IGP running over the GRE tunnels. Sydney being the Hub, and Jakarta being a stub.

My problem is that routes advertised by the stub routers are not appearing in the Hubs RT but they are in the OSPF DB. I have had to add floating static routes into the Sydney router config to get the customer's production traffic running as a bandaid fix.

I have reloaded the Jakarta (stub) router. I have also cleared the RT, OSPF process, NHRP, and Crypto on both Sydney and Jakarta. This has had no results, and the same floating static routes I added to Sydney to temporary fix this issue for the customer still remain in the Sydney RT.

I have attached some output from both Sydney (hub) and Jakarta (spoke). If someone could look at this and try to give me some advice.


Re: DMVPN with OSPF routing table problem

Can you share your topology

Taking look at the configs the first thing that comes to mind is that the Hub router should have been acting as the DR instead of the spoke router. Not sure whether this should have any influence thoough


New Member

Re: DMVPN with OSPF routing table problem

Take a look at the following link:

Your links have the same network type, so that shouldn't be the problem. Are you using unnumbered links on one side? Can you provide the configs for the WAN interfaces at both sides? Having the spoke as the DR shouldn't cause any problems.


New Member

Re: DMVPN with OSPF routing table problem

I fixed it.

The problem was that there is a half newly-transitioned secondary Hub router in Sydney that had a higher OSPF priority but had no adjacencies to the spokes. I adjusted the OSPF priorities around and now its all working well. This new secondary hub was turned on the same day as the issue began, but was ruled out as a cause by the design architect, I guess I should take his job now! :)

I just went back to CCNA basics, nobody could figure out what the issue was. Its a good lesson to step back a bit and think of the smallest things, as usually they are the problem.

Thanks for everyone's input so far.

CreatePlease to create content