Simulating operational errors on netsims

[rhinst001]

Is there a way to set up a netsim to return an error for all and/or specific netconf request payloads? Specifically, by "return an error", I mean that I want to be able to specify one or more <rpc-error /> elements to return in the <rpc-reply />

I'm troubleshooting an error on a device where the request payload validates just fine but the commit fails due to a malfunction or error condition within the OS during commit.  

I know I could probably do it by recompiling a customized version of the NED, but I'm looking for a way to do it on just a specific netsim instance without changing the NED it gets generated from.

[vleijon]

Well, you can do some things, but perhaps not all the things you want. The netconf protocol part is sort of opaque to you, but you can fail individual transactions, potentially based on their content.  There is also a limit to what kind of errors you can send, unfortunately.

You can take a look at the netsim control panel here https://gitlab.com/nso-developer/nso-scenario-explorer for some inspiration that may be helpful to you. 

[Jan Lindblad · Accepted solution]

Well, no. If you need low-level control over the exact formatting of the rpc-reply and things like that, you need a "parrot", i.e. an SSH server with pre-recorded response messages and some pattern matching logic. Note that NSO won't care about more than the first rpc-error anyway, so if that's all you're after, you may as well use something that gives you an easier path.

If you don't need to design a specific protocol level behavior, Netsims are often useful. They are really a simplified packaging of ConfD, so you could basically do anything a real device built on top of ConfD could do. But it may require a bit of programming. And you can't tell netsim alias ConfD how to react on malformed NETCONF messages, etc. It will deal with such low level errors in the way it's built-in way. 

You could add validation logic in the YANGs you use in netsim (which don't have to be identical to what you use in the NED -- but don't tell anyone I said that Or you could add two-phase subscribers that return an error in the first phase. That would cause the transaction to fail with your choice of pretext.