Send Netdot-devel mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://osl.uoregon.edu/mailman/listinfo/netdot-devel
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Netdot-devel digest..."
Today's Topics:
1. [Netdot - Bug #1913] Naming method 'sysname' ignores sysname
([email protected])
2. [Netdot - Bug #1914] (New) Auto-creation of zones is fairly
non-deterministic ([email protected])
----------------------------------------------------------------------
Message: 1
Date: Fri, 24 Mar 2017 06:39:47 -0700
From: [email protected]
Subject: [Netdot-devel] [Netdot - Bug #1913] Naming method 'sysname'
ignores sysname
To: [email protected], [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Issue #1913 has been updated by Brian Candler.
It matters because the topo graphs use "short_name", so all the devices are now
labelled "fa0-1" or "fa1-0"...
----------------------------------------
Bug #1913: Naming method 'sysname' ignores sysname
https://osl.uoregon.edu/redmine/issues/1913#change-3387
Author: Brian Candler
Status: New
Priority: Normal
Assignee:
Category:
Target version:
Resolution:
Here is a device with a valid sysName:
<pre>
# snmpwalk -v2c -c NetManage 100.68.100.235 sysName
SNMPv2-MIB::sysName.0 = STRING: transit1.nren.ws.nsrc.org
</pre>
This is what I want the device to be known as in Netdot.
The forward DNS matches its SNMP IP:
<pre>
# dig +short transit1.nren.ws.nsrc.org
100.68.100.235
</pre>
But the reverse DNS points to a more detailed name (including the interface).
<pre>
# dig +short -x 100.68.100.235
fa0-0.transit1.nren.ws.nsrc.org.
# dig +short fa0-0.transit1.nren.ws.nsrc.org
100.68.100.235
</pre>
Site.conf has:
<pre>
DEVICE_NAMING_METHOD_ORDER => [ 'sysname', 'snmp_target' ],
</pre>
Therefore I was expecting it to take the Netdot device name from the sysName.
But when I add the device, it uses the reverse DNS for the target address
instead.
<pre>
# /usr/local/netdot/bin/updatedevices.pl -H 100.68.100.235 -I -c xxxxxxxx
...
SNMP::Info::specify() - Changed Class to SNMP::Info::Layer3::Cisco.
DEBUG - SNMPv2 session with host 100.68.100.235 established
DEBUG - Device::get_snmp_info: SNMP target is 100.68.100.235
...
DEBUG - Device::get_snmp_info: Finished getting SNMP info from 100.68.100.235
DEBUG - Device::discover: Device 100.68.100.235 does not yet exist
DEBUG - Device::_get_main_ip: Trying method sysname
DEBUG - Device::_get_main_ip: Chose 100.68.100.235 using naming method: sysname
DEBUG - Device::assign_name: 100.68.100.235 resolves to
fa0-0.transit1.nren.ws.nsrc.org
INFO - Inserted new RR: fa0-0.transit1.nren.ws.nsrc.org
</pre>
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://osl.uoregon.edu/redmine/my/account
------------------------------
Message: 2
Date: Fri, 24 Mar 2017 07:20:09 -0700
From: [email protected]
Subject: [Netdot-devel] [Netdot - Bug #1914] (New) Auto-creation of
zones is fairly non-deterministic
To: [email protected], [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Issue #1914 has been reported by Brian Candler.
----------------------------------------
Bug #1914: Auto-creation of zones is fairly non-deterministic
https://osl.uoregon.edu/redmine/issues/1914
Author: Brian Candler
Status: New
Priority: Normal
Assignee:
Category:
Target version:
Resolution:
<pre>
--
-- Dumping data for table `rr`
--
LOCK TABLES `rr` WRITE;
/*!40000 ALTER TABLE `rr` DISABLE KEYS */;
INSERT INTO `rr` VALUES (0,1,'1970-01-02 00:00:01',NULL,1,NULL,'1970-01-02
00:00:01','@',1),
(1,0,'2017-03-24 13:29:32',NULL,2,NULL,'2017-03-24 13:29:32','@',2),
(1,0,'2017-03-24 13:29:32',NULL,3,NULL,'2017-03-24 13:29:32','fa0-0',2),
(1,0,'2017-03-24 13:31:40',NULL,4,NULL,'2017-03-24 13:31:40','@',3),
(1,0,'2017-03-24 13:31:40',NULL,5,NULL,'2017-03-24 13:31:40','fa0-1',3),
(1,0,'2017-03-24 13:32:04',NULL,6,NULL,'2017-03-24 13:32:04','@',4),
(1,0,'2017-03-24 13:32:04',NULL,7,NULL,'2017-03-24 13:32:04','fa1-0',4),
(1,0,'2017-03-24 13:32:41',NULL,8,NULL,'2017-03-24 13:32:41','@',5),
(1,0,'2017-03-24 13:32:41',NULL,9,NULL,'2017-03-24 13:32:41','netdot',5),
(1,0,'2017-03-24 13:33:34',NULL,10,NULL,'2017-03-24
13:33:34','fa0-1.bdr1.campus3',5),
(1,0,'2017-03-24 13:34:05',NULL,11,NULL,'2017-03-24
13:34:05','fa0-1.bdr1.campus5',5),
(1,0,'2017-03-24 13:34:22',NULL,12,NULL,'2017-03-24
13:34:22','fa0-0.transit2.nren',5);
/*!40000 ALTER TABLE `rr` ENABLE KEYS */;
UNLOCK TABLES;
</pre>
What happened as:
* Some individual devices were added, e.g. "fa0-0.transit1.nren.ws.nsrc.org"
automatically created "fa0-0" in zone "transit1.nren.ws.nsrc.org"
* Device "netdot.ws.nsrc.org" was added, creating "netdot" in zone "ws.nsrc.org"
* A later addition of "fa0-0.transit2.nren.ws.nsrc.org" (by means of neighbor
discovery) then created "fa0-0.transit2.nren" in zone "ws.nsrc.org"
I think I can see what's happening: once the "ws.nsrc.org" zone existed, Netdot
is preferring to use this existing zone (with a multi-label record) rather than
create a new zone. But to the user, it appears inconsistent, and leaves a mess
which is not easy to clean up.
A more consistent approach might be: *if* you have to auto-create a new zone,
then always create it with exactly two label parts (in this case "nsrc.org")
This isn't necessarily what you want, but at least the devices in auto-created
zones are always handled consistently, not depending on the history.
As today, you can make an explicit choice about the depth of the zones by
pre-creating the zones you want; for example if you want "nren.ws.nsrc.org" to
be a zone you create it, and then the device would be added as "fa0-0.transit2"
in that zone.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://osl.uoregon.edu/redmine/my/account
------------------------------
_______________________________________________
Netdot-devel mailing list
[email protected]
https://osl.uoregon.edu/mailman/listinfo/netdot-devel
End of Netdot-devel Digest, Vol 120, Issue 4
********************************************
