6. BGP Error Handling (Gestione degli errori BGP)

BGP Error Handling (Gestione degli errori BGP)

Questa sezione descrive le azioni da intraprendere quando vengono rilevati errori durante l'elaborazione dei messaggi BGP.

Quando viene rilevata una delle condizioni descritte qui, viene inviato un messaggio NOTIFICATION, con i campi Error Code, Error Subcode e Data indicati, e la connessione BGP viene chiusa (a meno che non sia esplicitamente dichiarato che nessun messaggio NOTIFICATION deve essere inviato e la connessione BGP non deve essere chiusa). Se non è specificato alcun Error Subcode, allora deve (MUST) essere usato zero.

L'espressione "la connessione BGP viene chiusa" significa che la connessione TCP è stata chiusa, l'Adj-RIB-In associato è stato cancellato e tutte le risorse per quella connessione BGP sono state deallocate. Le voci nel Loc-RIB associate al peer remoto sono contrassegnate come non valide. Il sistema locale ricalcola le sue migliori route per le destinazioni delle route contrassegnate come non valide. Prima che le route non valide vengano eliminate dal sistema, annuncia ai suoi peer, o ritiri per le route contrassegnate come non valide, o le nuove migliori route prima che le route non valide vengano eliminate dal sistema.

Se non specificato esplicitamente, il campo Data del messaggio NOTIFICATION che viene inviato per indicare un errore è vuoto.

6.1. Message Header Error Handling (Gestione degli errori dell'intestazione del messaggio)

Tutti gli errori rilevati durante l'elaborazione dell'intestazione del messaggio devono (MUST) essere indicati inviando il messaggio NOTIFICATION con l'Error Code Message Header Error. L'Error Subcode elabora la natura specifica dell'errore.

Il valore atteso del campo Marker dell'intestazione del messaggio è tutti uno. Se il campo Marker dell'intestazione del messaggio non è come previsto, allora si è verificato un errore di sincronizzazione e l'Error Subcode deve (MUST) essere impostato su Connection Not Synchronized.

Se almeno una delle seguenti condizioni è vera:

se il campo Length dell'intestazione del messaggio è inferiore a 19 o superiore a 4096, o
se il campo Length di un messaggio OPEN è inferiore alla lunghezza minima del messaggio OPEN, o
se il campo Length di un messaggio UPDATE è inferiore alla lunghezza minima del messaggio UPDATE, o
se il campo Length di un messaggio KEEPALIVE non è uguale a 19, o
se il campo Length di un messaggio NOTIFICATION è inferiore alla lunghezza minima del messaggio NOTIFICATION,

allora l'Error Subcode deve (MUST) essere impostato su Bad Message Length. Il campo Data deve (MUST) contenere il campo Length errato.

Se il campo Type dell'intestazione del messaggio non è riconosciuto, allora l'Error Subcode deve (MUST) essere impostato su Bad Message Type. Il campo Data deve (MUST) contenere il campo Type errato.

6.2. OPEN Message Error Handling (Gestione degli errori del messaggio OPEN)

Tutti gli errori rilevati durante l'elaborazione del messaggio OPEN devono (MUST) essere indicati inviando il messaggio NOTIFICATION con l'Error Code OPEN Message Error. L'Error Subcode elabora la natura specifica dell'errore.

Se il numero di versione nel campo Version del messaggio OPEN ricevuto non è supportato, allora l'Error Subcode deve (MUST) essere impostato su Unsupported Version Number. Il campo Data è un intero senza segno di 2 ottetti, che indica il più grande numero di versione supportato localmente inferiore alla versione offerta dal peer BGP remoto (come indicato nel messaggio OPEN ricevuto), o se il più piccolo numero di versione supportato localmente è maggiore della versione offerta dal peer BGP remoto, allora il più piccolo numero di versione supportato localmente.

Se il campo Autonomous System del messaggio OPEN è inaccettabile, allora l'Error Subcode deve (MUST) essere impostato su Bad Peer AS. La determinazione dei numeri di sistema autonomo accettabili è al di fuori dell'ambito di questo protocollo.

Se il campo Hold Time del messaggio OPEN è inaccettabile, allora l'Error Subcode deve (MUST) essere impostato su Unacceptable Hold Time. Un'implementazione deve (MUST) rifiutare valori di Hold Time di uno o due secondi. Un'implementazione può (MAY) rifiutare qualsiasi Hold Time proposto. Un'implementazione che accetta un Hold Time deve (MUST) utilizzare il valore negoziato per l'Hold Time.

Se il campo BGP Identifier del messaggio OPEN è sintatticamente scorretto, allora l'Error Subcode deve (MUST) essere impostato su Bad BGP Identifier. La correttezza sintattica significa che il campo BGP Identifier rappresenta un indirizzo host IP unicast valido.

Se uno dei parametri opzionali nel messaggio OPEN non è riconosciuto, allora l'Error Subcode deve (MUST) essere impostato su Unsupported Optional Parameters.

Se uno dei parametri opzionali nel messaggio OPEN è riconosciuto, ma è malformato, allora l'Error Subcode deve (MUST) essere impostato su 0 (Unspecific).

6.3. UPDATE Message Error Handling (Gestione degli errori del messaggio UPDATE)

Tutti gli errori rilevati durante l'elaborazione del messaggio UPDATE devono (MUST) essere indicati inviando il messaggio NOTIFICATION con l'Error Code UPDATE Message Error. L'error subcode elabora la natura specifica dell'errore.

Il controllo degli errori di un messaggio UPDATE inizia esaminando gli attributi di percorso. Se Withdrawn Routes Length o Total Attribute Length è troppo grande (cioè, se Withdrawn Routes Length + Total Attribute Length + 23 supera la lunghezza del messaggio), allora l'Error Subcode deve (MUST) essere impostato su Malformed Attribute List.

Se un attributo riconosciuto ha flag di attributo che sono in conflitto con l'Attribute Type Code, allora l'Error Subcode deve (MUST) essere impostato su Attribute Flags Error. Il campo Data deve (MUST) contenere l'attributo errato (tipo, lunghezza e valore).

Se un attributo riconosciuto ha una lunghezza dell'attributo che è in conflitto con la lunghezza prevista (basata sul codice del tipo di attributo), allora l'Error Subcode deve (MUST) essere impostato su Attribute Length Error. Il campo Data deve (MUST) contenere l'attributo errato (tipo, lunghezza e valore).

Se uno degli attributi ben noti obbligatori non è presente, allora l'Error Subcode deve (MUST) essere impostato su Missing Well-known Attribute. Il campo Data deve (MUST) contenere l'Attribute Type Code dell'attributo ben noto mancante.

Se uno degli attributi ben noti obbligatori non è riconosciuto, allora l'Error Subcode deve (MUST) essere impostato su Unrecognized Well-known Attribute. Il campo Data deve (MUST) contenere l'attributo non riconosciuto (tipo, lunghezza e valore).

Se l'attributo ORIGIN ha un valore non definito, allora l'Error Subcode deve (MUST) essere impostato su Invalid Origin Attribute. Il campo Data deve (MUST) contenere l'attributo non riconosciuto (tipo, lunghezza e valore).

Se il campo dell'attributo NEXT_HOP è sintatticamente scorretto, allora l'Error Subcode deve (MUST) essere impostato su Invalid NEXT_HOP Attribute. Il campo Data deve (MUST) contenere l'attributo scorretto (tipo, lunghezza e valore). La correttezza sintattica significa che l'attributo NEXT_HOP rappresenta un indirizzo host IP valido.

L'indirizzo IP nel NEXT_HOP deve (MUST) soddisfare i seguenti criteri per essere considerato semanticamente corretto:

a) Non deve (MUST) essere l'indirizzo IP dello speaker ricevente.

b) Nel caso di un EBGP, dove il mittente e il ricevitore sono a un hop IP l'uno dall'altro, o l'indirizzo IP nel NEXT_HOP deve (MUST) essere l'indirizzo IP del mittente utilizzato per stabilire la connessione BGP, o l'interfaccia associata all'indirizzo IP NEXT_HOP deve (MUST) condividere una sottorete comune con lo speaker BGP ricevente.

Se l'attributo NEXT_HOP è semanticamente scorretto, l'errore dovrebbe (SHOULD) essere registrato e la route dovrebbe (SHOULD) essere ignorata. In questo caso, un messaggio NOTIFICATION non dovrebbe (SHOULD) essere inviato e la connessione non dovrebbe (SHOULD) essere chiusa.

L'attributo AS_PATH viene verificato per la correttezza sintattica. Se il percorso è sintatticamente scorretto, allora l'Error Subcode deve (MUST) essere impostato su Malformed AS_PATH.

Se il messaggio UPDATE è ricevuto da un peer esterno, il sistema locale può (MAY) verificare se l'AS più a sinistra (rispetto alla posizione degli ottetti nel messaggio di protocollo) nell'attributo AS_PATH è uguale al numero di sistema autonomo del peer che ha inviato il messaggio. Se il controllo determina che questo non è il caso, l'Error Subcode deve (MUST) essere impostato su Malformed AS_PATH.

Se un attributo opzionale è riconosciuto, allora il valore di questo attributo deve (MUST) essere verificato. Se viene rilevato un errore, l'attributo deve (MUST) essere scartato e l'Error Subcode deve (MUST) essere impostato su Optional Attribute Error. Il campo Data deve (MUST) contenere l'attributo (tipo, lunghezza e valore).

Se un attributo appare più di una volta nel messaggio UPDATE, allora l'Error Subcode deve (MUST) essere impostato su Malformed Attribute List.

Il campo NLRI nel messaggio UPDATE viene verificato per la validità sintattica. Se il campo è sintatticamente scorretto, allora l'Error Subcode deve (MUST) essere impostato su Invalid Network Field.

Se un prefisso nel campo NLRI è semanticamente scorretto (ad esempio, un indirizzo IP multicast inaspettato), un errore dovrebbe (SHOULD) essere registrato localmente e il prefisso dovrebbe (SHOULD) essere ignorato.

Un messaggio UPDATE che contiene attributi di percorso corretti, ma nessun NLRI, deve (SHALL) essere trattato come un messaggio UPDATE valido.

6.4. NOTIFICATION Message Error Handling (Gestione degli errori del messaggio NOTIFICATION)

Se un peer invia un messaggio NOTIFICATION e il ricevitore del messaggio rileva un errore in quel messaggio, il ricevitore non può utilizzare un messaggio NOTIFICATION per segnalare questo errore al peer. Qualsiasi errore di questo tipo (ad esempio, un codice di errore o un sottocodice di errore non riconosciuto) dovrebbe (SHOULD) essere notato, registrato localmente e portato all'attenzione dell'amministrazione del peer. I mezzi per farlo, tuttavia, sono al di fuori dell'ambito di questo documento.

6.5. Hold Timer Expired Error Handling (Gestione degli errori di scadenza del timer Hold)

Se un sistema non riceve messaggi KEEPALIVE, UPDATE e/o NOTIFICATION successivi entro il periodo specificato nel campo Hold Time del messaggio OPEN, allora viene inviato il messaggio NOTIFICATION con l'Error Code Hold Timer Expired e la connessione BGP viene chiusa.

6.6. Finite State Machine Error Handling (Gestione degli errori della macchina a stati finiti)

Qualsiasi errore rilevato dalla macchina a stati finiti BGP (ad esempio, ricezione di un evento inaspettato) è indicato inviando il messaggio NOTIFICATION con l'Error Code Finite State Machine Error.

6.7. Cease (Cessazione)

In assenza di errori fatali (indicati in questa sezione), un peer BGP può (MAY) scegliere, in qualsiasi momento, di chiudere la sua connessione BGP inviando il messaggio NOTIFICATION con l'Error Code Cease. Tuttavia, il messaggio NOTIFICATION Cease non deve (MUST) essere utilizzato quando esiste un errore fatale indicato da questa sezione.

Un BGP speaker può (MAY) supportare la capacità di imporre un limite superiore configurato localmente sul numero di prefissi di indirizzo che lo speaker è disposto ad accettare da un vicino. Quando viene raggiunto il limite superiore, lo speaker, sotto il controllo della configurazione locale, o (a) scarta i nuovi prefissi di indirizzo dal vicino (mantenendo la connessione BGP con il vicino), o (b) termina la connessione BGP con il vicino. Se il BGP speaker decide di terminare la sua connessione BGP con un vicino perché il numero di prefissi di indirizzo ricevuti dal vicino supera il limite superiore configurato localmente, allora lo speaker deve (MUST) inviare al vicino un messaggio NOTIFICATION con l'Error Code Cease. Lo speaker può (MAY) anche registrare questo localmente.

6.8. BGP Connection Collision Detection (Rilevamento della collisione di connessione BGP)

Se una coppia di BGP speaker tenta di stabilire una connessione BGP l'uno con l'altro simultaneamente, allora verranno formate due connessioni parallele. Se l'indirizzo IP sorgente utilizzato da una di queste connessioni è lo stesso dell'indirizzo IP di destinazione utilizzato dall'altra, e l'indirizzo IP di destinazione utilizzato dalla prima connessione è lo stesso dell'indirizzo IP sorgente utilizzato dall'altra, si è verificata una collisione di connessione. In caso di collisione di connessione, una delle connessioni deve (MUST) essere chiusa.

Sulla base del valore dell'identificatore BGP, viene stabilita una convenzione per rilevare quale connessione BGP deve essere preservata quando si verifica una collisione. La convenzione consiste nel confrontare gli identificatori BGP dei peer coinvolti nella collisione e nel mantenere solo la connessione iniziata dal BGP speaker con l'identificatore BGP di valore superiore.

Al ricevimento di un messaggio OPEN, il sistema locale deve (MUST) esaminare tutte le sue connessioni che sono nello stato OpenConfirm. Un BGP speaker può (MAY) anche esaminare le connessioni in uno stato OpenSent se conosce l'identificatore BGP del peer con mezzi esterni al protocollo. Se, tra queste connessioni, esiste una connessione a un BGP speaker remoto il cui identificatore BGP è uguale a quello nel messaggio OPEN, e questa connessione collide con la connessione su cui viene ricevuto il messaggio OPEN, allora il sistema locale esegue la seguente procedura di risoluzione della collisione:

L'identificatore BGP del sistema locale viene confrontato con l'identificatore BGP del sistema remoto (come specificato nel messaggio OPEN). Il confronto degli identificatori BGP viene effettuato convertendoli in ordine di byte dell'host e trattandoli come interi senza segno di 4 ottetti.
Se il valore dell'identificatore BGP locale è inferiore a quello remoto, il sistema locale chiude la connessione BGP che esiste già (quella che è già nello stato OpenConfirm) e accetta la connessione BGP iniziata dal sistema remoto.
Altrimenti, il sistema locale chiude la connessione BGP appena creata (quella associata al messaggio OPEN appena ricevuto) e continua a utilizzare quella esistente (quella che è già nello stato OpenConfirm).

A meno che non sia consentito tramite configurazione, una collisione di connessione con una connessione BGP esistente che è nello stato Established causa la chiusura della connessione appena creata.

Si noti che una collisione di connessione non può essere rilevata con connessioni che sono negli stati Idle, Connect o Active.

La chiusura della connessione BGP (che risulta dalla procedura di risoluzione della collisione) viene effettuata inviando il messaggio NOTIFICATION con l'Error Code Cease.