cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
239
Views
1
Helpful
8
Replies
khgrant
Cisco Employee

Compiling Juniper Yang Model - Node name conflict

 

Hi,

 

 

Customer is trying to compile the Yang model for Junos

 

 

We’re getting the following error:

 

Warning: The following symbols have been suppressed due to a

 

conflict with a different node name mapped to the same symbol:

 

'action-choice', 'action_choice', 'address-choice', 'address_choice',

 

'alarm-mode', 'alarm_mode', 'area-range', 'area_range',

 

'buffer-limit', 'buffer_limit', 'ca-name', 'ca_name',

 

'class-name', 'class_name', 'community-name', 'community_name',

 

'context-id', 'context_id', 'domain-name', 'domain_name',

 

'flag-name', 'flag_name', 'gateway-name', 'gateway_name',

 

'group-address', 'group-id', 'group-name', 'group_address',

 

'group_id', 'group_name', 'input-choice', 'input-excess-bandwidth-share',

 

'input_choice', 'input_excess_bandwidth_share', 'instance-name', 'instance_name',

 

'interface-name', 'interface_name', 'isid-list', 'isid_list',

 

'lcc-number', 'lcc_number', 'list-name', 'list_name',

 

'log-type', 'log_type', 'loose-strict-none', 'loose_strict_none',

 

'metric-offset', 'metric_offset', 'mode-choice', 'mode_choice',

 

'msisdn-choice', 'msisdn_choice', 'name-value', 'name_value',

 

'next-hop', 'next_hop', 'nexthop-value', 'nexthop_value',

 

'oam-period', 'oam_period', 'path-name', 'path_name',

 

'policy-name', 'policy_name', 'rib-name', 'rib_name',

 

'routing-instance-name', 'routing_instance_name', 'rule-set', 'rule_set',

 

'source-address', 'source_address', 'term-name', 'term_name',

 

'vlan-list', 'vlan-name', 'vlan_list', 'vlan_name'.

 

Use tailf:code-name on the conflicting nodes to avoid the conflict.

 

 

I am trying to understand the conflict is between what and what?

 

Are those like reserved keyword internally? Or they are already used by another NED (the Tailf provided Juniper NED)?

 

 

Thanks

 

Mohamed

 

8 REPLIES 8
khgrant
Cisco Employee

 

Hi,

 

 

Since Juniper-Junos is not 100% NC/YANG compliant, we have productised this NED. Last I looked into this topic, it requires retrieving the models (XML/XSD) and converting them into YANG. Followed by some massaging of the yang models where required before compiling the NED.

 

 

The following error seem to imply that when symbols are generated (as part of compilation), they collide with some existing ones in the symbol space. The conflicting keywords/nodes do not appear to be internal/reserved. Perhaps pick a node and grep for the two variants (“action-choice” and “action_choice”) in the yang files to see if both these definitions exists and if one of them needs to be removed? As they both seem to be getting mapped to the same symbol. That would be my guess.

 

 

Thanks,

Bilal.

 

khgrant
Cisco Employee

 

Your guess is quite correct: this warning (it's not an error unless you ask for it with --fail-on-warnings) is not generated by the actual YANG compilation, but when running 'ncsc ... --emit-java <filename>' to create class definitions for Java code from the compiled YANG module.

 

Java, like most programming languages, can't have identifiers that contain '-', so e.g. 'action-choice' has to be mapped to 'action_choice'

 

for this file. And if the YANG module uses both those names - not a bug, but sloppy design IMHO - you get this result.

 

 

I don't know the context of this exercise, but it pretty much has to do with building either a NETCONF NED or a corresponding netsim component, and neither uses any Java code, so the --emit-java is completely pointless. If a package is being created based on ncs-make-package, the --no-java option is recommended.

 

 

The juniper-junos NED that we ship (which is still produced the way you describe AFAIK) obviously does *not* do the --emit-java as part of the build process. If this is about a YANG module provided by Juniper, it would probably be a good idea to contact the NED experts regarding the feasibility of using it as basis for a NETCONF NED before spending major efforts on it - ISTR hearing that such module(s) exist but don't really match the NETCONF that the devices expect yet (this may have changed though).

 

 

--Per

 

khgrant
Cisco Employee

 

Thanks Per and Bilal for your feedback

 

 

You are right, this is in a context of creating a Netconf NED based on Juniper “claimed” Yang-compliant model. I will keep into digging into it

 

As you pointed out, I noticed that this only a warning but wondering why it failed the compilation. I didn’t specify --fail-on-warnings, not sure if this is default? Below is the full log:

 

 

cisco@NSO-4:~/ncs4.3/packages/ned-junos/src$ make clean all

 

rm -rf ncsc-out ../load-dir ../shared-jar ../private-jar java/src/com/example/nedjunos/namespaces

 

cd ../netsim && make clean || true

 

make[1]: Entering directory `/home/cisco/ncs4.3/packages/ned-junos/netsim'

 

make[1]: Leaving directory `/home/cisco/ncs4.3/packages/ned-junos/netsim'

 

cd java && ant -q clean || true

 

 

BUILD SUCCESSFUL

 

Total time: 0 seconds

 

rm -f java/src/com/example/nedjunos/namespaces/*.java

 

mkdir -p ncsc-out

 

mkdir -p ../load-dir

 

mkdir -p ../shared-jar

 

mkdir -p ../private-jar

 

mkdir -p java/src/com/example/nedjunos/namespaces

 

/home/cisco/ncs4.3/bin/ncsc --ncs-compile-bundle yang \

 

--ncs-device-dir ncsc-out   \

 

--ncs-device-type netconf \

 

&& \

 

cp ncsc-out/modules/fxs/*.fxs ../load-dir;

 

yang/configuration.yang:4687: warning: the default value for a key leaf is ignored

 

yang/configuration.yang:7224: warning: the default value for a key leaf is ignored

 

yang/configuration.yang:9169: warning: the default value for a key leaf is ignored

 

yang/configuration.yang:44299: warning: the default value for a key leaf is ignored

 

yang/configuration.yang:47158: warning: the default value for a key leaf is ignored

 

yang/configuration.yang:79111: warning: the default value for a key leaf is ignored

 

yang/configuration.yang:116464: warning: the default value for a key leaf is ignored

 

yang/configuration.yang:225536: warning: the default value for a key leaf is ignored

 

augmented/configuration.yang:225403: warning: the default value for a key leaf is ignored

 

augmented/configuration.yang:228411: warning: the default value for a key leaf is ignored

 

augmented/configuration.yang:230877: warning: the default value for a key leaf is ignored

 

augmented/configuration.yang:273790: warning: the default value for a key leaf is ignored

 

augmented/configuration.yang:277381: warning: the default value for a key leaf is ignored

 

augmented/configuration.yang:316077: warning: the default value for a key leaf is ignored

 

augmented/configuration.yang:361528: warning: the default value for a key leaf is ignored

 

augmented/configuration.yang:494603: warning: the default value for a key leaf is ignored

 

augmented/configuration.yang:862719: warning: the default value for a key leaf is ignored

 

augmented/configuration.yang:865727: warning: the default value for a key leaf is ignored

 

augmented/configuration.yang:868193: warning: the default value for a key leaf is ignored

 

augmented/configuration.yang:911106: warning: the default value for a key leaf is ignored

 

augmented/configuration.yang:914697: warning: the default value for a key leaf is ignored

 

augmented/configuration.yang:953393: warning: the default value for a key leaf is ignored

 

augmented/configuration.yang:998844: warning: the default value for a key leaf is ignored

 

augmented/configuration.yang:1131919: warning: the default value for a key leaf is ignored

 

for f in `echo ../load-dir/*.fxs`; do \

 

n=`basename $f | sed 's/\.fxs//'`; \

 

/home/cisco/ncs4.3/bin/ncsc --java-disable-prefix --exclude-enums --fail-on-warnings --java-package com.example.nedjunos.namespaces --emit-java java/src/com/example/nedjunos/namespaces/${n}.java $f  || exit 1; \

 

done

 

Warning: The following symbols have been suppressed due to a

 

conflict with a different node name mapped to the same symbol:

 

'action-choice', 'action_choice', 'address-choice', 'address_choice',

 

'alarm-mode', 'alarm_mode', 'area-range', 'area_range',

 

'buffer-limit', 'buffer_limit', 'ca-name', 'ca_name',

 

'class-name', 'class_name', 'community-name', 'community_name',

 

'context-id', 'context_id', 'domain-name', 'domain_name',

 

'flag-name', 'flag_name', 'gateway-name', 'gateway_name',

 

'group-address', 'group-id', 'group-name', 'group_address',

 

'group_id', 'group_name', 'input-choice', 'input-excess-bandwidth-share',

 

'input_choice', 'input_excess_bandwidth_share', 'instance-name', 'instance_name',

 

'interface-name', 'interface_name', 'isid-list', 'isid_list',

 

'lcc-number', 'lcc_number', 'list-name', 'list_name',

 

'log-type', 'log_type', 'loose-strict-none', 'loose_strict_none',

 

'metric-offset', 'metric_offset', 'mode-choice', 'mode_choice',

 

'msisdn-choice', 'msisdn_choice', 'name-value', 'name_value',

 

'next-hop', 'next_hop', 'nexthop-value', 'nexthop_value',

 

'oam-period', 'oam_period', 'path-name', 'path_name',

 

'policy-name', 'policy_name', 'rib-name', 'rib_name',

 

'routing-instance-name', 'routing_instance_name', 'rule-set', 'rule_set',

 

'source-address', 'source_address', 'term-name', 'term_name',

 

'vlan-list', 'vlan-name', 'vlan_list', 'vlan_name'.

 

Use tailf:code-name on the conflicting nodes to avoid the conflict.

 

make: *** [ncsc-out/.done] Error 1

 

 

khgrant
Cisco Employee

 

It is given in the Makefile generated by ncs-make-package:

 

 

JFLAGS = --java-disable-prefix \

 

--exclude-enums \

 

--fail-on-warnings \

 

--java-package $(JAVA_PACKAGE).$(NS) \

 

--emit-java java/src/$(JDIR)/$(NS)

 

 

But as I mentioned, you/they should use the --no-java option to ncs-make-package when creating the package. Then there won't even be any invocation of 'ncsc --emit-java', and the question of what would happen with the warnings or errors it would generate if run is moot...

 

 

--Per

 

khgrant
Cisco Employee

 

Mohamed,

 

 

You can't use the Juniper official YANGs just yet. The Juniper devices don't announce these YANGs, which makes it impossible for NSO to know that these YANGs are applicable to the device in question. Juniper is aware, and it's on their roadmap to fix. Discussed this with them (again) just yesterday, here at the EANTC NETCONF/YANG interop.

 

 

Best,

 

/jan

 

khgrant
Cisco Employee

 

Thanks Jan,

 

 

Can you please expand on what do you mean by “announce” these yangs?

 

 

I guess this also answers my pending question:

 

If I have 2 netconf NEDs (one Junos and one XR-based), how will NSO know which device is which?

 

Since the only thing that we can specify when adding a new device to NSO is ned:netconf …

 

khgrant
Cisco Employee

 

Mohamed,

 

 

Can you please expand on what do you mean by “announce” these yangs?

 

 

Announce means mentioning them in the NETCONF <hello>, and if supported, in the yang-library. Since the Juniper devices currently do not announce support for these YANGs, NSO has no clue they might be relevant for these devices, even if you load them in a package.

 

 

I guess this also answers my pending question:

 

If I have 2 netconf NEDs (one Junos and one XR-based), how will NSO know which device is which?

 

Since the only thing that we can specify when adding a new device to NSO is ned:netconf …

 

 

Right. The NETCONF <hello> mechanism is supposed to handle that. When a NETCONF manager connects to a NETCONF device/server, they exchange information about what they support in a <hello> message. Since the junipers are currently playing secret agents with hidden capabilities, NSO won't know they might be capable of doing the stuff listed in the new Juniper YANGs. As I said, Juniper is aware of this and will fix it. Some day. Not all that soon, apparently. The old Tail-f YANGs for juniper devices still work, however.

 

 

/jan

 

khgrant
Cisco Employee

 

Thanks Jan

 

 

This is confirmed by looking at the Netconf traces on a J box:

 

 

<<<<in 16-Feb-2017::16:25:12.957 device=dis7-moria

 

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

 

  <capabilities>

 

    <capability>urn:ietf:params:netconf:base:1.0</capability>

 

    <capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>

 

    <capability>urn:ietf:params:netconf:capability:confirmed-commit:1.0</capability>

 

    <capability>urn:ietf:params:netconf:capability:validate:1.0</capability>

 

    <capability>urn:ietf:params:netconf:capability:url:1.0?scheme=http,ftp,file</capability>

 

    <capability>urn:ietf:params:xml:ns:netconf:base:1.0</capability>

 

    <capability>urn:ietf:params:xml:ns:netconf:capability:candidate:1.0</capability>

 

    <capability>urn:ietf:params:xml:ns:netconf:capability:confirmed-commit:1.0</capability>

 

    <capability>urn:ietf:params:xml:ns:netconf:capability:validate:1.0</capability>

 

    <capability>urn:ietf:params:xml:ns:netconf:capability:url:1.0?protocol=http,ftp,file</capability>

 

   <capability>http://xml.juniper.net/netconf/junos/1.0</capability>

 

    <capability>http://xml.juniper.net/dmi/system/1.0</capability>

 

  </capabilities>

 

 

Whereas a Cisco box response is more like that:

 

 

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

 

<capabilities>

 

  <capability>urn:ietf:params:netconf:base:1.1</capability>

 

  <capability>urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring?deviation=cisco-xr-ietf-netconf-monitoring-deviations</capability>

 

  <capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>

 

  <capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability>

 

  <capability>urn:ietf:params:netconf:capability:validate:1.1</capability>

 

  <capability>urn:ietf:params:netconf:capability:confirmed-commit:1.1</capability>

 

  <capability>http://cisco.com/ns/yang/Cisco-IOS-XR-ip-domain-cfg?module=Cisco-IOS-XR-ip-domain-cfg&amp;revision=2015-05-13</capability>

 

  <capability>http://cisco.com/ns/yang/Cisco-IOS-XR-mpls-te-cfg?module=Cisco-IOS-XR-mpls-te-cfg&amp;revision=2015-11-09</capability>

 

  <capability>http://cisco.com/ns/yang/Cisco-IOS-XR-ipv6-ma-oper?module=Cisco-IOS-XR-ipv6-ma-oper&amp;revision=2015-10-20</capability>

 

  <capability>http://cisco.com/ns/yang/Cisco-IOS-XR-infra-alarm-logger-datatypes?module=Cisco-IOS-XR-infra-alarm-logger-datatypes&amp;revision=2015-01-07</capability>

 

Content for Community-Ad

This widget could not be displayed.