1. Home
  2. Cisco Systems
  3. Good tool for reporting real-time and trend stats for multiple VPN 3000 concentrators?

Good tool for reporting real-time and trend stats for multiple VPN 3000 concentrators?

Can anyone point me to a good tool that can provide near-real-time and trend stats for multiple VPN 3000 concentrators?

Let's say that I have a cluster of concentrators at a site in D.C., another cluster in San Diego, and one in Paris. I'd like to know at any given time how many total users are connected, and be able to drill down by site (for example 12000 total users connected, 6000 of them are in Paris, 2000 are on one concentrator, and 4000 are on the other).

The trending would mostly be used to show usage patterns--my Paris users connect early in the morning until noon, but San Diego users connect all day Saturday. That sort of thing.

Having the output on a web page would be ideal.

I've called Cisco, and it seems like they listened to my request, and sent me literature on their syslog appliance that can be configured to send alarms, but provides no reporting function like what I've described, at least not that I can see from the literature. If someone's used one of these and can comment I'd appreciate that as well.

I've looked at sawmill for analyzing syslogs, and I suspect it could be made to do what I need, but I wonder if there are other parsers/reporting tools that are better suited to the 3000-series concentrators out of the box.

Thanks, Heath

Reply to
Heath Roberts
Loading thread data ...

I just started working with Concentrators in production this past year and I'm still flabergasted that enterprise level VPN appliances don't have reporting worth a damn. The only rpeorting is who is logged in at this second which is barely useful.

We have the same issue and someone here is doing a home made script to cull the syslogs and generate a DB of sessions.

I have to say... Nortel Contivity back in 2002 had built in history (multiple months) and reporting right on the device. Unlike Cisco's their redundant pairs also maintained a sync'd config. I can't believe I'm supposed to manually maintain sync'd configs between redundant nodes. I've becoming increasingly aware that as Cisco absorbs more and more companies to grow markets and remain "competitive" they seem to slip further away from building products that fit even basic customer needs.

"Heath Roberts" wrote:

DiGiTAL_ViNYL (no email)

Reply to
DigitalVinyl

DigitalVinyl wrote: [snip: incredible lack of enterprise level reporting]

I guess if you complain enough, it gets in there. We actually punted on the stackable 3700 series switches because it lacked basic snmp monitoring. It was a case of "rush it out and call it an enterprise switch" "What about the management?" We'll worry about that later!

But eventually, they do seem to add it in. It'll be interesting as they move more and more into other spaces (AON, cable settop boxes etc)

I must admit, the recent cable box acquisition was a brilliant move.

Reply to
Hansang Bae

We've got a few 3750 stacks and the auto-update-sw function is totally unreliable. Only one of four stacks successfully upgraded the slaves. And Cisco reps are pushing these stacks as the next-best-thing. Meanwhile we've had 3 hardware replacements out of about 16 boxes in productions. All three failed within the first few weeks. Maybe we're unlucky... i dunno. At another company we experienced similar unreliablility with Nortel's latest-greatest set of stacks (in

2001-don't recall the models).

With the PIX firewalls I think items like the fact that they still haven't come up with a fully functional reliable GUI for their firewall is embarassing. The latest ASDM GUI still doesn't compare in functionality or reliability to what I used on Checkpoint in 2002!

With technology changes everybody has problems, but I guess we always assume the market leader is the most forward-looking or at least talented in that respect. Unfortunately it is often the opposite. I still recall Bill Gates' affirmation that there was no commercial potential in 'the Internet'. Then suddenly MS woke up.

I do get frustrated that security and ESPECIALLY manageablility are typically unimportant in the design of new technolgoy. As I started dealing with fast switching (MLS/CEF) I found that thing we relied upon in the apst, like statistics and ACL hits were made useless because hardware switching made accounting on the traffic not possible. Then of course you can buy new expensive board to enable NetFlow technology which gets you back the visibility lost by the last technolgical move forward. That type of stuff frustrates me.

DiGiTAL_ViNYL (no email)

Reply to
DigitalVinyl

For a single box I'm using good old MRTG to graph the number of active users. It should be possible to set that up for multiple units and the total ? It's SNMP, use any tool you like.

Here's an extract from the MRTG config file, the SNMP OID is in there if needed :

### user count : .1.3.6.1.4.1.3076.2.1.2.17.1.9.0 ###

Target[vpn-users]:

1.3.6.1.4.1.3076.2.1.2.17.1.9.0&1.3.6.1.4.1.3076.2.1.2.17.1.9.0:@@@@@10.166.32.4 SetEnv[vpn-users]: MRTG_INT_IP="@@@@@" MRTG_INT_DESCR="" MaxBytes[vpn-users]: 100 Title[vpn-users]: Users -- VPN concentrator PageTop[vpn-users]: Users -- VPN concentrator System: Cisco 3000 VPN concentrator in MER Description:Users active
Reply to
brink

DigitalVinyl wrote: [snip]

Not to bash on Cisco too much, but what they hell were they thinking putting in such a small drive on their NMS modules? If you span a few ports on the 6500, you're done in a few minutes. What were they thinking?

Reply to
Hansang Bae

Why not use MRTG or Cacti to monitor the amount of logged in users on your concentrator.

Both monitoring tools will do the job, provided that you specify the OID's. These can also be found on cacti page.

I do like MRTG but cacti is easier to work with if you want it to do simple things.

Reply to
Johan

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.