Jumbo-Frames über GRE-Tunnel i.V.m. MPLS möglich?
Hallo,
ich habe hier zwei Standorte, die normalerweise per angemieteter MPLS verbunden sind. Über diesen Transport sind auch Jumbo-Frames möglich, was in einigen VLANs wohl auch genutzt wird.
Jedenfalls soll zum Zwecke der Redundanz zusätzlich ein GRE-Tunnel (Ethernet) über das Internet zwischen den beiden Routern aufgebaut werden, welcher aber natürlich eine deutlich reduzierte MTU hat. Für den Fall, dass da tatsächlich mal der Failover über den GRE-Tunnel aktiv wird, würde das also zu enormen Verbindungsproblemen führen.
Um dieses Problem zu umschiffen habe ich mir nun in den Kopf gesetzt, dass es doch möglich sein müsste mit einem über den GRE-Tunnel laufenden MPLS-Layer notfalls durch Fragmentierung der Pakete eine quasi beliebige MTU- resp. Frame-Größe übertragen zu können.
An beiden Standorten werden Cisco-Router eingesetzt. Anstelle einer direkten Tunnelverbindung zwischen den Routern wird es vielleicht auch einen Linux-Router geben zu dem die GRE-Tunnel aufgebaut werden und der mittels Ethernet-Bridge die Router miteinander verbindet - das sollte dem MPLS aber eigentlich egal sein.
Hat jemand sowas schonmal gebaut und kann bestätigen oder dementieren dass mein Vorhaben damit umsetzbar wäre?
Dass es durch Fragmentierung und derartige Stapelung von Tunnelprotokollen zu Performance-Einbußen kommen wird ist mir durchaus bewusst. Diese Einbußen wird es ohnehin geben, da die Bandbreite per Internet geringer ist als per MPLS. Wichtig ist nur, dass die VLANs alle weiterhin verbunden bleiben.
Danke!
ich habe hier zwei Standorte, die normalerweise per angemieteter MPLS verbunden sind. Über diesen Transport sind auch Jumbo-Frames möglich, was in einigen VLANs wohl auch genutzt wird.
Jedenfalls soll zum Zwecke der Redundanz zusätzlich ein GRE-Tunnel (Ethernet) über das Internet zwischen den beiden Routern aufgebaut werden, welcher aber natürlich eine deutlich reduzierte MTU hat. Für den Fall, dass da tatsächlich mal der Failover über den GRE-Tunnel aktiv wird, würde das also zu enormen Verbindungsproblemen führen.
Um dieses Problem zu umschiffen habe ich mir nun in den Kopf gesetzt, dass es doch möglich sein müsste mit einem über den GRE-Tunnel laufenden MPLS-Layer notfalls durch Fragmentierung der Pakete eine quasi beliebige MTU- resp. Frame-Größe übertragen zu können.
An beiden Standorten werden Cisco-Router eingesetzt. Anstelle einer direkten Tunnelverbindung zwischen den Routern wird es vielleicht auch einen Linux-Router geben zu dem die GRE-Tunnel aufgebaut werden und der mittels Ethernet-Bridge die Router miteinander verbindet - das sollte dem MPLS aber eigentlich egal sein.
Hat jemand sowas schonmal gebaut und kann bestätigen oder dementieren dass mein Vorhaben damit umsetzbar wäre?
Dass es durch Fragmentierung und derartige Stapelung von Tunnelprotokollen zu Performance-Einbußen kommen wird ist mir durchaus bewusst. Diese Einbußen wird es ohnehin geben, da die Bandbreite per Internet geringer ist als per MPLS. Wichtig ist nur, dass die VLANs alle weiterhin verbunden bleiben.
Danke!
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 334670
Url: https://administrator.de/forum/jumbo-frames-ueber-gre-tunnel-i-v-m-mpls-moeglich-334670.html
Ausgedruckt am: 11.05.2025 um 05:05 Uhr
3 Kommentare
Neuester Kommentar
Es wird vermutlich daran scheitern das du MPLS Frames nicht im GRE Tunnel übertragen kannst. MPLS Frames kannst du nur über eine reine MPLS Umgebung vom Anfang zum Ende übertragen. Egal welchen der 3 klassischen MPLS Dienste du benutzt VPLS, Layer 3 VPNs oder VLL.
Es darf keinerlei Medienbruch dazwischen geben also z.B. eine Verbindung die nicht Teil der MPLS Infrastruktur ist. Jeder Knoten im Link muss MPLS fähig sein.
Das ist auch nachvollziehbar, denn die Forwarding Entscheidung kann nur anhand des Labels gemacht werden. Außerdem muss deshalb zwingend noch ein Label Distribution Protokoll dadrunter liegen. (LDP)
Daran wird das vermutlich scheitern.
Ich meine auch das es keine so große Einschränkungen bei der Verbindung geben wird. Normal machen Endgeräte immer eine automatische MTU Discovery üder den gesamten Pfad und erkennen so dynmaisch die max. MTU bzw. einigen sich auf den kleinesten gemeinsamen Nenner im Pfad.
https://de.wikipedia.org/wiki/Path_MTU_Discovery
http://packetlife.net/blog/2008/aug/18/path-mtu-discovery/
Wenn du also parallel mit einem GRE Tunnel arbeitest und dynamischen Routing Protokoll oder floating static Routes, dann kann es allerhöchsten mal zu einem Sessionabbruch kommen beim Reroute auf den redundanten Link der dann durch MTU Discovery mit neuer MTU aufgebaut wird.
Das sollte also einigermaßen glimpflich vonstatten gehen auch mit Jumbo Framing.
Es darf keinerlei Medienbruch dazwischen geben also z.B. eine Verbindung die nicht Teil der MPLS Infrastruktur ist. Jeder Knoten im Link muss MPLS fähig sein.
Das ist auch nachvollziehbar, denn die Forwarding Entscheidung kann nur anhand des Labels gemacht werden. Außerdem muss deshalb zwingend noch ein Label Distribution Protokoll dadrunter liegen. (LDP)
Daran wird das vermutlich scheitern.
Ich meine auch das es keine so große Einschränkungen bei der Verbindung geben wird. Normal machen Endgeräte immer eine automatische MTU Discovery üder den gesamten Pfad und erkennen so dynmaisch die max. MTU bzw. einigen sich auf den kleinesten gemeinsamen Nenner im Pfad.
https://de.wikipedia.org/wiki/Path_MTU_Discovery
http://packetlife.net/blog/2008/aug/18/path-mtu-discovery/
Wenn du also parallel mit einem GRE Tunnel arbeitest und dynamischen Routing Protokoll oder floating static Routes, dann kann es allerhöchsten mal zu einem Sessionabbruch kommen beim Reroute auf den redundanten Link der dann durch MTU Discovery mit neuer MTU aufgebaut wird.
Das sollte also einigermaßen glimpflich vonstatten gehen auch mit Jumbo Framing.
Theoretisch sollte das mit der MTU-Discovery funktionieren - in der Praxis funktioniert das leider nur selten 
Alleine, wenn da noch irgendwo ein IPSsec-Tunnel zwischen ist, funktioniert das quasi garnicht mehr und man muss von Hand die MTUs an mehreren Stellen reduzieren.
Nachdem Cisco jedoch explizit MPLS over GRE als Feature "bewirbt" hatte ich mir gedacht, dass das möglicherweise die Alternative dazu ist.
Laut der Dokumentation ist es wohl auch möglich, für den MPLS-Tunnel eine höhere MTU zu wählen als es der darunterliegende Transport (in dem Fall GRE) zulässt. Nur selbst gemacht habe ich das noch nicht und kann momentan auf den produktiven Systemen natürlich auch schlecht herumexperimentieren.
Hast du (unabhängig von GRE als Transport) gute oder schlechte Erfahrungen mit MPLS und fragmentierten Frames?
Alleine, wenn da noch irgendwo ein IPSsec-Tunnel zwischen ist, funktioniert das quasi garnicht mehr und man muss von Hand die MTUs an mehreren Stellen reduzieren.
Nachdem Cisco jedoch explizit MPLS over GRE als Feature "bewirbt" hatte ich mir gedacht, dass das möglicherweise die Alternative dazu ist.
Laut der Dokumentation ist es wohl auch möglich, für den MPLS-Tunnel eine höhere MTU zu wählen als es der darunterliegende Transport (in dem Fall GRE) zulässt. Nur selbst gemacht habe ich das noch nicht und kann momentan auf den produktiven Systemen natürlich auch schlecht herumexperimentieren.
Hast du (unabhängig von GRE als Transport) gute oder schlechte Erfahrungen mit MPLS und fragmentierten Frames?
Fragmentieren ist generell nicht der Hit weil es den Router belastet aber solange man eine leistungsfähige Plattform hat und das moderat ist kann man das machen.
MPLS over GRE hab ich allerdings in der Praxis auch noch nicht gemacht oder gesehen. Laboraufbau und Proof of Concept wär ja dann ideal. Auf Produktivsystemem ist das ein Risiko wenn du SLAs erfüllen musst.
Wenn ihr Cisco Kunde seit lass dir doch 2 Systeme als Demo schicken und teste das aus.
MPLS over GRE hab ich allerdings in der Praxis auch noch nicht gemacht oder gesehen. Laboraufbau und Proof of Concept wär ja dann ideal. Auf Produktivsystemem ist das ein Risiko wenn du SLAs erfüllen musst.
Wenn ihr Cisco Kunde seit lass dir doch 2 Systeme als Demo schicken und teste das aus.
