On Sat, Jul 07, 2001 at 11:57:34AM +0200, Mikael Abrahamsson wrote:
> On Sat, 7 Jul 2001, Ryan O'Connell wrote:
> > Some Operating Systems (Windows NT 4 seems to be one, although I suspect it was
> > the fault of the driver, not the OS Kernel) actually start the DHCP process
> > before the network card has fully initialised, so you get less than 30 seconds....
>
> Then I believe those implementations are broken. Spanning tree has been
> around forever and this forwarding delay should be known by all
> and implementors should account for them.
It's all too easy to just blame the switch manufacturer though, and it's a long
combination of issues that makes it hard to point at any one person as being at
fault. MS are partly to blame for allowing PDC discovery to start before DHCP
completes, and 3Com for a driver/NIC that blips the port and returns from
startup and thus allows DHCP to start before the card is truely ready to
recieve/transmit data. Also, possibly the switch manufacturer for not disabling
STP on entry-level switches. IIRC, 3Com's low-end (1100 and 3300) switches
have STP disabled by default and some Cisco linecards put all ports in portfast
mode by default.
Network Engineers should be aware of the issues and it's just one of
the many minor irritations caused by deployment of Spanning Tree. There are
fixes (STP Portfast on Cisco, identical but sometimes differently named
settings on other switches) that get round this problem without sacrificing
network stability, particularly when coupled with other features such as BPDU
guard. Many of Cisco's release notes supplied with the switches actually
specifically mention this issue and list "set spantree portfast"/
"set port host"/"spantree portfast" as appropriate to fix the problem.
Most of the NICs I've seen that have this issue are "workgroup" level cards
that vendors are flogging to hub and dumb-STP-transparent-switch users.
Workstation and server-level cards (The ones Compaq use for example, certainly
the ones that support FEC) don't seem to have this problem. I guess the card
itself is more intelligent and starts EtherChannel/Speed/Duplex negotiation
the moment it's switched on, not when the OS loads the drivers.
In my case, Cisco was blamed by MCSEs and others because "it works on the
3Coms at the other office". Actually, it didn't work properly but because the
DHCP server and BDCs were local at that site it failed very infrequently.
-- Ryan O'Connell - <ryan@complicity.co.uk> - http://www.complicity.co.ukI'm not losing my mind, no I'm not changing my lines, I'm just learning new things with the passage of time
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:44 EDT