[smokeping-users] Cisco RTTMON-MIB and IPM (was: Problem with IOSPing)
mm at elabnet.de
Fri May 9 22:47:08 MEST 2003
I had that many bad experiences with IPM so I'll take the chance to get the frustration off my chest. posting it back to the list maybe preventing others to get also frustrated ;)
What I dislike on IPM:
- It's insecure, no *very* insecure regarding user-authentication at the frontend.
- it's impossible to limit access (without [undocumented from cisco] changes to the installed apache). anybody can point a browser to server:1744 gaining access
- I need to have per-customer access to only several (their) devices - impossible
- It's very ugly to manage (each source-destination must be entered as source and target because I cannot specify the source IP explicitely.) A bit complex to explain, but for instance management-access is only possible (my own security-policy) over an encrypted IPSec-tunnel to the management-loopback's IP, therefore I cannot measure from the routers' outside IP to something else as the "source" in IPM is the private Loopback.
The above is a limitation of IPM, not the MIB or the router.
- It's unstable, loosing probes when routers reload - totally inacceptable when you have 50 routers with each 50 probes
- (re-)configuring the probes is alway click-wait-click-wait-click several hundred times (running on full blown a PIII-1000 with 1gig RAM etc.)
- limited to none reporting-capabilities for stopped probes
- requires a bunch of memory-eating java-crap-services on a high-perfomance-machine which isn't nescessary for collecting and summing a few snmp-parameters - at leats IMHO ;)
- requires a bunch of memory-eating java-crap-services (no I really dont like java) on the client, loading megabytes of applets on each start to the browser (not everybody using it connects with 100mbit to this sever..)
- installing a special client is no option. (but it's not better with it)
- impossible to use the generated probes on the router to monitor remote site-to-site links with nagios (or any other intelligent monitoring tool) which takes care of scheduled downtimes, host-dependencies, notification and escalation-rules etc. -> so I'm in writing something anyway..
- impossible to make (usable) exports and report on collected data.
- BTW: SLM from within CW2k is the same but with even larger apps, limited capabilities and much more clicking-wainting-clicking-.. and the most important thing: no SCHEDULED DOWNTIMES ! what should an SLA report be good for when it measure maintenance downtimes without being able to correct it.
BTW2: talking about the windows version, I don't and won't use solaris (anymore)
not to leave the wrong impression, I like Cisco's products mostly and I really like the idea of the RTTMon-Mib but the according Cisco software-products are a pain.
now to your second question:
> SAA responder on the remote router, which could become a security issue.
no, you only have to enable it IF you want to run probes like Udpecho, not for ICMP. If you enable rtr resp you really should (as always) limit access with ACL's..
From: Zhu, Charles [mailto:zhihongzhu at kpmg.com]
Sent: Friday, May 09, 2003 9:55 PM
To: Michael Markstaller
Subject: RE: [smokeping-users] Re: Problem with IOSPing
Also, would you mind telling us what are the things that make you dislike
Cisco IPM? Thanks.
From: Zhu, Charles
Sent: Friday, May 09, 2003 3:33 PM
To: 'Michael Markstaller'
Subject: RE: [smokeping-users] Re: Problem with IOSPing
I read your email a few times and I think you have a lot of great ideas. We
are for sure interested in the same approach (i.e. use SomkePing and take
advantages of what Cisco-RTTMON-Mib can offer. We had a eval copy of the
Cisco IPM. My understanding is: in order to get it setup and working, one
would need to enable SAA responder on the remote router, which could become
a security issue. So, I am thinking that we are going to running to the
same requirements/issues using SmokePing, right? Wishing your success and
God speed in writing the probe for SmokePing.
From: Michael Markstaller [mailto:mm at elabnet.de]
Sent: Wednesday, April 30, 2003 3:50 AM
To: smokeping-users at list.ee.ethz.ch
Subject: [smokeping-users] Re: Problem with IOSPing
getting back to this I want to collect some opinions and maybe some
I went through Cisco-Ping-MIB and found it quite useless because the lack of
support to specify the source IP/If.
Cisco-RTTMON-Mib (called SAA/RTR on routers' side) is complete and would be
a great deal as Smokeping probe but quite complex to handle. But the
abailities would be great as it would provide any current IOS-router as
remote probe for many protocols (ICMP,UDP,TCP,HTTP,DNS etc.)
I know about and use Cisco's IPM (which actually uses this MIB) but I don't
like IPM that much...
I already read through Cisco-RTTMON-MIB and creating Smokeping-probes, so
I'm finally planning to actually write (and share afterwards) a
smokeping-probe for RTTMON-Mib but with my limited perl know-how and
resources any help/hint would be appreciated. What I need to achive for my
- Probe latency and probably some other things with RTTMON-Mib from several
(50) Routers, so I need speed and effeciency from the start. There're
especially IPSec-SA's to be monitored so this could be several pings from
- Monitor the RTR probes on the routers from Nagios later, as Smokeping is
very fine for latency-reporting but not for monitoring (scheduled downtimes,
I'm asking myself a few question now:
- Anybody else interested in uisng RTR on cisco-boxes as probes
- is there an easier way (besides IPM) ?
- should the RTR be created once running forever on the router and then only
polled from Smokeping (and recreated if not existant)
- this is the intentional "how-to-use-RTR" Cisco had
- would make monitoring possible with something other (my Nagios)
- would make coding the probe harder
- results in orphaned probes and resulting traffic if removed from
smokeping until next reload (I'm still thinking about that, maybe I can flag
each RTR-probe on the Cisco's with a flag uniquely identifying "my"
smokeping instance and kill all orphaned probes)
- It can run always, so i.e. for 20 pings with steps 300 I could do
a ping every 15 seconds which would make stats-distribution more real
(campared with running the 20 pings within 2 seconds while probing.
- the other way would be to create a RTR-probe each run and kill it after
reading the results
- I already see myself seeking a mem-leak with cisco-TAC ;)
Another problem I see, again my perl know-how is "limited". Smokeping
expects (pings)-values from each probe which is a global parameter. now I
want to keep making 20 pings but the RTTMON-probe will intentionally only
return 3 values (min/avg/max);
what is the best way to intergrate the probe into smokeping with having 20
pings configured returning only 3 values ? making 20 out of 3 values (a perl
sniplet will make me more than happy ;) or is there a smoother way to do ?
Anybody having experiences with using Cisco-RTTMON-MIB to probe things ? Any
sample would speed up things much for me..
Unsubscribe mailto:smokeping-users-request at list.ee.ethz.ch?subject=unsubscribe
Help mailto:smokeping-users-request at list.ee.ethz.ch?subject=help
More information about the smokeping-users