On 9 March 2018 at 11:19, Ben Pfaff <[email protected]> wrote:
> On Fri, Mar 02, 2018 at 09:40:07AM -0800, Guru Shetty wrote: > > On 1 March 2018 at 21:09, Anil Venkata <[email protected]> wrote: > > > > > > > > > > > On Fri, Mar 2, 2018 at 7:23 AM, Guru Shetty <[email protected]> wrote: > > > > > >> > > >> > > >> On 27 February 2018 at 03:13, Anil Venkata <[email protected]> > > >> wrote: > > >> > > >>> For example, I have a 10.1.0.0/24 network and a load balancer is > added > > >>> to it with 10.1.0.10 as VIP and 10.1.0.2(MAC 50:54:00:00:00:01), > > >>> 10.1.0.3(MAC 50:54:00:00:00:02) as members. > > >>> ovn-nbctl create load_balancer vips:10.1.0.10="10.1.0.2,10.1.0.3" > > >>> > > >> > > >> We currently need the VIP to be in a different subnet. You should > connect > > >> switch it to a dummy logical router (or connect it to a external > router). > > >> Since a VIP is in a different subnet, it sends an ARP for logical > router IP > > >> and then things will work. > > >> > > >> > > > > > > Thanks Guru. Any reason for introducing this constraint(i.e VIP to be > in a > > > different subnet)? Can we address this limitation? > > > > > > > It was just easy to implement with the constraint. You will need a ARP > > responder for the VIP. And now, you will have to specify the mac address > > for each VIP in the schema. So that is a bit of work - but not hard. > > Do we document the constraint? If we do not, then that would be > helpful. > I sent a patch: https://patchwork.ozlabs.org/patch/884054/
_______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
