VLAN-Tags werden bei der Paketerfassung (Linux) nicht über tcpdump angezeigt

Ich füge ein getaggtes VLAN zu eth0 hinzu:

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

Das führt zu:

#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

Jetzt starte ich dhclient:

#dhclient -d -v -1 eth0.20

Was ich in tcpdump sehe, ist ein nicht getaggter DHCP-Erkennungsrahmen:

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

Warum ist es nicht markiert?

Das 802.1q-Modul scheint verwendet zu werden:

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

(Betriebssystem: SLES11SP2-Kernel 3.0.13-0.27-Standard)

Übrigens wird auch kein anderer Verkehr markiert (zumindest zeigt tcpdump dies nicht an) ...

Update 16. Oktober

 # 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
                                                                       ^^^^^^

Daher wird hier immer noch kein Tag angezeigt.

Aber in der Tat erhöht sich der Sendezähler für eth0.20 in / proc / net / dev, wenn dhclient ausgeführt wird ...

dhcp linux-networking vlan

— Marki
quelle

kannst du "ip -d link show eth0.20" ausführen?

— Danila Ladner

Klar, ich habe die Info zur Frage hinzugefügt.

— Marki

Sind Sie sicher, dass der Datenverkehr auch ohne VLAN-Tags auf der Leitung angezeigt wird? Es könnte sich einfach um eine libpcap-Eigenheit handeln, für die VLAN-Schnittstellen implementiert sind ip link.

— the-wabbit

okay, auch was sagt "cat / proc / net / vlan / config"?

— Danila Ladner

Ich habe die Frage mit der Konfigurationsausgabe erweitert. Ich werde auch versuchen, außerhalb des Betriebssystems zu erfassen und Sie auf dem Laufenden zu halten.

— Marki

tcpdump -i eth0Aufgrund der VLAN-Beschleunigung wird das VLAN-Tag in der Ausgabe der i686 / x86_64-Architektur nicht angezeigt. Die VLAN-Ebene wird nach Kernel gefiltert, sodass sie immer ohne Tags aussieht. Bitte lesen Sie Bug 498981 - tcpdump kann nicht mit 802.1q vlan-Tags umgehen

Abhängig von Ihrem Fall können Sie VLAN-Tags erhalten über:

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

Sie sollten die folgende Ausgabe sehen:

<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

— shawmzhu
quelle

Du hast es falsch verstanden. Ich spreche von Linux , das eine DHCP-Entdeckung sendet . Es sollte markiert sein. Entweder ist es nicht oder die Anzeige ist falsch. Dies hat nichts mit dem Schalter zu tun, an den die Maschine angeschlossen ist.

— Marki

@ Marki Entschuldigung, ich habe Ihren Standpunkt nicht klar verstanden. Hier ist die aktualisierte Version nach einer 20-minütigen Studie über Google. Dieser Kommentar ist der Schlüssel zu Ihrer Frage.

— Shawmzhu

Ja, du scheinst recht zu haben. Man sollte auf alles aufpassen, was Layer 2 betrifft. Außerdem sollte man auf den DHCP-Client aufpassen, da dieser in einigen Fällen unformatierte Sockets zu verwenden scheint (sodass Sie die Pakete nicht einmal mit iptables erfassen können). Wenn Sie VMware verwenden, sollten Sie die Pakete auf keinen Fall in der VM kennzeichnen, da der vSwitch sie ablehnt. Sie müssen in diesem VLAN auf dem vSwitch eine dedizierte Schnittstelle für diese VM konfigurieren. All dies zusammenzubringen war nicht einfach ... ;-)

— Marki

Andererseits ... siehe meine Bearbeitung oben ... scheint doch nicht so einfach zu sein. Mein Problem ist jedoch behoben. Ich kann ohnehin keine getaggten Pakete von der VM aus senden. Aber für rein physische Hosts könnte dies ein Problem sein ...

— Marki