Forum Discussion
Ajene
Altocumulus
AltocumulusPool Member Nodes: Different Partitions, Same IP Address
In summary, I have created multiple partitions. I'm attempting to perform a merge configuration. I get an error stating that I cannot use the same IP address for two separate nodes that reside in different partitions. Is this be design? I'm performing a migration from A10. Can F5 have nodes in different partitions with the same IP address?
Here is my error via the CLI: 0107003a:3: Pool member node (/WEB/pcf-prod-gorouter1) and existing node (/APP/pcf-prod-gorouter1) cannot use the same IP Address (10.66.36.12).
As you can see by the names of the nodes, they reside in different partitions. Thanks in advance for the assistance.
Unfortunately, that is by design. A given IP address can only belong to one node in one route domain (across all partitions).
Further, a pool in one partition cannot reference a node in another (this is also true of most types of objects). The exception is the Common partition: objects in any custom partition may reference any of the objects in Common.
This means you need to move the node to Common and have your pools in WEB and APP partitions both reference the one node in the Common partition.
The supported way to do this is to delete the node from the custom partition, and recreate it again in Common. Of course, that means deleting it from all pools first, and adding it back in again afterwards. That could be quite disruptive.
A less disruptive way is to use the "experimental" mv command in tmsh. First, note the warnings on the manpage about this being an experimental command. Then enable it using the database key described on the manpage. Then, you can move your node while retaining pool memberships with, e.g.:
mv /APP/pcf-prod-gorouter1 /Common/pcf-prod-gorouter1I have found the mv command generally reliable for node moves, except once or twice in an older version where statistics stopped updating until config reload.
In your case (loading config with the merge option) you may also need to update the config you are merging so that the pool members reference Common nodes.
eey0reCirrostratus
Unfortunately, that is by design. A given IP address can only belong to one node in one route domain (across all partitions).
Further, a pool in one partition cannot reference a node in another (this is also true of most types of objects). The exception is the Common partition: objects in any custom partition may reference any of the objects in Common.
This means you need to move the node to Common and have your pools in WEB and APP partitions both reference the one node in the Common partition.
The supported way to do this is to delete the node from the custom partition, and recreate it again in Common. Of course, that means deleting it from all pools first, and adding it back in again afterwards. That could be quite disruptive.
A less disruptive way is to use the "experimental" mv command in tmsh. First, note the warnings on the manpage about this being an experimental command. Then enable it using the database key described on the manpage. Then, you can move your node while retaining pool memberships with, e.g.:
mv /APP/pcf-prod-gorouter1 /Common/pcf-prod-gorouter1I have found the mv command generally reliable for node moves, except once or twice in an older version where statistics stopped updating until config reload.
In your case (loading config with the merge option) you may also need to update the config you are merging so that the pool members reference Common nodes.
AjeneThank you very much! You are 100% correct. As soon as I create another route domain and bound it to the WEB partition, the load /sys config merge operation completed successfully. Luckily this is still a new system so I have the flexibility to configure everything correctly from the ground up without impacting production. Thanks again for the answer!
- eey0re
Route domains are probably an overly complex solution to this, if you can avoid them. They effectively make the two IPs no longer the same. You then need new Self IPs, VLANs etc. to connect the new route domain to the network (it's a bit like having a separate appliance).