The nb_cfg as a mechanism to "ping" OVN control plane is very useful in many ways. However, the current implementation will trigger update notifications flooding in the whole control plane. Each HV updates to SB the nb_cfg number and all these updates are notified to all the other HVs, which is O(n^2). Although updates are batched in fewers notifications than n^2, it still generates significant load on SB DB and also on ovn-controllers. In order to solve this problem and make the mechanism more scalable for large environments we should separate the chassis private data on it's own table so that chassis' can conditionally monitor and get updates for those records without flooding all other hypervisors.
by this bug, there is a new table added:chassis_private it is seperated from the table chassis. verified on the version: # rpm -qa|grep ovn ovn2.13-central-20.06.2-1.el8fdp.x86_64 ovn2.13-20.06.2-1.el8fdp.x86_64 ovn2.13-host-20.06.2-1.el8fdp.x86_64 # ovn-sbctl --columns name --bare find chassis hv1 hv0 [root@dell-per730-19 multicast]# nb_global_id=$(ovn-nbctl --columns _uuid --bare find nb_global) [root@dell-per730-19 multicast]# ovn-nbctl set NB_Global ${nb_global_id} nb_cfg=99 [root@dell-per730-19 multicast]# ovn-sbctl --columns nb_cfg --bare find chassis_private -----------this table is seperated from the table chassis 99 99 [root@dell-per730-19 multicast]# ovn-sbctl --columns nb_cfg --bare find chassis 0 0 # ovn-nbctl --wait=hv sync -----------sync [root@dell-per730-19 multicast]# ovn-sbctl --columns nb_cfg --bare find chassis -------this table no updates 0 0 [root@dell-per730-19 multicast]# ovn-sbctl --columns nb_cfg --bare find chassis_private -----------this table updates(incr 1) 100 100 tcpdump on the hv0,and then sync one time,we can see that only information about hv0 can be captured. # ovn-sbctl find chassis_private _uuid : 89754dfe-b7d2-4888-be0d-fc797469bc4a chassis : e260facc-f8a1-4a1a-95d0-4dbb4a80d529 external_ids : {} name : hv1 nb_cfg : 101 _uuid : 84d0f88b-29f1-4641-b922-c4a9c154f1a1 ----------the uuid chassis : c494a5cd-9e87-41ff-b223-14f7df0bcefc external_ids : {} name : hv0 nb_cfg : 101 check the packets in the wireshark,we can see information below: âº)À¬|þ¯àEÀö9@@Ã| òÖ{Gÿ1x7~/ .äK_{Ôdk{"id":null,"method":"update3","params":[["monid","OVN_Southbound"],"00000000-0000-0000-0000-000000000000",{"Chassis_Private":{"84d0f88b-29f1-4641-b922-c4a9c154f1a1":{"modify":{"nb_cfg":101}}}}]} --------it is the uuid of hv0. and no uuid of hv1.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (ovn2.13 bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:3769