- 1 Overview
- 2 Use Cases
- 3 Implementation overview
- 4 Data Model Changes
- 5 Configuration Variables
- 6 API’s
- 7 Requirements
- 8 Not yet addressed
When a network is created, a broadcast domain is available to plug ports. It should be interesting to proposed an option on the network creation that enable the isolation between ports in a same broadcast domain (network), similar to a common use of private VLANs with isolated port technologies (RFC 3069 and RFC 5517). This prevents communication between VMs on the same logical switch. The promiscuous port will be the gateway port by default. And to enable the traffic between isolated port, a local proxy ARP/NDP can be enable.
This functionality could address the use cases where we create a shared network between tenants, for example.
And this should also works with a provider network, if we want to create shared provider network to carry the public access in our Cloud for all tenants. In this case, the local proxy ARP is carried by a physical equipment.
This isolation between ports can be realized by set up this flows rules on each isolated ports
- ARP broadcast modifies to unicast MAC address of the local APR proxy (MAC address of the l3 agent gateway port for a totally virtualized network or a specified MAC address of the physical network gateway for a provider network).
- Multicast bootp traffic modifies to unicast MAC address of the DHCP server (MAC address of the DHCP agent port for a totally virtualized network or a specified MAC address of the physical DHCP server for a provider network)
- Authorize traffic for the unicast gateway (local proxy ARP) MAC address
- Drop all other traffics
When a network is created, a boolean could be specified to isolate ports.
If a gateway is set up on the subnet of the network, a local proxy ARP is enabled on the gateway to enable l3 traffic between ports.
If a gateway and/or DHCP ports are set up on the subnet of the network or if MAC addresses for local proxy ARP and/or DHCP server are set (through API), rules #1 and/or #2 are set to filter flows of each network's port.
Local Proxy ARP
The Linux kernel proposes the possibility to enable a proxy ARP which can replies back to the same interface (/proc/sys/net/ipv4/conf/<interface>/proxy_arp_pvlan)
With OVS driver in tunneling mode we can use the open flow tools to NAT flows with mod_dl_dst action and drop flows with drop action.
With LB driver and the OVS driver in VLAN mode, we can use Linux-based bridging firewall ebtables
The implementation of this extension will roughly follow the next plan:
- API modifications and database model with related code
- Implement support of proxy ARP on the L3 agent
- Implement support in OVS plugin
- Implement support in LB plugin
- Add CLI new attributes support
Data Model Changes
The database model extension is shown in the diagram below. It adds one new tables to the quantum database of the plugin.
- To binding the activation of the isolated function with a network;
- To binding the activation of the promiscuous port on the subnet. If a MAC address is provide, the promiscuous port on the subnet is activated.
The isolated network extends the Quantum API by creating new attributes. No new resources or actions are defined.
The network structure will be extended with 3 new attributes each in the isolated network namespace:
Enable or disable the isolation of ports on the network. It's a Boolean and by default, it sets to False.
Specified MAC address of an external gateway where the local proxy ARP runs. It's a String set to None by default. If it's None, the MAC address of the subnet's gateway is used.
Specified MAC address of an external DHCP server. It's a String set to None by default. If it's None, the MAC address of the subnet's DHCP server is used.
By default isolated network can only be created or deleted by admin users. The isolated network attributes are also only visible, and can only be updated by admins.
This extension will be added to the LB and OVS plugin to begin. The ML2 driver will be supported in a second step.
To enable the local proxy ARP, a modification on the l3 agent should occur.
The network-create and the network-update operations will need to support the new isolated network attributes. The quantum client application need to be updated.
Not yet addressed
IPv6 Proxies NDP messages
Not yet define but actually, the OpenStack networking l3 agent does not support IPv6