On Mon, 2005-03-14 at 03:10, Tim Chown wrote: > Indeed; there seems to be some 'smart' Alcatel software that is doing > some ARP/DHCP trickery (at least the APs are Alcatel, so the favourite > for the s/w is the same vendor...). > > Note that my problem all week was getting dis-associated from WLAN a > few times each hour, then seeing a long, if not indefinite, wait to get > a v4 address once re-associated. And when I was associated RTTs to the > default router of commonly >1000ms. Somehow I think that a few of the recommendations from the old "IETF Meeting Network Infrastructure Lore" document (as archived at http://www.ietf.org/meetings/draft-ymbk-termroom.txt) need to be remembered: 2.1 LAN Separation ... There MUST NOT be firewalls, NATs, or other end-to-end breakage between the public LAN(s) and the global internet. Assuming claims about what the 802.11 infrastructure was doing are correct, this provision was ignored and bad things happened. Stateful DHCP lease tracking was clearly causing more trouble than it's worth to the IETF network. 3.13 Advanced Technology While it is tempting for a host/vendor to show off fancy technology at an IETF, this audience runs and uses the most arcane assortment of services, and is a very poor place to find out that your fancy new switch breaks when someone tries to run IPv42 through it. Run a simple production network. If one must run a technology demo, isolate it onto a separate network segment so that it is unable to interfere with the production network. And maybe we need a new entry in: 3.14 Failed Technology Two attempts have been made to use ATM LAN Emulation, aka LANE, as the primary backbone protocol connecting all ethernet switches and routers at IETF meetings. Both attempts were disasters. Some have asserted that IETF traffic patterns are unusually unsuited to LANE. You MUST NOT try to use LANE. For the next couple of meetings, for 802.11b service we should go back to using conventional AP's connected via a conventional switched ethernet to a conventional dhcp server/relay and a conventional router or three. This, at least, would allow the folks running the network to reboot any and all components without forcing clients to reinitialize/rerun DHCP/etc. - Bill _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf