Avendo specificato le problematiche principali che deve affrontare da un punto di vista concettuale BGP, vediamo ora come è realizzato il protocollo per rendere possibile quanto descritto.

Talvolta BGP viene definito un protocollo di routing “path vector”, poiché il suo principale compito è annunciare rotte. In particolare BGP non fa altro che annunciare agli AS vicini, quali AS sono raggiungibili tramite quell'AS e attraverso quale percorso, indicato sempre in termini di AS attraversati.

Un tipico messaggio di dichiarazione rotte BGP conterrà quindi le destinazioni raggiungibili e gli AS da attraversare per raggiungere quelle destinazioni.

In Figure 15 è mostrato un esempio di scambio messaggi BGP. Premettiamo che non sono rappresentati tutti i messaggi scambiati, ma, per chiarezza, solo un sottoinsieme. In particolare, supponiamo che AS3 stia annunciando la rotta per raggiungere le destinazioni 1.0.0.0/8 che sono corrispondenti ad una sottorete presente al suo interno. AS3 manda dunque un messaggio per comunicare la presenza di questa rotta per la destinazione 1.0.0.0/8. La rotta in questo caso è semplicemente AS3, poiché AS3 sta annunciando una sua sottorete. Gli AS confinanti ottengono questa informazione e, se per loro è una nuova rotta, provvedono ad informare anche i loro vicini della presenza di questa nuova rotta. Ogni AS aggiunge il suo identificativo nel campo PATH del messaggio, poiché dichiara una rotta che deve attraversare se stesso per raggiungere la destinazione finale.

E' interessante vedere come BGP abbia due meccanismi per supportare le policy: quando un AS ha più rotte per la stessa destinazione, seleziona quale annunciare all'esterno in base alla sua policy amministrativa. Ad esempio, AS4 avrebbe potuto annunciare ad AS7 la rotta AS4,AS3 ma per qualche sua policy ha invece annunciato la rotta AS4,AS1,AS3. Il secondo meccanismo permette ad un AS anche di non annunciare affatto la nuova rotta ricevuta, in base a considerazioni analoghe a quelle fatte nel precedente paragrafo.

La presenza del PATH garantisca la possibilità di evitare loop nell'instradamento dei pacchetti, poiché ogni AS può controllare la rotta seguita. Inoltre, questo da' la possibilità di garantire possibilità di decisione, in base alle policy di natura amministrativa, di quale percorso seguire.

Viene a questo punto spontaneo chiedersi da dove BGP impari nuove rotte da annunciare. L'esempio precedente dimostra chiaramente che una parte delle rotte sono imparate dagli altri AS. Ma, ad esempio, cosa ha permesso ad AS3 di conoscere la rotta per 1.0.0.0/8?

In realtà BGP impara le rotte in altri due modi:

• Static configuration: le rotte da dichiarare sono impostate manualmente. Questo garantisce una solida stabilità ma, per contro, ogni aggiornamento va fatto manualmente richiedendo dunque un ingente tempo;

• Learned from IGP: è anche possibile che le rotte da annunciare siano conosciute apprendendole tramite il protocollo di routing IGP, chiaramente BGP dichiara poi aggregati delle destinazioni così apprese. Questa soluzione permette a BGP di seguire lo stato della rete e aggiornare le rotte in base alla comparsa di nuovi percorsi o alla scomparsa di altri, ad esempio a seguito della caduta di un link. Lo svantaggio è che se il protocollo IGP presenta una certa instabilità per via di condizioni mutevoli frequenti della rete, anche BGP diviene instabile, con conseguente crescita del traffico di overhead del protocollo, poiché ogni messaggio di aggiornamento BGP genera messaggi a cascata negli AS.

Avendo definito per sommi capi il funzionamento di segnalazione delle rotte di BGP, possiamo definire un'architettura di massima di un router BGP, tale architettura è riportata in Figure 16:

Gli import filter definiscono i messaggi BGP accettabili dal peer per cui sono definiti, tutte le possibili rotte vengono poi esaminate dal processo decisionale BGP, assieme alle rotte apprese tramite il protocollo di routing IGP, per selezionare fra questi quali sono quelle migliori per una data destinazione. Infine, queste rotte sono comunicate ai filtri di uscita che selezionano gli annunci di rotta che possono essere fatti al particolare peer per cui sono definiti quegli export filter.