NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
M4100 D12G spinnt?
Hallo!
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.
Warum wird der Tag nicht entfernt?
MfG
Thomas
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.
Warum wird der Tag nicht entfernt?
MfG
Thomas
9 Replies
Hallo!
Ich hab ein bischen herum weiter experimentiert.
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.
MfG
Thomas Belau
Hallo tbelau666 ,
willkommen in der NETGEAR Community.
1. Wie hast du festgestellt, dass die am Rechner A angekommenen Pakete keinen Tag enthalten?
2. Welche PVID hat der Port am M4100, wo der Rechner A angeschlossen ist?
3. Wenn Ports zu einer LAG gehören, dürfen die einzelnen Ports zu einem VLAN nicht gehören. Man weist dem VLAN nur die LAG zu.
Mit freundlichen Grüßen
WojciechKrz
NETGEAR Team- Hallo!
Also die Konfiguration:
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).
Schönes WE
Thomas
NETGEAR Academy
Steigern Sie Ihre Fähigkeiten mit der Netgear Academy - Lassen Sie sich schulen, zertifizieren und bleiben Sie mit der neuesten Netgear-Technologie auf dem neuesten Stand!
Machen Sie mit!
ProSupport for Business
Umfassende Supportpläne für maximale Netzwerkverfügbarkeit und geschäftliche Sicherheit