Hello all,

Say, the logical topology is as defined below. We have a logical router
connected to 1000 gateway routers through a join switch. This is a 1000
hypervisor OVN k8s cluster where-in each gateway router is bound to their
respective hypervisor.

+-----------+ +-----------+        +-----------+ +-----------+
|  Gateway  | |  Gateway  | .....  |  Gateway  | |  Gateway  |
| Router-1  | | Router-2  |        |Router-999 | |Router-1000|
+-----+-----+ +-----+-----+        +-----+-----+ +---+-------+
 100.64.0.2    100.64.0.3                |        100.64.x.y
      |             |                    |           |
+-----+-------------+--------------------+-----------+------+
|                    join logical_switch                    |
|                      (100.64.0.0/16)                      |
+----------------------------+------------------------------+
                             |
                             |
                        100.64.0.1
            +----------------+---------------+
            |     logical router             |
            +--------------------------------+

If we now look at table=12 (lr_in_arp_resolve) in the ingress pipeline of
Gateway Router-1, then you will see that there will be 2000 logical flow
entries (1000 for IPv4 and 1000 for IPv6) where-in each of the entry
resolves the NextHop IP address (corresponding to the 1000 routers) to
destination ethernet address. For example, on Gateway Router-1
(outport == rtoj-gr1 && reg0 == 100.64.0.3), action=(eth.dst=m3; next;)
(outport == rtoj-gr1 && reg0 == 100.64.0.4), action=(eth.dst=m4; next;)

Each router will have 2000 entries, and in total we will have 2000 * 1000 =
2M entries. That is lot of flows for OVN SB to digest.

In the topology above, the only intended path is North-South between each
gateway router and the logical router. There is no east-west traffic
between the gateway routers

We addressed this issue by creating 1000 join logical switches and each
join logical_switch connects one gateway router to the logical router.
However, this creates lots of logical resources and other scale issues in
OVN. Also, there are other places in the OVN kubernetes logical topology
that we could optimize by creating just one logical switch instead of 1000s
of logical switch (for example: instead of a separate external logical
switch with localnet port that connects gateway router to physical network,
we could just have one for the whole logical topology).

Is there an another way to solve the above problem with just keeping the
single join logical switch?

Regards,
~Girish
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Reply via email to