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

[Jakob Ilves]

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: text/x-vcard
-- Desc: Card for Jakob Ilves
-- Size: 433 bytes
-- URL : http://www.ee.ethz.ch/~slist/pantomime/11-jilves.vcf


--
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