Unexplained reboots for Firepower 2100

[daz10000]

After a long period of pretty stable operation, we have been experiencing semi-random outages for our WAN and after a brief suspicion of the external network connection are fairly certain our Firepower is actually the cause of the outage and just determined that it has in fact been rebooting itself.   It appears to happen after about 2 days of operation.   The web interface shows very little useful so getting more familiar with CLI.  A few questions

1) what is the best way to determine cause of reboot or symptoms?  (I have only seen uptime so far and it's short enough to explain the outage)

2) any ideas what might cause that pattern (the reboots are almost exactly (not quite)) 2 days apart so far, so it looks semi systematic..  Otherwise device looks happy - low cpu, plenty of disk space, not terribly loaded.   Any thoughts appreciated and I suspect I'm about to get a crash course in the cli commands which is fine

[steeda]

Same problem here with a 2130 running 6.6.1. Did you ever resolve your issue?

[gilbert.aispuro1]

I've had a ticket open with TAC for the past 2 weeks and they barely identified the issue.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvw30252

The reason of this is due to a corruption on the SMNP process, which is used only for the active unit.

So far there us a workaround which will fix this problem, the workaround works as follows:

• Remove the SNMP configuration from the FTDs via the FMC
• This can be accomplished by disabling SNMP under platform settings
• After this we will need to reboot both FTDs manually to clear the info remaining.
• This can be done with the following command:
• >reboot
• I suggest to do this after hours
• After this we will need to deploy one more time the SNMP configuration to the FWs.

Also this bug is fixed in LINA version 9.15.1 with is bundled with FTD 6.7 version.

[daz10000]

Yes, took a while to catch it in the act and see the what was happening but there was a bug in an earlier version that basically panicked once the clock skew got too high (difference between network time and machine time exceeded a threshold after a few days) - it would cause the stem to miss a heartbeat (or think it had) and then it would just panic and reboot the whole machine.  It's fixed in a later operating system.

[daz10000]

Mentioned here https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvm33553/?rfs=iqvred

[johnlloyd_13]

hi,

i have the same issue but i'm running FPR 2100 in ASA appliance mode.

the primary/active initially rebooted itself, then secondary (acting as active) got rebooted after around 2 days.

there's no 'show crashinfo' dump generated on both.

was the bug link provided by TAC? did they advise to do an image upgrade?

[hunnymonster]

Turning off basic monitoring functionality? Is that really sustainable? I have 27 of these devices - for some reason I feel the need to monitor them directly (not least because it appears SNMP query appears to be the only reasonable way to determine uptime).

For what it's worth (anecdote) we have experienced this from 6.4.0.7(8 & 9), 6.6.1 (2,3,5 & 5.1). I'd gladly upgrade to 7.x but 3 of our suppliers still insist on IKEv1 (argh!) - working on them becoming ex-suppliers in the New Year.

[sky2022]

Same problem here with a 2140 running 6.6.4 and  6.6.5 . Did you ever resolve your issue?

[steeda]

Get out of 6.6. Serious. 

[sky2022]

Cisco official website suggested 7.0.4, but Cisco engineers replied that users in China suggested 6.6.7。Which version do you use now？

[sky2022]

Cisco engineers asked us to upgrade from 6.6.4 to 6.6.5, but the problem remains. Now Cisco engineers suggest upgrading to 6.6.6