On Wed, 24 Jun 2009, Phil Mayers wrote:
So, it seems to be some kind of analogous feature to TCP SYN protect or
such like, to protect a client flooding a server.
All,
Cisco have identified this as a bug, fixed in 1.5 - CSCsw52831 / CSCsu42225
"udp packets are dropped by ace". It's a timing-related issue in session
setup.
Many thanks to the guys at TAC, who were extremely quick and effective on
this, and thanks to all who gave suggestions on the list.
Kudos to Phil for excellent work together! It was a very good bug hunt.
Luckily it was even already fixed, and was not something burnt in
hardware.
As I've blatantly self-appointed myself to track the ipv6-related
matters in TAC as much as I can, if anyone on the list has something on
the topic, feel free to drop an email to me with the case#, I'll ensure I
keep an eye on it. (disclaimer for the archives: this statement may no
longer be applicable in 2020 :)
looking a bit further - to all:
1) If the A/AAAA bang-bang lookup over a single 4-tuple is an issue for
anyone with other our other devices, I'd like to know ASAP.
2) what if the endboxes were doing the A and AAAA from two separate ports
? I see two clear disadvantages - doubling the state on the "dumber NAPT"
boxes, and "more work for glibc folks" - assuming the biggest problem is
the first, how big is it for real-life deployments ?
thanks,
andrew
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
