← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1803494] [NEW] [RFE] Add l2pop support for floating IP resources

 

Public bug reported:

Layer 2 population (l2pop) mechanism driver implements the ML2 driver to
improve open source plugins overlay implementations (VXLAN with Linux
bridge and GRE/VXLAN with OVS)[1]. L2pop avoid the broadcast in MAC
learning and ARP resolution by prepopulate the bridge forwarding
table[2]. However l2pop doesn’t have support for floating IP resources.
If the floating IP resources can be prepopulated, the broadcast for
scenarios when two VM instances, residing on different networks,
communicate via their respective FIP addresses can be avoided.

Problem Description
==========================================================
Figure-1 illustrates the scenarios for floating IP. The IP address “182.34.4.2” in Port3 is the IP address in floating IP resources. When the client in the external network tries to access VM1, the destination IP “182.34.4.2” is replaced by the IP address “10.0.0.3” of the Port1. Notice that the IP address of Port1 is the IP address of VM1. When VM1 send packets back to client, the source IP “10.0.0.3” will be replaced by “182.34.4.2”.

                         (Attached in the comment)
                                Figure-1
                       Port1 10.0.0.3, Port2 10.0.0.1
                       Port3 182.34.4.2, Port4 188.34.4.1

When users want to use floating IP, they should first require allocating
a floating IP from floating IP pool or choose a pre allocated floating
IP. Allocating floating IP will create a new port and also updates the
new port. Creating port will never trigger l2pop but updating port will
trigger l2pop on the condition that the port’s new status is ACTIVE or
DOWN. However the status of the port for floating IP will always be N/A.
Thus allocating floating IP won’t trigger l2pop.

After getting the available floating IP, users can require to associate
the VM and the floating IP. Associating the IP address of the VM with
the floating IP only updates the floating IP object and doesn’t update
the port for floating IP. Thus associating the VM and the floating IP
won’t trigger l2pop.

Based on the above analysis, the FDB of floating IP is not prepopulated.
It seems that to we can simply change the status of Port3 from N/A to
ACTIVE/DOWN to prepopulate the pair (MAC, IP) of Port3 . But we can’t do
that because the MAC address of Port3 is never used. In the non-DVR
scenario, the MAC address of router gateway will be replied to answer
the ARP request for floating IP. In the DVR scenario, the MAC address of
floating IP agent gateway will be replied to answer the ARP request for
floating IP.

In the following use case, ARP request will be sent out to query the MAC
address related to the specific floating IP. Figure-2 illustrates an
environment (DVR disabled) that there are two network nodes and two
compute nodes.

                         (Attached in the comment)
                                  Figure-2
                      Port1 10.0.0.1, Port2 198.0.0.2
                      Port5 182.34.4.5, Port6 182.34.4.6

Use Case 1
Tenant-1 creates Network-1 and Tenant-2 creates Network-2.
Tenant-1 creates Subnet-1 belonging to Network-1 and Tenant-2 creates Subnet-2 belonging to Network-2.
Tenant-1 creates Router-1 and links the Router-1 to the external provider network. Tenant-2 creates Router-2 and links the Router-2 to the external provider network.
Tenant-1 links the Router-1 to the Subnet-1 and Tenant-2 links Router-2 to the Subnet-2.
Tenant-1 creates VM-1 in Subnet-1 and Tenant-2 creates VM-2 in Subnet-2.
Tenant-1 creates FloatingIP-1 and Tenant-2 creates FloatingIP-2.
Tenant-1 associates VM-1 with FloatingIP-1 and Tenant2 associates VM-2 with FloatingIP-2.
VM-1 communicates VM-2 by floating IP. For example: VM-1 pings FloatingIP-2 for the first time.

VM-1 has the IP address “10.0.0.1” which is the IP address of Port1 and
VM-2 has the IP address “198.0.0.2” which is the IP address of Port2.
FloatingIP-1 has the IP address “182.34.4.5” and FloatingIP-2 has the IP
address “182.34.4.6”(The related ports are not drawn). The MAC address
of Router-1 gateway(Gateway-1) is “fa:16:3e:1b:ee:2b” and the MAC
address of Router-2 gateway(Gateway-2) is “fa:16:3e:ab:cf:34”.

VM-1 and VM-2 reside on different networks and communicate via their
respective floating IP addresses. When VM-1 pings FloatingIP-2 for the
first time, it needs to know the MAC address for FloatingIP-2. Thus ARP
request is sent out. And the MAC address “fa:16:3e:ab:cf:34” of
Gateway-2 will be answered. If the FDB is pre-populated, the ARP request
can be avoided. For non-DVR use case, (host_ip,
router_gateway_mac_address, floating_ip_address) should be prepopulated.

The figure-3 illustrates an environment (DVR enabled). The use case is
listed below:

Use Case 2
Tenant-1 creates Network-1 and Tenant-2 creates Network-2.
Tenant-1 creates Subnet-1 belonging to Network-1 and Tenant-2 creates Subnet-2 belonging to Network-2.
Tenant-1 creates a distributed virtual router DVR-1 and Router-1 is the distributed router on compute-1. Tenant-2 creates a distributed virtual router DVR-2 and Router-2 is the distributed router on compute-2.
Tenant-1 links the DVR-1 to the external provider network. Tenant-2 links the DVR-2 to the external provider network.
Tenant-1 links the DVR-1 to the Subnet-1 and Tenant-2 links DVR-2 to the Subnet-2.
Tenant-1 creates VM-1 in Subnet-1 and Tenant-2 creates VM-2 in Subnet-2.
Tenant-1 creates FloatingIP-1 and Tenant-2 creates FloatingIP-2.
Tenant-1 associates VM-1 with FloatingIP-1 and Tenant2 associates VM-2 with FloatingIP-2.
VM-1 communicates VM-2 by floating IP. For example: VM-1 pings FloatingIP-2 for the first time.

                         (Attached in the comment)
                                 Figure-3

VM-1 has the IP address “10.0.0.1” which is the IP address of Port1 and
VM-2 has the IP address “190.0.0.2” which is the IP address of Port2.
FloatingIP-1 has the IP address “182.34.4.5” which is the IP address of
Port5 and FloatingIP-2 has the IP address “182.34.4.6” which is the IP
address of Port6. When a floating IP is attached to a VM, the L3 agent
will create a FIP namespace (If one does not already exist) for the
external network that the FIP belongs to. After the step 8, FIP-1 and
FIP-2 will be created. Port9 is FIP-1 floating IP agent gateway and
Port10 is FIP-2 floating IP agent gateway. The MAC address of Port9 is
“fa:16:3e:e9:87:24” and the MAC address of Port10 is
“fa:16:3e:e7:86:db”.

VM-1 and VM-2 reside on different networks and communicate via their
respective floating IP addresses. When VM-1 pings FloatingIP-2 for the
first time, it needs to know the MAC address for FloatingIP-2. Thus ARP
request is sent out. And the MAC address “fa:16:3e:e7:86:db” of FIP-2
floating IP agent gateway will be answered. If the FDB is prepopulated,
the ARP request can be avoided. For DVR use case, (host_ip,
floatingip_agent_gateway_mac_address, floating_ip_address) should be
prepopulated.

Proposed Change
==================================================================
The idea is that advertising the FDBs for floating IP when the FIP status changes to "ACTIVE" and withdraw the FDBs for floating IP whenever the status is set to "DOWN" or the resource is deleted or disassociated.

Function _notify_fip_status will be added to send an event after
updating floating IPs.  Function _delete_floatingip should be modified
to use _notify_fip_status to notify the floating IP status. Function
_update_fip_assoc is used by function _create_floatingip and
_update_floatingip. Both functions will send events after updating
floating IP with the result from _update_fip_assoc. Thus we can just
insert the status of floating IP into the result of _update_fip_assoc.
Function disassociate_floatingips already sends event out after updating
floating IP. However after disassociating floating IPs, the router_id
and fixed_port_id both are None. Thus need to insert floating IP status,
last_known_router_id and last_fixed_port_id into the event.

A class L3RouterL2PopMixin should be added to process the event sent
after updating floating IP. This class should subscribe the event and
register the callback to l2pop mechanism driver to extend the l2pop FDBs
(Depends on RFE: https://bugs.launchpad.net/neutron/+bug/1793653). Thus
Callback l3_fdb_extend_func should be added. Function
handle_fip_status_update should be added to process the event and send
the l2pop FDBs out. For non-DVR, (host_ip, router_gateway_mac_address,
floating_ip_address) should be prepopulated. For DVR, (host_ip,
floatingip_agent_gateway_mac_address, floating_ip_address) should be
prepopulated. What’s more, some other functions used by the functions
described above should be added.

All changes can be viewed through the link below:
https://review.openstack.org/#/c/611261/
https://review.openstack.org/#/c/611284/

Data Model Impact
============================================================
None

REST API Impact
============================================================
None

Command Line Client Impact
============================================================
None

Other Impact
============================================================
None

Other Deployer Impact
============================================================
None

Performance Impact
============================================================
Performance testing should be conducted to see test the overhead of adding more information to FDB.

Implementation
Assignee(s)

Work Items
===========================================================
Add function _notify_fip_status to neutron/db/l3_db.py and modify some existing functions in l3_db.py.
Add class L3RouterL2PopMixin to neutron/services/l3_router/service_providers/l2pop.py
Add related tests.

Dependencies
============================================================
Need the RFE “Enable other subprojects to extend l2pop FDB information” merged in OpenStack. This RFE enables other subprojects to extend l2pop FDB information. We need to add floating IP related information to l2pop FDB. Thus we need to use the ability provided by the RFE. The link for RFE is below:
https://bugs.launchpad.net/neutron/+bug/1793653

Testing
============================================================
Unit tests are necessary.

Documentation Impact
============================================================
None.

References
============================================================
[1] https://github.com/openstack/neutron/tree/master/neutron/plugins/ml2/drivers/l2pop
[2] https://wiki.openstack.org/wiki/L2population_blueprint

** Affects: neutron
     Importance: Undecided
     Assignee: ChenjieXu (midone)
         Status: New

** Changed in: neutron
     Assignee: (unassigned) => ChenjieXu (midone)

** Description changed:

  Layer 2 population (l2pop) mechanism driver implements the ML2 driver to
  improve open source plugins overlay implementations (VXLAN with Linux
  bridge and GRE/VXLAN with OVS)[1]. L2pop avoid the broadcast in MAC
  learning and ARP resolution by prepopulate the bridge forwarding
  table[2]. However l2pop doesn’t have support for floating IP resources.
  If the floating IP resources can be prepopulated, the broadcast for
  scenarios when two VM instances, residing on different networks,
  communicate via their respective FIP addresses can be avoided.
  
- 
  Problem Description
  ==========================================================
- Figure-1 illustrates the scenarios for floating IP. The IP address “182.34.4.2” in Port3 is the IP address in floating IP resources. When the client in the external network tries to access VM1, the destination IP “182.34.4.2” is replaced by the IP address “10.0.0.3” of the Port1. Notice that the IP address of Port1 is the IP address of VM1. When VM1 send packets back to client, the source IP “10.0.0.3” will be replaced by “182.34.4.2”. 
+ Figure-1 illustrates the scenarios for floating IP. The IP address “182.34.4.2” in Port3 is the IP address in floating IP resources. When the client in the external network tries to access VM1, the destination IP “182.34.4.2” is replaced by the IP address “10.0.0.3” of the Port1. Notice that the IP address of Port1 is the IP address of VM1. When VM1 send packets back to client, the source IP “10.0.0.3” will be replaced by “182.34.4.2”.
  
- +-----------------+        +-------------------------+
- |    Compute      |        |         Network         |
- |                 |        |                         |
- | +-------------+ |        | +---------------------+ |       +----------------------+
- | |     VM1     | |        | |     Router_1        | |       |     Router_2         |
- | |  (Server1)  | |        | |                     | |       |  (External Router)   |      +----------+
- | |      +------+ |        | +--------+   +--------+ |       | +-------+  +-------+ |      | External |
- | |      | Port1+------------+ Port2  |   |Gateway +-----------+ Port4 |  | Port5 +--------+ Network  |
- | |      +------+ |        | +--------+   +--------+ |       | +-------+  +-------+ |      +----------+ 
- | |             | |        | +--------+            | |       |                      |      
- | +-------------+ |        | | Port3  |            | |       +----------------------+
- |                 |        | +--------+------------+ |
- +-----------------+        +-------------------------+ 
- 
-                                                   Figure-1
-                                         Port1 10.0.0.3, Port2 10.0.0.1
-                                         Port3 182.34.4.2, Port4 188.34.4.1 
+                                            (Attached in the comment)
+                                                   Figure-1
+                                         Port1 10.0.0.3, Port2 10.0.0.1
+                                         Port3 182.34.4.2, Port4 188.34.4.1
  
  When users want to use floating IP, they should first require allocating
  a floating IP from floating IP pool or choose a pre allocated floating
  IP. Allocating floating IP will create a new port and also updates the
  new port. Creating port will never trigger l2pop but updating port will
  trigger l2pop on the condition that the port’s new status is ACTIVE or
  DOWN. However the status of the port for floating IP will always be N/A.
  Thus allocating floating IP won’t trigger l2pop.
  
  After getting the available floating IP, users can require to associate
  the VM and the floating IP. Associating the IP address of the VM with
  the floating IP only updates the floating IP object and doesn’t update
  the port for floating IP. Thus associating the VM and the floating IP
  won’t trigger l2pop.
  
  Based on the above analysis, the FDB of floating IP is not prepopulated.
  It seems that to we can simply change the status of Port3 from N/A to
  ACTIVE/DOWN to prepopulate the pair (MAC, IP) of Port3 . But we can’t do
  that because the MAC address of Port3 is never used. In the non-DVR
  scenario, the MAC address of router gateway will be replied to answer
  the ARP request for floating IP. In the DVR scenario, the MAC address of
  floating IP agent gateway will be replied to answer the ARP request for
  floating IP.
  
- In the following use case, ARP request will be sent out to query the MAC address related to the specific floating IP. Figure-2 illustrates an environment (DVR disabled) that there are two network nodes and two compute nodes.
-                           
- +-----------------------+                                                          +----------------------+ 
- |       Compute-1       |                                                          |      Compute-2       |
- |                       |                                                          |                      |
- | +-------------------+ |         +-----------------+     +-----------------+      | +------------------+ |       
- | |     Network-1     | |         |     Network     |     |    Network      |      | |    Network-2     | |                            
- | | +---------------+ | |         |     Node-1      |     |    Node-2       |      | | +--------------+ | |
- | | |    Subnet-1   | | |         | +-------------+ |     | +-------------+ |      | | |  Subnet-2    | | |  
- | | | +-----------+ | | |         | |  Router-1   | |     | |  Router-2   | |      | | | +----------+ | | |
- | | | |   VM-1    | | | |         | |             | |     | |             | |      | | | |  VM-2    | | | |                      
- | | | |   +-------+ | | |         | | +---------+ | |     | | +---------+ | |      | | | +--------+ | | | |                              
- | | | |   | Port1 +-------------------+  Port3  | | |     | | |  Port4  +----------------+ Port2  | | | | |
- | | | |   +-------+ | | |         | | +---------+ | |     | | +---------+ | |      | | | +--------+ | | | |
- | | | |           | | | |         | |             | |     | |             | |      | | | |          | | | |  
- | | | +-----------+ | | |         | | +---------+ | |     | | +---------+ | |      | | | +----------+ | | |
- | | +---------------+ | |         | | |Gateway-1| | |     | | |Gateway-2| | |      | | +--------------+ | |
- | +-------------------+ |         | | +----+----+ | |     | | +---+-----+ | |      | +------------------+ |
- +-----------------------+         | +----- | -----+ |     | +---- | ------+ |      +----------------------+  
-                                   +------- | -------+     +------ | --------+
-                                            |                      |
-                                            |                      |
-                                   +------- | -------------------- | -----+                      
-                                   |        |       External       |      |
-                                   |        |        Router        |      |
-                                   |        |                      |      |
-                                   |   +----+----------------------+---+  |
-                                   |   |              Port5            |  |
-                                   |   +-------------------------------+  |
-                                   |                                      |          +------------+
-                                   |                           +--------+ |          |  External  |
-                                   |                           | Port6  +------------+  Network   |
-                                   |                           +--------+ |          +------------+
-                                   +--------------------------------------+ 
+ In the following use case, ARP request will be sent out to query the MAC
+ address related to the specific floating IP. Figure-2 illustrates an
+ environment (DVR disabled) that there are two network nodes and two
+ compute nodes.
  
-                                                   Figure-2
-                                        Port1 10.0.0.1, Port2 198.0.0.2 
-                                        Port5 182.34.4.5, Port6 182.34.4.6 
+                                            (Attached in the comment)
+                                                   Figure-2
+                                        Port1 10.0.0.1, Port2 198.0.0.2
+                                        Port5 182.34.4.5, Port6 182.34.4.6
  
  Use Case 1
  Tenant-1 creates Network-1 and Tenant-2 creates Network-2.
  Tenant-1 creates Subnet-1 belonging to Network-1 and Tenant-2 creates Subnet-2 belonging to Network-2.
  Tenant-1 creates Router-1 and links the Router-1 to the external provider network. Tenant-2 creates Router-2 and links the Router-2 to the external provider network.
  Tenant-1 links the Router-1 to the Subnet-1 and Tenant-2 links Router-2 to the Subnet-2.
  Tenant-1 creates VM-1 in Subnet-1 and Tenant-2 creates VM-2 in Subnet-2.
  Tenant-1 creates FloatingIP-1 and Tenant-2 creates FloatingIP-2.
  Tenant-1 associates VM-1 with FloatingIP-1 and Tenant2 associates VM-2 with FloatingIP-2.
  VM-1 communicates VM-2 by floating IP. For example: VM-1 pings FloatingIP-2 for the first time.
  
  VM-1 has the IP address “10.0.0.1” which is the IP address of Port1 and
  VM-2 has the IP address “198.0.0.2” which is the IP address of Port2.
  FloatingIP-1 has the IP address “182.34.4.5” and FloatingIP-2 has the IP
  address “182.34.4.6”(The related ports are not drawn). The MAC address
  of Router-1 gateway(Gateway-1) is “fa:16:3e:1b:ee:2b” and the MAC
  address of Router-2 gateway(Gateway-2) is “fa:16:3e:ab:cf:34”.
  
  VM-1 and VM-2 reside on different networks and communicate via their
  respective floating IP addresses. When VM-1 pings FloatingIP-2 for the
  first time, it needs to know the MAC address for FloatingIP-2. Thus ARP
  request is sent out. And the MAC address “fa:16:3e:ab:cf:34” of
  Gateway-2 will be answered. If the FDB is pre-populated, the ARP request
  can be avoided. For non-DVR use case, (host_ip,
  router_gateway_mac_address, floating_ip_address) should be prepopulated.
  
  The figure-3 illustrates an environment (DVR enabled). The use case is
  listed below:
  
  Use Case 2
  Tenant-1 creates Network-1 and Tenant-2 creates Network-2.
  Tenant-1 creates Subnet-1 belonging to Network-1 and Tenant-2 creates Subnet-2 belonging to Network-2.
  Tenant-1 creates a distributed virtual router DVR-1 and Router-1 is the distributed router on compute-1. Tenant-2 creates a distributed virtual router DVR-2 and Router-2 is the distributed router on compute-2.
  Tenant-1 links the DVR-1 to the external provider network. Tenant-2 links the DVR-2 to the external provider network.
  Tenant-1 links the DVR-1 to the Subnet-1 and Tenant-2 links DVR-2 to the Subnet-2.
  Tenant-1 creates VM-1 in Subnet-1 and Tenant-2 creates VM-2 in Subnet-2.
  Tenant-1 creates FloatingIP-1 and Tenant-2 creates FloatingIP-2.
  Tenant-1 associates VM-1 with FloatingIP-1 and Tenant2 associates VM-2 with FloatingIP-2.
  VM-1 communicates VM-2 by floating IP. For example: VM-1 pings FloatingIP-2 for the first time.
  
- +-----------------------------------+              +-------------------------------------+
- |              Compute-1            |              |              Compute-2              |
- |                                   |              |                                     |
- | +-------------------------------+ |              | +---------------------------------+ |       
- | |            Network-1          | |              | |           Network-2             | |                            
- | | +---------------------------+ | |              | | +-----------------------------+ | |
- | | |          Subnet-1         | | |              | | |          Subnet-2           | | |  
- | | | +-----------------------+ | | |              | | | +-------------------------+ | | |
- | | | |          VM-1         | | | |              | | | |           VM-2          | | | |                      
- | | | |  +-------+            | | | |              | | | |  +--------+             | | | |                              
- | | | |  |Port1  |            | | | |              | | | |  |  Port2 |             | | | |
- | | | +--+--+----+------------+ | | |              | | | +--+---+----+-------------+ | | |
- | | |       |                   | | |              | | |        |                    | | |
- | | +------ | ------------------+ | |              | | +------- | -------------------+ | | 
- | +-------- | --------------------+ |              | +--------- | ---------------------+ | 
- |           |                       |              |            |                        |
- | +-------- | --------------------+ |              | +--------- | ---------------------+ |
- | |         |    Router-1         | |              | |          |    Router-2          | |
- | |     +---+---+      +--------+ | |              | |      +---+---+       +--------+ | |
- | |     | Port3 |      | Port5  | | |              | |      | Port4 |       | Port6  | | |
- | |     +-------+      +---+----+ | |              | |      +-------+       +---+----+ | |
- | +----------------------- | -----+ |              | +------------------------- | -----+ |
- |                          |        |              |                            |        |
- | +----------------------- | -----+ |              | +------------------------- | -----+ |
- | |             FIP-1      |      | |              | |              FIP-2       |      | |
- | |     +-------+      +---+----+ | |              | |    +---------+       +---+----+ | |
- | |     | Port9 |      |  Port7 | | |              | |    | Port10  |       |  Port8 | | |
- | |     +---+---+      +--------+ | |              | |    +---+-----+       +--------+ | |
- | +-------- | --------------------+ |              | +------- | -----------------------+ |
- +---------- | ----------------------+              +--------- | -------------------------+  
-             |                                                 |
-             |                                                 |
- +---------- | ----------------------------------------------- | --------+                      
- |           |             External Router                     |         |
- |    +------+-------------------------------------------------+-------+ |
- |    |                         Port11                                 | |
- |    +----------------------------------------------------------------+ |          +-------------+
- |                                                            +--------+ |          |  External   |
- |                                                            | Port12 +------------+   Network   |
- |                                                            +--------+ |          +-------------+
- +-----------------------------------------------------------------------+ 
- 
-                                               Figure-3
+                                        (Attached in the comment)
+                                               Figure-3
  
  VM-1 has the IP address “10.0.0.1” which is the IP address of Port1 and
  VM-2 has the IP address “190.0.0.2” which is the IP address of Port2.
  FloatingIP-1 has the IP address “182.34.4.5” which is the IP address of
  Port5 and FloatingIP-2 has the IP address “182.34.4.6” which is the IP
  address of Port6. When a floating IP is attached to a VM, the L3 agent
  will create a FIP namespace (If one does not already exist) for the
  external network that the FIP belongs to. After the step 8, FIP-1 and
  FIP-2 will be created. Port9 is FIP-1 floating IP agent gateway and
  Port10 is FIP-2 floating IP agent gateway. The MAC address of Port9 is
  “fa:16:3e:e9:87:24” and the MAC address of Port10 is
  “fa:16:3e:e7:86:db”.
  
  VM-1 and VM-2 reside on different networks and communicate via their
  respective floating IP addresses. When VM-1 pings FloatingIP-2 for the
  first time, it needs to know the MAC address for FloatingIP-2. Thus ARP
  request is sent out. And the MAC address “fa:16:3e:e7:86:db” of FIP-2
  floating IP agent gateway will be answered. If the FDB is prepopulated,
  the ARP request can be avoided. For DVR use case, (host_ip,
  floatingip_agent_gateway_mac_address, floating_ip_address) should be
  prepopulated.
- 
  
  Proposed Change
  ==================================================================
  The idea is that advertising the FDBs for floating IP when the FIP status changes to "ACTIVE" and withdraw the FDBs for floating IP whenever the status is set to "DOWN" or the resource is deleted or disassociated.
  
  Function _notify_fip_status will be added to send an event after
  updating floating IPs.  Function _delete_floatingip should be modified
  to use _notify_fip_status to notify the floating IP status. Function
  _update_fip_assoc is used by function _create_floatingip and
  _update_floatingip. Both functions will send events after updating
  floating IP with the result from _update_fip_assoc. Thus we can just
  insert the status of floating IP into the result of _update_fip_assoc.
  Function disassociate_floatingips already sends event out after updating
  floating IP. However after disassociating floating IPs, the router_id
  and fixed_port_id both are None. Thus need to insert floating IP status,
  last_known_router_id and last_fixed_port_id into the event.
  
  A class L3RouterL2PopMixin should be added to process the event sent
  after updating floating IP. This class should subscribe the event and
  register the callback to l2pop mechanism driver to extend the l2pop FDBs
  (Depends on RFE: https://bugs.launchpad.net/neutron/+bug/1793653). Thus
  Callback l3_fdb_extend_func should be added. Function
  handle_fip_status_update should be added to process the event and send
  the l2pop FDBs out. For non-DVR, (host_ip, router_gateway_mac_address,
  floating_ip_address) should be prepopulated. For DVR, (host_ip,
  floatingip_agent_gateway_mac_address, floating_ip_address) should be
  prepopulated. What’s more, some other functions used by the functions
  described above should be added.
  
  All changes can be viewed through the link below:
  https://review.openstack.org/#/c/611261/
  https://review.openstack.org/#/c/611284/
  
  Data Model Impact
  ============================================================
  None
  
  REST API Impact
  ============================================================
  None
  
  Command Line Client Impact
  ============================================================
  None
  
  Other Impact
  ============================================================
  None
  
  Other Deployer Impact
  ============================================================
  None
  
  Performance Impact
  ============================================================
  Performance testing should be conducted to see test the overhead of adding more information to FDB.
  
  Implementation
  Assignee(s)
  
  Work Items
  ===========================================================
  Add function _notify_fip_status to neutron/db/l3_db.py and modify some existing functions in l3_db.py.
  Add class L3RouterL2PopMixin to neutron/services/l3_router/service_providers/l2pop.py
  Add related tests.
  
  Dependencies
  ============================================================
  Need the RFE “Enable other subprojects to extend l2pop FDB information” merged in OpenStack. This RFE enables other subprojects to extend l2pop FDB information. We need to add floating IP related information to l2pop FDB. Thus we need to use the ability provided by the RFE. The link for RFE is below:
  https://bugs.launchpad.net/neutron/+bug/1793653
  
- 
  Testing
  ============================================================
  Unit tests are necessary.
  
  Documentation Impact
  ============================================================
  None.
  
  References
  ============================================================
  [1] https://github.com/openstack/neutron/tree/master/neutron/plugins/ml2/drivers/l2pop
  [2] https://wiki.openstack.org/wiki/L2population_blueprint

** Description changed:

  Layer 2 population (l2pop) mechanism driver implements the ML2 driver to
  improve open source plugins overlay implementations (VXLAN with Linux
  bridge and GRE/VXLAN with OVS)[1]. L2pop avoid the broadcast in MAC
  learning and ARP resolution by prepopulate the bridge forwarding
  table[2]. However l2pop doesn’t have support for floating IP resources.
  If the floating IP resources can be prepopulated, the broadcast for
  scenarios when two VM instances, residing on different networks,
  communicate via their respective FIP addresses can be avoided.
  
  Problem Description
  ==========================================================
  Figure-1 illustrates the scenarios for floating IP. The IP address “182.34.4.2” in Port3 is the IP address in floating IP resources. When the client in the external network tries to access VM1, the destination IP “182.34.4.2” is replaced by the IP address “10.0.0.3” of the Port1. Notice that the IP address of Port1 is the IP address of VM1. When VM1 send packets back to client, the source IP “10.0.0.3” will be replaced by “182.34.4.2”.
  
-                                            (Attached in the comment)
-                                                   Figure-1
-                                         Port1 10.0.0.3, Port2 10.0.0.1
-                                         Port3 182.34.4.2, Port4 188.34.4.1
+                          (Attached in the comment)
+                                 Figure-1
+                        Port1 10.0.0.3, Port2 10.0.0.1
+                        Port3 182.34.4.2, Port4 188.34.4.1
  
  When users want to use floating IP, they should first require allocating
  a floating IP from floating IP pool or choose a pre allocated floating
  IP. Allocating floating IP will create a new port and also updates the
  new port. Creating port will never trigger l2pop but updating port will
  trigger l2pop on the condition that the port’s new status is ACTIVE or
  DOWN. However the status of the port for floating IP will always be N/A.
  Thus allocating floating IP won’t trigger l2pop.
  
  After getting the available floating IP, users can require to associate
  the VM and the floating IP. Associating the IP address of the VM with
  the floating IP only updates the floating IP object and doesn’t update
  the port for floating IP. Thus associating the VM and the floating IP
  won’t trigger l2pop.
  
  Based on the above analysis, the FDB of floating IP is not prepopulated.
  It seems that to we can simply change the status of Port3 from N/A to
  ACTIVE/DOWN to prepopulate the pair (MAC, IP) of Port3 . But we can’t do
  that because the MAC address of Port3 is never used. In the non-DVR
  scenario, the MAC address of router gateway will be replied to answer
  the ARP request for floating IP. In the DVR scenario, the MAC address of
  floating IP agent gateway will be replied to answer the ARP request for
  floating IP.
  
  In the following use case, ARP request will be sent out to query the MAC
  address related to the specific floating IP. Figure-2 illustrates an
  environment (DVR disabled) that there are two network nodes and two
  compute nodes.
  
-                                            (Attached in the comment)
-                                                   Figure-2
-                                        Port1 10.0.0.1, Port2 198.0.0.2
-                                        Port5 182.34.4.5, Port6 182.34.4.6
+                          (Attached in the comment)
+                                   Figure-2
+                       Port1 10.0.0.1, Port2 198.0.0.2
+                       Port5 182.34.4.5, Port6 182.34.4.6
  
  Use Case 1
  Tenant-1 creates Network-1 and Tenant-2 creates Network-2.
  Tenant-1 creates Subnet-1 belonging to Network-1 and Tenant-2 creates Subnet-2 belonging to Network-2.
  Tenant-1 creates Router-1 and links the Router-1 to the external provider network. Tenant-2 creates Router-2 and links the Router-2 to the external provider network.
  Tenant-1 links the Router-1 to the Subnet-1 and Tenant-2 links Router-2 to the Subnet-2.
  Tenant-1 creates VM-1 in Subnet-1 and Tenant-2 creates VM-2 in Subnet-2.
  Tenant-1 creates FloatingIP-1 and Tenant-2 creates FloatingIP-2.
  Tenant-1 associates VM-1 with FloatingIP-1 and Tenant2 associates VM-2 with FloatingIP-2.
  VM-1 communicates VM-2 by floating IP. For example: VM-1 pings FloatingIP-2 for the first time.
  
  VM-1 has the IP address “10.0.0.1” which is the IP address of Port1 and
  VM-2 has the IP address “198.0.0.2” which is the IP address of Port2.
  FloatingIP-1 has the IP address “182.34.4.5” and FloatingIP-2 has the IP
  address “182.34.4.6”(The related ports are not drawn). The MAC address
  of Router-1 gateway(Gateway-1) is “fa:16:3e:1b:ee:2b” and the MAC
  address of Router-2 gateway(Gateway-2) is “fa:16:3e:ab:cf:34”.
  
  VM-1 and VM-2 reside on different networks and communicate via their
  respective floating IP addresses. When VM-1 pings FloatingIP-2 for the
  first time, it needs to know the MAC address for FloatingIP-2. Thus ARP
  request is sent out. And the MAC address “fa:16:3e:ab:cf:34” of
  Gateway-2 will be answered. If the FDB is pre-populated, the ARP request
  can be avoided. For non-DVR use case, (host_ip,
  router_gateway_mac_address, floating_ip_address) should be prepopulated.
  
  The figure-3 illustrates an environment (DVR enabled). The use case is
  listed below:
  
  Use Case 2
  Tenant-1 creates Network-1 and Tenant-2 creates Network-2.
  Tenant-1 creates Subnet-1 belonging to Network-1 and Tenant-2 creates Subnet-2 belonging to Network-2.
  Tenant-1 creates a distributed virtual router DVR-1 and Router-1 is the distributed router on compute-1. Tenant-2 creates a distributed virtual router DVR-2 and Router-2 is the distributed router on compute-2.
  Tenant-1 links the DVR-1 to the external provider network. Tenant-2 links the DVR-2 to the external provider network.
  Tenant-1 links the DVR-1 to the Subnet-1 and Tenant-2 links DVR-2 to the Subnet-2.
  Tenant-1 creates VM-1 in Subnet-1 and Tenant-2 creates VM-2 in Subnet-2.
  Tenant-1 creates FloatingIP-1 and Tenant-2 creates FloatingIP-2.
  Tenant-1 associates VM-1 with FloatingIP-1 and Tenant2 associates VM-2 with FloatingIP-2.
  VM-1 communicates VM-2 by floating IP. For example: VM-1 pings FloatingIP-2 for the first time.
  
-                                        (Attached in the comment)
-                                               Figure-3
+                          (Attached in the comment)
+                                  Figure-3
  
  VM-1 has the IP address “10.0.0.1” which is the IP address of Port1 and
  VM-2 has the IP address “190.0.0.2” which is the IP address of Port2.
  FloatingIP-1 has the IP address “182.34.4.5” which is the IP address of
  Port5 and FloatingIP-2 has the IP address “182.34.4.6” which is the IP
  address of Port6. When a floating IP is attached to a VM, the L3 agent
  will create a FIP namespace (If one does not already exist) for the
  external network that the FIP belongs to. After the step 8, FIP-1 and
  FIP-2 will be created. Port9 is FIP-1 floating IP agent gateway and
  Port10 is FIP-2 floating IP agent gateway. The MAC address of Port9 is
  “fa:16:3e:e9:87:24” and the MAC address of Port10 is
  “fa:16:3e:e7:86:db”.
  
  VM-1 and VM-2 reside on different networks and communicate via their
  respective floating IP addresses. When VM-1 pings FloatingIP-2 for the
  first time, it needs to know the MAC address for FloatingIP-2. Thus ARP
  request is sent out. And the MAC address “fa:16:3e:e7:86:db” of FIP-2
  floating IP agent gateway will be answered. If the FDB is prepopulated,
  the ARP request can be avoided. For DVR use case, (host_ip,
  floatingip_agent_gateway_mac_address, floating_ip_address) should be
  prepopulated.
  
  Proposed Change
  ==================================================================
  The idea is that advertising the FDBs for floating IP when the FIP status changes to "ACTIVE" and withdraw the FDBs for floating IP whenever the status is set to "DOWN" or the resource is deleted or disassociated.
  
  Function _notify_fip_status will be added to send an event after
  updating floating IPs.  Function _delete_floatingip should be modified
  to use _notify_fip_status to notify the floating IP status. Function
  _update_fip_assoc is used by function _create_floatingip and
  _update_floatingip. Both functions will send events after updating
  floating IP with the result from _update_fip_assoc. Thus we can just
  insert the status of floating IP into the result of _update_fip_assoc.
  Function disassociate_floatingips already sends event out after updating
  floating IP. However after disassociating floating IPs, the router_id
  and fixed_port_id both are None. Thus need to insert floating IP status,
  last_known_router_id and last_fixed_port_id into the event.
  
  A class L3RouterL2PopMixin should be added to process the event sent
  after updating floating IP. This class should subscribe the event and
  register the callback to l2pop mechanism driver to extend the l2pop FDBs
  (Depends on RFE: https://bugs.launchpad.net/neutron/+bug/1793653). Thus
  Callback l3_fdb_extend_func should be added. Function
  handle_fip_status_update should be added to process the event and send
  the l2pop FDBs out. For non-DVR, (host_ip, router_gateway_mac_address,
  floating_ip_address) should be prepopulated. For DVR, (host_ip,
  floatingip_agent_gateway_mac_address, floating_ip_address) should be
  prepopulated. What’s more, some other functions used by the functions
  described above should be added.
  
  All changes can be viewed through the link below:
  https://review.openstack.org/#/c/611261/
  https://review.openstack.org/#/c/611284/
  
  Data Model Impact
  ============================================================
  None
  
  REST API Impact
  ============================================================
  None
  
  Command Line Client Impact
  ============================================================
  None
  
  Other Impact
  ============================================================
  None
  
  Other Deployer Impact
  ============================================================
  None
  
  Performance Impact
  ============================================================
  Performance testing should be conducted to see test the overhead of adding more information to FDB.
  
  Implementation
  Assignee(s)
  
  Work Items
  ===========================================================
  Add function _notify_fip_status to neutron/db/l3_db.py and modify some existing functions in l3_db.py.
  Add class L3RouterL2PopMixin to neutron/services/l3_router/service_providers/l2pop.py
  Add related tests.
  
  Dependencies
  ============================================================
  Need the RFE “Enable other subprojects to extend l2pop FDB information” merged in OpenStack. This RFE enables other subprojects to extend l2pop FDB information. We need to add floating IP related information to l2pop FDB. Thus we need to use the ability provided by the RFE. The link for RFE is below:
  https://bugs.launchpad.net/neutron/+bug/1793653
  
  Testing
  ============================================================
  Unit tests are necessary.
  
  Documentation Impact
  ============================================================
  None.
  
  References
  ============================================================
  [1] https://github.com/openstack/neutron/tree/master/neutron/plugins/ml2/drivers/l2pop
  [2] https://wiki.openstack.org/wiki/L2population_blueprint

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1803494

Title:
  [RFE] Add l2pop support for floating IP resources

Status in neutron:
  New

Bug description:
  Layer 2 population (l2pop) mechanism driver implements the ML2 driver
  to improve open source plugins overlay implementations (VXLAN with
  Linux bridge and GRE/VXLAN with OVS)[1]. L2pop avoid the broadcast in
  MAC learning and ARP resolution by prepopulate the bridge forwarding
  table[2]. However l2pop doesn’t have support for floating IP
  resources. If the floating IP resources can be prepopulated, the
  broadcast for scenarios when two VM instances, residing on different
  networks, communicate via their respective FIP addresses can be
  avoided.

  Problem Description
  ==========================================================
  Figure-1 illustrates the scenarios for floating IP. The IP address “182.34.4.2” in Port3 is the IP address in floating IP resources. When the client in the external network tries to access VM1, the destination IP “182.34.4.2” is replaced by the IP address “10.0.0.3” of the Port1. Notice that the IP address of Port1 is the IP address of VM1. When VM1 send packets back to client, the source IP “10.0.0.3” will be replaced by “182.34.4.2”.

                           (Attached in the comment)
                                  Figure-1
                         Port1 10.0.0.3, Port2 10.0.0.1
                         Port3 182.34.4.2, Port4 188.34.4.1

  When users want to use floating IP, they should first require
  allocating a floating IP from floating IP pool or choose a pre
  allocated floating IP. Allocating floating IP will create a new port
  and also updates the new port. Creating port will never trigger l2pop
  but updating port will trigger l2pop on the condition that the port’s
  new status is ACTIVE or DOWN. However the status of the port for
  floating IP will always be N/A. Thus allocating floating IP won’t
  trigger l2pop.

  After getting the available floating IP, users can require to
  associate the VM and the floating IP. Associating the IP address of
  the VM with the floating IP only updates the floating IP object and
  doesn’t update the port for floating IP. Thus associating the VM and
  the floating IP won’t trigger l2pop.

  Based on the above analysis, the FDB of floating IP is not
  prepopulated. It seems that to we can simply change the status of
  Port3 from N/A to ACTIVE/DOWN to prepopulate the pair (MAC, IP) of
  Port3 . But we can’t do that because the MAC address of Port3 is never
  used. In the non-DVR scenario, the MAC address of router gateway will
  be replied to answer the ARP request for floating IP. In the DVR
  scenario, the MAC address of floating IP agent gateway will be replied
  to answer the ARP request for floating IP.

  In the following use case, ARP request will be sent out to query the
  MAC address related to the specific floating IP. Figure-2 illustrates
  an environment (DVR disabled) that there are two network nodes and two
  compute nodes.

                           (Attached in the comment)
                                    Figure-2
                        Port1 10.0.0.1, Port2 198.0.0.2
                        Port5 182.34.4.5, Port6 182.34.4.6

  Use Case 1
  Tenant-1 creates Network-1 and Tenant-2 creates Network-2.
  Tenant-1 creates Subnet-1 belonging to Network-1 and Tenant-2 creates Subnet-2 belonging to Network-2.
  Tenant-1 creates Router-1 and links the Router-1 to the external provider network. Tenant-2 creates Router-2 and links the Router-2 to the external provider network.
  Tenant-1 links the Router-1 to the Subnet-1 and Tenant-2 links Router-2 to the Subnet-2.
  Tenant-1 creates VM-1 in Subnet-1 and Tenant-2 creates VM-2 in Subnet-2.
  Tenant-1 creates FloatingIP-1 and Tenant-2 creates FloatingIP-2.
  Tenant-1 associates VM-1 with FloatingIP-1 and Tenant2 associates VM-2 with FloatingIP-2.
  VM-1 communicates VM-2 by floating IP. For example: VM-1 pings FloatingIP-2 for the first time.

  VM-1 has the IP address “10.0.0.1” which is the IP address of Port1
  and VM-2 has the IP address “198.0.0.2” which is the IP address of
  Port2. FloatingIP-1 has the IP address “182.34.4.5” and FloatingIP-2
  has the IP address “182.34.4.6”(The related ports are not drawn). The
  MAC address of Router-1 gateway(Gateway-1) is “fa:16:3e:1b:ee:2b” and
  the MAC address of Router-2 gateway(Gateway-2) is “fa:16:3e:ab:cf:34”.

  VM-1 and VM-2 reside on different networks and communicate via their
  respective floating IP addresses. When VM-1 pings FloatingIP-2 for the
  first time, it needs to know the MAC address for FloatingIP-2. Thus
  ARP request is sent out. And the MAC address “fa:16:3e:ab:cf:34” of
  Gateway-2 will be answered. If the FDB is pre-populated, the ARP
  request can be avoided. For non-DVR use case, (host_ip,
  router_gateway_mac_address, floating_ip_address) should be
  prepopulated.

  The figure-3 illustrates an environment (DVR enabled). The use case is
  listed below:

  Use Case 2
  Tenant-1 creates Network-1 and Tenant-2 creates Network-2.
  Tenant-1 creates Subnet-1 belonging to Network-1 and Tenant-2 creates Subnet-2 belonging to Network-2.
  Tenant-1 creates a distributed virtual router DVR-1 and Router-1 is the distributed router on compute-1. Tenant-2 creates a distributed virtual router DVR-2 and Router-2 is the distributed router on compute-2.
  Tenant-1 links the DVR-1 to the external provider network. Tenant-2 links the DVR-2 to the external provider network.
  Tenant-1 links the DVR-1 to the Subnet-1 and Tenant-2 links DVR-2 to the Subnet-2.
  Tenant-1 creates VM-1 in Subnet-1 and Tenant-2 creates VM-2 in Subnet-2.
  Tenant-1 creates FloatingIP-1 and Tenant-2 creates FloatingIP-2.
  Tenant-1 associates VM-1 with FloatingIP-1 and Tenant2 associates VM-2 with FloatingIP-2.
  VM-1 communicates VM-2 by floating IP. For example: VM-1 pings FloatingIP-2 for the first time.

                           (Attached in the comment)
                                   Figure-3

  VM-1 has the IP address “10.0.0.1” which is the IP address of Port1
  and VM-2 has the IP address “190.0.0.2” which is the IP address of
  Port2. FloatingIP-1 has the IP address “182.34.4.5” which is the IP
  address of Port5 and FloatingIP-2 has the IP address “182.34.4.6”
  which is the IP address of Port6. When a floating IP is attached to a
  VM, the L3 agent will create a FIP namespace (If one does not already
  exist) for the external network that the FIP belongs to. After the
  step 8, FIP-1 and FIP-2 will be created. Port9 is FIP-1 floating IP
  agent gateway and Port10 is FIP-2 floating IP agent gateway. The MAC
  address of Port9 is “fa:16:3e:e9:87:24” and the MAC address of Port10
  is “fa:16:3e:e7:86:db”.

  VM-1 and VM-2 reside on different networks and communicate via their
  respective floating IP addresses. When VM-1 pings FloatingIP-2 for the
  first time, it needs to know the MAC address for FloatingIP-2. Thus
  ARP request is sent out. And the MAC address “fa:16:3e:e7:86:db” of
  FIP-2 floating IP agent gateway will be answered. If the FDB is
  prepopulated, the ARP request can be avoided. For DVR use case,
  (host_ip, floatingip_agent_gateway_mac_address, floating_ip_address)
  should be prepopulated.

  Proposed Change
  ==================================================================
  The idea is that advertising the FDBs for floating IP when the FIP status changes to "ACTIVE" and withdraw the FDBs for floating IP whenever the status is set to "DOWN" or the resource is deleted or disassociated.

  Function _notify_fip_status will be added to send an event after
  updating floating IPs.  Function _delete_floatingip should be modified
  to use _notify_fip_status to notify the floating IP status. Function
  _update_fip_assoc is used by function _create_floatingip and
  _update_floatingip. Both functions will send events after updating
  floating IP with the result from _update_fip_assoc. Thus we can just
  insert the status of floating IP into the result of _update_fip_assoc.
  Function disassociate_floatingips already sends event out after
  updating floating IP. However after disassociating floating IPs, the
  router_id and fixed_port_id both are None. Thus need to insert
  floating IP status, last_known_router_id and last_fixed_port_id into
  the event.

  A class L3RouterL2PopMixin should be added to process the event sent
  after updating floating IP. This class should subscribe the event and
  register the callback to l2pop mechanism driver to extend the l2pop
  FDBs (Depends on RFE:
  https://bugs.launchpad.net/neutron/+bug/1793653). Thus Callback
  l3_fdb_extend_func should be added. Function handle_fip_status_update
  should be added to process the event and send the l2pop FDBs out. For
  non-DVR, (host_ip, router_gateway_mac_address, floating_ip_address)
  should be prepopulated. For DVR, (host_ip,
  floatingip_agent_gateway_mac_address, floating_ip_address) should be
  prepopulated. What’s more, some other functions used by the functions
  described above should be added.

  All changes can be viewed through the link below:
  https://review.openstack.org/#/c/611261/
  https://review.openstack.org/#/c/611284/

  Data Model Impact
  ============================================================
  None

  REST API Impact
  ============================================================
  None

  Command Line Client Impact
  ============================================================
  None

  Other Impact
  ============================================================
  None

  Other Deployer Impact
  ============================================================
  None

  Performance Impact
  ============================================================
  Performance testing should be conducted to see test the overhead of adding more information to FDB.

  Implementation
  Assignee(s)

  Work Items
  ===========================================================
  Add function _notify_fip_status to neutron/db/l3_db.py and modify some existing functions in l3_db.py.
  Add class L3RouterL2PopMixin to neutron/services/l3_router/service_providers/l2pop.py
  Add related tests.

  Dependencies
  ============================================================
  Need the RFE “Enable other subprojects to extend l2pop FDB information” merged in OpenStack. This RFE enables other subprojects to extend l2pop FDB information. We need to add floating IP related information to l2pop FDB. Thus we need to use the ability provided by the RFE. The link for RFE is below:
  https://bugs.launchpad.net/neutron/+bug/1793653

  Testing
  ============================================================
  Unit tests are necessary.

  Documentation Impact
  ============================================================
  None.

  References
  ============================================================
  [1] https://github.com/openstack/neutron/tree/master/neutron/plugins/ml2/drivers/l2pop
  [2] https://wiki.openstack.org/wiki/L2population_blueprint

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1803494/+subscriptions


Follow ups