Latest revision as of 06:37, 25 August 2014

Neutron Dynamic Routing Use Cases

This is a short attempt to list the use cases for dynamic routing in Neutron. We’ll then attempt to find commonalities between the use cases to see where abstractions can be made and code shared in a common framework.

Multi-homed Openstack Cloud

Based on bgp-dynamic-routing

A multi-homed Openstack cloud would run a routing protocol (example BGP) against at least one router in each uplink network provider. By announcing floating IP prefixes to those peers, the Neutron network would be reachable by the rest of the internet via both paths. If the link to an uplink provider broke, the failure information would propagate to routers further up the stream, keeping the cloud reachable through the remaining healthy link. Likewise, in such a case, Neutron’s L3 router would eliminate the routes learned through the faulty link from its forwarding table, redirecting all cloud-originated traffic through the healthy link.

Routed Model for Floating IPs on External Network

This use case will allow an external network with a large public IP space to possibly span more than one L2 network. This could allow for improved scale and isolation between AZs while maintaining the appearance of a large external network where floating IPs and networks can float freely.

This use case eliminates one reason for assigning a permanent IP from the floating IP pool for each router. The router will be assigned an IP address on a private routing network. There are still some reasons remaining to assign such a permanent public IP. Default SNAT, DNS forwarding, and proxied metadata requests are among other reasons. Some of these could be modified to also use a private network but that is beyond the scope of this use case.

In the case of DVR, this model eliminates the need to allocate a public IP out of the floating ip pool for each compute node.

This use case may also include announcing public networks behind Neutron routers to an upstream router. It does not require learning routes from the upstream router.

MPLS/BGP

Note: This section is based on my own understanding of the blueprint. I would like feedback on it to be sure that I understand correctly.

This use case is described in its own blueprint. From the blueprint: "This BP implements partial RFC4364 BGP/MPLS IP Virtual Private Networks (VPNs) support for interconnecting existing network and OpenStack cloud."

This was discussed briefly in the Icehouse summit as part of VPNaaS. It could be argued that this use case is part of VPNaaS rather than dynamic routing.

VPNaaS currently has experimental implementations for IPSec and TLS. The VPN endpoint is inserted in to a neutron router. I assume that this implementation of VPNaaS will follow the same model.

Scenario 1: The Neutron Router is the CE

Following the pattern of the other VPNaaS implementations, the neutron router will play the role of a CE. A BGP peer to a PE will be established and the route_target / import_target / export_target are exchanged between with the PE as described in the last paragraph of section 4.3.1 of the RFC.

This type of VPN does not employ strong endpoint authentication or encryption to ensure the privacy of the network. Instead it relies on an established relationship between the provider and the customer and a guarantee that the connection between the two is physically secured. This has some implications on the feasibility of bringing this in to the cloud where the cloud provider is a third party distinct from the provider and the customer.

For example, consider the case where many neutron routers are connected to the same external network. Now, we connect a PE to the network with the goal to establish an MPLS/BPG link between one of the neutron routers acting as the CE to the PE. In this case, how will the provider securely determine the appropriate VRF for the customer’s traffic?

If I were the customer, I would be very nervous about using this shared external network as the “attachment circuit” for my virtual private network. I would insist on a private external network that is only accessible by my tenant. This is an extra constraint on this implementation of VPNaaS that the other implementations do not have. It already requires some configuration outside of Openstack which lessens the value of implementing any of this inside Openstack.

This type of VPN might be restricted to provider networks that are private to a tenant. This implies the need to allow routers to connect a gateway to a provider network.

Scenario 2: The VMs are the CEs

This scenario does not follow the pattern of the other VPNaaS implementations. In this scenario the CEs are the VMs themselves and the PE is connected to the same provider network. The Neutron system establishes a single BGP connection with the PE and publishes routes to all known Neutron ports on the network.