Re: [Devil-Linux-discuss] VLAN & routing. Poor performance

[Martin H. <ma...@ho...>]

Well, you have 1 physical link, one logical link (VLAN) comes with VLAN =
tagged frames, and the other one comes with ... nothing. So I assume =
that this causes the problem, because the untagged frames have - =
litterally - no idea where to go, but I see it more a bug than as a =
feature that you brought some packets through with this setup (1 VLAN =
and 1 nothing *g*).
=20
to sum it up: having VLAN tagged frames on one physical link you either =
have another tagged VLAN or another untagged VLAN, but you can't have =
another logical link without using VLANs.
=20
read here as a starting point for VLANs:
http://en.wikipedia.org/wiki/Vlan
=20
So I don't see it as a DL or Linux bug, IMO this is a matter of network =
design (even if it is only your DL box and a directly connected PC).
=20
hth, #m
=20
btw: don't use vlan id 1.

________________________________

Von: dev...@li... im Auftrag von =
John Jore
Gesendet: So 12.08.2007 15:00
An: dev...@li...
Betreff: Re: [Devil-Linux-discuss] VLAN & routing. Poor performance



Hi m,

Thank you for taking time to respond to this, not sure if I understand, =
but if you are asking if I've tested with two nics' both in "VLAN mode". =
I had not tested this.

Good point btw. I've now tested this too, and performance is good with =
SMB traffic in this setup.

=20

#4 below would therefore be:

Two NIC's, both in VLAN mode, map/browsing of shares from a machine on =
one side to a machine on the other, speed is good/normal.

=20

Seems to me traffic flows normal when both cards are in the same "mode". =
Not sure why this is? I've searched high and low on google, but could =
not find this issue documented. This leads to me to think it's not a =
common problem, but as "many" (unsubstantiated claim by me) people use =
VLAN's in Linux, could it be a problem with this specific kernel/build =
etc?

=20

=20

JJ

=20

=20

From: dev...@li... =
[mailto:dev...@li...] On Behalf Of =
Martin Hotze
Sent: 12. august 2007 10:33
To: dev...@li...
Subject: AW: [Devil-Linux-discuss] VLAN & routing. Poor performance

=20

=20

and what happens if you use 2 VLANs, both tagged or one tagged and one =
untagged? At least you would do so in the switching world.

=20

#m

=20

________________________________

Von: dev...@li... im Auftrag von =
John Jore
Gesendet: Sa 11.08.2007 21:47
An: dev...@li...
Betreff: [Devil-Linux-discuss] VLAN & routing. Poor performance

Hi!

I've got a VMware VM with 2 NICs, vmxnet/e1000's.  On each side there is =
another VM running Windows. I map and browse a share on one from the =
other, using the DL VM as a router.

=20

1: When both NICs are running in "normal" mode, no VLANs, speed is =
good/normal.

=20

2: When one NIC is running as "normal" and one as a VLAN card, (vmxnet =
and e1000 both support this). Speed is horrible and barely works. I can =
browse the root of the share, but it soon times-out and can't browse the =
share and looses all SMB connectivity with the host. Ping seems to be ok =
though, with both small and large packets.=20

=20

3: Remove/disable one NIC and run all traffic as VLAN traffic over the =
remaining card (router-on-a-stick): Speed is good/normal.

=20

=20

What is going on?!? And why am I seeing this? I'm using version 1.2.13 =
of DL.=20

To repeat myself just in case: When a packet arrives on the normal NIC =
and gets routed to the VLAN'ed NIC and exits DL performance is horrible.

Could there be a problem with the Linux kernel version when doing =
routing from a "non-VLAN'ed" NIC to a "VLAN'ed" NIC? The configuration =
of the nic's themselves can't really be wrong as Ping works, end-to-end. =
I've tried reducing the MTU as some sites have suggested, but did not =
solve anything. Also, I do not think neither vmxnet or e1000 have the =
MTU problem with VLANs.

=20

Anyone have any suggestions?

=20

=20

Regards,

John Jore

=20

=20

=20

PS: The firewall was enabled, but it's not doing much, and it's =
configuration did not change between these three setup's (enabled =
traffic on all interfaces, both vlan's and physical and filtered on IP =
addresses only) I would therefore not blame it in this case.

=20