Message-ID: <20091113033217.GQ838@cubit>
Date:	Fri, 13 Nov 2009 14:02:17 +1030
From:	Kevin Shanahan <kmshanah@...enchant.net>
To:	netdev@...r.kernel.org
Subject: Problem with VLANs and via-velocity driver

Hi,

I've had some problems with getting a fairly simple (I thought) VLAN
configuration working with the on board Via NICs on my Via M700
board. Looks like as soon as a tagged VLAN interface is added, the
underlying "raw" (untagged) interface stops responding.

E.g. this is my desired setup on eth1:

Untagged VLAN: 10.193.38.0/24
  cubert (Linux 2.6.30.5) - 10.193.38.254
  switch (HP ProCurve)    - 10.193.38.1

Tagged VLAN (101): 10.193.39.192/26
  cubert (Linux)       - 10.193.39.254
  switch (HP ProCurve) - 10.193.39.193

Starting with just eth1 configured, VLAN interfaces are down:

cubert:~# ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 00:40:63:fa:bb:80  
          inet addr:10.193.38.254  Bcast:10.193.38.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4504 errors:0 dropped:0 overruns:0 frame:0
          TX packets:453 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:49136 (47.9 KiB)  TX bytes:21066 (20.5 KiB)
          Interrupt:36 Base address:0xdc00 

cubert:~# ping 10.193.38.1
PING 10.193.38.1 (10.193.38.1) 56(84) bytes of data.
64 bytes from 10.193.38.1: icmp_seq=1 ttl=64 time=0.885 ms
64 bytes from 10.193.38.1: icmp_seq=2 ttl=64 time=0.889 ms
^C
--- 10.193.38.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.885/0.887/0.889/0.002 ms
cubert:~# 

So far so good...

cubert:~# ifup vlan101
Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config
Added VLAN with VID == 101 to IF -:eth1:-
cubert:~# ifconfig vlan101
vlan101   Link encap:Ethernet  HWaddr 00:40:63:fa:bb:80  
          inet addr:10.193.39.254  Bcast:10.193.39.255  Mask:255.255.255.192
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

cubert:~# ping 10.193.39.193
PING 10.193.39.193 (10.193.39.193) 56(84) bytes of data.
64 bytes from 10.193.39.193: icmp_seq=1 ttl=64 time=4.24 ms
64 bytes from 10.193.39.193: icmp_seq=2 ttl=64 time=1.11 ms
^C
--- 10.193.39.193 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.116/2.681/4.247/1.566 ms
cubert:~# 

Also looking good, however:

cubert:~# ping 10.193.38.1
PING 10.193.38.1 (10.193.38.1) 56(84) bytes of data.
^C
--- 10.193.38.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1010ms

And eth1 won't respond again until I take down vlan101 and eth1 and
bring eth1 back up again.

cubert:~# ifdown vlan101
Removed VLAN -:vlan101:-
cubert:~# ping 10.193.38.1
PING 10.193.38.1 (10.193.38.1) 56(84) bytes of data.
^C
--- 10.193.38.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1011ms

cubert:~# ifdown eth1
cubert:~# ifup eth1
cubert:~# ping 10.193.38.1
PING 10.193.38.1 (10.193.38.1) 56(84) bytes of data.
64 bytes from 10.193.38.1: icmp_seq=1 ttl=64 time=0.869 ms
64 bytes from 10.193.38.1: icmp_seq=2 ttl=64 time=0.947 ms
^C
--- 10.193.38.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1003ms
rtt min/avg/max/mdev = 0.869/0.908/0.947/0.039 ms

Here is my configuration in /etc/network/interfaces (Debian/Lenny):

iface eth1 inet static
	address 10.193.38.254
	netmask 255.255.255.0
	broadcast 10.193.38.255
	network 10.193.38.0

iface vlan101 inet static
	address 10.193.39.254
	netmask 255.255.255.192
	broadcast 10.193.39.255
	network 10.193.39.192
	vlan_raw_device eth1

A bit of searching found a few references to similar problems going
back a few years (2005, 2007). Sounded like there were some driver
issues, but it wasn't clear from the messages I found whether they
were believed to be fixed or not. I tried the same test using a
differnt NIC with the tg3 driver and there were no problems, so it
looks to me like it's still a via-velocity issue. Unfortunately I
don't have room to add NICs to this machine and need to use the on
board Via hardware.

This is the network hardware on the non-working Via board:

cubert:~# lspci -k
...
02:00.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 Gigabit Ethernet Adapter (rev 82)
	Kernel driver in use: via-velocity
03:00.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 Gigabit Ethernet Adapter (rev 82)
	Kernel driver in use: via-velocity

And on my laptop where this same config does work:

kulgan:~# lspci -k
...
09:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5752 Gigabit Ethernet PCI Express (rev 02)
	Subsystem: Dell Device 01d6
	Kernel driver in use: tg3

I understand that it's not best practice to combine tagged and
untagged frames on the same link (something to do with VLAN hopping
attacks), so perhaps this is not a priority to fix. However, I'm happy
to test patches if there are any.

Regards,
Kevin Shanahan.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists