Hello Gowthamraj
At first glance, your configs look to be OK. Can you give us some more information about what kind of issues you are facing so we can further help you with the troubleshooting process?
Thanks!
Laz
Actually ospf adj not formed between hub and spoke .
Hello Gowthamraj
If youâre not getting adjacencies forming then you should first check to see that there is connectivity between the hub and spokes. In order for an adjacency to form, you must have IP connectivity between the two routers. You can also debug OSPF to check to see what packets are being exchanged.
Did you originally have OSPF adjacency when you configured the broadcast type in the lesson or did you go directly to the non-broadcast?
Laz
Hi Laz
When I trying with broadcast everything is working fine for me.
When I changed into non-broadcast itâs not working. I can able to ping from Hub to spoke.
i tried both network and neighbor command for non broadcast its working fine for me.
but for non broadcast we can give only neighbor command am i right?
Please reply asapâŚ
Hello Gowthamraj
Thatâs strange. Iâve labbed this one up and it seems to be working for me. Something else must be going on with your topology. Can you do some debugging to see what OSPF packets are being exchanged? Maybe a Wireshark capture would also help to take a look at the hello packets, their destination IP addresses, and the contents as well. We can see if the packets are actually reaching the neighbor and if the neighbor is rejecting them for some reason.
Try debugs and Wireshark and let us know what kind of results you get so we can further help you with troubleshooting.
I hope this has been helpful!
Laz
Okay laz I will check it and let you know
This is an important point to remember! I was thinking to myself, here in Phase 2 we are using GRE multipoint on all the Routers then how come OSPF Network Type is still P2P but I guess this makes it bit clear for me.
Thanks Laz!
1 Like
Hello!
This is something that Iâve noticed right now. When we are configuring static neighbors in non-broadcast and P2MP-NB network types, we only have to manually specify the neighbor only on the hub and not on the spokes as well?
Iâve configured the neighbors manually only on the hubâs side and the hub established an adjacency with the spokes which is something that I didnât expect, I thought that you have to also configure the neighbor (the hub) manually on the spokes.
Thank you.
David
Hello David
This is actually expected behavior. In an NBMA network type, the medium doesnât inherently support broadcast capabilities for OSPF Hello packets. The âneighborâ command is used to tell the OSPF process on that router where to send unicast Hello packets to form an adjacency.
When you configure one OSPF router with the neighbor command, that router starts sending unicast Hello packets to the specified neighbor. The receiving router (even if it hasnât been configured with the corresponding neighbor command yet) will see those Hello packets and process them. If the Hello packets meet the criteria for forming an adjacency (matching area, subnet, hello/dead timers, etc.), the receiving router will respond with its own Hello packets and an adjacency can form.
However, this doesnât mean the configuration is complete or optimal. For a resilient and predictable OSPF over NBMA network, both sides should be manually configured with neighbor commands to ensure that unicast Hellos are initiated in both directions. This also ensures that if one side is restarted or its OSPF process is reset, it will still attempt to re-establish the adjacency once it comes back up.
Although the OSPF adjacency can form with just one side configured, you should always configure both sides for best practices and operational predictability.
I hope this has been helpful!
Laz
Hello Laz, thank you for the response!
Another thing that I am a little confused about is how all of these different networks behave in DMVPN specifically. Take a look at this
This is the broadcast network type. Why was the next-hop IP address value preserved? I originally thought the hub would change it to its own IP address, but it didnât.
However, this is not how this normally works. If I connect 3 routers together like this and advertise the 1.1.1.1/32 network.
R3 will see R2 as the next hop
But that didnât happen in this specific DMVPN scenario, the next-hop value remained the same.
Why does it work like this?
Thank you!
David
Hello David
Remember that there are many parameters when using DMVPN with OSPF. These include what Phase DMVPN is using, and what network type OSPF is using. The various combinations of these will give different results, and thatâs why Rene has shown every combination in his lessons.
For the broadcast OSPF network type and for all DMVPN Phases, the next hop IP address that appears in the OSPF routing entry of a network on another spoke is indeed the IP address of the remote spoke, and not that of the hub.
You can see this in all of the lessons where OSPF is used on all three phases of a DMVPN topology. This is simply the way that the broadcast OSPF network type operates on DMVPN topologies. By definintion, the broadcast network type means that any routers on the network segment should be able to have their next hop IP addresses appear in the routing table. DMVPN simulates this broadcast network type, so OSPF takes advantage of this.
This does not mean however that NHRP doesnât redirect this next hop IP address. As we know, regardless of what next hop appears in the OSPF table, NHRP is used to resolve the next hop address, something I wonât go into here.
Concerning your particular network you shared, it does indeed seem that R2 is the next hop in your OSPF table, however, I donât know what your DMVPN and OSPF network type configurations are so I canât help to troubleshoot that behavior. Can you confirm that youâve configured it correctly? Let us know how you get along so that we can help you further!
I hope this has been helpful!
Laz