-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
YANG bridge-domain membership configuration breaks cli config assumptions #28
Comments
Tested with new image version
Information in YANG is duplicatedConsider the following device configuration:
Retrieving this via YANG will result in the following XML
The service-instance here is presentet two times. Once in service-instance-list vs service-instance behave differently, two interfaces existThere now seem be two ways to configure the same attribute:
My questions:
service-instance-list tag is presented once for each instance, while each service instance should be contained in a single listConsider this config on the CLI
When querying this bridge domain it looks like this
Apart from the duplication with
but like this
member interface name normalization has not been fixedInterface name normalization still is something that is not happening. If Cisco is not intending to fix this please tell me so I can stop testing these things.
We now configure a Port-channel2 interface with a service-instance, but with a differently cased name:
When we now retrieve the bridge-domain we can see that in the YANG config db this is an extra entry, while on the device it stays the same.
The interface name should get normalized to Port-channel2 in this case. |
YANG and the cli do seem to have different opinions on how interface members work and should be represented.
Assume the following device state:
Via YANG we get the following
So all other instances are no longer reachable via the YANG api.
When we now reconfigure one of the portchannels we can see that it is replaced in YANG
In the device log we can see that YANG just issues a command to add this service instance to the port-channel:
Same goes for a replace operation, e.g.
No service-instance is actually removed from the device, even when we try to replace it.
For the driver migration I need some means to manage these members:
Also, YANG does not normalize the interface name and creates one entry for each differently cased/named interface
The text was updated successfully, but these errors were encountered: