07-02-2018 03:09 PM - edited 03-04-2019 02:17 AM
I'm playing around with Pioneer and am noticing some cases where some inferior yang modules are used when presented with more than one option. The specific example I had is openconfig-acl.yang used over Cisco-IOS-XE-acl.yang. This led to a lack of specific protocols being recognized as valid types. Once I disabled openconfig modules and rebuilt the NED I was able to recognize ESP and AHP types. Is there a way to force more complete modules to be selected over others?
<extended xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-acl">
...
<name>Broadband</name>
<access-list-seq-rule>
<sequence>40</sequence>
<ace-rule>
<action>permit</action>
<protocol>esp</protocol>
<host>x.x.x.x</host>
<dst-any/>
</ace-rule>
</access-list-seq-rule>
<access-list-seq-rule>
<sequence>50</sequence>
<ace-rule>
<action>permit</action>
<protocol>ahp</protocol>
<host>x.x.x.x</host>
<dst-any/>
</ace-rule>
</access-list-seq-rule>
...
07-09-2018 02:04 AM
I'm not sure I understand completely. NSO (nor Pioneer) will not choose between different modules with similar functionality. Unless you specifically disable/remove some YANG modules, *both* (or *all* if more than two) representations of the information will be included.
In the sample data above, the Cisco-IOS-XE-acl.yang moduel is being used, and it has no relation to the openconfig-acl.yang model.
Due to all the YANG syntax issues in the openconfig YANG models, I would suspect a different explanation: Could it be that your first build of the NED failed (due to errors in openconfig modules), so in practice you were using some other NED that was already loaded. Then, when you excluded the openconfig modules, the build succeeded and your NED ned took presedence over what you previously had loaded, and some new values appeared.
If you believe this explanation is incorrect, please explain what actions you took to correct the syntax issues in the openconfig modules. ;-)
07-10-2018 04:32 PM
I agree w/ Jan -- it's not clear if you're asking how to exclude modules in Pioneer? or are you looking for some "simple" way to compare (what might be considered "duplicate" modules? (which they aren't)
several modules are include, typically only when an "openconfig" module and IOS-XE module are handling a function.
-- "openconfig" which is meant to a very "vanilla" lowest-common-denominator model that "all" vendors can deploy...
-- "cisco-ios-xe" modules would be exposing every aspect of a device config.
in this case, looking at the YANG model for IOS-XE
File: Cisco-IOS-XE-acl.yang
(skip)
container ace-rule {
leaf action {
type enumeration {
enum deny;
enum permit;
}
}
leaf protocol {
type union {
type uint8 {
range "0..255";
}
type enumeration {
enum ahp;
enum esp;
enum hbh;
enum icmp;
enum ipv6;
enum pcp;
enum sctp;
enum tcp;
enum udp;
}
}
}
you can see exactly the structure you show in your XML.
However, in the "openconfig" module, it's just a "string"... in a leaf called "description" (sounds weird but this
seems to be where the "string" of your rule happens...)
File: openconfig-acl.yang
// Access List Entries
grouping access-list-entries-config {
description
"Access List Entries (ACE) config.";
leaf sequence-id {
type uint32;
description
"The sequence id determines the order in which ACL entries
are applied. The sequence id must be unique for each entry
in an ACL set. Target devices should apply the ACL entry
rules in the order determined by sequence id, rather than
the relying only on order in the list.";
}
leaf description {
type string;
description
"A user-defined description, or comment, for this Access List
Entry.";
}
}
as Jan pointed out these are "unrelated" modules - and just delete the openconfig one... recompile and good to go...
07-10-2018 04:47 PM
Thanks Jan & Gregg,
Your answers make sense and my question came from my lack of understanding which make sense now Essentially both models can be used but one may have gaps. I recompiled and everything works fine now.
Gregg, I believe that description is actually for an ACE description and the issue with Openconfig is lack of support for the ESP and AHP packet types:
http://ops.openconfig.net/branches/master/docs/openconfig-acl.html#ident-ip_protocol
But I could be wrong on this one too.
Pavlos
07-10-2018 04:52 PM
oh yes! you pointed to the correct module - yup
i've spent fairly little time w/ openconfig modules. took a quick guess.
thank you for the pointer!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide