11-14-2015 02:31 PM - edited 03-11-2019 11:53 PM
Hi all,
we have a severe problem with one of our Firepower modules. Our environment is a virtual Firesight 5.4.1.3 and two active/standby 5525 ASAs with firepower modules. I'll try to show what we did and what problems we have. It's a brand new installation.
When the ASAs were delivered the Firepower version was 5.3.1-152. This version is still running on the secondary (active) ASA without any problem.
I tried to upgrade the firepower module in the first ASA, but all didn't work:
- When pushing the update from Firesight to the module, the update starts, but after 80 to 90 percent Firesight loses communication with the module. When I restart the module, it shows the newer version, but when I make that ASA active, no traffic is passed.
- In addition to that we cant push new policies to that model. After applying the access-control policy, the failure is shown that the IPS policy can't be read from the module.
- tried to remove the module from firesight, removed the manager from the module, and configured the manager again. But now the manager cant add the module any more.
- tried to install 5.4.0, registration worked, but the module didn't pass any traffic when activated. After an update of the module same problems as before.
- Now I again reinstalled 5.3.1.155 which I downloaded from CCO, added it without problems to the manager and also applied all policies with success. Still, when we make this ASA active, no traffic flows.
- "show module sfr detail" shown normal output. But: When I look at the device in firesight, it nearly looks ok, the only indication of a problem is that in firesight the serial number is shown as UNKNOWN while the serial number is shown on the working module.
I really know how to operate these modules, but dont know how to troubleshoot this situation. Hoping to get some hints here how to solve this problem and or some links to helpful troubleshooting ressources.
thank you all in advance for thinking about my problem.
Ron
Solved! Go to Solution.
11-27-2015 02:32 PM
From your description of events I would guess that manually restarting the module prior to the upgrade having successfully completed left it in an indeterminate state. The TAC could tell for sure by examination of log files on the modules Linux file system.
You may need to reimagine the module to effect a complete recovery. If you don't want to go that route, then a TAC case is in order.
11-15-2015 01:48 PM
Hi,
one more addition to nail this down:
Although Firesight tells me that the policies are up-to-date on both ASAs, they are not.
The command show access-control-config on the working ASA shows the complete access-rule, while the command on the other shows only some rules and most of my categories are empty.
The "UNKNOWN" serial-number above is not unknown any more.
My main question at the moment is: When FS sends the policy down to the module, what can prohibit that the policy gets applied to Firepower?
11-27-2015 02:32 PM
From your description of events I would guess that manually restarting the module prior to the upgrade having successfully completed left it in an indeterminate state. The TAC could tell for sure by examination of log files on the modules Linux file system.
You may need to reimagine the module to effect a complete recovery. If you don't want to go that route, then a TAC case is in order.
11-27-2015 02:32 PM
Hi Marvin
your input was complete right. When the Firepower got unresponsive I did not wait enough. I reimaged all and the update finishd over night. The other problem was false configuration. After adding the zones I did not safe the config in the device config. All policies that hat zones could not got applied because the zones were not on the module. Firesight did not tell me that.
Thank you for your input.
Ron
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide