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 want network interconnections with the following properties: on demand on demand + + ? private addressing private addressing & isolation & isolation + + avoid the overhead of avoid the overhead of packet encryption … between NFV PoPs packet encryption 2 and/or datacenters…
Doing this with ? an orchestrator ? 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 VM VM VM VM VM VM … between NFV PoPs 3 and/or datacenters…
Let's extend “User facing” API : let a project defne that a local Neutron's API ! Router is linked to a Router on another Openstack => defne the link symmetrically on both sides ( , ) “Neutron-Neutron” API: ● check if the reverse link is defned on the other side bis: not yet ● bis: OK ! ● ● expose/retrieve the technical details on how to do realize connectivity ( ) parameters vary depending ● bis on the technique to use Neutron Neutron At the end of the exchange... bis Each side has the necessary information and can setup the interconnection ( ) 4 VM VM VM VM VM VM
Multitenancy & need for network isolation imply that we address trust questions 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 5
Multiple interconnection techniques are possible... Example with BGP VPNs Requirements for a ● technique to be applicable How ? ● each side provides the routing identifer which the other Provide isolated network – – side will use to import routes for this interconnection connectivity connectivity realized whether as an overlay over the WAN, – or with the collaboration of WAN BGP VPN routing L2 and/or L3 ● Interoperability preferred: Benefts ? – ● Each side independently allocates identifers makes the solution applicable – => no need to coordinate the use of a common space of between two OpenStack that identifers do not use the same SDN controller solution (because BGP RTs have are structured, prefixed typically by ● an AS number) Examples Can be implemented in Neutron by reusing the existing ● – VLAN hand-of BGPVPN Interconnection API – VXLAN gateway – (the BGPVPN Interconnection API already allows ● L2GW ‑ interconnections, but not on demand because requiring the – admin to create resources) BGP VPNs – will work with Neutron ref. drivers and many SDN controllers ● ... – Applicable to both IP and Ethernet interconnects – 6
Neutron-Neutron interconnections Wrap up Allows interconnections ? ● On-demand – No need for an orchestrator – Light on packet dataplane (no IPSec) – VM VM VM VM VM VM between OpenStack instances ● 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 – Next steps ? ● Neutron Specs being redacted – Implementation to be proposed based on a PoC implementation by Orange – Service composition: reusing the existing ● 7 Neutron BGPVPN Interconnection service
Recommend
More recommend