I don't want to be assigned the task of assigning blame -- every vendor has had their turn receiving and giving it -- but it's pretty clear to me that because Apple implemented RFC 4436 the bug in Cisco's software was brought to light. Since there appears to be no bug in the Apple code, but only in Cisco's ARP handling in specific cases, I presume that's why Cisco is taking the heat. Regards, Frank
_____ From: Prof. Robert Mathews (OSIA) [mailto:[EMAIL PROTECTED] Sent: Monday, August 06, 2007 1:24 PM To: [email protected] Subject: Re: [WIRELESS-LAN] iPhones, ARP Storms and Network Interruptions ... Frank Bulk - iNAME wrote: Robert: I'm not exactly sure what you're asking in this first question, but let me say that not many wireless clients (that would be network stack specific, I believe) have implemented DNAv4. That Cisco didn't catch this bug during their testing process is unfortunate of course, but not altogether abnormal. Programmers write code all the time that works under normal circumstances, but when something new is introduced, in a way that the programmer didn't expect, bad things can happen, and Cisco is not immune to that. Aruba's opportunistic release this week made it clear that they don't suffer from that bug. Dear Frank: First, I apologize for the tardiness in my response to you, and the list. I have been otherwise indisposed, where access to my E.mail was simply not possible. The point that I was trying to make WRT my first question was: it has come to my attention that Apple has had a running problem with DHCP and DNAv4 implementations. The thread at: http://lists.sans.org/pipermail/unisog/2007-January/027056.html was recently brought to my attention by someone who is familiar with the issue. >From the post, it appears that the issue has been longstanding. What I am having a problem reconciling is that the pronouncements have been that the problem was attributable wholly to CISCO. It appears (at least by the aforementioned URL) that Apple has had a contributory issue. IF this is indeed the case, then the fact that CISCO has issued a patch to combat ARP storms is only likely to satisfy how CISCO's hardware is able to negotiate Apple's issue, and as described. Yes, bad things can/do happen but, it can happen from MULTIPLE directions. I am just trying to understanding if CISCO code, and CISCO code alone is at the bottom of this. As for your second point, no, a single device is unlikely able to generate 11,000 ARP requests/second. What was happening was that the ARP traffic was exiting one WLC onto the wired network, entering another WLC on the same L2 network, and because of the bug, if the client's state had not aged out, was being spit out again on the wired network, after which the packets entered the first controller from the wired network and because of the bug, spit it out again, rinse and repeat. There's no TTL with ARP and the packets not crossing any L3 boundaries, even this packet did have one. So the traffic would keep cycling around until the wireless client's state expired on the second (and third, etc) WLC. Frank Understood.. All my best, Robert. -- ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
