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. > >> > > >
