© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
a60fb26
(Get the code!)
> @Omer: do you think I am slowly getting at what you're hinting all along?
Yes. This is exactly it!
a) These are the scenarios I ran into when using allowed address pairs. This RFE refers only to the first two:
a.1. MACVLAN - The VM knows the packet's final destination by its destination MAC. e.g. container network within a VM
a.2. IPVLAN - The VM knows the packet's final destination by its destination IP (The MAC is the VM's). e.g. HAProxy behind Amphora VMs, as used in Octavia.
a.3. As mentioned by @Armando, load-balancing with VRRP, where both ports share the same VIP as an allowed address pair.
a.4. A port behaves as a router. By placing a subnet in a port's allowed address pair, the routing to that subnet is done via that port.
I was hoping that the clear/simple scenario would be the general case of nested ports, where one port (that is known to Neutron) is not actually bound, but reachable by sending the packet (perhaps with some mangling, e.g., adding VLAN tags, or changing the destination MAC address) to another port (also known to Neutron). This covers the three use-cases listed in the original bug description.
b) The idea to extend the trunk API was proposed due to the similarities in general behaviour (port behind port). The gist of this RFE is creating a declarative (and extensible) API for e.g. MACVLAN and IPVLAN scenarios, not necessarily enforcing this API on other features.