cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3725
Views
2
Helpful
4
Replies

Getting "Device does not have a Network Element Driver registered" on connect

ron.whitt
Level 1
Level 1

I'm getting "info Device N9Kv-1 does not have a Network Element Driver registered" when I try to connect vNexus device.

I had previously loaded the the cisco-nx 5.0 NED and it worked with the attached Nexus device.  However, I loaded the cisco-iosxr NED (6.0.1) and I got errors on package reload from the cisco-nx.  So I upgraded the cisco-nx to 5.2. This solved the package reload problem, but now I cannot connect to the nexus box.  I get the "does not have Network Element Driver registered" message when I try. I have tried deleting and re-adding the device and doing an ncs --with-package-reload.  Still getting the error message when I try to connect to the device.  Thanks.

1 Accepted Solution

Accepted Solutions

See this warning in CHANGES of cisco-iosxr.

  WARNING:

    When using cisco-iosxr with other NEDs, certain combinations of NED versions

    may cause 'random' Exceptions. The reason for this is the introduction of

    a new common NED component - nedcom.jar - which initially was located in

    shared-jar, but later moved to private-jar. However, since the JAVA loader

    looks in shared-jar directories first, a newer NED with nedcom.jar in

    private-jar will still load another NED's older nedcom.jar in shared-jar;

    causing a version conflict and quite possibly an Exception.

    Hence, if you are using a newer NED (with private-jar/nedcom.jar) you must

    make sure no other NEDs in your project has a shared-jar/nedcom.jar. If they

    do, you must upgrade them to a version which also has nedcom in private-jar.

    The following NED versions have their nedcom.jar in shared-jar:

    a10-acos      3.6.5

    alu-sr        6.0.2 to 6.1.1

    cisco-asa     5.2 to to 5.2.1

    cisco-ios     5.2.8 to 5.4.2

    cisco-iosxr   6.0 to 6.1

    cisco-nx      4.4.7 to 4.5.2

    huawei-vrp    4.2.6

    In short, avoid the above NED versions when using other NEDs.

View solution in original post

4 Replies 4

frjansso
Cisco Employee
Cisco Employee

Is there any way you're short on memory? E.g. from running NSO in a container?

Does: "show packages package * oper-status" reveal anything interesting?

Any error in ncs-java-vm.log?

Here are some stats, I don't see a memory problem, but maybe you'll see something I'm not.

so here is oper-satus:

admin@ncs# show packages package oper-status

packages package cisco-ios

oper-status up

packages package cisco-iosxr

oper-status up

packages package cisco-nx

oper-status up

I thought it might be a memory thing too, so I removed one of the NEDs, same result.

here is a cat /proc/meminfo

atcadmin@NSO-POC3480:~/ncs-run$ cat /proc/meminfo

MemTotal:       24689752 kB

MemFree:        18465576 kB

MemAvailable:   22386388 kB

Buffers:          226992 kB

Cached:          3796648 kB

SwapCached:            0 kB

Active:          4070196 kB

Inactive:        1719852 kB

Active(anon):    1769420 kB

Inactive(anon):     8416 kB

Active(file):    2300776 kB

Inactive(file):  1711436 kB

Unevictable:        3660 kB

Mlocked:            3660 kB

SwapTotal:      25162748 kB

SwapFree:       25162748 kB

Dirty:                60 kB

Writeback:             0 kB

AnonPages:       1772116 kB

Mapped:            65784 kB

Shmem:              9004 kB

Slab:             311804 kB

SReclaimable:     279224 kB

SUnreclaim:        32580 kB

KernelStack:        4544 kB

PageTables:         7884 kB

NFS_Unstable:          0 kB

Bounce:                0 kB

WritebackTmp:          0 kB

CommitLimit:    37507624 kB

Committed_AS:    2874040 kB

VmallocTotal:   34359738367 kB

VmallocUsed:           0 kB

VmallocChunk:          0 kB

HardwareCorrupted:     0 kB

AnonHugePages:   1658880 kB

CmaTotal:              0 kB

CmaFree:               0 kB

HugePages_Total:       0

HugePages_Free:        0

HugePages_Rsvd:        0

HugePages_Surp:        0

Hugepagesize:       2048 kB

DirectMap4k:       88000 kB

DirectMap2M:    25077760 kB

Still troubleshooting, backed the cisco-nx NED back to 5.1, now getting the error I was before when loading the iosxr:

admin@ncs# show packages package package-version

             PACKAGE

NAME         VERSION

----------------------

cisco-ios    5.9.2

cisco-iosxr  6.0.1

cisco-nx     5.1

reload-result {

    package cisco-nx

    result false

    info [LOAD_PACKAGE[com.tailf.packages.ned.nedcom.NedComCliBase.<init>(Z)V]]

}

Note: this error went away when I loaded the 5.2 nx NED. 

I removed the cisco-iosxr 6.0.1 NED and now I'm able to connect and sync with the device.

So.... there appears to be a conflict with the cisco-iosxr NED (6.0.1) and versions of the cisco-nx NED, the exception being the cisco-nx 5.2 NED.  But I can't get the cisco-nx 5.2 NED to connect to a device.

See this warning in CHANGES of cisco-iosxr.

  WARNING:

    When using cisco-iosxr with other NEDs, certain combinations of NED versions

    may cause 'random' Exceptions. The reason for this is the introduction of

    a new common NED component - nedcom.jar - which initially was located in

    shared-jar, but later moved to private-jar. However, since the JAVA loader

    looks in shared-jar directories first, a newer NED with nedcom.jar in

    private-jar will still load another NED's older nedcom.jar in shared-jar;

    causing a version conflict and quite possibly an Exception.

    Hence, if you are using a newer NED (with private-jar/nedcom.jar) you must

    make sure no other NEDs in your project has a shared-jar/nedcom.jar. If they

    do, you must upgrade them to a version which also has nedcom in private-jar.

    The following NED versions have their nedcom.jar in shared-jar:

    a10-acos      3.6.5

    alu-sr        6.0.2 to 6.1.1

    cisco-asa     5.2 to to 5.2.1

    cisco-ios     5.2.8 to 5.4.2

    cisco-iosxr   6.0 to 6.1

    cisco-nx      4.4.7 to 4.5.2

    huawei-vrp    4.2.6

    In short, avoid the above NED versions when using other NEDs.