routing – OSPF and its use of Multicast

[ad_1]

In terms of what happens to OSPF hello/discovery multicast packets, you’re right. The switches send them to everyone on the subnet/VLAN/broadcast domain, as IGMP snooping isn’t happening for 224.0.0.0/24, just as Ron explained.

However – and I believe that’s the part you didn’t consider – a host can still discard these multicast earlier than if they were broadcast. If the host isn’t interested in (any/this) multicast group(s), it can drop the ethernet frame (at L2) or the IPv4/IPv6 packet (at L3), without even looking at any inner payload. A broadcast packet however would have to be passed ‘further up the stack’ to see if it is of interest to any of the running applications/services/deamons.

To add to Ron’s list of OSPF’s network types/operating modes:

It’s good practice to run edge networks connected to OSPF routers with passive interfaces, especially where the OSPF network type is “broadcast” by nature. For example, this is the case in the proverbial “25 client VLANs” of a large campus, each with a few dozen of hosts each at least:

passive-interface

  • keeps the chatter in the campus LAN down
  • reduces exposure of routers to end systems (script-happy CompSci students, anyone?) – no Hellos nor LSAs are exchanged, neither in nor out.
  • saves some ressources on the routers (what with not having to perform the same DR/BDR election with the same peer in dozens of VLANs)
  • still allows the routing information about these networks to be propagated as internal routes to the rest of the OSPF AS. Having them as external routes (by virtue of “redistribute connected”) has some implications (desirable or unwanted), e.g. when aggregating, redistributing or filtering routes in other corners of the AS.

[ad_2]

Source link

Leave a Reply

Your email address will not be published. Required fields are marked *