In response to this, I'd like to comment on Lucent's excellent response to this issue. Never before have I seen such an effective application of hear-no-evil, see-no-evil, and speak-no-evil. While other vendors were wasting our time sending out notifications of bugs / vulnerabilities with workarounds / fixes, Lucent's response was much more efficient and eloquent. Here is a summary of the responses I've received over several days phone calls, calling for my current employer who does not have a service contract, and one for one of my consulting customers who does have a service contract. If you have a service contract, I'm allowed to tell you we aren't aware of any issues. If you don't have a service contract, I'm allowed to sell you a service contract. On that note, I might have some TNT's for sale pretty soon. -Ejay -----Original Message----- From: Brian Wallingford [mailto:brian@meganet.net] Sent: Saturday, August 23, 2003 12:41 AM To: nanog@merit.edu Subject: TNT issues "workaround" I haven't seen specific details posted here, so: Like many others, we've had a few TNTs online for years without hiccups or reboots until this week. Beginning late Sunday, we saw seemingly random blade reboots, and total system crashes. Errors ranged from memory leaks to infinite loops on the controller blade, but all blades were susceptible. HDLC2 blades seemed to be particularly vulnerable. We saw boxes that had been rock-solid for very long periods suddenly rebooting at periods ranging from 20 minutes to 4 hours, with no obvious cause (i.e., nothing more specific than the above). Border and core filtering of icmp echo * did little good. On the suggestion of some folks on another list, and against my better judgment, we disabled route caching in order to free up additional memory (though memory did not appear fragmented). This stabilized all involved boxes, and surprisingly, did not result in significant degradation of end user performance. Granted, it's not a true fix, but it may get you a few extra Z's at night. hth, brian