Kirit:

1. Some users are still able to access ifxdb01/2 while others can only connect to ifxdb03/4
   This is the hard one. In this case you have new transactions on two different primary servers. Some of which may clash (hopefully your normal mode of operations makes this unlikely). In that case the best solution would be to link the two "primary" servers via ER and let ER sync the two copies of the database. Once that is done you can convert ifxdb02 to an RSS secondary. If the changes create too many clashes you may have to resolve some of the clashes manually. Very painful. This is one reason to use Connection Manager to manage server promotions with additional out-of-network methods for multiple CM instances to coordinate with each other to prevent split brains.
2. Even though it is still online, ifxdb01/2 is not reachable at all for any user transactions.
   This one is simple, you treat ifxdb01 & ifxdb02 as if they were offline and recover them appropriately once the network is back.
3. Even though ifxdb01/2 and ifxdb03/4 are not on speaking terms, users can still get to ifxdb01/2 and no one can get to ifxdb03/4
   This one is simple also, ignore that the backup site is unavailable and recover it when the network is repaired.

Kirit:

1. Some users are still able to access ifxdb01/2 while others can only connect to ifxdb03/4
   This is the hard one. In this case you have new transactions on two different primary servers. Some of which may clash (hopefully your normal mode of operations makes this unlikely). In that case the best solution would be to link the two "primary" servers via ER and let ER sync the two copies of the database. Once that is done you can convert ifxdb02 to an RSS secondary. If the changes create too many clashes you may have to resolve some of the clashes manually. Very painful. This is one reason to use Connection Manager to manage server promotions with additional out-of-network methods for multiple CM instances to coordinate with each other to prevent split brains.
2. Even though it is still online, ifxdb01/2 is not reachable at all for any user transactions.
   This one is simple, you treat ifxdb01 & ifxdb02 as if they were offline and recover them appropriately once the network is back.
3. Even though ifxdb01/2 and ifxdb03/4 are not on speaking terms, users can still get to ifxdb01/2 and no one can get to ifxdb03/4
   This one is simple also, ignore that the backup site is unavailable and recover it when the network is repaired.

Kirit:

1. Some users are still able to access ifxdb01/2 while others can only connect to ifxdb03/4
   This is the hard one. In this case you have new transactions on two different primary servers. Some of which may clash (hopefully your normal mode of operations makes this unlikely). In that case the best solution would be to link the two "primary" servers via ER and let ER sync the two copies of the database. Once that is done you can convert ifxdb02 to an RSS secondary. If the changes create too many clashes you may have to resolve some of the clashes manually. Very painful. This is one reason to use Connection Manager to manage server promotions with additional out-of-network methods for multiple CM instances to coordinate with each other to prevent split brains.
2. Even though it is still online, ifxdb01/2 is not reachable at all for any user transactions.
   This one is simple, you treat ifxdb01 & ifxdb02 as if they were offline and recover them appropriately once the network is back.
3. Even though ifxdb01/2 and ifxdb03/4 are not on speaking terms, users can still get to ifxdb01/2 and no one can get to ifxdb03/4
   This one is simple also, ignore that the backup site is unavailable and recover it when the network is repaired.