Passa al contenuto principale

5. Path Attributes (Attributi di percorso)

  1. Path Attributes (Attributi di percorso)

    Questa sezione tratta gli attributi di percorso del messaggio UPDATE.

    Gli attributi di percorso rientrano in quattro categorie separate:

    1. Well-known mandatory (Ben noti obbligatori)
    2. Well-known discretionary (Ben noti discrezionali)
    3. Optional transitive (Opzionali transitivi)
    4. Optional non-transitive (Opzionali non transitivi)

    Le implementazioni BGP devono (MUST) riconoscere tutti gli attributi ben noti. Alcuni di questi attributi sono obbligatori e devono (MUST) essere inclusi in ogni messaggio UPDATE che contiene NLRI. Altri sono discrezionali e possono (MAY) o non possono essere inviati in un particolare messaggio UPDATE.

    Una volta che un peer BGP ha aggiornato attributi ben noti, deve (MUST) passare questi attributi ai suoi peer in tutti gli aggiornamenti che trasmette.

    Oltre agli attributi ben noti, ogni percorso può (MAY) contenere uno o più attributi opzionali. Non è richiesto o previsto che tutte le implementazioni BGP supportino tutti gli attributi opzionali. La gestione di un attributo opzionale non riconosciuto è determinata dall'impostazione del bit Transitive nell'ottetto dei flag di attributo. I percorsi con attributi opzionali transitivi non riconosciuti dovrebbero (SHOULD) essere accettati. Se un percorso con un attributo opzionale transitivo non riconosciuto viene accettato e passato ad altri peer BGP, allora l'attributo opzionale transitivo non riconosciuto di quel percorso deve (MUST) essere passato, insieme al percorso, ad altri peer BGP con il bit Partial nell'ottetto Attribute Flags impostato su 1. Se un percorso con un attributo opzionale transitivo riconosciuto viene accettato e passato ad altri peer BGP e il bit Partial nell'ottetto Attribute Flags è impostato su 1 da qualche AS precedente, non deve (MUST) essere reimpostato a 0 dall'AS corrente. Gli attributi opzionali non transitivi non riconosciuti devono (MUST) essere ignorati silenziosamente e non passati ad altri peer BGP.

    Nuovi attributi opzionali transitivi possono (MAY) essere allegati al percorso dall'originatore o da qualsiasi altro BGP speaker nel percorso. Se non sono allegati dall'originatore, il bit Partial nell'ottetto Attribute Flags è impostato su 1. Le regole per allegare nuovi attributi opzionali non transitivi dipenderanno dalla natura dell'attributo specifico. La documentazione di ogni nuovo attributo opzionale non transitivo dovrebbe includere tali regole (la descrizione dell'attributo MULTI_EXIT_DISC fornisce un esempio). Tutti gli attributi opzionali (sia transitivi che non transitivi) possono (MAY) essere aggiornati (se appropriato) dai BGP speaker nel percorso.

    Il mittente di un messaggio UPDATE dovrebbe (SHOULD) ordinare gli attributi di percorso all'interno del messaggio UPDATE in ordine crescente di tipo di attributo. Il ricevitore di un messaggio UPDATE deve (MUST) essere preparato a gestire gli attributi di percorso all'interno dei messaggi UPDATE che sono fuori ordine.

    Lo stesso attributo (attributo con lo stesso tipo) non può apparire più di una volta all'interno del campo Path Attributes di un particolare messaggio UPDATE.

    La categoria obbligatoria si riferisce a un attributo che deve (MUST) essere presente negli scambi IBGP ed EBGP se NLRI è contenuto nel messaggio UPDATE. Gli attributi classificati come opzionali ai fini del meccanismo di estensione del protocollo possono essere puramente discrezionali, discrezionali, richiesti o non consentiti in determinati contesti.

    attribute EBGP IBGP ORIGIN mandatory mandatory AS_PATH mandatory mandatory NEXT_HOP mandatory mandatory MULTI_EXIT_DISC discretionary discretionary LOCAL_PREF see Section 5.1.5 required ATOMIC_AGGREGATE see Section 5.1.6 and 9.1.4 AGGREGATOR discretionary discretionary

5.1. Path Attribute Usage (Uso degli attributi di percorso)

L'uso di ogni attributo di percorso BGP è descritto nelle seguenti clausole.

5.1.1. ORIGIN

ORIGIN è un attributo ben noto obbligatorio. L'attributo ORIGIN è generato dallo speaker che origina le informazioni di routing associate. Il suo valore non dovrebbe (SHOULD) essere modificato da nessun altro speaker.

5.1.2. AS_PATH

AS_PATH è un attributo ben noto obbligatorio. Questo attributo identifica i sistemi autonomi attraverso i quali le informazioni di routing trasportate in questo messaggio UPDATE sono passate. I componenti di questo elenco possono essere AS_SET o AS_SEQUENCE.

Quando un BGP speaker propaga una route appresa dal messaggio UPDATE di un altro BGP speaker, modifica l'attributo AS_PATH della route in base alla posizione del BGP speaker a cui verrà inviata la route:

a) Quando un dato BGP speaker annuncia la route a un peer interno, lo speaker annunciante non deve (SHALL) modificare l'attributo AS_PATH associato alla route.

b) Quando un dato BGP speaker annuncia la route a un peer esterno, lo speaker annunciante aggiorna l'attribut AS_PATH come segue:

  1. se il primo segmento di percorso dell'AS_PATH è di tipo AS_SEQUENCE, il sistema locale antepone il proprio numero AS come ultimo elemento della sequenza (lo mette nella posizione più a sinistra rispetto alla posizione degli ottetti nel messaggio di protocollo). Se l'atto di anteporre causerà un overflow nel segmento AS_PATH (cioè più di 255 AS), dovrebbe (SHOULD) anteporre un nuovo segmento di tipo AS_SEQUENCE e anteporre il proprio numero AS a questo nuovo segmento.

  2. se il primo segmento di percorso dell'AS_PATH è di tipo AS_SET, il sistema locale antepone un nuovo segmento di percorso di tipo AS_SEQUENCE all'AS_PATH, includendo il proprio numero AS in quel segmento.

  3. se l'AS_PATH è vuoto, il sistema locale crea un segmento di percorso di tipo AS_SEQUENCE, colloca il proprio AS in quel segmento e colloca quel segmento nell'AS_PATH.

Quando un BGP speaker origina una route allora:

a) lo speaker originante include il proprio numero AS in un segmento di percorso, di tipo AS_SEQUENCE, nell'attributo AS_PATH di tutti i messaggi UPDATE inviati a un peer esterno. In questo caso, il numero AS del sistema autonomo dello speaker originante sarà l'unica voce nel segmento di percorso, e questo segmento di percorso sarà l'unico segmento nell'attributo AS_PATH.

b) lo speaker originante include un attributo AS_PATH vuoto in tutti i messaggi UPDATE inviati ai peer interni. (Un attributo AS_PATH vuoto è uno il cui campo di lunghezza contiene il valore zero).

Ogni volta che la modifica dell'attributo AS_PATH richiede di includere o anteporre il numero AS del sistema locale, il sistema locale può (MAY) includere/anteporre più di un'istanza del proprio numero AS nell'attributo AS_PATH. Questo è controllato tramite la configurazione locale.

5.1.3. NEXT_HOP

Il NEXT_HOP è un attributo ben noto obbligatorio che definisce l'indirizzo IP del router che dovrebbe (SHOULD) essere utilizzato come prossimo hop verso le destinazioni elencate nel messaggio UPDATE. L'attributo NEXT_HOP è calcolato come segue:

  1. Quando si invia un messaggio a un peer interno, se la route non è di origine locale, il BGP speaker non dovrebbe (SHOULD) modificare l'attributo NEXT_HOP a meno che non sia stato esplicitamente configurato per annunciare il proprio indirizzo IP come NEXT_HOP. Quando si annuncia una route di origine locale a un peer interno, il BGP speaker dovrebbe (SHOULD) utilizzare l'indirizzo dell'interfaccia del router attraverso il quale la rete annunciata è raggiungibile per lo speaker come NEXT_HOP. Se la route è direttamente connessa allo speaker, o se l'indirizzo dell'interfaccia del router attraverso il quale la rete annunciata è raggiungibile per lo speaker è l'indirizzo del peer interno, allora il BGP speaker dovrebbe (SHOULD) utilizzare il proprio indirizzo IP per l'attributo NEXT_HOP (l'indirizzo dell'interfaccia utilizzata per raggiungere il peer).

  2. Quando si invia un messaggio a un peer esterno, X, e il peer è a un hop IP dallo speaker:

    • Se la route annunciata è stata appresa da un peer interno o è di origine locale, il BGP speaker può utilizzare un indirizzo di interfaccia del router peer interno (o del router interno) attraverso il quale la rete annunciata è raggiungibile per lo speaker per l'attributo NEXT_HOP, purché il peer X condivida una sottorete comune con questo indirizzo. Questa è una forma di attributo NEXT_HOP "terza parte".

    • Altrimenti, se la route annunciata è stata appresa da un peer esterno, lo speaker può utilizzare un indirizzo IP di qualsiasi router adiacente (noto dall'attributo NEXT_HOP ricevuto) che lo speaker stesso utilizza per il calcolo della route locale nell'attributo NEXT_HOP, purché il peer X condivida una sottorete comune con questo indirizzo. Questa è una seconda forma di attributo NEXT_HOP "terza parte".

    • Altrimenti, se il peer esterno a cui viene annunciata la route condivide una sottorete comune con una delle interfacce del BGP speaker annunciante, lo speaker può (MAY) utilizzare l'indirizzo IP associato a tale interfaccia nell'attributo NEXT_HOP. Questo è noto come attributo NEXT_HOP "prima parte".

    • Per impostazione predefinita (se nessuna delle condizioni precedenti si applica), il BGP speaker dovrebbe (SHOULD) utilizzare l'indirizzo IP dell'interfaccia che lo speaker utilizza per stabilire la connessione BGP al peer X nell'attributo NEXT_HOP.

  3. Quando si invia un messaggio a un peer esterno X, e il peer è a più hop IP dallo speaker (alias "multihop EBGP"):

    • Lo speaker può (MAY) essere configurato per propagare l'attributo NEXT_HOP. In questo caso, quando si annuncia una route che lo speaker ha appreso da uno dei suoi peer, l'attributo NEXT_HOP della route annunciata è esattamente lo stesso dell'attributo NEXT_HOP della route appresa (lo speaker non modifica l'attributo NEXT_HOP).

    • Per impostazione predefinita, il BGP speaker dovrebbe (SHOULD) utilizzare l'indirizzo IP dell'interfaccia che lo speaker utilizza nell'attributo NEXT_HOP per stabilire la connessione BGP al peer X.

Normalmente, l'attributo NEXT_HOP è scelto in modo tale che venga preso il percorso disponibile più breve. Un BGP speaker deve (MUST) essere in grado di supportare la disabilitazione dell'annuncio di attributi NEXT_HOP di terze parti per gestire mezzi imperfettamente collegati a bridge.

Una route originata da un BGP speaker non deve (SHALL) essere annunciata a un peer utilizzando un indirizzo di quel peer come NEXT_HOP. Un BGP speaker non deve (SHALL) installare una route con se stesso come prossimo hop.

L'attributo NEXT_HOP è utilizzato dal BGP speaker per determinare l'interfaccia in uscita effettiva e l'indirizzo del prossimo hop immediato che dovrebbe (SHOULD) essere utilizzato per inoltrare i pacchetti di transito alle destinazioni associate.

L'indirizzo del prossimo hop immediato è determinato eseguendo un'operazione di ricerca di route ricorsiva per l'indirizzo IP nell'attributo NEXT_HOP, utilizzando il contenuto della tabella di routing, selezionando una voce se esistono più voci di costo uguale. La voce della tabella di routing che risolve l'indirizzo IP nell'attributo NEXT_HOP specificherà sempre l'interfaccia in uscita. Se la voce specifica una sottorete collegata, ma non specifica un indirizzo del prossimo hop, allora l'indirizzo nell'attributo NEXT_HOP dovrebbe (SHOULD) essere utilizzato come indirizzo del prossimo hop immediato. Se la voce specifica anche l'indirizzo del prossimo hop, questo indirizzo dovrebbe (SHOULD) essere utilizzato come indirizzo del prossimo hop immediato per l'inoltro dei pacchetti.

5.1.4. MULTI_EXIT_DISC

Il MULTI_EXIT_DISC è un attributo opzionale non transitivo destinato ad essere utilizzato su collegamenti esterni (inter-AS) per discriminare tra più punti di uscita o ingresso allo stesso AS vicino. Il valore dell'attributo MULTI_EXIT_DISC è un numero senza segno di quattro ottetti, chiamato metrica. A parità di tutti gli altri fattori, il punto di uscita con la metrica inferiore dovrebbe (SHOULD) essere preferito. Se ricevuto tramite EBGP, l'attributo MULTI_EXIT_DISC può (MAY) essere propagato tramite IBGP ad altri BGP speaker all'interno dello stesso AS (vedere anche 9.1.2.2). L'attributo MULTI_EXIT_DISC ricevuto da un AS vicino non deve (MUST) essere propagato ad altri AS vicini.

Un BGP speaker deve (MUST) implementare un meccanismo (basato sulla configurazione locale) che consenta di rimuovere l'attributo MULTI_EXIT_DISC da una route. Se un BGP speaker è configurato per rimuovere l'attributo MULTI_EXIT_DISC da una route, questa rimozione deve (MUST) essere effettuata prima di determinare il grado di preferenza della route e prima di eseguire la selezione della route (fasi 1 e 2 del processo decisionale).

Un'implementazione può (MAY) anche (in base alla configurazione locale) alterare il valore dell'attributo MULTI_EXIT_DISC ricevuto tramite EBGP. Se un BGP speaker è configurato per alterare il valore dell'attributo MULTI_EXIT_DISC ricevuto tramite EBGP, l'alterazione del valore deve (MUST) essere effettuata prima di determinare il grado di preferenza della route e prima di eseguire la selezione della route (fasi 1 e 2 del processo decisionale). Vedere la sezione 9.1.2.2 per le restrizioni necessarie su questo.

5.1.5. LOCAL_PREF

LOCAL_PREF è un attributo ben noto che deve (SHALL) essere incluso in tutti i messaggi UPDATE che un dato BGP speaker invia ad altri peer interni. Un BGP speaker deve (SHALL) calcolare il grado di preferenza per ogni route esterna in base alla politica configurata localmente e includere il grado di preferenza quando annuncia una route ai suoi peer interni. Il grado di preferenza più alto deve (MUST) essere preferito. Un BGP speaker utilizza il grado di preferenza appreso tramite LOCAL_PREF nel suo processo decisionale (vedere la sezione 9.1.1).

Un BGP speaker non deve (MUST) includere questo attributo nei messaggi UPDATE che invia ai peer esterni, tranne nel caso delle confederazioni BGP [RFC3065]. Se è contenuto in un messaggio UPDATE ricevuto da un peer esterno, questo attributo deve (MUST) essere ignorato dallo speaker ricevente, tranne nel caso delle confederazioni BGP [RFC3065].

5.1.6. ATOMIC_AGGREGATE

ATOMIC_AGGREGATE è un attributo ben noto discrezionale.

Quando un BGP speaker aggrega diverse route allo scopo di annunciarle a un particolare peer, l'AS_PATH della route aggregata normalmente include un AS_SET formato dall'insieme degli AS da cui è stato formato l'aggregato. In molti casi, l'amministratore di rete può determinare se l'aggregato può essere annunciato in sicurezza senza l'AS_SET e senza formare loop di route.

Se un aggregato esclude almeno alcuni dei numeri AS presenti nell'AS_PATH delle route aggregate come risultato dell'eliminazione dell'AS_SET, la route aggregata, quando annunciata al peer, dovrebbe (SHOULD) includere l'attributo ATOMIC_AGGREGATE.

Un BGP speaker che riceve una route con l'attributo ATOMIC_AGGREGATE non dovrebbe (SHOULD) rimuovere l'attributo quando propaga la route ad altri speaker.

Un BGP speaker che riceve una route con l'attributo ATOMIC_AGGREGATE non deve (MUST) rendere alcun NLRI di quella route più specifico (come definito in 9.1.4) quando annuncia questa route ad altri BGP speaker.

Un BGP speaker che riceve una route con l'attributo ATOMIC_AGGREGATE deve essere consapevole del fatto che il percorso effettivo verso le destinazioni, come specificato nel NLRI della route, pur avendo la proprietà di essere privo di loop, potrebbe non essere il percorso specificato nell'attributo AS_PATH della route.

5.1.7. AGGREGATOR

AGGREGATOR è un attributo opzionale transitivo, che può (MAY) essere incluso negli aggiornamenti formati per aggregazione (vedere la sezione 9.2.2.2). Un BGP speaker che esegue l'aggregazione di route può (MAY) aggiungere l'attributo AGGREGATOR, che deve (SHALL) contenere il proprio numero AS e indirizzo IP. L'indirizzo IP dovrebbe (SHOULD) essere lo stesso dell'identificatore BGP dello speaker.

Ultimo aggiornamento il