Vi upplever för tillfället längre svarstider än vanligt på grund av en ovanligt hög arbetsbelastning.
Vårt team arbetar med full intensitet för att effektivt hantera denna situation och minska väntetiderna.
Vi ber om er förståelse och tålamod under denna period och strävar efter att återgå till normala svarstider så snabbt som möjligt.

Skillnader i hantering av VLAN i kombination med bridge i Linux

Efter mycket huvudkliande har jag märkt att det finns en skillnad i hur 802.1q VLAN fungerar i kombination med bryggor i Linux mellan olika kernelversioner och/eller drivrutiner.

Scenario #1, Ubuntu 8.04.4 LTS:

root@ubuntu8:~# uname -a
Linux ubuntu8 2.6.24-26-server #1 SMP Tue Dec 1 18:26:43 UTC 2009 x86_64 GNU/Linux
    
root@ubuntu8:~# ethtool -i eth0
driver: tg3
version: 3.86
firmware-version: 5721-v3.61, ASFIPMI v6.21
bus-info: 0000:03:00.0

I första scenariot ville jag använda en bridge som raw-interface för VLAN, eftersom bridgen kör STP (Spanning Tree Protocol). Det fungerade inte. Efter lite sniffande kunde jag se att trafiken skickades ut taggad på rätt VLAN, men att VLAN-taggen på inkommande trafik ignorerades och trafiken såg ut att vara otaggad.

Enda sättet att få VLAN-trafiken att fungera var att använda de fysiska interfacen (eth0 och eth1) som raw-interface för VLAN-interfacen.

Scenario #2, Ubuntu 10.04.2 LTS:

root@ubuntu10:~# uname -a
Linux ubuntu10 2.6.32-31-generic #61-Ubuntu SMP Fri Apr 8 18:24:35 UTC 2011 i686 GNU/Linux
    
root@ubuntu10:~# ethtool -i eth2
driver: e100
version: 3.5.24-k2-NAPI
firmware-version: N/A
bus-info: 0000:01:01.0

I andra scenariot råkade mitt raw-interface redan vara med i en bridge tillsammans med ett tap-interface för openvpn. Vis av erfarenhet från tidigare problem försökte jag använda eth2 som raw-interface för mitt VLAN. Det fungerade inte.

Om jag sniffade trafiken på raw-interfacet så jag att både utgående och inkommande trafik var taggad, men de taggade svaren kom ändå inte in på VLAN-interfacet.

Här var jag tvungen att använda bryggan som raw-interface.