[smokeping-users] Re: Cisco RTTMON-MIB and IPM (was: Problem with IOSPing)

Mon May 12 23:43:03 MEST 2003

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:mm at elabnet.de]
Sent: Friday, May 09, 2003 4:47 PM
To: Zhu, Charles; smokeping-users at list.ee.ethz.ch
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:zhihongzhu at kpmg.com]
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: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

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:smokeping-users-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:smokeping-users-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/smokeping-users
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi