| We have seen problems with ceratin PCs running Windows NT that were
spraying randomly addressed packets in the network that was causing our
DECswitches to behave wierdly.
From what I have heard the problem in the PC is due to an
incorrect Cache setting. The cache setting on the PC should be Write
Through and NOT Write Back. If the cache is setup for Write Back and if
you have Bus Master DMA Adapters (I believe DEFEA is one), the adpater
DMAs garbage out of the Transmit memory and you see the strange packets
on the network. I do not know how you change the cache setting on the
PC, you may have to read the manual or consult an expert.
In the meantime, we have added extra hooks on the DECswitch firmware to
prevent them from being affected by these packets. This will be
available in the next Hub relase due to be out soon. Please note that
with the new firmware, the bridge behaves well but the network
performance is going to stink because of the garbage out there. So it
would be in the best interest to try and prevent the PCs from sending
out the junk. Let us know if the above fix works.
Krishna
|
| An update from the customer...He has been working this with Novell as
well, and they recommended disabling "Status Check Packets."
Apparently, with this enabled, status packets are broadcasted every
second. these have a SNAP type field of 00-00. This somehow has a
negative influence on the ethernet length field, screwing up the whole
data format.
They have disabled this for now, and I will post any results once
I get them.
BTW; they do have a few NT systems on ethernet...they will check the
cache status.
Dave
|
| update;
While monitoring the ring, customer has made the following
observations;
every now and then they detect a pause in traffic, following by
multicast of spanning tree from the EF, then either a mode change,
or the same packet type will continue untill the next pause.
Mode changes consist of three types;
1. Translates into ether2 with packet type of 0.
2. Passes as a SNAP with no traslation directly from FDDI to ethernet.
3. Translates as 802.3 raw.
Another observation, this only seems to occur while running NLSP...
Novells version of OSPF.
If the customer turns off Status Check Packets and or NLSP, things seem
to operate smoothly.
Novell engineering is invloved, I am posting this as an FYI, however,
I understand that the latest release of firmware will make the EF more
robust to this kind of interference.
Dave
|