cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebgoa <>
Subject Re: Third party VR / L2 support
Date Fri, 12 Jun 2015 11:25:47 GMT

On Jun 12, 2015, at 11:13 AM, Christian <> wrote:

> Thank you all for your views and comments. I agree with everything said
> when it is positioned under today’s business-as-usual cloud compute.
> Perhaps I should put some context around my thoughts.
> NFV is coming and the world is looking to deliver solid cloud networking
> solutions over the next couple of years. 90% of what I am hearing in this
> area revolves around OpenStack. I’m trying to put the case forward for
> using CloudStack.
> Yes, I can use sheer force of will to bend CloudStack into shape. I can
> ignore its insistence on using IP addresses for everything and tap
> straight into VLANs. I can also use kludges to suppress the virtual router
> and remove unwelcome DHCP services. However, I have to declare that I am
> doing these things when I present the case for CloudStack and this weakens
> my argument.
> There are some quick wins here that would help greatly in positioning
> CloudStack as a contender for running virtualised network appliances.
> Having a checkbox that flags a virtual network as Layer 2 (no IP
> addresses) would be one of them. Officially supporting a ‘No virtual
> router’ option within a Network Offering would be another.

Christian, I totally agree with you.
I was on the OPNFV mailing list couple months back and openstack was the only game in town.

So how do we get those quick wins going ?
Do you have code to make it happen and are looking for guidance to put them in the source
If you have to code for it, I can show you how to contribute it.

Or are you looking for other devs to do it ?

A starting point might be to describe those quick wins in a bit more details on the wiki as
a Feature request:

If you create an account I can give you the writes to create a page.

Let's keep this conversation going.



> I appreciate that offering third-party virtual routers as an alternative
> is not so straightforward, although this seems to be gaining more support
> than the ‘quick wins’. Maybe I am underestimating the development effort
> involved with the L2 asks?
> Cheers
> -Christian
> On 12/06/2015 05:57, "Koushik Das" <> wrote:
>> Agree to what Funs mentioned. The current network service model is
>> flexible, there is option to select a provider for a given service by
>> means of network offering.
>> About using 3rd party VR, there are 2 possibilities:
>> - Fully replace the existing VR with 3rd party VR
>> - Both co-exist and complement each other
>> CS manages the lifecycle of VR. For 3rd party (especially virtual
>> appliances), it needs to be decided what is the best way to manage
>> lifecycle. If CS is able to manage the lifecycle then it can be similar
>> to existing VR (spinning up instances when required). If managed
>> externally, then a pre-created pool of appliances needs to be registered
>> from CS and used.
>> -Koushik
>> -----Original Message-----
>> From: Funs Kessen [] On Behalf Of Funs
>> Kessen
>> Sent: Tuesday, June 09, 2015 3:26 PM
>> To:
>> Subject: Re: Third party VR / L2 support
>> 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.
>> Cheers,
>> Funs
>>> 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<
>>> iM7oPgP0-ItVsL6mkVQsA_-uXKQPH54czwGyS28mxt7gRuUOC-Go3u57toWkaQXYkPDZX8
>>> sv4c9rofl0C-R-G3f8bqHmyUaDM0npe1VNmKwXSTOGJlf26xnX8YXHj01JSJCxJy5hd71u
>>> i8Qnp9Ova_0MqJ31R/
>>> uild%2F%2F> CSForge ­ rapid IaaS deployment
>>> framework<
>>> poYkbqC-d58dZdWgI6Fopw_8NntmiZmE3ScJMe4tUgF2ir9dR8kG0FW98CRuUXi3DtcB1c
>>> Ip1rBEjh_gtHVBCd_VGqv5PjX1f-3IOGJIOsDmAsMcbkgs1SefKTfVTNzHec9mI9CiDA_j
>>> a8h5Abi3VOgeoVbcSusz8/>
>>> CloudStack 
>>> Consulting<
>>> vP_-4ZGRG_Prhsm_hypQSpgtVdnqan7JAwFGx-V4sKkWTRXFAN5FzVnfyDCyjXDysVzaSz
>>> KliSMkAYogajqlEieHV6xOkBSIlljD9Vq8K2MobsvX0H2Ko7MGltINDbv5lEIUOI5ZLesA
>>> txT-HB6hsIXolvmy-mPI_K/
>>> ancy%2F> CloudStack Software
>>> Engineering<
>>> A_1FCMSI-YXGEfuih_Uq7vwmhHlAiquJEZINwlZolL1ieIj0NfhxLA4FytOEf2h_63Qg1A
>>> 3mTnpoqP6SEtS-P0Cw_k4Kps-MnW68o0qjnHmXqg5veuzqtB_ipVSVp5Y6e2r2PkXu8S5B
>>> UK7wspjCjuniGljxy1DF5NA/
>>> re-engineering%2F> CloudStack Infrastructure
>>> Support<
>>> calPRagsx10bbPrMovd3ooAShHWdiTfXYVZbXuTPNTmrb-ovIBaxzS2b8IFw1YYaxflIvh
>>> bFKjLpzMfzlI_cBZpKsGkU-hIvdNSDfLcQfe_yKyNAJie8y4GWd-__KGAk208fB39Ie8bJ
>>> SK23CWHWZkbAAE_1FPs/
>>> ture-support%2F> CloudStack Bootcamp Training
>>> Courses<
>>> hYb7F-VfarsrkTIOkMSjxuLxdx3paM3U4Xu644oFXvtdKP2-NBg571Z80S3DkXA_KIG5gv
>>> G_rQX6eE6WSC0xy2sbtJq7f631ePaXioqihpHIs8TveQEvFEDBgONpyUsheRFRUPTDQDv-
>>> n8K3Ob_jkYjUWl4WRa3/
>>> F>
>>> 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.
>> ― 
>> 	=Funs

View raw message