This commit makes the Layer3 root_ip determination a little more picky about
the OSPF ID. My initial patch that Oliver committed would blindly accept the
OSPF ID if it was set. Instead, we check if it's actually a route advertised
by the device (in case someone uses OSPF IDs that aren't actually related to
the device), otherwise we fall back to picking the first /32 in the routing
table.
The previous behavior of root_ip meant that whatever /32 hosted by the device
that got listed first would be chosen as the root_ip. If the device only
serves one /32 this works fine, but if there are multiple /32s we could easily
pick the one that is not the intended address meant for management.
Instead, before we pick whatever /32 may exist, we now try to pick the /32 that
is also the OSPF router ID (the router ID is a 32-bit unique identifier which,
while not guaranteed, tends to be an IPv4 address unique to the device).
Otherwise we fall back to the previous method of finding the root_ip.
These two points in CiscoStack use a value from a hash in a numerical
comparison without verifying they exist. If they don't, Perl warnings get
emitted. Instead, we check for existence first, then compare the value.
Aruba controllers can act as L3 devices and provide L3 information through the
standard MIBs. This change makes Aruba devices get recognized as such.
Layer2.pm and Layer3.pm provide roughly the same functionality so there should
be little to no impact for Aruba devices only acting as L2 entities.
Brian De Wolf