North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: TCP session disconnection caused by Code Red?
George Herbert ([email protected]) said: I've been told (but not given permission to forward details of who/how/what) that some major sites with a single router and relatively flat network topology are dying due to the ARP request flood that is being generated by Code Red scans on the inside of their border router choking the router. Check the rate of ARP requests coming off your border router and see if it seems excessive; if so, that may be it. My campus is now seeing around 500 packets per second of CodeRed connection requests into blocks that total 130,000 addresses. The work of ARPing for all that stuff is distributed across 6 routers (mostly Cisco RSM) and they're doing OK. The experience at Cal State campuses is variable. They do tend to have flat topologies behind a single entrance router. Our neighbors at CSU Monterey Bay melted under the load _before_ CR-II emerged. They had their upstream install an access list permitting an explicit list of campus web servers and blocking port 80 to everything else. Their router is mfg by Alcatel, a PowerRail 7652 OmniCore 5052. I don't have a lot of details about their setup but I do know how big their assigned address pool is -- about 6000 addresses. That leaves me wondering about the importance of quality of the ARP implementation in the router code. I have heard that CSU Long Beach (Cabletron router) had similar problems. I'm looking for anyone that knows some details of Alcatel and SSR routers that might help us understand this. I don't think this is a case where the ingenuity of ASIC designers is the important parameter. Have any of the router benchmarks dealt with the capabilities and robustness of what I'm imagining must be process-level parts of the a router implementation? -jim warner, University of California Santa Cruz