cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
775
Views
0
Helpful
2
Replies

Using cisco-ios and netconf NED for IOS-XE - duplicate prefix

mfierbau
Cisco Employee
Cisco Employee

Hi all,

I just finished compiling the netconf ned for IOS-XE.  It appears that the yang models on the device use the same urn/prefix as the CLI NED.  In the XE Yang models, this is referenced in several places.

Given the number of references, it would appear that the two could not be easily used on the same system without significant rewriting of one of these two NEDs. 

Could someone confirm that using them both on the same system would not be realistically possible or is there some other way around this?

>>> System upgrade is starting.

>>> Sessions in configure mode must exit to operational mode.

>>> No configuration changes can be performed until upgrade has completed.

>>> System upgrade has been cancelled.

Error: Duplicate prefix "ios" used in 'http://cisco.com/ns/yang/Cisco-IOS-XE-native' and 'urn:ios'


Thanks,

Marty

1 Accepted Solution

Accepted Solutions

Jan Lindblad
Cisco Employee
Cisco Employee

You can work around this issue by editing the YANG so that one of the conflicting modules gets a different prefix. Most YANGs never use the local prefix within the module, and if it is used locally, just update those references to the same new prefix. If you have service code or templates that uses the changed prefix, that needs to be updated as well.

View solution in original post

2 Replies 2

alam.bilal
Cisco Employee
Cisco Employee

Hi,

There is a new NSO feature slated for 4.7 (mid 2018) that will allow multiple NED versions to on the same NSO instance. So that should help resolve the namespace conflicts.

I have a customer that is exploring using LSA to mitigate such issues.

Thanks.

Jan Lindblad
Cisco Employee
Cisco Employee

You can work around this issue by editing the YANG so that one of the conflicting modules gets a different prefix. Most YANGs never use the local prefix within the module, and if it is used locally, just update those references to the same new prefix. If you have service code or templates that uses the changed prefix, that needs to be updated as well.