-----Original Message----- From: Morten Brekkevold morten.brekkevold@uninett.no Sent: Monday, April 16, 2018 11:29 PM To: Zhi-Wei Lu zwlu@ucdavis.edu Cc: nav-users@uninett.no Subject: Re: netmap and lag
On Thu, 12 Apr 2018 16:31:25 +0000 Zhi-Wei Lu zwlu@ucdavis.edu wrote:
We are a "Brocade" (Foundry->Brocade->Ruckus&Extreme now) shop. When we enabled lldp on routers, the lldp chassis ID and port ID was populated with a single MAC address, typically the first interface MAC address. It turns out every physical port becomes a candidate port!
The discerning information, however, is contained in the port description such as GigabitEthernet3/1, which is probably not being used for NAV topology processing yet. For our Brocade edge switches, the port ID indeed matches the MAC address of the port, it detects the topology just fine.
NAV primarily uses the remote chassis id and remote port IDs from the LLDP records to identify remote ports.
If NAV fails to find a match for these, it will try to use the remote port description and remote sysname fields of the LLDP record to find a match.
So, if your switches provide incorrect IDs in the records, and these can be matched to something, NAV will never look at the description fields.
I'm not sure if this could be worked around in NAV at all. One suggestion would be to compare a positive ID with the description fields, but vendors put all kinds of crap in the description fields, making such an approach virtually useless, IMHO.
I'd kick Brocade in the shin to see if they would fix their issue, but I'm all ears if you have a suggestion for a workaround at the NMS level :)
I don't think Extreme and Ruckus (Brocade) would change anything with their router code. On the router, "show interface brief", shows nearly all mac-addresses are the same, the mac-address of the first interface! We will have to identify the remote device, if it is a Brocade device, one has to use lldpRemPortDesc to identify the port.