Even if I enable LLDP, the "bug" occurs...

Is realy a bug or not?? Please help me.

2013/3/30 Bruno Galindro da Costa bruno.galindro@gmail.com

Some return??

2013/3/28 Bruno Galindro da Costa bruno.galindro@gmail.com

...

Some return??

Another thing that I've noticed is that these devices that haven't Uplink information, doesn't have the VLANs information too. The SNMP community and views are correctly configured in these devices.

UplinksN/A Another curious thing is the fact of these information are present in other devices of same model, vendor and SNMP configuration.

I don't know if it is a bug or a wrong configuration.

How can I debug the navtopology process to try solve this strange behaviour?

I realy appreciate this project and I want to help the community.

Thanks

2013/3/27 Bruno Galindro da Costa bruno.galindro@gmail.com

...

What is the process that discover device's uplink? Is /usr/local/nav/bin/navtopology? Is it possible to put it's execution in debug mode?

I've some devices that not have uplink information after added. Whitout this information, netmap can't draw it.

-- Att. Bruno Galindro da Costa

-- Att. Bruno Galindro da Costa

-- Att. Bruno Galindro da Costa

Morten,

I apologize for being insistent in this case. I understand this is an open project and all of the developers has many other preoccupations. I did not know that you was in vacation... Sorry again. ;)

Let's go to the facts: Right now, I already solved the problem.

Most of our switches not receive all of our 2000 Vlans (I work in UFSC) in trunk port. It receives only necessary VLANs to do their job, including the managment VLAN.

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.

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?

## Another questions:

1 - What is the diference beetween these two commands?

# navtopology --l2 --vlan

and

# navtopology --l2

The doc: https://nav.uninett.no/doc/howto/debugging-topology.html#the-analysis-stages... to use navtopology --l2 (without --vlan parameter) but in navcron's crontab, the execution considers the --vlan parameter

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?

3 - These same switches (A and B) don't have the VLAN information displayed in the Netmap's right frame. It's shown only the room and location information. Why?

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.

So, if I execute navtopology --l2 --vlan booth of explained actions will be executed one after the other?

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?

These pictures awnser your question?

Switch A - Trunk port 1:24

[image: Imagem inline 1]

Switch B - Trunk port 1:26

[image: Imagem inline 2]

2013/4/3 Morten Brekkevold morten.brekkevold@uninett.no

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

You need to open these ports in ipdevinfo, not in the tabular reports system. The lists of actual detected vlans, if any, on these ports should be there.

Hm ok. Here they are:

SWITCH A:

[image: Imagem inline 2]

SWITCH B:

[image: Imagem inline 3]

Actually there is no vlan detected on ports. I think this is the problem... How can I debug this?

2013/4/10 Morten Brekkevold morten.brekkevold@uninett.no

On Sat, 6 Apr 2013 16:40:36 -0300 Bruno Galindro da Costa < bruno.galindro@gmail.com> wrote:

...

So, if I execute navtopology --l2 --vlan booth of explained actions will

be

...

executed one after the other?

Correct.

...

...

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?

These pictures awnser your question?

No. These images only display the collected lists of VLANs allowed on the trunk ports.

...

Switch A - Trunk port 1:24 Switch B - Trunk port 1:26

You need to open these ports in ipdevinfo, not in the tabular reports system. The lists of actual detected vlans, if any, on these ports should be there.

-- Morten Brekkevold UNINETT

Morten,

About Netmap and VLAN discovering, I think it's better to talk with you by skype or another chat... Is it possible to we talk through chat when you return from your vacation?

tks

2013/4/15 Morten Brekkevold morten.brekkevold@uninett.no

On Wed, 10 Apr 2013 09:49:23 -0300 Bruno Galindro da Costa < bruno.galindro@gmail.com> wrote:

...

Actually there is no vlan detected on ports. I think this is the

problem...

...

How can I debug this?

That is indeed the problem. Make the navtopology process debug log by adding this line to the `[levels]` section of your `logging.conf`:

nav.topology = DEBUG

Using the --vlan switch to navtopology should log in detail how it descends for each VLAN from the router to the edge switches.

-- Morten Brekkevold UNINETT

Hi,

Some NAV services don't start automatically (like "ipdevpoll") when my NAV server starts. I have to do it manually with the command "nav start ipdevpoll", and so on for each service not started.

Do you know how can I make them start automatically ?

Thank you very much :)

Cédric.

On Thu, 18 Jul 2013 17:53:47 -0300 Bruno Galindro da Costa bruno.galindro@gmail.com wrote:

To temporaly "solve" this issue, I've enabled LLDP on all switches.

But, this issue accours with other netboxes that doesn't have lldp

protocol (like printers and some wireless devices). I've found on navtopology's debug log these errors that maybe point us to a solution:

DEBUG:nav.topology.vlan:could not find reverse edge for (Netbox: y.x.250.134, <Netbox: y.x.204.217>, <Interface: 5:18 at y.x.250.134>)

What meaning these messages?

This message means that the topology detector has found out from y.x.250.134 that it's interface 5:18 is connected to y.x.204.217. It has, however, not found any information from y.x.204.217 that it is connected back to y.x.250.134.

This is typically the case with servers and other devices that don't talk SNMP. It is not a problem, unless y.x.204.217 is an SNMP-enabled device that has switch forwarding tables or LLDP/CDP support.

On 30.07.13 16:54, Bruno Galindro da Costa wrote:

Morten,

 y.x.204.217 is an SNMP-enabled device, but I don't know if it has switch

forwarding tables... It is a printer (Lexmark X464de). But this is a strange behaviour because there are other printers like that (with the same model) that are shown in netmap. I've already revised the snmp configuration and everything is good.

 Today, that device was maped into netmap. I think some strange behaviour

was occured with that device which caused the error.

 If this error occurs again, how can I debug it? Is there any snmp command

that I can exec to see with tcpdump what is happening?

The fact that navtopology could not find "a reverse edge" from this printer is not an error. It is just debug information. Unless the printer supports LLDP/CDP you're not likely to ever find this information from the printer itself. A printer doesn't do ethernet switching, so there would normally not be any forwarding tables to be found.

NAV will normally trust a switch that says a printer is a neighbor on one of its ports, and insert that information into its topology.

If the printer was previously missing from your NAV topology and then suddenly appeared, I cannot say for sure why without getting a ton of debug information from you.

There's this howto, if you're interested: https://nav.uninett.no/doc/howto/debugging-topology.html

Thanks!

2013/7/26 Morten Brekkevold morten.brekkevold@uninett.no

On Tue, 16 Jul 2013 13:33:29 -0300 Bruno Galindro da Costa < bruno.galindro@gmail.com> wrote:

...

About Netmap and VLAN discovering, I think it's better to talk with

you

...

by skype or another chat... Is it possible to we talk through chat when

you

...

return from your vacation?

I would recommend you use the #nav IRC channel on Freenode. All the developers and several users are active in that channel.

Caveat: Although some of our interns may be active in #nav 24/7, most of us are only active during working hours, 8-16 CEST. If you're in Brazil, I think the time difference during daylight saving time is about 5 hours.

-- Morten Brekkevold UNINETT