Problem
As confirmed by Cisco, NX-OS prior to version 10.6(3) has an issue that deals with the internal candidate DB used with gNMI when mixing feature and dependent configurations. As a result, when feature activation and dependent configuration is mixed within the same gNMI request, the configuration is not persisted to the internal config DB despite being persisted in YANG. When an operator queries YANG for the configuration, it is returned with the expected values despite not showing up e.g. in a show running-config.
Proposed Solution
As suggested also by Cisco, this bug can be avoided by performing two RPC transactions. E.g.
Features Config
gnmic -a 10.15.33.42:50051 -u admin -p <pass> --skip-verify set --update-path 'System/fm-items/bgp-items' --update-value '{"adminSt":"enabled"}' --update-path 'System/fm-items/nvo-items' --update-value '{"adminSt":"enabled"}' --update-path 'System/fm-items/evpn-items' --update-value '{"adminSt":"enabled"}'
Dependent Config
gnmic -a 10.15.33.42:50051 -u admin -p <pass> --skip-verify set --update-path 'System/eps-items/epId-items/Ep-list[epId=1]' --update-value '{"adminSt":"enabled","epId":1,"hostReach":"bgp","sourceInterface":"lo1"}
Tasks
Problem
As confirmed by Cisco, NX-OS prior to version 10.6(3) has an issue that deals with the internal candidate DB used with gNMI when mixing feature and dependent configurations. As a result, when feature activation and dependent configuration is mixed within the same gNMI request, the configuration is not persisted to the internal config DB despite being persisted in YANG. When an operator queries YANG for the configuration, it is returned with the expected values despite not showing up e.g. in a
show running-config.Proposed Solution
As suggested also by Cisco, this bug can be avoided by performing two RPC transactions. E.g.
Features Config
Dependent Config
Tasks