Weird and Wonderful Requirement - Separate Physical Networks

Unanswered Question
Mar 5th, 2010
User Badges:



There are two sites. One is the front end and other is the backend. Both are on two separate physical networks. Front end has a database and backend has its own database and the data needs to be shared between each other on daily basis/batch process. The Backend database holds highly classified information and therefore, one of the mandatory requirement for backend connectivity is that the data should not be exchanged over a 'wired' network at all i.e. both the networks should not be connected by any means. So thinking out of blue to fulfill this requirement below are the few options I could come up with.

1. Connect the front end and back end database over the wire through a switch. Connect another switch to the second NIC of backend database. Control both the switches via 'Remote Reboot Unit / Remote Power Control'. During the data transfer between the databases, power down the second switch through power control appliance. When the data transfer is over, power down (through power control appliance) the first switch and power up the second switch for backend communications

2. Same as option # 1 but use the time-based ACL on Layer 3 switches instead for complete traffic blocking (More of a logical disconnect but not really physical)

3. Some kind of a Robotic media handler. Media could be USB, CD or Tape. The robot would unload the media from library one (which holds front end database snapshot) and load it into the library two (to upload the data into the backend database). Both the networks are physically separate. Yet to find one robotic device as such.

4. Network Switch Circuit Breaker: Both the databases are connected via a switch. The internal circuitry of the switch is 'adjustable'. That is, once the data is transfered, the internal circuitry of the backend database port is switched to another port on the switch (i.e. breaks the complete connection with the front end database). Well, never heard of such a thing. Just thinking big.....(Like the oldest telephone networks wherein for every call the lines would be manually patched by the operator. Also could be a switch box with a big button on it. For e.g. button position 1 means allow traffic, button position 2 means block traffic.

Please suggest if anyone has tried out something like that and it has worked in Production environment.

The bottom-line is both the networks should not be connected and the data needs to be exchanged between both the networks. An automated solution is required and not manual (such as a human manually shifting CD's every night).

Looking forward to your bright ideas.


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
dedra_live Fri, 03/05/2010 - 15:26
User Badges:

Hi Reza,

Extremely interesting.

Is it possible to use the same technology (like installing send card on the second machine and receive card on the first machine for the way back) or any other technology for two-way data transfer.


Reza Sharifi Fri, 03/05/2010 - 17:55
User Badges:
  • Super Bronze, 10000 points or more
  • Cisco Designated VIP,

    2017 LAN


As far as I know this is a one way transfer and for security reasons you can not go the other way around if not it would defeat the purpose.

Would it work for you at all?


dedra_live Fri, 03/05/2010 - 18:12
User Badges:

Hello Reza,

The scenario I had mentioned will actually be an online system where the front end is connected to internet. Front end database information is pushed to back end database by ** some means of physical transfer in an automated way **. Subsequently, the back end database updates also needs to be pushed back/synchronized with the front end database by ** some means of physical transfer in an automated way **.

I was thinking of putting up four servers. Two for front end to back end with Owl and the other two for back end to front end again with Owl.

Also, even with a one-way transfer how can a hack attempt be prevented. Hack does not have to be two-way. The attacker can intrude and corrupt, write on to the server file system through one-way. Isn't that right ?


Reza Sharifi Fri, 03/05/2010 - 18:37
User Badges:
  • Super Bronze, 10000 points or more
  • Cisco Designated VIP,

    2017 LAN

Hi Dedra,

I think you idea of putting two servers on each side or may actually work well.  When I mentioned security reasons I did not mean hacking from outside world (Internet), I meant data classification as in your case the two networks can not touch one another........ You probably have to consult your security deportment before deploying such system as they may not allow that.


Giuseppe Larosa Fri, 03/05/2010 - 14:11
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Dedra,

>> 2. Same as option # 1 but use the time-based ACL on Layer 3 switches instead for complete traffic blocking (More of a logical disconnect but not really physical)

this is probably the better way to do this.

Another improvement  would be to use two different VRFs that are made able to communicate through one device with time based ACL on it so you have a guaranteee that the only possible path is that using that device.

The device could be a pair of routers implementing two HSRP groups on two subnets one connected to VRF1 and one to VRF2 for redundancy.

Hope to help


dedra_live Fri, 03/05/2010 - 19:27
User Badges:

Hope to get more bright ideas from Cisco Networkers....

dedra_live Sat, 03/06/2010 - 00:22
User Badges:

Hi Reza,

Below are few points with regards to Owl Security I got from FAQ


Owl systems are designed to prevent leakage of sensitive information from secure isolated networks. Data flows into the secure network, but cannot flow out through the same channel. Without the capability of bilateral communications, the secure network is rendered impervious to probing cyberattacks

An Owl system functions like a routing gateway, but with an important difference: data flows in one direction only, and routes are preconfigured. Because security is enforced in hardware, there is no possibility of security breach through software attack. Owl drivers have been developed internally and are not dependent on the IP communication stacks of host platforms on which they reside. Owl systems cannot be "hacked."



This Discussion