[APIC mapping] VLAN networks don't work with APIC mapping driver

Bug #1581264 reported by Amit Bose
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Group Based Policy
Fix Released
High
Amit Bose

Bug Description

APIC-mapping driver only supports Neutron networks of type OpFlex. This prevents use of GBP/APIC with VLAN networks.

Changed in group-based-policy:
status: New → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to group-based-policy (stable/mitaka)

Fix proposed to branch: stable/mitaka
Review: https://review.openstack.org/315880

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to group-based-policy (stable/liberty)

Fix proposed to branch: stable/liberty
Review: https://review.openstack.org/315881

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to group-based-policy (stable/kilo)

Fix proposed to branch: stable/kilo
Review: https://review.openstack.org/315882

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to group-based-policy (stable/juno)

Fix proposed to branch: stable/juno
Review: https://review.openstack.org/315883

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

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

commit ba62041267cb785c5896b2e533534a368becfe3d
Author: Amit Bose <email address hidden>
Date: Fri May 6 14:41:52 2016 -0700

    [APIC-mapping] Support non-OpFlex networks

    This change enables the apic-mapping driver to
    handle endpoints (ports) when the network-type
    is VLAN. In this scenario, there are no OpFlex
    agents on the compute/network nodes that can configure
    the datapath to isolate traffic and enforce policy.
    Instead we use additional 'shadow' Neutron networks,
    one per PTG, to isolate ports within a PTG from other
    PTGs. Static path binding is configured on-demand on
    APIC using the segmentation-ID of the shadow networks.

    These additional "shadow" networks mirror the
    configuration of the Neutron network created for
    the L2-policy of the PTGs:
    - The shadow networks are named using the convention
     apic_owned_ptg_<ptg-name>_<ptg-id>
    - Subnets in the L2P network are reflected in shadow
    networks of each PTG associated with the L2P. Their
    names use the convention
     apic_owned_sub_<id of subnet in L2P network>
    - Implicit ports created for policy-targets are mirrored
    in the shadow network of the corresponding PTG. This
    additional 'shadow' port is now associated with the
    PT instead of the implicitly created port. These implicit
    ports have device_owner set to 'apic' and device_id set
    to the ID of the PT for which they were created.
    - Explicit ports for PTs is allowed as long as they have
    been created in the appropriate shadow network
    - DHCP ports on the shadow networks are disabled to avoid
    unwanted/wrong responses to DHCP requests from VMs.

    This scheme imposes a few restrictions:
    - PTG of a PT can be no longer updated because that would
    require changing the network of the associated port
    - Ports created in the L2P network cannot be associated
    with a PT; instead such an explicit port must be created
    in the shadow network for the PTG of the PT.

    Without OpFlex agent, NAT-ing won't work with APIC. So
    the apic-mapping driver configures external-segments on
    APIC for the no-NAT case. Once support for edge-NAT is
    available (e.g. through ASR integration), we can make
    the appropriate changes to make floating-IPs and PAT
    work.
    Service-chaining, which requires special handling of
    endpoints in the OpFlex agent, is not expected to work
    out-of-the-box with non-OpFlex network.

    Closes-Bug: 1581264

    Change-Id: I39d09257f6eadcf5ae527d779f13493415a4ec85
    Signed-off-by: Amit Bose <email address hidden>

Changed in group-based-policy:
status: In Progress → Fix Released
tags: added: in-stable-juno
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to group-based-policy (stable/juno)

Reviewed: https://review.openstack.org/315883
Committed: https://git.openstack.org/cgit/openstack/group-based-policy/commit/?id=b4db17b3601b899da6f65b9f30504a76310f2f37
Submitter: Jenkins
Branch: stable/juno

commit b4db17b3601b899da6f65b9f30504a76310f2f37
Author: Amit Bose <email address hidden>
Date: Fri May 6 14:41:52 2016 -0700

    [APIC-mapping] Support non-OpFlex networks

    This change enables the apic-mapping driver to
    handle endpoints (ports) when the network-type
    is VLAN. In this scenario, there are no OpFlex
    agents on the compute/network nodes that can configure
    the datapath to isolate traffic and enforce policy.
    Instead we use additional 'shadow' Neutron networks,
    one per PTG, to isolate ports within a PTG from other
    PTGs. Static path binding is configured on-demand on
    APIC using the segmentation-ID of the shadow networks.

    These additional "shadow" networks mirror the
    configuration of the Neutron network created for
    the L2-policy of the PTGs:
    - The shadow networks are named using the convention
     apic_owned_ptg_<ptg-name>_<ptg-id>
    - Subnets in the L2P network are reflected in shadow
    networks of each PTG associated with the L2P. Their
    names use the convention
     apic_owned_sub_<id of subnet in L2P network>
    - Implicit ports created for policy-targets are mirrored
    in the shadow network of the corresponding PTG. This
    additional 'shadow' port is now associated with the
    PT instead of the implicitly created port. These implicit
    ports have device_owner set to 'apic' and device_id set
    to the ID of the PT for which they were created.
    - Explicit ports for PTs is allowed as long as they have
    been created in the appropriate shadow network
    - DHCP ports on the shadow networks are disabled to avoid
    unwanted/wrong responses to DHCP requests from VMs.

    This scheme imposes a few restrictions:
    - PTG of a PT can be no longer updated because that would
    require changing the network of the associated port
    - Ports created in the L2P network cannot be associated
    with a PT; instead such an explicit port must be created
    in the shadow network for the PTG of the PT.

    Without OpFlex agent, NAT-ing won't work with APIC. So
    the apic-mapping driver configures external-segments on
    APIC for the no-NAT case. Once support for edge-NAT is
    available (e.g. through ASR integration), we can make
    the appropriate changes to make floating-IPs and PAT
    work.
    Service-chaining, which requires special handling of
    endpoints in the OpFlex agent, is not expected to work
    out-of-the-box with non-OpFlex network.

    Closes-Bug: 1581264

    Change-Id: I39d09257f6eadcf5ae527d779f13493415a4ec85
    Signed-off-by: Amit Bose <email address hidden>
    (cherry picked from commit ba62041267cb785c5896b2e533534a368becfe3d)
    (cherry picked from commit 971ed58eeed832ad3c81ee526d031b8d14d4dfe6)
    (cherry picked from commit 7c3eb7b8eb6b4194c42897af8d7c387bb541e721)
    (cherry picked from commit 1b5e62ab190b79c743047233a6299effbe25a964)

tags: added: in-stable-kilo
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to group-based-policy (stable/kilo)

Reviewed: https://review.openstack.org/315882
Committed: https://git.openstack.org/cgit/openstack/group-based-policy/commit/?id=1b5e62ab190b79c743047233a6299effbe25a964
Submitter: Jenkins
Branch: stable/kilo

commit 1b5e62ab190b79c743047233a6299effbe25a964
Author: Amit Bose <email address hidden>
Date: Fri May 6 14:41:52 2016 -0700

    [APIC-mapping] Support non-OpFlex networks

    This change enables the apic-mapping driver to
    handle endpoints (ports) when the network-type
    is VLAN. In this scenario, there are no OpFlex
    agents on the compute/network nodes that can configure
    the datapath to isolate traffic and enforce policy.
    Instead we use additional 'shadow' Neutron networks,
    one per PTG, to isolate ports within a PTG from other
    PTGs. Static path binding is configured on-demand on
    APIC using the segmentation-ID of the shadow networks.

    These additional "shadow" networks mirror the
    configuration of the Neutron network created for
    the L2-policy of the PTGs:
    - The shadow networks are named using the convention
     apic_owned_ptg_<ptg-name>_<ptg-id>
    - Subnets in the L2P network are reflected in shadow
    networks of each PTG associated with the L2P. Their
    names use the convention
     apic_owned_sub_<id of subnet in L2P network>
    - Implicit ports created for policy-targets are mirrored
    in the shadow network of the corresponding PTG. This
    additional 'shadow' port is now associated with the
    PT instead of the implicitly created port. These implicit
    ports have device_owner set to 'apic' and device_id set
    to the ID of the PT for which they were created.
    - Explicit ports for PTs is allowed as long as they have
    been created in the appropriate shadow network
    - DHCP ports on the shadow networks are disabled to avoid
    unwanted/wrong responses to DHCP requests from VMs.

    This scheme imposes a few restrictions:
    - PTG of a PT can be no longer updated because that would
    require changing the network of the associated port
    - Ports created in the L2P network cannot be associated
    with a PT; instead such an explicit port must be created
    in the shadow network for the PTG of the PT.

    Without OpFlex agent, NAT-ing won't work with APIC. So
    the apic-mapping driver configures external-segments on
    APIC for the no-NAT case. Once support for edge-NAT is
    available (e.g. through ASR integration), we can make
    the appropriate changes to make floating-IPs and PAT
    work.
    Service-chaining, which requires special handling of
    endpoints in the OpFlex agent, is not expected to work
    out-of-the-box with non-OpFlex network.

    Closes-Bug: 1581264

    Change-Id: I39d09257f6eadcf5ae527d779f13493415a4ec85
    Signed-off-by: Amit Bose <email address hidden>
    (cherry picked from commit ba62041267cb785c5896b2e533534a368becfe3d)
    (cherry picked from commit 971ed58eeed832ad3c81ee526d031b8d14d4dfe6)
    (cherry picked from commit 7c3eb7b8eb6b4194c42897af8d7c387bb541e721)

tags: added: in-stable-liberty
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to group-based-policy (stable/liberty)

Reviewed: https://review.openstack.org/315881
Committed: https://git.openstack.org/cgit/openstack/group-based-policy/commit/?id=7c3eb7b8eb6b4194c42897af8d7c387bb541e721
Submitter: Jenkins
Branch: stable/liberty

commit 7c3eb7b8eb6b4194c42897af8d7c387bb541e721
Author: Amit Bose <email address hidden>
Date: Fri May 6 14:41:52 2016 -0700

    [APIC-mapping] Support non-OpFlex networks

    This change enables the apic-mapping driver to
    handle endpoints (ports) when the network-type
    is VLAN. In this scenario, there are no OpFlex
    agents on the compute/network nodes that can configure
    the datapath to isolate traffic and enforce policy.
    Instead we use additional 'shadow' Neutron networks,
    one per PTG, to isolate ports within a PTG from other
    PTGs. Static path binding is configured on-demand on
    APIC using the segmentation-ID of the shadow networks.

    These additional "shadow" networks mirror the
    configuration of the Neutron network created for
    the L2-policy of the PTGs:
    - The shadow networks are named using the convention
     apic_owned_ptg_<ptg-name>_<ptg-id>
    - Subnets in the L2P network are reflected in shadow
    networks of each PTG associated with the L2P. Their
    names use the convention
     apic_owned_sub_<id of subnet in L2P network>
    - Implicit ports created for policy-targets are mirrored
    in the shadow network of the corresponding PTG. This
    additional 'shadow' port is now associated with the
    PT instead of the implicitly created port. These implicit
    ports have device_owner set to 'apic' and device_id set
    to the ID of the PT for which they were created.
    - Explicit ports for PTs is allowed as long as they have
    been created in the appropriate shadow network
    - DHCP ports on the shadow networks are disabled to avoid
    unwanted/wrong responses to DHCP requests from VMs.

    This scheme imposes a few restrictions:
    - PTG of a PT can be no longer updated because that would
    require changing the network of the associated port
    - Ports created in the L2P network cannot be associated
    with a PT; instead such an explicit port must be created
    in the shadow network for the PTG of the PT.

    Without OpFlex agent, NAT-ing won't work with APIC. So
    the apic-mapping driver configures external-segments on
    APIC for the no-NAT case. Once support for edge-NAT is
    available (e.g. through ASR integration), we can make
    the appropriate changes to make floating-IPs and PAT
    work.
    Service-chaining, which requires special handling of
    endpoints in the OpFlex agent, is not expected to work
    out-of-the-box with non-OpFlex network.

    Closes-Bug: 1581264

    Change-Id: I39d09257f6eadcf5ae527d779f13493415a4ec85
    Signed-off-by: Amit Bose <email address hidden>
    (cherry picked from commit ba62041267cb785c5896b2e533534a368becfe3d)
    (cherry picked from commit 971ed58eeed832ad3c81ee526d031b8d14d4dfe6)

tags: added: in-stable-mitaka
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to group-based-policy (stable/mitaka)

Reviewed: https://review.openstack.org/315880
Committed: https://git.openstack.org/cgit/openstack/group-based-policy/commit/?id=971ed58eeed832ad3c81ee526d031b8d14d4dfe6
Submitter: Jenkins
Branch: stable/mitaka

commit 971ed58eeed832ad3c81ee526d031b8d14d4dfe6
Author: Amit Bose <email address hidden>
Date: Fri May 6 14:41:52 2016 -0700

    [APIC-mapping] Support non-OpFlex networks

    This change enables the apic-mapping driver to
    handle endpoints (ports) when the network-type
    is VLAN. In this scenario, there are no OpFlex
    agents on the compute/network nodes that can configure
    the datapath to isolate traffic and enforce policy.
    Instead we use additional 'shadow' Neutron networks,
    one per PTG, to isolate ports within a PTG from other
    PTGs. Static path binding is configured on-demand on
    APIC using the segmentation-ID of the shadow networks.

    These additional "shadow" networks mirror the
    configuration of the Neutron network created for
    the L2-policy of the PTGs:
    - The shadow networks are named using the convention
     apic_owned_ptg_<ptg-name>_<ptg-id>
    - Subnets in the L2P network are reflected in shadow
    networks of each PTG associated with the L2P. Their
    names use the convention
     apic_owned_sub_<id of subnet in L2P network>
    - Implicit ports created for policy-targets are mirrored
    in the shadow network of the corresponding PTG. This
    additional 'shadow' port is now associated with the
    PT instead of the implicitly created port. These implicit
    ports have device_owner set to 'apic' and device_id set
    to the ID of the PT for which they were created.
    - Explicit ports for PTs is allowed as long as they have
    been created in the appropriate shadow network
    - DHCP ports on the shadow networks are disabled to avoid
    unwanted/wrong responses to DHCP requests from VMs.

    This scheme imposes a few restrictions:
    - PTG of a PT can be no longer updated because that would
    require changing the network of the associated port
    - Ports created in the L2P network cannot be associated
    with a PT; instead such an explicit port must be created
    in the shadow network for the PTG of the PT.

    Without OpFlex agent, NAT-ing won't work with APIC. So
    the apic-mapping driver configures external-segments on
    APIC for the no-NAT case. Once support for edge-NAT is
    available (e.g. through ASR integration), we can make
    the appropriate changes to make floating-IPs and PAT
    work.
    Service-chaining, which requires special handling of
    endpoints in the OpFlex agent, is not expected to work
    out-of-the-box with non-OpFlex network.

    Closes-Bug: 1581264

    Change-Id: I39d09257f6eadcf5ae527d779f13493415a4ec85
    Signed-off-by: Amit Bose <email address hidden>
    (cherry picked from commit ba62041267cb785c5896b2e533534a368becfe3d)

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.