Neutron-Neutron interconnections
Thomas Morin
VM VM VM VM VM VM
? VM VM VM VM VM VM VM VM VM VM VM VM How to - - PowerPoint PPT Presentation
Neutron-Neutron interconnections Thomas Morin ? VM VM VM VM VM VM VM VM VM VM VM VM How to interconnect two OpenStack deployments ? ( two or more OpenStack ? two regions ?) Between datacenters or between NFV POPs, you may
Thomas Morin
VM VM VM VM VM VM
2
How to interconnect two OpenStack deployments ?
( …… two or more OpenStack ? two regions ?)
Between datacenters or between NFV POPs, you may want network interconnections with the following properties:
VM VM VM VM VM VM
… between NFV PoPs and/or datacenters…
private addressing & isolation private addressing & isolation
avoid the overhead of packet encryption avoid the overhead of packet encryption
3
Doing this with an orchestrator ?
VM VM VM VM VM VM
… between NFV PoPs and/or datacenters…
not always possible... not always wanted...
contexts where there isn't a single organization involved
need to expose an API to the projects
extra complexity
4
“Neutron-Neutron” API:
is defned on the other side
technical details on how to do realize connectivity ()
At the end of the exchange... Each side has the necessary information and can setup the interconnection () “User facing” API : let a project defne that a local Router is linked to a Router on another Openstack => defne the link symmetrically
Let's extend Neutron's API !
VM VM VM VM VM VM
Neutron Neutron
bis bis
5
Trusting that the interconnection preserves isolation
Goal:
no interconnection setup unless explictly asked by each project/tenant
How ?
Interconnect if and only if both sides agree (symmetric link check)
Each OpenStack instance has to trust the packets from the other OpenStack instances
This proposal is for organizations/entities trusting each other, and trusting the network used to carry interconnections
Authenticating Neutron-Neutron API exchanges
Each Neutron component on each side needs credentials to talk to the other side
Not to act as the project/tenant
Not to act as admin
Only need creds for a specifc role with read-only access to interconnection info
Keystone federation is not strictly needed for functionality, but will be in practice necessary to avoid too much confguration overhead
Multitenancy & need for network isolation imply that we address trust questions
6
Multiple interconnection techniques are possible...
technique to be applicable
–
Provide isolated network connectivity
–
Interoperability preferred:
makes the solution applicable between two OpenStack that do not use the same SDN controller solution
–
VLAN hand-of
–
VXLAN gateway
–
L2GW
–
BGP VPNs
–
...
Example with BGP VPNs
–
each side provides the routing identifer which the other side will use to import routes for this interconnection
–
connectivity realized whether as an overlay over the WAN,
–
Each side independently allocates identifers => no need to coordinate the use of a common space of identifers
an AS number)
–
Can be implemented in Neutron by reusing the existing BGPVPN Interconnection API
interconnections, but not on demand because requiring the ‑ admin to create resources)
–
Applicable to both IP and Ethernet interconnects
7
Wrap up
–
On-demand
–
No need for an orchestrator
–
Light on packet dataplane (no IPSec)
–
two OpenStack instances or more
–
between trusting entities
–
inter‑clouds, inter‑regions, inter‑DCs, between NFV POPs
–
including when these instances use a diferent SDN solution
–
Neutron Specs being redacted
–
Implementation to be proposed based on a PoC implementation by Orange
Neutron BGPVPN Interconnection service
VM VM VM VM VM VM