Thanks for responding Tom (yes, I meant you.)
Test is "the" central system;
Test can communicate to Dev and Prod, it is completely isolated from DR
and is now isolated from Demo. There are workarounds for all of this,
but my question is "Why do we need to use workarounds for work we are
supposed to be doing?"
In my mind, instead of isolating the DR box we should be using it for
HA.
Who are they? Users? Developers? Ops? Who's bringing up servers?
As near as I can tell the network group is now cloning application
servers using VM. Their concern is that they might accidentally bring
up a server and point it to the "wrong" database. Then either a client
might view test data and think that it's production or a programmer
might think they're working with test data, when actually it's prod.
Seems like an unlikely scenario to me, but I'm just the piano player.
Is this implying that these can pop up with no prior notice to you?
Yes, and apparently they can also restrict traffic between subnets with
no notice to me.
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...
Sorry about using the term "Network Security," of course I meant network
security, not your product. I have told them that they will need to
tell me when a new server needs to be added to the list, I am not going
to be able to "figure it out" based on the IP address being rejected.
They would prefer that I use "ESP."
My larger concern is that we are creating a hodgepodge of failure
points. For example, as we move into Vista we have experienced
intermittent drive mapping failures to the iSeries, when we add network
routing rules and restrictive packet filter rules to that it creates
three potential failure points and no-one with end-to-end
responsibilities. Since the actual users on our systems are all
programmers and operators they use iNav extensively and almost all have
authority to all the systems. So they get confused when they run a
command successfully on one system and then it fails on the next.
Regards,
Scott Ingvaldson
Senior IBM Support Specialist
Fiserv Midwest
midrange.com
