Public bug reported: >From a compute instance with one Neutron port, depending on the destination IP >address, some traffic is destined for the Internet, while other traffic is >meant to go to a tenant VPN outside of the OpenStack region. There are many >possible reasons to have such a tenant VPN, including: 1. Connectivity to an on premises tenant site using L3VPN connectivity, similar to AWS DirectConnect or SoftLayer DirectLink 2. Connectivity between OpenStack regions, either for geographic diversity or due to specific services available in specific OpenStack regions (e.g. bare metal support) 3. Connectivity to a non-OpenStack public data center
One common use case is a web front end within the OpenStack region, connected to a back end database tier that resides outside of this OpenStack region. The web front end must be reachable from the Internet. The back end database tier must not be reachable from the Internet. Specifically, the scenario of interest involves one or more OpenStack routers, where each OpenStack router has multiple networks connecting to the outside world (1). Relying on received BGP VPN routes, the OpenStack router’s routing table is programmed, causing traffic to different destination addresses to be directed towards different networks connecting to the outside world. The intention is to leave the internal operation of OpenStack (between compute nodes, and between compute nodes and network nodes) untouched, only affecting route selection from an OpenStack router to the outside world. For this reason, this effort is targeted at BGP Dynamic Routing [1] with VPN support [2]. Note that one goal is to hide the complexity of multiple networks connecting to the outside world from OpenStack compute instances. The solution should work with OpenStack compute instances that have only one Neutron port. The solution should not impose any requirement for host routing within the compute instances. The reference implementation will use BGP EVPN Prefix Advertisement [3], based on EVPN Route Type 5 (EVPN Prefix Route) specifying a recursion through a GW IP address, linking to an EVPN Route Type 2 (MAC/IP). The data plane will use VXLAN encapsulation on the networks connecting to the outside world (2). The initial scope will be network nodes only. Subsequent enhancements will extend support to DVR. (1) How to get more than one network connecting to the outside world, onto a single OpenStack router, is currently under investigation. This is not straightforward due to the limitation of one external gateway network per OpenStack router. Currently under consideration is an approach where all but one of the networks have router:external set to false, i.e. the external gateway network connects to the internet (since that needs Floating IP functionality and possibly a default route), while networks with router:external set to false connect to tenant VPNs (no Floating IP or NAT support). If enhancements are required to allow multiple networks connecting to the outside world from a single OpenStack router, a separate RFE will be filed. (2) From an OpenStack router, if one of the networks connecting to the outside world is considered to be an external gateway network, some enhancements may be required to support VXLAN encapsulation on that external gateway network. A separate RFE will be filed, if necessary. [1] https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing [2] https://bugs.launchpad.net/neutron/+bug/1509431 [3] draft-ietf-bess-evpn-prefix-advertisement [4] http://docs.openstack.org/developer/networking-bgpvpn/ ** Affects: neutron Importance: Undecided Status: New ** Tags: rfe -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1509436 Title: Add BGP Listener Support to BGP Dynamic Routing with VPN, for Dynamic Separation of Internet and Tenant External Traffic Status in neutron: New Bug description: From a compute instance with one Neutron port, depending on the destination IP address, some traffic is destined for the Internet, while other traffic is meant to go to a tenant VPN outside of the OpenStack region. There are many possible reasons to have such a tenant VPN, including: 1. Connectivity to an on premises tenant site using L3VPN connectivity, similar to AWS DirectConnect or SoftLayer DirectLink 2. Connectivity between OpenStack regions, either for geographic diversity or due to specific services available in specific OpenStack regions (e.g. bare metal support) 3. Connectivity to a non-OpenStack public data center One common use case is a web front end within the OpenStack region, connected to a back end database tier that resides outside of this OpenStack region. The web front end must be reachable from the Internet. The back end database tier must not be reachable from the Internet. Specifically, the scenario of interest involves one or more OpenStack routers, where each OpenStack router has multiple networks connecting to the outside world (1). Relying on received BGP VPN routes, the OpenStack router’s routing table is programmed, causing traffic to different destination addresses to be directed towards different networks connecting to the outside world. The intention is to leave the internal operation of OpenStack (between compute nodes, and between compute nodes and network nodes) untouched, only affecting route selection from an OpenStack router to the outside world. For this reason, this effort is targeted at BGP Dynamic Routing [1] with VPN support [2]. Note that one goal is to hide the complexity of multiple networks connecting to the outside world from OpenStack compute instances. The solution should work with OpenStack compute instances that have only one Neutron port. The solution should not impose any requirement for host routing within the compute instances. The reference implementation will use BGP EVPN Prefix Advertisement [3], based on EVPN Route Type 5 (EVPN Prefix Route) specifying a recursion through a GW IP address, linking to an EVPN Route Type 2 (MAC/IP). The data plane will use VXLAN encapsulation on the networks connecting to the outside world (2). The initial scope will be network nodes only. Subsequent enhancements will extend support to DVR. (1) How to get more than one network connecting to the outside world, onto a single OpenStack router, is currently under investigation. This is not straightforward due to the limitation of one external gateway network per OpenStack router. Currently under consideration is an approach where all but one of the networks have router:external set to false, i.e. the external gateway network connects to the internet (since that needs Floating IP functionality and possibly a default route), while networks with router:external set to false connect to tenant VPNs (no Floating IP or NAT support). If enhancements are required to allow multiple networks connecting to the outside world from a single OpenStack router, a separate RFE will be filed. (2) From an OpenStack router, if one of the networks connecting to the outside world is considered to be an external gateway network, some enhancements may be required to support VXLAN encapsulation on that external gateway network. A separate RFE will be filed, if necessary. [1] https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing [2] https://bugs.launchpad.net/neutron/+bug/1509431 [3] draft-ietf-bess-evpn-prefix-advertisement [4] http://docs.openstack.org/developer/networking-bgpvpn/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1509436/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
