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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf