On Tue, 2 Apr 2013 15:08:10 -0300 Bruno Galindro da Costa bruno.galindro@gmail.com wrote:
Let's go to the facts: Right now, I already solved the problem.
That's great :)
As we have many managed switches (650 approximately), we have dedicated 3 IP blocks (Class C) for managment use. Each class is associated with a specific VLAN. So, a switch that have your managment interface configured for VLAN x, can have a uplink to another switch with VLAN y configured in it's managment interface. Because of this, the CAM's method never will find the mac address of neighborhood because they are in different VLANs! To "solve" this with a minimum impact, I think that I need to use LLDP.
What you're saying sounds plausible, but I'm unconvinced it is really so.
Any ethernet frame originating from the uplink switch will cause one of its MAC addresses to be registered in the cam table for the uplink port. If your switches are STP enabled, I'm guessing STP traffic would do it. If you enabled LLDP, that would probably also do it (not that it matters any longer at that point).
Reading docs, I've noticed that NAV prefers LLDP over CDP and CAM. Before configure LLDP in all of my switches, the ipdevpool topology process have inserted into database all of the MAC addresses through CAM's method. I've configure two of my switches with LLDP. In my tests, LLDP worked as expected, but all of the CAM's MAC addresses still in database. Is this a spected behaviour? Is it possible to clear these "old" MACs?
Still in the database where? If you are talking about "neighbor candidates", as described in the topology troubleshooting guide: Everything that can be collected, will be collected.
When the guide says LLDP is preferred over CAM, it only means that data sourced from LLDP takes precedence over data sourced from CAM. I.e. if a port in the neighbor candidate report has both CAM entries and LLDP entries, navtopology will use only the LLDP entries.
1 - What is the diference beetween these two commands?
# navtopology --l2 --vlan
and
# navtopology --l2
The `--l2` option will do physical topology detection, based on the neighbor candidate data. The `--vlan` option will use detected physical topology and the collected VLAN configuration to detect the VLAN topologies of your network.
2 - Even if the issue reported before was "solved" by passing the same management VLAN of the trunked switch, the Uplink information still empty (N/A). They are physically connected -> Switch A port 1/0/5 to Switch B port 1/24. Netmap shows this conection, the "Connected to" and "Remote If" fileds are correct on both equipaments, but no Uplink information. Why?
The uplink field in ipdevinfo requires the proper VLAN detection to have taken place (since VLAN detection includes direction the link). If you click the invidual involved ports in ipdevinfo, does NAV list any configured/detected VLANs for them?