Forum Discussion
jayson27
Cirrus
CirrusChanging the VS IP of DR Site to Production IP
Hi,
Requesting your guidance.
We are planning to replicate the VSIP of production device to our DR device.
I'm wondering if this will cause a IP conflict. If I will disable the ARP and ICMP of the existing IP of our DR will it be inherit of the new IP after I changed?
I still don't quite get your environment, do you perhaps a drawing?
You write about a production and disaster recovery IP, are those for virtual servers or self IP addresses of the BIG-IP?
I sort of expect something like this.
There is a production BIG-IP with virtual server with IP address 192.168.10.10. You want that same IP address on the disaster recovery BIG-IP so that if the production BIG-IP fails you can enable it on disaster recovery BIG-IP. For that to work you would have to add the 192.168.10.10 virtual IP on the disaster recovery BIG-IP but disabled and not responding to pings. Then afterwards you can add the rest of the virtual server configuration.
One question I still have is why the setup with a production and disaster recovery BIG-IP? Create a cluster and you have a way better way to handle one system breaking down.
- whisperer
MVP
I dont quite understand this on several levels....
- Usually you have services setup as Pool Members and use a singular application VIP. You failover the Pool Members. If you are across 2 datacenters and have LOW latency, you can get away with HA and a traffic group (also assuming you are spanning that network space).
- The other way would be to use DNS based failover using the GTM/DNS module. You would change the advertisement of the IP address of the VIP or server depending upon automatic health monitored conditions or manually modifying the Pool or failing over a Datacenter.
Both of those VIPs are in the same subnet. Are you performing routing changes to only advertise the 10.0.10.0/24 in one datecenter? If so, why use different IP addresses? Just perform the routing change.
boneyardI'm not fully understand the question. Is your DR device a standalone device or a cluster with the production device? If standalone, is it in the same network as the production device?
If you have the same IP on two devices not in a cluster in the same network there will be an IP conflict. If you disable the virtual IP (different from the virtual server) then you can prevent a negative effect, but it remains risky.
Is there a specific reason to built it like this?
jayson27Our DR device is a standalone device.
Can I disable it in advance? Prior to change the existing VSIP?
- boneyard
Yes, just go to the virtual IP section and make the change. Afterwards creating the virtual server won't enable it again or such.
- jayson27
Hi,
I will disable the virtual IP of the existing VS IP that i will change under Virtual Server Address List?
- boneyard
It is probably easier if you can give an example what you are asking. Can be with fake IP addresses, but just to be sure it is clear what you are asking.
- jayson27
HI,
For example 10.0.10.120 is our production IP. And 10.0.10.100 is our DR IP.
On our DR F5 I will disable the 10.0.10.100 Virtual IP before I change it to production IP 10.0.10.120? Will this avoid the IP conflict?- boneyard
I still don't quite get your environment, do you perhaps a drawing?
You write about a production and disaster recovery IP, are those for virtual servers or self IP addresses of the BIG-IP?
I sort of expect something like this.
There is a production BIG-IP with virtual server with IP address 192.168.10.10. You want that same IP address on the disaster recovery BIG-IP so that if the production BIG-IP fails you can enable it on disaster recovery BIG-IP. For that to work you would have to add the 192.168.10.10 virtual IP on the disaster recovery BIG-IP but disabled and not responding to pings. Then afterwards you can add the rest of the virtual server configuration.
One question I still have is why the setup with a production and disaster recovery BIG-IP? Create a cluster and you have a way better way to handle one system breaking down.
