[ietf85-tech] Billo: netdisco question
Bjoern A. Zeeb
bzeeb-lists at lists.zabbadoz.net
Sat Nov 3 23:50:21 PDT 2012
On Sun, 4 Nov 2012, Bjoern A. Zeeb wrote:
> On Sat, 3 Nov 2012, Bill Fenner wrote:
>
>> I've never seen this behavior before. I agree that it's probably the chassis ID. If the MIB is reporting the chassis ID still, then I don't know what to do. If the MIB is reporting the right thing and netdisco is not finding it, then this is probably the problem that bz pointed out yesterday that "netdisco -r" isn't seeming to work, while "netdisco -R" is. The whole system is built around the idea that "netdisco -r" will work, so I recommend debugging that (e.g., looking at the logs).
>
> /usr/local/netdisco/netdisco you mean; I have now learnt that just
> startuing netdisco picks up the config file from
> /usr/loca./etc/netdisco and not the one from /usr/local/netdisco aka.
> /home/fenner/src/netdisco and it seems the default config files were
> never ever touched.
>
> This may explain the one or other strange things... like why the
> pasted command from the nightly cronjob did work and the discover loop
> did work but just running netdisco -r did not do updates.
>
> It doesn't explain why the DB entry was never updated as discover-loop
> seems to call it with the full path and was otherwise working. I
> guess at this point that this field is not updated unless there is
> another change condition on the entry forcing it to update.
>
> It seems the sw-noc is indeed reporting the right thing:
> SNMPv2-SMI::enterprises.9.9.23.1.1.1.1.2.10110 = INTEGER: 1
> SNMPv2-SMI::enterprises.9.9.23.1.1.1.1.4.10110 = INTEGER: 0
> SNMPv2-SMI::enterprises.9.9.23.1.1.1.1.5.10110 = INTEGER: 0
> SNMPv2-SMI::enterprises.9.9.23.1.1.1.1.6.10110 = STRING: "GigabitEthernet0/10"
> SNMPv2-SMI::enterprises.9.9.23.1.2.1.1.3.10110.9 = INTEGER: 1
> SNMPv2-SMI::enterprises.9.9.23.1.2.1.1.4.10110.9 = Hex-STRING: 82 81 01 19
> SNMPv2-SMI::enterprises.9.9.23.1.2.1.1.5.10110.9 = STRING: "Cisco IOS Software, C3560E Software (C3560E-UNIVERSALK9-M), Version 12.2(55)SE1, RELEASE SOFTWARE (fc1)
> SNMPv2-SMI::enterprises.9.9.23.1.2.1.1.6.10110.9 = STRING: "SW-IDF3.meeting.ietf.org"
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> SNMPv2-SMI::enterprises.9.9.23.1.2.1.1.7.10110.9 = STRING: "GigabitEthernet0/1"
> SNMPv2-SMI::enterprises.9.9.23.1.2.1.1.8.10110.9 = STRING: "cisco WS-C3560E-24PD"
> SNMPv2-SMI::enterprises.9.9.23.1.2.1.1.9.10110.9 = Hex-STRING: 00 00 00 28
> SNMPv2-SMI::enterprises.9.9.23.1.2.1.1.10.10110.9 = ""
> SNMPv2-SMI::enterprises.9.9.23.1.2.1.1.11.10110.9 = INTEGER: 1
> SNMPv2-SMI::enterprises.9.9.23.1.2.1.1.12.10110.9 = INTEGER: 3
> SNMPv2-SMI::enterprises.9.9.23.1.2.1.1.24.10110.9 = Timeticks: (378411139) 43 days, 19:08:31.39
>
> Though 43 days is a slight overestimate I fear.... Silly NTP?
>
Whatever it is t's back in the DB:
'sw-noc' => {
'GigabitEthernet0/10' => '00:1e:f7:e8:35:00',
'GigabitEthernet0/8' => 'ap101'
},
netdisco=> SELECT ip,remote_ip,remote_id FROM public.device_port WHERE remote_id is NOT NULL and ip='130.129.1.30';
ip | remote_ip | remote_id
--------------+---------------+------------------------
130.129.1.30 | 130.129.2.101 | ap101.meeting.ietf.org
130.129.1.30 | 130.129.1.25 | 00:1e:f7:e8:35:00
(2 rows)
Where TF does this value come from; this is obscure....
AHA
iso.0.8802.1.1.2.1.4.1.1.4.0.10.1 = INTEGER: 4
iso.0.8802.1.1.2.1.4.1.1.5.0.10.1 = Hex-STRING: 00 1E F7 E8 35 00
^^^^^^^^^^^^^^^^^^^^^^^^^^
iso.0.8802.1.1.2.1.4.1.1.6.0.10.1 = INTEGER: 5
iso.0.8802.1.1.2.1.4.1.1.7.0.10.1 = STRING: "Gi0/1"
iso.0.8802.1.1.2.1.4.1.1.8.0.10.1 = STRING: "GigabitEthernet0/1"
iso.0.8802.1.1.2.1.4.1.1.9.0.10.1 = STRING: "SW-IDF3.meeting.ietf.org"
iso.0.8802.1.1.2.1.4.1.1.10.0.10.1 = STRING: "Cisco IOS Software, C3560E Software (C3560E-UNIVERSALK9-M), Version 12.2(55)SE1, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Thu 02-Dec-10 06:44 by prod_rel_team"
iso.0.8802.1.1.2.1.4.1.1.11.0.10.1 = Hex-STRING: 28 00
iso.0.8802.1.1.2.1.4.1.1.12.0.10.1 = Hex-STRING: 20 00
iso.0.8802.1.1.2.1.4.2.1.3.0.10.1.1.4.130.129.1.25 = INTEGER: 3
iso.0.8802.1.1.2.1.4.2.1.4.0.10.1.1.4.130.129.1.25 = INTEGER: 1
iso.0.8802.1.1.2.1.4.2.1.5.0.10.1.1.4.130.129.1.25 = OID: SNMPv2-SMI::zeroDotZero
iso.0.8802.1.1.2.1.5.4795.1.2.2.0 = STRING: "WS-C3560CG-8PC-S (PowerPC):C0"
iso.0.8802.1.1.2.1.5.4795.1.2.3.0 = ""
iso.0.8802.1.1.2.1.5.4795.1.2.4.0 = STRING: "12.2(55)EX2"
iso.0.8802.1.1.2.1.5.4795.1.2.5.0 = ""
iso.0.8802.1.1.2.1.5.4795.1.2.6.0 = STRING: "Cisco Systems, Inc."
iso.0.8802.1.1.2.1.5.4795.1.2.7.0 = STRING: "WS-C3560CG-8PC-S"
iso.0.8802.1.1.2.1.5.4795.1.2.8.0 = ""
So the problem is indeed lldp_id() and how it's used ona CDP + LLDP
device from what I read in the implementations.
What we really want as remote_id is the
iso.0.8802.1.1.2.1.4.1.1.9.0.10.1
not the iso.0.8802.1.1.2.1.4.1.1.5.0.10.1
it seems. So I have slightly adjusted SNMP/Info/LLDP.pm::lldp_id()
sub lldp_id {
my $lldp = shift;
my $partial = shift;
my $ch_type = $lldp->lldp_rem_id_type($partial) || {};
my $ch = $lldp->lldp_rem_id($partial) || {};
+ my $sn = $lldp->lldp_rem_sysname($partial) || {};
my %lldp_id;
foreach my $key ( keys %$ch ) {
my $id = $ch->{$key};
next unless $id;
my $type = $ch_type->{$key};
next unless $type;
# May need to format other types in the future
if ( $type =~ /mac/ ) {
$id = join( ':', map { sprintf "%02x", $_ } unpack( 'C*', $id ) );
}elsif ($type eq 'networkAddress'){
if ( length(unpack('H*', $id)) == 10 ){
# IP address (first octet is sign, I guess)
my @octets = (map { sprintf "%02x",$_ } unpack('C*', $id))[1..4];
$id = join '.', map { hex($_) } @octets;
}
}
$lldp_id{$key} = $id;
}
+ foreach my $key ( keys %$sn ) {
+ my $id = $sn->{$key};
+ next unless $id;
+ $lldp_id{$key} = $id;
+ }
return \%lldp_id;
}
Seems to do the trick:
netdisco=> SELECT ip,remote_ip,remote_id FROM public.device_port WHERE remote_id is NOT NULL and ip='130.129.1.30';
ip | remote_ip | remote_id
--------------+---------------+--------------------------
130.129.1.30 | 130.129.2.101 | ap101.meeting.ietf.org
130.129.1.30 | 130.129.1.25 | SW-IDF3.meeting.ietf.org
(2 rows)
TATA
However theere is/was a disturbance in force as so far I have not done
anything else but rancid lost a few devices.... Might have to back
this out if that was me and disabled LLDP... will see...
>
> Anyway..... time to cause (no) trouble.
>
>
--
Bjoern A. Zeeb You have to have visions!
Stop bit received. Insert coin for new address family.
More information about the ietf85-tech
mailing list