Auf dieser Seite
Das Wichtigste
- Beide Richtungen dokumentierenGefilterte Zustellung und Rückweg müssen zum gewählten Routing- und Schutzmodell passen.
- Die gelieferte MTU verwendenKapselung und Backup-Pfade können unterschiedliche Werte verlangen.
- Weiterleitung und Wiederherstellung nachweisenEine aufgebaute Routing-Sitzung allein beweist nicht, dass nutzbarer Verkehr den Dienst erreicht.
Die Schnittstellenvereinbarung vor der Aktivierung festhalten
An der Übergabe liefert ein Team Verkehr und ein anderes übernimmt die Verantwortung. Dokumentieren Sie öffentliche Tunnelendpunkte oder physische Schnittstelle, innere Adressierung, gegebenenfalls VLAN, Adressfamilien, Routingnachbarn, freigegebene Präfixe und MTU. Zeigen Sie normalen, geschützten und rücklaufenden Verkehr in derselben Zeichnung, damit kein fehlender Schritt stillschweigend dem anderen Team zugerechnet wird.
Benennen Sie Verantwortliche für Schnittstelle, BGP-Richtlinie, Filterregeln und Zieldienst. Vereinbaren Sie Änderungsfenster, Nachweise beider Seiten und einen Kontakt zur Wiederherstellung. Das Übergabeprotokoll muss äußeren Tunnelausfall, falsche innere Route und eine nicht antwortende Anwendung unterscheiden können.
| Punkt | Explizit dokumentieren | Bei der Abnahme prüfen |
|---|---|---|
| Kapselung oder physischer Zugang | Tatsächlicher Endpunkt, Protokoll, Schnittstelle oder VLAN und Adressfamilie. | Der gewählte Pfad besteht und ist über das vorgesehene Trägernetz erreichbar. |
| Inneres Routing | Lokale und Nachbaradressen, ASN, erlaubte Ankündigungen und empfangene Routen. | Erwartete Präfixe und Rückrouten sind nutzbar, nicht nur konfiguriert. |
| Paketgröße | Gelieferte MTU jedes Pfads und erwartetes Erkennungsverfahren. | Kleine und größere legitime Übertragungen funktionieren. |
| Wiederherstellung | Bevorzugter Pfad, Backup-Regeln, Konvergenzkriterien und Rücknahmeverantwortlicher. | Verkehr nutzt nach dem vereinbarten Ausfall einen funktionierenden Pfad und kehrt wie vorgesehen zurück. |
MTU als Eigenschaft des vollständigen Pfads behandeln
Kapselung verbraucht einen Teil des äußeren Paketbudgets. In einem einfachen Beispiel bleiben bei 1.500 Byte äußerer IPv4-MTU nach 20 Byte äußerem IPv4-Header und 4 Byte einfachem GRE-Header 1.476 Byte für das innere Paket. GRE-Optionen, weitere Tunnel oder eine kleinere MTU im Trägernetz können das ändern. Dieser Rechenwert gehört nicht pauschal in jede GRE-Schnittstelle.
Verwenden Sie für jeden Tunnel die MTU aus seinem tatsächlichen Übergabeprotokoll. Primär- und Backup-Pfad können unterschiedliche Einstellungen brauchen. Ein gelieferter Wert von 1.452 auf einem Pfad darf nicht durch 1.476 ersetzt werden, nur weil ein anderer Pfad diesen Wert nutzt. Prüfen Sie vor der Größeninterpretation, welche Paketschicht die Schnittstelle oder Aufzeichnung zeigt.
Auch Path-MTU-Erkennung und Transportverhalten zählen. Ein erfolgreicher kleiner Ping beweist keine funktionierenden größeren TCP- oder UDP-Übertragungen. Eine TCP-MSS-Anpassung betrifft nur die TCP-Segmentgröße und löst nicht jedes UDP- oder Kapselungsproblem. Erhalten Sie die vom gewählten Erkennungsverfahren benötigten Kontrollmeldungen gemäß der vereinbarten Sicherheitsrichtlinie.
Reale kleine und große Übertragungen prüfen
Wählen Sie zum Dienst passende Tests. Prüfen Sie Verbindungsaufbau und eine sinnvolle Anwendungsaktion, anschließend eine größere Übertragung oder repräsentativen Datagrammaustausch. Wiederholen Sie dies für die vereinbarten Richtungen und Adressfamilien. Erfassen Sie Größen, Beobachtungspunkte, Zeitüberschreitungen und Zähler, statt nur „erreichbar“ zu notieren.
TCP-Durchsatz hängt neben der verfügbaren Leitung auch von Umlaufzeit, Verlusten, Empfängergrenzen und anderem Transportverhalten ab. Ziel ist die Eingrenzung eines Problems, nicht jede langsame Übertragung der Filterung zuzuschreiben. Nutzen Sie Anwendungsreferenz und Transportmessungen gemeinsam; ressourcensättigende Tests bleiben in einer freigegebenen isolierten Umgebung.
BGP-Zustand und nutzbare Weiterleitung unterscheiden
Eine BGP-Sitzung kann Established sein, obwohl nötige Routen fehlen, durch Richtlinien abgelehnt werden oder weniger bevorzugt sind. Prüfen Sie gesendete und empfangene Routen, akzeptierte Präfixe, gewählte nächste Hops und resultierende Weiterleitungseinträge. Benötigt der Kunde eine Standardroute, muss ausdrücklich feststehen, ob sie per BGP oder auf einem anderen vereinbarten Weg bereitgestellt wird.
Prüfen Sie auch den Rückweg. Eine veraltete statische Route oder ein ungeeigneter zustandsabhängiger Pfad kann ein Backup fehlerhaft erscheinen lassen, obwohl BGP funktioniert. Beachten Sie außerdem die Präfixlänge: Eine weniger spezifische Backup-Route übernimmt keinen Verkehr, der weiterhin einer spezifischeren installierten Route folgt. Untersuchen Sie die tatsächliche Routenauswahl vor Änderungen an Präferenzen.
Den Ausfall festlegen, den das Backup abdecken soll
Lassen Sie vereinbarte Standby-Tunnel und Routing-Sitzungen aktiviert, wenn sie automatische Wiederherstellung ermöglichen sollen. Die Präferenz im Normalbetrieb und die Eignung als Backup sind getrennte Fragen. Beide Enden brauchen kompatible Regeln; das bloße Vorhandensein einer Backup-Sitzung dokumentiert noch keine Präferenz der empfangenen Routen.
Erproben Sie das vereinbarte Szenario mit den Produktionsverantwortlichen: Sitzungsverlust, Tunnelausfall und Routerausfall sind nicht dasselbe. Zwei Tunnel auf einem Router belegen keine Routerredundanz. Erfassen Sie Weiterleitungsverluste, Anwendungsverhalten, Routenauswahl und Rückkehr. Versprechen Sie keinen verlustfreien Wechsel aufgrund eines Tests, der nur Erreichbarkeit gezeigt hat.
Beide Enden und den Wiederherstellungszeitraum korrelieren
Verwenden Sie ein gemeinsames Beobachtungsfenster und benennen Sie die Richtung jedes Zählers. Vergleichen Sie Sender, Tunnel- oder Übergabeschnittstelle, Empfangsschnittstelle, Filter und Zielanwendung. Notieren Sie, wann das Routing wechselte und wann der Dienst wieder nutzbar war. Ein am Ausgang gesehenes Paket belegt nicht die Ankunft am nächsten Bauteil; bewahren Sie genügend Nachweise zur Eingrenzung der Lücke auf.
Prüfen Sie nach Wiederherstellung des bevorzugten Pfads dessen Auswahl, die weitere Verfügbarkeit des Backups und das geforderte Verhalten bestehender Anwendungen. Kontrollieren Sie auch die Überwachung: Der Collector kann zu einem anderen Zeitpunkt als die Weiterleitung zurückgekehrt sein. Bewahren Sie endgültige Konfiguration und Abnahmeergebnisse beim Übergabeprotokoll auf.
Ein kompaktes Übergabe- und Abnahmeprotokoll
Dies sind Abnahmeaufgaben, keine Erlaubnis, einen laufenden Dienst ohne Abstimmung zu unterbrechen. Trennen Sie eingreifende Tests von Routinekontrollen und definieren Sie vorher Abbruchkriterien. Das Ergebnis soll die tatsächliche Übergabe reproduzierbar dokumentieren, nicht pauschal ein vollständig validiertes Netz behaupten.
Den Dienst identifizieren
Schnittstellen, Verantwortliche, freigegebene Präfixe und versionierte Konfiguration erfassen.
Normale Weiterleitung prüfen
Empfangene Routen, gewählte nächste Hops, beide Richtungen und Anwendungserfolg kontrollieren.
Paketgrößen prüfen
Je Pfad die gelieferte MTU sowie repräsentative kleine und große Übertragungen verwenden.
Ausfall und Wiederherstellung dokumentieren
Vereinbarten Ausfall, Konvergenzbeobachtungen, verbleibende Grenzen und Ergebnis der Rücknahme festhalten.
Fragen zur Übergabe
Kann ich für jeden GRE-Tunnel dieselbe MTU verwenden?
Nein. Verwenden Sie den gelieferten Wert des vollständigen Pfads. Zusätzliche Kapselung oder ein anderes Trägernetz kann die verfügbare innere MTU ändern.
Beweist eine Established-BGP-Sitzung ein funktionierendes Backup?
Nein. Prüfen Sie akzeptierte und gewählte Routen, Weiterleitung, Rückweg und Anwendungsverhalten im vereinbarten Ausfallszenario.
Was gehört in den abschließenden Abnahmebericht?
Tatsächliche Konfiguration und Verantwortliche, Ergebnisse des Normalbetriebs, Paketgrößenprüfungen, beobachteter Ausfall und Wiederanlauf sowie ausdrücklich ungeprüfte Bedingungen.
