15

I am adding a tagged VLAN onto eth0:

#ip link add link eth0 name eth0.20 type vlan id 20

This results in:

#ip link
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
 link/ether 9c:c7:a6:95:65:1c brd ff:ff:ff:ff:ff:ff
....
12: eth0.20@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
 link/ether 9c:c7:a6:95:65:1c brd ff:ff:ff:ff:ff:ff

#ip -d link show eth0.20
70: eth0.20@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether 9c:c7:a6:95:65:1c brd ff:ff:ff:ff:ff:ff
    vlan id 20 <REORDER_HDR>

#cat /proc/net/vlan/config
VLAN Dev name    | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
eth0.234       | 234  | eth0
eth0.20        | 20  | eth0

Now I start dhclient:

#dhclient -d -v -1 eth0.20

What I see in tcpdump is an untagged DHCP discovery frame:

#tcpdump -i eth0 -XX
0x0000:  ffff ffff ffff 9cc7 a695 651c 0800 4500 
                                       ^^^^

Why is it not tagged?

802.1q module seems to be used:

#lsmod | grep 8021q
8021q                  28324  0
garp                   14311  1 8021q

(OS: SLES11SP2 kernel 3.0.13-0.27-default)

BTW other traffic is not tagged either (at least tcpdump doesn't show it)...


Update 16 October
 # tcpdump -Uw - | tcpdump -i eth0 -en -r - &
[1] 7310
 # tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

 # dhclient -d -v -1 eth0.20
Internet Systems Consortium DHCP Client 4.2.3-P2
Copyright 2004-2012 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0.20/9c:c7:a6:95:65:1c
Sending on   LPF/eth0.20/9c:c7:a6:95:65:1c
Sending on   Socket/fallback
DHCPDISCOVER on eth0.20 to 255.255.255.255 port 67 interval 3
reading from file -, link-type EN10MB (Ethernet)
18:49:14.437882 9c:c7:a6:95:65:1c > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 347: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 9c:c7:a6:95:65:1c, length 305
                                                                       ^^^^^^

So, still no tag shown here.

But indeed the transmit counter for eth0.20 in /proc/net/dev does increment when running dhclient...

Marki
  • 2,795
  • 3
  • 27
  • 45

1 Answers1

17

You can't see VLAN tag from tcpdump -i eth0 output on i686/x86_64 architecture because of VLAN acceleration. the VLAN layer will be filtered by kernel so it always looks untagged. Please refer to Bug 498981 - tcpdump cannot deal with 802.1q vlan tag

According to your case, you can get VLAN tags via:

tcpdump -i eth0 -Uw - | tcpdump -en -r - vlan 20

You should see the following output:

<timestamp> <mac-addr-of-eth0> > Broadcast, ethertype 802.1Q (0x8100), length 346: vlan 20, p 0, ethertype IPv4, 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP
shawnzhu
  • 643
  • 4
  • 10
  • You got it wrong. I am talking about Linux *sending* a DHCP discovery. It should be tagged. Either it is not, or the display is wrong. This has nothing to do with the switch the machine is connected to. – Marki Oct 14 '13 at 10:34
  • 1
    @Marki sorry I didn't get your point clearly. here's the updated version after a 20min study via google. [this comment](https://bugzilla.redhat.com/show_bug.cgi?id=498981#c4) is key to your question. – shawnzhu Oct 14 '13 at 14:06
  • Yeah you seem to be right. One should be careful with everything layer 2. One should *additionally* be careful with the DHCP client as it seems to use raw sockets in some cases (so you can't even capture the packets using iptables). And furthermore, when you're using VMware you should not tag the packets in the VM in any case because the vSwitch will reject them, you have to configure a dedicated interface for that VM in that VLAN on the vSwitch. Getting all of this together was not easy... ;-) – Marki Oct 16 '13 at 08:52
  • On the other hand... see my edit above... does not seem to be that easy after all. But anyway my problem is fixed, I can't send tagged packets from within the VM anyway. But for purely physical hosts this might be a problem... – Marki Oct 16 '13 at 09:01