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