5
VLAN Tagging 802.1q und Trunking
Wie ist das technisch realisiert auf dem Trunk?
Hallo,
unsere Firma entwickelt gerade einen GigE Switch mit 10GigEWDM Uplinks. Damit sind nicht nur Punkt zu Punkt Verbindungen möglich, sondern auch Ringe mit und ohne Protektion.
Ich habe das besondere Vergnügen, dieses Produkt zu testen.
Der Switch hat 10x 1GigE Ports und zwei 10 GigE Uplink. Ich habe nun eine Punkt-zu-Punkt Verbindung aufgebaut und Port für Port der 10 Ports mit Volllast beschaltet. 9 Ports waren absolut kein Problem, beim 10. Port war keine Volllast auf allen Ports mehr möglich.
Die Erklärung unserer Entwickler war folgende:
Jeder Link benötigt ein eigenes VLAN. Dies wird - wie bei 802.1q üblich - in Form von einer 4 Byte großen Information getagged. Das 10 Gig Signal auf dem Uplink entsteht praktisch durch Aneinanderanhängen der getaggeden 10x 1GigE Paketen (klassisches TDM). Bei Volllast auf allen 10 Ports ergibt sich das Problem, dass die Kapazität nicht mehr ausreicht und es zu Pufferüberläufen mit Paketverlusten kommt.
Da es sich bei dem Switch Prozessor um einen Standard-LAN Switch handelt stellt sich mir die Frage, ob dies ein generelles Problem bei allen LAN-Switchen mit 802.1q ist.
Ist diese Einschränkung grundsätzlich da, sobald man VLAN tagging macht oder ist das ein Designfehler?
Hallo,
unsere Firma entwickelt gerade einen GigE Switch mit 10GigEWDM Uplinks. Damit sind nicht nur Punkt zu Punkt Verbindungen möglich, sondern auch Ringe mit und ohne Protektion.
Ich habe das besondere Vergnügen, dieses Produkt zu testen.
Der Switch hat 10x 1GigE Ports und zwei 10 GigE Uplink. Ich habe nun eine Punkt-zu-Punkt Verbindung aufgebaut und Port für Port der 10 Ports mit Volllast beschaltet. 9 Ports waren absolut kein Problem, beim 10. Port war keine Volllast auf allen Ports mehr möglich.
Die Erklärung unserer Entwickler war folgende:
Jeder Link benötigt ein eigenes VLAN. Dies wird - wie bei 802.1q üblich - in Form von einer 4 Byte großen Information getagged. Das 10 Gig Signal auf dem Uplink entsteht praktisch durch Aneinanderanhängen der getaggeden 10x 1GigE Paketen (klassisches TDM). Bei Volllast auf allen 10 Ports ergibt sich das Problem, dass die Kapazität nicht mehr ausreicht und es zu Pufferüberläufen mit Paketverlusten kommt.
Da es sich bei dem Switch Prozessor um einen Standard-LAN Switch handelt stellt sich mir die Frage, ob dies ein generelles Problem bei allen LAN-Switchen mit 802.1q ist.
Ist diese Einschränkung grundsätzlich da, sobald man VLAN tagging macht oder ist das ein Designfehler?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 116514
Url: https://administrator.de/contentid/116514
Ausgedruckt am: 23.11.2024 um 14:11 Uhr
5 Kommentare
Neuester Kommentar
Laborbedingungen sind Laborbedingungen.
Nicht jeder Port transportiert ständig im realen Betrieb auf Vollast in aller Regel.
Wenn der Uplink Port jedoch bei starker Last der Access Ports in die Knie geht ist das nicht so der Hit, aber merkt eh kaum einer im Normalbetrieb - ausser eventuell der Switch steht in einem Serverrack wo an jedem Port Server hängen die ständig grosse Datenmengen über die Ports pusten. Da wäre es schon bissi doof wenn der Uplink die vollast nicht verkraftet und Pakete verwirft. Man kann ja auch nicht die Oma aus dem Zug schmeissen nur weil der Zug voll ist - um mal ein ganz beklopptes Beispiel zu nennen. Muhahahahahaha.
Was das jetzt mit dem VLAN Tag in Ethernet Frames zu tun haben soll will sich mir jedoch nicht so ganz erschliessen...
Nicht jeder Port transportiert ständig im realen Betrieb auf Vollast in aller Regel.
Wenn der Uplink Port jedoch bei starker Last der Access Ports in die Knie geht ist das nicht so der Hit, aber merkt eh kaum einer im Normalbetrieb - ausser eventuell der Switch steht in einem Serverrack wo an jedem Port Server hängen die ständig grosse Datenmengen über die Ports pusten. Da wäre es schon bissi doof wenn der Uplink die vollast nicht verkraftet und Pakete verwirft. Man kann ja auch nicht die Oma aus dem Zug schmeissen nur weil der Zug voll ist - um mal ein ganz beklopptes Beispiel zu nennen. Muhahahahahaha.
Was das jetzt mit dem VLAN Tag in Ethernet Frames zu tun haben soll will sich mir jedoch nicht so ganz erschliessen...
Es ist eben ein himmelweiter Unterschied zwischen einem LAN/WAN Kunden und einem Carrier-Kunden. Ein Kunde, der aus der LAN Ecke kommt, schluckt dieses Verhalten ohne mit der Wimper zu zucken.Im schlimmsten Fall macht er noch einen RFC 2544 Test und sieht, dass das Produkt bei Volllast durchfällt und sagt sich dann: "Das passiert sowieso nie und wenn es doch passieren sollte, dann müssen das die oberen Layer abkönnen". Im Prinzip ist diese Einstellung aber völlig richtig.
Es gibt aber Kunden im Carrier Umfeld die sich sagen: "Wir haben 10x GigE kauft aber können nur 99% Last verlustfrei transportieren. Das Produkt arbeitet nicht fehlerfrei". Alles schon erlebt, kein Witz.
Um konkrete Zahlen zu nennen: 9x 100% und 1x 98% sind ok, aber dann wird es kritisch.
Wie du bereits gesagt hast - völlig utopisch aber eben trotzdem Bestandteil der RFC 2544 und somit gibt's ein "FAILED" bei 100%.
Das VLAN Tagging ist sehr wohl daran schuld. 10GigE sind genau 10x 1GigE. Kommt dann noch 10x das 4 Byte große VLAN tagging dazu, reicht die Bandbreite bei Volllast nicht mehr aus - trotz aller Toleranzen und der Tatsache, dass GigE asynchron ist.
Es gibt aber Kunden im Carrier Umfeld die sich sagen: "Wir haben 10x GigE kauft aber können nur 99% Last verlustfrei transportieren. Das Produkt arbeitet nicht fehlerfrei". Alles schon erlebt, kein Witz.
Um konkrete Zahlen zu nennen: 9x 100% und 1x 98% sind ok, aber dann wird es kritisch.
Wie du bereits gesagt hast - völlig utopisch aber eben trotzdem Bestandteil der RFC 2544 und somit gibt's ein "FAILED" bei 100%.
Das VLAN Tagging ist sehr wohl daran schuld. 10GigE sind genau 10x 1GigE. Kommt dann noch 10x das 4 Byte große VLAN tagging dazu, reicht die Bandbreite bei Volllast nicht mehr aus - trotz aller Toleranzen und der Tatsache, dass GigE asynchron ist.
Erstmal vorweg zu deiner Information: Du zitierst den falschen IEEE Standard. 802.11 ist Wireless LAN !
Was du meinst ist 802.1q !! Wenn schon dann auch richtig !!
Generell hast du Recht in der Theorie mit deinen Vermutungen denn durch den .1q Tag wird der Frame größer (1522 Byte statt 1518 Byte max), weshalb er auch dann für normale Endgeräte nicht mehr lesbar wird.
Zwei Kardinalsproblem hast du aber nicht erwähnt in deinem Laboraufbau:
1.) Mit welcher Framegröße hast du den Test gemacht auf den untagged Ports ? Dies ist nicht ganz irrelavnt da die IFGs (Inter Frame Gap) bei kleinen Frames (64 Byte) in Summe größer sind als bei großen Frames.
Aus dieser Sicht der variablen IFGs ist eine 100%tige Saturierung nicht möglich auf einem Ethernet Segement bei kleinere Framsizes !
2.) Ist der wichtigste Punkt eigentlich... Wenn du auf den 1 GiG Ports untagged Frames hast und auf dem 10 GiG Port einen tagged Port, dann vergleichst du Äpfel mit Birnen und dein Test an sich ist schon Makulatur bzw. nichtssagend !!
Um vergleichbar zu sein müsstest du auch auf allen 1 GiG Ports mit tagged Frames ankommen und die dann auf dem 10 GiG Port auch tagged rausschicken. Oder...eben utagged auf allen Ports. So wird ein Schuh draus nicht anders, denn das wäre ein fairer Test.
Alles andere ist Unsinn vom Testszenario her.
Das ist ja klar das der Switch wenn du ihn mit untagged Paketen mit 1518 Bytes max. auf den 10 Ports befeuerst auf dem 10GiG Port aber mit tagged rausgehst der Output Overhead größer ist als der Input und der Switch hier Frames droppen muss wenn seine Buffer voll sind.
In der Beziehung haben deine Entwickler also Recht, wenn man den Vergleich von Äpfel und Birnen dann mal übersieht !!
Im Übrigen gilt natürlich auch das was Spaceyfreak sagt. Ein Wirespeed, non blocking Switch sollte aber wenigstens die 100% schaffen wenn alles tagged oder alles untagged ist beim Testen das ist letztlich unbestreitbar !
Was du meinst ist 802.1q !! Wenn schon dann auch richtig !!
Generell hast du Recht in der Theorie mit deinen Vermutungen denn durch den .1q Tag wird der Frame größer (1522 Byte statt 1518 Byte max), weshalb er auch dann für normale Endgeräte nicht mehr lesbar wird.
Zwei Kardinalsproblem hast du aber nicht erwähnt in deinem Laboraufbau:
1.) Mit welcher Framegröße hast du den Test gemacht auf den untagged Ports ? Dies ist nicht ganz irrelavnt da die IFGs (Inter Frame Gap) bei kleinen Frames (64 Byte) in Summe größer sind als bei großen Frames.
Aus dieser Sicht der variablen IFGs ist eine 100%tige Saturierung nicht möglich auf einem Ethernet Segement bei kleinere Framsizes !
2.) Ist der wichtigste Punkt eigentlich... Wenn du auf den 1 GiG Ports untagged Frames hast und auf dem 10 GiG Port einen tagged Port, dann vergleichst du Äpfel mit Birnen und dein Test an sich ist schon Makulatur bzw. nichtssagend !!
Um vergleichbar zu sein müsstest du auch auf allen 1 GiG Ports mit tagged Frames ankommen und die dann auf dem 10 GiG Port auch tagged rausschicken. Oder...eben utagged auf allen Ports. So wird ein Schuh draus nicht anders, denn das wäre ein fairer Test.
Alles andere ist Unsinn vom Testszenario her.
Das ist ja klar das der Switch wenn du ihn mit untagged Paketen mit 1518 Bytes max. auf den 10 Ports befeuerst auf dem 10GiG Port aber mit tagged rausgehst der Output Overhead größer ist als der Input und der Switch hier Frames droppen muss wenn seine Buffer voll sind.
In der Beziehung haben deine Entwickler also Recht, wenn man den Vergleich von Äpfel und Birnen dann mal übersieht !!
Im Übrigen gilt natürlich auch das was Spaceyfreak sagt. Ein Wirespeed, non blocking Switch sollte aber wenigstens die 100% schaffen wenn alles tagged oder alles untagged ist beim Testen das ist letztlich unbestreitbar !
Danke für diese Antwort.
Klar habe ich 802.1q gemeint, ist auch schon korrigiert.
Ich hatte einen Paket Loss bei 128 Byte Frames, bei ~1500 Byte und bei Jumbo Frames. Ich muss das aber nochmals in Ruhe wiederholen und den prozentualen Verlust bei den verschiedenen Framegrößen errechnen .
Der Tipp mit IPG bzw. Rate Adaption hilft aber auf die richtige Spur.
Aber der IPG ist schon prinzipiell schuld an diesem Problem. Inzwischen liegt mir von unserem Engineering ein Whitepaper vor. IEEE sieht für GigE zunächst mal einen Minimum GAP von 12 Bytes vor. Der Absolute Minimum IPG laut IEEE für GigE ist 5 Bytes während er bei 10 GigE bei 8 Bytes liegt.
Für GigE haut das somit noch hin mit VLAN Tagging, aber eben nicht mehr für 10GigE.
Wir werden nun eine Hardware-Modifikation vornehmen und die Toleranzen, die Ethernet vorsieht ausnützen. Üblicherweise ist das clocking +/-30 ppm genau. Die Toleranz liegt bei +/- 100 ppm. Wir werden nun das Clocking für die 10GigE Uplinks hardwareseitig um +70 ppm (dann ist noch etwas Luft nach oben) übertakten und so das Risiko eines Paket Loss minimieren.
Da weiß man erst wieder, was man an SDH hat. Ich möchte aber den Nachteil von SDH in diesem Szenario fairerweise nicht verschweigen: Da wäre nach 8x GigE Schluss mit lustig. Der Rest geht für das SDH framing drauf.
Noch eine Sache zu den VLAN tagging. Dieses Feature ist nötig, weil man mit diesem Produkt Ringe bauen kann und für jeden Port an jeder beliebigen Stelle im Ring Add&Drop hat. Dies dient sozusagen der Zuordnung der Ports.
Ich möchte außerdem noch testen was passiert, wenn man schon getaggten Verkehr in den Switch reinschiebt. Das wird dann Q in Q.
Klar habe ich 802.1q gemeint, ist auch schon korrigiert.
Ich hatte einen Paket Loss bei 128 Byte Frames, bei ~1500 Byte und bei Jumbo Frames. Ich muss das aber nochmals in Ruhe wiederholen und den prozentualen Verlust bei den verschiedenen Framegrößen errechnen .
Der Tipp mit IPG bzw. Rate Adaption hilft aber auf die richtige Spur.
Aber der IPG ist schon prinzipiell schuld an diesem Problem. Inzwischen liegt mir von unserem Engineering ein Whitepaper vor. IEEE sieht für GigE zunächst mal einen Minimum GAP von 12 Bytes vor. Der Absolute Minimum IPG laut IEEE für GigE ist 5 Bytes während er bei 10 GigE bei 8 Bytes liegt.
Für GigE haut das somit noch hin mit VLAN Tagging, aber eben nicht mehr für 10GigE.
Wir werden nun eine Hardware-Modifikation vornehmen und die Toleranzen, die Ethernet vorsieht ausnützen. Üblicherweise ist das clocking +/-30 ppm genau. Die Toleranz liegt bei +/- 100 ppm. Wir werden nun das Clocking für die 10GigE Uplinks hardwareseitig um +70 ppm (dann ist noch etwas Luft nach oben) übertakten und so das Risiko eines Paket Loss minimieren.
Da weiß man erst wieder, was man an SDH hat. Ich möchte aber den Nachteil von SDH in diesem Szenario fairerweise nicht verschweigen: Da wäre nach 8x GigE Schluss mit lustig. Der Rest geht für das SDH framing drauf.
Noch eine Sache zu den VLAN tagging. Dieses Feature ist nötig, weil man mit diesem Produkt Ringe bauen kann und für jeden Port an jeder beliebigen Stelle im Ring Add&Drop hat. Dies dient sozusagen der Zuordnung der Ports.
Ich möchte außerdem noch testen was passiert, wenn man schon getaggten Verkehr in den Switch reinschiebt. Das wird dann Q in Q.
Zum Thema Ethernet und Ringe ist ggf. das noch lesenswert für dich:
Glasfaser Ringnetzwerk mit HP 2626 Switches
Glasfaser Ringnetzwerk mit HP 2626 Switches
