Hi Bill,
I'm not really sure that was the reason (or not the only one), because it
seems was sorted out after the first day, then the problem reappeared in the
same or different meeting rooms. Of course, it could be possible that it was
depending on what AP your are being associated.
My experience organizing 800 people events and using existing infrastructure
has been always that if I'm not able to take control of all the equipment
(making a backup of the existing configuration, using my own one, and then
restoring the configuration when the event is finished so the original
owners don't complain), then I only use cabling, and pure L2 devices (if
required). At this way, I never got this problem.
In one occasion, last summer, the APs where hanging on a kind of smart AP
switch, which didn't talked IPv6 at all and I was not allowed to replace or
configure in a different way. The solution was easy. We used on additional
L2 switch between the APs and the smart AP-switch to inject IPv6 (only). So
the IPv4 was still coming from the existing infrastructure, but IPv6 was
also provided under our own control.
Regards,
Jordi
De: Bill Fenner <fenner(_at_)research(_dot_)att(_dot_)com>
Responder a: <ietf-bounces(_at_)ietf(_dot_)org>
Fecha: Sat, 25 Mar 2006 15:44:56 -0800
Para: <jordi(_dot_)palet(_at_)consulintel(_dot_)es>
CC: "ietf(_at_)ietf(_dot_)org" <ietf(_at_)ietf(_dot_)org>
Asunto: Re: An absolutely fantastic wireless IETF
I also noticed that IPv6 disappeared from the network and reported it to the
NOC. I think they figured out the problem at least in one of the APs or
whatever it was. I've requested to know the reason but got no information at
the time being.
Jordi,
At the heart of this problem was that we were using the hotel's existing
switch infrastructure, since they already had ports all over the place,
and it also allowed us to use their existing APs as well as our own.
Unbeknownst to us, their switches were configured with the "security"
options, 'switchport block unicast' and 'switchport block multicast'.
The first meant that if the switch forgot a MAC address before the end
device's ARP table did (e.g., because there are lots of MAC addresses
flying around the network at a big meeting), that connectivity between
the two systems would be blackholed. This caused a great deal of trouble
with our monitoring station and also with the printers. The second meant
that the IPv6 ND / RA packets, sent to arbitrary multicast addresses,
were not forwarded since the switch didn't think that the multicast
should go to these ports.
After asking the hotel's provider to remove these restrictions, IPv6
worked again. There were still some isolated incidents which we were
unable to completely debug but could be explained by some lingering
'switchport block' commands.
This was the first time (to my knowledge) that we used a venue's existing
infrastructure so heavily. It certainly taught us a few things.
Bill
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
**********************************************
The IPv6 Portal: http://www.ipv6tf.org
Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com
This electronic message contains information which may be privileged or
confidential. The information is intended to be for the use of the
individual(s) named above. If you are not the intended recipient be aware that
any disclosure, copying, distribution or use of the contents of this
information, including attached files, is prohibited.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf