My experience is similar, I'd never recommend and upgrade to anyone from 8.2 to 8.3+ as the upgrade scripts for larger configs are imho more pain then they are worth. A once what felt an efficient and supportable config becomes the complete opposite. Do it in the lab prior and fix all the upgrade script problems, or do a parallel migration ie. new hardware on 8.4+ when your refresh cycle comes around.
On Monday, 18 February 2013, Jeff Kell wrote: > OK, now have ASA up on 8.4 software, and boy is it ever weird :) > > We do NAT extensively (all 1918 addressing inside). For public-facing > servers, primarily web servers, we made a habit of translating them into > a public /24 network (say x.y.z.*). The "firewall" atrributes for this > was to simply permit http and https for x.y.z.*/24 inbound on the > outside interface, and the rest took care of itself. > > Along comes 8.4... and it "includes" NAT with the network object > definitions... and the "migration" effort did this: > > * Put all the static NATs back into the inside object definition, > * Generated a "permit http" and a "permit https" for EVERY SINGLE SERVER > we had in the subnet > > Our configuration increased by an order of magnitude :( And it doesn't > appear that explicitly adding the original permit into the list even > works (it sits in the configuration above the generated individuals, but > doesn't get any hits, they fall through to the generated mess). > > This is the most bizarre "update" I've ever seen :( > > Jeff > > _______________________________________________ > cisco-nsp mailing list [email protected] <javascript:;> > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
