La scorsa volta abbiamo terminato la configurazione delle interfacce traffic-eng, a questo punto non ci resta che configurare BGP e (finalmente!) BGPVPLS.
Iniziamo quindi con la configurazione del BGP:
# West
/routing bgp instance
set default as=65000 router-id=192.0.2.240
/routing bgp peer
add address-families=l2vpn name=peer1 remote-address=192.0.2.250 remote-as=65000 update-source=192.0.2.248
add address-families=l2vpn name=peer2 remote-address=192.0.2.251 remote-as=65000 update-source=192.0.2.249
# East
/routing bgp instance
set default as=65000 router-id=192.0.2.243
/routing bgp peer
add address-families=l2vpn name=peer1 remote-address=192.0.2.248 remote-as=65000 update-source=192.0.2.250
add address-families=l2vpn name=peer2 remote-address=192.0.2.249 remote-as=65000 update-source=192.0.2.251Nota: abbiamo configurato i peer specificando solo l2vpn tra le address-families: questo significa che da queste sessioni non arriveranno annunci relativi ad IPv4/v6, ma solo informazioni relative alle interfacce VPLS.
La configurazione è piuttosto semplice, dopo aver impostato ASN e router-id, procediamo con la configurazione dei peer utilizzando gli indirizzi di loopback che abbiamo dedicato alle interfacce VPLS. BGP verifica che l'indirizzo IP sorgente della connessione corrisponda con quello configurato: di conseguenza vanno "incrociati" come nell'esempio sopra.
Dovremmo a questo punto vedere le sessioni in stato established:
[admin@East] > ro bgp peer print
Flags: X - disabled, E - established
# INSTANCE REMOTE-ADDRESS REMOTE-AS
0 E default 192.0.2.248 65000
1 E default 192.0.2.249 65000Le sessioni sono state stabilite, quindi tutto ok fin qui ! Possiamo quindi ultimare la configurazione, configurando BGPVPLS
# West
/interface vpls bgp-vpls
add export-route-targets=1:1 import-route-targets=1:1 name=via_north route-distinguisher=1:1 site-id=1
add export-route-targets=1:2 import-route-targets=1:2 name=via_south route-distinguisher=1:2 site-id=1
# East
/interface vpls bgp-vpls
add export-route-targets=1:1 import-route-targets=1:1 name=via_north route-distinguisher=1:1 site-id=2
add export-route-targets=1:2 import-route-targets=1:2 name=via_south route-distinguisher=1:2 site-id=2La spiegazione dei parametri *-route-targets e route-distinguisher esulano dallo scopo di questa serie e avrebbero bisogno di un post a parte. Per il nostro caso d'uso possiamo impostarli tutti uguali per ogni interfaccia, avendo cura di incrementare il secondo numero (1:1, 1:2, 1:3, etc.).
Ognuno di questi comandi fa si che il router annunci, su tutte le sessioni BGP abilitate per l2vpn (vedi sopra), la disponibilità a stabilire delle sessioni VPLS.
A questo punto dovremmo avere attive entrambe le interfacce:
[admin@West] > int vpls print
Flags: X - disabled, R - running, D - dynamic, B - bgp-signaled, C - cisco-bgp-signaled
0 RDB name="vpls12" mtu=1500 l2mtu=1500 mac-address=02:78:03:81:9F:BD arp=enabled arp-timeout=auto disable-running-check=no remote-peer=192.0.2.251 cisco-style=no
cisco-style-id=0 advertised-l2mtu=1500 pw-type=raw-ethernet use-control-word=yes vpls=via_south
1 RDB name="vpls13" mtu=1500 l2mtu=1500 mac-address=02:D5:8F:A5:DE:DA arp=enabled arp-timeout=auto disable-running-check=no remote-peer=192.0.2.251 cisco-style=no
cisco-style-id=0 advertised-l2mtu=1500 pw-type=raw-ethernet use-control-word=yes vpls=via_northResta solo un problema da risolvere: le interfacce sono salite entrambe, tuttavia il remote-peer è lo stesso...di conseguenza è presumibile che passino entrambi dallo stesso TE-TUNNEL (ricordiamo infatti che il TE tunnel del VPLS viene scelto proprio in base al remote address). Verificando meglio, infatti:
[admin@West] /interface vpls> monitor [find]
remote-label: 33 17
local-label: 34 18
remote-status:
transport: East_via_South East_via_South
transport-nexthop: 192.0.2.6 192.0.2.6
imposed-labels: 20 20
33 17Vediamo come entrambe le interfacce siano UP, ma il traffico transita in entrambi i casi dal south! Per quale motivo?
La risposta è che in questo momento stiamo annunciando entrambi i VPLS su entrambi i peer, di conseguenza la scelta del nexthop è demandata all'algoritmo di selezione di BGP...che in questo caso sceglie la prima "rotta" imparata e usa solo quella. Come si può fare per risolvere il problema? La risposta è semplice: utilizziamo i filtri BGP sui peer, annunciando in uscita, per ogni sessione, solo un BGPVPLS.
# West
/routing filter
add action=discard chain=north-out route-targets=!1:1
add action=discard chain=south-out route-targets=!1:2
/routing bgp peer
set [find where remote-address=192.0.2.250] out-filter=north-out
set [find where remote-address=192.0.2.251] out-filter=south-out
# East
/routing filter
add action=discard chain=north-out route-targets=!1:1
add action=discard chain=south-out route-targets=!1:2
/routing bgp peer
set [find where remote-address=192.0.2.248] out-filter=north-out
set [find where remote-address=192.0.2.249] out-filter=south-outRiavviamo le sessioni BGP (è sufficiente farlo da uno solo dei due lati) e verifichiamo che tutto funzioni come ci aspettiamo:
[admin@West] > routing bgp peer disable [find] ; routing bgp peer enable [find]
[admin@West] > interface vpls monitor [find] once
remote-label: 17 33
local-label: 18 34
remote-status:
transport: East_via_North East_via_South
transport-nexthop: 192.0.2.2 192.0.2.6
imposed-labels: 23 20
17 33
[admin@East] > int vpls monitor [find]
remote-label: 18 34
local-label: 17 33
remote-status:
transport: West_via_North West_via_South
transport-nexthop: 192.0.2.9 192.0.2.13
imposed-labels: 20 17
18 34 Missione compiuta! Le interfacce sono entrambe UP e fanno effettivamente due percorsi distinti.
A questo punto possiamo utilizzarle come meglio crediamo, inserendole magari in bridge distinti od utilizzandole in bonding.