L2 switching of OSPF multicast frames - TCP-IP
This is a discussion on L2 switching of OSPF multicast frames - TCP-IP ; Consider some OSPF routers and some servers attached to a
layer 2 switch (ethernet bridge). For simplicity sake, think of
a single LAN (i.e. no VLANs). Every OSPF router will periodically
send "hello" packets to 224.0.0.5.
Question: is the layer ...
-
L2 switching of OSPF multicast frames
Consider some OSPF routers and some servers attached to a
layer 2 switch (ethernet bridge). For simplicity sake, think of
a single LAN (i.e. no VLANs). Every OSPF router will periodically
send "hello" packets to 224.0.0.5.
Question: is the layer 2 switch able to forward that hello
frames only to the ports attached to OSPF routers?
Or will it always forward those OSPF frames to all ports?
Any pointers greatly appreciated!
Many thanks!
Everton
-
Re: L2 switching of OSPF multicast frames
"Everton" wrote:
> Consider some OSPF routers and some servers attached to a
> layer 2 switch (ethernet bridge). For simplicity sake, think of
> a single LAN (i.e. no VLANs). Every OSPF router will periodically
> send "hello" packets to 224.0.0.5.
>
> Question: is the layer 2 switch able to forward that hello
> frames only to the ports attached to OSPF routers?
> Or will it always forward those OSPF frames to all ports?
>
> Any pointers greatly appreciated!
The answer is in RFC 4541, the RFC that describes IGMP snooping.
Remember that membership in this 224.0.0.x range is NOT typically
joined. It is assumed, so there will be no IGMP packets of any kind for
these groups. And the packets remain within the IP subnet. They don't go
across routers.
-----Quoting from RFC 4541------
2.1.2. Data Forwarding Rules
2) Packets with a destination IP (DIP) address in the 224.0.0.X range
which are not IGMP must be forwarded on all ports.
This recommendation is based on the fact that many host systems do
not send Join IP multicast addresses in this range before sending
or listening to IP multicast packets. Furthermore, since the
224.0.0.X address range is defined as link-local (not to be
routed), it seems unnecessary to keep the state for each address
in this range. Additionally, some routers operate in the
224.0.0.X address range without issuing IGMP Joins, and these
applications would break if the switch were to prune them due to
not having seen a Join Group message from the router.
3) An unregistered packet is defined as an IPv4 multicast packet with
a destination address which does not match any of the groups
announced in earlier IGMP Membership Reports.
If a switch receives an unregistered packet, it must forward that
packet on all ports to which an IGMP router is attached. A switch
may default to forwarding unregistered packets on all ports.
Switches that do not forward unregistered packets to all ports
must include a configuration option to force the flooding of
unregistered packets on specified ports.
-------------------------------------
So, packets for 224.0.0.x groups must be flooded to all ports in the
spanning tree. On the other hand, packets for other groups than
224.0.0.x, which have had no IGMP queries or reports associated with
them, may be forwarded on only to router ports. Or may also be flooded
to all ports.
I would expect this behavior to be mimicked by any L2 multicast
protocol, such as GMRP, in the absence of some explicit mechanism to
signal joining of a multicast group at L2.
Bert