Well, I have recent experience of the problem. That's why I mentioned it. We did do a LAN reconfiguration at the office. We added a dozen Cisco catalyst switches to get rid of the cable spaghetti we had between racks. After the reconfiguration I was going to boot some of our Alphas and VAXen - which were now connected to the Catalyst switches - from the Infoserver. Earlier there was no problems at all, but now the boot didn't work at all. As there were no other changes made, I suspected the Catalysts. When monitoring what happened during the boot I found out that when the Ethernet adapter resets the link, the Catalyst starts the spanning tree listening period and blocks all traffic to and from the port until the listening period has ended. Unfortunately that seems to be too long a time for the protocol and the boot never continues. This was verified on other Catalysts as well. The solution is to disable spanning tree on the port where a booting node is connected. Then the booting problem is gone. I think it is an overkill from Cisco to implement spanning tree on every possible switch port. I can understand the point, though, because there are too many LAN users nowadays which don't have a clue of what is happening in the LAN. Regards, Kari On 15.11.2013 17:20, Paul_Koning at Dell.com wrote: On Nov 15, 2013, at 8:21 AM, Kari Uusim ki <uusimaki at exdecfinland.org> wrote: If you connect the MicroVAX ethernet port to a Cisco switch port, check that the Cisco switch port has spanning tree _disabled_ MOP booting and other low level protocols don't cope well with the spanning tree listening period the switch will enforce when the link is reset. That's hard to believe. Certainly MOP should deal just fine, unless someone implemented it very badly. Ditto any other DEC protocol. After all, DEC invented the spanning tree algorithm, so handling its implications was just elementary network algorithm design for all of us. paul .