Thanks for your attention, I have given my replies in my spec file, and I'll stick them here as follows:
<Q0:the detail of the new approach>
I think I have explained the implementation method clearly, but it seems that it is not enough. I will fill in this part if necessary
<Q1:why it works? and how it works>
First we create a port with VIP and never bind it to any vm, then Ocativa create some load balancers having their own real IP and sharing the one VIP.
Ocativa send request to Neutron to create a ECMP instance, then Neutron l3-agent excute command in qrouter namespaces to create a ECMP entry just like I wrote above, fill <destination_ip> field with VIP, fill <nexthop_ip> field with real ip.
Now, when packets come to router with VIP as their destination ip, they will match the
ECMP entry, so qrouter will change their destination mac address to the real ip's mac address which belongs to a load balancer.
<Q2:load balancer upon the Octavia load balancer>
Yes you are right. The ECMP is another layer of loadbalancer, which provide more flexity.
<Q3:add the LB "real server" to the octavia load balancer>
I'm not sure about what you mean....but the "back ends" refered here are exactly Octavia backends pool.
<Q4:same subnet will not go to the router>
In fact I also added the ARP surrogate setting to the router,but forgot to write it in my spec file, I'll make up that part later.
<Q5:why not add the route directly to the guest client VM>
It is because the simple ECMP approach can not proivde features about L7 loadbalaning. The complex loadbalancing should be done by haproxy, lvs or other loadbalancer. The two level of loadbalancing(ECMP+Loadbalancer) can be easily managed by octavia...
In Addition, Mr Liu YuLong has also ask server other questions in my spec file, as follows:
<Q6:How about DVR scenario>
It can works in DVR scenario,just put ecmp entries to every each route related to load balancing node.
<Q7:How about bug 1774459>
This bug will not trigger, because router will not need the mac of VIP.
To Slawek Kaplonski:
Thanks for your attention, I have given my replies in my spec file, and I'll stick them here as follows:
<Q0:the detail of the new approach> ECMP+Loadbalanc er) can be easily managed by octavia...
I think I have explained the implementation method clearly, but it seems that it is not enough. I will fill in this part if necessary
<Q1:why it works? and how it works>
First we create a port with VIP and never bind it to any vm, then Ocativa create some load balancers having their own real IP and sharing the one VIP.
Ocativa send request to Neutron to create a ECMP instance, then Neutron l3-agent excute command in qrouter namespaces to create a ECMP entry just like I wrote above, fill <destination_ip> field with VIP, fill <nexthop_ip> field with real ip.
Now, when packets come to router with VIP as their destination ip, they will match the
ECMP entry, so qrouter will change their destination mac address to the real ip's mac address which belongs to a load balancer.
<Q2:load balancer upon the Octavia load balancer>
Yes you are right. The ECMP is another layer of loadbalancer, which provide more flexity.
<Q3:add the LB "real server" to the octavia load balancer>
I'm not sure about what you mean....but the "back ends" refered here are exactly Octavia backends pool.
<Q4:same subnet will not go to the router>
In fact I also added the ARP surrogate setting to the router,but forgot to write it in my spec file, I'll make up that part later.
<Q5:why not add the route directly to the guest client VM>
It is because the simple ECMP approach can not proivde features about L7 loadbalaning. The complex loadbalancing should be done by haproxy, lvs or other loadbalancer. The two level of loadbalancing(
In Addition, Mr Liu YuLong has also ask server other questions in my spec file, as follows:
<Q6:How about DVR scenario>
It can works in DVR scenario,just put ecmp entries to every each route related to load balancing node.
<Q7:How about bug 1774459>
This bug will not trigger, because router will not need the mac of VIP.