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.