-
Notifications
You must be signed in to change notification settings - Fork 1
Description
In certain cases we have inconsistencies between the YANG state and the CLI state for the BD-VIF IPv6 address. YANG reports the IP address as being present on the device, while on CLI the address is not configured. This only happens sometimes. So far we have been able to reproduce it sometimes by repeatably adding and removing ips via the openstack driver.
YANG reports an IPv6 address for BD-VIF 6394
--------------------------------- raw query ---------------------------------
<native>
<interface>
<BD-VIF>
<name>6394</name>
<ipv6/>
</BD-VIF>
</interface>
</native>
--------------------------------- response ---------------------------------
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:10a4e33d-c500-4ca0-b9bf-d661f4c5cecb">
<data>
<native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
<interface>
<BD-VIF>
<name>6394</name>
<ipv6>
<address>
<prefix-list>
<prefix>2a10:abcd:abcd::1/64</prefix>
</prefix-list>
</address>
</ipv6>
</BD-VIF>
</interface>
</native>
</data>
</rpc-reply>CLI reports no ipv6 address on the interface.
eu-de-1-rt119a#show run int BD-VIF6394
Building configuration...
Current configuration : 416 bytes
!
interface BD-VIF6394
description ...
mac-address fa16.3eab.cdef
mtu 8950
vrf forwarding 35247803990d40b28e3d99b354dca6f0
no ip address
ip nat stick
ip policy route-map pbr-35247803990d40b28e3d99b354dca6f0
ntp disable
endRestarting the YANG stack fixes this (but causes a config downtime for a couple of minutes). Forcing a resync by modifying an object that we know will trigger a full resync seems to work as well with some delay, but also locks up the device for over 90 seconds in our production regions.
We have similar problems with floating ips / static nat statements, meaning that we have YANG entries for IPs that are missing on the CLI, looking like this:
ip nat inside source static 1.2.3.4 5.6.7.8 vrf my-vrf no-alias match-in-vrf stateless
Here, we would find this statement in YANG, but not on the cli.
Inconsistencies like this cause the driver to not be able to reconfigure a resource, as YANG thinks this is already configured on the device.
We have seen cases for this in both ways (missing in YANG but present on cli AND missing in CLI but present on YANG). We have seen this issue happening on 17.6 and in some combinations (maybe all) also on 17.15.01a.