Group Based Policy

subnet mapping broken with overlapping ips

Bug #1383947 reported by Ivar Lazzaro
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Group Based Policy
Triaged
High
Robert Kukura
Group Based Policy next

Bug Description

This is reproducible when overlapping IPs are enabled in Neutron.

Whenever a new EPG is created, all the subnets previously assigned to all the other EPGs on that L3_Policy plus a new one are associated with it:

l2p_web
epg_web 172.16.0.0/26

l2p_client-1
epg_client-1 172.16.0.0/26
epg_client-1 172.16.0.64/26

l2p_client-2
epg_client-2 172.16.0.0/26
epg_client-2 172.16.0.64/26
epg_client-2 172.16.0.128/26

Looking at the current implementation, this happens because the subnet creation is not refused, and attaching the router interface to any associated subnet fails with a BadRequest exception (2 interfaces in overlapping subnets are not allowed).

This causes the implicit subnet loop to repeat itself again, until a brand new subnet is associated with the EPG (that's why the more EPGs are created the more subnets are associated with them).

Ivar Lazzaro (mmaleckk)
Changed in group-based-policy:
importance: Undecided → Critical
importance: Critical → High
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to group-based-policy (master)

Fix proposed to branch: master
Review: https://review.openstack.org/132319

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to group-based-policy (master)

Reviewed: https://review.openstack.org/132319
Committed: https://git.openstack.org/cgit/stackforge/group-based-policy/commit/?id=bba2a768ab3620506697f7d089f777ab9113dbe0
Submitter: Jenkins
Branch: master

commit bba2a768ab3620506697f7d089f777ab9113dbe0
Author: Ivar Lazzaro <email address hidden>
Date: Tue Oct 28 18:03:19 2014 -0700

    Subnet mapping broken with overlapping ips

    This is a workaround that checks if a given subnet allocated for
    an EPG overlaps with any other existing subnet in the related
    L3_Policy context.

    Not a solutuion to the subnet allocation problem.

    Workarounds bug #1383947

    Change-Id: I1c00a7452a0417c4f63ded79d6fc0b35c8df8828

Sumit Naiksatam (snaiksat)
Changed in group-based-policy:
status: New → Confirmed
assignee: nobody → Robert Kukura (rkukura)
milestone: none → juno-release
Revision history for this message
Robert Kukura (rkukura) wrote :

I think Ivar's workaround from comment 2 is sufficient until we solve https://bugs.launchpad.net/group-based-policy/+bug/1382149, probably by using the subnet pool feature being implemented in Neutron for Kilo. The only thing we might consider in the mean time is deleting the subnet if the call to _add_router_interface() fails with BadRequest, which could happen with concurrent requests.

Sumit Naiksatam (snaiksat)
Changed in group-based-policy:
milestone: 2014.2rc2 → kilo-gbp-1
Revision history for this message
Robert Kukura (rkukura) wrote :

Neutron subnet pools will not be available in time for kilo-gbp-1.

Changed in group-based-policy:
milestone: kilo-gbp-1 → kilo-gbp-2
Sumit Naiksatam (snaiksat)
Changed in group-based-policy:
milestone: kilo-gbp-2 → kilo-gbp-3
Sumit Naiksatam (snaiksat)
Changed in group-based-policy:
milestone: kilo-gbp-3 → next
Revision history for this message
Sumit Naiksatam (snaiksat) wrote :

This actually depends on:
https://review.openstack.org/179327

Sumit Naiksatam (snaiksat)
Changed in group-based-policy:
status: Confirmed → Triaged
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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