[ironic][neutron] nf_conntrack_helper now disabled by default
Hi All,
Shortly before the holidays CI jobs moved from xenial to bionic, for 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 this job 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 trying to figure out the best way to deal with the new behaviour. I've put together some possible solutions along with some details on why they are not ideal and would appreciate some opinions
1. Why not enable the conntrack helper with echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper
The router namespace is still created with nf_conntrack_helper==0 as it follows the default the nf_conntrack module was loaded with
2. Enable it in modprobe.d # cat /etc/modprobe.d/conntrack.conf options nf_conntrack nf_conntrack_helper=1
This works but requires the nf_conntrack module to be unloaded if it has already been loaded, for devstack and I guess in the majority of cases (including CI nodes) this means a reboot stage or a potentially error prone sequence of stopping the firewall and unloading nf_conntrack modules.
This also globally turns on the helper on the host reintroducing the security concerns it comes with
3. Enable the contrack helper in the router network namespace when it is created[3] This works for ironic CI, but there may be better solutions that can be worked within neutron that I'm not aware of. Of the 3 options above this would be most transparent to other operators as the original behaviour would be maintained.
thoughts on any of the above? or better solutions?
1 - https://storyboard.openstack.org/#!/story/2004604 2 - https://kernel.googlesource.com/pub/scm/linux/kernel/git/horms/ipvs-next/+/3... 3 - https://review.openstack.org/#/c/628493/1
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 bionic, for 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 this job 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 trying to figure out the best way to deal with the new behaviour. I've put 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 put in rules such 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 tracker helper.
Doing so, allows us to raise this behavior change to operators minimizing the need of them having to troubleshoot it in production, and gives them a choice in the direction that they wish to take.
[trim]
- Enable the contrack helper in the router network namespace when it
is created[3] This works for ironic CI, but there may be better solutions that can be worked within neutron that I'm not aware of. Of the 3 options above this would be most transparent to other operators as the original behaviour would be maintained.
My thoughts exactly.
thoughts on any of the above? or better solutions?
I think we should just raise it as a configuration option. Coupled with a release note, provides operators visibility to the kernel change.
1 - https://storyboard.openstack.org/#!/story/2004604 2 - https://kernel.googlesource.com/pub/scm/linux/kernel/git/horms/ipvs-next/+/3... 3 - https://review.openstack.org/#/c/628493/1
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 bionic, for 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 this job 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 trying to figure out the best way to deal with the new behaviour. I've put 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 put in rules such 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 tracker helper.
Doing so, allows us to raise this behavior change to operators minimizing the need of them having to troubleshoot it in production, and gives 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.
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]
On Mon, Jan 7, 2019 at 9:11 AM Clark Boylan cboylan@sapwetik.org wrote:
On Mon, Jan 7, 2019, at 8:48 AM, Julia Kreger wrote:
[trim]
Doing so, allows us to raise this behavior change to operators minimizing the need of them having to troubleshoot it in production, and gives 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.
Maybe even avoid the configuration option entirely if ironic and neutron can set the required helper for tftp when tftp is used?
Great link Clark, thanks!
It could be viable to ask operators to explicitly set their security groups for tftp to be passed.
I guess we actually have multiple cases where there are issues and the only non-impacted case is when the ironic conductor host is directly attached to the flat network the machine is booting from. In the case of a flat network, it doesn't seem viable for us to change rules ad-hoc since we would need to be able to signal that the helper is needed, but it does seem viable to say "make sure connectivity works x way". Where as with multitenant networking, we use dedicated networks, so conceivably it is just a static security group setting that an operator can keep in place. Explicit static rules like that seem less secure to me without conntrack helpers. :(
Does anyone in Neutron land have any thoughts?
[trim]
[more trimming]
On 1/7/19 12:42 PM, Julia Kreger wrote:
On Mon, Jan 7, 2019 at 9:11 AM Clark Boylan cboylan@sapwetik.org wrote:
On Mon, Jan 7, 2019, at 8:48 AM, Julia Kreger wrote:
[trim]
Doing so, allows us to raise this behavior change to operators minimizing the need of them having to troubleshoot it in production, and gives 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.
Maybe even avoid the configuration option entirely if ironic and neutron can set the required helper for tftp when tftp is used?
Great link Clark, thanks!
It could be viable to ask operators to explicitly set their security groups for tftp to be passed.
I guess we actually have multiple cases where there are issues and the only non-impacted case is when the ironic conductor host is directly attached to the flat network the machine is booting from. In the case of a flat network, it doesn't seem viable for us to change rules ad-hoc since we would need to be able to signal that the helper is needed, but it does seem viable to say "make sure connectivity works x way". Where as with multitenant networking, we use dedicated networks, so conceivably it is just a static security group setting that an operator can keep in place. Explicit static rules like that seem less secure to me without conntrack helpers. :(
Does anyone in Neutron land have any thoughts?
I am from Neutron land, sorry for the slow reply.
First, I'm trying to get in contact with someone that knows more about nf_conntrack_helper than me, I'll follow-up here or in the patch.
In neutron, as in most projects, the goal is to have things configured so admins don't need to set any extra options, so we've typically done things like set sysctl values to make sure we don't get tripped-up by such issues. Mostly these settings have been in the L3 code, so are done in namespaces and have limited "impact" on the system hypervisor on the compute node.
Since this is security group related it is different, since that isn't done in a namespace - we add a rule for related/established connections in the "root" namespace, for example in the iptables_hybrid case. For that reason it's not obvious to me that setting this sysctl is bad - it's not in the VM itself, and the packets aren't going to the hypervisor, so is there any impact we need to worry about besides just having it loaded?
The other option would be to add more rules when SG rules are added that are associated with a protocol that has a helper. IMO that's not a great solution as there is no way for the user to control what filters (like IP addresses) are allowed, for example a SIP helper IP address.
Hopefully I'm understanding things correctly.
Thanks,
-Brian
On Mon, 14 Jan 2019 at 16:47, Brian Haley haleyb.dev@gmail.com wrote:
On 1/7/19 12:42 PM, Julia Kreger wrote:
On Mon, Jan 7, 2019 at 9:11 AM Clark Boylan cboylan@sapwetik.org wrote:
On Mon, Jan 7, 2019, at 8:48 AM, Julia Kreger wrote:
[trim]
Doing so, allows us to raise this behavior change to operators minimizing the need of them having to troubleshoot it in production, and gives 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.
Maybe even avoid the configuration option entirely if ironic and neutron can set the required helper for tftp when tftp is used?
Great link Clark, thanks!
It could be viable to ask operators to explicitly set their security groups for tftp to be passed.
I guess we actually have multiple cases where there are issues and the only non-impacted case is when the ironic conductor host is directly attached to the flat network the machine is booting from. In the case of a flat network, it doesn't seem viable for us to change rules ad-hoc since we would need to be able to signal that the helper is needed, but it does seem viable to say "make sure connectivity works x way". Where as with multitenant networking, we use dedicated networks, so conceivably it is just a static security group setting that an operator can keep in place. Explicit static rules like that seem less secure to me without conntrack helpers. :(
Does anyone in Neutron land have any thoughts?
I am from Neutron land, sorry for the slow reply.
First, I'm trying to get in contact with someone that knows more about nf_conntrack_helper than me, I'll follow-up here or in the patch.
Great, thanks
In neutron, as in most projects, the goal is to have things configured so admins don't need to set any extra options, so we've typically done things like set sysctl values to make sure we don't get tripped-up by such issues. Mostly these settings have been in the L3 code, so are done in namespaces and have limited "impact" on the system hypervisor on the compute node.
Since this is security group related it is different, since that isn't done in a namespace - we add a rule for related/established connections in the "root" namespace, for example in the iptables_hybrid case. For that reason it's not obvious to me that setting this sysctl is bad - it's not in the VM itself, and the packets aren't going to the hypervisor, so is there any impact we need to worry about besides just having it loaded?
As far as I've been able to figure out we'd need to have the kernel module loaded, one per protocol supported e.g. nf_conntrack_tftp, nf_conntrack_sip etc...
and set the sysctl inside the namespace,
my testing was on devstack where the node being deployed with ironic was on the same host, It may be that the sysctl is also needed in the root namespace in a more realistic scenario where ironic is controlling real baremetal nodes, I'll see if I can find out if this is the case.
The other option would be to add more rules when SG rules are added that are associated with a protocol that has a helper. IMO that's not a great solution as there is no way for the user to control what filters (like IP addresses) are allowed, for example a SIP helper IP address.
Ya, it doesn't sound ideal, also this would require specific SG rules to enable outgoing traffic which isn't normally the case
Hopefully I'm understanding things correctly.
Thanks,
-Brian
On Thu, 17 Jan 2019 at 17:45, Derek Higgins derekh@redhat.com wrote:
On Mon, 14 Jan 2019 at 16:47, Brian Haley haleyb.dev@gmail.com wrote:
On 1/7/19 12:42 PM, Julia Kreger wrote:
On Mon, Jan 7, 2019 at 9:11 AM Clark Boylan cboylan@sapwetik.org wrote:
On Mon, Jan 7, 2019, at 8:48 AM, Julia Kreger wrote:
[trim]
Doing so, allows us to raise this behavior change to operators minimizing the need of them having to troubleshoot it in production, and gives 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.
Maybe even avoid the configuration option entirely if ironic and neutron can set the required helper for tftp when tftp is used?
Great link Clark, thanks!
It could be viable to ask operators to explicitly set their security groups for tftp to be passed.
I guess we actually have multiple cases where there are issues and the only non-impacted case is when the ironic conductor host is directly attached to the flat network the machine is booting from. In the case of a flat network, it doesn't seem viable for us to change rules ad-hoc since we would need to be able to signal that the helper is needed, but it does seem viable to say "make sure connectivity works x way". Where as with multitenant networking, we use dedicated networks, so conceivably it is just a static security group setting that an operator can keep in place. Explicit static rules like that seem less secure to me without conntrack helpers. :(
Does anyone in Neutron land have any thoughts?
I am from Neutron land, sorry for the slow reply.
First, I'm trying to get in contact with someone that knows more about nf_conntrack_helper than me, I'll follow-up here or in the patch.
Great, thanks
In neutron, as in most projects, the goal is to have things configured so admins don't need to set any extra options, so we've typically done things like set sysctl values to make sure we don't get tripped-up by such issues. Mostly these settings have been in the L3 code, so are done in namespaces and have limited "impact" on the system hypervisor on the compute node.
Since this is security group related it is different, since that isn't done in a namespace - we add a rule for related/established connections in the "root" namespace, for example in the iptables_hybrid case. For that reason it's not obvious to me that setting this sysctl is bad - it's not in the VM itself, and the packets aren't going to the hypervisor, so is there any impact we need to worry about besides just having it loaded?
As far as I've been able to figure out we'd need to have the kernel module loaded, one per protocol supported e.g. nf_conntrack_tftp, nf_conntrack_sip etc...
Looks like we also need "nf_nat_tftp"
I'm also confused, we don't have any iptables rules inside the namespace matching any connections with --ctstate RELATED so is this just a nat issues, where the helpers are needed for nat to work and iptables isn't blocking anything?
if thats the case maybe we just set the sysctl as per patch and document that the appropriate kernel modules should be loaded
and set the sysctl inside the namespace,
my testing was on devstack where the node being deployed with ironic was on the same host, It may be that the sysctl is also needed in the root namespace in a more realistic scenario where ironic is controlling real baremetal nodes, I'll see if I can find out if this is the case.
I've set up a more realistic env and there were no additional requirements
The other option would be to add more rules when SG rules are added that are associated with a protocol that has a helper. IMO that's not a great solution as there is no way for the user to control what filters (like IP addresses) are allowed, for example a SIP helper IP address.
Ya, it doesn't sound ideal, also this would require specific SG rules to enable outgoing traffic which isn't normally the case
Hopefully I'm understanding things correctly.
Thanks,
-Brian
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 bionic, for 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 this job 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 trying to figure out the best way to deal with the new behaviour. I've put 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 put in rules such 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 tracker helper.
Doing so, allows us to raise this behavior change to operators minimizing the need of them having to troubleshoot it in production, and gives 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]
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 bionic, for 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 this job 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 trying to figure out the best way to deal with the new behaviour. I've put 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 put in
rules such
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 tracker
helper.
Doing so, allows us to raise this behavior change to operators
minimizing the
need of them having to troubleshoot it in production, and gives 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]
Hi Miguel, Brian, and All,
Don't think there was any progress on this so I'd like to pick it up.
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
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'?
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
bionic, for
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
this job
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
trying to
figure out the best way to deal with the new behaviour. I've
put
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
put in rules such
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
tracker helper.
Doing so, allows us to raise this behavior change to operators
minimizing the
need of them having to troubleshoot it in production, and gives
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]
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
bionic, for
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
this job
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
trying to
figure out the best way to deal with the new behaviour. I've
put
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
put in rules such
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
tracker helper.
Doing so, allows us to raise this behavior change to operators
minimizing the
need of them having to troubleshoot it in production, and gives
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]
participants (6)
-
Brian Haley
-
Clark Boylan
-
Derek Higgins
-
Harald Jensås
-
Julia Kreger
-
Miguel Lavalle