IPv6 link locals, dual stack and neighbour discovery

[rkerr]

In an environment with dual stack hosts netdisco seems to do some odd things with neighbour discovery - preferring to try to discover link local IPv6 addresses over reachable IPv4 addresses.

I've tried putting fe80::/64 in discover_no - which at least stops netdisco hanging trying to discover a load of link local addresses it will never be able to reach, but the topology is still broken and I can't seem to get it to acknowledge an IPv4 address is also being advertised or discover/display it.

The LLDP table seems to contain both addresses:

SNMP::Info::_load_attr lldp_rman_addr : leaf = .1.0.8802.1.1.2.1.4.2.1.3 , var = $VAR1 = bless( [ 'lldpRemManAddrIfSubtype', '0.52.1.1.4.y.y.y.y', 'ifIndex', 'INTEGER' ], 'SNMP::Varbind' ); SNMP::Info::_load_attr lldp_rman_addr : leaf = .1.0.8802.1.1.2.1.4.2.1.3 , var = $VAR1 = bless( [ 'lldpRemManAddrIfSubtype', '0.52.1.2.16.254.128.0.0.0.0.0.0.22.171.236.255.254.5.30.128', 'ifIndex', 'INTEGER' ], 'SNMP::Varbind' );

But netdisco seems to only try the link local address on the port and ignore the IPv4 address entirely:

[792159] 2025-01-23 16:20:48 debug [z.z.z.z] neigh - IP on 52: using fe80:0:0:0:16ab:ecff:fe05:1e80 as canonical form of fe80:0000:0000:0000:16ab:ecff:fe05:1e80 [792159] 2025-01-23 16:20:48 debug [z.z.z.z] neigh - fe80:0:0:0:16ab:ecff:fe05:1e80 with ID [14:ab:ec:05:1e:80] on 52 [792159] 2025-01-23 16:20:48 debug is_discoverable: fe80:0:0:0:16ab:ecff:fe05:1e80 matched discover_no [792159] 2025-01-23 16:20:48 debug [z.z.z.z] neigh - skip: fe80:0:0:0:16ab:ecff:fe05:1e80 of type [Aruba JL256A 2930F-48G-PoE+-4SFP+ Switch, revision WC.16.11.0021, ROM WC.16.01.0010 (/ws/swbuildm/rel_beluru_qaoff/code/build/lvm(swbuildm_rel_beluru_qaoff_rel_beluru))] excluded by discover_* config

I guess there might be cases where you might want to try to discover link local addresses (single flat network segment) but it seems like a pretty rare edge case and I wonder if it should be disabled by default. I certainly can't see a good reason to ever prioritise link locals over other addresses.

[ollyg]

somewhat relates to the fix for https://github.com/netdisco/netdisco/issues/1232

[ollyg]

also relates to this wishlist item https://github.com/netdisco/netdisco/issues/608

[ollyg]

and relates to https://github.com/netdisco/snmp-info/issues/531

[ollyg]

Hi @rkerr I've implemented a fix for this but I need to test a bit more before releasing.

[ollyg]

Oops didn’t mean to push that commit to GH. But anyway a fix is coming…

On Sat, 1 Feb 2025 at 19:45, Oliver Gorwits @.***> wrote:

Hi @rkerr https://github.com/rkerr I've implemented a fix for this but I need to test a bit more before releasing.

— Reply to this email directly, view it on GitHub https://github.com/netdisco/snmp-info/issues/549, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAHHVMGHDACG5WLFYLUOVL2NUP4JAVCNFSM6AAAAABVXY7AV6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMRZGA4DMMJUHE . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[ollyg]

Hi @rkerr please check out the new release 2.082002 which I think has the fix you need

[rkerr]

It seems to be know to ignore the link locals now:

[25244] 2025-02-03 08:40:47 debug [z.z.z.z] neigh - IP on 52: using fe80:0:0:0:16ab:ecff:fe05:1e80 as canonical form of fe80:0000:0000:0000:16ab:ecff:fe05:1e80 [25244] 2025-02-03 08:40:47 debug [z.z.z.z] neigh - fe80:0:0:0:16ab:ecff:fe05:1e80 is a non-unique local address - skipping

But still doesn't seem to be processing the IPv4 ones

[ollyg]

Hi @rkerr OK thanks, some progress at least!

You already confirmed that the device is returning both addresses in the table. I'm not sure if our libraries are chomping that or something else wrong.

Are you able to share with me an snmpwalk from the device? (snmpwalk -v 2c -c public -ObentU x.x.x.x .1) ?

If not, I think we're looking at: netdisco-do show -d x.x.x.x -e lldp_ipv6 -D

[rkerr]

Probably don't want to leave a full walk in a public github issue but happy to share it another way?

Here's the info from the show command not sure it's a lot of help:

~ $ netdisco-do show -d x.x.x.x -e lldp_ipv6 -D [51946] 2025-02-03 16:50:40 info App::Netdisco version 2.082002 loaded. [51946] 2025-02-03 16:50:40 info show: [x.x.x.x]/lldp_ipv6 started at Mon Feb 3 16:50:40 2025 [51946] 2025-02-03 16:50:40 debug show: running with timeout 600s [51946] 2025-02-03 16:50:40 debug //// CHECK \\ phase [51946] 2025-02-03 16:50:40 debug ⮕ worker Internal::BackendFQDN p1000000 [51946] 2025-02-03 16:50:40 debug ⮕ worker Internal::SNMPFastDiscover p1000000 [51946] 2025-02-03 16:50:40 debug running with configured SNMP timeouts [51946] 2025-02-03 16:50:40 debug ⮕ worker Show p0 [51946] 2025-02-03 16:50:40 debug ⬅ (done) Show is able to run [51946] 2025-02-03 16:50:40 debug //// MAIN \\ phase [51946] 2025-02-03 16:50:40 debug ⮕ worker Show p100 [51946] 2025-02-03 16:50:40 debug snmp reader cache warm: [x.x.x.x] [51946] 2025-02-03 16:50:40 debug [x.x.x.x:161] try_connect with v: 3, t: 0.2, r: 0, class: SNMP::Info::Layer2::HP, comm: { 0.51.1 "fe80:0000:0000:0000:16ab:ecff:fe06:33c0", 0.52.1 "fe80:0000:0000:0000:16ab:ecff:fe05:1e80" } [51946] 2025-02-03 16:50:41 debug ⬅ (done) Showed lldp_ipv6 response from x.x.x.x [51946] 2025-02-03 16:50:41 info show: finished at Mon Feb 3 16:50:41 2025 [51946] 2025-02-03 16:50:41 info show: status done: Showed lldp_ipv6 response from x.x.x.x

[ollyg]

Hi yes I should have asked for c_ip as well as lldp_ipv6

Anyway the snmpwalk, if you can send it to oliver at cpan dot org, that'd be great.

[ollyg]

Moved to SNMP::Info repo because Netdisco would log if it could see the IPv4 entry. Not sure what's going on but _lldp_addr_index in LLDP.pm should work for this.

Did not get a full snmpwalk from ticket author so could not troubleshoot further.