VLANs trunk mode kommunizieren mit einander

WorkNet

Cadet 1st Year
Registriert
Feb. 2022
Beiträge
11
Guten Morgen,

ich hoffe jemand könnte bei diesem Problem unterstützen. ich bin am Limit :-)
ich habe 2 Linux Maschinen (PC1 und PC2), die ich an einem managed switch Layer 2 angeschlossen.
Die beiden belegten Ports von dem switch wurden als Trunk Ports mit 2 Vlan IDs 10 und 20 konfiguriert.
Auf PC1 habe ich 2 Virtual sub-interfaces mit dem jeweiligen ID 10 und 20 erstellt und natürlich jedes Interfaces eine IP Adresse zugewiesen
Auf PC2 habe ich 2 Virtual sub-interfaces mit dem jeweiligen ID 10 und 20 erstellt und natürlich jedes Interfaces eine IP Adresse zugewiesen

normalerweise dürfen Vlan10 und Vlan20 bei dieser Konfiguration in beiden Richtungen gar nicht mit einander kommunizieren.
wenn ich ein Ping Request von Vlan10 auf Vlan2 schicke, bekomme ich einen Replay.
Woran kann es liegen?

ich freue mich auf eine Antwort.
Schönes WE
viele Grüsse
Yas
 
Willkommen hier im Forum :)
kannst du uns das genauer beschreiben?
Also wie sieht die config der beiden Linux Kisten aus?
"ip addr" wäre hier der entsprechende command
 
Naja da beide Rechner eine IP im jeweiligen VLAN haben, wird der Ping vermutlich von der entsprechenden Source gesendet.
Pingst du ganz sicher von der Source IP VLAN 10 auf die Destination IP Vlan 20 ?

Falls ja, was ist das Gateway ? Vielleicht wird es dort geroutet ?
 
  • Gefällt mir
Reaktionen: Skysnake, Raijin, paccoderpster und 2 andere
Ich stimme da erst mal @MetalForLive voll zu.

Du hast nach deiner Beschreibung an beiden PCs je ein Sub-Interface in einem VLAN. Dadurch können natürlich beide PCs grundsätzlich über beide VLANs miteinander kommunizieren.
Dann ist die Frage wie der Switch konfiguriert ist und ob es noch andere Netzwerkkomponenten mit VLAN 10 und 20 gibt.
Sind überhaupt am Switch beite VLANs getaggt oder nur 1 von beiden oder gibt es überhaupt ein VID Tag am Switch, nicht, dass der einfach als Accessport konfiguriert ist und einfach alles annimmt und ins gleiche VLAN schmeißt.
 
  • Gefällt mir
Reaktionen: paccoderpster
Guten Tag Zusammen,

vielen Dank für die Unterstützung, das weiss ich zu schätzen.

@Hannibal Smith
Die Vlans habe ich mit NetworkManager erstellt (Siehe bitte Anhang)
Vlan10: 10.10.10.10 (PC1) und 10.10.10.11(PC2)
Vlan 20: 20.20.20.20 (PC1) und 20.20.20.21 (PC2)


@MetalForLive
Es ist ein Layer 2 Switch (Für meine Verständnis wird bei Layer Switch nicht geroutet)

PC1 ist an Port 1 und PC2 an Port 2 angeschlossen

die einzige Konfiguration, die ich in dem switch vorgenommen habe, ist die BEIDEN SwitchPorts (2 und 3) als Trunk ports mit den Tags 10 und 20 konfiguriert.

Linux command :

ping -I 20.20.20.20 10.10.10.11


vielen Dank nochmals für die Hilfe
Gruss
Yas
 

Anhänge

  • Bildschirmfoto_2022-02-11_11-10-58.png
    Bildschirmfoto_2022-02-11_11-10-58.png
    37,1 KB · Aufrufe: 231
  • Bildschirmfoto_2022-02-11_11-10-32.png
    Bildschirmfoto_2022-02-11_11-10-32.png
    38 KB · Aufrufe: 228
Was für ein Switch kommt denn zum Einsatz?
Übrigens sind die IP-Adressen für das 20er Subnetz nicht für den privaten gebrauch vorgesehen. Nachzulesen im RFC 1918 https://datatracker.ietf.org/doc/html/rfc1918

WorkNet schrieb:
Linux command :

ping -I 20.20.20.20 10.10.10.11
Was erhälst du da für ein Ergebnis?
Was kommt bei einem Traceroute für ein Ergebnis?

Grüße
 
  • Gefällt mir
Reaktionen: Raijin und Hannibal Smith
@nosti
Layer 2 Managed Switch Moxa eds-510e
Ich habe es bereits mit 192.168.X.X Adressen ausprobiert und habe das gleiche Verhalten
command:
ping -I 20.20.20.20 10.10.10.11
replay:
64 bytes from 10.10.10.11: icmp_seq=1 ttl=64 time=0.645 ms

command:
traceroute -s 20.20.20.20 10.10.10.11
1 10.10.10.11 (10.10.10.11) 0,413 ms 0,432 ms 0,576 ms

vielen Dank nochmals
 
Dann schau dir doch mal mit tcpdump auf beiden Rechnern an, welche Pakete mit welchen Source- und Destination IPs auf welchen Interfaces hin- und hergehen. Dann wird recht schnell klar, was passiert.

Zwei Theorien:
1. Der SenderPC ist bereits so clever, den Ping aufs richtige Interface zu schicken
2. Der EmpfangsPC hat IP-Forwarding an und antwortet auf die Pings.

Ich tendiere zu 1. Ist aber eher ein Bauchgefühl.
 
  • Gefällt mir
Reaktionen: Raijin und nosti
Den Vorschlag mit dem TCPDump wollte ich auch gerade schreiben. Die Moxa Geräte kenne ich vor allem aus der Industrie, wer weiß obs noch ein paar coole Features gibt :D
Die erste Theorie klingt mir auch plausibel.

WorkNet schrieb:
Ich habe es bereits mit 192.168.X.X Adressen ausprobiert und habe das gleiche Verhalten

Das Verhalten bleibt in deiner Anwendung auch gleich, jedoch sollte man sich trotzdem an die Konvention halten. Irgendwann sucht man ansonsten eine halbe Ewigkeit nach dem Fehler.

Grüße

EDIT:

versuche auch den Traceroute nochmal mit der Option -i
https://www.computerhope.com/unix/utracero.htm
 
Zuletzt bearbeitet:
Schau mal in deine Routing Tabelle. Wie der Befehlt unter Linux ist weiss ich nicht.

Da steht aber garantiert drin, das saemtlicher Traffic in das Netz 20.20.20.0/24 ueber das Interface mit der IP 20.20.20.20 gehen soll. Und fuer das 10.10.10.0/24 Netz natuerlich entsprechend.

Windows macht das jedenfalls automatisch, das direkt benachbarte Netze in die Routingtabelle eingetragen werden, und ich waere ueberrascht wenn Linux das anders handhabt.

Uebrigends: 20.x.x.x sind *keine private Adressen. Bitte nicht verwenden.
 
  • Gefällt mir
Reaktionen: riversource
Ranayna schrieb:
Da steht aber garantiert drin, das saemtlicher Traffic in das Netz 20.20.20.0/24 ueber das Interface mit der IP 20.20.20.20 gehen soll. Und fuer das 10.10.10.0/24 Netz natuerlich entsprechend.
Genau so wird es sein.

Da wird also vermutlich ein Paket mit der Quelladresse 20.20.20.20 über den 10.10.10.x Link an die 10.10.10.11 geschickt. Der PC mit 10.10.10.11 sendet die Antwort an 20.20.20.20 über den 20.20.20.x Link.

Es steht ja nirgendwo, dass für Request und Response die gleiche Leitung benutzt werden muss. Hinweg geht über das eine VLAN, Rückweg über das andere. Da beide PCs in beiden Netzen sind und beide Routen kennen, wird das funktionieren.
 
Guten Morgen Zusammen,

ich habe ja was komisches herausgefunden.
Normalerweise wird in einem Ethernet-Frame der Source Vlan ID eingefügt.
In Wireshark sehe ich den Destination Vlan ID.
Der PC1 bzw. PC2 fügen den falschen ID ein. Das erklärt, warum die Kommunikation zugelassen wird oder?

vielen dank nochmals
lg Yas
wireshark.png
 
riversource schrieb:
Genau so wird es sein.

Da wird also vermutlich ein Paket mit der Quelladresse 20.20.20.20 über den 10.10.10.x Link an die 10.10.10.11 geschickt. Der PC mit 10.10.10.11 sendet die Antwort an 20.20.20.20 über den 20.20.20.x Link.

Es steht ja nirgendwo, dass für Request und Response die gleiche Leitung benutzt werden muss. Hinweg geht über das eine VLAN, Rückweg über das andere. Da beide PCs in beiden Netzen sind und beide Routen kennen, wird das funktionieren.
Default GW wird da das Thema sein.
 
Hallo Zusammen,

vielen Dank für die Unterstützung. ich konnte mittlerweile das Problem lösen.
Die Vlans habe ich mit dem NetworkManager erstellt. die Vlans ID wurden von Networkmanager falsch zugewiesen.
Das könnte man in Wireshark sehen

Schönen Tag noch.
Lg Yass
 
  • Gefällt mir
Reaktionen: Skysnake
Das heißt, du hast nun ein Interface mit VLAN ID 20 und IP-Adresse 10.10.10.10? Ja, kann man so machen. In deinem Szenario mit zwei VLANs auf zwei Rechnern führt das dann dazu, dass die VLAN ID zur Absenderadresse passt. Aber wenn du nun z.B. die 10.10.10.11 anpingst, läuft es auch über VLAN 20. Das passt dann wieder überhaupt nicht.
 
Irgendwie funktioniert es heute nicht mehr.
Ich pinge wieder in allen Richtungen....
Echt frustrierend:-(
 
Ranayna schrieb:
Poste mal bitte die vollstaendige IP Konfiguration und die Routingtabelle des Systems.
Hallo Ranayna,

danke vielmals für die Unterstützung.
Ich habe jetzt 192.168.X.X Adressen verwendet.

Viele Grüsse
Yass


PC1_IPs.png
route.png
 

Anhänge

  • PC2_IPs.png
    PC2_IPs.png
    38,7 KB · Aufrufe: 198
  • Config_PC1.png
    Config_PC1.png
    64,3 KB · Aufrufe: 199
  • Config_PC2.png
    Config_PC2.png
    86,5 KB · Aufrufe: 204
Zurück
Oben