×
We are experiencing an outage of our ReadyCloud service and are working to resolve the issue..
×
Auf Grunde der gegenwärtigen Situation mit dem COVID-19 Coronavirus erwarten wir ein ungewohnt hohes Anrufaufkommen and aus diesem Grund erhöhte Warte- und Antwortzeiten. Wir bitten um Ihr Verständnis während wir durch diesen Prozess arbeiten
×
Geplante Wartung des Community-Systems, Mitte Juli - Beiträge / Antworten werden deaktiviert. Erfahren Sie mehr.
Das Thema wurde wegen der Inaktivität geschlossen. Wir hoffen, Du wirst Dich die Community anschließen, indem Du einen neuen Beitrag in einem geöffnet Post hinzufügen bzw. einen neuen Post erstellen wirst.
Folgende Konstellation: Hinter dem Netgear hängt ein Cisco per Trunk. Am Netgear iat Rechner A, am Cisco Rechner B. Das M4100 ist im Routing Mode für das passende Subnetz und VLAN. Der Port für A steht auf untagged general. Der Port für B ist auch ein Trunk.
Nun die Frage: Wenn ein Paket über den Trunk läuft, wird es getaggt, so weit so korrekt. Es kommt auf B an. Was zurück zu A kommt bleibt aber getaggt. Und das obwohl der Port groß und breit mit U im VLAN ist.
Zunächst: ich habe vergessen zu erwähnen, daß die Verbindung zum Cisco-Switch über ein LAG erfolgte. Das stand sowohl auf trunk als auch auf general. Ordentlich getaggt, alles wie man sich das so denkt. Es funktionierte soweit. die Pakete kamen an, wo sie hin sollten. Der Routing-Mode ist zwar an, aber ungenutzt. Es sind IP-Netze auf VLAN zugewiesen, was prinzipiell erstmal mit dem routing ja nichts zu tun hat.
Aus dem als untagged markierten Port mit meinem beispielhaften Rechner A kamen immer Pakete vom Cisco zurück, die einen 802.1q tag mit dem passenden VLAN enthielten. Völlig unabhängig von der (native/access) PVID oder vom Modus (access, general, trunk).
Mir fiel dann irgendwann mal auf, daß das an den anderen Ports das Ganze ja durchaus funktioniert. Ich habe also einen Port aus dem LAG heraus genommen (natürlich auch auf dem Cisco) und zu einem ganz normalen trunk-Port gemacht. Resultat: Es kommen untagged Pakete auf Rechner A an.
Mein Fazit: Es ist ein Bug in der Firmware (10.0.2.35; mWn die Letzte) der dazu führt, daß die Nutzung von LAG nicht funktioniert. Port einzeln und LAG mit dem Port drin waren völlig identisch konfiguriert. Port einzeln geht, LAG geht nicht. Ergo ist der switch für komplexere Anwendungen, zumindest in heterogenen Umgebungen unbrauchbar.
Interessanter Weise hab ich hier im Forum auch einen Beitrag gesehen, bei dem das Verhalten genau gegensätzlich war.
Am Cisco (SG200) hängt ein Server (A) mit den VLAN 1 und 2 mit 802.1q, 1U, 2T. Da Trunk ist die PVID hier irrelevant. Von dem geht ein Trunk mit VLAN 1U, 2T und 20T auf den Netgear. Da hing ein Desktop (B) am VLAN20 (=PVID). Es ist auf dem Netgear IP - VLAN konfiguriert. Jedes VLAN auf ein Subnetz. Der Rest des Routings war klassisch lokal konfiguriert. Ich hab auf A ein dauer ping an B laufen lassen und mit wireshark kontrolliert, was kommt. Wenn ich auf dem Netgear den Trunk zum Cisco auf einen einzelnen Port am Netgear gelegt habe (auf dem Cisco lief es die ganze Zeit auf einem LAG) und der korrekt als Trunk konfiguriert war, kamen auf B (Port Access, admit untagged only, PVID20 -> der restriktivste, getestete Fall) untagged Pakete. So soll es auch sein. Habe ich dagegen auf dem Netgear den Trunk Port zum Cisco in ein LAG eingebunden, waren alle Pakete an B bei sonst gleicher Konfiguration tagged.
Aber zur Ehrenrettung: weil sehr schnell benutze ich das D12G jetzt als dedizierten Router. Dabei ist mir aufgefallen, daß die Routen-Prios einen etwas unglücklichen default haben. Die statischen VLAN-Routen sollten per default einen höheren Prio-Wert haben, als der gesetzte default-GW. Man sieht nicht auf den ersten Blick, warum der nicht erreichbar ist. Scheinbar wird in diesem Modus die Bridge aufgedröselt (snooping).
1.1. Wenn ein Port mit [T]agged markiert ist, ist seine PVID in jeweiligen VLAN irrelevant.
1.2. Wie ist der Port, wo der Desktop (B) hängt, markiert?
1.3. Ich möchte den Punkt «LAG in einem VLAN» noch einmal erwähnen. Anstatt individueller LAG-Mitglieder soll man nur die LAG selbst zu einem VLAN hinzufügen. Kannst du bestätigen, dass du es so gemacht hast?
Hallo! Erstmal sry für die späte Antwort. Ich hatte keine Zeit, weil ein Kundennetz komplett umkonfiguriert werden mußte. Hat gedrückt.
Zu 1.1: Ich verstehe die Frage nicht. 1.2: Wie ich schon schrieb admit untagged only, PVID20, access 1.3: Ich hab die Angewohnheit nicht als Solche genutzte Ports wieder auf "Werkseinstellung" zu setzen. Natürlich war naturgemäß das LAG konfiguriert. Trunk, 1U, 2T, 20T, admit all. Die Pakete kamen ja auch an.
1.3. Schließe den PC an dem Mini-USB-Port auf der Rückseite des M4100-D12G an.
1.4. Verschiebe den Schieber auf der Rückseite des M4100-D12G auf die Position «USB».
1.5. Verwende das Programm «PuTTy», um sich bei der Kommandozeile anzumelden.
COM > Die genaue COM-Port-Nummer wird im Windows-Geräte-Manager angezeigt. Speed (baud): 115200 Data bits: 8 Stop bits: 1 Parity: None Flow control: XON/XOFF
1.6. In der Kommandozeile führe den Befehl «enable» aus.
1.7. In der Kommandozeile führe den Befehl «show tech-support» aus.
1.8. Speichere den Inhalt der PuTTy-Session als TXT-Datei:
1.3. Schließe den PC an dem Mini-USB-Port auf der Rückseite des M4100-D12G an.
1.4. Verschiebe den Schieber auf der Rückseite des M4100-D12G auf die Position «USB».
1.5. Verwende das Programm «PuTTy», um sich bei der Kommandozeile anzumelden.
COM > Die genaue COM-Port-Nummer wird im Windows-Geräte-Manager angezeigt. Speed (baud): 115200 Data bits: 8 Stop bits: 1 Parity: None Flow control: XON/XOFF
1.6. In der Kommandozeile führe den Befehl «enable» aus.
1.7. In der Kommandozeile führe den Befehl «show tech-support» aus.
1.8. Speichere den Inhalt der PuTTy-Session als TXT-Datei:
