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