topic Please see the below url for in Network Security

FTDv 6.2 Upgrade no Deployment possible

m.stoedtner — Tue, 12 Mar 2019 08:53:46 GMT

Lets start from beginning.

We have two 5515 running FTD 6.1.0.1 and a Virtual Machine on ESXi with FTD 6.1.0.1!

We upgraded our FTDv to 6.2.0 and our Sensors in HA (Active/Standby) are on 6.1.0.1!

After the Upgrade no Deployment of our Access Policies are possible. The Active Peer switched to Secondary and no Switch back is possible.

The Policy Deployment hangs on 40% over an hour an quits up.

As in Cisco Bug CSCvc81801 mentioned, we should restart the ngfwManager on the Active Peer and restart the secondary peer.

But how can we do that? Which command should we use to restart this ngfwManager?

Thanks in Advance

Please see the below url for

syeda3 — Tue, 07 Feb 2017 13:51:27 GMT

Please see the below url for Command Reference for Firepower Threat Defense.

http://www.cisco.com/c/en/us/td/docs/security/firepower/command_ref/b_Command_Reference_for_Firepower_Threat_Defense.html

Hope to help.

You can restart ngfwManager

Oliver Kaiser — Tue, 07 Feb 2017 22:36:42 GMT

You can restart ngfwManager using pmtool on the CLI.

> expert
admin@ftd:/home/admin# sudo pmtool RestartById ngfwManager

Before executing the command you might wanna sync up with TAC to verify you really hit the bug. Your firewall should not restart in case you restart ngfwManager but I would recommend doing it during a maintenance window or consulting TAC.

This command was not found!

m.stoedtner — Mon, 13 Feb 2017 06:11:18 GMT

This command was not found! it wasn´t possible to restart this manager!

Our Solution was to delete

m.stoedtner — Mon, 13 Feb 2017 06:13:18 GMT

Our Solution was to delete the HA Cluster and reimage the the failed appliance to the newest version. afterward brought this device up with the active IP addresses and reimage the "active" device.

after this it was possible to recreate the HA Cluster with both appliances.

Re: You can restart ngfwManager

Robert Ebers — Wed, 28 Nov 2018 21:34:59 GMT

I was able to resolve my deployment conflict using this procedure.