Michael, Thank you very much for your valuable input. I am trying to see what basic response time STATs I can get from using the IOSPing Probe with SmokePing. 1) I have followed the instructions in setting the config file in SmokePing. 2) Set the entries in my router config to permit rsh... 3) Use my NMS with ReadWrite SNMP strings to update Cisco-RTTMON-Mib App. and created a RTT probe.
The problem is I still cannot get anything show on the SmokePing graphs. Anything I have missed? Thanks. Charles -----Original Message----- From: Michael Markstaller [mailto:[EMAIL PROTECTED] Sent: Friday, May 09, 2003 4:47 PM To: Zhu, Charles; [EMAIL PROTECTED] Subject: Cisco RTTMON-MIB and IPM (was: Problem with IOSPing) Hi, 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.. Michael -----Original Message----- From: Zhu, Charles [mailto:[EMAIL PROTECTED] Sent: Friday, May 09, 2003 9:55 PM To: Michael Markstaller Subject: RE: [smokeping-users] Re: Problem with IOSPing Michael, Also, would you mind telling us what are the things that make you dislike Cisco IPM? Thanks. Charles -----Original Message----- From: Zhu, Charles Sent: Friday, May 09, 2003 3:33 PM To: 'Michael Markstaller' Subject: RE: [smokeping-users] Re: Problem with IOSPing Michael, 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. Charles -----Original Message----- From: Michael Markstaller [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 30, 2003 3:50 AM To: [EMAIL PROTECTED] Subject: [smokeping-users] Re: Problem with IOSPing Hi, getting back to this I want to collect some opinions and maybe some experiences. 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 monitoring is: - 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 each devices) - Monitor the RTR probes on the routers from Nagios later, as Smokeping is very fine for latency-reporting but not for monitoring (scheduled downtimes, host-dependencies etc.). 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.. Michael ***************************************************************************** The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this email are subject to the terms and conditions expressed in the governing KPMG client engagement letter. ***************************************************************************** -- Unsubscribe mailto:[EMAIL PROTECTED] Help mailto:[EMAIL PROTECTED] Archive http://www.ee.ethz.ch/~slist/smokeping-users WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi
