Solved: Firepower 1150 Upgrade FTD 7.4.2.2 -> 7.6.2 kills OSPF redistribution

Network Diver · ‎10-07-2025

Hi,

While waiting for Cisco TAC to analyze all the troubleshoot info and core dumps I want to warn the community about yet another fun experience while updating Cisco firewalls.

We had to update our FTDs running 7.4.2.2 which ran fine for months due to the critical security flaw CVE-2025-20333. [1] Even the Swiss National Cyber Security Centre scanned and alerted us, so this seems to be a very critical one.

Last week ago I've updated a Firepower 1120 from our non-critical environment from FTD 7.4.2.2 to 7.6.2-329 and then to 7.6.2.1-3. That one went fine. Two days afterwards I did the same for a Firepower 1150 which is our prod AnyConnect VPN peer and access DMZ. I did again use the Wizard from FMC 7.6.2.1-3 but this time it was Saruman and not Gandalf doing his wizard business. Upgrading and reloading the standby unit worked fine, but then when doing failover from primary all network connection to VPN peer and DMZ was lost. With troubleshooting and analysis I found out that the FTD stopped redistributing connected subnets and AnyConnect VPN IPs via OSPF, but the FTD still could see routes from other network devices via OSPF. Quickly adding those routes on our Nexus core switches and redistributing them with OSPF re-established network connectivity again. The OSPF configuration is the same on all FTDs we have. The past couple of updates it did not cause trouble.

I desperately searched how to just restart the OSPF process like it is possible on ASA, Catalyst and Nexus, but despite useless and false Google AI suggestions I only found this, which didn't work Found CSCvq27999 [2], but here's no such command in normal CLI and not in diagnostic CLI. I had to reload primary standby, apply pending deployment and failover active. After that failover the core switch immediately showed the OSPF routes coming from the FTD.

The same happened when upgrading from 7.6.2-329 to 7.6.2.1-3 plus after switching the active peer the standby peer did a core dump and reboot, leaving a lina core file.

Is redistributing connected VLANs and AnyConnect IPs with OSPF from a FTD a bad and uncommon thing? We've done this with ASA for years. Alternatively one could inject those routes from the core switch into OSPF.

References:

nspasov · ‎10-07-2025

I just tested on another appliance running 7.4.1.1 and the command is there. I think the problem with your "ftd2" output is that you are trying to execute the command from the User EXEC Mode ">" Can you try again but first elevate your session to Privileged EXEC mode:

> system support diagnostic-cli
ftd2> enable
Password: blank just hit "enter"
ftd2# clear ospf 1 process

Thank you for rating helpful posts!

Thank you for rating helpful posts!

View solution in original post

nspasov · ‎10-07-2025

I am sorry to hear that you ran into an issue with your production environment! Please keep us posted on what TAC says because I have not seen this issue before.

About restarting OSPF: I don't have an 11xx appliance but I tested this on virtual and on the 1010 and while the "clear ospf process" command is not available via the CLISH, i was able to execute it via the diagnostic CLI:

NS-FTDv-02# clear ospf 1 process
Reset OSPF process? [no]: yes

Thank you for rating helpful posts!

Thank you for rating helpful posts!

Network Diver · ‎10-07-2025

Funny, that command seems to have come with FTD 7.6.2.1.

> system support diagnostic-cli
ftd1# clear ospf ?

  <1-65535>       Process ID number
  all             Clear ospf information for all VRF(s)
  counters        OSPF counters
  events          OSPF Event Log
  force-spf       Run SPF for OSPF process
  process         Reset OSPF process
  redistribution  Clear OSPF route redistribution
  traffic         Traffic related statistics
  vrf             Virtual Routing and Forwarding Instance

ftd1# clear ospf 1 ?

  counters        OSPF counters
  events          OSPF Event Log
  force-spf       Run SPF for OSPF process
  process         Reset OSPF process
  redistribution  Clear OSPF route redistribution
  traffic         Traffic related statistics
  vrf             Virtual Routing and Forwarding Instance
 
ftd1# clear ospf 1 process ?

It was not available with FTD 7.6.2 and older.

> system support diagnostic-cli
ftd2> clear ?

  lisp  clear lisp EID

The crash after switching active peer is related to OSPF.

nspasov · ‎10-07-2025

I just tested on another appliance running 7.4.1.1 and the command is there. I think the problem with your "ftd2" output is that you are trying to execute the command from the User EXEC Mode ">" Can you try again but first elevate your session to Privileged EXEC mode:

> system support diagnostic-cli
ftd2> enable
Password: blank just hit "enter"
ftd2# clear ospf 1 process

Thank you for rating helpful posts!

Thank you for rating helpful posts!

Network Diver · ‎10-07-2025

Thanks. I probably had forgotten that as the "enable" command is not available in the standard CLI. It's also not mentioned in CSCvq27999.

Network Diver · ‎10-09-2025

The OSPF redistribution error and crash reload is caused by this bug: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwq35960

nspasov · ‎10-10-2025

Yikes! This is a nasty one! Thank you for taking the time to share the CDET for this issue.

Thank you for rating helpful posts!

Thank you for rating helpful posts!