yahoo-eng-team team mailing list archive

[OpenStack Infra <1889631@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.opendev.org/748719
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=b8be1a05facff2ba8b484902494ce1663e0aae7c
Submitter: Zuul
Branch:    master

commit b8be1a05facff2ba8b484902494ce1663e0aae7c
Author: Rodolfo Alonso Hernandez <ralonsoh@xxxxxxxxxx>
Date:   Tue Sep 1 16:55:01 2020 +0000

    Process ingress multicast traffic for 224.0.0.X separately
    
    By default, if any multicast traffic sent to 224.0.0.X is allowed
    in the OVS firewall (that means there is a specific egress rule),
    this traffic is sent, in table 73 (ACCEPT_OR_INGRESS_TABLE), to
    a rule with action NORMAL.
    
    As commented in the related bug, https://tools.ietf.org/html/rfc4541,
    chapter 2.1.2, section (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."
    
    That means those packets will be forwarded to all ports regardless of
    any ingress rule. This patch process this traffic separately, sending
    those packets to table 102 (MCAST_RULES_INGRESS_TABLE). In this table
    the ingress rules that have a defined protocol, will have an Open Flow
    rule to output the traffic directly to those ports associated to this
    rule.
    
    For example, in the problem reported in the related bug, the VRRP
    protocol (112), will be sent only to those ports that have this
    ingress rule.
    
    Change-Id: Ie271de144f78e364d938731ec9f5297e1a9d73f9
    Closes-Bug: #1889631


** Changed in: neutron
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1889631

Title:
  [OVS][FW] Multicast non-IGMP traffic is allowed by default, not in
  iptables FW

Status in neutron:
  Fix Released

Bug description:
  In iptables firewall, the multicast traffic (non-IGMP) fro 224.0.0.X
  traffic was blocked. For example, VRRP traffic
  (https://en.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol) was
  blocked until a rule was added to allow it.

  In OVS native firewall implementation, this traffic is allowed by default because:
  - The OVS FW does not block it.
  - OVS follows the recommendations provided in https://tools.ietf.org/html/rfc4541, chapter 2.1.2, section (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."

  That means this traffic, belonging to a link-local IP address, in the
  range 224.0.0.x, should be always forwarded to all ports.

  
  Deployments migrating from iptables FW to OVS FW won't have this traffic blocked by default; this is a behavior change between both.

  Should we implicitly block this traffic when using OVS FW?

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1889631/+subscriptions