Physical errors on Shared LAN (w. Cisco FastHub400) & its effects on it?

[ak1871]

Is it really possible, that a defective NIC (Sniffer regognizes physical errors from this card) is can/could interrupt the whole traffic on a shared LAN?

In fact conversations, which do NOT go over the link to this NIC do/could fail?

Even a switch connected to this shared environment hadn't any log entries about these incidents, an increasing statistical counter (e.g. errors) or an down/up of the interface.

We've now removed the NIC and since a few days it seems, that this (also refer below) problem didn't occurred again.

I refer this as an idea/question to my posting (conversation), which I put in the forum Aug, 13 2002 with the title 'Mix of Switches and Hubs' and to which I didn't receive any idea or answer.

Thanks for any input!

[rfroom]

In the 4.5 years of working with Catalyst switches, I have seen this a dozen times or so. Basically if the NIC violates the operation of the network, this problem can happen. Most common senerio is when the NIC loops packets back onto the network or participates in bridging or spanning-tree. The later is more common with dual-homed servers. If the NIC loops back packets into the network, the MAC addresses for that VLAN all get learned off the wrong. However, by just enabling BPDU-guard this problem can be prevented, because BPDU would be looped as well. In addition, avoid IP forwarding/routing or bridging across multiple NICs in the same PC.

To minimize the impact of NIC problems to shared LANs, use the following features:

ErrDisable for excessive link errors

ErrDisable for excessive link flaps

Enable Aggressive UDLD on Interswitch links (may limit problem to single switch)

Broadcast Suppression at 1-2% on all host ports and interswitch connections.

Run STP with Portfast instead of disable STP

Disable trunking and channeling manually to host ports.