This ICMP discussion reminded me that we've been logging broadcasts for a while at ME to see what percentage of traffic they represented and what it was (the wrong way round to track back thru ICMP DoS attacks). If anyone's interested, the results are : 192.41.177.255 (254376 matches) 255.255.255.255 (1694830 matches) any other dest. (1047899270 matches) which is 0.18% of the total accounted for by broadcasts. Bad, of course, but not as bad as I thought. I guess the bigger the provider the smaller percentage of total (that 1billion is total input on our FDDI since I applied the list, rather than total packets on the LAN) I'm assuming that a billion packets is enough to be a representative sample. A bit of a breakdown from the logs : Split of broadcasts is ICMP 12% UDP 88% (actually, there were 5 packets for protocol 9 (private IGP?) but that's neither here nor there) Port breakdown (based on a smaller sample to save resources) ICMP ---- I won't name names (I'll contact people later on probably) but 99.2% of the ICMP traffic comes from one provider (two routers) and is directed at 255.255.255.255. That should be fairly easy to stop. Is there any good reason for a router to ping the broadcast address of a NAP ? UDP --- PORT: 53 PACKETS: 5 PORT: 67 PACKETS: 5364 PORT: 123 PACKETS: 9950 PORT: 161 PACKETS: 12 PORT: 513 PACKETS: 6635 PORT: 520 PACKETS: 19486 PORT: 5841 PACKETS: 4344 -------------------------------- 45796 53 = DNS (badly configured cisco, but temporary so that's OK) 67 = BOOTPS (!) (probably misconfigured cisco again ;) 123 = NTP (ditto!) 161 = SNMP (?? - god knows why this would happen) 513 = who? 520 = routed ( oh dear) 5841 = ??? (is this CDP?) The upshot would seem to be that even with loads of misconfigured/ clueless stuff going on, random traffic is so insignificant that it wouldn't affect the performance of the NAP infrastructure. Cheers, Lyndon -- Penis Envy is a total Phallusy.