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.
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
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
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
On Wed, 27 Mar 2013 11:00:13 -0300 Bruno Galindro da Costa bruno.galindro@gmail.com wrote:
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.
Please read our topology troubleshooting guide [1]. If it doesn't help, please post your findings to the list.
Your comments on the guide itself are also very welcome; it was written only recently and hasn't been field tested yet.
[1] https://nav.uninett.no/doc/howto/debugging-topology.html
On Thu, 28 Mar 2013 13:35:46 -0300 Bruno Galindro da Costa bruno.galindro@gmail.com wrote:
Some return??
Sorry for the late replies. For most of us, this a dayjob, and last week most Norwegians were on easter vacation. Some of us even started early :)
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.
Where in your network are the affected device uplinked to? Are the uplinks trunked? What do the corresponding downlinks look like in NAV?
How can I debug the navtopology process to try solve this strange behaviour?
Unfortunately, navtopology doesn't provide much debug information about physical topology detection, but will debug log how it traverses VLAN topologies.
Add the `/etc/nav/logging.conf` file if you haven't already, and make sure the following two lines are present:
[logging] nav.topology = DEBUG
I realy appreciate this project and I want to help the community.
Thank you :)
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?
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?
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
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.
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
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,
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
Morten,
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>) DEBUG:nav.topology.vlan:could not find reverse edge for (Netbox: y.x.250.244, <Netbox: y.x.162.81>, <Interface: Te1/14 at y.x.250.244>) . . .
What meaning these messages?
2013/7/16 Bruno Galindro da Costa bruno.galindro@gmail.com
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
-- Att. Bruno Galindro da Costa
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.
Orzakiewicz,
Please, open another thread (use other subject).
Thanks
:)
2013/7/19 Orzakiewicz Cedric cedric.orzakiewicz@barilla.com
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 J****
Cédric.****
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.
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
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 lldpprotocol (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.
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?
2013/7/29 Morten Brekkevold morten.brekkevold@uninett.no
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 lldpprotocol (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.
-- Morten Brekkevold UNINETT
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 switchforwarding 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 behaviourwas occured with that device which caused the error.
If this error occurs again, how can I debug it? Is there any snmp commandthat 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
-
Bruno Galindro da Costa -
Morten Brekkevold -
Orzakiewicz Cedric