I am so sorry to be a pain in the ass....
On Sun, 25 Mar 2007 20:52:20 +0800
"Sepherosa Ziehau" <[EMAIL PROTECTED]> wrote:
> > 1) I have to 'addm' the VLAN interfaces to the bridge manually
> > (they get added correctly then, this did not work at all before).
>
> Does the addm work now?
Only manually.
>
> > 2) When I try to tcpdump bridge0, I get 'network is down'. I also
> > have to 'up' bridge0 manually.
>
> Do you mean bridge0 is not up if it is configured in rc.conf?
Yes. In rc.conf I have:
ifconfig_bridge0="addm vlan0 addm vlan2 up"
When I do from commandline:
# ifconfig bridge0 addm vlan0 addm vlan2 up
it works. Strange.
> > 3) There are still no packets going through. :-(
>
> Things are a little bit complicated here, so I will need to talk to
> other developers when I have a clear solution, but I have a temporary
> workaround:
> ifconfig xl0 promisc
> ifconfig xl1 promisc
>
Does not help. Let me show you the structure:
HP 2524 #1 --- xl0 (vlan0 ID:11) -- bridge0 -- xl1 (vlan2 ID:11) -- HP2524 #2
The switches can not 'talk' to each other via the bridge.
OTOH:
>From the vlan(4) manpage I get this:
Selecting the Right Network Interface Card to Run VLANs Through
By now, the only NICs that have both hardware support and proper driver
hooks for the 802.1Q VLAN technology in DragonFly are bge(4), em(4),
gx(4), nge(4), re(4), ti(4), and txp(4).
The rest of the ethernet NICs supported by DragonFly can run VLANs using
software emulation in the vlan driver. However, most of them lack the
capability of transmitting and/or receiving oversized frames. Using such
a NIC as a parent interface implies a reduced MTU on the corresponding
vlan interfaces. In the modern Internet, this is likely to cause tcp(4)
connectivity problems due to massive, inadequate icmp(4) filtering that
breaks the Path MTU Discovery mechanism.
The NICs that support oversized frames are as follows:
dc(4) supports long frames for vlan natively.
de(4) requires defining BIG_PACKET in the
/sys/dev/netif/de/if_de.c source file and rebuilding the
kernel. The hack works only for the 21041, 21140, and
21140A chips.
fxp(4) supports long frames for vlan natively.
sis(4) supports long frames for vlan natively.
ste(4) supports long frames for vlan natively.
tl(4) has support for long frames.
tx(4) supports long frames for vlan natively.
xl(4) supports long frames only if the card is built on a newer
chip (Cyclone and above).
Note: Unless marked as having native support for vlan, the above drivers
don't inform the vlan driver about their long frame handling capability.
Just increase the MTU of a vlan interface if it appears to be lower than
1500 bytes after attaching to a parent known to support long frames.
This is from 2001. Is this still appropriate, or should I not think of any HW
issues at all? :-)
--
Gergo Szakal <[EMAIL PROTECTED]>
University Of Szeged, HU
Faculty Of General Medicine
/* Please do not CC me with replies, thank you. */
