Forum Discussion
CirrusBIG IP VE on a single network
Good afternoon I am migrating an F5 device to virtual from physical and when I define the internal network it says it overlaps with the management network. There's only a single network on this DMZ environment and wanted to know if there was a way of just using the internal interface with the ip addressing and bypassing the mgmt interface all together. Our physical LTMs do not have a management address as well they only have an internal ip assignment. Any help would be appreciated.
Thanks Dario I think I found a way to do this which is pretty simple. Our single network is a /24 I revised my mgmt ip to be an ip in a /25 network then created a self ip in the other /25. Set the mgmt ip to auto configure and then revised my self ip with the correct /24 mask. Thanks for the help with this anyway Devcentral is a lot more helpful than F5 official support!
4 Replies
Dario_GarridoNoctilucent
Hello Thomson.
You can use one of your self-ips to manage your device as a regular management IP.
To do so, you need to configure your IP lockdown option as "Allow default".
REF - https://support.f5.com/csp/article/K17333
Your current management IP could be replace it with a dummy IP instead.
Regards,
Dario.
Thomson_ThomasThanks Dario how can I achieve this in a VE install? right now im connecting with the management ip how can i change this to the self ip without losing connection? is there an option in the config utility to do this?
- Dario_Garrido
Hello Thomson.
You need to perform two actions:
1) configure a self-ip for allowing management access.
2) configure a dummy ip in the management interface (eth0).
You can achieve this using two ways:
1) using a transient ip between changes.
2) using a transaction to perform both actions at the same time.
REF - https://clouddocs.f5.com/cli/tmsh-reference/latest/modules/cli/cli_transaction.html
REF - https://support.f5.com/csp/article/K01930721
If it's the fist time you do a transaction, I recommend you to test it on your lab first in order to avoid management access disruption.
Regards,
Dario.
