Error when trying to update default VLANs, Self IPs and/or Route Domains

JosephPJordan commented 5 years ago

ISSUE TYPE

 - KNOWN ISSUE

DO BUILD/ VERSION

v1.6.0 and earlier

BIGIP VERSION

All versions

SUMMARY

If you used DO to initially onboard a BIG-IP and did not specify unique (non-default) VLANs, Self IPs, or Route domains, you cannot re-POST a DO declaration to the same BIG-IP using different VLANs, Self IPs or Route Domains. This is because when updating the configuration DO attempts to delete the initial configuration, and the default VLAN, Self IPs and Route domains cannot be deleted from the BIG-IP system. This will result in DO trying to rollback, which can fail, resulting in objects being left behind on the BIG-IP device. This can also occur if you did not use DO to onboard the BIG-IP, but later attempt to use DO to configure VLANs, Self IPs, and/or Route Domains.

WORKAROUND

If you want to onboard with DO and have non-default VLANs, Self IPs, or Route Domains, you must include these objects and values as a part of the initial onboarding declaration.

JeffGiroux commented 4 years ago

I think I'm running into this issue. Please confirm if this is the same or if I need to create a new github issue. DO error trying to change port lockdown on existing declaration - DO 1.11.0, BIG-IP 15.0.1.1:

error = 01071412:3: Cannot delete IP (10.0.2.4) because it is used by the system config-sync setting

My setup: Trying to setup HA. I forgot to set external NIC to port lockdown default. Initial declaration had none, so hence HA failed. I tried to push declaration again with default, but I received error above.

started with this declaration (snippet of self IP settings) "external-localself": { "class": "SelfIp", "address": "10.0.2.4/24", "vlan": "external", "allowService": "none", <<<<<<< first declare set to "none" "trafficGroup": "traffic-group-local-only"

Realized HA didn't work due to port lockdown, so I updated json, and repushed this (snippet shown only)...

"external-localself": {
"class": "SelfIp",
"address": "10.0.2.4/24",
"vlan": "external",
"allowService": "default", <<< tried to change 2nd delcare to "default"
"trafficGroup": "traffic-group-local-only"

Workaround, manually changed port lockdown in GUI to "default". Then re-pushed declaration with default...works.

dstokesf5 commented 4 years ago

It looks like DO tried to delete the self IP while trying to apply changes, when it should probably be trying to modify it instead. I believe the issue you are experiencing is different than the one in this issue, and deserves its own GitHub issue.

JeffGiroux commented 4 years ago

Is there an easy way to take my comment and copy into a new ticket? Or, am I better off doing it myself and creating a new ticket?

dstokesf5 commented 4 years ago

I recommend copying it manually so you can fill out the issue template.

xags commented 2 years ago

Will this ever be fixed? Still present in 1.26.0... We have a scenario where we constantly re-configure BIG-IP devices that have completely different configurations (selfIPs/VLANs/etc) and would like to do this with DO. Is there anyway to completely wipe the box state/DO declaration? For example I can't even run a 'tmsh load sys config default', re-install the DO RPM and post a new declaration. A load sys config default should wipe out past DO declarations but it does not and when an error is encountered it rolls back to a configuration it shouldn't even know about. There should be a way to delete the entire 'learned' declaration..

seattlevine commented 2 years ago

Is there anyway to completely wipe the box state/DO declaration?

DO needs something to set back to in the case that you post a declaration and later post another declaration without that object. To do this, it records the state of the device when you first run DO. This is stored internally (in the REST framework storage) in what is known as 'originalConfig'. This information is meant for internal use by DO and is not part of the public API. This means that it may change in the future. However, you currently can delete the 'originalConfig' by doing the following:

Issue a GET to /mgmt/shared/declarative-onboarding/config. This returns an array of config objects - typically only one item is in the array. Each item has an 'id' field.
For all items in the array, issue a DELETE to /mgmt/shared/declarative-onboarding/config/{{CONFIG_ID}}

For the case of rollback during error handling, DO will attempt to restore the state of the device as it was when it received the current declaration. If you have VLANs on the device and post a declaration with different VLANs, then an error occurs during processing, DO will put back the VLANs that were there when it received the POST. This is not something that can be modified.

xags commented 2 years ago

Is there anyway to completely wipe the box state/DO declaration?

DO needs something to set back to in the case that you post a declaration and later post another declaration without that object. To do this, it records the state of the device when you first run DO. This is stored internally (in the REST framework storage) in what is known as 'originalConfig'. This information is meant for internal use by DO and is not part of the public API. This means that it may change in the future. However, you currently can delete the 'originalConfig' by doing the following:

Issue a GET to /mgmt/shared/declarative-onboarding/config. This returns an array of config objects - typically only one item is in the array. Each item has an 'id' field.

For all items in the array, issue a DELETE to /mgmt/shared/declarative-onboarding/config/{{CONFIG_ID}}

For the case of rollback during error handling, DO will attempt to restore the state of the device as it was when it received the current declaration. If you have VLANs on the device and post a declaration with different VLANs, then an error occurs during processing, DO will put back the VLANs that were there when it received the POST. This is not something that can be modified.

THANK YOU! This did the trick!

xags commented 2 years ago

Is there anyway to completely wipe the box state/DO declaration?

DO needs something to set back to in the case that you post a declaration and later post another declaration without that object. To do this, it records the state of the device when you first run DO. This is stored internally (in the REST framework storage) in what is known as 'originalConfig'. This information is meant for internal use by DO and is not part of the public API. This means that it may change in the future. However, you currently can delete the 'originalConfig' by doing the following:

Issue a GET to /mgmt/shared/declarative-onboarding/config. This returns an array of config objects - typically only one item is in the array. Each item has an 'id' field.

For all items in the array, issue a DELETE to /mgmt/shared/declarative-onboarding/config/{{CONFIG_ID}}

For the case of rollback during error handling, DO will attempt to restore the state of the device as it was when it received the current declaration. If you have VLANs on the device and post a declaration with different VLANs, then an error occurs during processing, DO will put back the VLANs that were there when it received the POST. This is not something that can be modified.

One other question. I notice once my new declaration is properly posted and no rollback occurs, when I issue another GET to /config/ I still see some remnants of the old configuration (DNS,NTP, hostname, tacacs config, remote roles,snmp data). Should this not be updated especially for items that I'm specifically setting in my new declaration (DNS, NTP,hostname)?

seattlevine commented 2 years ago

'originalConfig' is the state of the device when DO receives it's first declaration (before applying any changes). By deleting the 'originalConfig' you are tricking DO into thinking that it has not yet received a declaration. Since deleting the 'originalConfig' does not otherwise alter the state of the device, anything you have previously set (DNS, NTP, etc) remains and is recorded as 'originalConfig' when the new declaration comes in. In other words, no, these values should not be updated in this case. You would have to post an intermediate declaration that has the default values you want, then delete 'originalConfig'.

xags commented 2 years ago

Got it, made the intermediary post and it worked as expected, thank you very much for the clarification.

F5Networks / f5-declarative-onboarding