We have the following distributed Spectrum 9.2 infrastructure approaching a production rollout:
(4) Linux Red Hat 5.4 ES - OC Consoles - geographically located for redundancy (1) Linux Red Hat 5.4 ES - MLS Primary / secondary pair - also functions as the Trap Exploder & Trap Director (9) Linux Red Hat 5.4 ES - SS primary/secondary pairs to monitor our 11,000 network devices (1) Windows 2003 Server - SS primary secondary pair that basically support our SANM requirements since SANM not available on Linux (2) Windows 2003 Server - One is setup for SRM primary - the secondary a cold backup. This function will not be included below as the data is stored outside the isolated network. We got started with the Windows SRM approach back on 9.0 not supporting SRM/BOXI on Red Hat 5.x. All primary/secondary MLS/SS/SANM server pairs are split between two different geographic locations Here is our challenge - we provide application processing for a client that has very strict security requirements. One of those is that monitoring data cannot be stored outside of the network segment where it's network devices are monitored. Based on that requirement we are placing a primary/secondary SS pair inside the isolated segment (SDC would not work here) to do the actual monitoring, process traps, etc and store the SSdb & DDM data inside that network. Spectrum Admin's have a special VPN access to these servers for SSH access. The challenge comes in with CORBA connectivity between the OC consoles, MLS, and SANM that reside outside that network, to the primary/secondary SS pair inside the isolated network. A second requirement is no clear text traffic inside the isolated network nor any tightly nailed down connections to other network segments if needed. Based on that we are using SNMP V3 to monitor the network devices and handle the device traps. As a note running a standalone Spectrum environment for this client is not an option either as the NOC will not work with two different sets of OC consoles. The connectivity of the NOC & Spectrum Admin's to the OC consoles, is addressed with SSL connectivity from Java clients to the OC consoles. Now what is left is the CORBA connectivity between the MLS, OC Console, SANM, and the isolated SS primary secondary pair. All suggestions point to using IPSec tunnels (17 pairs) at this point but we are getting a lot of FUD (Fear Uncertainty & Doubt) from our Linux & Windows Admin's stating we cannot do Windows to Linux IPSec tunnels and the Linux to Linux is too much overhead on the environment. I have asked them to quantify the FUD factor as to how much is the performance overhead. IPSec tunnels are not a standard, setup for our organization, even though we have had Windows to Windows IPSec tunnels for years on our Unicenter TNG/NSM environment. This isn't a large number of network devices being monitored (under 100) so the overhead on the SS pair will not be much and the processing power is 4 x what we normally have available for our Linux SS (16GB Memory & 4 Dual Core processors). Yes, I know that is a bit overkill for 100 network devices. We might be more concerned with the virtual MLS and/or OC images, the SANM's should be okay as they will have low usage. So . . . Does anyone have any experience with IPSec tunnels carrying the CORBA connectivity between Spectrum resources? Windows to Linux & Linux to Linux configurations that would be willing to share their experience? Or can you suggest a better method to provide server to server (end to end) encryption & security of that clear text CORBA traffic? Thanks Raymond Ferber IT Architect Office 402-777-1868 Mobile 402-960-5126 [email protected] ----------------------------------------- The information in this message may be proprietary and/or confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify First Data immediately by replying to this message and deleting it from your computer. --- To unsubscribe from spectrum, send email to [email protected] with the body: unsubscribe spectrum [email protected]
<<image002.png>>
