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).