Thank you, Morten, for pointing out debugging resources for trouble shooting topology issue.

I think that I may have found the reason why we are getting bad topology.

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.

Thanks again!

Zhi-Wei Lu IET-CR-Network Operations Center University of California, Davis (530) 752-0155

-----Original Message----- From: Morten Brekkevold morten.brekkevold@uninett.no Sent: Monday, March 19, 2018 4:02 AM To: Zhi-Wei Lu zwlu@ucdavis.edu Cc: nav-users@uninett.no Subject: Re: netmap and lag

On Fri, 16 Mar 2018 17:45:49 +0000 Zhi-Wei Lu zwlu@ucdavis.edu wrote:

...

We have a very limited test envioronment for NAV, our environment are Foundry based (->Brocade-> Arris and Extreme now). We have enabled lldp on edge switches, but not on ALL upstream routers. Even on connections with lldp on, the map does not show LAG ports correctly, it seems. Is there a manual way to fix netmap problem for those it fails to correctly identify the connections?

The supported router interface description conventions [1] do allow for specifically setting a `to_router` value - but I do not think the modern topology detector uses this information.

However, what exactly is wrong when "the map does not show LAG ports correctly"? What is your expectation vs. what does NAV actually show?

There is currently an open issue related to topology detection for LAG ports and LLDP [2], but if you haven't enabled LLDP everywhere, this may not be your problem. You might want to refer to the topology troubleshooting guide [3] (because Netmap is not always an accurate depiction of the topology information NAV has gathered).

[1] https://nav.uninett.no/wiki/subnetsandvlans#guide_lines_for_configuring_rout er_interface_descriptions [2] https://github.com/UNINETT/nav/issues/1669 [3] https://nav.uninett.no/doc/4.8/howto/debugging-topology.html

-- Morten Brekkevold UNINETT

-----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.

On Fri, 27 Apr 2018 23:52:40 +0000 Zhi-Wei Lu zwlu@ucdavis.edu wrote:

...

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 :)

Is it possible to have a manual/GUI way to set the connections, once set manually, the automatic updating would leave it along, if cdp/lldp finds discrepancy, warn about the inconsistency.

Not at the moment, no. It would be possible with some code modifications.

I believe old versions of NAV may have allowed interface descriptions to override topology, given various description string conventions. Using interface description strings to override or give more information about links and VLANs have been integral to NAV since its inception, so it would perhaps be our preferred way to implement (or reimplement) some support for this.

But again, I would also support a workaround for Brocade, in which the topology detector would not consider remote interface identifiers that aren't unique on the remote end.