LOL. I am so glad we went with palo alto.
http://www.networkworld.com/article/3186772/security/cisco-issues-urgent-reboot-warning-for-bug-in-asa-and-firepower-appliances.html?idg_eid=dd4c0543036ed3c974fdee9c968ce967&email_SHA1_lc=b8d6d747842dd1d58cedecfeef2ae6dc354abcf2&cid=nww_nlt_networkworld_security_alert_2017-03-31&utm_source=Sailthru&utm_medium=email&utm_campaign=NWW%20Security%20Alert%202017-03-31&utm_term=networkworld_security_alert (http://www.networkworld.com/article/3186772/security/cisco-issues-urgent-reboot-warning-for-bug-in-asa-and-firepower-appliances.html?idg_eid=dd4c0543036ed3c974fdee9c968ce967&email_SHA1_lc=b8d6d747842dd1d58cedecfeef2ae6dc354abcf2&cid=nww_nlt_networkworld_security_alert_2017-03-31&utm_source=Sailthru&utm_medium=email&utm_campaign=NWW%20Security%20Alert%202017-03-31&utm_term=networkworld_security_alert)
Seems like this one is making the rounds, and it's a big one, so it's justified.
We're having some issues with unresponsive firewalls and are *downgrading* code to try and resolve the issues.
Ristau has another thread on this, but I'm not going to combine them. This is a big enough issue to warrant two threads.
For those of you just joining us, it may be wise to script a reboot of your ASA firewalls every 212 days.
:facepalm4:
Yikes - glad we went with PA as well :P
We are still waiting on our replacement Cisco 43xx routers for the clock signal bug.
This is BS. Network engineers aren't supposed to reboot stuff.
Quote from: Dieselboy on March 31, 2017, 08:31:53 PM
This is BS. Network engineers aren't supposed to reboot stuff.
Absolutely. That's what sysadmins are for!
Honestly. It is an inconvenience, but the ASA fail-over is nice, and it is very seamless. It is just another thing to throw on the "ASA is crap" list.
THIS TIME IT _IS_ THE FIREWALL.
:rofl:
I received an automated email from Cisco today about this, sent to our group email which the director / company owner received. The email says a fix is out but I've not looked yet. Was busy scouring packet captures for a packet loss issue. :blank:
Quote from: Dieselboy on April 04, 2017, 07:22:08 AM
I received an automated email from Cisco today about this, sent to our group email which the director / company owner received. The email says a fix is out but I've not looked yet. Was busy scouring packet captures for a packet loss issue. :blank:
yes there are fixes, if you are running ASA 9.7.1 or greater use the arp limiter command
arp rate-limit <value>
this will restart the ARP rate limiter and extend another 5120 hours.
if running less that 9.7.1 reload the device before 5120 hours (213 days)
Quote from: ristau5741 on April 04, 2017, 07:45:16 AM
Quote from: Dieselboy on April 04, 2017, 07:22:08 AM
I received an automated email from Cisco today about this, sent to our group email which the director / company owner received. The email says a fix is out but I've not looked yet. Was busy scouring packet captures for a packet loss issue. :blank:
yes there are fixes, if you are running ASA 9.7.1 or greater use the arp limiter command
arp rate-limit <value>
this will restart the ARP rate limiter and extend another 5120 hours.
if running less that 9.7.1 reload the device before 5120 hours (213 days)
Okay so Cisco's email said this:
QuoteWe estimate your device is currently at 33 days of uptime, and will therefore experience this issue in 180 days if no action is taken. Fixed versions of software are now available on the Software Download Center on cisco.com
They gave the bug ID (note number of cases :XD:)
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvd78303
And then note the "fixed" software versions, for my 9.7.1 it says 9.7.1-4
and cisco.com downloads has 9.7.1-4 ready for the DL: asa971-4-smp-k8.bin
(PS you have to drill down in the downloads to find this release under "inter rim" :squint:
"Interim" where I work means "wait and see".
Anyone going with the 9.7.1-4?
We're undecided on which way to go.. and We have a while before the bug is triggered on our ASA's
I was going to, but haven't got round to it yet. When I went to the first release of 9.7.1 there was a memory page issue that was known to Cisco but an internal-only bug ID. So after reading the release notes and not finding anything alarming then setting up a VTI tunnel and running a few pings I was happy and went home. The next day I had a window before the remote site users arrived in the office, so I set up some static routes to send traffic over the VTI which was set up the night previous. Shortly after doing that, I lost my SSH session to the ASA-X. Luckily for me, I have an active/standby pair. Unluckily for me, when the standby ASA took over, it was of course running the same image as the primary and immediately crashed due to the same issue.
This isn't how it is supposed to be. It kind of devalues the release notes.
What about if I upgrade the primary only, and leave the backup unit as-is? I think the ASA will moan there is a version mismatch but they're both the same major version number. Even going from different version numbers I've managed to do upgrades without breaking anything. I can reboot the backup unit every 6 months and if there's a catastrophic problem with the latest release then the backup will take over. As the versions arent the same, the catastrophic problem shouldnt be there.
We're looking at 9.5.2 as a good, stable release without a lot of baggage. We'll go to 9.7.5 probably after 9.7.7 is released.
:yeahright:
We're in the 9.5 range too... Decision on which version should be decided next week..
Quote from: EOS on April 08, 2017, 07:31:02 AM
We're in the 9.5 range too... Decision on which version should be decided next week..
9.5.2 is the latest version that doesn't have this bug and not as many CVEs against it as the earlier versions.
I'm on 9.7.1-2 and I'm waiting to see what you guys do before I make up my mind :XD: