Question regarding OSPF neighbor and address

[leo123]

 

Hi, I've been learning about OSPF and have couple of questions regarding those:

I learned about how routers establish neighbors in the same network, but one thing that confuse me is that when I tried it in EVE-NG, with 3 routers connected to the same switch, R1 is the DR, and when i turned on the R2 and R3, they would send hello packets to 224.0.0.5, and after R1 received that, it would send hello packets back to them by unicast, but I've never seen R2 and R3 sending unicast hello packets to each other, only to R1, I'm wondering if there's something wrong with it cuz as far as I know, the routers should all be sending packets to each other to become neighbors even when they're DROTHER routers.

My second question is, from what I understand, the DROTHER routers should be sending LSR/LSU/LSACK to 224.0.0.6 for DR/BDRs to listen, and DR/BDRs should be sending these to 224.0.0.5, which would be all the OSPF routers in the same network segment, but what I've seen in the EVE-NG is that, only LSACK is sent to 224.0.0.6, LSUPDATE and LSR sent by the DROTHER routers are still sent to 224.0.0.5 as the pic below(10.1.1.2 is the DROTHER router)

[M02@rt37 · Accepted solution]

Hello @leo123 

First, in a broadcast network, OSPF routers send Hello packets to the multicast address 224.0.0.5 to discover and establish neighbor relationships. Once the DR/BDR election is complete, all DROTHER routers form full OSPF adjacencies only with the DR and BDR, but not directly with each other. This is expected behavior because DROTHER routers rely on the DR/BDR to distribute LSAs, reducing the number of adjacencies and overall network overhead.

In your case, when R2 and R3 (both DROTHERs) came online, they sent Hello packets to 224.0.0.5, which were processed by R1 (the DR). R1 then responded with unicast Hello packets to R2 and R3 to establish neighbor relationships. However, R2 and R3 never exchange unicast Hello packets directly because they do not form a full adjacency with each other—only with the DR and BDR. Instead, their OSPF state remains at 2-Way with each other, meaning they recognize each other as neigbors but do not exchange LSAs directly. 

-> Check the OSPF neighbor state on R2 and R3 using the command:

#show ip ospf neighbor

You should see R1 (DR) in Full state, while R2 and R3 see each other in 2-Way state.

As concerned your second question, in OSPF, the communication flow for LSR, LSU, and LSACK packets depends on the router's role.

• DROTHER to DR/BDR: Normally, DROTHER routers send LSR and LSU to 224.0.0.6 (All DR Routers) since only DR/BDR should process and forward them.
• DR/BDR to All Routers: The DR and BDR then multicast LSUs to 224.0.0.5 (All OSPF Routers) so every router gets the update.
• LSACK Behavior: Acknowledgment packets (LSACK) are often sent to the unicast address of the originator, but sometimes multicast to 224.0.0.6.

So, I'm gonna check on my EVE-NG if I have your beahvior too...

[leo123]

Thanks a lot for such a detailed explanation! However there are still a bit I don't quite understand, could you check my understanding below and let me know if there are any mistakes?

I understand that first when a router initializes the OSPF, they would try sending hello packets to 224.0.0.5 first, and after that when a router received the hello packet from another, they would send unicast hello packet back and eventually build neighbor with the ospf routers that are also in the network segment, and their status would go from down to 2 way, and in a broadcast network, they would stay in 2 way for 40 sec by default and go into exstart and finally to FULL, which means that they're now adjacent, and all the routers in the same network segment would only be adjacent with the DR and BDR, they would stay in 2 way with other DROTHER routers. However, from what I understand, I'd think that the DROTHER routers are still neighbors(not adjacent), and doesn't neighbors send hello packets to let each other know they're alive? Or is it different when a network already exists a DR? I thought that they would be adjacent to the DR but still be neighbor with the DROTHERs, and it would exchange LSAs with the DR but still exchange hello packets directly to DROTHER routers. 

Here's an example:

At the start all the routers would send hello to 224.0.0.5, and when they received the packets, they would exchange hello packets by multicast like R1 1.1.1.1 to R2 2.2.2.2, and vice versa so R1 and R2 becomes 2 way. And if the DR has already been elected, and I add another R5 5.5.5.5 to the switch, it would send hello to 224.0.0.5, and all the routers in the network could receive that, but won't the DROTHERs send hello back to R5 when they received the hello packets from R5? Or if it's enough for R5 to just exchange hello packets with the DR(R4) and would have all the neighbor information so it would consider the DROTHERs neighbors? If so, can I conclude that the neighbor relationship between one DROTHER to another DROTHER is maintained all by the DR instead of exchanging hello packets themselves?

I'm sorry if I made it look messy and hard to understand what I'm asking and thanks in advance!

[M02@rt37 · Accepted solution]

Thanks for the update @leo123 

When a router initializes OSPF, it sends Hello packets to 224.0.0.5... All routers in the segment receive these packets, and if they meet OSPF neighbor conditions (same area, authentication, timers, etc...), they will acknowledge each other as neighbors. At this stage, routers transition from Down to 2-Way state. In a broadcast network, the routers then elect a DR and BDR to reduce unnecessary LSA flooding. Once a DR/BDR is elected, DROTHER routers (non-DR, non-BDR) only form adjacencies with the DR and BDR. They remain in the 2-Way state with other DROTHER, meaning they recognize each other as neighbors but do not establish a full adjacency.

Regarding Hello packets now, OSPF Hello messages continue to be exchanged between all routers in the segment, including DROTHERs. The purpose of Hello packets is to maintain neighbor relationships and detect failures. Even though DROTHERs do not form a full adjacency with each other, they still exchange Hello packets directly to maintain neighbor status. However, LSA are only exchanged between adjacent routers, meaning DROTHER send LSA to the DR/BDR, which then flood them to the rest of the network.

In your exampe, if you add R5 to the switch, it will send a hello packet to 224.0.0.5. All existing routers (R1, R2, R3, R4) will receive it, and if they meet neighbor conditions, they will acknowledge R5 as a neighbor. The DR (R4) and BDR will go through the full adjacency process with R5, while the other DROTHER will remain in the 2-Way state with it. However, DROTHER still exchange Hello packets with each other to maintain the neighbor relationship, even though they don’t become fully adjacent. The DR is responsible for LSA flooding, but it does not "maintain" the neighbor relationships between DROTHERs—each DROTHER keeps track of its own neighbors through periodic Hello packets.

So, DROTHER do exchange Hello packets with each other, but they only form full adjacencies with the DR/BDR. The DR is responsible for relaying LSA, but neighbor relationships are maintained directly between routers using Hello packets, not through the DR.

[leo123]

Thanks for the explanation! I think I may had a misunderstanding about the purpose of hello packets which gave me this confusion, I thought hello packets are only used to form and maintain neighbor and do not have anything to do with forming a adjacent state, I thought that would only be the DBD, LSR,LSUs which does that. 

I'll go back to the books again to review that session and thank you so much for answering!

[Joshqun Ismayilov]

For the first question, there is no issue here.


For second question - DROTHER routers should send LSU/LSR packets to 224.0.0.6 (the DR/BDR multicast address), and the DR/BDR should forward updates to 224.0.0.5 (all OSPF routers). However, in your capture:

The DROTHER (10.1.1.2) sends LSU directly to 224.0.0.5 (packet 619), which violates OSPF rules. This behavior occurs if the OSPF network type is misconfigured. 

If the interface is set to point-to-multipoint instead of broadcast, routers will use 224.0.0.5 for all communications.

Thank!

[leo123]

Thanks for answering! I've checked my config but it seems I did not change the type to P2P or P2MP, I'm thinking maybe it's because of the EVE-NG, I'll try doing that again and see if i get a different result, but still thanks confirming on the theories.

[vishalbhandari · Accepted solution]

@leo123 Your observations are correct, and there's no issue with what you're seeing in EVE-NG.

1. Unicast Hello Packets Between DROTHERs: In an OSPF broadcast network, DROTHER routers (R2 and R3 in your case) only form full adjacencies with the DR and BDR, not with each other. They exchange Hello packets with the DR/BDR but do not send unicast Hellos to each other because they don’t form full neighbor relationships—only a two-way state. This behavior is expected and aligns with OSPF's design to reduce unnecessary adjacencies in broadcast networks.

2. Multicast Usage in LSA Exchange: Normally, DROTHER routers should send LS Request (LSR), LS Update (LSU), and LS Acknowledge (LSACK) to 224.0.0.6, which is listened to by the DR and BDR. However, in your packet capture, the LSU and LSR from the DROTHER router (10.1.1.2) are being sent to 224.0.0.5. This could be due to how EVE-NG processes OSPF packets, or it might be a specific behavior in your OSPF implementation (depending on the router's vendor or IOS version). Some OSPF implementations allow LSU and LSR to be sent to 224.0.0.5 under certain conditions, such as retransmissions or topology changes.

Overall, your setup is working as expected, but the multicast behavior of LSR/LSU might be a platform-specific variation. You could try debugging OSPF adjacency and packet processing on the routers to confirm further.

[leo123]

Thanks for your answer, I think I understand how it works now, and the unexpected results in the LSA Exchange is probably with EVE-NG, I'll go test again somtime.

Thank you!