cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
932
Views
5
Helpful
8
Replies

Junos Conf Class of Service unit not accepting wildcards

ldacol
Level 1
Level 1

Hello,

 

I am observing Module errors during conversions JSON <-> XML when using wildcards in the unit name leaf.

 

XML Code

 

<configuration xmlns="http://yang.juniper.net/junos/conf/root">
<class-of-service xmlns="http://yang.juniper.net/junos/conf/class-of-service">
    <interfaces>
      <interface>
        <name>et-*/*/*</name>
        <scheduler-map>COS-SCHEDULER-MAP</scheduler-map>
        <unit>
          <name>*</name>
          <classifiers>
            <dscp>
              <name>COS-DSCP</name>
            </dscp>
          </classifiers>
        </unit>
      </interface>
    </interfaces>
</class-of-service>
</configuration>

Runtime error:

 

 

python convert.py -x test07.xml
Traceback (most recent call last):
  File "convert.py", line 117, in <module>
    print(yang_xml_to_json(ARGS['xml_file']))
  File "convert.py", line 104, in yang_xml_to_json
    decoded_xml = CODEC.decode(XML_PROVIDER, config_xml)
  File "/opt/neteng/lib/python3.6/site-packages/ydk/errors/error_handler.py", line 112, in helper
    return func(self, provider, entity, *args, **kwargs)
  File "/opt/neteng/lib/python3.6/site-packages/ydk/services/codec_service.py", line 140, in decode
    return self._decode(provider, payload_holder, subtree)
  File "/opt/neteng/lib/python3.6/site-packages/ydk/services/codec_service.py", line 174, in _decode
    root_data_node = codec_service.decode(root_schema, payload, provider.encoding)
RuntimeError: YModelError: Invalid value "*" in "name" element. Path: /junos-conf-root:configuration/junos-conf-class-of-service:class-of-service/interfaces/interface[name='et-*/*/*']/unit[name='*']/name

 

Junos Yang module allows wildcards and

https://github.com/Juniper/yang/blob/master/18.4/18.4R3/junos/conf/junos-conf-class-of-service%402019-01-01.yang#L3583

 

Any comment, insight appreciated

Thank you,

Luca

1 Accepted Solution

Accepted Solutions

As a workaround updated Juniper Yang modules with the proper escaping sequence and recreated the bundle

View solution in original post

8 Replies 8

yangorelik
Spotlight
Spotlight
Hi Luca
Please check the YANG definition for the leaf 'name':
leaf name {
description "Interface name (or wildcard)";
type union {
type jt:interface-device-wildcard;
type string {
pattern "<.*>|$.*";
}
}
}
}
The value in your XML does not match the pattern. Check it with any online lint tool. You need to change either the YANG definition or the interface name. Based on the pattern your value should be '<et-*/*/*>'.
Yan Gorelik
YDK Solutions

Hi Yan,

Thanks for the reply. I admit it can be confusing but I don't feel the error message refers to the interface name but rather to the unit section:

        <unit>
          <name>*</name>

In fact, as soon as the "unit name *" is replaced with a numerical value such as:

<configuration xmlns="http://yang.juniper.net/junos/conf/root">
<class-of-service xmlns="http://yang.juniper.net/junos/conf/class-of-service">
    <interfaces>
      <interface>
        <name>et-*/*/*</name>
        <scheduler-map>COS-SCHEDULER-MAP</scheduler-map>
        <unit>
          <name>0</name>
          <classifiers>
            <dscp>
              <name>COS-DSCP</name>
            </dscp>
          </classifiers>
        </unit>
      </interface>
    </interfaces>
</class-of-service>
</configuration>

the conversion finalizes correctly. The above snippet of code is taken from a Juniper device in production. If I look the yang model for the unit section (below) I think * under the unit section would be a legitimate configuration as it should match the "\*" part of the regexp

     list unit {
       key name;
       description "Logical interface unit (or wildcard)";
       leaf name {
         description "Logical unit number";
         type union {
           type string {
             pattern "\*";
           }
           type union {
             type string {
               pattern "<.*>|$.*";
             }
             type uint32 {
               range "0 .. 1073741823";
             }
           }
         }
       }

Thank you!

Luca

Hi Yan,

I feel the issue is similar to https://community.cisco.com/t5/yang-tools/juniper-openconfig-bgp-failure/m-p/3997137#M1358 and https://github.com/CESNET/libyang/issues/978 where Juniper uses "\*" in the pattern. I can modify the yang and replace the double quotes for single ones but the pattern is present across all the versions. Would the fix you applied in https://community.cisco.com/t5/yang-tools/juniper-openconfig-bgp-failure/m-p/3997137#M1358 cover this as use case as well?

Thank you,

Luca

 

 

The libyang fix should work for any character in YDK release 0.8.5 and up. Let me know if it does not work.

Yan

Hi Yan,

cloned the libyang fork from your repo and attempted to make however it fails. (libyang from https://github.com/CESNET/libyang.git compiles without any issue). 

libyang.so.2 from CESNET is installed as you can see from the code below, however I am unclear which yang_static library the ld is looking for. System is a RHEL 7.9

[  2%] Building C object CMakeFiles/yangobj.dir/src/common.c.o
[  5%] Building C object CMakeFiles/yangobj.dir/src/context.c.o
[  8%] Building C object CMakeFiles/yangobj.dir/src/log.c.o
[ 10%] Building C object CMakeFiles/yangobj.dir/src/dict.c.o
[ 13%] Building C object CMakeFiles/yangobj.dir/src/resolve.c.o
[ 16%] Building C object CMakeFiles/yangobj.dir/src/validation.c.o
[ 18%] Building C object CMakeFiles/yangobj.dir/src/xml.c.o
[ 21%] Building C object CMakeFiles/yangobj.dir/src/parser.c.o
[ 24%] Building C object CMakeFiles/yangobj.dir/src/parser_yin.c.o
[ 27%] Building C object CMakeFiles/yangobj.dir/src/parser_xml.c.o
[ 29%] Building C object CMakeFiles/yangobj.dir/src/parser_json.c.o
[ 32%] Building C object CMakeFiles/yangobj.dir/src/parser_yang_bis.c.o
[ 35%] Building C object CMakeFiles/yangobj.dir/src/parser_yang_lex.c.o
[ 37%] Building C object CMakeFiles/yangobj.dir/src/parser_yang.c.o
[ 40%] Building C object CMakeFiles/yangobj.dir/src/tree_schema.c.o
[ 43%] Building C object CMakeFiles/yangobj.dir/src/tree_data.c.o
[ 45%] Building C object CMakeFiles/yangobj.dir/src/extensions.c.o
[ 48%] Building C object CMakeFiles/yangobj.dir/src/printer.c.o
[ 51%] Building C object CMakeFiles/yangobj.dir/src/xpath.c.o
[ 54%] Building C object CMakeFiles/yangobj.dir/src/printer_yang.c.o
[ 56%] Building C object CMakeFiles/yangobj.dir/src/printer_yin.c.o
[ 59%] Building C object CMakeFiles/yangobj.dir/src/printer_xml.c.o
[ 62%] Building C object CMakeFiles/yangobj.dir/src/printer_tree.c.o
[ 64%] Building C object CMakeFiles/yangobj.dir/src/printer_info.c.o
[ 67%] Building C object CMakeFiles/yangobj.dir/src/printer_json.c.o
[ 70%] Building C object CMakeFiles/yangobj.dir/src/yang_types.c.o
[ 70%] Built target yangobj
Linking C shared library libyang.so
[ 70%] Built target yang
[ 72%] Building C object CMakeFiles/yang2yin.dir/tools/yang2yin/main.c.o
Linking C executable yang2yin
[ 72%] Built target yang2yin
[ 75%] Building C object CMakeFiles/yanglint.dir/tools/lint/main.c.o
[ 78%] Building C object CMakeFiles/yanglint.dir/tools/lint/main_ni.c.o
[ 81%] Building C object CMakeFiles/yanglint.dir/tools/lint/commands.c.o
[ 83%] Building C object CMakeFiles/yanglint.dir/tools/lint/completion.c.o
[ 86%] Building C object CMakeFiles/yanglint.dir/tools/lint/configuration.c.o
[ 89%] Building C object CMakeFiles/yanglint.dir/linenoise/linenoise.c.o
Linking C executable yanglint
/bin/ld: cannot find -lyang_static
collect2: error: ld returned 1 exit status
make[2]: *** [yanglint] Error 1
make[1]: *** [CMakeFiles/yanglint.dir/all] Error 2
make: *** [all] Error 2


ldconfig -p | grep yang
libyang.so.2 (libc6,x86-64) => /lib64/libyang.so.2

I don't see the fix on your fork being ported to the libyang library.  Are you planning to maintain this fork and/or get aligned with the CESNET repo?

Thank you,

Luca

As a workaround updated Juniper Yang modules with the proper escaping sequence and recreated the bundle

The YDK code needed to make few adjustments to the Libyang code, therefore the fork will be maintained in near future. In regards to your issue, I just checked the fix and can confirm that it is present in the master branch and it was applied to the YDK-0.8.5.

Please do not use the CESNET version of the Libyang code, because it is not compatible with the YDK-0.8.x code.

Thank you

Yan.

Yan Gorelik
YDK Solutions

I am still seeing a few issues when attempting to compile and make the libyang fork from your repo related to ld not being able to find yang_static library (shared the error earlier). Is there any additional requirement in order to compile your fork vs the CESNET as I was able to compile it without any issue.

 

Aside from that with the Juniper modules updated with the proper escaping I was able to get the code converted. What I am seeing though is a separate error when converting back to XML from YAML which was generated from YDK which I will document separately.