cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian <>
Subject Re: Third party VR / L2 support
Date Fri, 12 Jun 2015 09:13:57 GMT
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.

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?


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.
>-----Original Message-----
>From: Funs Kessen [] On Behalf Of Funs
>Sent: Tuesday, June 09, 2015 3:26 PM
>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.
>> 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
>>> 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
>> 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
>> 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