06-15-2023
03:23 AM
- last edited on
06-20-2023
03:21 AM
by
Translator
Hello experts,
I have a topology like below:
Three routers R1, R2, R3 are running DMVPN phase 1. And I configure by static mapping, like below:
I attach my
eve-ng lab
file, you can download and check it.
HUB:
interface Tunnel1
no shutdown
ip address 10.0.0.1 255.255.255.0
ip nhrp map 10.0.0.2 113.171.2.2
ip nhrp map 10.0.0.3 113.171.3.2
ip nhrp network-id 111
tunnel source Ethernet0/0
tunnel mode gre multipoint
SPOKE R2 and R3 similar (just different IP and network ID):
interface Tunnel1
no shutdown
ip address 10.0.0.2 255.255.255.0
ip nhrp map 10.0.0.1 113.171.1.2
ip nhrp network-id 222
tunnel source Ethernet0/0
tunnel destination 113.171.1.2
After I configure , the tunnel on each router is up normally.
But the problem is that after I enable OSPF on tunnel like this:
HUB and SPOKEs:
int tu1
ip ospf 1 area 0
ip ospf network point-to-multipoint
Then OSPF is DOWN/UP frequently.
%OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on Tunnel1 from FULL to DOWN, Neighbor Down: Dead timer expired
%OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on Tunnel1 from LOADING to FULL, Loading Done
I
show ip ospf neighbor
on R2, and see that: OSPF dead timer is 120 seconds, but hello packet is sent from HUB to SPOKE each 125ms, then the result is OSPF down/up again and again.
P/S:
If I add command below:
at HUB:
int tu1
ip nhrp map multicast 113.171.2.2 (IP NBMA of SPOKE R2)
ip nhrp map multicast 113.171.3.2 (IP NBMA of SPOKE R3)
at both SPOKEs:
ip nhrp map multicast 113.171.1.2 (IP NBMA of HUB)
Then OSPF send hello packet always on time, each 30 seconds. And OSPF is UP stably.
My question is why before I add above commands, OSPF still send OSPF hello but very late ( about 125seconds).
Please help to explain.
Thank you!!
Solved! Go to Solution.
06-15-2023
01:20 PM
- last edited on
06-20-2023
03:27 AM
by
Translator
but hello packet is sent from HUB to SPOKE each 125ms, then the result is OSPF down/up again and again.
Hi, above statement is incorrect. It is not root cause.
Let me explain case. On hub you have gre multipoint, on spoke
gre point-to-point
When multicast map does not exists, spoke still sends OSPF multicast hello to remote destination (router assumes only one neighbor due to tunnel type
gre point-to-point
). Packet reaches the hub and hub responses with unicast packet (when first hello is received from spoke, hub sends immediate hello), so this traffic is also reached to spoke. They exchange other OSPF packets (DBD / LSR / LSU / LSA) which are also unicast and adjacency is created.
However, after successful neighborship hub sends multicast hello which can not reach spoke. Spoke sends multicast with mapping tunnel destination and hello which reaches hub. Both are multicast, but due to tunnel type (gre multipoint vs
gre point-to-point
) spoke knows where router can map that multicast, hub does not know.
*Jun 15 20:13:00.797: OSPF-1 HELLO Tu1: Rcv hello from 192.168.2.1 area 0 10.0.0.2
*Jun 15 20:13:00.797: OSPF-1 HELLO Tu1: Send immediate hello to nbr 192.168.2.1, src address 10.0.0.2
*Jun 15 20:13:00.797: OSPF-1 HELLO Tu1: Send hello to 10.0.0.2 area 0 from 10.0.0.1
*Jun 15 20:13:00.798: OSPF-1 HELLO Tu1: Rcv hello from 192.168.2.1 area 0 10.0.0.2
*Jun 15 20:13:00.798: OSPF-1 ADJ Tu1: 2 Way Communication to 192.168.2.1, state 2WAY
*Jun 15 20:13:00.798: OSPF-1 ADJ Tu1: Nbr 192.168.2.1: Prepare dbase exchange
*Jun 15 20:13:00.798: OSPF-1 ADJ Tu1: Send DBD to 192.168.2.1 seq 0x1EB0 opt 0x52 flag 0x7 len 32
*Jun 15 20:13:00.798: OSPF-1 ADJ Tu1: Rcv DBD from 192.168.2.1 seq 0x9E2 opt 0x52 flag 0x7 len 32 mtu 1476 state EXSTART
*Jun 15 20:13:00.798: OSPF-1 ADJ Tu1: NBR Negotiation Done. We are the SLAVE
*Jun 15 20:13:00.798: OSPF-1 ADJ Tu1: Nbr 192.168.2.1: Summary list built, size 1
*Jun 15 20:13:00.798: OSPF-1 ADJ Tu1: Send DBD to 192.168.2.1 seq 0x9E2 opt 0x52 flag 0x2 len 52
*Jun 15 20:13:00.802: OSPF-1 ADJ Tu1: Rcv DBD from 192.168.2.1 seq 0x9E3 opt 0x52 flag 0x1 len 32 mtu 1476 state EXCHANGE
*Jun 15 20:13:00.802: OSPF-1 ADJ Tu1: Exchange Done with 192.168.2.1
*Jun 15 20:13:00.802: OSPF-1 ADJ Tu1: Synchronized with 192.168.2.1, state FULL
*Jun 15 20:13:00.802: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.2.1 on Tunnel1 from LOADING to FULL, Loading Done
*Jun 15 20:13:40.803: OSPF-1 ADJ Tu1: Nbr 192.168.2.1: Clean-up dbase exchange
*Jun 15 20:13:49.145: OSPF-1 HELLO Tu1: Rcv hello from 192.168.2.1 area 0 10.0.0.2
*Jun 15 20:13:49.146: OSPF-1 ADJ Tu1: Cannot see ourself in hello from 192.168.2.1, state INIT
*Jun 15 20:13:49.146: OSPF-1 HELLO Tu1: Send immediate hello to nbr 192.168.2.1, src address 10.0.0.2
*Jun 15 20:13:49.146: OSPF-1 HELLO Tu1: Send hello to 10.0.0.2 area 0 from 10.0.0.1
*Jun 15 20:13:49.151: OSPF-1 HELLO Tu1: Rcv hello from 192.168.2.1 area 0 10.0.0.2
*Jun 15 20:13:49.151: OSPF-1 ADJ Tu1: 2 Way Communication to 192.168.2.1, state 2WAY
*Jun 15 20:13:49.151: OSPF-1 ADJ Tu1: Nbr 192.168.2.1: Prepare dbase exchange
*Jun 15 20:13:49.151: OSPF-1 ADJ Tu1: Send DBD to 192.168.2.1 seq 0x9E4 opt 0x52 flag 0x7 len 32
*Jun 15 20:13:49.151: OSPF-1 ADJ Tu1: Rcv DBD from 192.168.2.1 seq 0x1751 opt 0x52 flag 0x7 len 32 mtu 1476 state EXSTART
*Jun 15 20:13:49.151: OSPF-1 ADJ Tu1: NBR Negotiation Done. We are the SLAVE
*Jun 15 20:13:49.151: OSPF-1 ADJ Tu1: Nbr 192.168.2.1: Summary list built, size 2
*Jun 15 20:13:49.151: OSPF-1 ADJ Tu1: Send DBD to 192.168.2.1 seq 0x1751 opt 0x52 flag 0x2 len 72
*Jun 15 20:13:49.152: OSPF-1 ADJ Tu1: Rcv DBD from 192.168.2.1 seq 0x1752 opt 0x52 flag 0x1 len 72 mtu 1476 state EXCHANGE
*Jun 15 20:13:49.152: OSPF-1 ADJ Tu1: Exchange Done with 192.168.2.1
*Jun 15 20:13:49.152: OSPF-1 ADJ Tu1: Send LS REQ to 192.168.2.1 length 36 LSA count 1
*Jun 15 20:13:49.152: OSPF-1 ADJ Tu1: Send DBD to 192.168.2.1 seq 0x1752 opt 0x52 flag 0x0 len 32
*Jun 15 20:13:49.153: OSPF-1 ADJ Tu1: Rcv LS UPD from 192.168.2.1 length 76 LSA count 1
*Jun 15 20:13:49.153: OSPF-1 ADJ Tu1: Synchronized with 192.168.2.1, state FULL
*Jun 15 20:13:49.153: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.2.1 on Tunnel1 from LOADING to FULL, Loading Done
On hub:
*Jun 15 20:13:00.802: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.2.1 on Tunnel1 from LOADING to FULL, Loading Done
*Jun 15 20:13:49.153: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.2.1 on Tunnel1 from LOADING to FULL, Loading Done
*Jun 15 20:14:36.866: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.2.1 on Tunnel1 from LOADING to FULL, Loading Done
On spoke:
*Jun 15 20:13:43.803: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on Tunnel1 from FULL to DOWN, Neighbor Down: Dead timer expired
*Jun 15 20:13:49.153: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on Tunnel1 from LOADING to FULL, Loading Done
*Jun 15 20:14:31.658: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on Tunnel1 from FULL to DOWN, Neighbor Down: Dead timer expired
*Jun 15 20:14:36.866: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on Tunnel1 from LOADING to FULL, Loading Done
*Jun 15 20:15:19.371: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on Tunnel1 from FULL to DOWN, Neighbor Down: Dead timer expired
As you see, on hub neighborship during next 40 sec (after loading to full) is still refreshed by spoke and it in reality does not go down.
On spoke, spoke just counts down 40 sec, but neighborship goes down, because there is no hello from hub.
Summary:
The reason for down/up on spoke is tunnel nature. Tunnel
gre point-to-multipoint
can not map multicast to unicast IP without
ip nhrp map
command. Tunnel
gre point-to-point
can do it if tunnel destination is configured. In reality, if spoke tunnel will remain
point-to-point
(so only one hub DMVPN design), it is not mandatory to configure multicast map for spoke.
06-15-2023 08:51 AM
Hello,
It probably sends it initially thinking it can reach its neighbor without that command. But due to the nature of DMVPN you need the multicast command to allow the routing protocol multicast messages to pass through and establish adjacencies.
06-15-2023
09:05 AM
- last edited on
06-20-2023
03:23 AM
by
Translator
this config must work
interface Tunnel1
no shutdown
ip address 10.0.0.1 255.255.255.0ip nhrp map 10.0.0.2 113.171.2.2 <<- deleteip nhrp map 10.0.0.3 113.171.3.2 <<- delete
ip nhrp network-id 111
ip nhrp map multicast dynamic
tunnel key 10
tunnel source Ethernet0/0
ip ospf network type broadcast ip ospf priority 100
tunnel mode gre multipoint
SPOKE R2 and R3 similar (just different IP and network ID):
interface Tunnel1
no shutdown
ip address 10.0.0.2 255.255.255.0
ip nhrp nhs 10.0.0.1
tunnel key 10
ip nhrp map multicast 113.171.1.2
ip nhrp map 10.0.0.1 113.171.1.2 ip ospf network type broadcast
ip nhrp network-id 111
tunnel source Ethernet0/0
tunnel destination 113.171.1.2 <<- HUB
06-15-2023
01:20 PM
- last edited on
06-20-2023
03:27 AM
by
Translator
but hello packet is sent from HUB to SPOKE each 125ms, then the result is OSPF down/up again and again.
Hi, above statement is incorrect. It is not root cause.
Let me explain case. On hub you have gre multipoint, on spoke
gre point-to-point
When multicast map does not exists, spoke still sends OSPF multicast hello to remote destination (router assumes only one neighbor due to tunnel type
gre point-to-point
). Packet reaches the hub and hub responses with unicast packet (when first hello is received from spoke, hub sends immediate hello), so this traffic is also reached to spoke. They exchange other OSPF packets (DBD / LSR / LSU / LSA) which are also unicast and adjacency is created.
However, after successful neighborship hub sends multicast hello which can not reach spoke. Spoke sends multicast with mapping tunnel destination and hello which reaches hub. Both are multicast, but due to tunnel type (gre multipoint vs
gre point-to-point
) spoke knows where router can map that multicast, hub does not know.
*Jun 15 20:13:00.797: OSPF-1 HELLO Tu1: Rcv hello from 192.168.2.1 area 0 10.0.0.2
*Jun 15 20:13:00.797: OSPF-1 HELLO Tu1: Send immediate hello to nbr 192.168.2.1, src address 10.0.0.2
*Jun 15 20:13:00.797: OSPF-1 HELLO Tu1: Send hello to 10.0.0.2 area 0 from 10.0.0.1
*Jun 15 20:13:00.798: OSPF-1 HELLO Tu1: Rcv hello from 192.168.2.1 area 0 10.0.0.2
*Jun 15 20:13:00.798: OSPF-1 ADJ Tu1: 2 Way Communication to 192.168.2.1, state 2WAY
*Jun 15 20:13:00.798: OSPF-1 ADJ Tu1: Nbr 192.168.2.1: Prepare dbase exchange
*Jun 15 20:13:00.798: OSPF-1 ADJ Tu1: Send DBD to 192.168.2.1 seq 0x1EB0 opt 0x52 flag 0x7 len 32
*Jun 15 20:13:00.798: OSPF-1 ADJ Tu1: Rcv DBD from 192.168.2.1 seq 0x9E2 opt 0x52 flag 0x7 len 32 mtu 1476 state EXSTART
*Jun 15 20:13:00.798: OSPF-1 ADJ Tu1: NBR Negotiation Done. We are the SLAVE
*Jun 15 20:13:00.798: OSPF-1 ADJ Tu1: Nbr 192.168.2.1: Summary list built, size 1
*Jun 15 20:13:00.798: OSPF-1 ADJ Tu1: Send DBD to 192.168.2.1 seq 0x9E2 opt 0x52 flag 0x2 len 52
*Jun 15 20:13:00.802: OSPF-1 ADJ Tu1: Rcv DBD from 192.168.2.1 seq 0x9E3 opt 0x52 flag 0x1 len 32 mtu 1476 state EXCHANGE
*Jun 15 20:13:00.802: OSPF-1 ADJ Tu1: Exchange Done with 192.168.2.1
*Jun 15 20:13:00.802: OSPF-1 ADJ Tu1: Synchronized with 192.168.2.1, state FULL
*Jun 15 20:13:00.802: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.2.1 on Tunnel1 from LOADING to FULL, Loading Done
*Jun 15 20:13:40.803: OSPF-1 ADJ Tu1: Nbr 192.168.2.1: Clean-up dbase exchange
*Jun 15 20:13:49.145: OSPF-1 HELLO Tu1: Rcv hello from 192.168.2.1 area 0 10.0.0.2
*Jun 15 20:13:49.146: OSPF-1 ADJ Tu1: Cannot see ourself in hello from 192.168.2.1, state INIT
*Jun 15 20:13:49.146: OSPF-1 HELLO Tu1: Send immediate hello to nbr 192.168.2.1, src address 10.0.0.2
*Jun 15 20:13:49.146: OSPF-1 HELLO Tu1: Send hello to 10.0.0.2 area 0 from 10.0.0.1
*Jun 15 20:13:49.151: OSPF-1 HELLO Tu1: Rcv hello from 192.168.2.1 area 0 10.0.0.2
*Jun 15 20:13:49.151: OSPF-1 ADJ Tu1: 2 Way Communication to 192.168.2.1, state 2WAY
*Jun 15 20:13:49.151: OSPF-1 ADJ Tu1: Nbr 192.168.2.1: Prepare dbase exchange
*Jun 15 20:13:49.151: OSPF-1 ADJ Tu1: Send DBD to 192.168.2.1 seq 0x9E4 opt 0x52 flag 0x7 len 32
*Jun 15 20:13:49.151: OSPF-1 ADJ Tu1: Rcv DBD from 192.168.2.1 seq 0x1751 opt 0x52 flag 0x7 len 32 mtu 1476 state EXSTART
*Jun 15 20:13:49.151: OSPF-1 ADJ Tu1: NBR Negotiation Done. We are the SLAVE
*Jun 15 20:13:49.151: OSPF-1 ADJ Tu1: Nbr 192.168.2.1: Summary list built, size 2
*Jun 15 20:13:49.151: OSPF-1 ADJ Tu1: Send DBD to 192.168.2.1 seq 0x1751 opt 0x52 flag 0x2 len 72
*Jun 15 20:13:49.152: OSPF-1 ADJ Tu1: Rcv DBD from 192.168.2.1 seq 0x1752 opt 0x52 flag 0x1 len 72 mtu 1476 state EXCHANGE
*Jun 15 20:13:49.152: OSPF-1 ADJ Tu1: Exchange Done with 192.168.2.1
*Jun 15 20:13:49.152: OSPF-1 ADJ Tu1: Send LS REQ to 192.168.2.1 length 36 LSA count 1
*Jun 15 20:13:49.152: OSPF-1 ADJ Tu1: Send DBD to 192.168.2.1 seq 0x1752 opt 0x52 flag 0x0 len 32
*Jun 15 20:13:49.153: OSPF-1 ADJ Tu1: Rcv LS UPD from 192.168.2.1 length 76 LSA count 1
*Jun 15 20:13:49.153: OSPF-1 ADJ Tu1: Synchronized with 192.168.2.1, state FULL
*Jun 15 20:13:49.153: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.2.1 on Tunnel1 from LOADING to FULL, Loading Done
On hub:
*Jun 15 20:13:00.802: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.2.1 on Tunnel1 from LOADING to FULL, Loading Done
*Jun 15 20:13:49.153: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.2.1 on Tunnel1 from LOADING to FULL, Loading Done
*Jun 15 20:14:36.866: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.2.1 on Tunnel1 from LOADING to FULL, Loading Done
On spoke:
*Jun 15 20:13:43.803: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on Tunnel1 from FULL to DOWN, Neighbor Down: Dead timer expired
*Jun 15 20:13:49.153: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on Tunnel1 from LOADING to FULL, Loading Done
*Jun 15 20:14:31.658: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on Tunnel1 from FULL to DOWN, Neighbor Down: Dead timer expired
*Jun 15 20:14:36.866: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on Tunnel1 from LOADING to FULL, Loading Done
*Jun 15 20:15:19.371: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on Tunnel1 from FULL to DOWN, Neighbor Down: Dead timer expired
As you see, on hub neighborship during next 40 sec (after loading to full) is still refreshed by spoke and it in reality does not go down.
On spoke, spoke just counts down 40 sec, but neighborship goes down, because there is no hello from hub.
Summary:
The reason for down/up on spoke is tunnel nature. Tunnel
gre point-to-multipoint
can not map multicast to unicast IP without
ip nhrp map
command. Tunnel
gre point-to-point
can do it if tunnel destination is configured. In reality, if spoke tunnel will remain
point-to-point
(so only one hub DMVPN design), it is not mandatory to configure multicast map for spoke.
06-15-2023 10:15 PM
Thank Kanan,
Thank for your reply, I understand that main cause is: I have not yet enabled mapping multicast clearly on HUB. So HUB doesn't know where to send multicast traffic ( which is hello).
But I am not sure why when I capture wirehshark on HUB:
- HUB receivce many hello packets (red color) from R2, (and R3 similar)
But why it does not reply (yellow color) as soon as time of receving but wait about more than 120s, example: receive red color at 12:07:20, and wait ultil 12:08:47 to send hello reply .
Thanks!!
06-15-2023 10:24 PM - edited 06-15-2023 10:25 PM
Immediate hello is not sent always. It is sent when state is lower than 2-way (INIT) or as you have seen log, router has normal state (FULL), but router does not see itself in neighbor's hello. Below is RFC draft which shows this mechanism and used by vendors for OSPF tuning purposes.
https://datatracker.ietf.org/doc/html/draft-kou-ospf-immediately-replying-hello-00
06-16-2023 12:33 AM
Your config have many mistakes' check my reply I use broadcast Or @pman reply he use point to multipoint.
Ospf in dmvpn must config correct otherwise the neighbor will stuck in one state not full.
06-15-2023
02:31 PM
- last edited on
06-20-2023
03:45 AM
by
Translator
Hi,
Attaches the minimal changes made to stabilize DMVPN and OSPF:
R1-HUB
interface Tunnel1
no shutdown
ip address 10.0.0.1 255.255.255.0
no ip redirects
ip nhrp map 10.0.0.2 113.171.2.2 <--- deleted
ip nhrp map 10.0.0.3 113.171.3.2 <--- deleted
ip nhrp map multicast dynamic <--- added
ip nhrp network-id 111
ip ospf network point-to-multipoint
ip ospf 1 area 0
tunnel source Ethernet0/0
tunnel mode gre multipoint
!
R2-SPOKE
interface Tunnel1
ip address 10.0.0.2 255.255.255.0
ip nhrp map 10.0.0.1 113.171.1.2
ip nhrp map multicast 113.171.1.2 <--- added
ip nhrp network-id 222 <--- deleted
ip nhrp network-id 111 <--- added
ip nhrp nhs 10.0.0.1 <--- added
ip ospf network point-to-multipoint
ip ospf 1 area 0
tunnel source Ethernet0/0
tunnel destination 113.171.1.2
!
R3-SPOKE
interface Tunnel1
no shutdown
ip address 10.0.0.3 255.255.255.0
ip nhrp map 10.0.0.1 113.171.1.2
ip nhrp map multicast 113.171.1.2 <--- added
ip nhrp network-id 333 <--- deleted
ip nhrp network-id 111 <--- added
ip nhrp nhs 10.0.0.1 <--- added
ip ospf network point-to-multipoint
ip ospf 1 area 0
tunnel source Ethernet0/0
tunnel destination 113.171.1.2
R1-HUB(config-if)#do show dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer
NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
UpDn Time --> Up or Down Time for a Tunnel
==========================================================================
Interface: Tunnel1, IPv4 NHRP Details
Type:Hub, NHRP Peers:2,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 113.171.2.2 10.0.0.2 UP 00:10:27 D
1 113.171.3.2 10.0.0.3 UP 00:10:27 D
R1-HUB(config-if)#do show ip route
.
.
.
O 192.168.2.0/24 [110/1010] via 10.0.0.2, 00:11:54, Tunnel1
O 192.168.3.0/24 [110/1010] via 10.0.0.3, 00:11:54, Tunnel1
how to configure DMVPN Phase 1 Basic Configuration:
https://networklessons.com/cisco/ccie-routing-switching/dmvpn-phase-1-basic-configuration
DMVPN Phase 1 Debugs Troubleshoot Guide
https://www.cisco.com/c/en/us/support/docs/security-vpn/dynamic-multi-point-vpn-dmvpn/116957-technote-dmvpn-00.html#anc14
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: