bgp attributi funzionalità e formato header

Home » Blog » Routing » bgp » bgp teoria » bgp attributi funzionalità e formato header

bgp attributi funzionalità e formato header

04.01 2020 | by massimiliano

BGP ATTRUBUTE:   BGP divide i suoi attributi in: Well Know Mandatory (obbligatori e sempre presenti nei messaggi update):   […]


https://www.ingegnerianetworking.com/wp-content/uploads/2020/01/bgp-attribute-header-7c7.png

BGP ATTRUBUTE:

 

BGP divide i suoi attributi in:


Well Know Mandatory (obbligatori e sempre presenti nei messaggi update):

    ORIGIN

    AS PATH

    NEXT HOP

 

Well Know Discretionary (importanti ma non sempre presenti nei messaggi update):

    LOCAL PREFERENCE

    ATOMIC AGGREGATE

 

Optional Transitive (se l’attributo non è riconosciuto da uno speaker BGP, questo deve ignorarlo e passare ai suoi BGP peers):

    AGGREGATOR

    COMMUNITY

    EXTENDED COMMUNITY

    AS4 PATH

    AS4 AGGREGATOR

 

Optional Non Transitive (se l’attributo non è riconosciuto da uno speaker BGP, questo deve ignorarlo e non passare ai suoi BGP peers):  

    MULTI EXIT DISC (MED)

    ORIGINATOR ID

    CLUSTER LIST

    MP REACH NLRI

    MP UNREACH NLRI

 

 

bgp attribute header

 

 

 

 

 

ORIGIN (Type Code = 1): specifica l’origine di un prefisso IP e può assumere tre differenti valori:


 IGP: è il prefisso IP originato dal router stesso
 EGP: è il prefisso IP appreso attraverso un protocollo EGP (non più usato poiché soppiantato da BGP come external routing)
 INCOMPLETE: è il prefisso IP appreso in qualche altro modo come ad esempio una qualsiasi redistribuzione di un qualsiasi protocollo di routing in BGP

 

Viene propagato invariato su tutti gli AS

Viene utilizzato per i processi di selezione BGP con la seguente regola di preferenza: IGP –> EGP –> INCOMPLETE

 

 

 

bgp origin header

 

 

 

 

AS PATH (Type Code = 2): specifica una lista ordinata o meno degli AS attraversati da un prefisso IP.


E’ rappresentato da una serie di segmenti ciascuno con i seguenti significati:

 AS SEQUENCE: è una lista ordinata di AS con:

     Path Segment Type = 1

     Path Segment Lenght = è il numero di AS della lista

     AS Sequence è utilizzato da un BGP speaker per aggiornare la lista ordinata degli AS (Path Vector) attraversati

 

 AS SET: è una lista non ordinata di AS con:

    Path Segment Type = 2

    Path Segment Lenght = è il numero di AS della lista

    AS SET è utilizzato da un BGP peer che effettua una aggregazione di prefissi IP per conservare memoria degli AS attraversati dai prefissi oggetto di aggregazione

 

 

bgp aspath header

 

 

AS PATH avviene secondo determinate regole:


  AS PATH non viene modificato in caso di invio di un messaggio update tra IBGP speakers (internal-bgp)

  AS PATH viene modificato in caso di invio di un messaggio update tra un BGP speaker ed un EBGP peer (external-bgp)

 

se l’AS PATH è di tipo AS-Sequence, il router che origina il messaggio inserisce il proprio numero di AS in testa alla lista

se l’AS PATH è di tipo AS-SET, il router che origina il messaggio inserisce un nuovo segmento di tipo AS Sequence contenente il solo proprio numero di AS

se l’AS PATH è vuoto, il router che origina il messaggio si comporta come se fosse di tipo AS SET.

 

 

AS PATH ha principalmente due funzioni:


Prevenzione di loop path che si basa:

    un BGP speaker non invia ad un E-BGP peer annunci contenenti nel’attributo AS PATH il numero di AS dell’E-BGP che ha originato il messaggio (oppure un BGP speaker rifiuta sempre annunci contenetenti nell’AS PATH il proprio numero di AS)

   Best Path per il processo di selezione con il numero più basso di AS contenuti nella lista preferito ad uno con un numero più alto di AS attraversati.

 

 

 

 

NEXT HOP (Type Code = 3): specifica il next hop da utilizzare per i prefissi contenuti nel campo NLRI.

 

Le regole dicono:

 

Il Next Hop viene modificato solo quando gli annunci BGP vengono inoltrati su sessioni E-BGP; l’indirizzo IP del next hop è quello utilizzato dal BGP che ha originato il messaggio per aprire la connessione TCP verso il BGP peer

Se un prefisso locale viene annunciato su una sessione IBGP tra due peer dello stesso AS, l’indirizzo IP del next hop è quello utilizzato dal router che origina il messaggio e propaga l’annuncio per aprire la connessione TCP verso il BGP peer

Se un prefisso remoto (esterno ad un AS), ricevuto su una sessione E-BGP viene propagato su una sessione I-BGP, l’indirizzo IP next hop non cambia (resta quello del router che origina il messaggio)

Se un prefisso remoto viene propagato in reti di tipo Broadcast e NBMA con AS differenti, l’indirizzo IP next hop non cambia (regola conosciuta come Third-Party Next-Hop)

NOTA: la regola Third-Party Next-Hop non vale quando le sessioni sono attive su interfacce diverse da quelle fisiche, ad esempio le loopback

 

 

bgp next hop header

 

 

 

 

 

MED (Multi Exit Discriminator Type Code = 4): è una metrica utilizzata per dare un valore di preferenza ad un annuncio utilizzato nelle politiche di traffico « inbound « per forzare il punto di ingresso da un Autonomous System.


E’ una metrica più debole rispetto a quella definita per la Local Preference.

Il valore di MED viene assegnato su base configurazione dal router peer che invia gli annunci E-BGP; una volta assegnato il valore di MED, questo viene propagato solo all’interno dell’AS che riceve l’annuncio e viene tolto se l’annuncio viene propagato ad altri AS.

La regola generale dice:

Tra tutti gli annunci provenienti dallo stesso AS, viene preferito quello che ha valore associato di MED più basso.

 

 

bgp med header

 

 

 

 

LOCAL PREFERENCE (Type Code = 5): specifica una metrica per dare un grado di preferenza ad un annuncio e viene utilizzato per politiche di routing di tipo «outbound» e quindi specificare il punto di uscita del traffico da un AS.


E’ il primo valore di metrica considerato nel processo di selezione BGP

Valore di default = 100; il valore più alto è considerato migliore.

Viene propagato solo all’interno dell’AS e viene annullato negli annunci uscenti dall’AS.

 

bgp local pref header

 

 

 

 

ATOMIC AGGREGATOR (Type Code = 6): serve a notificare ad altri BGP peers che il nodo che emette l’annuncio ha eseguito una operazione di aggregazione dei prefissi con perdita di memoria di attributi.


L’attributo Atomic Aggregator non deve essere inserito quando nell’attributo AS PATH è presente un segmento AS-PATH di tipo AS-SET, perché questo significa che nel processo di aggregazione si tiene memoria degli AS attraversati dai prefissi aggregati

 

 

bgp atomic aggreg header

 

 

 

 

AGGREGATOR (Type Code = 7): serve per notificare ad altri BGP peer quale router ha effettuato una aggregazione dei prefissi.


E’ formato dalla coppia < AS; BGP Identifier > dove i due parametri sono riferiti al router che ha effettuato l’aggregazione di prefissi

 

bgp aggregator header

 

 

 

 

 

COMMUNITY (Type Code = 8): serve per classificare annunci BGP secondo differenti specifiche amministrative; può essere usato per:


 Assegnare un valore di LP (Local Preference) su base Community

 Definire politiche di QoS su base SLA (Service Level Agreement)

 Filtraggio dei prefissi IP come ad esempio non annunciare prefissi che hanno un particolare valore di Community 

 I valori di Community hanno un formato del tipo < AS:NN > dove AS è un numero di AS (2 byte) ed NN è un numero arbitrario (2 byte).
I valori di Community possono essere assegnati su base configurazione ed applicati per politiche sia in uscita che in ingresso del traffico.

 

Well Know Community:

NO EXPORT (0xFFFFFF01): tutti gli annunci con questo valore di Community non devono essere propagati al di fuori di un AS (non devono essere propagati quindi su sessioni E-BGP)

NO ADVERTSISE (0xFFFFFF02): tutti i prefissi con questo valore di Community non devono esseere propagati su nessuna sessione sia I-BGP che E-BGP

NO EXPORT SUBCONFED (0xFFFFFF03): sono Community utilizzate nelle Confederazioni BGP

 

bgp community header

 

 

 

EXTENDED COMMUNITY (Type Code = 16): è una versione che trova applicazioni nelle reti VPN (Virtual Private Network) IP su base BGP/MPLS.

Hanno un formato più lungo rispetto a quello Community di tipo ordinario (8 byte)

 

 

 

AS4 PATH (Type Code = 17): ha le stesse funzioni viste in precedenza con l’ attributi AS PATH.

La differenza consiste nel fatto di gestire AS di 4 byte = 32 bit (anziché di 2 byte = 8 bit); esempi di numerazione AS:

 

OBS (Old BGP Speaker):   AS = 100

NBS (New BGP Speaker): AS = 0.300

 

Le regole di peering tra un BGP speaker OBS ed uno NBS sono:

 Quando un NBS invia un messaggio update ad un OBS, inserisce entrambi gli attributi AS PATH ed AS4 PATH; il primo contiene il valore di 2 byte invariato mentre il secondo con 4 byte sono sostituiti dal numero di AS riservato 23456 (conosciuto come AS-TRANS)

 

Quando un OBS riceve un messaggio update da un NBS (oppure da un OBS), aggiorna l’attributo AS PATH secondo le regole solite dell’AS PATH e lascia passare inalterato l’attributo AS4 PATH.

Quando un NBS invia un messaggio update as un NBS, inserisce solo l’attributo AS PATH dove però i numeri di AS sono codificati a 4 byte.

Quando un NBS riceve un messaggio update da un OBS, propaga ad un BGP peer un messaggio update inserendo un AS PATH con AS codificati a 4 byte, ottenuto a partire dai due attributi AS PATH ed AS4 PATH ricevuti; il nuovo attributo AS PATH quindi, si ottiene a partire dall’AS PATH corrente, sostituendo ai valori 23456 presenti i corrispondenti valori di AS con 4 byte.

 

 

as4 path example

 

 

 

 

 

AS4 AGGREGATOR (Type Code = 18): ha le stesse funzioni viste in precedenza con l’ attributo AS-AGGREGATOR.

La differenza consiste nel fatto di gestire AS di 4 byte = 32 bit (anziché di 2 byte = 8 bit); esempi di numerazione AS:

 

OBS (Old BGP Speaker):   AS = 100
NBS (New BGP Speaker): AS = 0.300

 

Le regole di peering tra un BGP speaker OBS ed uno NBS sono:

 

Un NBS che effettua una aggregazione di prefissi genera verso un OBS entrambi gli attributi AGGREGATOR ed AS4 AGGREGATOR; se l’AS di appartenenza del NBS è di 4 byte, inserisce nell’attributo AGGREGATOR il numero fittizio 23456

 

Un NBS che riceve da un OBS entrambi gli attributi, ignora l’attributo AGGREGATOR

 

Un NBS che effetta una aggregazione di prefissi genera verso un NBS un attributo AGGREGATOR con un valore a 4 byte

 

 

as4 aggregator example

 

 

 

 

 

 

MP_REACH_NLRI (Type Code = 14) and MP_UNREACH_NLRI (Type Code = 15): utilizzati dal MP-BGP ed hanno i seguenti campi:


ADDRESS FAMILY IDENTIFIER (2 byte): è il codice AFI che identifica la famiglia di indirizzi di cui propagare le informazioni di routing

 

SUBSEQUENT AFI (1 byte): è il codice SAFI che fornisce più informazioni riguardo la famiglia di indirizzi di cui propagare le informazioni di routing

 

LENGHT of NEXT HOP NETWORK ADDRESS (1 byte): è la lunghezza del campo Network Address of Next Hop

 

NETWORK ADDRESS of NEXT HOP (variabile): contiene l’indirizzo Next Hop nel formato specificato dal codice AFI, associato ai NLRI specificati nel campo Network Layer Reachability Information

 

NLRI (NETWORK LAYER REACHABILITY INFORMATION): contiene uno o più NLRI nel formato specificato dai codici AFI/SAFI.

 

Esempi di codifica AFI / SAFI:

AFI / SAFI = 1/1 = identifica prefissi IPv4 unicast
AFI / SAFI = 1/2 = identifica prefissi IPv6 unicast

 

Il Formato del campo Capability BGP Multi Protocol è il seguente:

 

AFI (Address Family Identifier): identifica il tipo di informazioni di routing (L3) che in BGP peer vuole propagare

Reserved: 0x00

SAFI (Subsequence Address Family Identifier): fornisce maggiori informazioni circa la famiglia specificata nel campo AFI.

 

 

mp bgp reach nlri header

 

 

Un messaggio UPDATE che includa il MP-REACH-NLRI deve contenere sempre gli attributi ORIGIN ed AS-PATH sia per sessioni E-BGP che I-BGP dove per quest’ultimo deve contenere anche l’attributo Local-Preference.

 

Se il messaggio UPDATE contiene solo il valore NLRI in MP-REACH-NLRI, non deve essere incluso l’attributo NEXT-HOP; qualora fosse incluso viene ignorato dai router peer che ricevono il messaggio UPDATE

 

 

 

CLUSTER-LIST (Type Code = 10): è utilizzato dai Router Reflector.

 

Uno o più RR con i propri RR-Client forma un cluster, identificato dal Cluster-ID (4 byte)

 

Gli I-BGP peers di un RR possono essere divisi in due classi:

Client Peer (RR Client): sono i peers a cui il RR riflette gli annunci BGP ricevuti
Non-Client Peer: sono normali peer del RR e per ricevere tutti gli annunci devono per forza avere tra loro una maglia completa di sessioni IBGP tra loro.

 

 

 

ORIGINATOR-ID (Type Code = 9): è utilizzato dai Router Reflector.


Specifica il BGP RID del router che origina un prefisso all’interno di un AS.

Viene creato automaticamente dal primo RR che riceve l’annuncio e propagato solo all’interno di un AS.

 

Le regole generali sono:

 

Un RR non può creare un attributo ORIGINATOR_ID se già contenuto nell’annuncio
Un BGP speaker che riconosce l’attributo ORIGINATOR_ID deve ignorare l’annuncio se il valore di ORIGINATOR_ID coincide con il proprio BGP RID

 

 

 

 

Torna in alto