Re: Management Central and Network Security

Ingvaldson, Scott wrote:

I am running into difficulties justifying intersystem access for
Management Central here, has anyone else had to do this?

Not me. I've justified it, but never had a problem doing so.

We have an LPARed 550 with a dev, test and production environments, we
also have a completely segregated DR system and a 520 that's being
designated as a "Demo" system for our sales force.

Our network group has recommended that there be no access between
environments, so even though my workstation can contact every system
here, I need to have three separate MC monitors in three different iNav
sessions to view all the systems. This is also affecting running
commands on the Demo system through iNav because the Test LPAR was
designated as the central system and as near as I can tell makes the
compare and update fixes function unusable.

I'm not clear on that last part. Test is "the" central system; that implies that the other two are endpoint systems, perhaps all in a group. It seems reasonable.

I know that I can request that the specific MC ports be opened, but I
was wondering how many others have had to go through this exercise.

I'm hoping that John or Tom will chime in on this...

I guessed that "Tom" might be me because of "John" and also "Network Security" in the subject. But it's not clear what the actual problem is.

Hmmm... but you have a follow-up post...

"The network god's concern is that they *might* accidently bring up a new application server that points to the wrong database."

'...they' -- Who are they? Users? Developers? Ops? Who's bringing up servers?

And "...then they want me to monitor this so that I can immediately authorize a new server that *should not* be excluded from any particular environment."

Is this implying that these can pop up with no prior notice to you? A new app server is installed and you start seeing rejected packets, and you get to immediately figure out if it's okay and to authorize transactions if it is okay, and you don't know about it until packets are rejected...?

So, you have Network Security rules and you have packet-filter rules. (I'm working out why "Network Security" is in here.) You see a rejected packet. You track it down and somehow figure that it shouldn't be rejected. You change the filter to allow similar future ones, and also ensure that any related Network Security rejections are reduced so that the related transactions will be allowed...

Whew!

But, maybe I'm way off base. (Wouldn't surprise me.)

Can you supply an actual scenario? Also, if this does involve the "Network Security" product rather than generic 'network security', this might be a reasonable call to our Support group.

'How-to' is a valid reason for some service.

Get a call record created; it'll get routed out of 'Support', I can guess. You have enough complications for them to at least get John interested. And John will ask us...

Tom Liotta