|
Posted by Bill Grant on April 9, 2008, 3:02 am
Please log in for more thread options
Thanks for the feedback.
>>
>>> The adapters do NOT connect to the same switch.
>>>
>>> Adapter one is configured for 192.168.231.0/24. Adapter one is the
>>> host's connection to a firewall (direct connection).
>>>
>>> Adapter two is configured for 10.0.54.0/24. Adapter two is the host's
>>> connection to a tape library.
>>>
>>> Host is NOT configured to route.
>>>
>>> Could this be a device driver defect in the drivers for either of the
>>> adapters?
>>>
>>> --
>>> Will
>>>
>>>
>>
>> I really have no idea what might cause it. Sorry, I have never seen
>> that happen.
>
> Looks like I have stumbled on some really strange misfeature of one of the
> drivers or of Windows itself.
>
> I traced the problem down and it's a really bizarre one. We started out
> with a four port Intel adapter, and added to the Windows 2003 server a six
> port Silicom adapter. Someone migrated a subnet off the four port Intel
> to the Silicom.
>
> Fine so far but they forgot to deassign the IP address on the Intel, but
> they to further complicate matters they unselected Internet Protocol
> (TCP/IP) in the list of Network Connection items for the Intel adapter.
> The Intel adapter is also being used as a bridging port for VMWare, so the
> Intel adapter was in a very indeterminate state:
>
> - adapter as enabled
> - IP was assigned to a static IP in an overlapping subnet
> - IP was deactivated
> - port was being used for VMWare bridging on a different subnet
>
> With the card in that weird state, some of the traffic started to bridge
> across the two adapters and merge with VMWare traffic on virtual adapters
> bridged to some of the same ports. After fixing up the misassigned IP,
> most of the bridging stopped. I still notice some abnormalities, such as
> Intel adapters that identify themselves through Arp in Wireshark as being
> Silicom Mac addresses. But the catastrophic crossing of traffic across
> adapters looks like it is cured.
>
> --
> Will
>
>
>
|