Commit Failures Following PAN-OS v5.0.x Upgrade (Panorama Managed Device)

Printer Friendly Page

Commit Failures Following PAN-OS v5.0.x Upgrade (Panorama Managed Device)

Issue

Following upgrade to PAN-OS v5.0.x, managed devices with locally configured Log Settings referencing PANORAMA PUSHED objects, i.e. 'SNMP Trap Server' object result in commit failures though autocommit will complete successfully following the upgrade.

Though shared profile exists on the appliance & Log Settings (i.e. Config Log configured to utilize Panorama Shared SNMP Trap Server), commits will fail referencing shared server object. Additionally, attempting to edit any of the available log settings and selecting the SNMP Trap drop-down menu will NOT populate Panorama pushed object (though existing config will still reference the now 'ghosted' object).

Panorama v4.1.x referencing a 'Shared' SNMP Trap Server Profile:

418.JPG

Managed Device, PAN-OS v4.1.x showing the 'Panorama Pushed' Server Profile:

418device.JPG

Managed Device, PAN-OS v4.1.x configured utilizing the 'Panorama Pushed' Server Profile as an SNMP Trap server for local log settings:

418device-log-settings.JPG

Commits initiated from either Panorama (on PAN-OS v4.1.8) or locally on the device should be successful, i.e.:

418-commit-ok.JPG

Following upgrade of Panorama/PAN-OS v5.0.x, upon completion of the initial AutoCom of the appliance, subsequent commits now result in failure, with errors similar to the following:

Operation: Commit

Result: Failed

Details: log-settings -> system -> informational -> send-snmptrap -> using-snmptrap-setting 'SNMP-Trap-Test' is_not_a_valid_reference

This is despite there being a SNMP Trap Server Profile (pushed from Panorama) available:

50commit-fail.JPG

Editing the local Log Settings however & selecting the SNMP Trap drop-down for any of the severities WILL NOT populate the Panorama Pushed Server Profile, validating the previous error:

drop-down.JPG

Workaround

Due to the schema changes following the major release upgrade (which includes Panorama Template options, etc...), a Template push to the device will be required FIRST following the upgrade, followed by a Device Group push to assure Panorama<->Device synchronization.

From the Panorama Context, select the 'Commit' operation, then select Commit Type: Template (as well as associated device experiencing the commit failures):

template-push.JPG

Following successful Template Commit, Commit once more to the device, selecting Commit Type: Device Group which will now re-push shared objects/synchronize with the device:

successful.JPG

Following final device group push (Commit Succeeded), managed device should now be in-sync:

sync.JPG

Managed device should now have a Panorama Pushed/Synced Server Profile which will also be a selectable drop-down option via the local Log Settings:

verify-device.JPG

Subsequent changes requiring either Panorama Pushed or Local Device initiated commits should now be successful:

ok.JPG

owner: bryan

Labels (1)
Comments

If the above procedure does not work, does anyone know of other possible debugs to run and review or other workarounds? I'm thinking maybe recreate the affected object in Panorama, though I'd like to avoid this if possible.