Is delete-config on candidate DB supported by netconf

[ascesh1]

Hi All,

This is a basic question on netconf,

I have enabled candidate DB and set it to be managed by CDB

on the netconf interactive console I have , I am trying the below command
and seem to be getting syntactical errors ,

---

* Enter a NETCONF operation, end with an empty line
<delete-config>
 <target>
    <candidate/>
 </target>
</delete-config>

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2">
  <rpc-error>
    <error-type>protocol</error-type>
    <error-tag>missing-element</error-tag>
    <error-severity>error</error-severity>
    <error-path>
    /rpc/delete-config/target/url
  </error-path>
    <error-info>
      <bad-element>url</bad-element>
    </error-info>
  </rpc-error>
</rpc-reply>

* Enter a NETCONF operation, end with an empty line
------------------------------------------------------------------------------------------

Any pointers guys

[per]

You need to have both /confdConfig/datastores/candidate/enabled and /confdConfig/netconf/capabilities/candidate/enabled set for the candidate to be available via netconf. If neither startup nor candidate is enabled under /confdConfig/netconf/capabilities, the only remaining possibility for <target> is <url>.

That said, why are you attempting <delete-config> on the candidate? It's not a very useful operation - typically you want to update running via edit of the candidate, and then you'll want to start out with a candidate that is a copy of running. <discard-changes> will achieve this.

[ascesh1]

<discard-changes>

Hey Per,

<discard-changes/> worked and it served the purpose to throw away all changes done in candidate db

But just to understand the error response better,
both the data store and capability were enabled , so was suspecting is needed , but not sure why it has to be given ,since the intention was to delete the entire candiate db and revert it to its default values ,
Which is nothing but the running db.

also brings me to another question ,
when does someone really need to use <delete-config>, netconf RFC prevents it to be ran on running datastore ( looks like we can't run it on candidate datastore) ??

[per]

Your final question is actually quite to the point - the original implementor of the ConfD NETCONF server didn't think that <delete-config> on the candidate (or startup) made any sense, so simply didn't include the possibility (unfortunately without documenting this deviation from the standard - though actually it may not have been a formal standard at that point). I.e. the only allowed child of <delete-config> is actually <url>, regardless of which capabilities are enabled in confd.conf - sorry for the misleading first part of my previous reply.

In hindsight, this decision was probably correct - I don't recall this "problem" having surfaced at any time before in the 10 years that the ConfD NETCONF server has existed - you may actually be the first one to attempt it. The idea of deleting one of the "logical" data stores (as opposed to deleting the configuration "within" a data store) is rather dubious, and the RFC gives no guidance as to what it is actually supposed to mean. And the answer to your question is "never". In case you actually want to delete all the config in the candidate (or running) for some reason, <copy-config> with an inline empty source should do it (not tested:-).

--Per

[ascesh1]

Thanks again per,

I also believe this part of the RFC could have been better clarified, It mentions explicitly that running db is NOT supposed to be an argument to <delete-config>, but remains silent about other datastores (like candidate datastore).

~ascesh

P.S noticed my earlier post is looking odd because the text within xml tags got striped out

[per]

I also believe this part of the RFC could have been better clarified, It mentions explicitly that running db is NOT supposed to be an argument to <delete-config>, but remains silent about other datastores (like candidate datastore).

Well, as far as that goes, I think it should be interpreted to mean that the other data stores can be deleted. But it doesn't say what it means... "Delete all the config in the data store" could be an interpretation, but that's not what it says. And that is probably not what you want/expect for <url> (e.g. you want 'rm file', not 'cp /dev/null file').

P.S noticed my earlier post is looking odd because the text within xml tags got striped out

Yeah, I did the same mistake - but I noticed it "quickly" and used the edit function (which I otherwise don't really like) to fix it. Will probably do the same mistake again next time I write an xml tag...

--Per

[Hatim5253]

hi Per,

I tried to delete the entire candidate datastore using the method you suggested. but it didnt work.

can you please let me know if there is any other way i can do this. my intention is to remove all the config on my device.

*"




< >

"*

I got error as
"


application
unknown-element
error

/rpc/copy-config/source






"

[Hatim5253]

it seems that the RPC is not displayed:

RPC:

copy-config
target
\candidate/
/target
source

/source
/copy-config

this is the error:

rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="410"
rpc-error
error-type>application error-tag>unknown-element error-severity>error error-path
/rpc/copy-config/source
/error-path
error-info
bad-element/
/error-info
/rpc-error
/rpc-reply

[per]

I tried to delete the entire candidate datastore using the method you suggested. but it didnt work.

Well, what did you give for <source> in the copy-config? Looking at the "unformatted" version of your message, it looks like < > - what's that supposed to mean? From https://tools.ietf.org/html/rfc6241#section-7.3:

  source:  Name of the configuration datastore to use as the source
     of the <copy-config> operation, or the <config> element
     containing the complete configuration to copy.

Thus an empty "complete configuration" can be given as <config/>, or for the complete rpc:

<copy-config>
  <target>
    <candidate/>
  </target>
  <source>
    <config/>
  </source>
</copy-config>

Seems to work fine now that I actually tested it. If you use the netconf-console tool that comes with ConfD, it can conveniently be done as:

netconf-console --copy-config=/dev/null --db=candidate

Try netconf-console -h to see all the nifty options.

it seems that the RPC is not displayed:

Yes, the forum software "eats" everything that looks like XML - check the preview before you post, and use the </> "Preformatted text" option for XML chunks (for "inline" preformatted text, you can just enclose it in "back-tics", i.e. ` characters).

[darcyl]

HI,
I use the command:
netconf-console --copy-config=/dev/null --db=running

to delete the running datastore, but after I delete, the netconf-console can't connect the the confd server now, it always reports the "Authentication failed", what's the root cause? Thanks!

/root/confd/bin > netconf-console --db=running --get-config
Authentication failed.

The confd server is running:
/root/confd/bin > netstat -anp|grep confd
tcp 0 0 127.0.0.1:4565 0.0.0.0:* LISTEN 13285/confd
tcp 0 0 0.0.0.0:2022 0.0.0.0:* LISTEN 13285/confd
tcp 0 0 127.0.0.1:2023 0.0.0.0:* LISTEN 13285/confd
tcp 0 0 0.0.0.0:2024 0.0.0.0:* LISTEN 13285/confd
unix 2 [ ] DGRAM 80847140 13285/confd

Thanks
Darcy

[per]

I believe @mnovak's reply to your same question in the other thread is right on target - if you delete all the config in the running datastore, obviously the AAA rules are also gone.

[darcyl]

Yes, thanks for the response! After restore the AAA the confd is OK.