Bug Reference

https://issues.apache.org/jira/browse/CLOUDSTACK-1532

Branch

No branch. a patch is submitted through Review Request #10970

Introduction

Currently a VPC private gateway interface can be plugged on a specific VLAN. We like to see the possibility to specify a Nicira NVP logical switch instead of a VLAN.

Purpose

Give an administrator more flexible network solutions for virtual private clouds.

References

jira ticket CLOUDSTACK-1532

Related work is nTier Apps 2.0 Features, however in this work it is choosen to add multiple gateways to a VPC, which will result in the number of interfaces on the VPC router running out. Preferably would be to add multiple routes to a single (or one of the) gateway(s). This is a new issue however.

Document History

Feature Specifications

An administrator must be able to choose a sdn based network for use in a vpc router gateway.

Use cases

One of the use cases we have for this is VPC <-> VPC connectivity (routing) within the logical space of NVP.
This functionality should then be combined with the possibility to specify more then one route on the virtual private gateway for multiple peer networks, this gives us a better manageable environment for customer networks.

The picture above speaks for itself. The vpc gateways are plugged into a lswitch on NiciraNvp. In addition to that they are on the same logical switch, which in ACS terms means they are on the same network. In cloudstack, therefore, a check must be created that checks if the net a vpc switch is plugged on is an lswitch. If it is it must not refuse to create the gateway when the network allready exists, as it does now. see multiple vpc gateways on the same network for this.

Architecture and Design description

tbd

Web Services APIs

As the gateway creates a network and the network offering for a nicira based network has a different 'Connectivity' provider then the default, a network offering must be passed as an optional argument to the createVpcGateway api call. This will be added by uuid.

The api call now accepts an vlanid. it must be loosened to also accept a broadcastUri, i.e. lswitch:<a-uuid-of-some-sort>. It makes sense to then also let it accept vlan://<number>.

DB changes

no changes are strictly needed.

It may be wise to change some columns in name and in some cases in type from 'vlan' to 'broadcast_uri'.

In the long run it makes sense too remove broadcastDomainType fields from tables that have a broadcastUri as it is encoded in it. This must be decided on a case by case basis.

UI flow

Appendix

Appendix A:

Appendix B:

  • No labels