What follows is a delinquent response to the HP request for feedback on this subject; been working for awhile and finally finished. Post in case still of pre-IPROF interest, and to allow the usual throwing of rocks if I said something that doesn't seem to make sense...... ~135 lines total...... Ken Sletten ========================================= The "Who's Connected to the 3000 Project": We would especially like to concur with the inputs HP already received from Kirby Joss and Chris Bartram; they both did a good job of stating what they said; Chris did a particularly nice job of laying out detailed suggestions. Rather than try and say what Chris did in other words, I'm going to take it upon myself to provide some additional comments and variations, in a slightly different format than the example layout you posted to the list (I tend to interpret instructions liberally in most cases...). So here goes: ========================================= USERS: SM, OP, and Image/SQL database admininstrators. GOALS: (1) Prevent unauthorized system access. (2) Be able to efficiently monitor system access and activity by all users. Zero in on users who are having problems, and also on users who are causing problems (not quite the same). (3) Be able to gracefully get rid of *all* hung/ghost net sessions, WITHOUT having to reboot the system (maybe this is out of scope for the project in question, but recent problems we have had with this cause me to mention it every chance I get (but we just went to 5.0 PUSH last Friday, and I am told some of the problems in this area have been fixed (??))). .... Then again, you did list "SM or OP can easily *resolve* problems" as one of your identified business goals...... (4) Increase visibility of *all* non-direct-DTC-connect access, which currently tend to be more-or-less invisible. (5) Except maybe for stuff like various exotic, obscure network problems (for which you may need a network analyzer, etc.), be able to do (1) through (4) above in an integrated fashion directly on the 3000. TASKS: Kirby Joss, Chris Bartram, and others laid out some good scenarios. Without trying to repeat the good points that have already been raised, a couple more thoughts/refinements: (1) Expanding on one of Chris Bartram's suggestions to be able to configure lists of allowed originating IP addresses: We would like to be able to configure both an ALLOW *and* a DISALLOW list, and be able to do that using at least basic wild card syntax. I.e: Be able to put in everything from one or more specific IP entries, to something like [log in to unmask]@ (2) In any attempt to do a new SHOWCONN command or etc. like Chris suggested, including the <hostname.domain.org> or <[log in to unmask]> whenever possible is important. And leave plenty of space for this; some (like mine) are really long (hmmm..... admit I don't know what the the theoretical or practical max is.....). (3) We would like to be able to set variable trigger values for various network access (or should I say "excess") activities, and automatically log "problem" events. Details of just how this logging should be done I won't try and speculate on. The key is being able to effectively filter problem events out of the massive volume of "normal" net activity. Example: If someone out there is continually sending or receiving huge numbers of TCP packets for an extended period, we would like to have a record...... Actually, we would also like some kind of an "alarm" to go off...... We might even want to be able to configure a level-dependent "freeze" (or dump to ES queue) of net users that appear to be running totally amuck (we have had some). ....... Maybe we are getting a bit out of project scope again, but as before: The "SM or OP can easily resolve problems" goal..... FREQUENCY: We monitor daily as best we can now. Real crises is when system starts going south and we can't figure it out. IMPACT: All of the comments by other users who have already responded apply. TODAY: What we would like to be able to do is either not possible, or requires an inordinate amount of time stumbling around. TOMORROW: Second the motion on bunch of good ideas already mentioned by others. PLUS: Considering all of the above, it seems like one thing we should definitely have as part of a solution in this area is a "NETWORK" screen in GLANCE, where all the neat things you have done and are going to do could be coalesced and integrated. Even though Glance is not part of FOS, it seems like one obvious place to do this. ONE MORE IDEA on GLANCE: How about adding some basic user-defined scripting and logic capability to GLANCE; for ex., something like (many possible variations): IF (# of TCP packets) IN ( { 'x'-seconds | refresh interval } ) > (pick a #) THEN { CS | DS | ES | SUSPEND } This would allow us to automatically put sessions that might try and download 400 MBtyes to their PC or etc. during the busy part of the day into the ES queue..... Of course we would want any such type of IF-THEN logic to apply not just to network parameters, but also to CPU usage and maybe disc I/O..... ....Suppose now I've *really* gotten off project scope...... In any case, another reason logic like above would be nice is that we don't have time to monitor GLANCE continually during the day; sometimes before we notice and/or user(s) start complaining, the problem may have been going on for a long time. So all this would come under the "avoid/fix the problem before they notice" heading. PLUS: Since GLANCE runs in the 'B' queue, if the system is really starting to go south sometimes GLANCE is the last thing we can talk to; one more reason to put things like this there..... ========================================== Thank you to HP for the opportunity to comment. See y'all at IPROF..... Over 50 users signed up for SIGNETWORKING on Saturday, at last count.... =========================================== Ken Sletten ** Tel: 360-396-2525 NUWC Division Keyport ** Fax: 360-396-7861 Code 3311, Building 894 Keyport, WA 98345 [log in to unmask] =========================================== ** Yes, area code is changing: 360 instead of 206.