I’ve sent more info to the TAC re that ACE logging issue – which has not shown up again for a few weeks. It stopped suddenly after the production rservers in the ‘correct’ context were finally started up (the context was prepared and active prior to server deployment). In any case, the TAC has escalated it to the engineering team for analysis. I agreed with one of Cisco’s engineers that said “this shouldn’t be possible”. Love it :)
We deployed a Cisco WAAS appliance to the Brisbane office – all seemed ok however the voice team said ‘at some stage after the WAAS was turned on’ they had messages-on-hold errors. Strange given that WAN optimisers ignore udp. Because the deployment is using wccp – it is likely something has gone wrong with the router – or it could be unrelated altogether.
Also, I learned a valuable lesson the other night – never gloss over the ‘clear xlate’ command on a FWSM. When messing around with static nats, hours can be saved troubleshooting by using that command … bah.
Invisible Infrastructure 
I love it how Cisco class logging as low severity bugs. Logging is considered a low priority, however when you get a spanning tree or routing issue that melts your network this is a priority issue. Especially when it is a GSR or 7600 core device.
In the troubleshooting process you rely on the accuracy of logs to effectively troubleshoot a priority network affecting issue that would be classed priority one by the TAC. Ah the irony, and you are expected to have accurate and time synched logs to provide the TAC with enough info to assist the troubleshooting process.
Well when you get ‘bugged’ by logging caveats it’s a catch 22.