Hi:

IRL , we always use different subnets for VIPs for OpenStack workloads in
production for couple of reasons:
1.  It's easy to fail over in case of outages if VIP and pool members are
in different subnets.
2.  It is also easy for neutron's IPAM to manage 2 different subnets; one
for VIP and other for VM/containers instead of allocating from a same
subnet because neutron doesn't care if the allocated IP is getting used for
VIP or VM/container

 Hence, I think its ok to stick with the solution suggested by Guru. If
folks in OpenStack community are exclusively asking for this requirement;
this implementation is worth prioritizing.


On Fri, Mar 2, 2018 at 9:40 AM, Guru Shetty <g...@ovn.org> wrote:

>
>
> On 1 March 2018 at 21:09, Anil Venkata <anilvenk...@redhat.com> wrote:
>
>>
>>
>> On Fri, Mar 2, 2018 at 7:23 AM, Guru Shetty <g...@ovn.org> wrote:
>>
>>>
>>>
>>> On 27 February 2018 at 03:13, Anil Venkata <anilvenk...@redhat.com>
>>> 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.
>
>
>>
>>
>>>>  When I try to send a request from client within the subnet(i.e
>>>> 10.1.0.33) its not reaching any load balancer members.
>>>> I noticed ARP not resolved for VIP 10.1.0.10.
>>>>
>>>> I tried to resolve this in two ways
>>>> 1) Adding a new ARP reply ovs flow for VIP 10.1.0.10 with router port's
>>>> MAC. When client tries to connect VIP, it will use router's MAC. Now router
>>>> gets the packet after load balancing, and will forward the packet to
>>>> appropriate member.
>>>>
>>>> 2) Second approach,
>>>>    a) Using a new MAC(example, 50:54:00:00:00:ab) for VIP 10.1.0.10,
>>>> and adding a new ARP reply flow with this MAC.
>>>>    b) As we are not using router, when load balancing changes
>>>> destination ip, VIP MAC has to be replaced with corresponding member's MAC
>>>> i.e
>>>>       sudo ovs-ofctl add-flow br-int "table=24,ip,priority=150,dl_d
>>>> st=50:54:00:00:00:ab,nw_dst=10.1.0.2,action=mod_dl_dst:50:54
>>>> :00:00:00:01,load:0x1->NXM_NX_REG15[],resubmit(,32)"
>>>> sudo ovs-ofctl add-flow br-int "table=24,ip,priority=150,dl_d
>>>> st=50:54:00:00:00:ab,nw_dst=10.1.0.3,action=mod_dl_dst:50:54
>>>> :00:00:00:02,load:0x2->NXM_NX_REG15[],resubmit(,32)"
>>>>
>>>> Which approach will be better or is there any alternate solution?
>>>>
>>>> Thanks
>>>> Anil
>>>>
>>>>
>>>> _______________________________________________
>>>> discuss mailing list
>>>> disc...@openvswitch.org
>>>> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>>>>
>>>>
>>>
>>
>
> _______________________________________________
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
>
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Reply via email to