Page History

Introduction

Currently connecting multiple

Intro

Within an availability zone when application / user resources need to be shared / connected between VPC's it makes sense to connect VPC's together via SDN enabled inter-VPC routing or together can basically be achieved by using inter VPC routing via PrivateGateways or via VPN tunnels.

The current way method of enabling inter-VPC's routing connectivity between VPC's in CloudStack (4.6) is via a PrivateGateway and adding one or multiple static route(s).  The Creating a privategateway api call however is however not available/permitted for subdomain admin domain admins or non-admin users within CloudStackby the API.  This puts a burden on the root-admins to enable privategateways a PrivateGateway on VPC's that users have a user has created. Another aspect is that domain admins or non-admin users of subdomains in CloudStack do not always have the right information, such as gateway address, vlan, and ip, to use a createprivategateway create privategateway function even if users would be allowed to.  

From a usability and efficiency perspective it also does not make sense to require cloud users to a) provide this information, and b) to have to enable a privategateway PrivateGateway and to add a static route on each VPC to be connected . while a single request per connection to connect VPC X to Y and perhaps Z to X could suffice.

This design aims to propose a more functional, and for the user more simplified and efficient way of connecting multiple VPC's. The functionality would be called VPC Peering and would aim to provide a simple and efficient yet powerful interface for users to connect 2 or more VPC's to each other that effectively creates layer 3 reachability between VPC's over private ip space.

Use case

A shared resource VPC with satellite VPC's

Imagine a VPC containing company wide shared resources such as a active directory, fileservers, or other supporting systems that are managed by department Office IT for instance. Now let's say you have a trading platform VPC which is managed by an IT sourcing provider and then there's a VPC which contains finance applications which is managed by yet another 3rd party and all VPC's live in the same zone.

The 2 VPC's: trading, and finance need to access services in the office IT VPC but should not be allowed to reach each other's services. The owners of the trading and finance VPC's can then create a VPC Peering request towards the office IT VPC.  The owner of the office IT VPC can then choose to accept or reject the peering request.

...

A band of VPC's

Let's say you run a high traffic high risk app and need to guarantee maximum availability and you've built 3 VPC's each containing services that together form a geo cluster. Each VPC in this circle must be able to reach services in the other VPCs.  In this example each VPC will have 2 VPC peering connections.

Requirements

Limits

• VPC peering connections are not possible between VPC's with matching or overlapping VPC CIDR blocks
• VPC peering connections are not transitive in the sense that VPC's will not automatically gain access to a 3rd VPC even when the VPC that is peered too has a peering connection with that 3rd VPC.
• VPC peering connections are only possible within a CloudStack region
• There is a maximum amount of pending VPC peering requests per VPC
• There is a maximum amount of active VPC peering connections
• There is an expiry time on the pending VPC peering requests

Procesflow

Domain model

Authorization

...

Implementation

UI

API

• createVPCPeeringConnection
• listVPCPeeringConnections
• deleteVPCPeeringConnection
• acceptVPCPeeringConnection
• rejectVPCPeeringConnection

Datamodel

Marvin

...

Network providers

• VMWare NSX
• OVS
• Physical (VLAN based)

...

Tests