Uploaded image for project: 'Observium'
  1. Observium
  2. OBS-4431

Add script to populate ifAlias values for routers using FRR

Details

    • Improvement
    • Resolution: Fixed
    • Major
    • None
    • None
    • Scripts
    • None

    Description

      I have created an updates set of scripts from the original scripts that populate the ifAlias MIB. These scripts use the output of 'show interface description' in vtysh and add this into the MIB data.

       

      Attachments

        1. ifAlias
          1 kB
          Jan Hugo Prins
        2. ifAlias_persist
          1 kB
          Jan Hugo Prins

        Issue Links

          Activity

            [OBS-4431] Add script to populate ifAlias values for routers using FRR

            In r12998 added complete new pass_persist script, now python based.

            For FRR it try read from both places (by vtysh and later from frr.conf).

            • Install python module:

              sudo pip install snmp_passpersist

            • copy scripts/ifAlias.py to /usr/local/bin/
            • add (replace old) in snmpd.conf:

              pass_persist .1.3.6.1.2.1.31.1.1.1.18 /usr/local/bin/ifAlias.py

            restart snmpd

            landy Mike Stupalov added a comment - In r12998 added complete new pass_persist script, now python based. For FRR it try read from both places (by vtysh and later from frr.conf). Install python module: sudo pip install snmp_passpersist copy scripts/ifAlias.py to /usr/local/bin/ add (replace old) in snmpd.conf: pass_persist .1.3.6.1.2.1.31.1.1.1.18 /usr/local/bin/ifAlias.py restart snmpd

            Parsing /etc/frr/frr.conf sound like a good idea, but this will give you a different problem. 

            The configuration can be written to /etc/frr/frr.conf, but only when an integrated configuration is being used. When there are multiple configuration files for the different frr daemons this will fail because the information needed could be in different files. The only sure way to know that you have the correct information is asking vtysh to give it to you because vtysh has the complete overview independent of the type of configuration file being used, and also independent of the name of the configuration file being used.

            jprins Jan Hugo Prins added a comment - Parsing /etc/frr/frr.conf sound like a good idea, but this will give you a different problem.  The configuration can be written to /etc/frr/frr.conf, but only when an integrated configuration is being used. When there are multiple configuration files for the different frr daemons this will fail because the information needed could be in different files. The only sure way to know that you have the correct information is asking vtysh to give it to you because vtysh has the complete overview independent of the type of configuration file being used, and also independent of the name of the configuration file being used.

            Improved in r12992.

            But for get interface descriptions I use parsing of /etc/frr/frr.conf file, because it's need less permissions than vtysh command.

            landy Mike Stupalov added a comment - Improved in r12992. But for get interface descriptions I use parsing of /etc/frr/frr.conf file, because it's need less permissions than vtysh command.

            Did some minor improvements on the scripts.

            • Will now always take the description from frr, also when the interface is down or unknown
            • If there is no description in FRR it will fill in the interface name in this description field.
            jprins Jan Hugo Prins added a comment - Did some minor improvements on the scripts. Will now always take the description from frr, also when the interface is down or unknown If there is no description in FRR it will fill in the interface name in this description field.
            jprins Jan Hugo Prins added a comment - - edited

            These scripts are no replacements for the old ones, but new scripts doing the same as the old scripts but in a different environment.

            This script is not installed, it is just mentioned in the documentation that you can use it on your servers to populate the information in the MIB.
            So, my suggestion would be to just add it to the scripts directory, maybe in a subdirectory, and mention it in the same documentation.
            I could ofcourse try to modify the scripts and check what codepath to use, but I have not Debian install to test against and I really do not need it.

            jprins Jan Hugo Prins added a comment - - edited These scripts are no replacements for the old ones, but new scripts doing the same as the old scripts but in a different environment. This script is not installed, it is just mentioned in the documentation that you can use it on your servers to populate the information in the MIB. So, my suggestion would be to just add it to the scripts directory, maybe in a subdirectory, and mention it in the same documentation. I could ofcourse try to modify the scripts and check what codepath to use, but I have not Debian install to test against and I really do not need it.

            General questions and device support can be discussed in our Discord channel, click here to join.


            Please make and attach additional information about the device:

            • full snmp dump from device:

              snmpwalk -v2c -c <community> -t 3 -Cc --hexOutputLength=0 -ObentxU <hostname> .1 > myagent.snmpwalk
              snmpwalk -v2c -c <community> -t 3 -Cc --hexOutputLength=0 -ObentxU <hostname> .1.3.6.1.4.1 >> myagent.snmpwalk

              If device not support SNMP version 2c, replace -v2c with -v1.

            • If you have problems with discovery or poller processes, please do and attach these debugs:

              ./discovery.php -d -h <device>
              ./poller.php -d -h <device>

            • additionally attach device and/or vendor specific MIB files

            This comment is added automatically.

            bot Observium Bot added a comment - General questions and device support can be discussed in our Discord channel, click here to join . Please make and attach additional information about the device: full snmp dump from device: snmpwalk -v2c -c <community> -t 3 -Cc --hexOutputLength=0 -ObentxU <hostname> .1 > myagent.snmpwalk snmpwalk -v2c -c <community> -t 3 -Cc --hexOutputLength=0 -ObentxU <hostname> .1.3.6.1.4.1 >> myagent.snmpwalk If device not support SNMP version 2c, replace -v2c with -v1. If you have problems with discovery or poller processes, please do and attach these debugs: ./discovery.php -d -h <device> ./poller.php -d -h <device> additionally attach device and/or vendor specific MIB files This comment is added automatically.

            People

              landy Mike Stupalov
              jprins Jan Hugo Prins
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: