Hi! I have a problem with VLAN auto discover. I have followed the guidelines with adding the router (firewall), but it won't get the VLAN info from it. The firewall is a software firewall (Sophos UTM) that's running in a Hyper-V cluster for HA . Could it be the software switch in the Hyper-V that's giving some problem or the firewall software?
Before I also had some HP 2530 swithes added as an GWS. Then I got some VLAN info added to NAV, but NAV deletes the VLAN info in the SeedDB after a while and create it again with a new ID. So now I have changed the HP 2530 switches back to SW and hope the VLAN info will stay in SeedDB! But it would be great if I can get VLAN info to show up in Netmap. Is there some way to fix this if I can't get the info from the firewall?
There is also a problem if you change a GWS to a SW, then ipdevpoll try to still collect ip2mac from the device but won't get the info and you end up with WatchDog reporting problems with ip2mac for that switch, The solution I have used is to go into the database and delete all post related to ip2mac for that device from ipdevpoll_log_job table. Is it a bug or am I doing something wrong here?
Best regards Mattias
On Thu, 5 Mar 2015 08:32:35 +0200 Mattias Söderholm mattias.soderholm@malax.fi wrote:
Hi!
Hi Mattias!
I have a problem with VLAN auto discover. I have followed the guidelines with adding the router (firewall), but it won't get the VLAN info from it.
What _do_ you get from this firewall router? Does NAV find its router ports?
Before I also had some HP 2530 swithes added as an GWS. Then I got some VLAN info added to NAV, but NAV deletes the VLAN info in the SeedDB after a while and create it again with a new ID. So now I have changed the HP 2530 switches back to SW and hope the VLAN info will stay in SeedDB! But it would be great if I can get VLAN info to show up in Netmap. Is there some way to fix this if I can't get the info from the firewall?
Unless your switches are performing routing duties, you shouldn't add them as GSW's. NAV may pick up their management interfaces as "router ports", but they will not be considered authoritative for prefix information, which might be why they are being deleted.
NAV doesn't have very good support for unrouted VLANs; it will typically look for a router port prefix, try to find a VLAN tag for that prefix, and connect the two. If it cannot find the VLAN tag information from the router on which it found a routed prefix, it may create a tagless VLAN entry connected to that prefix (I cannot immediately remember all the ways in which NAV will try to discover the association between a prefix and a VLAN).
There is also a problem if you change a GWS to a SW, then ipdevpoll try to still collect ip2mac from the device but won't get the info and you end up with WatchDog reporting problems with ip2mac for that switch, The solution I have used is to go into the database and delete all post related to ip2mac for that device from ipdevpoll_log_job table. Is it a bug or am I doing something wrong here?
We know about this, and we should really consider it a bug. The WatchDog component and other parts of NAV will only look at the log of job runs in the `ipdevpoll_log_job` table to determine which jobs are overdue, but they won't know that a job isn't supposed to run for a device any longer, only ipdevpoll knows that.
Even if you change a device from GSW to SW, every 30 minutes ipdevpoll will try to verify whether it should run the ip2mac job for that device, and decide not to. I think it probably should log the status of this verification as well (i.e. jobs now have a "success" boolean status, they should maybe have a "success/failure/norun" indicator instead).
Hallo, Morten.
Thank you for the answare.
NAV is listing the router ports from the firewall but don't get any other info from them. It list the MAC, Link (Active), IP and the Prefix for each port when I check the Port details.
I also notice now that there is some switches that's reporting router port on the VLAN that the management IP is activated. All switches are set to SW now, but do I have to delete router ports for those switches? (If it's possible!)
Would be nice if you can fix the "bug" in some upcoming versions.
Best regards Mattias
----- Ursprungligt meddelande ----- Från: "Morten Brekkevold" morten.brekkevold@uninett.no Till: "Mattias Söderholm" mattias.soderholm@malax.fi Kopia: nav-users@uninett.no Skickat: måndag, 9 mar 2015 11:00:50 Ämne: Re: NAV and VLAN with Virtualized firewall
On Thu, 5 Mar 2015 08:32:35 +0200 Mattias Söderholm mattias.soderholm@malax.fi wrote:
Hi!
Hi Mattias!
I have a problem with VLAN auto discover. I have followed the guidelines with adding the router (firewall), but it won't get the VLAN info from it.
What _do_ you get from this firewall router? Does NAV find its router ports?
Before I also had some HP 2530 swithes added as an GWS. Then I got some VLAN info added to NAV, but NAV deletes the VLAN info in the SeedDB after a while and create it again with a new ID. So now I have changed the HP 2530 switches back to SW and hope the VLAN info will stay in SeedDB! But it would be great if I can get VLAN info to show up in Netmap. Is there some way to fix this if I can't get the info from the firewall?
Unless your switches are performing routing duties, you shouldn't add them as GSW's. NAV may pick up their management interfaces as "router ports", but they will not be considered authoritative for prefix information, which might be why they are being deleted.
NAV doesn't have very good support for unrouted VLANs; it will typically look for a router port prefix, try to find a VLAN tag for that prefix, and connect the two. If it cannot find the VLAN tag information from the router on which it found a routed prefix, it may create a tagless VLAN entry connected to that prefix (I cannot immediately remember all the ways in which NAV will try to discover the association between a prefix and a VLAN).
There is also a problem if you change a GWS to a SW, then ipdevpoll try to still collect ip2mac from the device but won't get the info and you end up with WatchDog reporting problems with ip2mac for that switch, The solution I have used is to go into the database and delete all post related to ip2mac for that device from ipdevpoll_log_job table. Is it a bug or am I doing something wrong here?
We know about this, and we should really consider it a bug. The WatchDog component and other parts of NAV will only look at the log of job runs in the `ipdevpoll_log_job` table to determine which jobs are overdue, but they won't know that a job isn't supposed to run for a device any longer, only ipdevpoll knows that.
Even if you change a device from GSW to SW, every 30 minutes ipdevpoll will try to verify whether it should run the ip2mac job for that device, and decide not to. I think it probably should log the status of this verification as well (i.e. jobs now have a "success" boolean status, they should maybe have a "success/failure/norun" indicator instead).
On Mon, 9 Mar 2015 11:23:51 +0200 Mattias Söderholm mattias.soderholm@malax.fi wrote:
NAV is listing the router ports from the firewall but don't get any other info from them. It list the MAC, Link (Active), IP and the Prefix for each port when I check the Port details.
And if you click the collected prefixes, is any VLAN information attached to these?
I also notice now that there is some switches that's reporting router port on the VLAN that the management IP is activated. All switches are set to SW now, but do I have to delete router ports for those switches? (If it's possible!)
No. Managed switches _will_ have a "router port", i.e. a port that has an IP address and a prefix. Because the device is just SW, the port is not considered a router port for that prefix, for the purposes of topology (although it may be referred to as a gwport in some parts of the user interface).
Would be nice if you can fix the "bug" in some upcoming versions.
Well, I've filed it here for now, so we at least have a reference for it:
https://bugs.launchpad.net/nav/+bug/1429868
Two prefixes have VLAN tag showing but the rest is missing it. But all now have one gateway (gwcount), so that's good. And all is of network type LAN.
The two VLAN that it finds is having at least one "better" switch with IPs on both VLANS. We have switches on other VLANs to, but those are cheap ones. So maybe NAV can't get the VLAN info for those management interfaces.
I shall try to add the missing info from SeedDB and see if it's being deleted or not now.
/Mattias
----- Ursprungligt meddelande ----- Från: "Morten Brekkevold" morten.brekkevold@uninett.no Till: "Mattias Söderholm" mattias.soderholm@malax.fi Kopia: nav-users@uninett.no Skickat: måndag, 9 mar 2015 15:55:41 Ämne: Re: NAV and VLAN with Virtualized firewall
On Mon, 9 Mar 2015 11:23:51 +0200 Mattias Söderholm mattias.soderholm@malax.fi wrote:
NAV is listing the router ports from the firewall but don't get any other info from them. It list the MAC, Link (Active), IP and the Prefix for each port when I check the Port details.
And if you click the collected prefixes, is any VLAN information attached to these?
I also notice now that there is some switches that's reporting router port on the VLAN that the management IP is activated. All switches are set to SW now, but do I have to delete router ports for those switches? (If it's possible!)
No. Managed switches _will_ have a "router port", i.e. a port that has an IP address and a prefix. Because the device is just SW, the port is not considered a router port for that prefix, for the purposes of topology (although it may be referred to as a gwport in some parts of the user interface).
Would be nice if you can fix the "bug" in some upcoming versions.
Well, I've filed it here for now, so we at least have a reference for it:
https://bugs.launchpad.net/nav/+bug/1429868
On Tue, 10 Mar 2015 07:41:50 +0200 Mattias Söderholm mattias.soderholm@malax.fi wrote:
Two prefixes have VLAN tag showing but the rest is missing it. But all now have one gateway (gwcount), so that's good. And all is of network type LAN.
The two VLAN that it finds is having at least one "better" switch with IPs on both VLANS. We have switches on other VLANs to, but those are cheap ones. So maybe NAV can't get the VLAN info for those management interfaces.
I skimmed some of the code again now, and NAV's way of associating prefixes and VLANs seems a tad simple-minded.
For any non-Cisco router, it will only work if it is a routing switch (GSW) that uses virtual router ports with interface names of the pattern Vl## or Vlan### (which at least holds true for Cisco routing switches). For plain L3 Cisco routers (GW), there is a proprietary MIB that gets us the VLAN tags.
Which model router routes these un-identified prefixes of yours, and is there any obvious way to get VLAN tag numbers from it?
I shall try to add the missing info from SeedDB and see if it's being deleted or not now.
What, exactly, are you adding?
Okey. So if I understand you correctly we need to change our router (firewall) to be a GSW and not a GW when it's not a Cisco router? And then it needs to show all router port as Vl## or Vlan###.
Our firewall is a Sophos UTM9 and is the only router on all prefixes. It now shows the router port as eth0, eth1 and so on in NAV. It's not possible to change the interface names in UTM. I now have entered in the UTM's interface description field the guidelines that's described here: https://nav.uninett.no/wiki/subnetsandvlans#guide_lines_for_configuring_rout... Don't know how to get the information from it. (I have no knowledge about MIBs and SNMP) The VLAN information that's inserted now in NAV must come from some switches (Management interface). They have the VLAN tag as router port.
The missing information I was trying to enter is the VLAN, Organization and Usage in SeedDB that you can manually insert for VLAN. But it's getting deleted...
/Mattias
----- Ursprungligt meddelande ----- Från: "Morten Brekkevold" morten.brekkevold@uninett.no Till: "Mattias Söderholm" mattias.soderholm@malax.fi Kopia: nav-users@uninett.no Skickat: torsdag, 12 mar 2015 10:48:39 Ämne: Re: NAV and VLAN with Virtualized firewall
On Tue, 10 Mar 2015 07:41:50 +0200 Mattias Söderholm mattias.soderholm@malax.fi wrote:
Two prefixes have VLAN tag showing but the rest is missing it. But all now have one gateway (gwcount), so that's good. And all is of network type LAN.
The two VLAN that it finds is having at least one "better" switch with IPs on both VLANS. We have switches on other VLANs to, but those are cheap ones. So maybe NAV can't get the VLAN info for those management interfaces.
I skimmed some of the code again now, and NAV's way of associating prefixes and VLANs seems a tad simple-minded.
For any non-Cisco router, it will only work if it is a routing switch (GSW) that uses virtual router ports with interface names of the pattern Vl## or Vlan### (which at least holds true for Cisco routing switches). For plain L3 Cisco routers (GW), there is a proprietary MIB that gets us the VLAN tags.
Which model router routes these un-identified prefixes of yours, and is there any obvious way to get VLAN tag numbers from it?
I shall try to add the missing info from SeedDB and see if it's being deleted or not now.
What, exactly, are you adding?
On Thu, 12 Mar 2015 12:17:20 +0200 Mattias Söderholm mattias.soderholm@malax.fi wrote:
Okey. So if I understand you correctly we need to change our router (firewall) to be a GSW and not a GW when it's not a Cisco router? And then it needs to show all router port as Vl## or Vlan###.
No. The GW category is for a pure layer 3 router. GSW is for a routing switch, operating on both layer 3 and 2. I only meant to comment on what it seems NAV actually supports.
The point is, NAV only knows how to associate VLAN tags with prefixes on a router if:
1. It's a Cisco router which supports 802.1q VLAN tagging.
or
2. It's a routing switch that signal the corresponding Vlan tag by including it in its router port names (matching the regexp "Vl(an)?[0-9]+").
Our firewall is a Sophos UTM9 and is the only router on all prefixes. It now shows the router port as eth0, eth1 and so on in NAV. It's not possible to change the interface names in UTM.
Fully understandable. The question is, does the Sophos UTM9 support 802.1q VLAN tagging?
If it doesn't, we cannot conceivably get that information from it, ever. We would have to find that information elsewhere. For example, if we find that the physical router port is directly connected to another switch, where we could read the VLAN tag from the connected switch port. NAV doesnt currently do that, but I see it as a possible enhancement.
I now have entered in the UTM's interface description field the guidelines that's described here: https://nav.uninett.no/wiki/subnetsandvlans#guide_lines_for_configuring_rout...
Beautiful! I'd completely forgotten that you can force the VLAN number of a prefix through the interface description conventions :-)
I just reviewed the related code, and unfortunately, there seems to be a glaring omission here. The VLAN tag number is parsed, but seems to never be used anywhere :-(
I smell a bug report coming... Would you like to file it yourself at https://bugs.launchpad.net/nav/+filebug ?
Don't know how to get the information from it. (I have no knowledge about MIBs and SNMP) The VLAN information that's inserted now in NAV must come from some switches (Management interface). They have the VLAN tag as router port.
The missing information I was trying to enter is the VLAN, Organization and Usage in SeedDB that you can manually insert for VLAN. But it's getting deleted...
Is the entire VLAN entry being deleted, or is it just the data fields (organization, usage, net_ident, description)?
If NAV finds a VLAN entry that doesn't seem to be in use anywhere (i.e. associated with a prefix or detected as active on a switch port), it will squarely delete it - but it shouldn't change the attached data fields, as they are always parsed from router port descriptions.
Hi. The Sophos UTM9 supports VLAN tagging, but we are not using it. We need to create new VLAN interfaces and reconfigure the whole UTM9 to get that active. Right now we only use separate network interfaces for different LAN segments.
About the bug reporting for the VLAN number of a prefix through the interface description conventions you can create one. See that I need to have some Ubuntu account for the bug reporting...
Today the whole VLAN entry being deleted and then recreated with a new ID.
Best regards Mattias
----- Ursprungligt meddelande ----- Från: "Morten Brekkevold" morten.brekkevold@uninett.no Till: "Mattias Söderholm" mattias.soderholm@malax.fi Kopia: nav-users@uninett.no Skickat: fredag, 13 mar 2015 11:40:34 Ämne: Re: NAV and VLAN with Virtualized firewall
On Thu, 12 Mar 2015 12:17:20 +0200 Mattias Söderholm mattias.soderholm@malax.fi wrote:
Okey. So if I understand you correctly we need to change our router (firewall) to be a GSW and not a GW when it's not a Cisco router? And then it needs to show all router port as Vl## or Vlan###.
No. The GW category is for a pure layer 3 router. GSW is for a routing switch, operating on both layer 3 and 2. I only meant to comment on what it seems NAV actually supports.
The point is, NAV only knows how to associate VLAN tags with prefixes on a router if:
1. It's a Cisco router which supports 802.1q VLAN tagging.
or
2. It's a routing switch that signal the corresponding Vlan tag by including it in its router port names (matching the regexp "Vl(an)?[0-9]+").
Our firewall is a Sophos UTM9 and is the only router on all prefixes. It now shows the router port as eth0, eth1 and so on in NAV. It's not possible to change the interface names in UTM.
Fully understandable. The question is, does the Sophos UTM9 support 802.1q VLAN tagging?
If it doesn't, we cannot conceivably get that information from it, ever. We would have to find that information elsewhere. For example, if we find that the physical router port is directly connected to another switch, where we could read the VLAN tag from the connected switch port. NAV doesnt currently do that, but I see it as a possible enhancement.
I now have entered in the UTM's interface description field the guidelines that's described here: https://nav.uninett.no/wiki/subnetsandvlans#guide_lines_for_configuring_rout...
Beautiful! I'd completely forgotten that you can force the VLAN number of a prefix through the interface description conventions :-)
I just reviewed the related code, and unfortunately, there seems to be a glaring omission here. The VLAN tag number is parsed, but seems to never be used anywhere :-(
I smell a bug report coming... Would you like to file it yourself at https://bugs.launchpad.net/nav/+filebug ?
Don't know how to get the information from it. (I have no knowledge about MIBs and SNMP) The VLAN information that's inserted now in NAV must come from some switches (Management interface). They have the VLAN tag as router port.
The missing information I was trying to enter is the VLAN, Organization and Usage in SeedDB that you can manually insert for VLAN. But it's getting deleted...
Is the entire VLAN entry being deleted, or is it just the data fields (organization, usage, net_ident, description)?
If NAV finds a VLAN entry that doesn't seem to be in use anywhere (i.e. associated with a prefix or detected as active on a switch port), it will squarely delete it - but it shouldn't change the attached data fields, as they are always parsed from router port descriptions.
On Tue, 24 Mar 2015 07:53:41 +0200 Mattias Söderholm mattias.soderholm@malax.fi wrote:
The Sophos UTM9 supports VLAN tagging, but we are not using it. We need to create new VLAN interfaces and reconfigure the whole UTM9 to get that active. Right now we only use separate network interfaces for different LAN segments.
Ok.
We are seeing a similar problem here, as well, though on routers that do support 802.1Q: We are deploying more and more Juniper routers, and we support no proprietary MIBs on this platform so far.
At leaast, these routers use a seemingly reliable pattern of interface naming that contains the VLAN tag, but it doesn't match the current VLAN pattern used by NAV (I think the Juniper's use "irb.<vlantag>"). We will likely be adding support for that pattern as well.
About the bug reporting for the VLAN number of a prefix through the interface description conventions you can create one. See that I need to have some Ubuntu account for the bug reporting...
Yes, I think Ubuntu merged Launchpad accounts with Ubuntu accounts at some point.
Anyway, I did post the bug here: https://bugs.launchpad.net/nav/+bug/1436388
Hoping to work on it tomorrow.
Today the whole VLAN entry being deleted and then recreated with a new ID.
I think it may be because NAV cannot trace a tagless VLAN entry on your L2 network, so it likely appears disused. Not entirely sure though - I would like to fix the above bug and have you test it before we dive into that.
On Wed, 25 Mar 2015 16:16:11 +0100 Morten Brekkevold morten.brekkevold@uninett.no wrote:
On Tue, 24 Mar 2015 07:53:41 +0200 Mattias Söderholm mattias.soderholm@malax.fi wrote:
About the bug reporting for the VLAN number of a prefix through the interface description conventions you can create one. See that I need to have some Ubuntu account for the bug reporting...
Anyway, I did post the bug here: https://bugs.launchpad.net/nav/+bug/1436388
I've committed a fix for this issue now. I'm not sure when the next release will be, since next week is easter vacation for most Norwegians, and I have a three day tutorial/training the week after that.
If you'd like, you can patch your installation directly using the patch at https://nav.uninett.no/hg/stable/rev/a97f53df2156.
Okey. Have inserted the code now on my NAV 4.2.5 server, so will see what happens.
Best regards Mattias
----- Ursprungligt meddelande ----- Från: "Morten Brekkevold" morten.brekkevold@uninett.no Till: "Mattias Söderholm" mattias.soderholm@malax.fi Kopia: nav-users@uninett.no Skickat: fredag, 27 mar 2015 15:34:24 Ämne: Re: NAV and VLAN with Virtualized firewall
On Wed, 25 Mar 2015 16:16:11 +0100 Morten Brekkevold morten.brekkevold@uninett.no wrote:
On Tue, 24 Mar 2015 07:53:41 +0200 Mattias Söderholm mattias.soderholm@malax.fi wrote:
About the bug reporting for the VLAN number of a prefix through the interface description conventions you can create one. See that I need to have some Ubuntu account for the bug reporting...
Anyway, I did post the bug here: https://bugs.launchpad.net/nav/+bug/1436388
I've committed a fix for this issue now. I'm not sure when the next release will be, since next week is easter vacation for most Norwegians, and I have a three day tutorial/training the week after that.
If you'd like, you can patch your installation directly using the patch at https://nav.uninett.no/hg/stable/rev/a97f53df2156.
Now I have VLAN listed with the right prefixes, but some prefixes are still missing the VLAN tag (but managed by the firewall). Also they are missing the other information like organisation and usage. And there is also LAN that have the same VLAN tags with no information (same VLAN tag as the one with the right prefixes above).
I also notices that there is a lot of VLAN with the network type LAN that have no information at all.
Here in Finland we also have easter vacation, so no hurry ;)
/Mattias
----- Ursprungligt meddelande ----- Från: "Morten Brekkevold" morten.brekkevold@uninett.no Till: "Mattias Söderholm" mattias.soderholm@malax.fi Kopia: nav-users@uninett.no Skickat: fredag, 27 mar 2015 15:34:24 Ämne: Re: NAV and VLAN with Virtualized firewall
On Wed, 25 Mar 2015 16:16:11 +0100 Morten Brekkevold morten.brekkevold@uninett.no wrote:
On Tue, 24 Mar 2015 07:53:41 +0200 Mattias Söderholm mattias.soderholm@malax.fi wrote:
About the bug reporting for the VLAN number of a prefix through the interface description conventions you can create one. See that I need to have some Ubuntu account for the bug reporting...
Anyway, I did post the bug here: https://bugs.launchpad.net/nav/+bug/1436388
I've committed a fix for this issue now. I'm not sure when the next release will be, since next week is easter vacation for most Norwegians, and I have a three day tutorial/training the week after that.
If you'd like, you can patch your installation directly using the patch at https://nav.uninett.no/hg/stable/rev/a97f53df2156.
Well, looks like NAV can't see that the firewall is connected trough a vSwitch to a physical switch. So then it can not build the network path with the VLANs. If I look in the Network Explorer, it only lists the firewall and it's interfaces and noting more.
It has now deleted all empty VLANs...
/Mattias
----- Ursprungligt meddelande ----- Från: "Mattias Söderholm" mattias.soderholm@malax.fi Till: "Morten Brekkevold" morten.brekkevold@uninett.no Kopia: nav-users@uninett.no Skickat: tisdag, 31 mar 2015 14:33:35 Ämne: Re: NAV and VLAN with Virtualized firewall
Now I have VLAN listed with the right prefixes, but some prefixes are still missing the VLAN tag (but managed by the firewall). Also they are missing the other information like organisation and usage. And there is also LAN that have the same VLAN tags with no information (same VLAN tag as the one with the right prefixes above).
I also notices that there is a lot of VLAN with the network type LAN that have no information at all.
Here in Finland we also have easter vacation, so no hurry ;)
/Mattias
----- Ursprungligt meddelande ----- Från: "Morten Brekkevold" morten.brekkevold@uninett.no Till: "Mattias Söderholm" mattias.soderholm@malax.fi Kopia: nav-users@uninett.no Skickat: fredag, 27 mar 2015 15:34:24 Ämne: Re: NAV and VLAN with Virtualized firewall
On Wed, 25 Mar 2015 16:16:11 +0100 Morten Brekkevold morten.brekkevold@uninett.no wrote:
On Tue, 24 Mar 2015 07:53:41 +0200 Mattias Söderholm mattias.soderholm@malax.fi wrote:
About the bug reporting for the VLAN number of a prefix through the interface description conventions you can create one. See that I need to have some Ubuntu account for the bug reporting...
Anyway, I did post the bug here: https://bugs.launchpad.net/nav/+bug/1436388
I've committed a fix for this issue now. I'm not sure when the next release will be, since next week is easter vacation for most Norwegians, and I have a three day tutorial/training the week after that.
If you'd like, you can patch your installation directly using the patch at https://nav.uninett.no/hg/stable/rev/a97f53df2156.
On Tue, 31 Mar 2015 15:42:08 +0300 Mattias Söderholm mattias.soderholm@malax.fi wrote:
Well, looks like NAV can't see that the firewall is connected trough a vSwitch to a physical switch. So then it can not build the network path with the VLANs.
Could you draw a diagram of your setup?
If I look in the Network Explorer, it only lists the firewall and it's interfaces and noting more.
When NAV cannot find any topology for the VLAN associated with a router port, there will be no topology to expand.
What kind of firewall are we talking about, again?
Here you have a diagram. I don't write everything we have, but you will see how it's connected.
Firewall is a Sophos UTM9 software router running in a hyper-v cluster.
/Mattias
----- Ursprungligt meddelande ----- Från: "Morten Brekkevold" morten.brekkevold@uninett.no Till: "Mattias Söderholm" mattias.soderholm@malax.fi Kopia: nav-users@uninett.no Skickat: torsdag, 9 apr 2015 14:23:30 Ämne: Re: NAV and VLAN with Virtualized firewall
On Tue, 31 Mar 2015 15:42:08 +0300 Mattias Söderholm mattias.soderholm@malax.fi wrote:
Well, looks like NAV can't see that the firewall is connected trough a vSwitch to a physical switch. So then it can not build the network path with the VLANs.
Could you draw a diagram of your setup?
If I look in the Network Explorer, it only lists the firewall and it's interfaces and noting more.
When NAV cannot find any topology for the VLAN associated with a router port, there will be no topology to expand.
What kind of firewall are we talking about, again?
On Thu, 9 Apr 2015 16:13:39 +0300 Mattias Söderholm mattias.soderholm@malax.fi wrote:
Here you have a diagram. I don't write everything we have, but you will see how it's connected.
Firewall is a Sophos UTM9 software router running in a hyper-v cluster.
Thanks for the diagram. Does the UTM9 support LLDP as well? Does NAV see the L2 neighbors of the UTM9 correctly, regardless of VLAN info?
Dosen't find anything about LLDP, so may be lacking that. Switch dosen't report any LLDP info on the port either.
NAV see witch port (Port trunk) the firewall is connected to in the switch. Tooltip box at the switch port status page in NAV also shows VLAN id and that it's connected to firewall (DNS name).
/Mattias
----- Ursprungligt meddelande ----- Från: "Morten Brekkevold" morten.brekkevold@uninett.no Till: "Mattias Söderholm" mattias.soderholm@malax.fi Kopia: nav-users@uninett.no Skickat: måndag, 13 apr 2015 12:19:32 Ämne: Re: NAV and VLAN with Virtualized firewall
On Thu, 9 Apr 2015 16:13:39 +0300 Mattias Söderholm mattias.soderholm@malax.fi wrote:
Here you have a diagram. I don't write everything we have, but you will see how it's connected.
Firewall is a Sophos UTM9 software router running in a hyper-v cluster.
Thanks for the diagram. Does the UTM9 support LLDP as well? Does NAV see the L2 neighbors of the UTM9 correctly, regardless of VLAN info?
On Tue, 31 Mar 2015 14:33:35 +0300 Mattias Söderholm mattias.soderholm@malax.fi wrote:
Now I have VLAN listed with the right prefixes, but some prefixes are still missing the VLAN tag (but managed by the firewall).
Also they are missing the other information like organisation and usage.
Check `ipdevpoll.log`. ipdevpoll will not create new organizational units or usage categories if the ones listed in interface description don't correctly match the ones already in the database.
And there is also LAN that have the same VLAN tags with no information (same VLAN tag as the one with the right prefixes above).
I'm not sure I understand what you are saying here. Do you mean to say that NAV has multiple VLAN entries with the same VLAN tag number? That would be normal in cases where a VLAN tag is reused across different broadcast domains. Question is whether NAV thinks one of your broadcast domains are two different broadcast domains...
I also notices that there is a lot of VLAN with the network type LAN that have no information at all.
NAV defaults to categorizing a routed VLAN as 'lan', and only changes this in the face of other information. And, of course, if NAV is unable to parse anything meaningful from a router port interface description, it will be short on details.
As now in SeedDB --> VLAN it looks like when we first started this tread. I have all the prefixes there but two of the prefixes has its VLAN number correctly and two prefixes missing its VLAN number (all other information fields are empty). So NAV can't use the information commented on the interface at the firewall, and I have the comments correctly entered for the organisation and usage! I notice when ipdevpoll runs the topo job for the firewall it add 5 rows in SeedDB --> VLAN with only LAN as net type and everything else empty (Not even a prefix). There is two interfaces on the firewall that do not have comments in it for NAV (some other text there). We have a total of 6 interfaces on the firewall right now.
I don't find any interesting in ipdevpoll.log file, do I need to set log level to Debug?
From navtopology.log this is shown for today: 2015-04-09 01:35:05,081 [INFO nav.topology.detector] deleting unused vlans: [<Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>] 2015-04-09 02:35:03,690 [INFO nav.topology.detector] deleting unused vlans: [<Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, '...(remaining elements truncated)...'] 2015-04-09 03:35:03,081 [INFO nav.topology.detector] deleting unused vlans: [<Vlan: N/A>] 2015-04-09 04:35:03,881 [INFO nav.topology.detector] deleting unused vlans: [<Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>] 2015-04-09 05:35:02,816 [INFO nav.topology.detector] deleting unused vlans: [<Vlan: N/A>] 2015-04-09 07:35:03,331 [INFO nav.topology.detector] deleting unused vlans: [<Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>] 2015-04-09 08:35:03,580 [INFO nav.topology.detector] deleting unused vlans: [<Vlan: N/A>, <Vlan: 605>, <Vlan: 602>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, '...(remaining elements truncated)...'] 2015-04-09 09:35:03,800 [INFO nav.topology.detector] deleting unused vlans: [<Vlan: N/A>] 2015-04-09 10:35:02,919 [INFO nav.topology.detector] deleting unused vlans: [<Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>] 2015-04-09 11:35:04,708 [INFO nav.topology.detector] deleting unused vlans: [<Vlan: N/A>] 2015-04-09 13:35:05,931 [INFO nav.topology.detector] deleting unused vlans: [<Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>] 2015-04-09 14:35:03,692 [INFO nav.topology.detector] deleting unused vlans: [<Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, '...(remaining elements truncated)...'] 2015-04-09 15:35:05,160 [INFO nav.topology.detector] deleting unused vlans: [<Vlan: N/A>]
/Mattias
----- Ursprungligt meddelande ----- Från: "Morten Brekkevold" morten.brekkevold@uninett.no Till: "Mattias Söderholm" mattias.soderholm@malax.fi Kopia: nav-users@uninett.no Skickat: torsdag, 9 apr 2015 14:06:23 Ämne: Re: NAV and VLAN with Virtualized firewall
On Tue, 31 Mar 2015 14:33:35 +0300 Mattias Söderholm mattias.soderholm@malax.fi wrote:
Now I have VLAN listed with the right prefixes, but some prefixes are still missing the VLAN tag (but managed by the firewall).
Also they are missing the other information like organisation and usage.
Check `ipdevpoll.log`. ipdevpoll will not create new organizational units or usage categories if the ones listed in interface description don't correctly match the ones already in the database.
And there is also LAN that have the same VLAN tags with no information (same VLAN tag as the one with the right prefixes above).
I'm not sure I understand what you are saying here. Do you mean to say that NAV has multiple VLAN entries with the same VLAN tag number? That would be normal in cases where a VLAN tag is reused across different broadcast domains. Question is whether NAV thinks one of your broadcast domains are two different broadcast domains...
I also notices that there is a lot of VLAN with the network type LAN that have no information at all.
NAV defaults to categorizing a routed VLAN as 'lan', and only changes this in the face of other information. And, of course, if NAV is unable to parse anything meaningful from a router port interface description, it will be short on details.
On Thu, 9 Apr 2015 16:10:52 +0300 Mattias Söderholm mattias.soderholm@malax.fi wrote:
As now in SeedDB --> VLAN it looks like when we first started this tread. I have all the prefixes there but two of the prefixes has its VLAN number correctly and two prefixes missing its VLAN number (all other information fields are empty).
I'll have to write this "out loud", to help me reason about it:
* Vlan entries in NAV are representaions of L2 broadcast domains (i.e. it doesn't matter whether 802.1q is involved at all, any broadcast domain NAV needs to register gets a VLAN record, and one is registered for every L3 prefix. It may not have any other details than the fact that it is some L2 broadcast domain).
* There are only two places NAV will create new Vlan records: 1. The ipdevpoll prefix plugin. 2. The ipdevpoll ciscovlan plugin.
I don't think (2) enters into it, unless you have Cisco equipment in your network (I cannot remember if you specified a vendor for your switches).
Whenever (1) finds a router port and registers a prefix for it, it will also attach a Vlan record to the prefix. A 802.1q tag is only registered for this Vlan by (1) if the interface the prefix was found on is named in a known pattern that contains the corresponding Vlan number.
Later, during the save-to-database stage, when a router port is about to be saved to the database, it's description is parsed to see if it matches with one of the two supported description conventions.
- If no convention matches are found, the corresponding VLAN record's netident will be set to the full value of the router port's description. Are you able to observe this, at least, for the prefixes whose VLAN tag information remains empty?
- If the description matches the NTNU convention, and this contains a VLAN tag number in the correct place, the router port's prefix->vlan->vlan tag is set according to this value (if using the not-yet-released patch from LP#1436388).
So NAV can't use the information commented on the interface at the firewall, and I have the comments correctly entered for the organisation and usage!
I notice when ipdevpoll runs the topo job for the firewall it add 5 rows in SeedDB --> VLAN with only LAN as net type and everything else empty (Not even a prefix).
The 'topo' job creates Vlan entries? That's not supposed to happen. How did you isolate the topo job as the origin here?
There is two interfaces on the firewall that do not have comments in it for NAV (some other text there). We have a total of 6 interfaces on the firewall right now.
I don't find any interesting in ipdevpoll.log file, do I need to set log level to Debug?
If you care to wade through the massive amounts of logs that will result from debug logging all of ipdevpoll, be my guest.
Often, debug logging of targeted parts of ipdevpoll is more helpful, but I wouldn't be sure which parts to suggest debug logging until you respond to my points above.
If you do want to enable full debug logging for all of ipdevpoll, you can add "nav.ipdevpoll = DEBUG" to your `/etc/nav/logging.conf`.
From navtopology.log this is shown for today: 2015-04-09 01:35:05,081 [INFO nav.topology.detector] deleting unused vlans: [<Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>] 2015-04-09 02:35:03,690 [INFO nav.topology.detector] deleting unused vlans: [<Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, <Vlan: N/A>, '...(remaining elements truncated)...']
Any VLAN that is not attached to a prefix, and has not been found active on any switch ports by navtopology, will be deleted here. It appears, in your case, that ipdevpoll is creating a bunch of junk vlans that cannot be validated by navtopology - I do hope we get to the bottom of why these "junk" VLANs appear.
As it is now, everything is looking and working exactly the same as when we first started this tread.
I don't find anything interested in ipdevpoll.log. Do I need to enable debug for ipdevpoll?
Something I noticed was that when topo job runs for firewall it adds four lan rows in SeedDB --> Vlan that are totally empty (these are removed later by navtopology). We have a total of six interfaces in the firewall but only four of them have the NAV VLAN comment in its description field (but none of the descriptions is shown in the NAV).
/Mattias
----- Ursprungligt meddelande ----- Från: "Morten Brekkevold" morten.brekkevold@uninett.no Till: "Mattias Söderholm" mattias.soderholm@malax.fi Kopia: nav-users@uninett.no Skickat: torsdag, 9 apr 2015 14:06:23 Ämne: Re: NAV and VLAN with Virtualized firewall
On Tue, 31 Mar 2015 14:33:35 +0300 Mattias Söderholm mattias.soderholm@malax.fi wrote:
Now I have VLAN listed with the right prefixes, but some prefixes are still missing the VLAN tag (but managed by the firewall).
Also they are missing the other information like organisation and usage.
Check `ipdevpoll.log`. ipdevpoll will not create new organizational units or usage categories if the ones listed in interface description don't correctly match the ones already in the database.
And there is also LAN that have the same VLAN tags with no information (same VLAN tag as the one with the right prefixes above).
I'm not sure I understand what you are saying here. Do you mean to say that NAV has multiple VLAN entries with the same VLAN tag number? That would be normal in cases where a VLAN tag is reused across different broadcast domains. Question is whether NAV thinks one of your broadcast domains are two different broadcast domains...
I also notices that there is a lot of VLAN with the network type LAN that have no information at all.
NAV defaults to categorizing a routed VLAN as 'lan', and only changes this in the face of other information. And, of course, if NAV is unable to parse anything meaningful from a router port interface description, it will be short on details.
-
Mattias Söderholm -
Morten Brekkevold