Heinrich Rebehn wrote:
[EMAIL PROTECTED]@mgEDV.net wrote:
some hints:
- the other switch seems to be cisco, too. (catalyst series, IOS)
- if the trunk contains more lines, check them for physical damage
(maybe 1
fails sometimes, 2 is ok)
- try to setup the cisco-switches for nonegotiate-trunking to your box
- setup the interfaces from autoselect to fixed rates (speed/duplex)
on both
sides (switches, box)
- enable debugging on the switch and read what happens for the ports
(maybe
on/off events)
- check for portfast/CDP settings on the cisco, maybe interferring w.
your
config
- check with a packet-analyzer if the dot1q tags are ok within the
packets
- dump transparently with a bridge before and after your box (network
monitoring port on switch may help you)
- set the NICs on your box to the same interrupts (if possible)
- check for a driver replacement for the marvell card provided by marvell
(if you use it for trunking)
good luck!
Many thanks for the many responses :-) Most of them dealt with sk0 not
being in full duplex mode. When plugged in, sk0 does negotiate full
duplex, though. I also tried using one the the xl interfaces to rule out
a problem with the sk(4) driver, still no luck.
I still have difficulties to believe that this might be a full/half
duplex problem, because things work fine if i use non-dot1q mode (using
a different switch port though)
Anyway, i will be on leave next week, and for the week after, i already
arranged with the admin of the switch to hunt down this bug together.
I will sure report back then.
--Heinrich
So here is my report:
1. Problem is solved :-)
2. The cause was more complicated than duplex mode or driver issues. Let
me try to explain:
The original firewall which i was about to replace, had 4 physical
interfaces. Interfaces 2 and 4 were bridged with a filtering bridge(4).
During my experiments i bypassed the bridge with a cable, so the lans
stayed connected when the firewall was down.
At that time i already realized that id *had* to unplug one of the
interfaces or otherwise i observed the phenomena described in my OP.
Obviously obsd does not like seeing packets with the same MAC on
different interfaces.
In my new setup i replaced the 4 phys. interfaces with a trunk carrying
4 vlans. In order to avoid the problems i left one of the bridged vlans
unconfigured (should have been equivalent to an unplugged cable on the
setup described before).
But it was not! I had to remove one of the vlans from the trunk on the
cisco side for the problems to go away. I am not sure if this is
expected behaviour, but anyway, the setup is running fine now!
--Heinrich
