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/.
begin:vcard
fn:Prof. Robert Mathews
n:Mathews;Robert
org:University of Hawai'i
adr:Wentworth Hall, Room# 2, 200 W. Kawili St. (ITO);;415 Nahua St., Ste 814 & 815 (HNL) / ;Honolulu & Hilo;HI;96815/96720;U.S.A
email;internet:[EMAIL PROTECTED]
title:Distinguished Senior Research Scholar on National Security Affairs & U.S. Industrial Preparedness
tel;work:+ 315.853.7853 (NY) / + 703.655.7124 (VA/WDC)
tel;fax:+ 315.859.1998
note;quoted-printable:This visiting card contains two distinct addresses, =
=0D=0A=
one for Honolulu Hi., and the other for Hilo, Hi. =
=0D=0A=
=0D=0A=
If writing to Prof. Mathews is your preference,=0D=0A=
then it must be noted that he can presently =
=0D=0A=
be reached through the following address, =
=0D=0A=
and it is:=0D=0A=
=0D=0A=
119 St. Mary's Avenue,=0D=0A=
Clinton, NY 13323.=0D=0A=
U.S.A
x-mozilla-html:FALSE
url:http://www2.hawaii.edu/~mathews
version:2.1
end:vcard
