Comment 14 for bug 1844712

Revision history for this message
Clark Boylan (cboylan) wrote :

FWIW I agree with fungi and am curious to know if Neutron has anything ready to address this (another case would be rogue dhcp servers as well).

But to help aid in understanding what is going on here I'll try to answer the previous questions.

1. I think that is the assumption (though it may be more than just tobiko testing). Basically test jobs run, those jobs then result in RAs being sent from the test node to other nodes on the network.

2. We have observed it on limestone because it broke the mirror nodes ability to fetch external resources there. This can happen there because limestone's two tenants share a single flat network. This may happen on other clouds but network topology limits the destructiveness it can cause or prevents it entirely.

For example on the fortnebula cloud the mirror and test nodes are on different networks. In this case it would be only the other test nodes that end up with trashed networking. This may cause jobs to fail oddly (in fact we have seen octavia jobs fail there with broken DNS).

In OVH every host is on a /32 for ipv4 and while we don't configure ipv6 there I can only assume they do a similar /128 and force all traffic through their routers.

On rackspace networking is shared but you are assigned a network out of pools of networks AIUI. So this comes down to luck of the draw.

Finally I will point out that if we break ipv6 routing on a node with ipv4 networking too that the host should fall back to ipv4. This may slow down jobs but they will function. Thus we likely only really see the true impact of this when on ipv6 only clouds like limestone and fortnebula.

To go back to Jeremy's point I think it would be useful to know if neutron is expected to prevent this from happening (as it does with arp spoofing). If it does then we should probably communicate that more effectively and maybe even configure this by default? I know neutron refuses to have more open security group rules as part of its secure by default policy. I would expect that to apply here too.

If neutron doesn't do this today, then should it?