Archive for the 'Network' Category


Stuck with 2 different networks

Recently, while working on dataguard we had a problem configuring it accross networks between our production site and our DR site.
After a few tests, it seems that the configuration works fine locally but not through the lease line.
So, to bypass this, we wanted to take the standby server back to production site and configure dataguard locally.

This raises a few problems.

1) We can’t modify the IP address of Primary or Standby server
2) The network on the production site is different from the network on the DR site.

Basically, when we bring it to the production site, it’s not possible to ping or connect to the standby server.

The solution is very simple:

The production site network is 172.30.XX.0/
The DR site network is 172.30.XY.0/

Prerequisite: Both servers need 2 NICs

What we are going to do is the following:

On primary:
Configure a 2nd NIC to use an IP address of the DR site: 172.30.XY.34

On standby:
Configure a 2nd NIC to use an IP address of the production site: 172.30.XX.12

On primary:
Type the following command on command line:
C:\>route add 172.30.XY.0 MASK 172.30.XX.12

On standby:
C:\>route add 172.30.XX.0 MASK 172.30.XY.34

If we now try to ping the IP address 172.30.XY.XXX of the standby database from production site, we will receive an answer.
What we are telling to the production server is: If you are sending a packet to the DR Site, then send it to the address 172.30.XX.12 instead. The same applies to the standby server.

With this route added, the production server won’t be visible to the DR site anymore since every packet are routed to a different location. So use it with caution.

Finally, when all is done, what is left to do after the configuration is to delete the route:

On primary:
C:\route delete 172.30.XY.0

On standby:
C:\route delete 172.30.XX.0

Disable the secondary NICs. All is back to normal.


March 2018
« Mar    


Blog Stats

  • 514,673 DB lovers