Thanks for this update Ilya,

Best regards,

Kris



On 11 April 2016 at 07:59, ilya <ilya.mailing.li...@gmail.com> wrote:

> Kris and Nick
>
> Noticed an update in the FS:
>
> >> The VPC Inline LB appliance therefore is a regular System VM, exactly
> the same as the Internal LB appliance today. Meaning it has 1 guest nic
> and 1 control (link-local / management) nic.
>
>
>
> This should be ok. The premise behind my concern was - if LB Inline VM
> was to get hack (re: SSL HeartBlead) and intruder has root level
> privileges, he could try to go further in the network in an attempt to
> get access to MGMT layer. Since we have link-local - its limited to 1
> hypervisor only.
>
> Assuming iptables/firewall on hypervisor blocks incoming traffic from VR
> link local address - we should be ok. I guess i need to double check on
> this.
>
> Regards
> ilya
>
>
>
> On 4/10/16 1:26 PM, Kris Sterckx wrote:
> > Hi all
> >
> >
> > Thanks for reviewing the FS. Based on the received comments I clarified
> > further in the FS that the Vpc Inline LB appliance solution is based on
> the
> > Internal LB appliance solution, only now extended with secondary IP's and
> > static NAT to Public IP.
> >
> > I also corrected the "management" nic to "control" nic. The text really
> > meant eth1, i.e the link-local nic on KVM.
> >
> > Pls find the updated text :
> >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61340894
> >
> > Architecture and Design description
> >
> > We will introduce a new CloudStack network plugin “VpcInlineLbVm” which
> is
> > based on the Internal LoadBalancer plugin and which just like the
> Internal
> > LB plugin is implementing load balancing based on at-run-time deployed
> > appliances based on the VR (Router VM) template (which defaults to the
> > System VM template), but the LB solution now extended with static NAT to
> > secondary IP's.
> >
> > The VPC Inline LB appliance therefore is a regular System VM, exactly the
> > same as the Internal LB appliance today. Meaning it has 1 guest nic and 1
> > control (link-local / management) nic.
> >
> > With the new proposed VpcInlineLbVm set as the Public LB provider of a
> VPC,
> > when a Public IP is acquired for this VPC and LB rules are configured on
> > this public IP, a VPC Inline LB appliance is deployed if not yet
> existing,
> > and an additional guest IP is allocated and set as secondary IP on the
> > appliance guest nic, upon which static NAT is configured from the Public
> IP
> > to the secondary guest IP.  (See below outline for the detailed
> algorithm.)
> >
> > *In summary*, the VPC Inline LB appliance is reusing the Internal LB
> > appliance but its solution now extended with Static NAT from Public IP's
> to
> > secondary (load balanced) IP's at the LB appliance guest nic.
> >
> >
> > Hi Ilya,
> >
> > Let me know pls whether that clarifies and brings new light to the
> > questions asked.
> >
> > Can you pls indicate, given the suggested approach of reusing the
> appliance
> > mechanism already used for Internal LB, whether this addresses the
> concern
> > or, when it doesn't, pls further clarify the issue seen in this approach.
> >
> > Thanks!
> >
> >
> > Hi Sanjeev, to your 1st question:
> >
> > Will this LB appliance be placed between guest vm's and the Nuage VSP
> > provider(Nuage VSP and lb appliance will have one nic in guest network)?
> >
> >> Please note that the LB appliance is a standard System VM, having 1 nic
> > in Guest network and 1 nic in Control. There is as such no relation
> between
> > this Appliance and the Nuage VSP.
> >
> > In the case where Nuage VSP is the Connectivity provider, the appliance
> has
> > a guest nic in a Nuage VSP managed (VXLAN) network, like all guest VM's
> > would have. But that is dependent on the provider selection.
> >
> > In the specific case of Nuage VSP, publicly load balanced traffic will
> > indeed flow as : (pls read-on to your 2nd question also) :
> >     -> incoming traffic on Public IP  (Nuage VSP managed)
> >     -> .. being Static NAT'ted to Secondary IP on Vpc Inline LB VM
> >  (NAT'ting is Nuage VSP managed)
> >     -> .. being load balanced to real-server guest VM IP's  (Vpc Inline
> LB
> > VM appliance managed)
> >     -> .. reaching the real-server guest VM IP
> >
> > To your 2nd question:
> >
> > Is there any specific reason for traffic filtering on lb appliance
> instead
> > of Nuage VSP ? If we configure firewall rules for LB services on the
> Nuage
> > VSP instead of the inline lb appliance (iptable rules  for lb traffic),
> > traffic can be filtered on the Nuage VSP before Natting?
> >
> >> Please note that the generic Static NAT delegation is applicable : the
> > realization of the Static NAT rules being set up, depends on the Static
> NAT
> > provider in the VPC offering. In case Nuage VSP is the provider for
> Static
> > NAT (which it would be in the case of a Nuage SDN backed deployment), the
> > NAT’ting is effectively done by the Nuage VSP.  If anyone else is the
> > provider, than this provider is being delegated to.
> >
> > Thanks!
> >
> >
> > Let me know whether this overall clarifies.
> >
> > Pls don't hesitate to ask and further questions.
> >
> >
> > Best regards,
> >
> >
> > Kris Sterckx
> >
> >
> >
> > On 25 March 2016 at 07:08, Sanjeev Neelarapu <
> > sanjeev.neelar...@accelerite.com> wrote:
> >
> >> Hi Nick Livens,
> >>
> >> I have gone through the FS and following are my review comments:
> >>
> >> 1. Will this LB appliance be placed between guest vms and the Nuage VSP
> >> provider(Nuage VSP and lb appliance will have one nic in guest network)?
> >> 2. Is there any specific reason for traffic filtering on lb appliance
> >> instead of Nuage VPS ? If we configure firewall rules for LB services on
> >> the Nuage VSP instead of the inline lb appliance (iptable rules  for lb
> >> traffic), traffic can be filtered on the Nuage VSP before Natting?
> >>
> >> Best Regards,
> >> Sanjeev N
> >> Chief Product Engineer, Accelerite
> >> Off: +91 40 6722 9368 | EMail: sanjeev.neelar...@accelerite.com
> >>
> >>
> >> -----Original Message-----
> >> From: ilya [mailto:ilya.mailing.li...@gmail.com]
> >> Sent: Thursday, March 24, 2016 10:16 PM
> >> To: dev@cloudstack.apache.org
> >> Subject: Re: [DISCUSS] Request for comments : VPC Inline LoadBalancer
> (new
> >> plugin)
> >>
> >> Hi Nick,
> >>
> >> Being fan of SDN, I gave this proposal a thorough read.
> >>
> >> I do have only 1 comment - that you can perhaps can use to reconsider:
> >>
> >> "Each appliance will have 2 nics, one for management, and one in the
> guest
> >> network. "
> >>
> >> In general, 2 nics - one going to management and one going to guest - is
> >> looked very negatively upon by internal InfoSec team. This
> implementation
> >> will make an LB non-compliant from SOX or PCI perspective.
> >>
> >> Proposed alternate solution:
> >> Deploy a VM with 2 NICs but put them both on the same guest network (I
> >> believe the support 2 NICs on the *same* guest network has already been
> >> submitted upstream). 1 NIC for MGMT and 1 NIC for GUEST.
> >>
> >> Using SDNs ability to restrict communication flow (openvswitch or what
> >> not), only allow specific connections from CloudStack MS to Inline LB on
> >> MGMT NIC. You will need to block all external GUEST communication to
> MGMT
> >> NIC and only make it talk to CloudStack MS on specific ports.
> >>
> >> This approach should preserve the internal compliance and wont raise any
> >> red flags.
> >>
> >> Perhaps reach out to a client who requested this feature and ask what
> they
> >> think, maybe they have not thought this through.
> >>
> >> Regards
> >> ilya
> >>
> >> PS: If we were to entertain the idea of InLine LB, we would most likely
> >> ask for approach mentioned above.
> >>
> >>
> >>
> >>
> >> On 3/24/16 1:18 AM, Nick LIVENS wrote:
> >>> Hi all,
> >>>
> >>> I'd like to propose a new plugin called the "VPC Inline LB" plugin.
> >>> The design document can be found at :
> >>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61340
> >>> 894
> >>>
> >>> Looking forward to hear your reviews / thoughts.
> >>>
> >>> Thanks!
> >>>
> >>> Kind regards,
> >>> Nick Livens
> >>>
> >>
> >>
> >>
> >> DISCLAIMER
> >> ==========
> >> This e-mail may contain privileged and confidential information which is
> >> the property of Accelerite, a Persistent Systems business. It is
> intended
> >> only for the use of the individual or entity to which it is addressed.
> If
> >> you are not the intended recipient, you are not authorized to read,
> retain,
> >> copy, print, distribute or use this message. If you have received this
> >> communication in error, please notify the sender and delete all copies
> of
> >> this message. Accelerite, a Persistent Systems business does not accept
> any
> >> liability for virus infected mails.
> >>
> >
>

Reply via email to