Open Stack

Hi Slawek:

I agree with Akihiro and you:
- This should be fixed to match both FW behaviour, but only in master.
- Of course, a "big" release note to make this public.
- Not to add a knob that changes the API behaviour.

I'll wait for more feedback. Although I'll be on PTO, I'll check and reply
to the mail.

Thank you and regards.


On Fri, Aug 7, 2020 at 11:19 AM Slawek Kaplonski <skaplons at redhat.com>
wrote:

> Hi,
>
> > On 4 Aug 2020, at 19:05, Rodolfo Alonso Hernandez <ralonsoh at redhat.com>
> wrote:
> >
> > Hello all:
> >
> > First of all, the link: https://bugs.launchpad.net/neutron/+bug/1889631
> >
> > To sum up the bug: in iptables FW, the non-IGMP multicast traffic from
> 224.0.0.x was blocked; this is not happening in OVS FW.
> >
> > That was discussed today in the Neutron meeting today [1]. We face two
> possible situations here:
> > - If we block this traffic now, some deployments using the OVS FW will
> experience an unexpected network blockage.
>
> I would be for this option but left stable branches not touched.
> Additionally we should of course add release note with info that this
> behaviour changed now and also we can add upgrade check which will write
> warning about that if any of the agents in the DB is using “openvswitch”
> firewall driver.
> I don’t think we can do anything more to warn users about such change.
>
> > - Deployments migrating from iptables to OVS FW, now won't be able to
> explicitly allow this traffic (or block it by default). This also breaks
> the current API, because some rules won't have any effect (those ones
> allowing this traffic).
>
> This is current issue, right? If we would fix it as You proposed above,
> then behaviour between both drivers would be the same. Am I understanding
> correct?
>
> >
> > A possible solution is to add a new knob in the FW configuration; this
> config option will allow to block or not this traffic by default. Remember
> that the FW can only create permissive rules, not blocking ones.
>
> I don’t like to add yet another config knob for that. And also as I think
> Akihiro mentioned it’s not good practice to change API behaviour depending
> on config options. This wouldn’t be discoverable in API.
>
> >
> > Any feedback is welcome!
> >
> > Regards.
> >
> > [1]
> http://eavesdrop.openstack.org/meetings/networking/2020/networking.2020-08-04-14.00.log.html#l-136
> >
> >
>
> —
> Slawek Kaplonski
> Principal software engineer
> Red Hat
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200807/1de68647/attachment.html>