Utilizza GTM (Global Table Multicast) non segmentato per mVPN
Sommario
Introduzione
Questo documento descrive la tabella globale multicast (GTM) non segmentata per mVPN.
Prerequisiti
Requisiti
Nessun requisito specifico previsto per questo documento.
Componenti usati
Il documento può essere consultato per tutte le versioni software o hardware.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Premesse
NG mVPN (RFC 6513/6514) ha molti profili. La maggior parte dei profili dispone di VPN (Virtual Private Network) o VRF (Virtual Routing/Forwarding) sui router PE. Alcuni profili (profili 7 e
Sia la RFC 7524 che la RFC 7716 (draft-ietf-band-mvpn-global-table-mcast) richiedono che gli indirizzi di origine GTM siano raggiungibili tramite route unicast BGP (unicast IPv4 della famiglia di indirizzi o multicast IPv4 della famiglia di indirizzi).
Il vantaggio della bozza draft-ietf-bess-mvpn-global-table-mcast rispetto alla RFC 7524 è che vengono mantenute le stesse procedure utilizzate per la normale RFC 6514 (NG mVPN).
Con GTM, la mVPN può essere non segmentata o segmentata.
Architettura
In questo articolo, il termine router di confine viene usato per un router ABR, ASBR o Aggregation, che connette due segmenti della rete. In genere, ABR si trova in reti MPLS senza interruzioni. L'ASBR viene utilizzato quando si utilizza una VPN MPLS Inter-AS. Inoltre, il router di aggregazione viene utilizzato quando un router di overlay GTM non segmentato connette le due parti della rete principale, quando una delle due parti esegue un protocollo albero principale multicast diverso. Ad esempio, il router di aggregazione può connettere la parte PIM della rete principale con la parte mLDP della rete principale.
Per qualsiasi modello, è possibile utilizzare il SAFI 2. Il vantaggio è che SAFI 2 può avere una topologia diversa rispetto a SAFI 1. È quindi possibile modificare la RPF per il multicast senza modificare l'inoltro unicast.
Un router di confine non supporta l'incapsulamento doppio. Ciò significa che il router non può inoltrare il multicast su due protocolli core-tree o in modalità diversa contemporaneamente. Questa opzione può essere utilizzata in genere quando si esegue la migrazione da un albero principale a un altro. Durante la migrazione, il file PE in entrata viene inoltrato su entrambi gli alberi centrali. Ciò non è possibile sui router di confine.
L'architettura GTM supporta GTM non segmentati e segmentati. Il presente documento si riferisce esclusivamente al GTM non segmentato.
Le procedure per la sovrapposizione GTM non segmentata sono quelle descritte in draft-ietf-bess-mvpn-global-table-mcast. Vengono seguite le stesse procedure descritte nella RFC 6513/6514 con alcune modifiche.
Quali sono le modifiche apportate alla RFC 6513/6514?
Con GTM, si applicano i punti seguenti. Alcuni di essi sono uguali a quelli della RFC 6513/6514, altri sono diversi.
- Selezione inoltro singolo (SFS) non supportata.
- AF IPv6 è supportato.
- È supportata la segnalazione C-PIM e C-BGP.
- Sulle interfacce dei router PE rivolte verso il bordo non è presente alcun VRF. Queste interfacce sono ora globali. Questi router sono noti come Protocol Boundary Router (PBR) nel draft-ietf-bess-mvpn-global-table-mcast. Questi router si interfacciano tra un protocollo LSM Core Tree e un PIM. Questi router li chiamiamo router di confine.
- La rete principale esegue un protocollo LSM (Label Switched Multicast).
- sono supportati mLDP, P2MP TE (statico e dinamico) e IR.
- Sono supportati MDT di dati, partizionati e predefiniti
- Poiché non esistono prefissi VPNv4/6 in GTM, i prefissi VRF Route-Import EC e Source-AS EC sono collegati ai prefissi IPv4 unicast (SAFI 1) o multicast (SAFI 2).
I tipi di route 1, 3 e 5 dispongono di RT. In Cisco IOS® XR questi RT devono essere presenti per GTM, anche se non è richiesto dalla bozza. Affinché GTM possa essere utilizzato, è necessario configurare gli RT in BGP. Questi RT sono simili agli RT utilizzati nei VRF per le mVPN regolari, ma si applicano ora al contesto globale.
I router di tipo 4, 6 e 7 sono dotati di una funzionalità RT che identifica il router PE upstream. Il campo Amministratore globale corrisponde all'indirizzo IP del file PE a monte. Il campo dell'amministratore locale è impostato su 0 per GTM (identifica il VRF in una mVPN non GTM o normale).
I router PE diventano i router di interconnessione tra un protocollo LSM (Label Switched Multicast), mLDP (Core Tree Protocol), P2MP Traffic Engineering, Ingress Replication (IR) e PIM. Quindi, c'è una parte della rete centrale che esegue LSM e noi abbiamo una parte della rete centrale che esegue PIM. Chiamiamo i router principali che agiscono come interfaccia tra la parte LSM della rete e la parte PIM della rete, i router di confine. In alcuni degli esempi seguenti, questi router sono denominati router C-PE (C per Core).
Questi router di confine sono i router con la configurazione necessaria per il GTM. Nessuno degli altri router riconosce il GTM.
La configurazione per GTM è simile a quella richiesta per i normali profili mVPN. Le interfacce verso lo spigolo non sono in un VRF.
Non è disponibile un identificatore di route standard, poiché non sono presenti VRF. Poiché non esistono distintori di route (RD) regolari, ma i RD vengono utilizzati quando si segnala con BGP, i RD di tutti gli zeri e i RD di tutti gli uno vengono utilizzati per la segnalazione in GTM. Per disporre di questa funzionalità, è necessario configurare il comando BGP global-table-multicast.
Con GTM, le route unicast non sono in VPNv4/6. Pertanto, la raggiungibilità unicast deve essere fornita in BGP in AF IPv4 o AF IPv6 e SAFI 1 o SAFI 2. Ciò significa che è ancora necessario utilizzare BGP tra i router di confine (router PE senza VRF).Fare riferimento all'immagine 1.
Immagine 1
Tra il confine e i router CE, non è presente alcun BGP. Il router di confine aggiunge gli attributi multicast quando annuncia le route in iBGP verso gli altri router di confine.
È importante notare che potrebbe essere presente BGP tra i router CE e PE. Fare riferimento all'immagine 2.
Immagine 2
In questo caso, il router PE aggiunge gli attributi multicast quando inoltra le route unicast da eBGP a iBGP, verso gli altri router PE. Se il CE ha annunciato le route unicast con attributi multicast già al router PE, il router PE mantiene gli attributi multicast così come sono e inoltra le route unicast agli altri router PE. Per impostazione predefinita, per le sessioni eBGP, gli attributi multicast vengono rimossi. Pertanto, quando le route PE pubblicizzano le route unicast da iBGP in eBGP alle route CE, non vi sono attributi multicast.
Quando il router PE annuncia il prefisso unicast tramite iBGP, collega la VRF Route Import (VRF-RI) della community estesa (EC) e la Source-AS della CE. L'altro router PE rimuove questi elementi prima di propagare queste route in eBGP.
Quando la sessione eBGP è tra due ASBR, sono presenti una VPN MPLS Inter-AS e una mVPN Inter-AS. In questo caso, è possibile mantenere gli attributi multicast. Poiché il comportamento predefinito prevede la loro rimozione nella sessione eBGP, è necessario configurare il comando send-multicast-attributes sulla sessione eBGP tra le due ASBR.
Nei casi in cui si dispone di un RR, può esserci una propagazione da iBGP a iBGP. Questo è il caso della versione inline-ABR (there is next-hop-self) di Seamless MPLS. Poiché il comportamento predefinito prevede di mantenere gli attributi multicast per le sessioni iBPG, per rimuoverli è necessario che il comando inline-ABR disponga del comando send-multicast-attributes-disable.
Modifiche alla configurazione
È necessario configurare global-table-multicast nella famiglia di indirizzi (AF) ipv4 mVPN nel router BGP. Ciò consente il funzionamento di tutti gli zero RD e di tutti gli uno RD.
È necessario configurare import-rt e export-rt in multicast-routing per AF ipv4 nel contesto globale. Questo accade perché non vi sono più RT configurati per i VRF, poiché il GTM non dispone di VRF. Questi RT non devono sovrapporsi ad alcun RT utilizzato per mVPN standard.
I comandi pim del router (topologia rpf e comandi mdt) sono ora configurati nel contesto globale.
I comandi di routing multicast (rilevamento automatico bgp e comandi mdt) sono ora configurati nel contesto globale.
Annuncio route
Tra i router di confine c'è un iBGP che annuncia i prefissi di origine. In che modo il router di confine in entrata può imparare il prefisso Source (Origine)? Ci sono tre possibilità.
L'immagine 3 mostra questi tre possibili scenari.
Immagine 3
- Il router di confine ha ricevuto i prefissi dal PE come prefissi non BGP. Il router di confine deve ridistribuire questi prefissi in BGP. Questo router di confine aggiunge gli attributi multicast.
- I router di confine dispongono di una sessione eBGP verso i router PE. Il router di confine aggiunge gli attributi multicast prima di propagare il prefisso su iBGP agli altri router di confine. Se i prefissi ricevuti durante la sessione eBGP hanno già gli attributi multicast, vengono conservati e inoltrati così come sono. Il router di confine non li sovrascrive.
- Il router di confine in entrata apprende il prefisso Source da iBGP. In questo caso, il router di confine in entrata è un router di ripristino. Questo scenario viene utilizzato in MPLS Seamless, dove i router di confine sono ABR.
Quando il router di confine annuncia un prefisso iBGP ricevuto da un altro router di confine, rimuove gli attributi multicast prima di inviare il prefisso al router PE. Affinché il comando send-multicast-attribute venga disabilitato nel router BGP, i router di confine devono avere il comando send-multicast-attributes.
Esempi
Ecco alcuni esempi. Il primo esempio inizia con la trasformazione del profilo 12 in una distribuzione GTM.
Esempio 1: profilo 12: MDT - mLDP - P2MP - BGP-AD - BGP C-mcast Signaling
L'immagine 4 mostra questa rete. Non è presente alcun VRF sul router PE verso il router CE.
Immagine 4
Notare che la rete centrale interna esegue mLDP. La rete core esterna esegue PIM. Quindi, i router di confine, che connettono il PIM al core del mLDP, devono tradurre il PIM in mLDP e viceversa.
Impossibile apprendere l'origine come percorso IGP sul router di confine C-PE2. L'IGP è qui l'ISIS. In questo caso, l'RPF sul router di confine utilizzerebbe il percorso ISIS, che punta a P1. In questo caso, l'RPF fallisce in quanto non esiste un vicinato PIM. Si desidera che il router C-PE2 faccia riferimento a RPF per 10.2.1.8 e che punti a MDT come interfaccia RPF. Potrebbe trattarsi di un MDT basato su mLDP, P2MP o IR.
La soluzione è utilizzare il SAFI 2. Viene utilizzato in modo che l'origine venga appresa come route AFI 2 in BGP. Pertanto, il router di confine (C-PE2) dispone dell'origine come route BGP SAFI 2 (show route ipv4 multicast). L'RPF della sorgente punta all'interfaccia MDT.
L'uso di SAFI 2 modifica l'RPF e l'RPF per tutte le fonti ora utilizza SAFI 2. Questo significa che RPF per tutte le origini in globale utilizza SAFI 2, che include RPF per il PE in ingresso, ad esempio, per il servizio VPN. Una volta abilitato il SAFI 2, tutti gli RPF si verificano solo attraverso il SAFI 2. Poiché solo le fonti si trovano in SAFI 2, il RPF per i router PE in entrata non funziona. Per eseguire questa operazione, è possibile configurare il comando rump always-replicate in rib router. Poiché solo RPF per i prefissi di origine in globale e RPF per i router PE devono funzionare, è possibile configurare un elenco degli accessi per il comando di replica continua di massa e specificare solo le origini in globale e i router PE in entrata nell'elenco degli accessi. In questo modo, se il router di confine esegue già il BGP per il SAFI 1 e questo SAFI 1 contiene un gran numero di prefissi, questi prefissi non verrebbero ridistribuiti nel SAFI 2 RIB e utilizzerebbero la memoria senza necessità.
In alternativa, è possibile configurare la distanza bgp 20 20 20 per il multicast ipv4 della famiglia di indirizzi con il router BGP. Questo assicura che, se le fonti in globale vengono anche apprese attraverso l'AFI 2 dell'IGP, quelle apprese da BGP sono preferite a causa della distanza inferiore di iBGP rispetto alla distanza dell'IGP.
Configurazione
Questa è la configurazione del router di confine.
hostname C-PE1
router rib
address-family ipv4
rump always-replicate
!
route-policy global-one
set core-tree mldp-default
end-policy
!
route-policy sources-in-ISIS
if destination in (10.2.1.0/24) then
pass
endif
end-policy
!
router isis 1
is-type level-1
net 49.0001.0000.0000.0003.00
address-family ipv4 unicast
metric-style wide
mpls traffic-eng level-1
mpls traffic-eng router-id Loopback0
!
interface Loopback0
address-family ipv4 unicast
!
address-family ipv4 multicast
!
!
interface GigabitEthernet0/0/0/0
address-family ipv4 unicast
!
address-family ipv4 multicast
!
!
interface GigabitEthernet0/0/0/1
address-family ipv4 unicast
!
address-family ipv4 multicast
!
!
!
router bgp 1
address-family ipv4 unicast
!
address-family ipv4 multicast
redistribute connected route-policy loopback
redistribute isis 1 route-policy sources-in-ISIS
!
address-family ipv4 mvpn
global-table-multicast
!
neighbor 10.100.1.5
remote-as 1
update-source Loopback0
address-family ipv4 multicast
next-hop-self
!
address-family ipv4 mvpn
!
!
mpls ldp
mldp
address-family ipv4
rib unicast-always
!
!
router-id 10.100.1.3
address-family ipv4
!
interface GigabitEthernet0/0/0/0
address-family ipv4
!
!
interface GigabitEthernet0/0/0/1
address-family ipv4
!
!
!
multicast-routing
address-family ipv4
interface Loopback0
enable
!
interface GigabitEthernet0/0/0/1
enable
!
mdt source Loopback0
export-rt 1:1
import-rt 1:1
bgp auto-discovery mldp
!
mdt default mldp p2mp
mdt data mldp 10 immediate-switch
!
!
router pim
address-family ipv4
rpf topology route-policy global-one
mdt c-multicast-routing bgp
interface Loopback0
enable
!
interface GigabitEthernet0/0/0/1
!
!
!
È necessario disporre della configurazione successiva sui router di confine:
- BGP configurato con AF ipv4 mvpn
- BGP AD abilitato
- MDT specificato
- import-rt ed export-rt configurati con il bgp del router
- global-table-multicast configurato sotto il router bgp AF ipv4/6 mvpn
Facoltativamente, il protocollo SAFI 2 deve essere abilitato nel protocollo BGP del router
Risoluzione dei problemi
- In primo luogo, le route di confine devono avere le route di tipo 1 presenti.
- Verificate l'albero principale nel nucleo interno. Ecco, questo è mLDP. La segnalazione mLDP è corretta? Controllare le voci del database mLDP per individuare gli MDT predefiniti e i possibili MDT dati.
- Controllare la route di origine in BGP.
- Controllare l'RPF sul router di confine in uscita.
- Controllare la segnalazione multicast C in BGP (route-type 6 e 7) sui router di confine.
Router per bordo in entrata
L'interfaccia di uscita sul router di confine in entrata è l'interfaccia Lmdt.
RP/0/0/CPU0:C-PE1#show mrib route 203.0.113.1 10.2.1.8
IP Multicast Routing Information Base
Entry flags: L - Domain-Local Source, E - External Source to the Domain,
C - Directly-Connected Check, S - Signal, IA - Inherit Accept,
IF - Inherit From, D - Drop, ME - MDT Encap, EID - Encap ID,
MD - MDT Decap, MT - MDT Threshold Crossed, MH - MDT interface handle
CD - Conditional Decap, MPLS - MPLS Decap, EX - Extranet
MoFE - MoFRR Enabled, MoFS - MoFRR State, MoFP - MoFRR Primary
MoFB - MoFRR Backup, RPFID - RPF ID Set, X - VXLAN
Interface flags: F - Forward, A - Accept, IC - Internal Copy,
NS - Negate Signal, DP - Don't Preserve, SP - Signal Present,
II - Internal Interest, ID - Internal Disinterest, LI - Local Interest,
LD - Local Disinterest, DI - Decapsulation Interface
EI - Encapsulation Interface, MI - MDT Interface, LVIF - MPLS Encap,
EX - Extranet, A2 - Secondary Accept, MT - MDT Threshold Crossed,
MA - Data MDT Assigned, LMI - mLDP MDT Interface, TMI - P2MP-TE MDT Interface
IRMI - IR MDT Interface
(10.2.1.8,203.0.113.1) RPF nbr: 10.1.2.2 Flags: RPF
Up: 00:08:58
Incoming Interface List
GigabitEthernet0/0/0/1 Flags: A, Up: 00:08:58
Outgoing Interface List
Lmdtdefault Flags: F LMI MA, Up: 00:08:58
RP/0/0/CPU0:C-PE1#show mfib route 203.0.113.1 10.2.1.8
IP Multicast Forwarding Information Base
Entry flags: C - Directly-Connected Check, S - Signal, D - Drop,
IA - Inherit Accept, IF - Inherit From, EID - Encap ID,
ME - MDT Encap, MD - MDT Decap, MT - MDT Threshold Crossed,
MH - MDT interface handle, CD - Conditional Decap,
DT - MDT Decap True, EX - Extranet, RPFID - RPF ID Set,
MoFE - MoFRR Enabled, MoFS - MoFRR State, X - VXLAN
Interface flags: F - Forward, A - Accept, IC - Internal Copy,
NS - Negate Signal, DP - Don't Preserve, SP - Signal Present,
EG - Egress, EI - Encapsulation Interface, MI - MDT Interface,
EX - Extranet, A2 - Secondary Accept
Forwarding/Replication Counts: Packets in/Packets out/Bytes out
Failure Counts: RPF / TTL / Empty Olist / Encap RL / Other
(10.2.1.8,203.0.113.1), Flags:
Up: 01:47:24
Last Used: 00:00:00
SW Forwarding Counts: 1197/1197/239400
SW Replication Counts: 1197/0/0
SW Failure Counts: 0/0/0/0/0
Lmdtdefault Flags: F LMI, Up:01:47:24
GigabitEthernet0/0/0/1 Flags: A, Up:01:47:24
RP/0/0/CPU0:C-PE1#show route ipv4 multicast
Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, su - IS-IS summary null, * - candidate default
U - per-user static route, o - ODR, L - local, G - DAGR, l - LISP
A - access/subscriber, a - Application route
M - mobile route, r - RPL, (!) - FRR Backup path
Gateway of last resort is not set
i L1 10.1.1.0/24 [255/20] via 10.1.2.2, 1d21h, GigabitEthernet0/0/0/1
C 10.1.2.0/24 is directly connected, 1d21h, GigabitEthernet0/0/0/1
L 10.1.2.3/32 is directly connected, 3d19h, GigabitEthernet0/0/0/1
i L1 10.1.3.0/24 [115/20] via 10.1.3.4, 3d13h, GigabitEthernet0/0/0/0
L 10.1.3.3/32 is directly connected, 3d19h, GigabitEthernet0/0/0/0
i L1 10.1.4.0/24 [115/20] via 10.1.3.4, 3d13h, GigabitEthernet0/0/0/0
i L1 10.1.5.0/24 [115/30] via 10.1.3.4, 3d12h, GigabitEthernet0/0/0/0
i L1 10.1.6.0/24 [255/40] via 10.1.3.4, 1d21h, GigabitEthernet0/0/0/0
i L1 10.2.1.0/24 [255/30] via 10.1.2.2, 1d21h, GigabitEthernet0/0/0/1
i L1 10.2.2.0/24 [255/50] via 10.1.3.4, 1d21h, GigabitEthernet0/0/0/0
i L1 10.100.1.1/32 [255/30] via 10.1.2.2, 1d21h, GigabitEthernet0/0/0/1
i L1 10.100.1.2/32 [255/20] via 10.1.2.2, 1d21h, GigabitEthernet0/0/0/1
L 10.100.1.3/32 is directly connected, 1d21h, Loopback0
i L1 10.100.1.4/32 [115/20] via 10.1.3.4, 3d13h, GigabitEthernet0/0/0/0
i L1 10.100.1.5/32 [115/30] via 10.1.3.4, 3d12h, GigabitEthernet0/0/0/0
i L1 10.100.1.6/32 [255/40] via 10.1.3.4, 1d21h, GigabitEthernet0/0/0/0
i L1 10.100.1.7/32 [255/50] via 10.1.3.4, 1d21h, GigabitEthernet0/0/0/0
RP/0/0/CPU0:C-PE1#show pim rpf 10.2.1.8
Table: IPv4-Multicast-default
* 10.2.1.8/32 [255/30]
via GigabitEthernet0/0/0/1 with rpf neighbor 10.1.2.2
Router del bordo in uscita
Per il percorso di origine, le voci VRF Route-Import EC e Source-AS EC sono collegate al prefisso unicast o multicast IPv4. In questo caso, si tratta di una route multicast IPv4:
RP/0/0/CPU0:C-PE2#show bgp ipv4 multicast 10.2.1.0/24
BGP routing table entry for 10.2.1.0/24
Versions:
Process bRIB/RIB SendTblVer
Speaker 32 32
Last Modified: Sep 12 08:34:56.441 for 15:09:58
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local
10.100.1.3 (metric 30) from 10.100.1.3 (10.100.1.3)
Origin incomplete, metric 30, localpref 100, valid, internal, best, group-best
Received Path ID 0, Local Path ID 1, version 32
Extended community: VRF Route Import:10.100.1.3:0 Source AS:1:0
Esempio di percorso privo dei seguenti EC:
RP/0/0/CPU0:C-PE2#show bgp ipv4 multicast 10.2.1.0/24
BGP routing table entry for 10.2.1.0/24
Versions:
Process bRIB/RIB SendTblVer
Speaker 277 277
Last Modified: Sep 13 04:08:37.441 for 00:00:02
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local
10.100.1.3 (metric 30) from 10.100.1.3 (10.100.1.1)
Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best
Received Path ID 0, Local Path ID 1, version 277
Originator: 10.100.1.1, Cluster list: 10.100.1.3
Per questo motivo, l'RPF fallisce:
RP/0/0/CPU0:C-PE2#show pim rpf 10.2.1.8
Table: IPv4-Multicast-default
* 10.2.1.8/32 [200/30]
via Null with rpf neighbor 0.0.0.0
RP/0/0/CPU0:C-PE2#show bgp ipv4 mvpn
BGP router identifier 10.100.1.5, local AS number 1
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 0
BGP main routing table version 56
BGP NSR Initial initsync version 4 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
Global table multicast is enabled
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 0:0:0
*>i[1][10.100.1.3]/40 10.100.1.3 100 0 i
*> [1][10.100.1.5]/40 0.0.0.0 0 i
*>i[3][32][10.2.1.8][32][203.0.113.1][10.100.1.3]/120
10.100.1.3 100 0 i
*> [7][0:0:0][1][32][10.2.1.8][32][203.0.113.1]/184
0.0.0.0 0 i
Processed 4 prefixes, 4 paths
Il comando può essere specificato con le parole chiave rd all-zero-rd. Vengono quindi visualizzate tutte le voci con il RD composto da tutti gli zeri.
RP/0/0/CPU0:C-PE2#show bgp ipv4 mvpn rd all-zero-rd
BGP router identifier 10.100.1.5, local AS number 1
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 0
BGP main routing table version 56
BGP NSR Initial initsync version 4 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
Global table multicast is enabled
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 0:0:0
*>i[1][10.100.1.3]/40 10.100.1.3 100 0 i
*> [1][10.100.1.5]/40 0.0.0.0 0 i
*>i[3][32][10.2.1.8][32][203.0.113.1][10.100.1.3]/120
10.100.1.3 100 0 i
*> [7][0:0:0][1][32][10.2.1.8][32][203.0.113.1]/184
0.0.0.0 0 i
Processed 4 prefixes, 4 paths
Il percorso di tipo 1:
RP/0/0/CPU0:C-PE2#show bgp ipv4 mvpn rd all-zero-rd [1][10.100.1.3]/40
BGP routing table entry for [1][10.100.1.3]/40, Route Distinguisher: 0:0:0
Versions:
Process bRIB/RIB SendTblVer
Speaker 43 43
Last Modified: Sep 8 07:42:43.786 for 1d17h
Paths: (1 available, best #1, not advertised to EBGP peer)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local
10.100.1.3 (metric 30) from 10.100.1.3 (10.100.1.3)
Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported
Received Path ID 0, Local Path ID 1, version 43
Community: no-export
Extended community: RT:1:1
PMSI: flags 0x00, type 2, label 0, ID 0x060001040a640103000701000400000001
Source AFI: IPv4 MVPN, Source VRF: default, Source Route Distinguisher: 0:0:0
PMSI decodificato:
PMSI: flag 0x00, tipo 2, etichetta 0, ID 0x060001040a640103000701000400000001
Il PMSI decodificato dal comando precedente è:
The PMSI Tunnel Type is : 2 : mLDP P2MP LSP
The PMSI Tunnel ID is : 0x060001040a640103000701000400000001
FEC Element
FEC Element Type : 6 : P2MP
AF Type : 1
Address Length : 4
Root Node Address : 10.100.1.3
MP Opaque Length : 7
MP Opaque Value Element
Opaque Type : 1 : LSP ID Global
Opaque Length : 4
Global ID (Generic LSP Identifier) : 1
L'MDT dei dati è segnalato da una route AD di tipo route 3 da C-PE1.
RP/0/0/CPU0:C-PE2#show bgp ipv4 mvpn rd all-zero-rd [3][32][10.2.1.8] [32][203.0.113.1][10.100.1.3]/120
BGP routing table entry for [3][32][10.2.1.8][32][203.0.113.1][10.100.1.3]/120, Route Distinguisher: 0:0:0
Versions:
Process bRIB/RIB SendTblVer
Speaker 56 56
Last Modified: Sep 10 00:51:52.786 for 00:04:57
Paths: (1 available, best #1, not advertised to EBGP peer)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local
10.100.1.3 (metric 30) from 10.100.1.3 (10.100.1.3)
Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported
Received Path ID 0, Local Path ID 1, version 56
Community: no-export
Extended community: RT:1:1
PMSI: flags 0x00, type 2, label 0, ID 0x060001040a640103000701000400000007
Source AFI: IPv4 MVPN, Source VRF: default, Source Route Distinguisher: 0:0:0
Il PMSI decodificato indica che l'identificatore LSP globale è 7. Viene quindi utilizzato per la voce del database mLDP per questo Data MDT.
PMSI: flag 0x00, tipo 2, etichetta 0, ID 0x060001040a640103000701000400000007
Il PMSI decodificato dal comando precedente è:
The PMSI Tunnel Type is : 2 : mLDP P2MP LSP
The PMSI Tunnel ID is : 0x060001040a640103000701000400000007
FEC Element
FEC Element Type : 6 : P2MP
AF Type : 1
Address Length : 4
Root Node Address : 10.100.1.3
MP Opaque Length : 7
MP Opaque Value Element
Opaque Type : 1 : LSP ID Global
Opaque Length : 4
Global ID (Generic LSP Identifier) : 7
Con i comandi successivi, è possibile controllare gli annunci in ingresso di PE relativi all'MDT dati. Notare che questo è GTM, quindi non c'è VRF nel comando successivo.
RP/0/0/CPU0:C-PE2#show pim mdt mldp remote
Core MDT Cache Max DIP Local VRF Routes
Identifier Source Count Agg Entry Using Cache
[global-id 7] 10.100.1.3 1 255 N N 1
RP/0/0/CPU0:C-PE2#show pim mdt mldp cache
Core Source Cust (Source, Group) Core Data Expires
10.100.1.3 (10.2.1.8, 203.0.113.1) [global-id 7] never
Il tipo di route 7 non dispone di un PMSI collegato:
RP/0/0/CPU0:C-PE2#show bgp ipv4 mvpn rd all-zero-rd [7][0:0:0][1][32][10.2.1.8][32][203.0.113.1]/184
BGP routing table entry for [7][0:0:0][1][32][10.2.1.8][32][203.0.113.1]/184, Route Distinguisher: 0:0:0
Versions:
Process bRIB/RIB SendTblVer
Speaker 52 52
Last Modified: Sep 10 00:51:51.786 for 00:07:37
Paths: (1 available, best #1)
Advertised to peers (in unique update groups):
10.100.1.3
Path #1: Received by speaker 0
Advertised to peers (in unique update groups):
10.100.1.3
Local
0.0.0.0 from 0.0.0.0 (10.100.1.5)
Origin IGP, localpref 100, valid, redistributed, best, group-best, import-candidate
Received Path ID 0, Local Path ID 1, version 52
Extended community: RT:10.100.1.3:0
RT identifica il router PE upstream. Il campo Amministratore globale corrisponde all'indirizzo IP del file PE a monte. Il campo dell'amministratore locale è impostato su 0 per GTM.
RP/0/0/CPU0:C-PE2#show mrib route 203.0.113.1 10.2.1.8
IP Multicast Routing Information Base
Entry flags: L - Domain-Local Source, E - External Source to the Domain,
C - Directly-Connected Check, S - Signal, IA - Inherit Accept,
IF - Inherit From, D - Drop, ME - MDT Encap, EID - Encap ID,
MD - MDT Decap, MT - MDT Threshold Crossed, MH - MDT interface handle
CD - Conditional Decap, MPLS - MPLS Decap, EX - Extranet
MoFE - MoFRR Enabled, MoFS - MoFRR State, MoFP - MoFRR Primary
MoFB - MoFRR Backup, RPFID - RPF ID Set, X - VXLAN
Interface flags: F - Forward, A - Accept, IC - Internal Copy,
NS - Negate Signal, DP - Don't Preserve, SP - Signal Present,
II - Internal Interest, ID - Internal Disinterest, LI - Local Interest,
LD - Local Disinterest, DI - Decapsulation Interface
EI - Encapsulation Interface, MI - MDT Interface, LVIF - MPLS Encap,
EX - Extranet, A2 - Secondary Accept, MT - MDT Threshold Crossed,
MA - Data MDT Assigned, LMI - mLDP MDT Interface, TMI - P2MP-TE MDT Interface
IRMI - IR MDT Interface
(10.2.1.8,203.0.113.1) RPF nbr: 10.100.1.3 Flags: RPF
Up: 00:52:34
Incoming Interface List
Lmdtdefault Flags: A LMI, Up: 00:52:34
Outgoing Interface List
GigabitEthernet0/0/0/0 Flags: F NS, Up: 00:52:34
L'interfaccia in ingresso deve essere un'interfaccia Lmdt.
RP/0/0/CPU0:C-PE2#show mfib route 203.0.113.1 10.2.1.8
IP Multicast Forwarding Information Base
Entry flags: C - Directly-Connected Check, S - Signal, D - Drop,
IA - Inherit Accept, IF - Inherit From, EID - Encap ID,
ME - MDT Encap, MD - MDT Decap, MT - MDT Threshold Crossed,
MH - MDT interface handle, CD - Conditional Decap,
DT - MDT Decap True, EX - Extranet, RPFID - RPF ID Set,
MoFE - MoFRR Enabled, MoFS - MoFRR State, X - VXLAN
Interface flags: F - Forward, A - Accept, IC - Internal Copy,
NS - Negate Signal, DP - Don't Preserve, SP - Signal Present,
EG - Egress, EI - Encapsulation Interface, MI - MDT Interface,
EX - Extranet, A2 - Secondary Accept
Forwarding/Replication Counts: Packets in/Packets out/Bytes out
Failure Counts: RPF / TTL / Empty Olist / Encap RL / Other
(10.2.1.8,203.0.113.1), Flags:
Up: 02:31:00
Last Used: never
SW Forwarding Counts: 0/2037/407400
SW Replication Counts: 0/2037/407400
SW Failure Counts: 0/0/0/0/0
Lmdtdefault Flags: A LMI, Up:02:31:00
GigabitEthernet0/0/0/0 Flags: NS EG, Up:02:31:00
Controllare le rotte SAFI 2:
RP/0/0/CPU0:C-PE2#show route ipv4 multicast
Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, su - IS-IS summary null, * - candidate default
U - per-user static route, o - ODR, L - local, G - DAGR, l - LISP
A - access/subscriber, a - Application route
M - mobile route, r - RPL, (!) - FRR Backup path
Gateway of last resort is not set
i L1 10.1.2.0/24 [115/30] via 10.1.4.4, 3d12h, GigabitEthernet0/0/0/1
i L1 10.1.3.0/24 [115/20] via 10.1.4.4, 3d12h, GigabitEthernet0/0/0/1
C 10.1.4.0/24 is directly connected, 1d21h, GigabitEthernet0/0/0/1
L 10.1.4.5/32 is directly connected, 3d12h, GigabitEthernet0/0/0/1
C 10.1.5.0/24 is directly connected, 1d21h, GigabitEthernet0/0/0/0
L 10.1.5.5/32 is directly connected, 3d12h, GigabitEthernet0/0/0/0
B 10.2.1.0/24 [200/30] via 10.100.1.3, 1d17h
i L1 10.100.1.3/32 [115/30] via 10.1.4.4, 3d12h, GigabitEthernet0/0/0/1
i L1 10.100.1.4/32 [115/20] via 10.1.4.4, 3d12h, GigabitEthernet0/0/0/1
L 10.100.1.5/32 is directly connected, 1d21h, Loopback0
Notare che il percorso per l'origine è SAFI 2 (si trova nel multicast IPv4 AF), in quanto si trova nel multicast IPv4 RIB AF.
Notare che l'hop successivo è 10.100.1.3, il loopback di C-PE1, in quanto il router ha il self-hop successivo sotto il multicast AF ipv4 sotto il router BGP.
RP/0/0/CPU0:C-PE2#show bgp ipv4 multicast 10.2.1.0/24
BGP routing table entry for 10.2.1.0/24
Versions:
Process bRIB/RIB SendTblVer
Speaker 34 34
Last Modified: Sep 8 07:42:18.786 for 1d17h
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local
10.100.1.3 (metric 30) from 10.100.1.3 (10.100.1.3)
Origin incomplete, metric 30, localpref 100, valid, internal, best, group-best
Received Path ID 0, Local Path ID 1, version 34
Extended community: VRF Route Import:10.100.1.3:0 Source AS:1:0
L'RPF per l'origine punta all'interfaccia Lmdt e al router adiacente PIM attraverso di essa. L'RPF viene eseguito nella tabella Multicast IPv4.
RP/0/0/CPU0:C-PE2#show pim rpf 10.2.1.8
Table: IPv4-Multicast-default
* 10.2.1.8/32 [200/30]
via Lmdtdefault with rpf neighbor 10.100.1.3
Verificare che il router di confine in entrata sia riconosciuto come router PE.
RP/0/0/CPU0:C-PE2#show pim pe
MVPN Provider Edge Router information
PE Address : 10.100.1.3 (0x1071da64)
RD: 0:0:0 (valid), RIB_HLI 0, RPF-ID 3, Remote RPF-ID 0, State: 1, S-PMSI: 2
PPMP_LABEL: 0, MS_PMSI_HLI: 0x00000, Bidir_PMSI_HLI: 0x00000, MLDP-added: [RD 0, ID 0, Bidir ID 0, Remote Bidir ID 0], Counts(SHR/SRC/DM/DEF-MD): 0, 1, 0, 0, Bidir: GRE RP Count 0, MPLS RP Count 0RSVP-TE added: [Leg 0, Ctrl Leg 0, Part tail 0 Def Tail 0, IR added: [Def Leg 0, Ctrl Leg 0, Part Leg 0, Part tail 0, Part IR Tail Label 0
bgp_i_pmsi: 1,0/0 , bgp_ms_pmsi/Leaf-ad: 0/0, bgp_bidir_pmsi: 0, remote_bgp_bidir_pmsi: 0, PMSIs: I 0x106a2d50, 0x0, MS 0x0, Bidir Local: 0x0, Remote: 0x0, BSR/Leaf-ad 0x0/0, Autorp-disc/Leaf-ad 0x0/0, Autorp-ann/Leaf-ad 0x0/0
IIDs: I/6: 0x1/0x0, B/R: 0x0/0x0, MS: 0x0, B/A/A: 0x0/0x0/0x0
Bidir RPF-ID: 4, Remote Bidir RPF-ID: 0
I-PMSI: MLDP-P2MP, Opaque: [global-id 1] (0x106a2d50)
I-PMSI rem: (0x0)
MS-PMSI: (0x0)
Bidir-PMSI: (0x0)
Remote Bidir-PMSI: (0x0)
BSR-PMSI: (0x0)
A-Disc-PMSI: (0x0)
A-Ann-PMSI: (0x0)
RIB Dependency List: 0x1016446c
Bidir RIB Dependency List: 0x0
Sources: 1, RPs: 0, Bidir RPs: 0
Il PMSI inclusivo (I-PMSI) è presente.
Vengono visualizzate le due voci P2MP mLDP che formano l'MDT predefinito tra i due router di confine nel database mLDP. Esiste anche una voce P2MP mLDP con C-PE1 come root per Data MDT.
RP/0/0/CPU0:C-PE2#show mpls mldp database brief
LSM ID Type Root Up Down Decoded Opaque Value
0x00007 P2MP 10.100.1.3 1 1 [global-id 1]
0x00008 P2MP 10.100.1.5 0 2 [global-id 1]
0x0000B P2MP 10.100.1.3 1 1 [global-id 7]
Esempio 2: Profilo 20 MDT predefinito - P2MP-TE - BGP-AD - PIM - Segnalazione C-mcast
Questo è molto simile all'esempio 1. Ora c'è P2MP TE nel nucleo. I tunnel sono impostati come tunnel automatici. I router di coda vengono rilevati tramite BGP AD. Un'altra differenza con l'esempio 1 è che il protocollo di sovrapposizione è ora PIM. Osservare l'immagine 5.
Immagine 5
Configurazione
Questa è la configurazione del router di confine:
hostname C-PE1
logging console debugging
router rib
address-family ipv4
rump always-replicate
!
!
line default
timestamp disable
exec-timeout 0 0
!
ipv4 unnumbered mpls traffic-eng Loopback0
interface Loopback0
ipv4 address 10.100.1.3 255.255.255.255
!
interface MgmtEth0/0/CPU0/0
shutdown
!
interface GigabitEthernet0/0/0/0
ipv4 address 10.1.3.3 255.255.255.0
load-interval 30
!
interface GigabitEthernet0/0/0/1
ipv4 address 10.1.2.3 255.255.255.0
!
interface GigabitEthernet0/0/0/2
shutdown
!
interface GigabitEthernet0/0/0/3
shutdown
!
interface GigabitEthernet0/0/0/4
shutdown
!
interface GigabitEthernet0/0/0/5
shutdown
!
interface GigabitEthernet0/0/0/6
shutdown
!
interface GigabitEthernet0/0/0/7
shutdown
!
interface GigabitEthernet0/0/0/8
shutdown
!
route-policy loopback
if destination in (10.100.1.3/32) then
pass
endif
end-policy
!
route-policy global-one
set core-tree p2mp-te-default
end-policy
!
route-policy sources-in-ISIS
if destination in (10.2.1.0/24) then
pass
endif
end-policy
!
router isis 1
is-type level-1
net 49.0001.0000.0000.0003.00
address-family ipv4 unicast
metric-style wide
mpls traffic-eng level-1
mpls traffic-eng router-id Loopback0
!
interface Loopback0
address-family ipv4 unicast
!
address-family ipv4 multicast
!
!
interface GigabitEthernet0/0/0/0
address-family ipv4 unicast
!
address-family ipv4 multicast
!
!
interface GigabitEthernet0/0/0/1
address-family ipv4 unicast
!
address-family ipv4 multicast
!
!
!
router bgp 1
address-family ipv4 unicast
!
address-family ipv4 multicast
redistribute connected route-policy loopback
redistribute ospf 1
redistribute isis 1 route-policy sources-in-ISIS
!
address-family ipv4 mvpn
global-table-multicast
!
neighbor 10.100.1.5
remote-as 1
update-source Loopback0
address-family ipv4 multicast
next-hop-self
!
address-family ipv4 mvpn
!
!
!
mpls oam
!
rsvp
interface GigabitEthernet0/0/0/0
bandwidth 1000000
!
interface GigabitEthernet0/0/0/1
bandwidth 1000000
!
!
mpls traffic-eng
interface GigabitEthernet0/0/0/0
auto-tunnel backup
!
!
interface GigabitEthernet0/0/0/1
auto-tunnel backup
!
!
auto-tunnel p2mp
tunnel-id min 1000 max 2000
!
!
mpls ldp
log
neighbor
!
mldp
logging notifications
address-family ipv4
rib unicast-always
!
!
router-id 10.100.1.3
address-family ipv4
!
interface GigabitEthernet0/0/0/0
address-family ipv4
!
!
interface GigabitEthernet0/0/0/1
address-family ipv4
!
!
!
multicast-routing
address-family ipv4
interface Loopback0
enable
!
interface GigabitEthernet0/0/0/1
enable
!
mdt source Loopback0
export-rt 1:1
import-rt 1:1
bgp auto-discovery p2mp-te
!
mdt default p2mp-te
mdt data p2mp-te 100 immediate-switch
!
!
router pim
address-family ipv4
rpf topology route-policy global-one
interface Loopback0
enable
!
interface GigabitEthernet0/0/0/1
!
!
!
Risoluzione dei problemi
Router per bordo in entrata
Verificare che il RD all-zero sia presente. Le route di tipo 1 devono essere presenti per poter costruire il TE P2MP basato sui tunnel TE P2MP.
RP/0/0/CPU0:C-PE1#show bgp ipv4 mvpn rd all-zero-rd
BGP router identifier 10.100.1.3, local AS number 1
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 0
BGP main routing table version 140
BGP NSR Initial initsync version 4 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
Global table multicast is enabled
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 0:0:0
*> [1][10.100.1.3]/40 0.0.0.0 0 i
*>i[1][10.100.1.5]/40 10.100.1.5 100 0 i
Processed 2 prefixes, 2 paths
Verificare più dettagliatamente il ciclo di lavorazione di tipo 1:
RP/0/0/CPU0:C-PE1#show bgp ipv4 mvpn rd all-zero-rd [1][10.100.1.5]/40
BGP routing table entry for [1][10.100.1.5]/40, Route Distinguisher: 0:0:0
Versions:
Process bRIB/RIB SendTblVer
Speaker 135 135
Last Modified: Sep 12 08:21:42.207 for 00:20:14
Paths: (1 available, best #1, not advertised to EBGP peer)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local
10.100.1.5 (metric 30) from 10.100.1.5 (10.100.1.5)
Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported
Received Path ID 0, Local Path ID 1, version 135
Community: no-export
Extended community: RT:1:1
PMSI: flags 0x00, type 1, label 0, ID 0x000003e8000003e80a640105
Source AFI: IPv4 MVPN, Source VRF: default, Source Route Distinguisher: 0:0:0
Controllare i vicini PIM sul valore predefinito MDT:
RP/0/0/CPU0:C-PE1#show pim neighbor
PIM neighbors in VRF default
Flag: B - Bidir capable, P - Proxy capable, DR - Designated Router,
E - ECMP Redirect capable
* indicates the neighbor created for this router
Neighbor Address Interface Uptime Expires DR pri Flags
10.1.2.2 GigabitEthernet0/0/0/1 6d02h 00:01:16 1 B
10.1.2.3* GigabitEthernet0/0/0/1 6d02h 00:01:15 1 (DR) B E
10.100.1.3* Loopback0 6d02h 00:01:32 1 (DR) B E
10.100.1.3* Tmdtdefault 00:36:21 00:01:40 1
10.100.1.5 Tmdtdefault 00:17:37 00:01:26 1 (DR)
Controllare il percorso MRIB. L'interfaccia in uscita deve essere Tmdt:
RP/0/0/CPU0:C-PE1#show mrib route 203.0.113.1
IP Multicast Routing Information Base
Entry flags: L - Domain-Local Source, E - External Source to the Domain,
C - Directly-Connected Check, S - Signal, IA - Inherit Accept,
IF - Inherit From, D - Drop, ME - MDT Encap, EID - Encap ID,
MD - MDT Decap, MT - MDT Threshold Crossed, MH - MDT interface handle
CD - Conditional Decap, MPLS - MPLS Decap, EX - Extranet
MoFE - MoFRR Enabled, MoFS - MoFRR State, MoFP - MoFRR Primary
MoFB - MoFRR Backup, RPFID - RPF ID Set, X - VXLAN
Interface flags: F - Forward, A - Accept, IC - Internal Copy,
NS - Negate Signal, DP - Don't Preserve, SP - Signal Present,
II - Internal Interest, ID - Internal Disinterest, LI - Local Interest,
LD - Local Disinterest, DI - Decapsulation Interface
EI - Encapsulation Interface, MI - MDT Interface, LVIF - MPLS Encap,
EX - Extranet, A2 - Secondary Accept, MT - MDT Threshold Crossed,
MA - Data MDT Assigned, LMI - mLDP MDT Interface, TMI - P2MP-TE MDT Interface
IRMI - IR MDT Interface
(10.2.1.8,203.0.113.1) RPF nbr: 10.1.2.2 Flags: RPF
Up: 00:09:10
Incoming Interface List
GigabitEthernet0/0/0/1 Flags: A, Up: 00:09:10
Outgoing Interface List
Tmdtdefault Flags: F NS TMI, Up: 00:09:10
Verificare che esista un tunnel P2MP TE per router di confine come router headend:
RP/0/0/CPU0:C-PE1#show mpls traffic-eng tunnels tabular
Tunnel LSP Destination Source FRR LSP Path
Name ID Address Address State State Role Prot
----------------- ----- --------------- --------------- ------ ------ ---- -----
^tunnel-mte1001 10004 10.100.1.5 10.100.1.3 up Inact Head
auto_C-PE2_mt1000 10005 10.100.1.3 10.100.1.5 up Inact Tail
^ = automatically created P2MP tunnel
Una volta attivato Data MDT, vengono utilizzate le route di tipo 3 e 4:
RP/0/0/CPU0:C-PE1#show bgp ipv4 mvpn rd all-zero-rd
BGP router identifier 10.100.1.3, local AS number 1
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 0
BGP main routing table version 143
BGP NSR Initial initsync version 4 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
Global table multicast is enabled
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 0:0:0
*> [1][10.100.1.3]/40 0.0.0.0 0 i
*>i[1][10.100.1.5]/40 10.100.1.5 100 0 i
*> [3][32][10.2.1.8][32][203.0.113.1][10.100.1.3]/120
0.0.0.0 0 i
*>i[4][3][0:0:0][32][10.2.1.8][32][203.0.113.1][10.100.1.3][10.100.1.5]/224
10.100.1.5 100 0 i
Processed 4 prefixes, 4 paths
Il tipo di percorso 3 annuncia a tutti i router di coda che è segnalato un MDT dati:
RP/0/0/CPU0:C-PE1#show bgp ipv4 mvpn rd all-zero-rd [3][32][10.2.1.8][32][203.0.113.1][10.100.1.3]/120
BGP routing table entry for [3][32][10.2.1.8][32][203.0.113.1][10.100.1.3]/120, Route Distinguisher: 0:0:0
Versions:
Process bRIB/RIB SendTblVer
Speaker 141 141
Last Modified: Sep 12 08:46:17.207 for 00:00:41
Paths: (1 available, best #1, not advertised to EBGP peer)
Advertised to peers (in unique update groups):
10.100.1.5
Path #1: Received by speaker 0
Advertised to peers (in unique update groups):
10.100.1.5
Local
0.0.0.0 from 0.0.0.0 (10.100.1.3)
Origin IGP, localpref 100, valid, redistributed, best, group-best, import-candidate
Received Path ID 0, Local Path ID 1, version 141
Community: no-export
Extended community: RT:1:1
PMSI: flags 0x01, type 1, label 0, ID 0x000003ed000003ed0a640103
PMSI decodificato:
PMSI: flag 0x01, tipo 1, etichetta 0, ID 0x000003ed000003ed0a640103
Il PMSI decodificato dal comando precedente è:
The PMSI Tunnel Type is : 1 : RSVP-TE P2MP LSP
The PMSI Tunnel ID is : 0x000003ed000003ed0a640103
Extended Tunnel ID : 1005
Reserved part (should be zero): 0X0000
Tunnel ID : 1005
P2MP ID : 10.100.1.3
Questa condizione può essere rilevata anche qui:
RP/0/0/CPU0:C-PE1#show pim mdt cache
Core Source Cust (Source, Group) Core Data Expires
10.100.1.3 (10.2.1.8, 203.0.113.1) [p2mp 6] never
Leaf AD: 10.100.1.5
Il tipo di routing 4 annuncia al router headend quale router è il terminale di coda:
RP/0/0/CPU0:C-PE1#show bgp ipv4 mvpn rd all-zero-rd [4][3][0:0:0][32][10.2.1.8][32][203.0.113.1][10.100.1.3][10.100.1.5]/224
BGP routing table entry for [4][3][0:0:0][32][10.2.1.8][32][203.0.113.1][10.100.1.3][10.100.1.5]/224, Route Distinguisher: 0:0:0
Versions:
Process bRIB/RIB SendTblVer
Speaker 143 143
Last Modified: Sep 12 08:46:17.207 for 00:01:25
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local
10.100.1.5 (metric 30) from 10.100.1.5 (10.100.1.5)
Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported
Received Path ID 0, Local Path ID 1, version 143
Extended community: SEG-NH:10.100.1.5:0 RT:10.100.1.3:0
Source AFI: IPv4 MVPN, Source VRF: default, Source Route Distinguisher: 0:0:0
Verificare che Data MDT nel tunnel P2MP TE sia configurato:
RP/0/0/CPU0:C-PE1#show mpls traffic-eng tunnels tabular
Tunnel LSP Destination Source FRR LSP Path
Name ID Address Address State State Role Prot
----------------- ----- --------------- --------------- ------ ------ ---- -----
^tunnel-mte1001 10004 10.100.1.5 10.100.1.3 up Inact Head
^tunnel-mte1005 10002 10.100.1.5 10.100.1.3 up Inact Head
auto_C-PE2_mt1000 10005 10.100.1.3 10.100.1.5 up Inact Tail
^ = automatically created P2MP tunnel
Router del bordo in uscita
Verificare che l'interfaccia in ingresso sia l'interfaccia Tmdt:
RP/0/0/CPU0:C-PE2#show mrib route 203.0.113.1
IP Multicast Routing Information Base
Entry flags: L - Domain-Local Source, E - External Source to the Domain,
C - Directly-Connected Check, S - Signal, IA - Inherit Accept,
IF - Inherit From, D - Drop, ME - MDT Encap, EID - Encap ID,
MD - MDT Decap, MT - MDT Threshold Crossed, MH - MDT interface handle
CD - Conditional Decap, MPLS - MPLS Decap, EX - Extranet
MoFE - MoFRR Enabled, MoFS - MoFRR State, MoFP - MoFRR Primary
MoFB - MoFRR Backup, RPFID - RPF ID Set, X - VXLAN
Interface flags: F - Forward, A - Accept, IC - Internal Copy,
NS - Negate Signal, DP - Don't Preserve, SP - Signal Present,
II - Internal Interest, ID - Internal Disinterest, LI - Local Interest,
LD - Local Disinterest, DI - Decapsulation Interface
EI - Encapsulation Interface, MI - MDT Interface, LVIF - MPLS Encap,
EX - Extranet, A2 - Secondary Accept, MT - MDT Threshold Crossed,
MA - Data MDT Assigned, LMI - mLDP MDT Interface, TMI - P2MP-TE MDT Interface
IRMI - IR MDT Interface
(10.2.1.8,203.0.113.1) RPF nbr: 10.100.1.3 Flags: RPF
Up: 00:18:03
Incoming Interface List
Tmdtdefault Flags: A TMI, Up: 00:18:00
Outgoing Interface List
GigabitEthernet0/0/0/0 Flags: F NS, Up: 00:18:03
L'RPF sul router di confine in uscita punta al router di confine in entrata. L'interfaccia in entrata è Tmdtdefault. Notare la T per il tunnel TE:
RP/0/0/CPU0:C-PE2#show pim rpf 10.2.1.8
Table: IPv4-Multicast-default
* 10.2.1.8/32 [200/30]
via Tmdtdefault with rpf neighbor 10.100.1.3
Esempio 3: come nell'esempio 1, ma tra PE e Border Router è presente iBGP
Guardate l'immagine 6.
Immagine 6
Vediamo una configurazione asimmetrica in cui abbiamo una rete core con mLDP su un lato e PIM ancora sull'altro lato e GTM. Ciò può verificarsi durante la migrazione degli alberi del nucleo. Il router C-PE1 deve essere un router RR per BGP IPv4 multicast e BGP IPv4 mVPN. La configurazione per PIM e multicast-routing disponibile su C-PE1 nell'esempio 1 è ora necessaria su PE1.
Esempio 4: MPLS perfetto
Il protocollo GTM viene implementato su MPLS (Unified MPLS). Il router PE deve riconoscere il GTM, operazione che può essere eseguita solo da un router Cisco IOS XR, mentre il router PE deve generare il vettore PIM RPF-Proxy nel dominio PIM. Questo vettore PIM RPF-Proxy è necessario affinché i router IP possano eseguire RPF sull'indirizzo IP proxy (ABR). Da Cisco IOS XR 5.3.2, Cisco IOS XR può originare il vettore RPF-Proxy in un contesto globale. GTM può avere il vettore RPF-Proxy.
Per creare il vettore PIM RPF-Proxy, il router PE deve avere la seguente configurazione:
router pim
address-family [ipv4|ipv6]
rpf-vector
!
!
Ciò consente l'implementazione di GTM su MPLS perfetto.
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
1.0 |
14-Dec-2022 |
Versione iniziale |
Feedback