DMPVN-OSPF Neighborship Flip-Flop

Hey guys,

I'm running a DMVPN lab with single area OSPF.

I've configured an ospf priority of 50 on the Hub and 0 on the Spokes. The Hub has the necessary tunnel config and a static default route to point to the Internet (R4), to reach all Spokes, and vice-versa for Spokes.

Maybe someone can shed some light as to why my topology continue to experience OSPF neighborship flip-flops between the Hub (R1) and R3. R1 and R2 seem to form a full adjacency just fine.

Please view the following debug info from the Hub (R1):

*Apr 30 11:40:14.263: OSPF: 2.2.2.2 address 172.16.0.2 on Tunnel0 is dead, state DOWN
*Apr 30 11:40:14.263: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Tunnel0 from FULL to DOWN, Neighbor Down: Adja cency forced to reset
*Apr 30 11:40:14.267: OSPF: 2 Way Communication to 3.3.3.3 on Tunnel0, state 2WAY
*Apr 30 11:40:14.267: OSPF: Send DBD to 3.3.3.3 on Tunnel0 seq 0x1506 opt 0x52 flag 0x7 len 32
*Apr 30 11:40:14.723: OSPF: 3.3.3.3 address 172.16.0.3 on Tunnel0 is dead, state DOWN
*Apr 30 11:40:14.723: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Tunnel0 from EXSTART to DOWN, Neighbor Down: A djacency forced to reset
*Apr 30 11:40:14.727: OSPF: 2 Way Communication to 2.2.2.2 on Tunnel0, state 2WAY
*Apr 30 11:40:14.727: OSPF: Send DBD to 2.2.2.2 on Tunnel0 seq 0x1994 opt 0x52 flag 0x7 len 32
*Apr 30 11:40:14.731: OSPF: OSPF: Rcv pkt from Tunnel0 src 172.16.0.3 dst 224.0.0.5 id 3.3.3.3 type 2 if_state 4 : ignored due to unknown neighbor
*Apr 30 11:40:14.735: OSPF: Rcv DBD from 2.2.2.2
R1HUB#sho on Tunnel0 seq 0x671 opt 0x52 flag 0x7 len 32 mtu 1472 state EXSTART
*Apr 30 11:40:14.735: OSPF: NBR Negotiation Done. We are the SLAVE
*Apr 30 11:40:14.735: OSPF: Send DBD to 2.2.2.2 on Tunnel0 seq 0x671 opt 0x52 flag 0x2 len 92
*Apr 30 11:40:14.747: OSPF: 2.2.2.2 address 172.16.0.2 on Tunnel0 is dead, state DOWN
*Apr 30 11:40:14.747: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Tunnel0 from EXCHANGE to DOWN, Neighbor Down: Adjacency forced to reset

Thanks.

ospf neighbor mismatch.jpg

Find more posts tagged with

Comments

hurricane1091

I am curious!

DCD

It's hard to tell from the output but it look like your tunnel down do to no data traffic is flowing to the spoke to keep the tunnel up.

hurricane1091

I'm not advanced enough to go too deep into this, but what is the timeout of the VPN? If it's less than how frequently the OSPF hello's are sent, it would close down and re-initiate (flap).

AwesomeGarrett

Have you checked your OSPF interface types?

siggnation

It's bizarre. Once I add R3 to ospf area 0, R2 and R3's neighbor relationship start to flip-flop. This error occurs at the EXSTART phase. I wonder if it is experiencing issues with the Master/Slave relationship. Hmm.

siggnation

AwesomeGarrett wrote: »

Have you checked your OSPF interface types?

Garrett my man, welcome to this mess, lol.

Great suggestion, and I have ip ospf network broadcast set on the hub and ip ospf netword non-broadcast setup on the 2 spokes.

siggnation

hurricane1091 wrote: »

I'm not advanced enough to go too deep into this, but what is the timeout of the VPN? If it's less than how frequently the OSPF hello's are sent, it would close down and re-initiate (flap).

Hurricane-- I set the ip nhrp holdtime to 600, higher than the ospf hold time.

siggnation

So for kicks, I took R2 out of the ospf participation and bam! R3 and R1 are fine now with lsa exchange and neighborship. Same goes for R1 and R2 when R3 is taken out of the ospf game. Once both spokes participate with the Hub, we're left with a messy 3-way that highly disagrees.

AwesomeGarrett

Post some configs.

Other than getting the easy stuff out of the way(i.e. MTU, OSPF network types, interface timers), we'll just have to take a look.

fredrikjj

some things to check:

- mismatched interface MTU
- duplicate router IDs
- broken unicast connectivity

(this is what the IP Routing Troubleshooting book says about exstart/exchange problems).

siggnation

The link will take you to my Google Drive folder to view the show run output:

https://drive.google.com/folderview?id=0B-UDeHZrqQcOflVLU1psUHBNQy1IZDdjYjd5X3FnX3hLRjU0dXNpVXA1WUJFQ2JMb0IwYkk&usp=sharing

Thanks guys.

Please display the output from these commands Show Crypto Isakap Sa , Show IP Route , Show IP Interface Brief , Debug DMVPN Detail All.

siggnation

DCD wrote: »

Please display the output from these commands Show Crypto Isakap Sa , Show IP Route , Show IP Interface Brief , Debug DMVPN Detail All.

I'm not running any IPSEC so crypto is out. All routers can reach each other because they have a static default route running through the Internet Cloud (R4). I'm running a debug on dmvpn and it hasn't produced any productive output pertaining to the issue at hand. So far, debugging ospf adj has given me the most details about this.

siggnation

AwesomeGarrett wrote: »

Have you checked your OSPF interface types?

Holy moly---Garrett wins the day. When I first read this I thought, "yeah, I set the opsf network types to broadcast on all three afterwards and nothing to show for it; however, I was configuring ospf commands on the PHYSICAL interfaces, rather than the required TUNNEL interface."

I feel as though Occam's Razor showed up here. A valuable lesson to learn.

Hondabuff

I would add "Passive interface default on each router" and add "no passive interface tunnel 0" on each router. Just to control where your sending the LSA's to.

siggnation

Absolutely Honda, great suggestion. I need to condition myself to enter best practice commands like those.

Cheers.