Read EOF error in NED

[previousqna]

Hi Experts,

I am from VMS IWAN team in India and we are regularly facing an error in NED because of which our service deployment is failing.

cpe-9APRNXYQT52(config-route-map)#

<< 16-Feb-2017::07:39:47.077 SET-TIMOUT

  *** output 16-Feb-2017::07:39:47.077 ***

set tag 101

>> 16-Feb-2017::07:39:48.343 CLOSE 14: (Pool: false)

<< 16-Feb-2017::07:39:48.349 ERROR: Network Element Driver error ned_prepare_cli for device cpe-9APRNXYQT52: read eof

<< 16-Feb-2017::07:39:48.351 CLOSED

>> 16-Feb-2017::07:39:48.351 CLI CONNECT to cpe-9APRNXYQT52-10.254.0.6:22 as vms-cisco (Trace=true)

<< 16-Feb-2017::07:39:48.352 SET-TIMOUT

-- NCS VERSION: 61 6010200

-- NED VERSION: cisco-ios 4.1.2 2016-04-06

-- SSH connecting to host: 10.254.0.6:22 --

-- SSH initializing session --

-- SSH new session --

Any lead will be very helpful.

[previousqna]

Hello

Looks like you are importing NED, but NED YANG model is empty (contains only eof).

Try to check path to NED in Makefile.

[previousqna]

Looks like the connection between NCS and the device was closed unexpectedly. It is interesting that this error coincides with close() call, while the "read eof" error comes from prepare() callback apparently associated with another connection. Looking at the full raw NED trace log as well as ncs-java-vm.log with level-debug logging for com.tailf.ned might be useful.

[previousqna]

It does not look like the same issue to me, since it mentions "timeout" vs "read eof" in the previous log snippet. Also these two errors are almost 5 minutes apart looking at the timestamp.

There's connect-timeout, read-timeout and write-timeout, defined in tailf-ncs-devices.yang. In short, if a connect-timeout triggers, then it means we were unable to establish connection to the device within this time. If a read-timeout triggers, then it means we sent a command to the device, but have not received any expected response (typically a CLI

prompt) back. If a write-timeout triggers this means either the device's TCP receive buffer is full and it doesn't accept any more data, or (more

likely) the connectivity is broken.

[previousqna]

Hi,

I experienced this in 4.3 this week. I upped the connection/read/write timeouts to overcome.