On 3/15/19 10:06 AM, Harald Jensås wrote:
Hi Miguel, Brian, and All,
Don't think there was any progress on this so I'd like to pick it up.
Hi Harald, Sorry, I seemed to have dropped the ball on this.
I tested this PoC patch, which adds a CT firewall rule to the namespace. And it seems to do the job. https://review.openstack.org/643570
Glad it worked for you. One reason I don't mind this approach is that inside the router namespace we aren't really running any services (except for maybe radvd or dibbler-client), so the hypervisor shouldn't be accessible even when a helper is loaded.
Not sure that adding these rules trough a global option is the right thing to do. Would it be better to implement this as an extension similar to how FIP port forwarding was done?
A new object?
{'conntrack_helper_rules': 'helpers': [ {'proto': '<protocol>', 'port': '<port>', 'helper': '<helper>'}, ], 'router_id': '<router_uuid>' }
An extension in `neutron/agent/l3/extensions` that adds the relevant firewall rules in the namespace. The conntrack_helper_rules would be a sub_resource_extension of `neutron_lib/api/definitions/l3.py`/'router'?has
That's a good suggestion, my only thought is it makes things more complicated to configure. Let me add it to the L3 subteam meeting agenda this week so we can spend some time talking about our options. Thanks, -Brian
wdyt?
Best Regards Harald
On Sun, 2019-01-13 at 12:11 -0600, Miguel Lavalle wrote:
Hi Derek,
Yes, these rules would need to be added inside the router namespace when it is created and it seems to me it is a workable solution. I will raise this work in the next L3 sub-team meeting, so we keep an eye on the patches / progress you make
Regards
Miguel
On Mon, Jan 7, 2019 at 11:54 AM Derek Higgins <derekh@redhat.com> wrote:
On Mon, 7 Jan 2019 at 17:08, Clark Boylan <cboylan@sapwetik.org> wrote:
On Mon, Jan 7, 2019, at 8:48 AM, Julia Kreger wrote:
Thanks for bringing this up Derek! Comments below.
On Mon, Jan 7, 2019 at 8:30 AM Derek Higgins <derekh@redhat.com wrote:
Hi All,
Shortly before the holidays CI jobs moved from xenial to
Ironic this meant a bunch failures[1], all have now been dealt with, with the exception of the UEFI job. It turns out that during
our (virtual) baremetal nodes use tftp to download a ipxe image. In order to track these tftp connections we have been making use of the fact that nf_conntrack_helper has been enabled by default. In newer kernel versions[2] this is no longer the case and I'm now
figure out the best way to deal with the new behaviour. I've
together some possible solutions along with some details on why they are not ideal and would appreciate some opinions
The git commit message suggests that users should explicitly
that the traffic is matched. I feel like the kernel change ends up being a behavior change in this case.
I think the reasonable path forward is to have a configuration parameter that the l3 agent can use to determine to set the netfilter connection
Doing so, allows us to raise this behavior change to operators
minimizing the
need of them having to troubleshoot it in production, and gives
bionic, for this job trying to put put in rules such tracker helper. them a choice
in the direction that they wish to take.
https://home.regit.org/netfilter-en/secure-use-of-helpers/ seems to cover this. Basically you should explicitly enable specific helpers when you need them rather than relying on the auto helper rules.
Thanks, I forgot to point out the option of adding these rules, If I understand it correctly they would need to be added inside the router namespace when neutron creates it, somebody from neutron might be able to indicate if this is a workable solution.
Maybe even avoid the configuration option entirely if ironic and
neutron can set the required helper for tftp when tftp is used?
[trim]
[more trimming]