Comment 3 for bug 1525059
Revision history for this message
| Mickey Spiegel (emspiege) wrote Re: neutron router vxlan gw can't work | #3 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
I agree that this is useful. A few comments on the "how" part described above.
The underlay IP multicast group needs to be consistent across all nodes using a particular VNI. Specifying this per router means specifying the same value multiple times, and it also leaves open the possibility of misconfiguration, with inconsistent values on different routers. There are two options that seem cleaner:
1) Add the attribute to network, something like "provider:
2) Specify underlay IP multicast groups in the configuration, as is currently done for LinuxBridge:
https:/
Note that with this approach, the provider would have to know the hard coded algorithm to determine which IP multicast address goes with which VNI, so that it could configure upstream physical switches to be consistent with the Neutron routers.
Note also recent discussion on openstack-neutron IRC (12/7/15) about moving this configuration from linuxbridge_
It seems like the underlay peer IP addresses that trigger tunnel creation should be a list of external underlay peer IP addresses. For example, if the upstream physical routers use VRRP, there would be two different underlay peer IP addresses.
There are many possibilities for where to specify the underlay peer IP addresses, with different pros and cons: networks, subnets, router external gateway info, or in a configuration file. What you need to end up with at a minimum is a set of VXLAN tunnels to the underlay peer IP addresses where all upstream gateway IPs are located (union over all routers on the node, following the external gateway fixed IPs to subnets to gateway IPs). I guess having more VXLAN tunnels than you need would not be harmful, especially if underlay IP multicast groups are used for broadcasts and unknowns.