cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
312
Views
2
Helpful
27
Replies
khgrant
Cisco Employee

Juniper NED handling

 

Hello team,

do we have an expert for Juniper NED in the group?

 

2 things I need to clarify:

 

1. "statement must contain additional statements"

The device replies with that “warning” in rpc-error message.

Has somebody experience what the device would like to see ? Is this related to netconf “replace” or similar tags

 

2. NCS inconsistency with device

 

I see that despite the above warning NCS completes the transaction. The device only holds a subset of the target config, but NCS believe the transaction succeeded. Please see the example below. I imagine this occurs because Juniper still closes the rpc-reply with "<ok/>”.  

Regards

 

Mike

 

 

 

Logs:

 

>>>>out 7-Aug-2015::15:43:22.193 device=MS3-EA10 session-id=50151

?xml version="1.0" encoding="UTF-8"?>

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="4">

<edit-config xmlns:nc='urn:ietf:params:xml:ns:netconf:base:1.0'><target><candidate/></target><test-option>test-then-set</test-option><config>

<configuration xmlns="http://xml.juniper.net/xnm/1.1/xnm"><interfaces><interface><name>e3-3/0/1</name><speed>oc3</speed><unit><name>0</name><bandwidth>20764</bandwidth><description>ac(0132106-1-1)#u#coco##44L/SK/941941-613131/120005#Router_4441000001_120005</description><family><inet6><address><name>2003:4:f023:220::1/64</name></address><sampling><input></input></sampling><rpf-check></rpf-check></inet6><inet><sampling><input></input></sampling><unnumbered-address><source>lo0.0</source></unnumbered-address><rpf-check></rpf-check></inet></family></unit></interface></interfaces><class-of-service><interfaces><interface><name>e3-3/0/1</name><scheduler-map>to-line-E3-Shape-20764</scheduler-map><unit><name>0</name><classifiers><inet-precedence><classifier-name>Classify-IP-Public</classifier-name></inet-precedence></classifiers></unit></interface></interfaces></class-of-service><routing-options><rib><name>inet6.0</name><static><route><name>2003:4:f023:530::1/128</name><next-hop>2003:4:f023:220::2</next-hop></route><route><name>2003:4:f023:8400::/60</name><next-hop>2003:4:f023:220::22</next-hop></route></static></rib><static><route><name>80.156.121.16/28</name><next-hop>e3-3/0/1</next-hop></route><route><name>80.156.121.195/32</name><next-hop>e3-3/0/1</next-hop></route></static></routing-options></configuration></config></edit-config>

</rpc>

>>>>out 7-Aug-2015::15:43:22.194 device=MS3-EA10 session-id=50151

EOM

>>>>out 7-Aug-2015::15:43:22.194 device=MS3-EA10 session-id=50151

<?xml version="1.0" encoding="UTF-8"?>

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="5">

<validate><source><candidate/></source>

</validate>

</rpc>

>>>>out 7-Aug-2015::15:43:22.194 device=MS3-EA10 session-id=50151

EOM

<<<<in 7-Aug-2015::15:43:22.199 device=MS3-EA10 session-id=50151

<rpc-reply xmlns:junos="http://xml.juniper.net/junos/13.3I0/junos" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="4">

<<<<in 7-Aug-2015::15:43:22.318 device=MS3-EA10 session-id=50151

<rpc-error>

<<<<in 7-Aug-2015::15:43:22.319 device=MS3-EA10 session-id=50151

<error-severity>warning</error-severity>

<<<<in 7-Aug-2015::15:43:22.320 device=MS3-EA10 session-id=50151

<error-message>mgd: statement must contain additional statements</error-message>

<<<<in 7-Aug-2015::15:43:22.321 device=MS3-EA10 session-id=50151

</rpc-error>

<<<<in 7-Aug-2015::15:43:22.321 device=MS3-EA10 session-id=50151

<rpc-error>

<<<<in 7-Aug-2015::15:43:22.322 device=MS3-EA10 session-id=50151

<error-severity>warning</error-severity>

<<<<in 7-Aug-2015::15:43:22.322 device=MS3-EA10 session-id=50151 

<error-message>mgd: statement must contain additional statements</error-message>

<<<<in 7-Aug-2015::15:43:22.322 device=MS3-EA10 session-id=50151

</rpc-error>

<<<<in 7-Aug-2015::15:43:22.323 device=MS3-EA10 session-id=50151

<rpc-error> 

<<<<in 7-Aug-2015::15:43:22.323 device=MS3-EA10 session-id=50151

<error-severity>warning</error-severity>

<<<<in 7-Aug-2015::15:43:22.323 device=MS3-EA10 session-id=50151

<error-message>mgd: statement must contain additional statements</error-message>

<<<<in 7-Aug-2015::15:43:22.324 device=MS3-EA10 session-id=50151

</rpc-error> 

<<<<in 7-Aug-2015::15:43:22.326 device=MS3-EA10 session-id=50151 

<ok/>

<<<<in 7-Aug-2015::15:43:22.327 device=MS3-EA10 session-id=50151

</rpc-reply>

<<<<in 7-Aug-2015::15:43:22.327 device=MS3-EA10 session-id=50151

]]>]]>

<<<<in 7-Aug-2015::15:43:22.328 device=MS3-EA10 session-id=50151

<rpc-reply xmlns:junos="http://xml.juniper.net/junos/13.3I0/junos" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="5">

<<<<in 7-Aug-2015::15:43:22.331 device=MS3-EA10 session-id=50151

<commit-results>

<<<<in 7-Aug-2015::15:43:28.998 device=MS3-EA10 session-id=50151

</commit-results> 

<<<<in 7-Aug-2015::15:43:28.999 device=MS3-EA10 session-id=50151 

<ok/>

<<<<in 7-Aug-2015::15:43:28.999 device=MS3-EA10 session-id=50151

</rpc-reply>

<<<<in 7-Aug-2015::15:43:28.999 device=MS3-EA10 session-id=50151

]]>]]>

 

 

1 ACCEPTED SOLUTION

Accepted Solutions
khgrant
Cisco Employee

 

To my understanding this is a bug in the implementation of NETCONF.

 

From RFC4741/NETCONF:

 

  1. 4.4. <ok> Element

 

The <ok> element is sent in <rpc-reply> messages if no errors or warnings occurred during the processing of an <rpc> request. For

 

example:

<rpc-reply message-id="101"

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

   <ok/>

</rpc-reply>

 

and also the rpc-error element should not contain the element <ok/>

 

We need to somehow code around this, it is not the first time

 

/Dag

 

View solution in original post

27 REPLIES 27
khgrant
Cisco Employee

 

Hi Mike,

First can you supply the NED version you are using and Junos Version of the router in question?

-Dan

 

khgrant
Cisco Employee

 

Hi Dan,

 

Junos 13.3

 

<rpc-reply xmlns:junos="http://xml.juniper.net/junos/13.3I0/junos"

xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="5”>

 

Juniper NED from NCS 3.4.1 

    <file>ncs-3.4.1_HEAD-juniper-junos-3.0.14.tar.gz</file>

 

Mike

 

 

khgrant
Cisco Employee

 

Hi Mike,

Perhaps it might be worth trying this with the most recent NED as the one that comes with 3.4.1 isn’t the latest.

 

-Dan

 

khgrant
Cisco Employee

 

Hi Dan,

 

 

I now used the most recent Juniper NED from devnet which is "ncs-3.4-juniper-junos-3.0.15.tar.gz”.

The result is exact the same as before, where: 

    1. The router has only a subset of the configuration.
    2. NSO believe the whole service is deployed despite the rpc-error-reply.

On router:

 

e3-3/0/1 {

description "ac(0132106-1-1)#u#coco##44L/SK/941941-613131/120005#Router_4441000001_120005";

    clocking external;

encapsulation ppp;

}

 

Regards Mike

 

(in green highlighted what has been configured on the router)

 

>>>>out 8-Aug-2015::15:34:39.711 device=MS3-EA10 session-id=67179

<?xml version="1.0" encoding="UTF-8"?>

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="4"> 

<edit-config xmlns:nc='urn:ietf:params:xml:ns:netconf:base:1.0'><target><candidate/></target><test-option>test-then-set</test-option><config>

<configuration xmlns="http://xml.juniper.net/xnm/1.1/xnm"><interfaces><interface><name>e3-3/0/1</name><description>ac(0132106-1-1)#u#coco##44L/SK/941941-613131/120005#Router_4441000001_120005</description><encapsulation>ppp</encapsulation><clocking><external></external></clocking><speed>oc3</speed><unit><name>0</name><bandwidth>20764</bandwidth><description>ac(0132106-1-1)#u#coco##44L/SK/941941-613131/120005#Router_4441000001_120005</description><family><inet6><address><name>2003:4:f023:220::1/64</name></address><sampling><input></input></sampling><rpf-check></rpf-check></inet6><inet><sampling><input></input></sampling><unnumbered-address><source>lo0.0</source></unnumbered-address><rpf-check></rpf-check></inet></family></unit></interface></interfaces><class-of-service><interfaces><interface><name>e3-3/0/1</name><scheduler-map>to-line-E3-Shape-20764</scheduler-map><unit><name>0</name><classifiers><inet-precedence><classifier-name>Classify-IP-Public</classifier-name></inet-precedence></classifiers></unit></interface></interfaces></class-of-service><routing-options><rib><name>inet6.0</name><static><route><name>2003:4:f023:530::1/128</name><next-hop>2003:4:f023:220::2</next-hop></route><route><name>2003:4:f023:8400::/60</name><next-hop>2003:4:f023:220::22</next-hop></route></static></rib><static><route><name>80.156.121.16/28</name><next-hop>e3-3/0/1</next-hop></route><route><name>80.156.121.195/32</name><next-hop>e3-3/0/1</next-hop></route></static></routing-options></configuration></config></edit-config>

</rpc>

>>>>out 8-Aug-2015::15:34:39.712 device=MS3-EA10 session-id=67179

EOM

>>>>out 8-Aug-2015::15:34:39.712 device=MS3-EA10 session-id=67179

<?xml version="1.0" encoding="UTF-8"?>

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="5">

<validate><source><candidate/></source>

</validate>

</rpc>

>>>>out 8-Aug-2015::15:34:39.712 device=MS3-EA10 session-id=67179

EOM

<<<<in 8-Aug-2015::15:34:39.716 device=MS3-EA10 session-id=67179

<rpc-reply xmlns:junos="http://xml.juniper.net/junos/13.3I0/junos" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="4">

<<<<in 8-Aug-2015::15:34:39.851 device=MS3-EA10 session-id=67179 

<rpc-error>

<<<in 8-Aug-2015::15:34:39.853 device=MS3-EA10 session-id=67179

<error-severity>warning</error-severity>

<<<<in 8-Aug-2015::15:34:39.853 device=MS3-EA10 session-id=67179

<error-message>mgd: statement must contain additional statements</error-message>

<<<<in 8-Aug-2015::15:34:39.854 device=MS3-EA10 session-id=67179

</rpc-error>

<<<<in 8-Aug-2015::15:34:39.854 device=MS3-EA10 session-id=67179

<rpc-error>

<<<<in 8-Aug-2015::15:34:39.855 device=MS3-EA10 session-id=67179

<error-severity>warning</error-severity>

<<<<in 8-Aug-2015::15:34:39.855 device=MS3-EA10 session-id=67179

<error-message>mgd: statement must contain additional statements</error-message>

<<<<in 8-Aug-2015::15:34:39.855 device=MS3-EA10 session-id=67179

</rpc-error>

<<<<in 8-Aug-2015::15:34:39.856 device=MS3-EA10 session-id=67179

<rpc-error>

<<<<in 8-Aug-2015::15:34:39.856 device=MS3-EA10 session-id=67179

<error-severity>warning</error-severity>

<<<<in 8-Aug-2015::15:34:39.856 device=MS3-EA10 session-id=67179

<error-message>mgd: statement must contain additional statements</error-message>

<<<<in 8-Aug-2015::15:34:39.857 device=MS3-EA10 session-id=67179

</rpc-error>

<<<<in 8-Aug-2015::15:34:39.857 device=MS3-EA10 session-id=67179

<ok/>

<<<<in 8-Aug-2015::15:34:39.858 device=MS3-EA10 session-id=67179

</rpc-reply>

<<<<in 8-Aug-2015::15:34:39.858 device=MS3-EA10 session-id=67179

]]>]]> 

<<<<in 8-Aug-2015::15:34:39.859 device=MS3-EA10 session-id=67179

<rpc-reply xmlns:junos="http://xml.juniper.net/junos/13.3I0/junos" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="5">

<<<<in 8-Aug-2015::15:34:39.863 device=MS3-EA10 session-id=67179

<commit-results>

<<<<in 8-Aug-2015::15:34:46.022 device=MS3-EA10 session-id=67179

</commit-results>

<<<<in 8-Aug-2015::15:34:46.022 device=MS3-EA10 session-id=67179

<ok/>

<<<<in 8-Aug-2015::15:34:46.023 device=MS3-EA10 session-id=67179

</rpc-reply>

<<<<in 8-Aug-2015::15:34:46.023 device=MS3-EA10 session-id=67179

]]>]]>

>>>>out 8-Aug-2015::15:34:46.024 device=MS3-EA10 session-id=67179

<?xml version="1.0" encoding="UTF-8"?>

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="6">

<commit/></rpc>

>>>>out 8-Aug-2015::15:34:46.024 device=MS3-EA10 session-id=67179

 

khgrant
Cisco Employee

 

Hi Mike,

Well, NCS shouldn’t be indicating the transaction was successful if its not. We probably need to get a full trace and see what engineering thinks.

-Dan

 

khgrant
Cisco Employee

 

My guess is NCS only checking for <ok> and ignored the error.

 

 

https://tools.ietf.org/html/rfc6241#section-4.4

 

   The <ok> element is sent in <rpc-reply> messages if no errors or
   warnings occurred during the processing of an <rpc> request, and no
   data was returned from the operation.

 

 

I read this as Juniper should not send <ok> in first place, but lets wait for our dev team to check if NCS behaviour could be improved, too.

 

 

Mike

 

khgrant
Cisco Employee

 

To my understanding this is a bug in the implementation of NETCONF.

 

From RFC4741/NETCONF:

 

  1. 4.4. <ok> Element

 

The <ok> element is sent in <rpc-reply> messages if no errors or warnings occurred during the processing of an <rpc> request. For

 

example:

<rpc-reply message-id="101"

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

   <ok/>

</rpc-reply>

 

and also the rpc-error element should not contain the element <ok/>

 

We need to somehow code around this, it is not the first time

 

/Dag

 

View solution in original post

khgrant
Cisco Employee

 

Isn’t Juniper using the tail-f confD deamon for netconf?

 

klaus

 

khgrant
Cisco Employee

 

Nope, they have their own impl.

/klacke

 

khgrant
Cisco Employee

 

thanks for clarification.

I think I’ve seen in some of our older slides that Juniper is using confD.

So this is wrong and we should not reference that any more?

klaus

 

khgrant
Cisco Employee

 

Klaus,

 

I think you may have seen slides of some internal experimentation project. But the netconf support has been there for quite sometime, there are some deviations from the standard though.

 

Thanks,

Kalyan

 

khgrant
Cisco Employee

 

Many thanks.

So do we agree on the below:

 

a) Juniper to fix there Netconf implementation

b) We will harden NCS to prioritize rpc-error vs. ok   or reject reply as non-compliant

As I cannot open RT’s, Dag/Klacke could you do so ?

 

Regards

 

Mike

 

 

khgrant
Cisco Employee

  Sorry, I wasn't reading the entire thread when replying.

   

Two things:

 

<rpc-error>

<error-severity>warning</error-severity>

<error-message>mgd: statement must contain additional statements</error-message>

</rpc-error>

 

This comes from a minor bug in NCS, sometimes, we send list entries

with just the key in it, no data at all. This is irritating, but not the end of the world. We've had this back and forth over the years, and it's pretty irritating that this bad behaviour is back again. Grrr.

 

 

If you look at the NETCONF trace, you'll see these msgs.

 

  1. 2. The rpc-reply itself is actually ok. The errors are warnings only, we drop the warnings and look at the <ok/> and get happy. Thus, the bug that we send empty list entries should be fixed.

 

I created internal tail-f trac ticket on this one. Trac #13311. We're doing the right thing here, ignoring the warnings and going for the final <ok/>

 

/klacke

 

 

khgrant
Cisco Employee

 

Hi Klacke,

 

somewhere in between I recognized that the  <error-message>mgd: statement must contain additional  messages were caused by the service trying to configure an innterface parameter that is not supported on that card.  After fixing that the warnings disappeared and the service was correctly configured on the device.

 

Still I read in the RFC that ok should only be sent if no error or warning occurred. So I am a bit surprised that we accept such reply, but I may miss something ?

 

Mike

 

Content for Community-Ad

This widget could not be displayed.