cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Funs Kessen <>
Subject Re: Third party VR / L2 support
Date Tue, 09 Jun 2015 09:55:49 GMT
Hi Christian and Paul,

I agree that the VR/VPC construct could do with some improvements, the biggest being that
it should actually be api driven and allow for more flexible networking/services combined
with scale out itself (we’re looking into this actually). All of these things bring along
their own problems and should be tackled piece by piece, if we’d want to be efficient we
should first blot out the API and then start pushing services in, which is difficult at the
speed it is moving at.

The driver model in Cloudstack already supports the decoupling of services via "network service
providers" (plugins) and ties in with the way the “network service offerings" work with
"service capabilities" and "supported services". At SBP we use NSX-mh for the service “Connectivity”,
we could add “SourceNat”, “StaticNat” and “Port Forwarding” to this for NSX if
we want to, but decided to leave that in the VR back then as these services were rather new
in NSX. My point being that you can already mix and match things and are not stuck with the
VR/VPC, and you can actually use devices on that level if need be, if you create the service
offerings for them.
At the moment anyone can already create a plugin that exposes a single functionality or multiple,
and expose that as a service that is offered, examples of these are the Palo-Alto, SRX, F5,
Netscaler, Cisco VNMC, NSX and Nuage. I’m not saying it’s simple or easy, but if you know
the API of what you want to integrate with you can. 
The construction of the plugin module has its own unique challenges, and I agree with John
Burwell (Shape Blue) and Paul that we need to change the way this all hangs together if we
want more flexibility and ease of integration in the future.

BGP is brought in for use with IPv6,  the first code for that has just gone in from Suresh
via Wilder. As that runs on top of Quagga you could do OSPF with that too. This again leads
me to believe we really need to change the way the RV/VPC receives configuration, I’ve spoken
to a big Cloudstack user, whom also contributes, that wants to be able to do more with HaProxy,
read full configuration freedom, and after hearing this and bumping my head against it in
the past it made perfect sense to me.

On the topic of L2 networking we’re bridging in and out a lot of networks at the moment
for “Enterprise” production customers. Ranging from legacy environments to cloud environments
or environments where we have full cloud workloads but also need physical iron due to “regulatory
requirements” or because there is no viable alternative yet (or we haven’t made a plugin
that exposes that functionality from another device/VM/container that can be placed in a service
offering etc). I think in our case L2 is not always a requirement for all areas as such and
I’d prefer L3 in most cases where viable. We solved things that way, the L2 way, because
that was our frame of mind, although it may be a requirement in your case.



> On 09 Jun 2015, at 10:27, Paul Angus <> wrote:
> Hi Christian,
> This is a feature put forward by myself.  As a non-developer I can come up with these
things and throw them over the wall to the developers and pretend I don't know how complicated
it is :)
> In summary, it requires a few other pieces of the roadmap to be in place. The high level
plan is to move ever closer to a driver/plugin model for CloudStack.  For this feature we
need to fully separate the VR plugin code from the 'core' code and create strong contracts
for VR commands/responses.  Then 'anyone' can create and maintain drivers for any type of
router/firewall/vpn endpoint/loadbalancer. The CloudStack community would then continue to
maintain the 'standard' VR/VPC.
> We're also developing OSPF capable and a routing-mode VPC offerings which we hope will
be in 4.6
> I'd be interested to hear how you're using  the L2 devices to see where if we can fit
it in to our 'Enterprise use' enhancements.
> Regards,
> Paul Angus
> Cloud Architect
> D: +44 20 3468 5163 |S: +44 20 3603 0540 | M: +44 7711 418 784 | T: @CloudyAngus
> -----Original Message-----
> From: Christian []
> Sent: 01 June 2015 13:26
> To:
> Subject: Third party VR / L2 support
> Hi Sebastien,
> Thank you for publishing the roadmap.
>> Replace VR with h/w (srx, asa etc)
> A question for all - What are the implications of expanding this feature to support s/w
appliances, such as the ASA/CSR 1000V ?
> This is something that I have been implementing manually to date because:
>> Improve VR, VR agent, API for VR   :)
> It involves a little bit of 'creative networking' in order to suppress the CS virtual
router. Any improvements in this area would be very useful.
> Even a QuickCloudNoServices-like offering for isolated networks would be great. I¹m
aware that this can be created manually, but I¹m not convinced that this is a supported configuration.
> Pushing this concept further, I¹d like to see support for Layer 2 isolated networks.
I use these for running virtual L2 devices under CS simply by creating dummy IP address ranges
and ignoring them. Again, I have to suppress the VR, because it¹s not needed at L2.
> I¹ve been doing a fair bit to push the limits of networking in CloudStack over the last
year using just VLANs and the standard API calls . I¹m happy to answer any questions anyone
may have.
> Best regards,
> -Christian
> --
> Christian Lafferty
> <>
> On 31/05/2015 05:08, "Sebastien Goasguen" <> wrote:
>> Hi folks,
>> Several folks on this list representing their company¹s interest shared
>> with me their fixes/features plans and hopes.
>> I believe we can use this to build a solid roadmap for our project,
>> something that we have never had.
>> I captured a lot of bullet items and tried to categorize them to start
>> building a roadmap.
>> You can see the document on our wiki at:
>> I would like to call everyone to make this page a great living document
>> that will be up to date and help us drive cloudstack forward.
>> First order of business would be to add description to each item and if
>> you are working on it or would like to help out, write your name down !
>> Cheers,
>> -Sebastien
> Find out more about ShapeBlue and our range of CloudStack related services
> IaaS Cloud Design & Build<>
> CSForge – rapid IaaS deployment framework<>
> CloudStack Consulting<>
> CloudStack Software Engineering<>
> CloudStack Infrastructure Support<>
> CloudStack Bootcamp Training Courses<>
> This email and any attachments to it may be confidential and are intended solely for
the use of the individual to whom it is addressed. Any views or opinions expressed are solely
those of the author and do not necessarily represent those of Shape Blue Ltd or related companies.
If you are not the intended recipient of this email, you must neither take any action based
upon its contents, nor copy or show it to anyone. Please contact the sender if you believe
you have received this email in error. Shape Blue Ltd is a company incorporated in England
& Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated
under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated
in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company
registered by The Republic of South Africa and is traded under license from Shape Blue Ltd.
ShapeBlue is a registered trademark.


View raw message