VLANs trunk mode kommunizieren mit einander

[Hannibal Smith]

Und aktuell geht ein ping von 192.168.10.10 an 192.168.20.21?
Disable am src PC das vlan 20 und versuchs nochmal.
Und du nutzt ping auch schön mit -i <interface> ?
Im Wireshark sieht es aktuell wie aus?

 

[WorkNet]

Und aktuell geht ein ping von 192.168.10.10 an 192.168.20.21?
Disable am src PC das vlan 20 und versuchs nochmal.
Und du nutzt ping auch schön mit -i <interface> ?
Im Wireshark sieht es aktuell wie aus?

Das geht,
wenn ich Vlan20 (PC2) disable kann ich von Vlan10 (PC1) auf Vlan10(PC2) pingen, aber nicht auf Vlan20(PC2). woran kann es liegen?

 

[Ranayna]

Wenn du einfach pingst, dann schaut der Rechner in die Routingtabelle.

Pingst du zB 192.168.20.100 an, schaut er in seine Routing Tabelle. Da hast du drinstehen, dass das Netz 192.168.20.0/24, in dem 192.168.20.100 liegt, ueber das VLAN 20 Interface erreichbar ist. Also nimmt er das auch.
Deaktivierst du das VLAN 20 Interface faellt diese Route weg. Und offensichtlich hast du ueber die 0.0.0.0 default Route keinen Weg in das 192.168.20.0/24 Netz, kannst also nicht mehr pingen.
Das sollte by default fuer allen Netzwerkverkehr gelten, solange der nicht explizit an ein Interface gekoppelt ist.

Ich kenne mich nicht mit Linux aus, aber ich wuerde davon ausgehen, das der -i Parameter, den @Hannibal Smith nennt, dafuer sorgt, das der Ping dazu gezwungen wird ein bestimmtes Interface zu verwenden. Damit sollte ein Ping ins fremde Netz dann nicht moeglich sein.

Ist das denn aktuell immer noch so, das im Wireshark eine unpassende Source IP angezeigt wird?
Woran das liegt kann ich ehrlich gesagt nicht erklaeren.

 

[Hannibal Smith]

Das geht,
wenn ich Vlan20 (PC2) disable kann ich von Vlan10 (PC1) auf Vlan10(PC2) pingen, aber nicht auf Vlan20(PC2). woran kann es liegen?

Das ist doch das richtige Verhalten. Oder was ist das aktuelle Problem?
Wenn du es wieder aktivierst wird wahrscheinlich der cross ping wieder funktionieren. Mit ping -i <interface> erzwingst du den ping durch ein bestimmtes interface. So sollte der crossping nicht gehen.

Schildere doch bitte einfach anhand deiner Beobachtungen und mit Hilfe aller zuvor genannten Tipps dein Problem.

 

[WorkNet]

Das ist doch das richtige Verhalten. Oder was ist das aktuelle Problem?
Wenn du es wieder aktivierst wird wahrscheinlich der cross ping wieder funktionieren. Mit ping -i <interface> erzwingst du den ping durch ein bestimmtes interface. So sollte der crossping nicht gehen.

Schildere doch bitte einfach anhand deiner Beobachtungen und mit Hilfe aller zuvor genannten Tipps dein Problem.

Richtig wäre wenn ich kein Interface deaktiviere. Sprich:
Wenn alles aktiv ist und ich PC1_V20 von PC2_V10 anpinge, kein response zurück kommt:

Ping -I PC1_V10 PC2_V20 sollte KEIN response zurückkommen
Ping -I PC1_V10 PC2_V20 sollte ein response zurückkommen.

Das fonktioniert nur wenn ich PC1_V20 deaktiviere. Das heisst, wenn ich mehrere Vlans auf PC1 hätte, muss ich sie alle deaktiveren, bevor ich andere Vlans auf PC2 anpinge

 

[Ranayna]

Poste mal genau was du fuer Kommandos absetzt und die Antwort die da jeweils kommt.

 

[riversource]

Ist das denn aktuell immer noch so, das im Wireshark eine unpassende Source IP angezeigt wird?

Wireshark hat ja nicht die falsche Source IP angezeigt, sondern er hat ja im Ping Kommando die Source-IP gesetzt. Da die Ziel-IP aber im anderen Subnetz lag, hat der PC aus Ausgangsinterface natürlich das Interface mit der VLAN ID des Ziel-Netzes benutzt, aber mit der im Ping Kommando gesetzten (falschen) Source IP.

Die Antwort des anderen PCs ging natürlich an die im Ping Kommando gesetzte Source-IP, und damit über das andere VLAN zurück. So erklären sich die falschen Quell-IPs auf den VLAN Links.

 

[WorkNet]

Poste mal genau was du fuer Kommandos absetzt und die Antwort die da jeweils kommt.

 

[riversource]

Ich hab das Szenario jetzt mal bei mir nachgebaut, auf einem Raspi und einem PC mit Ubuntu 20.04. Es gibt 2 VLAN Interfaces mit VLAN ID 10 und VLAN ID 20. Das VLAN 10 hat die IPs 192.168.10.10 bzw. 192.168.10.11. Das VLAN 20 hat die IPs 192.168.20.20 bzw. 192.168.20.21.

Zunächst hab ich einen Ping von 192.168.10.10 auf 192.168.10.11 abgesetzt:

Wie erwartet fließen Request und Reply über VLAN 10.

Dann ein Ping von 192.168.20.20 auf 192.168.20.21:

Auch hier alles passend, die Daten fließen über VLAN 20.

Nun ein Ping auf 192.168.20.21, aber mit erzwungener Absenderadresse 192.168.10.10 (ping -I 192.168.10.10 192.168.20.21):

Und es passiert genau das, was oben beschrieben ist: Das Request Paket hat zwar die Absenderadresse 192.168.10.10, aber wird über VLAN 20 an die 192.168.20.21 gesendet. Das ist ja auch richtig, denn die Route für das Zielnetz 192.168.20.0/24 zeigt auf das Interface mit VLAN 20.
Die Antwort (reply) kommt hingegen auf VLAN 10 zurück. Was schon wieder logisch ist, denn die Antwort wird an das Zielnetz 192.168.10.0/24 gesendet, und damit auf dem Interface mit der VLAN ID 10. Die Absenderadresse ist dabei natürlich die Zieladresse des Requests - 192.168.20.21.

Man sieht, alles hatte seine Richtigkeit, von Anfang an.

 

[WorkNet]

Ich hab das Szenario jetzt mal bei mir nachgebaut, auf einem Raspi und einem PC mit Ubuntu 20.04. Es gibt 2 VLAN Interfaces mit VLAN ID 10 und VLAN ID 20. Das VLAN 10 hat die IPs 192.168.10.10 bzw. 192.168.10.11. Das VLAN 20 hat die IPs 192.168.20.20 bzw. 192.168.20.21.

Zunächst hab ich einen Ping von 192.168.10.10 auf 192.168.10.11 abgesetzt:
Anhang anzeigen 1188917
Wie erwartet fließen Request und Reply über VLAN 10.

Dann ein Ping von 192.168.20.20 auf 192.168.20.21:
Anhang anzeigen 1188922
Auch hier alles passend, die Daten fließen über VLAN 20.

Nun ein Ping auf 192.168.20.21, aber mit erzwungener Absenderadresse 192.168.10.10 (ping -I 192.168.10.10 192.168.20.21):
Anhang anzeigen 1188923
Und es passiert genau das, was oben beschrieben ist: Das Request Paket hat zwar die Absenderadresse 192.168.10.10, aber wird über VLAN 20 an die 192.168.20.21 gesendet. Das ist ja auch richtig, denn die Route für das Zielnetz 192.168.20.0/24 zeigt auf das Interface mit VLAN 20.
Die Antwort (reply) kommt hingegen auf VLAN 10 zurück. Was schon wieder logisch ist, denn die Antwort wird an das Zielnetz 192.168.10.0/24 gesendet, und damit auf dem Interface mit der VLAN ID 10. Die Absenderadresse ist dabei natürlich die Zieladresse des Requests - 192.168.20.21.

Man sieht, alles hatte seine Richtigkeit, von Anfang an.

Das ergibt sinn. Dankeeeeee :-)