Hi Ed, The main concern from my point is that the challenge for the application server and the Management system, too. For Maglev, the backend AS doesn’t only need to de-capsulate the GRE tunneling header, It also need to handle the VIP.
Adding the GRE tunneling decreases the performance absolutely and handling the same VIP On thousands of backend ASs results in the complexity of network management, the ASs Need at least three planes of network configuration ( GRE tunneling VTEP, VIP, data Plane network to other service in the cluster) . So how could we balance the scalability and Complexity is quite a hard question to answer. Waiting for your opinions, thanks! Best Regards, -Johnson From: Ni, Hongjun Sent: Tuesday, April 25, 2017 11:05 AM To: Ed Warnicke <hagb...@gmail.com> Cc: vpp-dev@lists.fd.io; Li, Johnson <johnson...@intel.com> Subject: RE: [vpp-dev] Requirement on Load Balancer plugin for VPP Hi Ed, Thanks for your prompt response. This item is required to handle legacy AS, because some legacy AS does not want to change their underlay forwarding infrastructure. Besides, some AS IPs are private and invisible outside the AS cluster domain, and not allowed to expose to external network. Thanks, Hongjun From: Ed Warnicke [mailto:hagb...@gmail.com] Sent: Tuesday, April 25, 2017 10:44 AM To: Ni, Hongjun <hongjun...@intel.com<mailto:hongjun...@intel.com>> Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>; Li, Johnson <johnson...@intel.com<mailto:johnson...@intel.com>> Subject: Re: [vpp-dev] Requirement on Load Balancer plugin for VPP Hongjun, I can see this point of view, but it radically reduces the scalability of the whole system. Wouldn't it just make sense to run vpp or some other mechanism to decap the GRE on whatever is running the other AS and feed whatever we are load balancing to? Forcing back traffic through the central load balancer radically reduces scalability (which is why Maglev, which inspired what we are doing here, doesn't do it that way either). Ed On Mon, Apr 24, 2017 at 7:18 PM, Ni, Hongjun <hongjun...@intel.com<mailto:hongjun...@intel.com>> wrote: Hey, Currently, traffic received for a given VIP (or VIP prefix) is tunneled using GRE towards the different ASs in a way that (tries to) ensure that a given session will always be tunneled to the same AS. But in real environment, many Application Servers do not support GRE feature. So we raise a requirement for LB in VPP: (1). When received traffic for a VIP, the LB need to do load balance, then do DNAT to change traffic’s destination IP from VIP to AS’s IP. (2). When returned traffic from AS, the LB will do SNAT first to change traffic’s source IP from AS’s IP to VIP, then go through load balance sessions, and then sent to clients. Any comments about this requirement are welcome. Thanks a lot, Hongjun _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> https://lists.fd.io/mailman/listinfo/vpp-dev
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
