OSPF flapping

[misaleh]

I am having a problem in my OSPF network. I have a connectivity with my ISP via OSPF that connects us to a remote site but the neighborship keeps flapping. The neighborship is via a sub-interface, there are 3 other subinterfaces on the same physical interface and they don't flap. There are no CRCs on the interface. I've tried changing the hello and dead timers to 30 and 120 respectively, but the issue still occurs. I've also added " ip ospf mtu-ignore", but it also didn't fix the problem. I'm not sure what exactly is the issue or how to fix it so any help would be really appreciated.

The OSPF config. on my router is:

Router ospf 12 vrf WAN
router id x.x.x.x
network 10.0.0.0 0.255.255.255 area 0
default-information originate

interface gi0/0/2.1142
bandwidth 20000
encapsualtion dot1q 1142
ip vrf forwarding WAN
ip address 10.x.x.x 255.255.255.252

and the OSPF configuration on the ISP router is:

router ospf 1
router-id x.x.x.x
redistribute static subnets
network 10.x.x.x 0.0.0.3 area 0

interface Ethernet0.1142
encapsulation dot1Q 1142
ip address 10.x.x.x 255.255.255.252

Here are the logs that appear on the router:

Aug 25 11:51:06: %OSPF-5-ADJCHG: Process 12, Nbr 10.x.x.x on GigabitEthernet0/0/2.1142 from LOADING to FULL, Loading Done
Aug 25 11:55:23: %OSPF-5-ADJCHG: Process 12, Nbr 10.x.x.x on GigabitEthernet0/0/2.1142 from LOADING to FULL, Loading Done
Aug 25 11:56:25: %OSPF-5-ADJCHG: Process 12, Nbr 10.x.x.x on GigabitEthernet0/0/2.1142 from LOADING to FULL, Loading Done
Aug 25 11:59:20: %OSPF-5-ADJCHG: Process 12, Nbr 10.x.x.x on GigabitEthernet0/0/2.1142 from LOADING to FULL, Loading Done
Aug 25 12:02:12: %OSPF-5-ADJCHG: Process 12, Nbr 10.x.x.x on GigabitEthernet0/0/2.1142 from LOADING to FULL, Loading Done
Aug 25 12:03:27: %OSPF-5-ADJCHG: Process 12, Nbr 10.x.x.x on GigabitEthernet0/0/2.1142 from LOADING to FULL, Loading Done
Aug 25 12:06:56: %OSPF-5-ADJCHG: Process 12, Nbr 10.x.x.x on GigabitEthernet0/0/2.1142 from LOADING to FULL, Loading Done
Aug 25 12:10:47: %OSPF-5-ADJCHG: Process 12, Nbr 10.x.x.x on GigabitEthernet0/0/2.1142 from FULL to DOWN, Neighbor Down: Dead timer expired
Aug 25 12:12:30: %OSPF-5-ADJCHG: Process 12, Nbr 10.x.x.x on GigabitEthernet0/0/2.1142 from LOADING to FULL, Loading Done
Aug 25 12:14:21: %OSPF-5-ADJCHG: Process 12, Nbr 10.x.x.x on GigabitEthernet0/0/2.1142 from LOADING to FULL, Loading Done
Aug 25 12:16:47: %OSPF-5-ADJCHG: Process 12, Nbr 10.x.x.x on GigabitEthernet0/0/2.1142 from LOADING to FULL, Loading Done
Aug 25 12:20:05: %OSPF-5-ADJCHG: Process 12, Nbr 10.x.x.x on GigabitEthernet0/0/2.1142 from LOADING to FULL, Loading Done

[MHM Cisco World]

can you double check the mask 
one side is /8 other is /30 

[Richard Burts]

I do not understand why the original poster believes that IP addresses in network 10.0.0.0 need to be disguised. But they are disguised and we will have to work with the information that we have got. If the masks that MHM references were masks for interfaces then I would agree that the mismatch could be an issue. But these masks are for OSPF to figure out which interfaces should be active in OSPF. On the customer router the /8 mask means that any address in network 10.0.0.0 is a match. Certainly interface gi0/0/2.1142 is a match and runs OSPF. There is some possibility that other interfaces on the router also match - but I do not see how that would impact this issue. On the ISP router the /30 mask means that only 1 interface could be a match. We assume that interface Ethernet0.1142 is a match because  there is an OSPF adjacency. So the mask mismatch is not a big deal.

I find the log messages puzzling. There is one instance where the neighbor relationship went down due to dead timer expired. And there are lots of messages about going LOADING to FULL. Why are there not messages when it transitions to the loading phase? Perhaps the output of debug for ospf adjacency might shed some light?

[misaleh]

Aug 25 08:42:21.264: OSPF-12 ADJ Gi0/0/2.1142: Cannot see ourself in hello from 10.200.14.14, state INIT
Aug 25 08:42:21.264: OSPF-12 ADJ Gi0/0/2.1142: Neighbor change event
Aug 25 08:42:21.264: OSPF-12 ADJ Gi0/0/2.1142: DR/BDR election
Aug 25 08:42:21.264: OSPF-12 ADJ Gi0/0/2.1142: Elect BDR 0.0.0.0
Aug 25 08:42:21.264: OSPF-12 ADJ Gi0/0/2.1142: Elect DR 172.18.0.189
Aug 25 08:42:21.264: OSPF-12 ADJ Gi0/0/2.1142: DR: 172.18.0.189 (Id)
Aug 25 08:42:21.265: OSPF-12 ADJ Gi0/0/2.1142: BDR: none
Aug 25 08:42:21.271: OSPF-12 ADJ Gi0/0/2.1142: 2 Way Communication to 10.200.14.14, state 2WAY
Aug 25 08:42:21.271: OSPF-12 ADJ Gi0/0/2.1142: Neighbor change event
Aug 25 08:42:21.271: OSPF-12 ADJ Gi0/0/2.1142: DR/BDR election
Aug 25 08:42:21.271: OSPF-12 ADJ Gi0/0/2.1142: Elect BDR 10.200.14.14
Aug 25 08:42:21.271: OSPF-12 ADJ Gi0/0/2.1142: Elect DR 172.18.0.189
Aug 25 08:42:21.271: OSPF-12 ADJ Gi0/0/2.1142: DR: 172.18.0.189 (Id)
Aug 25 08:42:21.271: OSPF-12 ADJ Gi0/0/2.1142: BDR: 10.200.14.14 (Id)
Aug 25 08:42:21.271: OSPF-12 ADJ Gi0/0/2.1142: Nbr 10.200.14.14: Prepare dbase exchange
Aug 25 08:42:21.272: OSPF-12 ADJ Gi0/0/2.1142: Send DBD to 10.200.14.14 seq 0x230E opt 0x52 flag 0x7 len 32
Aug 25 08:42:21.272: OSPF-12 ADJ Gi0/0/2.1142: Neighbor change event
Aug 25 08:42:21.272: OSPF-12 ADJ Gi0/0/2.1142: DR/BDR election
Aug 25 08:42:21.272: OSPF-12 ADJ Gi0/0/2.1142: Elect BDR 10.200.14.14
Aug 25 08:42:21.272: OSPF-12 ADJ Gi0/0/2.1142: Elect DR 172.18.0.189
Aug 25 08:42:21.272: OSPF-12 ADJ Gi0/0/2.1142: DR: 172.18.0.189 (Id)
Aug 25 08:42:21.272: OSPF-12 ADJ Gi0/0/2.1142: BDR: 10.200.14.14 (Id)
Aug 25 08:42:21.272: OSPF-12 ADJ Gi0/0/2.1142: Neighbor change event
Aug 25 08:42:21.272: OSPF-12 ADJ Gi0/0/2.1142: DR/BDR election
Aug 25 08:42:21.272: OSPF-12 ADJ Gi0/0/2.1142: Elect BDR 10.200.14.14
Aug 25 08:42:21.272: OSPF-12 ADJ Gi0/0/2.1142: Elect DR 172.18.0.189
Aug 25 08:42:21.272: OSPF-12 ADJ Gi0/0/2.1142: DR: 172.18.0.189 (Id)
Aug 25 08:42:21.272: OSPF-12 ADJ Gi0/0/2.1142: BDR: 10.200.14.14 (Id)
Aug 25 08:42:21.272: OSPF-12 ADJ Gi0/0/2.1142: Rcv DBD from 10.200.14.14 seq 0xD90 opt 0x52 flag 0x7 len 32 mtu 1500 state EXSTART
Aug 25 08:42:21.272: OSPF-12 ADJ Gi0/0/2.1142: First DBD and we are not SLAVE
Aug 25 08:42:21.279: OSPF-12 ADJ Gi0/0/2.1142: Rcv DBD from 10.200.14.14 seq 0x230E opt 0x52 flag 0x2 len 292 mtu 1500 state EXSTART
Aug 25 08:42:21.279: OSPF-12 ADJ Gi0/0/2.1142: NBR Negotiation Done. We are the MASTER
Aug 25 08:42:21.279: OSPF-12 ADJ Gi0/0/2.1142: Nbr 10.200.14.14: Summary list built, size 13
Aug 25 08:42:21.279: OSPF-12 ADJ Gi0/0/2.1142: Send DBD to 10.200.14.14 seq 0x230F opt 0x52 flag 0x1 len 52
Aug 25 08:42:21.286: OSPF-12 ADJ Gi0/0/2.1142: Rcv DBD from 10.200.14.14 seq 0x230F opt 0x52 flag 0x0 len 32 mtu 1500 state EXCHANGE
Aug 25 08:42:21.286: OSPF-12 ADJ Gi0/0/2.1142: Exchange Done with 10.200.14.14
Aug 25 08:42:21.286: OSPF-12 ADJ Gi0/0/2.1142: Send LS REQ to 10.200.14.14 length 36
Aug 25 08:42:21.293: OSPF-12 ADJ Gi0/0/2.1142: Rcv LS UPD from Nbr ID 10.200.14.14 length 64 LSA count 1
Aug 25 08:42:21.293: OSPF-12 ADJ Gi0/0/2.1142: Synchronized with 10.200.14.14, state FULL
Aug 25 10:42:21: %OSPF-5-ADJCHG: Process 12, Nbr 10.200.14.14 on GigabitEthernet0/0/2.1142 from LOADING to FULL, Loading Done
Aug 25 10:44:44: %OSPF-5-ADJCHG: Process 12, Nbr 10.200.14.14 on GigabitEthernet0/0/2.1142 from LOADING to FULL, Loading Done

[MHM Cisco World]

See below comment 

[paul driver]

Hello

Try the following

rtr
interface gi0/0/2.1142
ip ospf 12 area 0
ip ospf network point-to-point

Router ospf 12 vrf WAN
no network 10.0.0.0 0.255.255.255 area 0

ISP router
interface Ethernet0.1142
ip ospf 1 area 0
ip ospf network point-to-point

router ospf 1
no network 10.x.x.x 0.0.0.3 area 0

[misaleh]

Will try it tomorrow, but what if I want to advertise other networks 10.x.x.x in OSPF?

[MHM Cisco World]

One more Q 

Are you run ospf between cisco and other vendor ? 

[misaleh]

the isp router is cisco as well

[MHM Cisco World]

https://ine.com/blog/2011-03-30-ospf-and-mtu-mismatch

Mtu mismatch check link

Can not see is the key word here,

Check how router declare peer is down in end of link I share 

[misaleh]

but there is no mtu mismatch between my router and ISP router. Both have the default MTU. Also, the debug doesn't show any mtu mismatches.

[Richard Burts]

Thank you for the debug output. Am I correct in understanding that 10.200.14.14 is the ISP router with which you are neighbor? I am surprised to see in the debug output 172.18.0.189. Can you tell us what device this is?

[misaleh]

Yes, 10.200.14.14 is the ISP router and 172.18.0.189 is the router-id of my router.

[MHM Cisco World]

The ospf is check mtu before db exchanges,  but you here mention " ip ospf mtu-ignore"  command,  this commend ignore mtu check and hence you dont get log,

Default mtu not meaning match,  you must double check mtu in each interface. 

[MHM Cisco World]

Share the 
show ip ospf interface 
for both side