Port IP address removed from address set when duplicate exists

Bug #1611836 reported by Richard Theis
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
networking-ovn
Won't Fix
Medium
Unassigned

Bug Description

Neutron can be configured to allow overlapping IP addresses (see the allow_overlapping_ips configuration option). This is the default in DevStack. With overlapping IP addresses (as the example shows below), OVN address sets do not store duplicate addresses. As a result, deleting a port with a duplicate IP address on the same security group will result in networking-ovn removing the overlapping IP address from the security group's address set even though another port is using the IP address.

Recreate Steps:

$ openstack network create network1
$ openstack network create network2
$ openstack subnet create --subnet-range 10.1.0.0/24 --network network1 subnet1
$ openstack subnet create --subnet-range 10.1.0.0/24 --network network2 subnet2
$ openstack port create --network network1 --fixed-ip ip-address=10.1.0.10 port1
$ openstack port create --network network2 --fixed-ip ip-address=10.1.0.10 port2

$ ovn-nbctl show
    switch 58c1eaa8-96b3-47f5-93b1-b7c568811e3c (neutron-56a3c2a7-f70f-4614-93de-1399a81defdb)
        port 37cef443-4a2d-4670-8abd-05fc7d97cba0
            addresses: ["fa:16:3e:b2:7e:c1 10.1.0.10"]
    switch acd899f1-6846-4f58-ae7c-aa72f765ea02 (neutron-95bad130-4b0c-4aa2-b11f-e1cfeb1ec62b)
        port 605cf49a-3d65-49b1-bb0f-7ba72ffc0b7a
            addresses: ["fa:16:3e:8c:0e:a1 10.1.0.10"]

...

$ ovn-nbctl list address_set
_uuid : 9e09ff9e-9bc7-49dc-8837-71808182a403
addresses : ["10.1.0.10"]
external_ids : {"neutron:security_group_name"=default}
name : "as_ip4_a420da8b_ea8b_46d4_891e_5441a87a261d"

...

$ openstack port delete port2

$ ovn-nbctl list address_set

_uuid : 9e09ff9e-9bc7-49dc-8837-71808182a403
addresses : []
external_ids : {"neutron:security_group_name"=default}
name : "as_ip4_a420da8b_ea8b_46d4_891e_5441a87a261d"

...

$ ovn-nbctl show
    switch 58c1eaa8-96b3-47f5-93b1-b7c568811e3c (neutron-56a3c2a7-f70f-4614-93de-1399a81defdb)
        port 37cef443-4a2d-4670-8abd-05fc7d97cba0
            addresses: ["fa:16:3e:b2:7e:c1 10.1.0.10"]

...

Richard Theis (rtheis)
Changed in networking-ovn:
status: New → Confirmed
description: updated
summary: - Port IP address removed from address set when duplicate exist
+ Port IP address removed from address set when duplicate exists
Revision history for this message
Richard Theis (rtheis) wrote :

Fixing this bug should take into consideration https://bugs.launchpad.net/networking-ovn/+bug/1611852.

Revision history for this message
Han Zhou (zhouhan) wrote :

Richard, thanks for reporting. This sounds interesting. To solve the problem, I wonder we firstly need to clarify the requirement from neutron model point of view.

In neutron model, ports can have overlapping IPs (they belongs to different networks and they don't talk to each other, so that's fine). But when they are attached to same security group, it is tricky.

It is valid use case saying that those ports just share same security rules, as long as there is no reference of the security group as "remote group".

Otherwise, if the shared security group is referred as a "remote group" in a security rule of some security group (that some security group could be the same group or a different group, which doesn't matter), I wonder what's the real intent of the rule. For example, the rule says allow any ipv4 packets from a security group. Now we have 2 ports with same IP address, one in the group, the other not. Shall we allow the packet from that IP address? In general, a security group implementation can't distinguish source ports if they have same IP address. This sounds like a conflicting requirement.

Revision history for this message
Richard Theis (rtheis) wrote :

Han, I agree that we need to sort out the use case first to determine what, if anything, needs to be fixed. At a minimum, I think we'll need a note in the code to document this behavior.

Revision history for this message
ZongKai LI (zongkai) wrote :

I think neither OVN nor Neutron is ready to allow overlapping_ips subnets to attach onto the same router, so we will not meet a case two ports P1 and P2 with the same IP are both reachable to port P3, while P1 and P3 are in the same SG, but not P2.

It seems we have two cases to handle (only consider Neutron basic default security group rules case):
[1] port P4 is reachable to P5, they are in them SG which has rule using the SG itself as remote group, and P4 IP address is missing for that. So the expected behavior P4 can communicate with P5 may not appear, since no SG rule allow to.
[2] port P6 is reachable to P7, only P6 is in SG which has rule using the SG itself as remote group, and P7 IP address is in address set used by SG remote group. So the expected behavior P7 can not communicate with P6 may not appear, since "wrong" address is recorded in Address_Set.

My first thought is to align to general security group implementation, not to distinguish which one of ports using the same IP is in group. This will be a simple fix.
My second thought is to split current address set per subnets connectivity. This will make sure IP in address set wouldn't mis up. Its implementation may need to maintain mapping between connected subnets to address set. Not sure is this expansive to do.

Changed in networking-ovn:
importance: Undecided → Medium
Revision history for this message
Lucas Alvares Gomes (lucasagomes) wrote :

networking-ovn no longer rely on address sets after the port groups feature was introduced. Marking it as WONTFIX

Changed in networking-ovn:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.