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 ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: L2 switching of OSPF multicast frames

  1. 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


  2. 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


+ Reply to Thread