I have a customer running 8.3.1 that is facing a very strange issue. Some SIP packets are silenty dropped. This seems to be random. The SIP packets are of type "request:options". The source and destination ports are the same: 5060. The outside interface has an ACL permitting this traffic. We also have the default service-policy applied. Anyone has seen something like this ? Any ideas of how to troubleshoot this ?
Thanks. Regards, Antonio Soares, CCIE #18473 (R&S/SP) [email protected] -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Ryan West Sent: quarta-feira, 12 de Maio de 2010 13:40 To: Ivan; cisco-nsp Subject: Re: [c-nsp] ASA 8.3 Ivan, > -----Original Message----- > Sent: Wednesday, May 12, 2010 4:12 AM > To: cisco-nsp > Subject: [c-nsp] ASA 8.3 > > Hi All, > > Shortly I will be deploying some new ASAs and came across the 8.3 > release. I didn't expect that a minor release would have quite so many > fundamental changes. Without looking at the release notes, migration > notes > (http://www.cisco.com/en/US/docs/security/asa/asa83/upgrading/migrating.html) > and various blogs etc on the Internet I would have expected things to be > not too different than 8.2 which I have used recently. > > I would appreciate any feedback from those who have deployed 8.3 as a > new install or migration. I will eventually have to decide if it is > better to stick with the known 8.2 or the new 8.3 (new features and new > bugs) to save the pain of an update later. > The structure of NAT has changed so much that any non vanilla implementations are going to be very touchy. If you're using a large pool of NAT exempt addresses and calling them from a object-group, this will be expanded per entry into statements like: Nat (inside,any) source static <new generated object network (not an object-group)> <new generated object network (not an object-group)> destination static <object-group name> <object-group name> So, seeing that for the first time might come as a surprise. I ran into two NAT bugs during a migration with PAT and order of operations. CSCtf89372 is one of them, which still is not fixed in the interim. A manual re-ordering of NAT rules fixes the issues, I thought Cisco had moved on from the PIX 6.3 days, guess not. -ryan _______________________________________________ cisco-nsp mailing list [email protected] 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/
