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@xxxxxxxxxxxxxxxx> > Responder a: <ietf-bounces@xxxxxxxx> > Fecha: Sat, 25 Mar 2006 15:44:56 -0800 > Para: <jordi.palet@xxxxxxxxxxxxxx> > CC: "ietf@xxxxxxxx" <ietf@xxxxxxxx> > 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@xxxxxxxx > 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf