ºÝºÝߣ

ºÝºÝߣShare a Scribd company logo

OpenStack Neutron-Neutron interconnections

?
?
Thomas Morin
Thomas Morin

[ lightning talk done during the OpenStack Summit, Sydney Nov. 2018 ] Provide network interconnections between Openstack clouds ? between regions ? DC pods ? Neutron today offers floating IPs and IPSec VPNaaS. However these are not always good enough: sometimes private addressing and network isolation is needed, but avoiding the overhead of IPSec encryption would be preferable. How to avoid the overhead of adding an orchestrator ? Solutions also exists to create interconnections in ways specific to each overlay technology or SDN backends, but they will require central coordination via an orchestrator (not always possible), and sometimes also the provisioing of network devices (not always simple). "Neutron talking to Neutron" This talk exposes and showcases a solution where Openstack projects define their network interconnection needs across regions or clouds, and Neutron endpoints in the different regions coordinate together in a simple way to setup these private isolated interconnections. Without orchestration nor network device configuration.

1 of 7
Download to read offline
Neutron-Neutron interconnections 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: on demandon demand 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: ¡ñ check if the reverse link is defined on the other side ¡ñ ?bis: not yet ? ¡ñ ?bis: OK ! ? ¡ñ expose/retrieve the technical details on how to do realize connectivity (?) ¡ñ parameters vary depending on the technique to use At the end of the exchange... Each side has the necessary information and can setup the interconnection (?) ¡°User facing¡± API : let a project define that a local Router is linked to a Router on another Openstack => define the link symmetrically on both sides (?,?) 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 specific 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 configuration overhead Multitenancy & need for network isolation imply that we address trust questions
6 Multiple interconnection techniques are possible... ¡ñ Requirements for a technique to be applicable ¨C Provide isolated network connectivity ¡ñ L2 and/or L3 ¨C Interoperability preferred: makes the solution applicable between two OpenStack that do not use the same SDN controller solution ¡ñ Examples ¨C VLAN hand-off ¨C VXLAN gateway ¨C L2GW ¨C BGP VPNs ¨C ... Example with BGP VPNs ¡ñ How ? ¨C each side provides the routing identifier which the other side will use to import routes for this interconnection ¨C connectivity realized whether as an overlay over the WAN, or with the collaboration of WAN BGP VPN routing ¡ñ Benefits ? ¨C Each side independently allocates identifiers => no need to coordinate the use of a common space of identifiers ¡ñ (because BGP RTs have are structured, prefixed typically by an AS number) ¨C Can be implemented in Neutron by reusing the existing BGPVPN Interconnection API ¡ñ (the BGPVPN Interconnection API already allows interconnections, but not on demand because requiring the?demand because requiring the admin to create resources) ¡ñ will work with Neutron ref. drivers and many SDN controllers ¨C Applicable to both IP and Ethernet interconnects
7 Neutron-Neutron interconnections Wrap up ¡ñ Allows interconnections ¨C On-demand ¨C No need for an orchestrator ¨C Light on packet dataplane (no IPSec) ¡ñ between OpenStack instances ¨C two OpenStack instances or more ¨C between trusting entities ¨C inter clouds, inter regions, inter DCs, between NFV POPs?demand because requiring the ?demand because requiring the ?demand because requiring the ¨C including when these instances use a different SDN solution ¡ñ Next steps ? ¨C Neutron Specs being redacted ¨C Implementation to be proposed based on a PoC implementation by Orange ¡ñ Service composition: reusing the existing Neutron BGPVPN Interconnection service VM VM VM VM VM VM ?

More Related Content

OpenStack Neutron-Neutron interconnections

  • 2. 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: on demandon demand 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. 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. 4 ¡°Neutron-Neutron¡± API: ¡ñ check if the reverse link is defined on the other side ¡ñ ?bis: not yet ? ¡ñ ?bis: OK ! ? ¡ñ expose/retrieve the technical details on how to do realize connectivity (?) ¡ñ parameters vary depending on the technique to use At the end of the exchange... Each side has the necessary information and can setup the interconnection (?) ¡°User facing¡± API : let a project define that a local Router is linked to a Router on another Openstack => define the link symmetrically on both sides (?,?) Let's extend Neutron's API ! VM VM VM VM VM VM Neutron Neutron ? ? ? ? ? ?bis ? ?bis?
  • 5. 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 specific 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 configuration overhead Multitenancy & need for network isolation imply that we address trust questions
  • 6. 6 Multiple interconnection techniques are possible... ¡ñ Requirements for a technique to be applicable ¨C Provide isolated network connectivity ¡ñ L2 and/or L3 ¨C Interoperability preferred: makes the solution applicable between two OpenStack that do not use the same SDN controller solution ¡ñ Examples ¨C VLAN hand-off ¨C VXLAN gateway ¨C L2GW ¨C BGP VPNs ¨C ... Example with BGP VPNs ¡ñ How ? ¨C each side provides the routing identifier which the other side will use to import routes for this interconnection ¨C connectivity realized whether as an overlay over the WAN, or with the collaboration of WAN BGP VPN routing ¡ñ Benefits ? ¨C Each side independently allocates identifiers => no need to coordinate the use of a common space of identifiers ¡ñ (because BGP RTs have are structured, prefixed typically by an AS number) ¨C Can be implemented in Neutron by reusing the existing BGPVPN Interconnection API ¡ñ (the BGPVPN Interconnection API already allows interconnections, but not on demand because requiring the?demand because requiring the admin to create resources) ¡ñ will work with Neutron ref. drivers and many SDN controllers ¨C Applicable to both IP and Ethernet interconnects
  • 7. 7 Neutron-Neutron interconnections Wrap up ¡ñ Allows interconnections ¨C On-demand ¨C No need for an orchestrator ¨C Light on packet dataplane (no IPSec) ¡ñ between OpenStack instances ¨C two OpenStack instances or more ¨C between trusting entities ¨C inter clouds, inter regions, inter DCs, between NFV POPs?demand because requiring the ?demand because requiring the ?demand because requiring the ¨C including when these instances use a different SDN solution ¡ñ Next steps ? ¨C Neutron Specs being redacted ¨C Implementation to be proposed based on a PoC implementation by Orange ¡ñ Service composition: reusing the existing Neutron BGPVPN Interconnection service VM VM VM VM VM VM ?