[ovs-discuss][OVN] Join switch and ls_in_arp_rsp table

[Girish Moodalbail]

Hello Han, Dumitru, Numan, and others,

As per OVN architecture documentation, `join` logical switch is exclusively used to connect the gateway routers to distributed routers. So, all the ports connected to the join switch are ‘router’ logical_switch_ports. Now,

1. Say a packet arrives on the gateway router and is meant for a VM behind a logical switch. We lookup the routing table, determine the nexthop, find the destination MAC address for the nexthop IP from lr_in_arp_resolve table and send the packet out towards the distributed router.

2. On the other direction, the packet from a VM towards 8.8.8.8 arrives at the distributed router. We lookup the routing table, determine the nexhop, find the destination MAC address for the nexthop IP lfrom lr_in_arp_resolve table and send the packet out towards the gateway router.

From (a) and (b) above, at least on the Join switch, we should never see any ‘ARP requests at all, right? If this is the case, then the whole ls_in_arp_rsp table for the join switch can be just 

  table=13(ls_in_arp_rsp      ), priority=0    , match=(1), action=(next;)

Any thoughts?

In a 1000 Node K8s cluster, there are around 12K Logical Flows for `join` switch.  Out of which, 6K Logical flows are from table=13 and none of those flows are being used. I am trying to see if we can optimize this path.

Regards,

~Girish

[Girish Moodalbail]

On Mon, Jul 13, 2020 at 10:50 PM Numan Siddique <num...@ovn.org> wrote:

On Tue, Jul 14, 2020 at 8:13 AM Girish Moodalbail <gmood...@gmail.com> wrote:
>
> Hello Han, Dumitru, Numan, and others,
>
>
> As per OVN architecture documentation, `join` logical switch is exclusively used to connect the gateway routers to distributed routers. So, all the ports connected to the join switch are ‘router’ logical_switch_ports. Now,
>
>
> Say a packet arrives on the gateway router and is meant for a VM behind a logical switch. We lookup the routing table, determine the nexthop, find the destination MAC address for the nexthop IP from lr_in_arp_resolve table and send the packet out towards the distributed router.
>
>
> On the other direction, the packet from a VM towards 8.8.8.8 arrives at the distributed router. We lookup the routing table, determine the nexhop, find the destination MAC address for the nexthop IP lfrom lr_in_arp_resolve table and send the packet out towards the gateway router.
>
>
> From (a) and (b) above, at least on the Join switch, we should never see any ‘ARP requests at all, right? If this is the case, then the whole ls_in_arp_rsp table for the join switch can be just

Hi Girish,

I don't think ovn-northd/ovn-controller can say if a logical switch is
a join switch or not. I think OVN can address this by providing an
option in the logical_switch options column and if it is set to true,
ovn-northd will not populate
the ls_in_arp_rps table at all. ovn-k8s should set this option when
creating join logical switches.

Any thoughts on this approach ?

Thanks Numan for the reply. Absolutely agree. Options based approach would be the way to go. 

Regards,

~Girish

Thanks
Numan

>
>
>   table=13(ls_in_arp_rsp      ), priority=0    , match=(1), action=(next;)
>
>
> Any thoughts?
>
>
> In a 1000 Node K8s cluster, there are around 12K Logical Flows for `join` switch.  Out of which, 6K Logical flows are from table=13 and none of those flows are being used. I am trying to see if we can optimize this path.


>
>
> Regards,
>
> ~Girish
>
>

> --
> You received this message because you are subscribed to the Google Groups "ovn-kubernetes" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ovn-kubernete...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/ovn-kubernetes/CAAF2STSCRqYJW5nojZJOrRhSEg%2BmJeyTEEL3EmHY0pnWYs9Vbg%40mail.gmail.com.