cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
672
Views
3
Helpful
2
Replies
Beginner

How does the Junos NED work?

Hi community,

I'm trying to integrate a new Junos platform into NSO. The juniper-junos NED is loaded.

The sync-from fails:

admin@ncs> request devices sync-from device [ jdm ]

sync-result {

    device jdm

    result false

    info Device jdm does not advertise any known YANG modules

}


The trace indicates that the discovery stops right after the Netconf hello + capability exchange.


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

   <nc:capabilities>

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

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

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

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

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

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

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

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

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

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

    <nc:capability>urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring</nc:capability>

  </nc:capabilities>

  <nc:session-id>12216</nc:session-id>

</nc:hello>


Compared to another Junos device which is properly discovered by NSO, two capabilities (Yang namespaces) are missing:


http://xml.juniper.net/dmi/system/1.0

http://xml.juniper.net/netconf/junos/1.0

Do these capabilities really make the difference?

I can't find a reference to these URIs in the Junos NED code... The namespace for the Junos NED is http://xml.juniper.net/xnm/1.1/xnm. Where in the code is it written that these capabilities must be present in order to go on with the get-config? How does NSO know that the valid Yang models for this devices are the ones from the Junos NED?

How can I force the Junos NED (or my own NED) to be used for these specific Junos platform which doesn't announce the mentioned capabilities?

In short, how does the Junos NED work? :-)

Thanks,

Sylvain

Everyone's tags (5)
1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Cisco Employee

Re: How does the Junos NED work?

You are quite right that those namespace announcements make all the difference. If there is no mention of juniper in the hello message, how would NSO know it's talking to a juniper device? Or which YANG modules the device supports?

I'm not sure exactly what code you are referring to when you say "Junos NED code". Since the Junos NED is a NETCONF NED package, there is no code to look at. There is, however, special code inside NSO that handles the Juniper case. This code recognizes the http://xml.juniper.net/netconf/junos/1.0 string in hello and translates to the appropriate set of capabilities and YANG namespaces (http://xml.juniper.net/xnm/1.1/xnm) for Juniper devices.

There is no way to trigger this code by any setting in NSO, if the device doesn't announce the given string in hello. You'd have to find a way to make the device make its announcements in hello properly, if possible. What kind of device is this, anyway? I haven't seen this particular behavior before. Do you have a contact name at Juniper related to this device? (I thought I'd ask just in case)

Maybe I should mention that the Juniper NETCONF/YANG hello behavior (including the behavior that actually works with our special code in NSO) is a violation of the YANG RFCs so that this is completely clear.

View solution in original post

2 REPLIES 2
Highlighted
Cisco Employee

Re: How does the Junos NED work?

You are quite right that those namespace announcements make all the difference. If there is no mention of juniper in the hello message, how would NSO know it's talking to a juniper device? Or which YANG modules the device supports?

I'm not sure exactly what code you are referring to when you say "Junos NED code". Since the Junos NED is a NETCONF NED package, there is no code to look at. There is, however, special code inside NSO that handles the Juniper case. This code recognizes the http://xml.juniper.net/netconf/junos/1.0 string in hello and translates to the appropriate set of capabilities and YANG namespaces (http://xml.juniper.net/xnm/1.1/xnm) for Juniper devices.

There is no way to trigger this code by any setting in NSO, if the device doesn't announce the given string in hello. You'd have to find a way to make the device make its announcements in hello properly, if possible. What kind of device is this, anyway? I haven't seen this particular behavior before. Do you have a contact name at Juniper related to this device? (I thought I'd ask just in case)

Maybe I should mention that the Juniper NETCONF/YANG hello behavior (including the behavior that actually works with our special code in NSO) is a violation of the YANG RFCs so that this is completely clear.

View solution in original post

Highlighted
Beginner

Re: How does the Junos NED work?

Hi Jan,

Thanks a lot for these details.

I'm not sure exactly what code you are referring to when you say "Junos NED code". Since the Junos NED is a NETCONF NED package, there is no code to look at. There is, however, special code inside NSO that handles the Juniper case. This code recognizes the http://xml.juniper.net/netconf/junos/1.0 string in hello and translates to the appropriate set of capabilities and YANG namespaces (http://xml.juniper.net/xnm/1.1/xnm) for Juniper devices.

"Junos NED code" = anything which makes the mapping. But your answer is clear: the login resides in NSO itself.

There is no way to trigger this code by any setting in NSO, if the device doesn't announce the given string in hello. You'd have to find a way to make the device make its announcements in hello properly, if possible. What kind of device is this, anyway? I haven't seen this particular behavior before. Do you have a contact name at Juniper related to this device? (I thought I'd ask just in case)

This specific device is a NFX250. This is a uCPE, in which reside a Junos VM called JDM, from which VNF's are instantiated. We will mention this issue to the product team, if you are interested I can probably forward the information we'll get.

NFX250 Network Services Platform – Juniper Networks

Maybe I should mention that the Juniper NETCONF/YANG hello behavior (including the behavior that actually works with our special code in NSO) is a violation of the YANG RFCs so that this is completely clear.

Totally clear, thank you :-)