[mrtg] Re: Network conf. changes ==> MRTG is messed up!!!

[Tim Kennedy]

Hello Argiris,

I have had the same problem.   We have about 160 routers, and on any given
day hardware is being swapped out or circuits are beind added or removed
or upgraded.
Here is the patch for using interface names as the target, instead of the
ifindex instance.  This is applied to cfgmaker.

303c303,307
<     my $name="$router.$index";
---
>     my $interface = $sifdesc{$index};
>     $interface =~ s/\s/\_/g;
>     $interface =~ s/\//-/g;
>     $interface = "\L$interface\E";
>     my $name="$router.$interface";

Now.  If you changed that to parse out the interface description instead,
you could use a specific field in your interface desription like a circuit
ID or something to build your targets and logfiles and everything else.

Then you wouldn't have to try to move around all those now obsoleted
logfiles and graphs to the new name.  You just let it go.  occasionally
you would need to rebuild if you add completely new hardware.  also, you
would have to make sure you weren't usting [nyc-wdc] on all you circuits
from "NYC" to "WDC", as that would confuse the script.

Best I can think of so far.

-Tim

ps. don't forget to check for bandwidth so that when that circuit moves
you don't still have t-1 bw on it when it got upgraded to a t-3.  :)


On Mon, 15 Nov 1999, Arnellos Argyris wrote:

> Hello thanks for replying.
> 
> The network is changing in the sense of the router's configuration changing.
> 
> Let's say, today the link from XXX to YYY is on ATM/1/0/1 of the switch A
> and tomorrow it may be on ATM/1/0/2 of the switch A.
> 
> This means that I have to change the .ok file in order to keep track and
> also change the cfg file in order the correct description to be included in
> the respective .html file.
> 
> The configuration of the Cisco routers, can also be changed (with respect to
> the interface descriptions) even with a simple "reboot".
> 
> You are right to say that "Mrtg must thus somehow be told the change in
> /what/ or the change in /where/, in order to work properly"
> and for this to be done there must be a common key (in all the
> configuration). We have done this in our NMS and the key is the description
> of the interfaces. Unfortunately, I cannot get into the MRTG code and do the
> same think. What makes me wonder is why nobody from the MRTG development
> team has ever worry about this problem.
> 
> Regards
> 
> Argiris

Timothy Kennedy
sugarat.net, Network Management Resources
http://www.sugarat.net

--
* To unsubscribe from the mrtg mailing list, send a message with the
  subject: unsubscribe to mrtg-request at list.ee.ethz.ch
* The mailing list archive is at http://www.ee.ethz.ch/~slist/mrtg