Login 
BGP labeled-unicast definizione
22.03 2022 | by massimilianoBGP conosciuto anche come vanilla-BGP è un protocollo in grado di annunciare (advertising) IPv4 Prefix; la possibilità di estendere gli […]
https://www.ingegnerianetworking.com/wp-content/uploads/2022/03/bgp-lu-dc1-5e8.png
BGP conosciuto anche come vanilla-BGP è un protocollo in grado di annunciare (advertising) IPv4 Prefix; la possibilità di estendere gli annunci anche per altri protocolli il BGP fa riferimento al Multi-Protocol BGP dove è in grado di annunciare e ruotare non solo IPv4, ma anche IPv6, Multicast come pure MAC addresses e Label Mapping.
Allo stesso modo di IPv4 (vanilla-BGP), anche la versione Multi-Protocol fa leva sullo scambio di NLRI (Network Layer Reachability Information) trasportando così un insieme di informazioni codificate in esso.
Ciascun NLRI ha un suo identificativo conosciuto con la coppia di AFI e SAFI.
AFI = Address Family Identifier
SAFI = Subsequence Address Family Identifier
Esempio:
IPv4 unicast significa AFI = 1 SAFI =1
IPv6 unicast significa AFI = 2 SAFI = 1
Per la parte BGP-LU questi valori assumono: AFI = 1 SAFI = 4 dove appunto NLRI contiene l’informazione riguardante il label-mapping (RFC 3107)
BGP-LU ha tante applicazioni in termini di network design quali VPN, MPLS in datacenter (in questo caso il design viene conosciuto come MPLS Fabric viceversa da IP Fabric) oppure Seamless MPLS.
BGP quindi è il protocollo de-facto per i moderni datacenter a Fabric per la parte di control-plane per la comunicazione al suo interno (Spine Leaf)
EBGP è preferito a IBGP per motivi di meglior capacità di multipath e loop-detection.
Un esempio di design può essere questo:
Tutti i nodi MPLS-enabled stabiliscono sessioni single-hop external BGP-LU con i nodi adiacenti (simile al concetto IGP+LDP peer), mentre la parte vanilla-BGP stabilisce sessioni multi-hop EBGP di servizio.
L’utilizzo di Community permette poi i corretti annunci di host/prefix (loopback addresses)
Aspetti di configurazione:
Cisco IOS-XR considera la label come una proprietà addizionale dell’IP unicast routes.
Junos considera sia la versione labeled unicast che unlabeled unicast routes come proprietà differenti mantenendole in differenti tabelle di routing:
- – inet.0 per IPv4 global routing table (FIB and IP routing quali IGP e vanilla-BGP)
- – inet.3 per BGP next-hop resolution ed in generale popolata da protocolli di segnalazione (LDP, RSVP, IGP, Spring-enables)
BGP-LU installa prefissi in inet.0 ed importa prefissi sempre da inet.0 per re-advertising; come opzione possiamo esplicitare una configurazione o parte di essa per copiare prefix all’interno della inet.3 abilitando il BGP next-hop resolution per servizi MPLS
BGP-LU installa prefissi in inet.3 ed importa prefissi sempre da inet.3 per re-advertising; come opzione possiamo esplicitare una configurazione o parte di essa per copiare prefix all’interno della inet.0 abilitando IPv4 forwarding con labeled next-hop verso questi prefissi.
Esempio di configurazione BGP-LU in inet.3 routing table
ESEMPIO di CONFIG JUNOS:
1° step è quello di copiare a PE level la local loopback address da inet.0 (dove risiede per default) a inet.3 in modo che BGP-LU possa re-annunciarla.
policy-option {
policy-statement PS-MY-LOOPBACK
term MY-LOOPBACK
from interface lo0.0
then {
metric 0;
origin incomplete;
community add Com-Server;
accept;
}
}
term DIRECT
from protocol direct;
then reject;
}
}
community Com-Server member 65301:3
}
routing-option {
interface-routes
rib-group inet RO-MY-LOOPBACK;
}
rib-groups {
RO-MY-LOOPBACK {
import-rib [ inet.0 inet.3 ];
import-policy PS-MY-LOOPBACK
Stessa configurazione è prevista lato RR level con una different community Com-RR
Una rib-groups è vista come un template contenente una lista ordinata in termini di RIB dove la prima è la inet.0 (dove risiede il prefisso da copiare) all’interno della seconda RIB inet.3
La rib-groups è poi applicata al protocollo oppure come in questo caso ad una interface route; il risultato è quello di aver copiato l’indirizzo 172.16.3.11/32 (PE1) o 172.16.3 .22/32 (PE2) da inet.0 a inet.3
La policy PS-MY-LOOPBACK performa una selezione selettiva di cosa andare a copiare; viceversa tutte le interface routes sarebbero state copiate.
NOTA:
di default in Junos il valore di MED (Multi Exit Discrimator) è nullo mentre per Cisco IOS-XR il valore = 0; la policy setta il valore di MED = 0 per consistenza tra differenti vendors
di default il valore di origin sia per Junos che IOS-XR è igp ed incomplete; la policy setta il valore su incomplete.
2° step è quello di assegnare la label alla route ed annunciarla come BGP-LU
protocol bgp {
group EBGP-LU-65201 {
family inet {
labeled-unicast {
per-prefix-labels;
rib {
inet.3;
}
}
export PS-MY-LOOPBACK
peer-as 65201
neighbor 10.0.0.1
Nota: per-prefix-label è simile (equivalente) al significato di LDP deaggregate; è raccomandato in BGP-LU per migliorare tempi di convergenza.
Con queesta seconda parte di configurazioni il risultato è quello di annunciare la sua loopback labeled verso P1 (o P2).
Facendo il comando “show route advertising-protocol bgp 10.0.0.1 possiamo notare come la prefix sia annunciata con un valore di label (in questo caso con il valore di label = 3 implicit null label abilitando il ruolo di PHP (Penultimate Hop Popping)
ESEMPIO di CONFIG IOS-XR:
route-policy PS-MY-LOCAL
if destination in (172.16.3.11) then
set community Com-Server
pass
endif
end-policy
!
route-policy PS-MY-LOOPBACK
if community matches-any Com-Server then
pass
else
drop
endif
end-policy
!
route-policy PS-ALL
pass
end-policy
!
community Com-Server
65301:3
end-set
!
router bgp 65301
mpls activate
interface te0/0/0/1
!
address-family ipv4 unicast
redistribute connected route-policy PS-MY-LOCAL
allocate-label all
!
neighbor 10.0.0.1
remote-as 65201
address-family ipv4 labeled-unicast
send-community-ebgp
route-policy PS-MY-LOOPBACK out
route-policy PS-ALL in
!
router static
address-family ipv4 unicast
10.0.0.1/32 Te0/0/0/1