[mrtg] Re: Suggestion: How to Poll if:s on their names (or IP/ifDesc) instead of ifindexes. (Long)

Tue May 23 15:48:39 MEST 2000

Jakob (and other list members),

I am pleased to report that such a patch does exist.  I am not sure why it has not been done in vanilla MRTG, but that is not really the point.

* History (feel free to skip this section...but it does give credit to those who deserve it)

Andre Pirard originally wrote such a patch for MRTG v2.1.  He had a separate version for interface names with slashes (Serial0/1) and one for interface names without slashes.  Rob Janssen partially ported the patch to MRTG v2.53 in May of 1998, based on the file date.  I came across these patches last year when I was using MRTG v2.4.7b.  I decided to port the same patch to that version of MRTG, which I finished and then submitted to Mr. Pirard to post on his Web site at http://www.ulg.ac.be/~pirard/Cisco/mrtg_descriptors.htm.

Several months ago, I had multiple e-mail messages requesting an updated patch for MRTG v2.8.12.  I decided to port my v2.7.4b patch without making any real code changes and see if it fit.  I did fit with little or no troubleshooting, but I was not able to fully test it then.  I sent the file to those that had requested it, and I planned to create a Web site with these patches and contiue to post new ones as new versions of MRTG came out.  I still plan to do this, but time has not allowed so far.

Note that my modified version should work fine for interfaces with slashes, and it should still allow the use of the slash to specify an interface by IP address.

* The file

I am attaching the file for any and all who are interested.  (Which of course means it will be available at a URL listed below.)  You can rename it from 'mrtg-ifdescrs' to 'mrtg' (and you may have to), but I would recommend backing up a copy of your current 'mrtg' file.

* Issues

There is one known issue with the script at this time.  Interface names that contain a colon will not work.  This is because the colon is used as the field separator between the interface and the community string.  I have a solution to this problem that has not been tested.  If anyone would like this functionality and would not mind being a guinea pig, please e-mail me.

* Disclaimer

I make no claims as to the accurate functionality of this script.  Please use at your own risk.

* The end

I hope this helps some of you out there.  I'm not necessarily available to troubleshoot lots of problems, but if you find something specific, I would not mind the notification.  Then if I look at this script in the future, I can try to figure out the reported problems as well.

Best regards,
Keith

----- Original Message ----- 
From: "Jakob Ilves" <jilves at se.oracle.com>
To: <mrtg at list.ee.ethz.ch>
Sent: Tuesday, May 23, 2000 3:38 AM
Subject: [mrtg] Suggestion: How to Poll if:s on their names (or IP/ifDesc) instead of ifindexes. (Long)

Hello MRTG users!

(This posting is long, I know.  My apolgizes if it put anyone to sleep.)

There has been some postings here on the subject of polling an interface
based on the name of the interface instead of the ifindex number.  Such
a feature is not only convenient, it is actually vital when polling
logical subinterfaces which ifindex might change upon reboot the
device.  (Also, one could imagine it to be useful to be able to select
the if based on ip-address or on the description matching a certain
regexp which helps if connections are moved between interfaces).

Below are my thoughts on the subject.

The solution which seems the most common (I say "seems" as I've not
actually read the patch providing this to MRTG and thus don't necessary
know what I talk about ;-) is to get all ifnames using SNMP and then
pick the right names, find their matching ifindex and then do the rest
of the polling.  This each time the MRTG do it's polling cycle every 5
minutes.  The drawback with this approach is that you need to get all
the ifnames everytime MRTG are to poll the device, even if it is just a
single router.  Not only will it make MRTG polling slower (and thus
making it more difficult to do all interfaces within 5 minutes) but
also, it will cause more SNMP polling against the router than perhaps
necessary, causing the router to spend extra CPU on SNMP.

(Imagine that you are to poll a Cisco Catalyst switch with 200
interfaces and you only are intrested in ONE interface...  or a Cisco
router interface with 1000+ subinterfaces (yes, they exist!).  That
would be quite some CPU overhead).

So what do I have in mind?  Two suggestions based on doing that "get all
ifnames" of the device only once everytime it has just rebooted. (Both
suggestions assume that interfaces ifindex stays fixed between bootings
of the device).

1.) Keep polling ifindexes as usual, but as a first step when MRTG does
it polling thing, it checks the uptime of the device.  If the devices
uptime is longer than the age of the actual config file, proceed as
normal as the config file is expected to reflect the current
ifname/ifindex relation.

If the config file is older than the uptime of the device, though, that
means that the machine has rebooted and ifindexes has changed.  In that
case, first scan all the ifnames and then do the necessary alterations
of all ifindexes in the config file.  This will need either intricate
logic in the reconfig code or an alteration of the MRTG config file or
both.

2.) Never touch the config file but let each device have an extra file
associated with it containing each ifname/ifindex pair or
ifname/ip-address/if-description/ifindex etc (let's call that file the
"interface file" :-).  At every MRTG poll cycle, test the uptime of the
device vs. the age of the device's interface file.  If the interface
file is younger than the device uptime just proceed with normal MRTG
polling.  If the interface file is older than the device uptime or the
file even do not exist, first regenerate it and then proceed with
polling.  (Deleting the interface file will force it to be regenerated
and thus be up to date which could be useful).  This way MRTG will only
do a polling of all ifnames (and perhaps if ip-addresses) once per time
the device is rebooted.

The interface file could have lines like

14:public at myrouter, ATM4/1/0.43, 10.1.1.17, UK-US Link

Of course, if multiple MRTG instances refer to the same device, they all
might decide that the device's interface file is out of date and try to
update it in parallell having each MRTG instance poll the device for all
names and then try to write them down...  (Locking schemes?  Just live
with this behaviour?  Have a dedicated daemon to handle this?  Unh...
now it might start to get complicated....).

In order to make the two both suggestions above far simplier it would be
very good if one somehow could specify in the Target[] statement if an
interface with a specific name, ip-address or description is wanted.

Target[router_pvc_43]: ATM4/1/0.43:public at router.myorg.org
Target[router_ethernet]: 10.1.1.15:public at router.myorg.org
Target[router_ethernet]: /UK-US Link.*/:public at router.myorg.org

is clear and unambigous enough to specify an interface based on ifname,
if ip-address or if description (the last line is supposed to contain a
regexp).

Personally, I would just LOVE to have the ability to specify a
description field regexp on each target and just forget about if
indexes, if names or if ip-addresses.  Imagine you have a clearly
defined naming convention in place for the description fields so every
description for contains "near_end_site-far_end_site" in the beginning. 
Creating MRTG targets would then be a breeze!

Your thoughts on this?

Best regards

/IlvJa

-- 
                (Jakob Ilves) <jakob.ilves at oracle.com> 
             {Oracle Global IT, Network Management Group}
[Office as well as mobile phone: +46/8/477 3666 | Fax: +46/8/477 3572]

-- Attached file removed by Listar and put at URL below --
-- Type: application/octet-stream
-- Size: 73k (74771 bytes)
-- URL : http://www.ee.ethz.ch/~slist/pantomime/mrtg-ifdescrs

--
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
Archive     http://www.ee.ethz.ch/~slist/mrtg
FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org