Link Aggregation bei versch. Layer 1

[dgr243]

Moin zusammen,

ich stelle mir grad die Frage ob und wenn ja wie stabil eine Link Aggregation bei verschiedenen Medien auf Layer 1 funktioniert.

Als Protokoll ist es mir hierbei wurst ob wir PAGP (Cisco proprietär) oder LACP (offen) nehmen.

Hintergrund:

Ich hab 2 Standorte die ich über 2*Gigabit Verbindungen transparent auf Layer 2 (also kein Routing, sondern reines L2 Switching) koppeln will.

Hierbei hab ich als primäre Strecke eine Monomode Glasfaser (1000BaseLX/LH) und als sekundäre Strecke eine dedizierte Richtfunkverbindung.

Naturgemäss werde ich auf der Funkstrecke etwas höhere Laufzeiten haben. Rechnerisch liege ich hier bei sauberer Strecke bei 4ms auf der Funke und bei 1ms auf dem Glas.

Könnte ich hier theoretisch Link Aggregation nutzen?

Hintergrund ist, dass ich auch bei Rapid Spanning Tree eine kurze Umschaltzeit bei Ausfall der Primärstrecke habe. Das würde bei Link Aggregation natürlich wegfallen. Lediglich die Bandbreite würde sich vermindern.

Klar: Klassisch verwendet man Spanning Tree (und Nachfolger) als Layer 2 Redundanz, aber die Überlegung mit Link Aggregation ging mir trotzdem durch den Kopf...

Im LACP Standard hab ich hierzu leider keine Infos gefunden. Zum PAGP wiederrum habe ich gar keine detailierten Protokollinformationen finden können die mir Auskuft über das nötige Timing geben..

Grüße

dgr

[netzwerker]

Wenn die Bandbreite beider Links identisch ist, sehe ich da keine Probleme. Je nach Konfig gehen dann bestimmte "Sessions" immer über die Funkstrecke mit dem höheren Delay.

Mirko

[dgr243]

Die LACP bzw. PAGP Frames sind also nicht latenzsensitiv? Ich könnte -rein theoretisch- also auch über eine ATM oder MPLS Strecke zusammen mit einer Glasstrecke Link Aggregation fahren, solange sich die Bandbreiten nicht unterscheiden?

Dann frage ich mich allerdings, wieso ich nen GE und nen FA zusammen schalten kann .. Das sind ja definitiv unterschiedliche BB :confused:

[netzwerker]

Die LACP bzw. PAGP Frames sind also nicht latenzsensitiv?

Nein. Interessant ist halt die Fehlersuche in solchen Konfigs. Je nach Einstellung der Lastverteilung haben manche Session ein höheres Delay und dadurch möglicherweise einen schlechteren Durchsatz.

Da ist ®STP doch wesentlich deterministischer.

Mirko

[RipperFox]

Ich könnte -rein theoretisch- also auch über eine ATM oder MPLS Strecke zusammen mit einer Glasstrecke Link Aggregation fahren, solange sich die Bandbreiten nicht unterscheiden?

Dann frage ich mich allerdings, wieso ich nen GE und nen FA zusammen schalten kann .. Das sind ja definitiv unterschiedliche BB :confused:

Geht schon:

Ports mit unterschiedlichem Link-Speed kann man bei LACP in Link Aggregation Groups (LAG) unterteilen. Im Normalbetrieb wird die LAG mit der größten Bandbreite genutzt, bei Ausfall die kleinere..

Bei Juniper gabs sowas: Ethernet Link Redundancy Behavior

Aber was genau (Redundanz, Balancing, etc.) und wie genau alles geht kommt auf die Möglichkeiten deiner Switches an..

Grüße Ripper

[dgr243]

Ok denn werd ich das mal testweise aufbauen und gucken.

Allerdings werde ich weiterhin nur eine link-aggregation gruppe haben. Hab ich grad auf nem cat3750 getestet.

eins gigabit sfps mit kupfer bestückt, und zusammen mit einem fa in eine gruppe gesteckt. funzt.

allerdings hab ich hier natürlich keine latenzunterschiede, da beides kabel. bin gespannt wie des mit zwei unterschiedlichen medien tut

[RosaRotesQuarkbällchen]

Hallo dgr243

was hast du denn für eine Funkstrecke? Wie lang, was für eine Kapazität hat sie, welcher Hersteller?

Sind die beiden Standorte direkt über den Funk verbunden oder geht das noch durch ein Netz eines TK Anbieters?

LG RRQ

[RosaRotesQuarkbällchen]

Also,

für eine 4,4 km lange Funkstrecke mit GbE 360 Mbps habe ich ein Delay von 0,2mS gemessen....

[dgr243]

hey rrq,

ist ein direktlink, wird aber von uns als tk carrier betrieben.

Technisch gibt es verschiedene Lösungen die je nach lokalen Gegebenheiten eingesetzt wird. Im konkreten Fall ging es um Ceragon FibeAir, hat sich aber zwischenzeitlich aufgrund Anforderungsänderung eh erledigt. JETZT ist das nur noch technisches Interesse

Die 0.2ms hast du als IP Latenz oder auf welchem layer gemessen?

War es Latenz (oneway) oder RTT (hin und Rück)?

War das ne transparente (Layer 2 transparent) Strecke oder ne L3 Strecke?

Fragen über Fragen

[RosaRotesQuarkbällchen]

soooo, na jetzt gehts ja um meinen Favorite im RF Bereich..

Bei Ceragon kannst du nix falsch machen...

Ceragon ist der derzeitige Leader im Wireless IP Bereich, d.h wir sprechen derzeit über eine Kapazität auf dem air Interface von >800Mbps bei 64Byte Rahmen, bei 1518Byte Rahmen kann Ceragon ca 730Mbps. Das ist möglich über 2 Radio Links ( 1 Antenne + 2 Ausseneinheiten) und 1 Indoor Einheit. Zuführung des GbE über 1 !!! Port, die IDU teilt den Datenstrom selbst auf die beiden Ausseneinheiten auf und setzt sie wieder zusammen. Das ganze wird getopt durch die ACM, adaptives Coding und Modulation. D.h, du hast eine Verfügbarkeit von >99.99%...:uli

Bei entsprechend schlechten Wetter wird die Modulation in der Ausseneinheit runtergefahren ==> weniger Bandbreite aber dafür ist eine Datenübertragung noch möglich, wo andere schon aufhören :D:D

Die Meßwerte sind alle Layer 1 mit einem BER meßgerät gemessen.

Es ist RTT, also Hin und zurück gegen Hardware Loop.

Ob es dann eine L2 oder L3 Strecke wurde, kann ich dir gar nicht sagen, da wir nur L1 ( RiFu) zur Verfügung gestellt haben.

Soooo, und nun kaufen *g*

LG RRQ

[dgr243]

OK Layer 1 gegen Hardwareloop ist klar. Dann wunder ich mich auch nicht über die 0.2ms RTT Die Begrenzung liegt hierbei ja im wesentlichen in den Ausbreitungsbedingungen auf HF Seite

Aber du Missverstehst.. Nicht ich kaufe, sondern wir verkaufen/vermieten die Strecke. MEIN Part beschränkt sich hierbei auf die Switches HINTER der RiFU und LWL Strecke (LWL primär, RiFU Backup). War hier halt kurzzeitig am überlegen ob man statt reine Redundanz via (Rapid) Spanning Tree zu fahren nicht eben auch Link Aggregation nutzen könnte und so Bandbreite UND Redundanz bieten könnte. Hat sich aber wie gesagt wegen etwas geänderter Anforderungen des Kunden schon wieder geändert

Zum RiFU Thema allein könnten wir vermutlich seitenweise Threads füllen. Ist zwar nicht ganz meine Baustelle, aber ich hab mit unseren RiFu Techniker genug zu tun gehabt um verschiedenste PmP und PtP Techniken inkl. deren Vor- und Nachteile zu kennen. Ist ja aber nicht Thema dieses Threads, daher hör ich mal mit dem OT auf xD