On 7 July 2016 at 21:28, Guru Shetty <g...@ovn.org> wrote: > > > On 7 July 2016 at 20:30, Mickey Spiegel <emspi...@us.ibm.com> wrote: > >> >To: dev@openvswitch.org >> >From: Gurucharan Shetty >> >Sent by: "dev" >> >Date: 07/05/2016 11:15AM >> >Subject: [ovs-dev] [PATCH 1/2] ovn-northd: Ability to loop-back in a >> router. >> > >> >Currently, when a client looks at a load balancer VIP, >> >it notices that it is in a different subnet than itself >> >and sends the packet to its connected router port's >> >MAC address. The load balancer intercepts it. >> > >> >If the load balancer VIP translates to an endpoint IP in a >> >different subnet (than the one client has), than the >> >load balancing works fine because the router will send >> >the packet to the correct destination. >> > >> >But if one of the endpoints that VIP translated into >> >was in the same subnet as the client, the OVN router >> >fails to send the packet back via the same interface. >> >> So the load balancer is translating the destination IP, >> but leaving the MAC address unchanged? >> Based on the MAC address, the packet is forwarded to >> the router patch port? >> > Yes. This does look like a common behavior. Atleast, the default > Kubernetes load balancers (or any iptables based load-balancers) seem to do > that. > > --snip... > >> >> >> I am concerned about two aspects of this proposal: >> 1. It applies to all traffic to directly connected subnets, not just >> for load balancer traffic. That is a significant change in behavior. >> > Agreed. (Having said that, some Physical routers seem to do the same > thing. i.e. have the capability to send back the traffic. I am not sure > whether all Physical routers are capable of doing it.) > > > >> 2. It is removing the inport early on in the router ingress pipeline, >> which scares me and seems like it will make debugging difficult. >> You could narrow it down quite a bit by matching on inport, but >> that still leaves the behavior that concerns me for some traffic. >> Looking at my design for NAT in a distributed router, removing >> the inport would break it. I suspect there might be other >> future features that might act on inport, such as RPF. >> >> > This is only true when the destination IP address is in the same subnet as > the router port. For other cases, inport is available. Do you also need to > send back traffic? I guess what I am getting at is, why do you think this > will hurt other features which won't loop-back? >
Looks like my patch does it for every router port in that router. That is clearly wrong and was not my intention. If I limit it to only the port which has that subnet, would that satisfy your concern? > > > (For cases like that, a workaround would be to store inport in a register > for later use? ) > > >> >> >> > /* NAT in Gateway routers. */ >> >-- >> >1.9.1 >> > >> >_______________________________________________ >> >dev mailing list >> >dev@openvswitch.org >> >http://openvswitch.org/mailman/listinfo/dev >> > >> >> _______________________________________________ >> dev mailing list >> dev@openvswitch.org >> http://openvswitch.org/mailman/listinfo/dev >> > > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
