Writing to ConfD device


Jonas Martensson
 

Hi,

we have problems when TransportPCE is trying to write data to a device running ConfD. It seems ODL can't parse the <ok> element in the rpc-reply to an edit-config rpc. Here are relevant snippets from karaf.log:

java.lang.IllegalArgumentException: Failed to parse RPC response [rpc-reply: null]

Caused by: javax.xml.stream.XMLStreamException: Schema for node with name ok and namespace urn:ietf:params:xml:ns:netconf:base:1.0 does not exist at AbsoluteSchemaPath{path=[(urn:ietf:params:xml:ns:netconf:base:1.0?revision=2011-06-01)edit-config, (urn:ietf:params:xml:ns:netconf:base:1.0?revision=2011-06-01)output]}

From the ConfD Netconf server perspective everything looks fine and the data is actually stored in the database but since TransportPCE doesn't get any confirmation the operation fails and ODL reconnects the Netconf session. I found this old issue which seems related to our problem but it doesn't offer any solution:

https://jira.opendaylight.org/browse/NETCONF-90

Does anyone know how to get TransportPCE to play nice with ConfD?

/Jonas
 


Guillaume Lambert
 

Hi Jonas

 

As I can understand it, this question should be better be addressed to the Netconf project.
This looks like the problem that described in the URL https://wiki.opendaylight.org/view/File:Feedback_on_ODL_netconf.pdf at slide 4.

 

To help you,  you will find in the TranportPCE repo a “debug_tools” folder at the root.

There is a script to hijack the netconf session that can modify capabilities on the fly.

 

Hope this help

Guillaume

 

From: Transportpce-dev@... [mailto:Transportpce-dev@...] On Behalf Of Jonas Martensson
Sent: jeudi 10 octobre 2019 14:25
To: Transportpce-dev@...
Subject: [Transportpce-dev] Writing to ConfD device

 

Hi,

we have problems when TransportPCE is trying to write data to a device running ConfD. It seems ODL can't parse the <ok> element in the rpc-reply to an edit-config rpc. Here are relevant snippets from karaf.log:

java.lang.IllegalArgumentException: Failed to parse RPC response [rpc-reply: null]

Caused by: javax.xml.stream.XMLStreamException: Schema for node with name ok and namespace urn:ietf:params:xml:ns:netconf:base:1.0 does not exist at AbsoluteSchemaPath{path=[(urn:ietf:params:xml:ns:netconf:base:1.0?revision=2011-06-01)edit-config, (urn:ietf:params:xml:ns:netconf:base:1.0?revision=2011-06-01)output]}

From the ConfD Netconf server perspective everything looks fine and the data is actually stored in the database but since TransportPCE doesn't get any confirmation the operation fails and ODL reconnects the Netconf session. I found this old issue which seems related to our problem but it doesn't offer any solution:

https://jira.opendaylight.org/browse/NETCONF-90

Does anyone know how to get TransportPCE to play nice with ConfD?

/Jonas
 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.


Jonas Martensson
 

Thanks Guillaume,

 

I don’t understand exactly the problem described on slide 4 in your presentation. In our case the ConfD device supports <get-schema> and the ietf-netconf@... module is retrieved and stored in the karaf cache/schema directory. Is this a problem? What is meant by “the netconf capabilities must be overloaded when mounting the device in REST” and how is this accomplished?

 

/Jonas

 

From: guillaume.lambert@... <guillaume.lambert@...>
Sent: den 10 oktober 2019 14:59
To: Jonas Mårtensson <jonas.martensson@...>; Transportpce-dev@...
Subject: RE: [Transportpce-dev] Writing to ConfD device

 

Hi Jonas

 

As I can understand it, this question should be better be addressed to the Netconf project.
This looks like the problem that described in the URL https://wiki.opendaylight.org/view/File:Feedback_on_ODL_netconf.pdf at slide 4.

 

To help you,  you will find in the TranportPCE repo a “debug_tools” folder at the root.

There is a script to hijack the netconf session that can modify capabilities on the fly.

 

Hope this help

Guillaume

 

From: Transportpce-dev@... [mailto:Transportpce-dev@...] On Behalf Of Jonas Martensson
Sent: jeudi 10 octobre 2019 14:25
To: Transportpce-dev@...
Subject: [Transportpce-dev] Writing to ConfD device

 

Hi,

we have problems when TransportPCE is trying to write data to a device running ConfD. It seems ODL can't parse the <ok> element in the rpc-reply to an edit-config rpc. Here are relevant snippets from karaf.log:

java.lang.IllegalArgumentException: Failed to parse RPC response [rpc-reply: null]

Caused by: javax.xml.stream.XMLStreamException: Schema for node with name ok and namespace urn:ietf:params:xml:ns:netconf:base:1.0 does not exist at AbsoluteSchemaPath{path=[(urn:ietf:params:xml:ns:netconf:base:1.0?revision=2011-06-01)edit-config, (urn:ietf:params:xml:ns:netconf:base:1.0?revision=2011-06-01)output]}

From the ConfD Netconf server perspective everything looks fine and the data is actually stored in the database but since TransportPCE doesn't get any confirmation the operation fails and ODL reconnects the Netconf session. I found this old issue which seems related to our problem but it doesn't offer any solution:

https://jira.opendaylight.org/browse/NETCONF-90

Does anyone know how to get TransportPCE to play nice with ConfD?

/Jonas
 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.


Guillaume Lambert
 

I don’t have enough information in your first email  to conclude.

My personal experience is that some devices omit this namespace completely or partially during the handshake phase because without it, you can’t establish the nectonf communication.
But it seems to happen later during the edit-config for you.

You can try to eavesdrop the netconf session or enable more debug in ODL to check what happens.

 

Maybe ODL is enable to retrieve tail-f proprietary extensions, what causes some trouble when ODL tries to modify the device configuration…

ODL also strictly enforces the coherence between capability and netconf-state (cf slide 5).

You may need to check that too.

Hope this help

Guillaume

From: Jonas Mårtensson [mailto:jonas.martensson@...]
Sent: jeudi 10 octobre 2019 15:21
To: LAMBERT Guillaume TGI/OLN; Transportpce-dev@...
Subject: RE: [Transportpce-dev] Writing to ConfD device

 

Thanks Guillaume,

 

I don’t understand exactly the problem described on slide 4 in your presentation. In our case the ConfD device supports <get-schema> and the ietf-netconf@... module is retrieved and stored in the karaf cache/schema directory. Is this a problem? What is meant by “the netconf capabilities must be overloaded when mounting the device in REST” and how is this accomplished?

 

/Jonas

 

From: guillaume.lambert@... <guillaume.lambert@...>
Sent: den 10 oktober 2019 14:59
To: Jonas Mårtensson <jonas.martensson@...>; Transportpce-dev@...
Subject: RE: [Transportpce-dev] Writing to ConfD device

 

Hi Jonas

 

As I can understand it, this question should be better be addressed to the Netconf project.
This looks like the problem that described in the URL https://wiki.opendaylight.org/view/File:Feedback_on_ODL_netconf.pdf at slide 4.

 

To help you,  you will find in the TranportPCE repo a “debug_tools” folder at the root.

There is a script to hijack the netconf session that can modify capabilities on the fly.

 

Hope this help

Guillaume

 

From: Transportpce-dev@... [mailto:Transportpce-dev@...] On Behalf Of Jonas Martensson
Sent: jeudi 10 octobre 2019 14:25
To: Transportpce-dev@...
Subject: [Transportpce-dev] Writing to ConfD device

 

Hi,

we have problems when TransportPCE is trying to write data to a device running ConfD. It seems ODL can't parse the <ok> element in the rpc-reply to an edit-config rpc. Here are relevant snippets from karaf.log:

java.lang.IllegalArgumentException: Failed to parse RPC response [rpc-reply: null]

Caused by: javax.xml.stream.XMLStreamException: Schema for node with name ok and namespace urn:ietf:params:xml:ns:netconf:base:1.0 does not exist at AbsoluteSchemaPath{path=[(urn:ietf:params:xml:ns:netconf:base:1.0?revision=2011-06-01)edit-config, (urn:ietf:params:xml:ns:netconf:base:1.0?revision=2011-06-01)output]}

From the ConfD Netconf server perspective everything looks fine and the data is actually stored in the database but since TransportPCE doesn't get any confirmation the operation fails and ODL reconnects the Netconf session. I found this old issue which seems related to our problem but it doesn't offer any solution:

https://jira.opendaylight.org/browse/NETCONF-90

Does anyone know how to get TransportPCE to play nice with ConfD?

/Jonas
 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.


Jonas Martensson
 

Thanks again,

 

> Maybe ODL is enable to retrieve tail-f proprietary extensions, what causes some trouble when ODL tries to modify the device configuration…

 

It seems this was the problem. I got it working by removing all tail-f netconf extensions from the confd server.

 

/Jonas

 

From: guillaume.lambert@... <guillaume.lambert@...>
Sent: den 10 oktober 2019 15:35
To: Jonas Mårtensson <jonas.martensson@...>; Transportpce-dev@...
Subject: RE: [Transportpce-dev] Writing to ConfD device

 

I don’t have enough information in your first email  to conclude.

My personal experience is that some devices omit this namespace completely or partially during the handshake phase because without it, you can’t establish the nectonf communication.
But it seems to happen later during the edit-config for you.

You can try to eavesdrop the netconf session or enable more debug in ODL to check what happens.

 

Maybe ODL is enable to retrieve tail-f proprietary extensions, what causes some trouble when ODL tries to modify the device configuration…

ODL also strictly enforces the coherence between capability and netconf-state (cf slide 5).

You may need to check that too.

Hope this help

Guillaume

From: Jonas Mårtensson [mailto:jonas.martensson@...]
Sent: jeudi 10 octobre 2019 15:21
To: LAMBERT Guillaume TGI/OLN; Transportpce-dev@...
Subject: RE: [Transportpce-dev] Writing to ConfD device

 

Thanks Guillaume,

 

I don’t understand exactly the problem described on slide 4 in your presentation. In our case the ConfD device supports <get-schema> and the ietf-netconf@... module is retrieved and stored in the karaf cache/schema directory. Is this a problem? What is meant by “the netconf capabilities must be overloaded when mounting the device in REST” and how is this accomplished?

 

/Jonas

 

From: guillaume.lambert@... <guillaume.lambert@...>
Sent: den 10 oktober 2019 14:59
To: Jonas Mårtensson <jonas.martensson@...>; Transportpce-dev@...
Subject: RE: [Transportpce-dev] Writing to ConfD device

 

Hi Jonas

 

As I can understand it, this question should be better be addressed to the Netconf project.
This looks like the problem that described in the URL https://wiki.opendaylight.org/view/File:Feedback_on_ODL_netconf.pdf at slide 4.

 

To help you,  you will find in the TranportPCE repo a “debug_tools” folder at the root.

There is a script to hijack the netconf session that can modify capabilities on the fly.

 

Hope this help

Guillaume

 

From: Transportpce-dev@... [mailto:Transportpce-dev@...] On Behalf Of Jonas Martensson
Sent: jeudi 10 octobre 2019 14:25
To: Transportpce-dev@...
Subject: [Transportpce-dev] Writing to ConfD device

 

Hi,

we have problems when TransportPCE is trying to write data to a device running ConfD. It seems ODL can't parse the <ok> element in the rpc-reply to an edit-config rpc. Here are relevant snippets from karaf.log:

java.lang.IllegalArgumentException: Failed to parse RPC response [rpc-reply: null]

Caused by: javax.xml.stream.XMLStreamException: Schema for node with name ok and namespace urn:ietf:params:xml:ns:netconf:base:1.0 does not exist at AbsoluteSchemaPath{path=[(urn:ietf:params:xml:ns:netconf:base:1.0?revision=2011-06-01)edit-config, (urn:ietf:params:xml:ns:netconf:base:1.0?revision=2011-06-01)output]}

From the ConfD Netconf server perspective everything looks fine and the data is actually stored in the database but since TransportPCE doesn't get any confirmation the operation fails and ODL reconnects the Netconf session. I found this old issue which seems related to our problem but it doesn't offer any solution:

https://jira.opendaylight.org/browse/NETCONF-90

Does anyone know how to get TransportPCE to play nice with ConfD?

/Jonas
 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.


Guillaume Lambert
 

Thanks for the feedback.

The alternative solution is to fill the ODL karaf cache with those proprietary models.

 

 

From: Transportpce-dev@... [mailto:Transportpce-dev@...] On Behalf Of Jonas Martensson
Sent: jeudi 10 octobre 2019 22:15
To: LAMBERT Guillaume TGI/OLN; Transportpce-dev@...
Subject: Re: [Transportpce-dev] Writing to ConfD device

 

Thanks again,

 

> Maybe ODL is unable to retrieve tail-f proprietary extensions, what causes some trouble when ODL tries to modify the device configuration…

 

It seems this was the problem. I got it working by removing all tail-f netconf extensions from the confd server.

 

/Jonas

 

From: guillaume.lambert@... <guillaume.lambert@...>
Sent: den 10 oktober 2019 15:35
To: Jonas Mårtensson <jonas.martensson@...>; Transportpce-dev@...
Subject: RE: [Transportpce-dev] Writing to ConfD device

 

I don’t have enough information in your first email  to conclude.

My personal experience is that some devices omit this namespace completely or partially during the handshake phase because without it, you can’t establish the nectonf communication.
But it seems to happen later during the edit-config for you.

You can try to eavesdrop the netconf session or enable more debug in ODL to check what happens.

 

Maybe ODL is unable to retrieve tail-f proprietary extensions, what causes some trouble when ODL tries to modify the device configuration…

ODL also strictly enforces the coherence between capability and netconf-state (cf slide 5).

You may need to check that too.

Hope this help

Guillaume

From: Jonas Mårtensson [mailto:jonas.martensson@...]
Sent: jeudi 10 octobre 2019 15:21
To: LAMBERT Guillaume TGI/OLN; Transportpce-dev@...
Subject: RE: [Transportpce-dev] Writing to ConfD device

 

Thanks Guillaume,

 

I don’t understand exactly the problem described on slide 4 in your presentation. In our case the ConfD device supports <get-schema> and the ietf-netconf@... module is retrieved and stored in the karaf cache/schema directory. Is this a problem? What is meant by “the netconf capabilities must be overloaded when mounting the device in REST” and how is this accomplished?

 

/Jonas

 

From: guillaume.lambert@... <guillaume.lambert@...>
Sent: den 10 oktober 2019 14:59
To: Jonas Mårtensson <jonas.martensson@...>; Transportpce-dev@...
Subject: RE: [Transportpce-dev] Writing to ConfD device

 

Hi Jonas

 

As I can understand it, this question should be better be addressed to the Netconf project.
This looks like the problem that described in the URL https://wiki.opendaylight.org/view/File:Feedback_on_ODL_netconf.pdf at slide 4.

 

To help you,  you will find in the TranportPCE repo a “debug_tools” folder at the root.

There is a script to hijack the netconf session that can modify capabilities on the fly.

 

Hope this help

Guillaume

 

From: Transportpce-dev@... [mailto:Transportpce-dev@...] On Behalf Of Jonas Martensson
Sent: jeudi 10 octobre 2019 14:25
To: Transportpce-dev@...
Subject: [Transportpce-dev] Writing to ConfD device

 

Hi,

we have problems when TransportPCE is trying to write data to a device running ConfD. It seems ODL can't parse the <ok> element in the rpc-reply to an edit-config rpc. Here are relevant snippets from karaf.log:

java.lang.IllegalArgumentException: Failed to parse RPC response [rpc-reply: null]

Caused by: javax.xml.stream.XMLStreamException: Schema for node with name ok and namespace urn:ietf:params:xml:ns:netconf:base:1.0 does not exist at AbsoluteSchemaPath{path=[(urn:ietf:params:xml:ns:netconf:base:1.0?revision=2011-06-01)edit-config, (urn:ietf:params:xml:ns:netconf:base:1.0?revision=2011-06-01)output]}

From the ConfD Netconf server perspective everything looks fine and the data is actually stored in the database but since TransportPCE doesn't get any confirmation the operation fails and ODL reconnects the Netconf session. I found this old issue which seems related to our problem but it doesn't offer any solution:

https://jira.opendaylight.org/browse/NETCONF-90

Does anyone know how to get TransportPCE to play nice with ConfD?

/Jonas
 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.


Jonas Martensson
 

Sorry, slight misunderstanding. The problem was not that ODL was unable to retrieve the modules. The karaf cache was populated with the tail-f modules retrieved using get-schema. The problem is that tail-f modules augment the base netconf edit-config rpc, which confused ODL so that the ok rpc-reply from confd was not recognized.

 

/Jonas

 

From: guillaume.lambert@... <guillaume.lambert@...>
Sent: den 11 oktober 2019 12:03
To: Jonas Mårtensson <jonas.martensson@...>; Transportpce-dev@...
Subject: RE: [Transportpce-dev] Writing to ConfD device

 

Thanks for the feedback.

The alternative solution is to fill the ODL karaf cache with those proprietary models.

 

 

From: Transportpce-dev@... [mailto:Transportpce-dev@...] On Behalf Of Jonas Martensson
Sent: jeudi 10 octobre 2019 22:15
To: LAMBERT Guillaume TGI/OLN;
Transportpce-dev@...
Subject: Re: [Transportpce-dev] Writing to ConfD device

 

Thanks again,

 

> Maybe ODL is unable to retrieve tail-f proprietary extensions, what causes some trouble when ODL tries to modify the device configuration…

 

It seems this was the problem. I got it working by removing all tail-f netconf extensions from the confd server.

 

/Jonas

 

From: guillaume.lambert@... <guillaume.lambert@...>
Sent: den 10 oktober 2019 15:35
To: Jonas Mårtensson <
jonas.martensson@...>; Transportpce-dev@...
Subject: RE: [Transportpce-dev] Writing to ConfD device

 

I don’t have enough information in your first email  to conclude.

My personal experience is that some devices omit this namespace completely or partially during the handshake phase because without it, you can’t establish the nectonf communication.
But it seems to happen later during the edit-config for you.

You can try to eavesdrop the netconf session or enable more debug in ODL to check what happens.

 

Maybe ODL is unable to retrieve tail-f proprietary extensions, what causes some trouble when ODL tries to modify the device configuration…

ODL also strictly enforces the coherence between capability and netconf-state (cf slide 5).

You may need to check that too.

Hope this help

Guillaume

From: Jonas Mårtensson [mailto:jonas.martensson@...]
Sent: jeudi 10 octobre 2019 15:21
To: LAMBERT Guillaume TGI/OLN;
Transportpce-dev@...
Subject: RE: [Transportpce-dev] Writing to ConfD device

 

Thanks Guillaume,

 

I don’t understand exactly the problem described on slide 4 in your presentation. In our case the ConfD device supports <get-schema> and the ietf-netconf@... module is retrieved and stored in the karaf cache/schema directory. Is this a problem? What is meant by “the netconf capabilities must be overloaded when mounting the device in REST” and how is this accomplished?

 

/Jonas

 

From: guillaume.lambert@... <guillaume.lambert@...>
Sent: den 10 oktober 2019 14:59
To: Jonas Mårtensson <
jonas.martensson@...>; Transportpce-dev@...
Subject: RE: [Transportpce-dev] Writing to ConfD device

 

Hi Jonas

 

As I can understand it, this question should be better be addressed to the Netconf project.
This looks like the problem that described in the URL
https://wiki.opendaylight.org/view/File:Feedback_on_ODL_netconf.pdf at slide 4.

 

To help you,  you will find in the TranportPCE repo a “debug_tools” folder at the root.

There is a script to hijack the netconf session that can modify capabilities on the fly.

 

Hope this help

Guillaume

 

From: Transportpce-dev@... [mailto:Transportpce-dev@...] On Behalf Of Jonas Martensson
Sent: jeudi 10 octobre 2019 14:25
To:
Transportpce-dev@...
Subject: [Transportpce-dev] Writing to ConfD device

 

Hi,

we have problems when TransportPCE is trying to write data to a device running ConfD. It seems ODL can't parse the <ok> element in the rpc-reply to an edit-config rpc. Here are relevant snippets from karaf.log:

java.lang.IllegalArgumentException: Failed to parse RPC response [rpc-reply: null]

Caused by: javax.xml.stream.XMLStreamException: Schema for node with name ok and namespace urn:ietf:params:xml:ns:netconf:base:1.0 does not exist at AbsoluteSchemaPath{path=[(urn:ietf:params:xml:ns:netconf:base:1.0?revision=2011-06-01)edit-config, (urn:ietf:params:xml:ns:netconf:base:1.0?revision=2011-06-01)output]}

From the ConfD Netconf server perspective everything looks fine and the data is actually stored in the database but since TransportPCE doesn't get any confirmation the operation fails and ODL reconnects the Netconf session. I found this old issue which seems related to our problem but it doesn't offer any solution:

https://jira.opendaylight.org/browse/NETCONF-90

Does anyone know how to get TransportPCE to play nice with ConfD?

/Jonas
 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.


Guillaume Lambert
 

OK
The issue I had with those tail-f models was a little different.

The models by themselves could be retrieved but not the models they imported (they were also proprietary)

 

Guillaume

 

From: Jonas Mårtensson [mailto:jonas.martensson@...]
Sent: vendredi 11 octobre 2019 12:38
To: LAMBERT Guillaume TGI/OLN; Transportpce-dev@...
Subject: RE: [Transportpce-dev] Writing to ConfD device

 

Sorry, slight misunderstanding. The problem was not that ODL was unable to retrieve the modules. The karaf cache was populated with the tail-f modules retrieved using get-schema. The problem is that tail-f modules augment the base netconf edit-config rpc, which confused ODL so that the ok rpc-reply from confd was not recognized.

 

/Jonas

 

From: guillaume.lambert@... <guillaume.lambert@...>
Sent: den 11 oktober 2019 12:03
To: Jonas Mårtensson <jonas.martensson@...>; Transportpce-dev@...
Subject: RE: [Transportpce-dev] Writing to ConfD device

 

Thanks for the feedback.

The alternative solution is to fill the ODL karaf cache with those proprietary models.

 

 

From: Transportpce-dev@... [mailto:Transportpce-dev@...] On Behalf Of Jonas Martensson
Sent: jeudi 10 octobre 2019 22:15
To: LAMBERT Guillaume TGI/OLN;
Transportpce-dev@...
Subject: Re: [Transportpce-dev] Writing to ConfD device

 

Thanks again,

 

> Maybe ODL is unable to retrieve tail-f proprietary extensions, what causes some trouble when ODL tries to modify the device configuration…

 

It seems this was the problem. I got it working by removing all tail-f netconf extensions from the confd server.

 

/Jonas

 

From: guillaume.lambert@... <guillaume.lambert@...>
Sent: den 10 oktober 2019 15:35
To: Jonas Mårtensson <
jonas.martensson@...>; Transportpce-dev@...
Subject: RE: [Transportpce-dev] Writing to ConfD device

 

I don’t have enough information in your first email  to conclude.

My personal experience is that some devices omit this namespace completely or partially during the handshake phase because without it, you can’t establish the nectonf communication.
But it seems to happen later during the edit-config for you.

You can try to eavesdrop the netconf session or enable more debug in ODL to check what happens.

 

Maybe ODL is unable to retrieve tail-f proprietary extensions, what causes some trouble when ODL tries to modify the device configuration…

ODL also strictly enforces the coherence between capability and netconf-state (cf slide 5).

You may need to check that too.

Hope this help

Guillaume

From: Jonas Mårtensson [mailto:jonas.martensson@...]
Sent: jeudi 10 octobre 2019 15:21
To: LAMBERT Guillaume TGI/OLN;
Transportpce-dev@...
Subject: RE: [Transportpce-dev] Writing to ConfD device

 

Thanks Guillaume,

 

I don’t understand exactly the problem described on slide 4 in your presentation. In our case the ConfD device supports <get-schema> and the ietf-netconf@... module is retrieved and stored in the karaf cache/schema directory. Is this a problem? What is meant by “the netconf capabilities must be overloaded when mounting the device in REST” and how is this accomplished?

 

/Jonas

 

From: guillaume.lambert@... <guillaume.lambert@...>
Sent: den 10 oktober 2019 14:59
To: Jonas Mårtensson <
jonas.martensson@...>; Transportpce-dev@...
Subject: RE: [Transportpce-dev] Writing to ConfD device

 

Hi Jonas

 

As I can understand it, this question should be better be addressed to the Netconf project.
This looks like the problem that described in the URL
https://wiki.opendaylight.org/view/File:Feedback_on_ODL_netconf.pdf at slide 4.

 

To help you,  you will find in the TranportPCE repo a “debug_tools” folder at the root.

There is a script to hijack the netconf session that can modify capabilities on the fly.

 

Hope this help

Guillaume

 

From: Transportpce-dev@... [mailto:Transportpce-dev@...] On Behalf Of Jonas Martensson
Sent: jeudi 10 octobre 2019 14:25
To:
Transportpce-dev@...
Subject: [Transportpce-dev] Writing to ConfD device

 

Hi,

we have problems when TransportPCE is trying to write data to a device running ConfD. It seems ODL can't parse the <ok> element in the rpc-reply to an edit-config rpc. Here are relevant snippets from karaf.log:

java.lang.IllegalArgumentException: Failed to parse RPC response [rpc-reply: null]

Caused by: javax.xml.stream.XMLStreamException: Schema for node with name ok and namespace urn:ietf:params:xml:ns:netconf:base:1.0 does not exist at AbsoluteSchemaPath{path=[(urn:ietf:params:xml:ns:netconf:base:1.0?revision=2011-06-01)edit-config, (urn:ietf:params:xml:ns:netconf:base:1.0?revision=2011-06-01)output]}

From the ConfD Netconf server perspective everything looks fine and the data is actually stored in the database but since TransportPCE doesn't get any confirmation the operation fails and ODL reconnects the Netconf session. I found this old issue which seems related to our problem but it doesn't offer any solution:

https://jira.opendaylight.org/browse/NETCONF-90

Does anyone know how to get TransportPCE to play nice with ConfD?

/Jonas
 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.