netdisco / snmp-info

Other
38 stars 32 forks source link

IPv6 arpnip don't get neigbours when uses IPv6 only on Vlan interfaces #531

Open elbuit opened 4 weeks ago

elbuit commented 4 weeks ago

I've several Cisco 9500X and netdisco can't get IPv6 neighbours if ALL interfaces VLAN are only IPv6.

If I add a IPv4 address to a int Vlan then netdisco can do the arpnip correctly on that interface and also the rest of them, although these vlan interfaces are IPv6 only configured.

That router had IPv4 only vlan interfaces, and the arpnip in IPv4 works perfectly, is when you have IPv4/IPv6 only Vlan interfaces.

Your Environment

App::Netdisco 2.78.0 SNMP::Info 3.970.1 DB Schema 88 PostgreSQL 11.00.17 Perl / Python 5.36.0 / 3.11.2

Device information

Cisco C9500-32C Cisco IOS XE Software, Version 17.15.01

Example:

With all Vlan interfeces IPv6 only:

2024-08-29 10:05:32 UTC [686688]  info App::Netdisco version 2.078000 loaded.
2024-08-29 10:05:32 UTC [686688]  info arpnip: [XXX.XXX.100.225] started at Thu Aug 29 12:05:32 2024
2024-08-29 10:05:32 UTC [686688] debug arpnip: running with timeout 600s
2024-08-29 10:05:32 UTC [686688] debug //// CHECK \\\\ phase
2024-08-29 10:05:32 UTC [686688] debug ⮕ worker Internal::BackendFQDN p1000000
2024-08-29 10:05:32 UTC [686688] debug ⮕ worker Internal::SNMPFastDiscover p1000000
2024-08-29 10:05:32 UTC [686688] debug running with configured SNMP timeouts
2024-08-29 10:05:32 UTC [686688] debug ⮕ worker Arpnip p0
2024-08-29 10:05:32 UTC [686688] debug ⬅ (done) arpnip is able to run
2024-08-29 10:05:32 UTC [686688] debug //// EARLY \\\\ phase
2024-08-29 10:05:32 UTC [686688] debug ⮕ worker Arpnip::Nodes p0 "prepare common data"
2024-08-29 10:05:32 UTC [686688] debug //// MAIN \\\\ phase
2024-08-29 10:05:32 UTC [686688] debug ⮕ worker Arpnip::Nodes p1000000
2024-08-29 10:05:32 UTC [686688] debug ⬅ (info) skip: arp table data supplied by other source
2024-08-29 10:05:32 UTC [686688] debug ⮕ worker Arpnip::Nodes p200
2024-08-29 10:05:32 UTC [686688] debug ⬅ (info) skip: driver or action not applicable
2024-08-29 10:05:32 UTC [686688] debug ⮕ worker Arpnip::Nodes p100
2024-08-29 10:05:32 UTC [686688] debug snmp reader cache warm: [XXX.XXX.100.225]
2024-08-29 10:05:32 UTC [686688] debug [XXX.XXX.100.225:161] try_connect with v: 2, t: 0.2, r: 0, class: SNMP::Info::Layer3::CiscoSwitch, comm: <hidden>
2024-08-29 10:05:33 UTC [686688] debug ⬅ (done) Gathered arp caches from XXX.XXX.100.225
2024-08-29 10:05:33 UTC [686688] debug ⮕ worker Arpnip::Subnets p100
2024-08-29 10:05:33 UTC [686688] debug  [XXX.XXX.100.225] arpnip - found subnet 10.3.0.0/24
2024-08-29 10:05:33 UTC [686688] debug  [XXX.XXX.100.225] arpnip - found subnet 10.15.100.0/23
2024-08-29 10:05:33 UTC [686688] debug  [XXX.XXX.100.225] arpnip - found subnet XXX.XXX.100.80/29
2024-08-29 10:05:33 UTC [686688] debug  [XXX.XXX.100.225] arpnip - found subnet XXX.XXX.100.136/30
2024-08-29 10:05:33 UTC [686688] debug  [XXX.XXX.100.225] arpnip - found subnet XXX.XXX.236.0/22
2024-08-29 10:05:33 UTC [686688] debug  [XXX.XXX.100.225] arpnip - found subnet XXX.XXX.7.96/30
2024-08-29 10:05:33 UTC [686688] debug  [XXX.XXX.100.225] arpnip - found subnet 10.3.32.0/19
2024-08-29 10:05:33 UTC [686688] debug  [XXX.XXX.100.225] arpnip - found subnet 10.4.0.0/16
2024-08-29 10:05:33 UTC [686688] debug ⬅ (info)  [XXX.XXX.100.225] arpnip - processed 8 Subnet entries

[...]

2024-08-29 10:05:37 UTC [686688] debug  [XXX.XXX.100.225] arpnip - processed 1044 ARP Cache entries
2024-08-29 10:05:37 UTC [686688] debug  [XXX.XXX.100.225] arpnip - processed 2 IPv6 Neighbor Cache entries

Then I added a IPv4 on a Vlan Interface (192.168.160.1):

2024-08-29 09:55:31 UTC [684231]  info App::Netdisco version 2.078000 loaded.
2024-08-29 09:55:32 UTC [684231]  info discover: [XXX.XXX.100.225] started at Thu Aug 29 11:55:32 2024
2024-08-29 09:55:32 UTC [684231] debug discover: running with timeout 600s
2024-08-29 09:55:32 UTC [684231] debug //// CHECK \\\\ phase
2024-08-29 09:55:32 UTC [684231] debug ⮕ worker Internal::BackendFQDN p1000000
2024-08-29 09:55:32 UTC [684231] debug ⮕ worker Internal::SNMPFastDiscover p1000000
2024-08-29 09:55:32 UTC [684231] debug running with configured SNMP timeouts
2024-08-29 09:55:32 UTC [684231] debug ⮕ worker Discover p0
2024-08-29 09:55:32 UTC [684231] debug ⬅ (done) Discover is able to run.
2024-08-29 09:55:32 UTC [684231] debug //// EARLY \\\\ phase
2024-08-29 09:55:32 UTC [684231] debug ⮕ worker Discover::Properties p100
2024-08-29 09:55:32 UTC [684231] debug snmp reader cache warm: [XXX.XXX.100.225]
2024-08-29 09:55:32 UTC [684231] debug [XXX.XXX.100.225:161] try_connect with v: 2, t: 0.2, r: 0, class: SNMP::Info::Layer3::CiscoSwitch, comm: <hidden>
2024-08-29 09:55:32 UTC [684231] debug ⬅ (done) Ended discover for XXX.XXX.100.225
2024-08-29 09:55:32 UTC [684231] debug ⮕ worker Discover::Properties p100
2024-08-29 09:55:32 UTC [684231] debug ⬅ (info)  [XXX.XXX.100.225] device - OK to continue discover (not a duplicate)
2024-08-29 09:55:32 UTC [684231] debug ⮕ worker Discover::Properties p100
2024-08-29 09:55:32 UTC [684231] debug ⬅ (info)  [XXX.XXX.100.225] device - OK to continue discover (valid interfaces)
2024-08-29 09:55:32 UTC [684231] debug ⮕ worker Discover::Properties p100
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - aliased as XXX.XXX.100.138
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - aliased as XXX.XXX.236.88
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - aliased as XXX.XXX.7.97
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - aliased as XXX.XXX.100.81
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - aliased as 192.168.160.1
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - aliased as XXX.XXX.100.225
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - aliased as 10.3.32.1
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - aliased as 10.3.0.1
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - aliased as 10.15.100.1
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - aliased as 10.4.0.1
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - skipping alias fe80:0:0:0:a611:bbff:fef4:98ff as potentially not unique
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - aliased as 2001:db8:aaaa:f402:0:0:0:1
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - aliased as 2001:db8:aaaa:1314:0:0:0:1
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - skipping alias fe80:0:0:0:a611:bbff:fef4:98ff as potentially not unique
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - aliased as 2001:db8:aaaa:f401:0:0:0:1
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - aliased as 2001:db8:aaaa:f407:0:0:0:1
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - skipping alias fe80:0:0:0:a611:bbff:fef4:98ff as potentially not unique
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - aliased as 2001:db8:aaaa:f410:0:0:0:1
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - skipping alias fe80:0:0:0:a611:bbff:fef4:9860 as potentially not unique
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - skipping alias fe80:0:0:0:a611:bbff:fef4:98ff as potentially not unique
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - skipping alias fe80:0:0:0:a611:bbff:fef4:98ff as potentially not unique
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - aliased as 2001:db8:aaaa:f403:0:0:0:1
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - skipping alias fe80:0:0:0:a611:bbff:fef4:98ff as potentially not unique
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - aliased as 2001:db8:aaaa:1001:0:0:0:32
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - aliased as 2001:db8:aaaa:f405:0:0:0:1
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - aliased as 2001:db8:aaaa:f406:0:0:0:1
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - skipping alias fe80:0:0:0:a611:bbff:fef4:98ff as potentially not unique
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - skipping alias fe80:0:0:0:a611:bbff:fef4:98ff as potentially not unique
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - aliased as 2001:db8:aaaa:a20b:0:0:0:1
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - skipping alias fe80:0:0:0:a611:bbff:fef4:98ff as potentially not unique
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - aliased as 2001:db8:aaaa:a:0:0:0:d
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - skipping alias fe80:0:0:0:a611:bbff:fef4:98ff as potentially not unique
2024-08-29 09:55:32 UTC [684231] debug  resolving 21 aliases with max 100 outstanding requests
2024-08-29 09:55:32 UTC [684231] debug  [XXX.XXX.100.225] device - removed 20 aliases
2024-08-29 09:55:32 UTC [684231] debug ⬅ (info)  [XXX.XXX.100.225] aliases - added 21 new aliases and 21 subnets
2024-08-29 09:55:32 UTC [684231] debug ⮕ worker Discover::Properties p100

[...]

2024-08-29 10:06:54 UTC [687404] debug  [XXX.XXX.100.225] arpnip - processed 1045 ARP Cache entries
2024-08-29 10:06:54 UTC [687404] debug  [XXX.XXX.100.225] arpnip - processed 1551 IPv6 Neighbor Cache entries

And netdisco gets IPv6 subnets and neighbours for all the Vlan IPv6 Interfaces.

ollyg commented 3 weeks ago

Hi @elbuit Thanks for opening an issue. This is unlikely to be Netdisco itself (as far as I can tell from code), and likely either SNMP::Info or even an issue in the Cisco platform (that is, a bug). There are some things you can do to see where the data is lost:

(just to note that in your original message above, you had an arpnip for the first output but a "discover" for the second, which I assume was a mistake)

Netdisco uses ipv6_n2p_mac() and ipv6_n2p_addr() from SNMP::Info for the v6 table. You can see the underlying data:

~/bin/netdisco-do show -d XXX.XXX.100.225 -e ipv6_n2p_mac
~/bin/netdisco-do show -d XXX.XXX.100.225 -e ipv6_n2p_addr

However each of these methods actually tries three ways to get the v6 table from the device. I wonder if it's picking the "wrong" one (there is a first-success logic, but it could be missing the best option that way).

# in order:
~/bin/netdisco-do show -d XXX.XXX.100.225 -e c_inet_phys_addr
~/bin/netdisco-do show -d XXX.XXX.100.225 -e ip_n2p_phys_addr
~/bin/netdisco-do show -d XXX.XXX.100.225 -e i6_n2p_phys_addr

There's also another method which shows IPv6 interfaces:

~/bin/netdisco-do show -d XXX.XXX.100.225 -e ipv6_n2p_if

Maybe try each of these, with and without the v4 address applied, and see if they return a low or a high number of records?

I would not be surprised if it's a Cisco platform bug. But that doesn't mean we can't work around it in SNMP::Info. We just need the reproducing test case.

regards Oliver.

elbuit commented 3 weeks ago

(just to note that in your original message above, you had an arpnip for the first output but a "discover" for the second, which I assume was a mistake)

You're right, I wanted to do a arpnip ;-)

To sum, this router have several vlan interfaces with IPv4 only, several vlan interfaces with IPv6 only , and 2 interfaces ethernet directly routed. With this configuration(entries Wihtout IPv4 ) I only get one(or 2) IPv6 neigbour but if I add also an IPv4 address on IPv6 only vlan interface(entries With IPv4 ) I get the full IPv6 neigbours .

Tell me if you want me to do another test or modify something in snmpinfo. Thanks.

function entries With IPv4 entries Wihtout IPv4
ipv6_n2p_mac > 4000 2
ipv6_n2p_addr > 4000 2
c_inet_phys_addr undef undef
ip_n2p_phys_addr > 5000 > 1000
i6_n2p_phys_addr undef undef
ipv6_n2p_if > 4000 2

With IPv4 in interface vlan401

ipv6_n2p_mac more than 4000 entries

~/bin/netdisco-do show -d XXX.XXX.100.225 -e ipv6_n2p_mac

2024-09-05 07:21:06 UTC [3553645]  info App::Netdisco version 2.078000 loaded.
2024-09-05 07:21:07 UTC [3553645]  info show: [XXX.XXX.100.225]/ipv6_n2p_mac started at Thu Sep  5 09:21:07 2024
{
    34.2.16.32.1.7.32.16.20.162.11.0.0.0.0.0.0.0.2                  "f4:e9:d4:da:02:22",

    [...]

    179.2.16.32.1.7.32.16.20.244.1.52.184.66.8.246.104.19.204       "82:02:75:bf:e1:3e" (dualvar: 82),
    (...skipping 4425 keys...)
}
2024-09-05 07:21:13 UTC [3553645]  info show: finished at Thu Sep  5 09:21:13 2024
2024-09-05 07:21:13 UTC [3553645]  info show: status done: Showed ipv6_n2p_mac response from XXX.XXX.100.225

ipv6_n2p_addr more than 4000 entries

~/bin/netdisco-do show -d XXX.XXX.100.225 -e ipv6_n2p_addr

2024-09-05 07:22:33 UTC [3553957]  info App::Netdisco version 2.078000 loaded.
2024-09-05 07:22:33 UTC [3553957]  info show: [XXX.XXX.100.225]/ipv6_n2p_addr started at Thu Sep  5 09:22:33 2024
{
    34.2.16.32.1.7.32.16.20.162.11.0.0.0.0.0.0.0.2                  "2001:db8:aaaa:a20b:0000:0000:0000:0002" (dualvar: 2001),

    [...]

    179.2.16.32.1.7.32.16.20.244.1.48.193.118.90.99.19.35.3         "2001:db8:aaaa:f401:30c1:765a:6313:2303" (dualvar: 2001),
    (...skipping 4468 keys...)
}
2024-09-05 07:22:39 UTC [3553957]  info show: finished at Thu Sep  5 09:22:39 2024
2024-09-05 07:22:39 UTC [3553957]  info show: status done: Showed ipv6_n2p_addr response from XXX.XXX.100.225

c_inet_phys_addr returns undef


~/bin/netdisco-do show -d XXX.XXX.100.225 -e c_inet_phys_addr
2024-09-05 07:25:13 UTC [3554575]  info App::Netdisco version 2.078000 loaded.
2024-09-05 07:25:13 UTC [3554575]  info show: [XXX.XXX.100.225]/c_inet_phys_addr started at Thu Sep  5 09:25:13 2024
undef
2024-09-05 07:25:13 UTC [3554575]  info show: finished at Thu Sep  5 09:25:13 2024
2024-09-05 07:25:13 UTC [3554575]  info show: status done: Showed c_inet_phys_addr response from XXX.XXX.100.225

ip_n2p_phys_addr more than 5000 keys

~/bin/netdisco-do show -d XXX.XXX.100.225 -e ip_n2p_phys_addr

2024-09-05 07:25:54 UTC [3555116]  info App::Netdisco version 2.078000 loaded.
2024-09-05 07:25:54 UTC [3555116]  info show: [XXX.XXX.100.225]/ip_n2p_phys_addr started at Thu Sep  5 09:25:54 2024
{
    1.1.4.XXX.XXX.236.1                                        "84:b8:02:e1:80:00" (dualvar: 84),

     [...]

    175.1.4.10.3.55.17                                         "50:1c:b0:52:5c:78" (dualvar: 50),
    (...skipping 5558 keys...)
}
2024-09-05 07:26:01 UTC [3555116]  info show: finished at Thu Sep  5 09:26:01 2024
2024-09-05 07:26:01 UTC [3555116]  info show: status done: Showed ip_n2p_phys_addr response from XXX.XXX.100.225

i6_n2p_phys_addr returns undef

~/bin/netdisco-do show -d XXX.XXX.100.225 -e i6_n2p_phys_addr
2024-09-05 07:26:51 UTC [3555226]  info App::Netdisco version 2.078000 loaded.
2024-09-05 07:26:51 UTC [3555226]  info show: [XXX.XXX.100.225]/i6_n2p_phys_addr started at Thu Sep  5 09:26:51 2024
undef
2024-09-05 07:26:52 UTC [3555226]  info show: finished at Thu Sep  5 09:26:52 2024
2024-09-05 07:26:52 UTC [3555226]  info show: status done: Showed i6_n2p_phys_addr response from XXX.XXX.100.225

ipv6_n2p_if more than 4000 entries

 ~/bin/netdisco-do show -d XXX.XXX.100.225 -e ipv6_n2p_if
2024-09-05 07:36:26 UTC [3558532]  info App::Netdisco version 2.078000 loaded.
2024-09-05 07:36:26 UTC [3558532]  info show: [XXX.XXX.100.225]/ipv6_n2p_if started at Thu Sep  5 09:36:26 2024
{
    34.2.16.32.1.7.32.16.20.162.11.0.0.0.0.0.0.0.2                  34,
    34.2.16.254.128.0.0.0.0.0.0.246.233.212.255.254.218.2.34        34,
 [...]
    179.2.16.32.1.7.32.16.20.244.1.48.19.44.145.227.230.190.20      179,
    179.2.16.32.1.7.32.16.20.244.1.48.41.9.117.233.217.155.231      179,
    179.2.16.32.1.7.32.16.20.244.1.48.193.118.90.99.19.35.3         179,
    (...skipping 4635 keys...)
}
2024-09-05 07:36:33 UTC [3558532]  info show: finished at Thu Sep  5 09:36:33 2024
2024-09-05 07:36:33 UTC [3558532]  info show: status done: Showed ipv6_n2p_if response from XXX.XXX.100.225

WITHOUT IPv4 in int Vlan401

arpnip only gets 2 IPv6 entries.

2024-09-05 07:29:37 UTC [3555943] debug store_arp - device XXX.XXX.100.225 mac f4:e9:d4:da:02:22 ip fe80:0000:0000:0000:f6e9:d4ff:feda:0222
2024-09-05 07:29:37 UTC [3555943] debug store_arp - device XXX.XXX.100.225 mac f4:e9:d4:da:02:22 ip 2001:db8:aaaa:a20b:0000:0000:0000:0002

ipv6_n2p_mac 2 entries

~/bin/netdisco-do show -d XXX.XXX.100.225 -e ipv6_n2p_mac
2024-09-05 07:30:18 UTC [3556829]  info App::Netdisco version 2.078000 loaded.
2024-09-05 07:30:18 UTC [3556829]  info show: [XXX.XXX.100.225]/ipv6_n2p_mac started at Thu Sep  5 09:30:18 2024
{
    34.2.16.32.1.7.32.16.20.162.11.0.0.0.0.0.0.0.2             "f4:e9:d4:da:02:22",
    34.2.16.254.128.0.0.0.0.0.0.246.233.212.255.254.218.2.34   "f4:e9:d4:da:02:22"
}
2024-09-05 07:30:19 UTC [3556829]  info show: finished at Thu Sep  5 09:30:19 2024
2024-09-05 07:30:19 UTC [3556829]  info show: status done: Showed ipv6_n2p_mac response from XXX.XXX.100.225

ipv6_n2p_addr gets 2 entries

~/bin/netdisco-do show -d XXX.XXX.100.225 -e ipv6_n2p_addr
2024-09-05 07:31:40 UTC [3557378]  info App::Netdisco version 2.078000 loaded.
2024-09-05 07:31:40 UTC [3557378]  info show: [XXX.XXX.100.225]/ipv6_n2p_addr started at Thu Sep  5 09:31:40 2024
{
    34.2.16.32.1.7.32.16.20.162.11.0.0.0.0.0.0.0.2             "2001:db8:aaaa:a20b:0000:0000:0000:0002" (dualvar: 2001),
    34.2.16.254.128.0.0.0.0.0.0.246.233.212.255.254.218.2.34   "fe80:0000:0000:0000:f6e9:d4ff:feda:0222"
}
2024-09-05 07:31:41 UTC [3557378]  info show: finished at Thu Sep  5 09:31:41 2024
2024-09-05 07:31:41 UTC [3557378]  info show: status done: Showed ipv6_n2p_addr response from XXX.XXX.100.225

c_inet_phys_addr returns undef

~/bin/netdisco-do show -d XXX.XXX.100.225 -e c_inet_phys_addr

2024-09-05 07:33:08 UTC [3557786]  info App::Netdisco version 2.078000 loaded.
2024-09-05 07:33:08 UTC [3557786]  info show: [XXX.XXX.100.225]/c_inet_phys_addr started at Thu Sep  5 09:33:08 2024
undef
2024-09-05 07:33:08 UTC [3557786]  info show: finished at Thu Sep  5 09:33:08 2024
2024-09-05 07:33:08 UTC [3557786]  info show: status done: Showed c_inet_phys_addr response from XXX.XXX.100.225

ip_n2p_phys_addr returns more than 1000 entries

~/bin/netdisco-do show -d XXX.XXX.100.225 -e ip_n2p_phys_addr

2024-09-05 07:33:57 UTC [3557850]  info App::Netdisco version 2.078000 loaded.
2024-09-05 07:33:57 UTC [3557850]  info show: [XXX.XXX.100.225]/ip_n2p_phys_addr started at Thu Sep  5 09:33:57 2024
{
    1.1.4.XXX.XXX.236.1                                        "84:b8:02:e1:80:00" (dualvar: 84),
    1.1.4.XXX.XXX.236.11                                       "68:4f:64:08:58:be" (dualvar: 68),
    [...]
    175.1.4.10.3.55.17                                         "50:1c:b0:52:5c:78" (dualvar: 50),
    (...skipping 946 keys...)
}
2024-09-05 07:33:58 UTC [3557850]  info show: finished at Thu Sep  5 09:33:58 2024
2024-09-05 07:33:58 UTC [3557850]  info show: status done: Showed ip_n2p_phys_addr response from XXX.XXX.100.225

i6_n2p_phys_addr returns undef

 ~/bin/netdisco-do show -d XXX.XXX.100.225 -e i6_n2p_phys_addr
2024-09-05 07:35:11 UTC [3557985]  info App::Netdisco version 2.078000 loaded.
2024-09-05 07:35:11 UTC [3557985]  info show: [XXX.XXX.100.225]/i6_n2p_phys_addr started at Thu Sep  5 09:35:11 2024
undef
2024-09-05 07:35:12 UTC [3557985]  info show: finished at Thu Sep  5 09:35:12 2024
2024-09-05 07:35:12 UTC [3557985]  info show: status done: Showed i6_n2p_phys_addr response from XXX.XXX.100.225

ipv6_n2p_if returns 2 entries

~/bin/netdisco-do show -d XXX.XXX.100.225 -e ipv6_n2p_if
2024-09-05 07:35:44 UTC [3558456]  info App::Netdisco version 2.078000 loaded.
2024-09-05 07:35:44 UTC [3558456]  info show: [XXX.XXX.100.225]/ipv6_n2p_if started at Thu Sep  5 09:35:44 2024
{
    34.2.16.32.1.7.32.16.20.162.11.0.0.0.0.0.0.0.2             34,
    34.2.16.254.128.0.0.0.0.0.0.246.233.212.255.254.218.2.34   34
}
2024-09-05 07:35:45 UTC [3558456]  info show: finished at Thu Sep  5 09:35:45 2024
2024-09-05 07:35:45 UTC [3558456]  info show: status done: Showed ipv6_n2p_if response from XXX.XXX.100.225

Thanks.