Closed grantcurell closed 4 years ago
After spending a bunch of time rolling through the code and getting a much better idea of how this works - is the reason that you don't know ahead of time what hash capabilities a switch will provide? So on the Dell switch you have a separate YANG file which defines the specific hash capabilities on Dell hardware, but because opx-config-global-switch
was written for the general case it doesn't reference those?
I haven't submitted yet, but I wrote a patch to fix the behavior: https://github.com/grantcurell/opx-tools/tree/opx-config-global-switch-add-hash-fields
I'm looking into https://github.com/open-switch/opx-tools/issues/27 and want to implement a fix.
I'm still learning the code base, but after investigating
opx-config-global-switch
in opx-tools it looks like it reads from the CPS keybase-switch/switching-entities/switching-entity
which is defined in dell-base-switch-element.yang. However, the CPS server application responsible for thehash-fields
attribute, the NAS daemon (with code defined inopx-nas-l2/src/switch/nas_hash_cps.cpp
), uses dell-base-hash.yang instead. dell-base-hash.yang defines the exact same values as dell-base-switch-element.yang as far as I can tell.This means when
opx-config-global-switch
runs:base-switch/switching-entities/switching-entity/lag-hash-fields
will never be present intarget_attrs
which leads to the problem described in https://github.com/open-switch/opx-tools/issues/27. What drove the use ofdell-base-hash.yang
instead ofdell-base-switch-element.yang
?