La future local-as consente ad un  apparato di apparire membro di un secondo AS in aggiunta al suo reale AS.

Tale future può essere utilizzata solo per peer ebgp. Supponiamo quindi di avere la seguente situazione (riportata nel diagramma sottostante) in cui nel dominio 65535 vogliamo che il device R1 per il neighbor 89.96.14.217 appartenga all’AS 198319.

             

Se R2 punterà sempre all’AS 198319 nel caso di R1 avremo la seguente configurazione.

router bgp 65535

!

neighbor 89.96.14.217 local-as 198319 

In questo caso un eventuale update verso R2 (es rotta 50.1.1.1/24) l’AS path sarà composto da AS_LOCAL + AS_REAL, per le rotte ricevute invece sarà LOCAL_AS  + AS_PEER_REMOTO

R2#show bgp

Fri Apr 12 09:53:42.702 MET

BGP router identifier 10.252.20.56, local AS number 15500

BGP generic scan interval 60 secs

Non-stop routing is enabled

BGP table state: Active

Table ID: 0xe0000000   RD version: 8494826

BGP main routing table version 8494826

BGP NSR Initial initsync version 2100187 (Reached)

BGP tunnel nexthop version 1

BGP scan interval 60 secs

Status codes: s suppressed, d damped, h history, * valid, > best

              i - internal, r RIB-failure, S stale 

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network            Next Hop            Metric LocPrf Weight Path

*> 50.1.1.0/24        82.149.32.2              0             0 198319 65535 ?

*> 82.149.32.2/32     82.149.32.2              0             0 198319 65535 ?

                                                                                                                                          

R2#show bgp

     Network          Next Hop            Metric LocPrf Weight Path

 *>  2.228.29.68/30   0.0.0.0                  0         32768 ?

 *>  7.30.0.252/32    89.96.14.217         65546             0 198319 15500 ?

 *>  7.30.0.253/32    89.96.14.217         65546             0 198319 15500 ?

 *>  7.30.0.254/32    89.96.14.217         65546             0 198319 15500 ?

 *>  7.30.0.255/32    89.96.14.217         65546             0 198319 15500 ?

Se per le rotte ricevute non voglio aggiungere il LOCAL_AS devo utilizzare keyword  “no-prepend”

router bgp 65535

!

neighbor 89.96.14.217 local-as 198319  no-prepend

R1#show bgp

BGP table version is 106, local router ID is 10.0.0.254

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,

              x best-external, a additional-path, c RIB-compressed,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path

 *>  2.228.29.68/30   0.0.0.0                  0         32768 ?

 *>  7.30.0.252/32    89.96.14.217         65546             0 15500 ?

 *>  7.30.0.253/32    89.96.14.217         65546             0 15500 ?

 *>  7.30.0.254/32    89.96.14.217         65546             0 15500 ?

Se nell’update verso R2 non voglio che il REAL_AS (65535) si aggiunto dobbiamo utilizzare “replace-as”.

router bgp 65535

!

neighbor 89.96.14.217 local-as 198319  no-prepend replace-as

R2#show bgp 

Fri Apr 12 10:03:23.289 MET

BGP router identifier 10.252.20.56, local AS number 15500

BGP generic scan interval 60 secs

Non-stop routing is enabled

BGP table state: Active

Table ID: 0xe0000000   RD version: 8494858

BGP main routing table version 8494858

BGP NSR Initial initsync version 2100187 (Reached)

BGP tunnel nexthop version 1

BGP scan interval 60 secs

*> 50.1.1.0/24        82.149.32.2              0             0 198319 ?

*> 82.149.32.2/32     82.149.32.2              0             0 198319

La “capability” multisession consente al BGP di avere multiple sessioni BGP (quindi multiple conessioni TCP) tra una coppia di speekers, anche se esiste solo un stato di “neighbor”

La “mulitsession capability” è scambiata nei messaggi di “Open” all’atto dell’instaurazione sessione BGP come mostrato nell’output sottostante.

R1#debug ip bgp 10.100.1.2
BGP debugging is on for neighbor 10.100.1.2 for address family: IPv4 Unicast
  
We clear the BGP session.

BGP: 10.100.1.2 passive rcv OPEN, version 4, holdtime 180 seconds
BGP: 10.100.1.2 passive rcv OPEN w/ OPTION parameter len: 35
BGP: 10.100.1.2 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 4
BGP: 10.100.1.2 passive OPEN has CAPABILITY code: 132, length 2
BGP: 10.100.1.2 passive OPEN has TID CAP for:  2
BGP: 10.100.1.2 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6
BGP: 10.100.1.2 passive OPEN has CAPABILITY code: 1, length 4
BGP: 10.100.1.2 passive OPEN has MP_EXT CAP for afi/safi: 1/1
BGP: 10.100.1.2 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 2
BGP: 40.50.1.1 passive OPEN has CAPABILITY code: 128, length 0
BGP: 40.50.1.1 passive OPEN has ROUTE-REFRESH capability(old) for all address-families
BGP: 40.50.1.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 2
BGP: 40.50.1.1 passive OPEN has CAPABILITY code: 2, length 0
BGP: 40.50.1.1 passive OPEN has ROUTE-REFRESH capability(new) for all address-families
BGP: 40.50.1.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 3
BGP: 40.50.1.1 passive OPEN has CAPABILITY code: 131, length 1
BGP: 40.50.1.1 passive OPEN has MULTISESSION capability, without grouping
BGP: 40.50.1.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6
BGP: 40.50.1.1 passive OPEN has CAPABILITY code: 65, length 4
BGP: 40.50.1.1 passive OPEN has 4-byte ASN CAP for: 1
BGP: nbr global 40.50.1.1 neighbor does not have IPv4 MDT topology activated
BGP: 40.50.1.1 passive rcvd OPEN w/ remote AS 1, 4-byte remote AS 1

R1#show ip bgp neighbors 10.100.1.2
BGP neighbor is 10.100.1.2,  remote AS 1, internal link

  Neighbor capabilities:
    Route refresh: advertised and received(new) on session 1, 2, 3
    Four-octets ASN Capability: advertised and received on session 1, 2, 3
    Address family IPv4 Unicast: advertised and received
    Multisession Capability: advertised and received

Se vogliamo avere una sessione strettamente per neighobr possiamo utilizzare il comand “transport multi-session”

R1#sh run | s bgp
router bgp 1
neighbor 10.100.1.2 remote-as 1
neighbor 10.100.1.2 transport multi-session
neighbor 10.100.1.2 update-source Loopback0
!
address-family ipv4
  neighbor 10.100.1.2 activate
exit-address-family
!
address-family vpnv4
  neighbor 10.100.1.2 activate
  neighbor 10.100.1.2 send-community extended
exit-address-family
!
address-family ipv6
  neighbor 10.100.1.2 activate
exit-address-family

R2#

BGP: 10.100.1.1 passive open to 10.100.1.2

...

BGP: 10.100.1.1 passive OPEN has CAPABILITY code: 1, length 4
BGP: 10.100.1.1 passive OPEN has MP_EXT CAP for afi/safi: 1/1

...

BGP: 10.100.1.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 3
BGP: 10.100.1.1 passive OPEN has CAPABILITY code: 131, length 1
BGP: 10.100.1.1 passive OPEN has MULTISESSION capability, without grouping

BGP: ses global 10.100.1.1 (0x461CC60:0) pas Adding topology IPv4 Unicast:base

%BGP-5-ADJCHANGE: neighbor 10.100.1.1 Up

BGP: 10.100.1.1 passive open to 10.100.1.2

...

BGP: 10.100.1.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6
BGP: 10.100.1.1 passive OPEN has CAPABILITY code: 1, length 4
BGP: 10.100.1.1 passive OPEN has MP_EXT CAP for afi/safi: 2/1

...

                

Cosa è il Route Target e Route Distinghisher

In questo primo articolo tratteremo del concetto di Route Target e Route Distighisher.

MPLS VPN offre la possibilità di utilizzare lo stesso backbone MPLS per diversi clienti o servizi senza l'interagire uno con l'altro. E 'abbastanza comune trovare diversi clienti che utilizzano la stessa gamma di indirizzi IP privati​​. Come può una società di provider di servizi Internet offrire  connettività a diversi siti remoti al cliente "Masso" e al cliente "NE" senza uniformare le loro informazioni di routing? 

Di qui la necessità di utilizzare lo stesso schema di indirizzamento per sedi dislocate in zone non fisicamente contigue.

Con il Route Distinguisher , trasformiamo un indirizzo IP di 32 bit di lunghezza in un indirizzo di 96 bit di lunghezza, univoco nella rete. Quindi PEs non annunciaranno indirizzi IP di lunghezza 32 ma indirizzi di 96 bit attraverso il Multiprotocol BGP.

Il  formato del rd può essere di due tipi:

1.  ASN: nn o indirizzo
2.  IP: nn. 

Si deve però ricordare che valori rd/VRFname  hanno valore locale; ciò che conta davvero è come esportiamo la rotta , perché questo è quello che consente di importare o esportare. 

Sorge quindi spontanea la domanda: si deve utilizzare lo stesso rd tra due siti remoti? o è meglio avere due RD diversi?

Per capire quale soluzione scegliere analizziamo l'architettura riportata in foto in cui il Site 1 è una sede ridondata.

Situazione 1 - Su entrambi i PE è configurato il medesimo rd

Se su entrambi i PE il rd è configurato nel medesimo modo i prefissi

sui due link saranno univoci. Il RR metterà solo uno dei due prefissi nel suo update. In tal modo perdiamo in tempi di convergenza e in carico bilanciato (qualora sia una situazione desiderata).

Situazione 2 - Su entrambi i PE sono configurarti diversi rd 

In tal caso al RR arriveranno due prefissi differenti di 96 bit che verranno riflessi entrambi garantendo, nel caso sia voluto, carico bilanciato e tempi di convergenza minori.

Il Route Target è una extended community di 64 bit che serve a fare il tagging delle rotte bgp consentendo l'export e l'import delle rotte.

ip vrf multicast_vpn
 rd 1512:2012
 route-target export 1512:2012
 route-target import 1512:2012
 mdt default 239.0.0.1

L'esempio di configurazione sta a significare che le rotte annunciata dal Multiprotocol BGP saranno esportate con le community  "1512:2012" mentre saranno importate localmente solo le rotte con community "1512:2012".

Nel prossimo articolo vedremo come fare il "write"  o aggiungere un RT