@iores wrote:
But if hello packets are multicast, then the adjacency shoudn't come up in the first place? The device with ACL would deny those packets.
Could it be that device without ACL, send its hello packets first, and when neighboring device receive them, the communication turns to unicast. Then when adjacency comes up, the hello packets are sent to 224.0.0.5 again?
Honestly, don't know that level of detail off the top of my head.
The reason I even mentioned .6 (with a question mark), assuming .5 is fully blocked, some OSPF information has to be getting though for any adjacency attempts, or so I would think.
In the real world, I presume blocking a defined destination IP, or packet type, used by a routing protocol, isn't a "good thing". I don't worry about what may or may not work, I just want to insure, initially, nothing the protocol is expecting is blocked without good reason.
In other words, your question, to me, is only of "academic" interest. That doesn't mean you cannot pursue it, but what's the final benefit? Whatever you "discover" should then be checked against the OSPF RFCs, to see if the results make sense, right? Again, knowing exactly the impact of blocking one of OSPF's defined packet types, benefits us how? (Well, other than seeing the same issue again, and perhaps more quick identification of the cause. [Which is actually careless or ignorance of OSPF needs? I.e. how did such a configuration get applied?])
In my experience, there's enough other "real" OSPF issues that you can stub your toe on, without understanding all of OSPF operational workings without blocking one of its defined packet types.
Possibly the point I'm making isn't clear. I.e. knowing about 224.0.0.5 and 224.0.0.6 being used by OSPF is good, to avoid blocking either, but how worthwhile is it to know what will exactly happen if you block just one or the other?
Again, I don't mean to infer knowing such is in any way "bad" or even worthless, just that there's so much else to know about OSPF that can cause issues if you don't know specific OSPF design considerations.
Laugh, on these forums, someone presented an OSPF issue, which took me sometime to figure out, as it was a rather rare situation and OSPF changed its behavior between two RFCs. Interestingly, Cisco supports using the old RFC or the newer RFC handling, but also uses different defaults based on the Cisco equipment (I recall Catalyst defaults to the older RFC, and Nexus to the newer RFC, which makes for a mess if you mix the two families and have to deal with this rare usage situation.)
Again, the forgoing is likely uncommon, but also, I think, more worthwhile than spending time on a question like yours, is learning what Cisco has done to its OSPF implementation, to "improve it", yet not necessarily how other implementations do it. Or, things like, when Cisco introduced the OSPF iSPF feature, although I believe that now be eliminated, as Cisco believes it's no longer offers benefit, or . . .
