[ovs-dev] [PATCH v1 ovn 0/1] Forwarding group to load balance l2 traffic with liveness detection

Manoj Sharma manoj.sharma at nutanix.com
Wed Jan 15 02:10:12 UTC 2020

Hi Numan,

Please see my answers inline:

On 1/13/20, 11:37 PM, "Numan Siddique" <numans at ovn.org> wrote:

    On Sat, Jan 11, 2020 at 6:31 AM Manoj Sharma <manoj.sharma at nutanix.com> wrote:
    > Thank you for the review Numan.
    > On 1/8/20, 11:14 PM, "Numan Siddique" <numans at ovn.org> wrote:
    >     Hi Manoj,
    >     Thanks for the patch. I didn't look into the complete patch. I have
    >     initial few comments.
    >     The patch fails to compile when --enable-Werror and --enable-sparse
    >     are enabled during configuration.
    > I sent the v2 that has the fix for the compilation issue.
    Thanks for v2. I will take a look at it.
    I have few follow up questions.
    >     Can you please include the description in Patch 0 in the actual patch
    >     commit message ?
    >     The commit message in the patch doesn't have much details.
    > Done
    >     In your above description, does the logical switch (with logical ports
    >     lsp1 and lsp2) has a localnet port ?
    > It does not matter if the switch has localnet port or not. You are only putting
    > the logical switch ports in an openflow group so that traffic can be load balanced
    > across them.
    >     I am confused how the packet goes out of the logical switch to the
    >     external network ?
    >     Does lsp1 and lsp2 bound to any VM/VIF ?
    >     From the test case you have written I see that lsp21 and lsp22 are
    >     part of forward group and they
    >     have VIF ports as well. So the packet destined to the VIP will be
    >     delivered to one of the VIF ?
    >     And the VIF/VM takes care of sending the traffic to external routers ?
    > We can model an external router as an OVN chassis. For HA, you will need more than one external router
    > and bind the lsp1 and lsp2 to these chassis (lsp1 <> chassis1, lsp2 <> chassis2). If we want
    > to load balance across these external routers then just send the traffic to the VIP.
    Does ovn-controller run on these external router hosts ? I presume so,
    otherwise there will be no
    chassis entry in the SB Chassis table.
    I am curious on how the packet will go out of br-int ?

It's not necessary to run ovn-controller on these external appliances. It can be any device, outside OVN also. 
Yes, you need an entry in the chassis table for it.
I will give an example of how it can be used. Let's assume that there are two external hosts "ext_rtr1", and "ext_rtr2".  
We add these hosts in the chassis table by :  
"ovn-sbctl chassis-add ext_rtr1 ENCAP-TYPE ENCAP-IP" and "ovn-sbctl chassis-add ext_rtr2 ENCAP-TYPE ENCAP-IP". 
I have a logical switch "ext-ls" with one port for connecting to each of these chassis : 
"ovn-sbctl lsp-bind ext-lsp1 ext_rtr1" and "ovn-sbctl lsp-bind ext-lsp2 ext_rtr2".

You can configure a fwd group on "ext_ls" with "ext_lsp1" and "ext_lsp2" as child ports and load balance traffic to these two external hosts. With liveness enabled, if any of the hosts goes down, traffic will stop getting forwarded to it automatically.

    You must be aware that we already have native load balancer feature in
    OVN which does almost exactly the same
    thing. The forward groups you proposed here and the OVN load balancer
    uses the same mechanism.
    But probably load balancer don't use BFD mechanism to check the liveliness.
    Can the native load balancer be used instead ? It does have health
    check feature now. If it's possible, then
    definitely I would avoid adding forward groups.

The native load balancer can not be used with non-ovn appliance where BFD is the most common mechanism to detect liveness. Also I see forwarding group more of a LAG/bond interface at the logical switch. 


More information about the dev mailing list