6. BGP Error Handling (BGP-Fehlerbehandlung)

6. BGP Error Handling (BGP-Fehlerbehandlung)

   Dieser Abschnitt beschreibt Aktionen, die ergriffen werden müssen, wenn Fehler während der Verarbeitung von BGP-Nachrichten erkannt werden.

   Wenn eine der hier beschriebenen Bedingungen erkannt wird, wird eine NOTIFICATION-Nachricht mit dem angegebenen Error Code, Error Subcode und Data-Feldern gesendet, und die BGP-Verbindung wird geschlossen (es sei denn, es wird explizit angegeben, dass keine NOTIFICATION-Nachricht gesendet werden soll und die BGP-Verbindung nicht geschlossen werden soll). Wenn kein Error Subcode angegeben ist, dann muss (MUST) Null verwendet werden.

   Der Ausdruck "die BGP-Verbindung wird geschlossen" bedeutet, dass die TCP-Verbindung geschlossen wurde, die zugehörige Adj-RIB-In gelöscht wurde und alle Ressourcen für diese BGP-Verbindung freigegeben wurden. Einträge im Loc-RIB, die mit dem entfernten Peer verbunden sind, werden als ungültig markiert. Das lokale System berechnet seine besten Routen für die Ziele der als ungültig markierten Routen neu. Bevor die ungültigen Routen aus dem System gelöscht werden, kündigt es seinen Peers entweder Rückzüge für die als ungültig markierten Routen oder die neuen besten Routen an, bevor die ungültigen Routen aus dem System gelöscht werden.

   Sofern nicht explizit angegeben, ist das Data-Feld der NOTIFICATION-Nachricht, die gesendet wird, um einen Fehler anzuzeigen, leer.

6.1. Message Header Error Handling (Nachrichtenkopf-Fehlerbehandlung)

Alle Fehler, die während der Verarbeitung des Message Headers erkannt werden, müssen (MUST) durch Senden der NOTIFICATION-Nachricht mit dem Error Code Message Header Error angezeigt werden. Der Error Subcode erläutert die spezifische Natur des Fehlers.

Der erwartete Wert des Marker-Felds des Nachrichtenkopfs ist alle Einsen. Wenn das Marker-Feld des Nachrichtenkopfs nicht wie erwartet ist, dann ist ein Synchronisierungsfehler aufgetreten, und der Error Subcode muss (MUST) auf Connection Not Synchronized gesetzt werden.

Wenn mindestens eine der folgenden Bedingungen wahr ist:

• wenn das Length-Feld des Nachrichtenkopfs kleiner als 19 oder größer als 4096 ist, oder

• wenn das Length-Feld einer OPEN-Nachricht kleiner als die Mindestlänge der OPEN-Nachricht ist, oder

• wenn das Length-Feld einer UPDATE-Nachricht kleiner als die Mindestlänge der UPDATE-Nachricht ist, oder

• wenn das Length-Feld einer KEEPALIVE-Nachricht nicht gleich 19 ist, oder

• wenn das Length-Feld einer NOTIFICATION-Nachricht kleiner als die Mindestlänge der NOTIFICATION-Nachricht ist,

dann muss (MUST) der Error Subcode auf Bad Message Length gesetzt werden. Das Data-Feld muss (MUST) das fehlerhafte Length-Feld enthalten.

Wenn das Type-Feld des Nachrichtenkopfs nicht erkannt wird, dann muss (MUST) der Error Subcode auf Bad Message Type gesetzt werden. Das Data-Feld muss (MUST) das fehlerhafte Type-Feld enthalten.

6.2. OPEN Message Error Handling (OPEN-Nachricht-Fehlerbehandlung)

Alle Fehler, die während der Verarbeitung der OPEN-Nachricht erkannt werden, müssen (MUST) durch Senden der NOTIFICATION-Nachricht mit dem Error Code OPEN Message Error angezeigt werden. Der Error Subcode erläutert die spezifische Natur des Fehlers.

Wenn die Versionsnummer im Version-Feld der empfangenen OPEN-Nachricht nicht unterstützt wird, dann muss (MUST) der Error Subcode auf Unsupported Version Number gesetzt werden. Das Data-Feld ist eine vorzeichenlose 2-Oktett-Ganzzahl, die die größte, lokal unterstützte Versionsnummer angibt, die kleiner ist als die vom entfernten BGP-Peer gebotene Version (wie in der empfangenen OPEN-Nachricht angegeben), oder wenn die kleinste, lokal unterstützte Versionsnummer größer ist als die vom entfernten BGP-Peer gebotene Version, dann die kleinste, lokal unterstützte Versionsnummer.

Wenn das Autonomous System-Feld der OPEN-Nachricht nicht akzeptabel ist, dann muss (MUST) der Error Subcode auf Bad Peer AS gesetzt werden. Die Bestimmung akzeptabler Autonomous System-Nummern liegt außerhalb des Umfangs dieses Protokolls.

Wenn das Hold Time-Feld der OPEN-Nachricht nicht akzeptabel ist, dann muss (MUST) der Error Subcode auf Unacceptable Hold Time gesetzt werden. Eine Implementierung muss (MUST) Hold Time-Werte von einer oder zwei Sekunden ablehnen. Eine Implementierung kann (MAY) jede vorgeschlagene Hold Time ablehnen. Eine Implementierung, die eine Hold Time akzeptiert, muss (MUST) den ausgehandelten Wert für die Hold Time verwenden.

Wenn das BGP Identifier-Feld der OPEN-Nachricht syntaktisch falsch ist, dann muss (MUST) der Error Subcode auf Bad BGP Identifier gesetzt werden. Syntaktische Korrektheit bedeutet, dass das BGP Identifier-Feld eine gültige Unicast-IP-Hostadresse darstellt.

Wenn einer der optionalen Parameter in der OPEN-Nachricht nicht erkannt wird, dann muss (MUST) der Error Subcode auf Unsupported Optional Parameters gesetzt werden.

Wenn einer der optionalen Parameter in der OPEN-Nachricht erkannt wird, aber fehlerhaft ist, dann muss (MUST) der Error Subcode auf 0 (Unspecific) gesetzt werden.

6.3. UPDATE Message Error Handling (UPDATE-Nachricht-Fehlerbehandlung)

Alle Fehler, die während der Verarbeitung der UPDATE-Nachricht erkannt werden, müssen (MUST) durch Senden der NOTIFICATION-Nachricht mit dem Error Code UPDATE Message Error angezeigt werden. Der Error Subcode erläutert die spezifische Natur des Fehlers.

Die Fehlerprüfung einer UPDATE-Nachricht beginnt mit der Untersuchung der Pfadattribute. Wenn die Withdrawn Routes Length oder Total Attribute Length zu groß ist (d.h., wenn Withdrawn Routes Length + Total Attribute Length + 23 die Nachrichtenlänge überschreitet), dann muss (MUST) der Error Subcode auf Malformed Attribute List gesetzt werden.

Wenn ein erkanntes Attribut Attribute Flags hat, die mit dem Attribute Type Code in Konflikt stehen, dann muss (MUST) der Error Subcode auf Attribute Flags Error gesetzt werden. Das Data-Feld muss (MUST) das fehlerhafte Attribut (Typ, Länge und Wert) enthalten.

Wenn ein erkanntes Attribut eine Attribute Length hat, die mit der erwarteten Länge (basierend auf dem Attributtypcode) in Konflikt steht, dann muss (MUST) der Error Subcode auf Attribute Length Error gesetzt werden. Das Data-Feld muss (MUST) das fehlerhafte Attribut (Typ, Länge und Wert) enthalten.

Wenn eines der bekannten obligatorischen Attribute nicht vorhanden ist, dann muss (MUST) der Error Subcode auf Missing Well-known Attribute gesetzt werden. Das Data-Feld muss (MUST) den Attribute Type Code des fehlenden, bekannten Attributs enthalten.

Wenn eines der bekannten obligatorischen Attribute nicht erkannt wird, dann muss (MUST) der Error Subcode auf Unrecognized Well-known Attribute gesetzt werden. Das Data-Feld muss (MUST) das nicht erkannte Attribut (Typ, Länge und Wert) enthalten.

Wenn das ORIGIN-Attribut einen undefinierten Wert hat, dann muss (MUST) der Error Subcode auf Invalid Origin Attribute gesetzt werden. Das Data-Feld muss (MUST) das nicht erkannte Attribut (Typ, Länge und Wert) enthalten.

Wenn das NEXT_HOP-Attributfeld syntaktisch falsch ist, dann muss (MUST) der Error Subcode auf Invalid NEXT_HOP Attribute gesetzt werden. Das Data-Feld muss (MUST) das falsche Attribut (Typ, Länge und Wert) enthalten. Syntaktische Korrektheit bedeutet, dass das NEXT_HOP-Attribut eine gültige IP-Hostadresse darstellt.

Die IP-Adresse im NEXT_HOP muss (MUST) die folgenden Kriterien erfüllen, um als semantisch korrekt betrachtet zu werden:

a) Sie darf (MUST) nicht die IP-Adresse des empfangenden Speakers sein.

b) Im Fall eines EBGP, bei dem Sender und Empfänger einen IP-Hop voneinander entfernt sind, muss (MUST) entweder die IP-Adresse im NEXT_HOP die IP-Adresse des Senders sein, die zur Herstellung der BGP-Verbindung verwendet wird, oder die mit der NEXT_HOP-IP-Adresse verbundene Schnittstelle muss (MUST) ein gemeinsames Subnetz mit dem empfangenden BGP-Speaker teilen.

Wenn das NEXT_HOP-Attribut semantisch falsch ist, sollte (SHOULD) der Fehler protokolliert werden, und die Route sollte (SHOULD) ignoriert werden. In diesem Fall sollte (SHOULD) keine NOTIFICATION-Nachricht gesendet werden, und die Verbindung sollte (SHOULD) nicht geschlossen werden.

Das AS_PATH-Attribut wird auf syntaktische Korrektheit überprüft. Wenn der Pfad syntaktisch falsch ist, dann muss (MUST) der Error Subcode auf Malformed AS_PATH gesetzt werden.

Wenn die UPDATE-Nachricht von einem externen Peer empfangen wird, kann (MAY) das lokale System überprüfen, ob das am weitesten links stehende AS (in Bezug auf die Position der Oktette in der Protokollnachricht) im AS_PATH-Attribut gleich der Autonome-System-Nummer des Peers ist, der die Nachricht gesendet hat. Wenn die Überprüfung feststellt, dass dies nicht der Fall ist, muss (MUST) der Error Subcode auf Malformed AS_PATH gesetzt werden.

Wenn ein optionales Attribut erkannt wird, dann muss (MUST) der Wert dieses Attributs überprüft werden. Wenn ein Fehler erkannt wird, muss (MUST) das Attribut verworfen werden, und der Error Subcode muss (MUST) auf Optional Attribute Error gesetzt werden. Das Data-Feld muss (MUST) das Attribut (Typ, Länge und Wert) enthalten.

Wenn ein Attribut mehr als einmal in der UPDATE-Nachricht erscheint, dann muss (MUST) der Error Subcode auf Malformed Attribute List gesetzt werden.

Das NLRI-Feld in der UPDATE-Nachricht wird auf syntaktische Gültigkeit überprüft. Wenn das Feld syntaktisch falsch ist, dann muss (MUST) der Error Subcode auf Invalid Network Field gesetzt werden.

Wenn ein Präfix im NLRI-Feld semantisch falsch ist (z.B. eine unerwartete Multicast-IP-Adresse), sollte (SHOULD) ein Fehler lokal protokolliert werden, und das Präfix sollte (SHOULD) ignoriert werden.

Eine UPDATE-Nachricht, die korrekte Pfadattribute, aber keine NLRI enthält, muss (SHALL) als gültige UPDATE-Nachricht behandelt werden.

6.4. NOTIFICATION Message Error Handling (NOTIFICATION-Nachricht-Fehlerbehandlung)

Wenn ein Peer eine NOTIFICATION-Nachricht sendet und der Empfänger der Nachricht einen Fehler in dieser Nachricht erkennt, kann der Empfänger keine NOTIFICATION-Nachricht verwenden, um diesen Fehler an den Peer zurückzumelden. Jeder solche Fehler (z.B. ein nicht erkannter Error Code oder Error Subcode) sollte (SHOULD) bemerkt, lokal protokolliert und der Aufmerksamkeit der Verwaltung des Peers gebracht werden. Die Mittel dazu liegen jedoch außerhalb des Umfangs dieses Dokuments.

6.5. Hold Timer Expired Error Handling (Hold Timer abgelaufene Fehlerbehandlung)

Wenn ein System keine aufeinanderfolgenden KEEPALIVE-, UPDATE- und/oder NOTIFICATION-Nachrichten innerhalb der im Hold Time-Feld der OPEN-Nachricht angegebenen Periode empfängt, dann wird die NOTIFICATION-Nachricht mit dem Error Code Hold Timer Expired gesendet und die BGP-Verbindung wird geschlossen.

6.6. Finite State Machine Error Handling (Endlicher-Automat-Fehlerbehandlung)

Jeder Fehler, der von der BGP-Finite-State-Machine erkannt wird (z.B. Empfang eines unerwarteten Ereignisses), wird durch Senden der NOTIFICATION-Nachricht mit dem Error Code Finite State Machine Error angezeigt.

6.7. Cease (Beenden)

In Abwesenheit fataler Fehler (die in diesem Abschnitt angegeben sind) kann (MAY) ein BGP-Peer zu jedem Zeitpunkt wählen, seine BGP-Verbindung zu schließen, indem er die NOTIFICATION-Nachricht mit dem Error Code Cease sendet. Die Cease NOTIFICATION-Nachricht darf (MUST) jedoch nicht verwendet werden, wenn ein in diesem Abschnitt angegebener fataler Fehler vorliegt.

Ein BGP-Speaker kann (MAY) die Fähigkeit unterstützen, eine lokal konfigurierte Obergrenze für die Anzahl der Adresspräfixe aufzuerlegen, die der Speaker bereit ist, von einem Nachbarn zu akzeptieren. Wenn die Obergrenze erreicht ist, verwirft der Speaker unter Kontrolle der lokalen Konfiguration entweder (a) neue Adresspräfixe vom Nachbarn (während er die BGP-Verbindung mit dem Nachbarn aufrechterhält) oder (b) beendet die BGP-Verbindung mit dem Nachbarn. Wenn der BGP-Speaker beschließt, seine BGP-Verbindung mit einem Nachbarn zu beenden, weil die Anzahl der vom Nachbarn empfangenen Adresspräfixe die lokal konfigurierte Obergrenze überschreitet, dann muss (MUST) der Speaker dem Nachbarn eine NOTIFICATION-Nachricht mit dem Error Code Cease senden. Der Speaker kann (MAY) dies auch lokal protokollieren.

6.8. BGP Connection Collision Detection (BGP-Verbindungskollisionserkennung)

Wenn ein Paar von BGP-Speakern versucht, gleichzeitig eine BGP-Verbindung miteinander herzustellen, werden zwei parallele Verbindungen gebildet. Wenn die von einer dieser Verbindungen verwendete Quell-IP-Adresse dieselbe ist wie die von der anderen verwendete Ziel-IP-Adresse, und die von der ersten Verbindung verwendete Ziel-IP-Adresse dieselbe ist wie die von der anderen verwendete Quell-IP-Adresse, ist eine Verbindungskollision aufgetreten. Im Falle einer Verbindungskollision muss (MUST) eine der Verbindungen geschlossen werden.

Basierend auf dem Wert des BGP Identifiers wird eine Konvention festgelegt, um zu erkennen, welche BGP-Verbindung bei einer Kollision erhalten bleiben soll. Die Konvention besteht darin, die BGP Identifiers der an der Kollision beteiligten Peers zu vergleichen und nur die vom BGP-Speaker mit dem höherwertigen BGP Identifier initiierte Verbindung beizubehalten.

Beim Empfang einer OPEN-Nachricht muss (MUST) das lokale System alle seine Verbindungen untersuchen, die sich im OpenConfirm-Zustand befinden. Ein BGP-Speaker kann (MAY) auch Verbindungen in einem OpenSent-Zustand untersuchen, wenn er den BGP Identifier des Peers durch Mittel außerhalb des Protokolls kennt. Wenn unter diesen Verbindungen eine Verbindung zu einem entfernten BGP-Speaker vorhanden ist, dessen BGP Identifier dem in der OPEN-Nachricht entspricht, und diese Verbindung mit der Verbindung kollidiert, über die die OPEN-Nachricht empfangen wird, dann führt das lokale System das folgende Kollisionsauflösungsverfahren durch:

1. Der BGP Identifier des lokalen Systems wird mit dem BGP Identifier des entfernten Systems (wie in der OPEN-Nachricht angegeben) verglichen. Der Vergleich von BGP Identifiers erfolgt durch Konvertierung in Host-Byte-Reihenfolge und Behandlung als vorzeichenlose 4-Oktett-Ganzzahlen.

2. Wenn der Wert des lokalen BGP Identifiers kleiner als der entfernte ist, schließt das lokale System die bereits existierende BGP-Verbindung (diejenige, die sich bereits im OpenConfirm-Zustand befindet) und akzeptiert die vom entfernten System initiierte BGP-Verbindung.

3. Andernfalls schließt das lokale System die neu erstellte BGP-Verbindung (diejenige, die mit der neu empfangenen OPEN-Nachricht verbunden ist) und verwendet weiterhin die existierende (diejenige, die sich bereits im OpenConfirm-Zustand befindet).

Sofern nicht durch Konfiguration erlaubt, führt eine Verbindungskollision mit einer existierenden BGP-Verbindung, die sich im Established-Zustand befindet, zum Schließen der neu erstellten Verbindung.

Beachten Sie, dass eine Verbindungskollision nicht mit Verbindungen erkannt werden kann, die sich in den Zuständen Idle, Connect oder Active befinden.

Das Schließen der BGP-Verbindung (das aus dem Kollisionsauflösungsverfahren resultiert) wird durch Senden der NOTIFICATION-Nachricht mit dem Error Code Cease erreicht.