Nav-dev

nav-dev@lister.sikt.no

96 discussions

VoIP management on Juniper devices
by FOUR Ludovic (EXT) 13 Apr '23

13 Apr '23

Hello, Maybe i'm doing wrong. I want to manage different voIP vlans I've added voIP vlans in NAV Portadmin.conf (separated with comma) voice_vlans = <My first voIP ID>,<my other voIP vlan ID> When I activate VOIP to the interfaces directly in JunOS console (1) , It will create two separate configurations on the device: - Interface configuration with port-mode ACCESS and vlan XXXX (not the VOIP vlan) - a VOIP configuration with all "voIP" interfaces (command: show ethernet-switching-options voip ) However, NAV see this interface has a trunk port, with a native vlan YYYY and a trunk vlan corresponding to voIP vlan. When I want to change of vlan trunk configuration in Portadmin page, I have the following error: "Error editing trunk: Device raised RpcError: error: VOIP can only be configured on access ports error: configuration check-out failed" because Juniper doesn't allow VoIP setup on trunk ports. If I remove the voIP configuration on Juniper device, and keep NAV using trunks with a native vlan, the voIP phones are not working. Question is : How can we manage multiple VoIP vlans for Juniper with NAV ? It is possible to activate voIP on interface, by adding some button in portadmin page (for example) ? Regards, Ludovic Four IT Staff / Network manager Faculty of pharmacy University of Strasbourg - FRANCE (1) Depending on JunoS Version the command is - set ethernet-switching-options voip interface <interface number> vlan <voIP vlan ID> - set switch-options voip interface <interface number> vlan <voIP vlan ID>

2 1

add VoIP support with netplan ?
by FOUR Ludovic (EXT) 10 Nov '22

10 Nov '22

Hello, I hope everyone is doing well I'm trying to setup voice vlans for Juniper on nav conf. For some reasons, I don't want to activate VoIP on all ports, but just activate it for specific ports through portadmin page. I've declared voice_vlans in /etc/nav/portadmin/portadmin.conf but it seems it is only working with Cisco devices. Is there a way to make it work for Juniper or within netplan ? (maybe on future releases ?) Or using hooks and try external commands for interfaces ? Can we add specific netconf commands or it's internal builtin ? Regards, Ludovic FOUR Faculté de Pharmacie - Support Informatique Université de Strasbourg / CNRS France

3 3

Distribution test, please ignore
by Morten Brekkevold 14 Sep '22

14 Sep '22

This is just a test that distribution through the new mailing list address works as expected. Please excuse the noise :) -- Sincerely, Morten Brekkevold Sikt – Norwegian Agency for Shared Services in Education and Research

1 0

Re: How to add sensorgateway probes to nav ?
by Morten Brekkevold 21 Des '21

21 Des '21

On Fri, 17 Dec 2021 13:08:58 +0100 (CET) "FOUR Ludovic (EXT)" <ludovic.four(a)unistra.fr> wrote: > Hi Morten, > > Thanks for the reply. I know how to use SNMP OID's but I must admit > i'm not really comfortable yet with MIB schemas. I've learned > something with OBJECT IDENTIFIER and ::= { enterprises } in the MIB > file today ! Thanks a lot ! :) No problem :) > I can check SNMP connectivity in seedDB IP devices but there's still > nothing in collected info Type Found no new type in SeedDB (unknown > empty) > > If I remove one of the devices from Seed Database, and add it again > but nothing happens. Still no sensor graph The ipdevpoll `inventory` job needs to run successfully for the device to be identified first (and, unfortunately, the sensor may not be added on the first inventory run. The first run sets the device type, so that the sensors plugin has that value available only on the second run - and by default, successful runs are on 6 hour intervals). You should see all succesful/failing jobs in the job status box in the ipdevinfo page of your sensor device (just search for it in the navbar). If the jobs aren't running at all, are you sure ipdevpoll is running? You can also run these jobs manually from the command line: ipdevpolld -J inventory -n <name-of-sensor-device> Run it twice, and see if the sensor appears in ipdevinfo. Once it does, the 1minstats plugin should collect data from the registered sensors every 60 seconds. > Another point with serverscheck sensor : if I use snmpwalk to > interrogate my sensor temperature, i get this : > iso.3.6.1.4.1.17095.3.2.0 = STRING: "22.07" > > It appears that the sensor value format is STRING, not as integer. Is > that a problem ? I think it should be fine; as long as you do not provide a precision value in the sensor record, the string would be sent raw to Graphite. SNMP doesn't really have a data type for floating point numbers, so there are usually only two ways to go about this: Use strings, or provide a scaled value. -- sincerely, Morten Brekkevold Uninett Uninett is merging with Unit and NSD to form the new Norwegian Agency for Shared Services in Education and Research, and will stop trading under its own name per 1 January 2022.

1 0

Re: How to add sensorgateway probes to nav ?
by Morten Brekkevold 17 Des '21

17 Des '21

On Tue, 14 Dec 2021 15:16:16 +0100 (CET) "FOUR Ludovic (EXT)" <ludovic.four(a)unistra.fr> wrote: > I'm trying to add the probes by following the adding AKCP probe > tutorial. Cool! Glad to see it's of use to someone :) > snmpwalk -c community -v1|2c <IP of the probe> > ServersCheck:sensor1Name.0 > > If I translate into OID with snmptranslate command, I get this OID > .1.3.6.1.4.1.17095.3.2.0 > - Add the following lines to /etc/nav/ipdevpoll.conf (note sure of > iana code of serverscheck manufacturer. should be 25432) > > 25432 = ServersCheckMib > SERVERSCHECK = SERVERSCHECK-MIB Actually, from the MIB it appears the vendor/enterprise id for your device is 17095, not 25342. 17095 is registered to Microchip Technology Inc. > At this point i'm stuck (ipdevpoll log empty) and I still can't get > sensors readings into NAV and it doesn't recognize the probe type into > collected info of the seedDB probe page First of all, are you able to verify SNMP connectivity with the device through the SeedDB IP device form? The sysObjectID of your probe device is most likely unknown to NAV, so regardless of your new implementation, ipdevpoll should auto-create a type entry for the probe the first time the inventory job runs. This type record will just have the sysObjectID as its name, and the type description will be fetched from the sysDescr object. This type record should be edited in SeedDB once it appears, so you can give it a more human-friendly name and description. > Any ideas of what I'm doing wrong ? I assume the hard-coded sensor return value in your get_all_sensors() implementation is just for testing purposes - it should at least cause ipdevpoll to try to fetch this value for all devices with an enterprise id of 25432. Most likely, your problem is that you've used the wrong enterprise id in the ipdevpoll config. -- sincerely, Morten Brekkevold Uninett Uninett is merging with Unit and NSD to form the new Norwegian Agency for Shared Services in Education and Research, and will stop trading under its own name per 1 January 2022.

1 0

Re: How to add sensorgateway probes to nav ?
by Morten Brekkevold 17 Des '21

17 Des '21

On Tue, 14 Dec 2021 15:16:16 +0100 (CET) "FOUR Ludovic (EXT)" <ludovic.four(a)unistra.fr> wrote: > Hello, > > I'm using NAV 5.2 and I would like to add a couple of Serverscheck temperature probes that monitor our network racks > Product reference is detailed here : https://serverscheck.com/sensors/baseunit.asp > > I'm trying to add the probes by following the adding AKCP probe tutorial. I made this : First off, I suggest moving this entire discussion to the nav-dev mailing list (if you're not already subscribed). I've Cc-ed it, and will post a full reply there. > 1/ Translate the sensorgateway.mib into SERVERSCHECK-MIB.py with smidump command > 2/ Copy the python file to folder /opt/venvs/nav/lib/python3.7/site-packages/nav/smidumps > > There's a ServersCheck module used in MIB file, that i'm using to interrogate directly the probe > I can get the temperature value with snmpwalk -c community -v1|2c <IP of the probe> ServersCheck:sensor1Name.0 > > If I translate into OID with snmptranslate command, I get this OID > .1.3.6.1.4.1.17095.3.2.0 > > > 3/ Create the file serverscheck_mib.py with those lines to /opt/venvs/nav/lib/python3.7/site-packages/nav/mibs > > from twisted.internet import defer > from nav.mibs import reduce_index > from nav.mibs.mibretriever import MibRetriever > from nav.smidumps import get_mib > > class ServerCheckMib(MibRetriever): > mib = get_mib('SERVERSCHECK-MIB') > @defer.inlineCallbacks > def get_all_sensors(self): > result = [ > { > 'oid': '.1.3.6.1.4.1.17095.3.2.0', > 'unit_of_measurement': 'celsius', > 'precision': 1, > 'scale': None, > 'description': "Ambient temperature", > 'name': "Ambient temperature", > 'internal_name': "Ambient temperature", > 'mib': 'SERVERSCHECK-MIB', > } > ] > defer.returnValue(result) > > > - Add the following lines to /etc/nav/ipdevpoll.conf (note sure of > iana code of serverscheck manufacturer. should be 25432) > > 25432 = ServersCheckMib > SERVERSCHECK = SERVERSCHECK-MIB > > At this point i'm stuck (ipdevpoll log empty) and I still can't get > sensors readings into NAV and it doesn't recognize the probe type into > collected info of the seedDB probe page > > Any ideas of what I'm doing wrong ? -- sincerely, Morten Brekkevold Uninett Uninett is merging with Unit and NSD to form the new Norwegian Agency for Shared Services in Education and Research, and will stop trading under its own name per 1 January 2022.

1 0

Re: Adding a new device to NAV
by Morten Brekkevold 29 Jan '21

29 Jan '21

On Tue, 17 Nov 2020 15:11:04 +0100 Simon Brown <simon.brown(a)eiscat.se> wrote: > I'm testing with two device types, an ordinary WLAN access point and a switch. > > https://www.zyxel.com/products_services/802-11ac-Dual-Radio-Dual-optimized-… NAV does not have any specific support for WLAN access points, so there is no pre-existing framework to model that type of information in today's data model. Normally, an AP will expose information about its ethernet ports using the standardised IF-MIB, which includes traffic counters and status of these ports. These might be its uplink port(s) and its "virtual" WLAN ports. > https://sevensols.es/index.php/index/timing-products/white-rabbit-switch/ > > Regarding basic information, I'm not really sure what to expect as I'm not > that good yet at parsing MIB files. I don't know what is generic standard info > and what is device specific. As a first step for the switch I see nothing in > the Ports tab "No ports found" I was hoping for someway to setup VLANs. > > The MIB file for the switch is here: > https://ohwr.org/project/wr-switch-sw/blob/ > 4df35933f51680e7497cb2b5b183905b374ed28e/userspace/snmpd/WR-SWITCH-MIB.txt > > And it looks like individual port status is exposed, version information, > temperatures and a host of other things. I don't know yet how much of this > will be useful so I would like to make as much of it available as possible. > What is basic from your point of view? To be blunt: I am asking "What do _you_ expect NAV to tell you about these devices that it isn't already telling you?" If you have a network device, it will have the concept of network interfaces, whether they be physical or virtual. I expect to at least be able to see these interfaces listed in NAV - and there is only one definitive MIB to provide this information: IF-MIB (RFC 2863). If you have an SNMP-enabled networking device and it does not support this MIB, it is useless for most network monitoring tools (maybe the vendor sells their own NMS and want to make money off of that?). Personally, I have never come across such a device before. The MIB you pointed to seems to provide some proprietary information about ports, with an information model that seems to differ considerably from IF-MIB. I'm sure you can author support for this proprietary MIB and make some things work, but NAV's model for interfaces follows IF-MIB pretty closely, and I'm not sure how the concepts of WR-SWITCH-MIB will map into those. These are the necessary steps I foresee: 1. Dump WR-SWITCH-MIB to a Python dictionary representation. 2. Write a MibRetriever to implement the abstractions necessary to fetch and make sense of the data in the MIB. As an example, here is the corresponding MibRetriever for the IF-MIB: [1]. These two steps more or less overlap with start of the howto for writing support for sensor equipment [2]. 3. Write something that corresponds to the ipdevpoll interfaces plugin [3], which will use the abstractions provided by your MibRetriever implementation to fetch data from the device and map that data into NAV's interface model. Worst-case scenario: You may want to store attributes that aren't part of NAV's standard interface model. Then you will need to propose changes to the generic model used by everyone, and that will take much longer to design and approve. NB: I suggest moving this entire discussion to the nav-dev mailing list, rather than bother everyone on the users list with the low-level details. Cc: to nav-dev(a)uninett.no. [1] https://github.com/Uninett/nav/blob/master/python/nav/mibs/if_mib.py [2] https://nav.uninett.no/doc/5.0/hacking/adding-environment-probe-support.html [3] https://github.com/Uninett/nav/blob/master/python/nav/ipdevpoll/plugins/int… -- Best regards, Morten Brekkevold Senior systems developer Uninett

2 1

copy all data and settings to new NAV install
by kempere＠quakerchem.com 09 Sep '19

09 Sep '19

Hello, Is there a good way to move all settings and data to a fresh NAV installation? Regards Erik

2 1

Juniper, SNMP and Netconf
by Jean Benoit 21 Aug '19

21 Aug '19

Hello, I tried to set a VLAN to a port on Juniper EX using NAV PortAdmin. It didn't work. I think going for a unique standard (SNMP) to interact with the equipements was a sound design decision. The problem is some vendors have different ways of doing things. I tried SNMP setting the VLAN on a port on Juniper EX (EX2200C as a test platform, running JunOS 12.3R6.6) It looks like there is no way to do it with SNMP, neither using the Q-BRIDGE-MIB, nor using the Juniper enterprise MIB : export MIBS=JUNIPER-SMI:JUNIPER-EX-SMI:JUNIPER-VLAN-MIB:Q-BRIDGE-MIB export MIBDIRS=+/var/lib/snmp/mibs/juniper:+/var/lib/snmp/mibs/ietf snmpset -v2c -c private ex2200.example.com jnxExVlanPortStatus.1.524 i 3 Error in packet. Reason: notWritable (That object does not support modification) Failed object: JUNIPER-VLAN-MIB::jnxExVlanPortStatus.1.524 snmpset -v2c -c private ex2200.example.com dot1qPvid.524 Unsigned32 4 Error in packet. Reason: notWritable (That object does not support modification) Failed object: Q-BRIDGE-MIB::dot1qPvid.524 snmpset -v2c -c private ex2200.example.com dot1qVlanStaticEgressPorts.3 s "00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0C 10 " Error in packet. Reason: notWritable (That object does not support modification) Failed object: Q-BRIDGE-MIB::dot1qVlanStaticEgressPorts.3 Looking into Juniper documentation, where some writable SNMP mib variables are mentionned, it seems that SNMP is not intended to be the main tool to modify things. Juniper provides ssh and Netconf ; there is a library in python (Junos PyEZ). You can even choose to interact with the switch using XML, JSON or text. My feeling is most of those automations won't be available through SNMP. My first idea was to add a login/password/ssh-key in the database, then call a specific function based on this lib. In a previous email on nav-users, Morten said : >Regardless of whether NAV had more support for Juniper (which we plan to >add, since we are increasingly becoming a Juniper shop ourselves) [...] What is the strategy to bring more support for Juniper from a code perspective ? I discovered there is a Netconf branch in the git repo. I couldn't find any information about it. How stable/mature is the Netconf branch ? Do you have any plan to integrate and release it ? Thanks for your answers ! -- Jean

2 1

enable CDP on voice ports
by Philipp Petermann 24 Jul '19

24 Jul '19

Hi everybody, I'm Philipp working in the network team of the University of Basel, Switzerland. We use NAV since many years to provide self-service port administration for our colleagues and power users throughout our campus. NAV became a key service that everyone highly appreciates. Many thanks for your great effort at this point! Yesterday I submitted a feature request at github.com, unfortunately _after_ reading "hacking.rst" https://github.com/Uninett/nav/issues/1971 It's about providing an option (because I'm not sure everybody with cisco_voice_vlan = true want's this) in PortAdmin to automatically enable CDP if you check the "Tel" checkbox. We already have a patch for that, however, without the possibility to opt in or out which needs some additional config file parsing. But before I submit anything, what do think about the idea of automatically enable CDP on voice ports? Cheers, Philipp

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Nav-dev