On 03/24/2017 06:41 AM, Ghanshyam Mann wrote:
Hi All,

Tempest is testing SG rule creation and pinging scenario tests with
ethertype='IPv6' and protocol='icmp' [0].
In case of ethertype='IPv6', currently neutron accept protocol type
as 'icmp', 'icmpv6' and 'ipv6-icmp' which again seems like duplication
of SG rules bug on neutron side but not sure [1]

But it seems like some driver does not work with 'icmp' on IPv6, at
least ODL as mentioned in bug [2]. Where few others like ML2/OVS
iptables driver convert 'icmp' to 'icmpv6' when ethertype='IPv6' and had
no issue with 'icmp'.

IMO neutron should keep accepting 'icmp' for IPv6 for backward
compatibility and legacy usage and tempest should test 'icmp' also along
with other protocol type.
But we need more feedback on that what is right way (as per backward
compatibility pov) and recommended way for having best behaviour for SG
rules on IPv6. What best can work for all plugins also?

Thanks for raising this issue. Let me just restate it a little so it's clear.

1. One can create an IPv6 rule using protocol value "icmp" today, and the base security group code does the right thing changing the rule to be correct for the underlying implementation, for example, "ipv6-icmp" for iptables. It doesn't look like all other drivers handle this properly.

2. The neutron API will accept multiple values - "icmp", "ipv6-icmp" and "icmpv6" for an IPv6 rule, but it will create unique database entries for each (I just verified that). While that shouldn't create multiple entries in the base iptables code, it will probably generate a warning in the logs about a duplicate being suppressed.


So there are a few things that could be done:

1. Drivers need to accept "icmp" in order to be backwards-compatible with the current code.

2. Duplicates should be detected and generate 409 (?) errors.

3. We should add a migration (IMO) where any duplicates are squashed.

The open question is, do we want to change the DB to have a different value here, like "icmpv6" ? We could obviously add a migration where we update the value. The problem is that flag day could pose a problem if out-of-tree drivers don't support the new value. I think we should leave it "icmp" for that reason, thoughts from others?

-Brian

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to