Welcome, Guest. Please login or register.

Author Topic: Link discovering at buggy LLDP devices  (Read 5615 times)

steffen1

  • Guest
Link discovering at buggy LLDP devices
« on: May 13, 2010, 01:05:28 PM »
Hello,

I need very urgently a workarround for devices, that L2-discovery protocol doesnt provides the neighbor IP addresse, like JunOS v10 devices. The original code will skip this link:

Code: [Select]
$r = $session->get_table('1.0.8802.1.1.2.1.4.2.1.3'); # Get LLDP IPs
$err = $session->error;
if ($err){
print "Qa";
print "$err\n" if $main::opt{d};
}else{
while( my($key, $val) = each(%{$r}) ) {
my @k = split (/\./,$key);
$neb{$k[12]}{$k[13]}{'ip'} = (defined $k[19])?&misc::MapIp("$k[16].$k[17].$k[18].$k[19]"):'';
}
}

I've got 2 ideas:
1. derive neighbor devices IP by using the node table using LLDP neighbor MAC
2. extending existing OUI discovering by link maintanance using found MAC to search in node table for neighbors IP.

Q)
Does anybody did this allready? Remo, will this be a topic in v1.0.6 you are currently working on and may I take a look at this part of code? What method would you use to solve the problem?

thx for hints, Steffen

rickli

  • Administrator
  • Hero Member
  • *****
  • Posts: 2607
    • View Profile
    • NeDi
Re: Link discovering at buggy LLDP devices
« Reply #1 on: May 13, 2010, 05:39:55 PM »
What do you need, the link or just the ip for discovery? In the latter case you could simply use ouidev and -o...
Please consider Other-Invoices on your NeDi installation for an annual contribution, tx!
-Remo

steffen1

  • Guest
Re: Link discovering at buggy LLDP devices
« Reply #2 on: May 13, 2010, 07:50:07 PM »
I did OID discovering as well, but it will only benefit in finding new devices or save work for seedfile maintenance at initial discovering. But -o doesnt maintain the linktable. Though - It doesnt work nor can I find it in the code that it is intented to should work.

rickli

  • Administrator
  • Hero Member
  • *****
  • Posts: 2607
    • View Profile
    • NeDi
Re: Link discovering at buggy LLDP devices
« Reply #3 on: May 15, 2010, 07:29:24 PM »
Nope doesn't maintain links (anymore, as it wasn't reliable enough). How about adding static links?
Please consider Other-Invoices on your NeDi installation for an annual contribution, tx!
-Remo

steffen1

  • Guest
Re: Link discovering at buggy LLDP devices
« Reply #4 on: May 15, 2010, 09:07:39 PM »
For this network a colleque of mine found a solution at Juniper level: you can configure an LLDP management IP addresse. With this setting, the IP-OID will be filled and nedi shows the LLDP links.

We need dynamic links.

... and meanwhile I found the problem within the nedi lldp code: $k[11] need not be 0 allways.
If you replace all 1.0.8802.1.1.2.1.4.1.1.x.0.$k[12].$k[13] 1.0.8802.1.1.2.1.4.1.1.x.$k[11].$k[12].$k[13], the code is also working for unconfigured JunOS10 devices, because Juniper uses lldpRemName - not IP - native.

I will update the netmon-nedi-libs and Juniper-defs after more testing in this forum soon. There will be a lot of improvement for Juniper devices.
« Last Edit: May 19, 2010, 02:48:19 PM by steffen1 »

rickli

  • Administrator
  • Hero Member
  • *****
  • Posts: 2607
    • View Profile
    • NeDi
Re: Link discovering at buggy LLDP devices
« Reply #5 on: May 25, 2010, 09:50:11 PM »
Yepp, vasily pointed that one out as well. It's working fine now. The main problem to get LLDP (and CDP) working properly is to take care of all those inconsistencies...
Please consider Other-Invoices on your NeDi installation for an annual contribution, tx!
-Remo

SteffenS

  • Guest
Re: Link discovering at buggy LLDP devices
« Reply #6 on: May 27, 2010, 03:17:18 PM »
Yes - with Nortel (or Avaya since 2010) devices like ERS45xx and ERS25xx also!

I have replaced all the ".0.$k[12].$k[13]" with ".$k[11].$k[12].$k[13]" in the lldp-section.

Works fine now (show now mac-addresses instead of hieroglyphs before).

Thanks you
Steffen

SteffenS

  • Guest
Re: Link discovering at buggy LLDP devices
« Reply #7 on: May 27, 2010, 05:35:26 PM »
By the way:

An snmpwalk on one of this Avaya/Nortel-device (ERS2526T) with 2 lldp-neighbor (one HP,one Nortel) at OID 1.0.8802.1.1.2.1.4.1.1 it tell me this:
Code: [Select]
nedio45:/var/nedi#snmpwalk -v2c -c public 10.73.53.113 1.0.8802.1.1.2.1.4.1.1
iso.0.8802.1.1.2.1.4.1.1.4.171195276.1.4 = INTEGER: 4
iso.0.8802.1.1.2.1.4.1.1.4.336630752.24.5 = INTEGER: 4
iso.0.8802.1.1.2.1.4.1.1.5.171195276.1.4 = Hex-STRING: 00 1F 9A 69 54 01
iso.0.8802.1.1.2.1.4.1.1.5.336630752.24.5 = Hex-STRING: 00 12 79 F8 E9 C0
iso.0.8802.1.1.2.1.4.1.1.6.171195276.1.4 = INTEGER: 3
iso.0.8802.1.1.2.1.4.1.1.6.336630752.24.5 = INTEGER: 7
iso.0.8802.1.1.2.1.4.1.1.7.171195276.1.4 = Hex-STRING: 00 1F 9A 69 54 43
iso.0.8802.1.1.2.1.4.1.1.7.336630752.24.5 = STRING: "23"
iso.0.8802.1.1.2.1.4.1.1.8.171195276.1.4 = STRING: "Unit 2 Port 2"
iso.0.8802.1.1.2.1.4.1.1.8.336630752.24.5 = STRING: "23"
iso.0.8802.1.1.2.1.4.1.1.9.171195276.1.4 = STRING: "DESWSTUN01"
iso.0.8802.1.1.2.1.4.1.1.9.336630752.24.5 = STRING: "DESWSTUlldptestHP2524"
iso.0.8802.1.1.2.1.4.1.1.10.171195276.1.4 = STRING: "Ethernet Routing Switch 4548GT        HW:05       FW:5.1.0.7   SW:v5.1.3.019"
iso.0.8802.1.1.2.1.4.1.1.10.336630752.24.5 = STRING: "HP J4813A ProCurve Switch 2524, revision F.05.72, ROM F.02.01  (/sw/code/build/info(s02))"
iso.0.8802.1.1.2.1.4.1.1.11.171195276.1.4 = STRING: " "
iso.0.8802.1.1.2.1.4.1.1.11.336630752.24.5 = STRING: " "
iso.0.8802.1.1.2.1.4.1.1.12.171195276.1.4 = STRING: " "
iso.0.8802.1.1.2.1.4.1.1.12.336630752.24.5 = STRING: " "
nedio45:/var/nedi#

So you can see that the ERS4548 tells his port-id with type MAC (1.0.8802.1.1.2.1.4.1.1.6...="3") in 0.8802.1.1.2.1.4.1.1.7..., but the port-description will send as string (1.0.8802.1.1.2.1.4.1.1.8.171195276.1.4="Unit 2 Port 2").
But nedi don't show me this port-description if port-id=MAC, only the port-id(=MAC).

line 990-993 in my libsnmp.pl looks so:
Code: [Select]
if(${$r}{"1.0.8802.1.1.2.1.4.1.1.6.$k[11].$k[12].$k[13]"} eq 7 and $val =~ /^[0-9]+$/){ # Prefer Descr if subtype is local and a #
$neb{$k[12]}{$k[13]}{'if'} = &misc::Shif(${$r}{"1.0.8802.1.1.2.1.4.1.1.8.$k[11].$k[12].$k[13]"});
}elsif(${$r}{"1.0.8802.1.1.2.1.4.1.1.6.$k[11].$k[12].$k[13]"} eq 3){ # if subtype is MAC address
$neb{$k[12]}{$k[13]}{'if'} = unpack("H16",$val);

My question: How can I test if the received value from .8. is type "STRING" and not "HEX-STRING" to use this port-description instead of the MAC-address?

« Last Edit: May 27, 2010, 05:47:49 PM by SteffenS »

rickli

  • Administrator
  • Hero Member
  • *****
  • Posts: 2607
    • View Profile
    • NeDi
Re: Link discovering at buggy LLDP devices
« Reply #8 on: May 29, 2010, 11:37:47 PM »
 :-\ But now you see what I mean...
Please consider Other-Invoices on your NeDi installation for an annual contribution, tx!
-Remo

steffen1

  • Guest
Re: Link discovering at buggy LLDP devices
« Reply #9 on: May 31, 2010, 03:20:24 PM »
Quote
How can I test if the received value from .8. is type "STRING" and not "HEX-STRING" to use this port-description instead of the MAC-address?

For reverse MIB engineering against to a real system I use the attached script. It is net-snmp based. Look at the Path section inside the script to adjust the location of your extracted private MIBs.