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?

--
Morten Brekkevold
UNINETT