I have recently updated my ASA cluster to 8.4.X in the hope that this might introduce some stability in my IPv6 support. Little did I know it would introduce other issues for IPv4 that I have only now resolved.
Firstly a little bit of background. I run a pair of Cisco ASA 5510 in active/standby mode. They run OSPF to learn about internal routes whilst having a default route pointing out to my policy routers.
The problem I had encountered since the upgrade (or perhaps shortly after) was that the ASA cluster was no longer sending messages to syslog. Upon investigating I could see an obvious route in the routing table, learned via OSPF yet the firewall would state that there was no route.
This was unusual behaviour and whilst I wanted to resolve it , I also needed syslog working. So I created a static host route for the syslog server so that I could get that working. In order to complete the process I had to disable redistribution of static routes within OSPF else all other syslog traffic would end up at the firewalls.
This of course then broke remote access VPN as an IPSec VPN would generate a static route on the ASA which would then need to be redistributed. So I lived with that for a while whilst I continued to investigate.
Today I needed to get the VPN working again so I renabled the static route redistribution which then caused the syslog routes to dissapear. I finally solved it when I looked at the configuration in CLI mode and discovered that OSPF had three network statements! Now normally this wouldn't be an issue but when I looked closely at the routing table I discovered something unusual. For each internal destination there were multiple routes in the routing table, only one of which had an interface associated with it.
I theorized that a bug in ASDM prevented any of the network statements from showing up and thus caused me to add superfluous network statements. In turn, these superfluous network statements caused invalid routes to be added to the routing table and prevent normal traffic from working.
I believe this is correct as upon removing the extra network statements and bouncing the OSPF process, the interface-less routes dissapeared and normal traffic resumed. I was able to remove the static routes and everything functioned as expected.
For reference, I'm running 8.4.2. I can only assume this is a bug and will be resolve in a future update. I'm just glad I've resolved it.
