Sommario

Introduzione

Migrazione dei protocolli della struttura principale

Migrazione protocollo multicast C

Scenario 1.

Scenario 2.

Scenario 3.

Scenario 4.

Il problema

La soluzione

Conclusioni

Introduzione

In questo documento viene descritta la migrazione di MDT basati su albero multicast basati su albero del protocollo Multicast VPN (mVPN) Multicast indipendente (PIM) su albero del protocollo Multipoint Label Distribution Protocol (mLDP). Inoltre, la modalità di segnalazione dettagliata dei Data MDT al momento della migrazione. Questo documento descrive la migrazione solo per il router Ingress Provider Edge (PE) con Cisco IOS®-XR.

Migrazione dei protocolli della struttura principale

Il termine dual-encap si riferisce a un router in ingresso in grado di inoltrare un flusso multicast cliente (C) a diversi tipi di strutture centrali contemporaneamente. Ad esempio, il router PE in ingresso inoltra un flusso multicast C su un albero principale basato su PIM e un albero principale basato su mLDP contemporaneamente. Questo è un requisito per migrare correttamente mVPN da un tipo di albero core a un altro.

La doppia crittografia è supportata per PIM e mLDP.

La doppia crittografia non è supportata per Multiprotocol Label Switching (MPLS) P2MP Traffic Engineering (TE).

La migrazione o la coesistenza di MDT Generic Routing Encapsulation (GRE) e MDT mLDP predefinito si basa sul fatto che il router PE in ingresso inoltra un flusso multicast C su un albero principale basato su PIM e uno basato su mLDP contemporaneamente. Mentre il PE in ingresso viene inoltrato su entrambi gli MDT, è possibile eseguire la migrazione dei router PE in uscita uno per uno da un tipo di albero principale a un altro.

In genere, le route PE eseguono la migrazione dal modello di distribuzione mVPN meno recente utilizzando strutture ad albero principali basate su PIM a un modello di distribuzione mVPN utilizzando strutture basate su mLDP. L'implementazione mVPN più vecchia è Profile 0, che è una struttura ad albero basata su PIM, no Border Gateway Protocol (BGP) Auto-Discovery (AD) e PIM nella segnalazione di sovrapposizione. Tuttavia, la migrazione può avvenire anche in modo opposto.

Esaminiamo questo scenario di migrazione in quanto si tratta della migrazione più comune che si verifica: dal GRE nel core (profilo 0) a un profilo MDT mLDP predefinito.

Sono possibili alcuni profili mLDP predefiniti.

Diamo un'occhiata a questi:

- mLDP senza BGP AD

- mLDP con segnalazione BGP AD e PIM C

- mLDP con segnalazione BGP AD e BGP C

In quest'ultimo caso, c'è anche una migrazione del protocollo di segnalazione C.

Uno degli aspetti da tenere presente è che quando si utilizza BGP AD, l'MDT dei dati viene segnalato da BGP per impostazione predefinita. Se non è presente BGP AD, l'MDT dati non può essere segnalato da BGP.

In ogni caso, il file PE in ingresso deve avere sia il profilo 0 che il profilo mLDP configurato. Il PE in ingresso inoltrerà il traffico multicast C su entrambi i MDT (predefiniti o dati) di entrambi i protocolli della struttura principale. Pertanto, entrambi gli MDT predefiniti devono essere configurati nel file PE in ingresso.

Se il PE in uscita è in grado di eseguire i protocolli PIM e mLDP dell'albero principale, può decidere da quale albero prelevare il traffico multicast C. A tale scopo, è necessario configurare il criterio Reverse Path Forwarding (RPF) nell'PE in uscita.

Se il router PE in uscita è in grado di supportare solo il profilo 0, tale router si unirà solo alla struttura PIM nel core e riceverà il flusso multicast C nella struttura basata su PIM.

Nota: se si utilizza la modalità di sparsità PIM, sia RP-PE che S-PE devono essere raggiungibili in entrambi gli MDT basati su GRE e mLDP.

Migrazione protocollo multicast C

Il protocollo multicast C può essere migrato da PIM a BGP o viceversa. A tale scopo, è necessario configurare l'uscita PE in modo da scegliere PIM o BGP come protocollo di overlay. È l'Egress PE che invia un join da PIM o BGP. Il PE in ingresso può ricevere ed elaborare entrambi in uno scenario di migrazione.

Questo è un esempio di migrazione del protocollo multicast C, configurato sul PE in uscita:

router pim

vrf one

address-family ipv4

rpf topology route-policy rpf-for-one

mdt c-multicast-routing bgp

!

interface GigabitEthernet0/1/0/0

enable

!

!

!

!

route-policy rpf-for-one

set core-tree mldp-default

end-policy

!

BGP abilitato come protocollo di segnalazione overlay. Il valore di default è PIM.

Scenari

Vedere la Figura 1. per verificare l'impostazione utilizzata per gli scenari.

Figura 1.

In questi scenari, si dispone di almeno un router PE legacy come router PE ricevitore. Questo è un router che esegue solo il profilo 0 (impostazione predefinita, MDT - GRE - PIM e segnalazione multicast).

Su questo router deve essere configurato BGP IPv4 MDT.

È presente almeno un router Receiver-PE con un profilo basato su mLDP. Si tratta di tutti i profili MDT mLDP predefiniti (1, 9, 13, 12, 17), di tutti i profili MDT mLDP partizionati (2, 4, 5, 14, 15) e del profilo 7. È supportato anche il profilo 8 per P2MP TE.

Il router PE in ingresso è un router a doppia crittografia: esegue il profilo 0 e un profilo basato su mLDP.

Il router PE in ingresso deve inoltrare in qualsiasi momento il traffico sugli MDT basati su PIM e sugli MDT basati su mLDP. Questi MDT possono essere predefiniti e MDT dati.

Come router legacy, accettare un router con IOS, che può eseguire solo il profilo 0. La configurazione del router legacy è la seguente.

vrf definition one

rd 1:3

vpn id 1:1

route-target export 1:1

route-target import 1:1

!

address-family ipv4

mdt default 232.1.1.1

exit-address-family

È necessario configurare la MDT BGP IPv4:

router bgp 1

…

address-family ipv4 mdt

neighbor 10.1.100.7 activate

neighbor 10.1.100.7 send-community extended

exit-address-family

!

…

Scenario 1.

Uno o più router PE legacy come router Receiver-PE.

Uno o più router PE come router Receiver-PE eseguono il profilo 1 (MDT predefinito - mLDP MP2MP PIM C-mcast Signaling).

Non sono presenti segnali BGP AD o BGP C-multicast.

Configurazione del router Receiver-PE con profilo 1:

vrf one

vpn id 1:1

address-family ipv4 unicast

import route-target

1:1

!

export route-target

1:1

!

!

router pim

vrf one

address-family ipv4

rpf topology route-policy rpf-for-one

!

interface GigabitEthernet0/1/0/0

enable

!

!

!

!

route-policy rpf-for-one

set core-tree mldp-default

end-policy

!

multicast-routing

vrf one

address-family ipv4

mdt source Loopback0

mdt default mldp ipv4 10.1.100.7

mdt data 100

rate-per-route

interface all enable

!

accounting per-prefix

!

!

!

mpls ldp

mldp

logging notifications

address-family ipv4

!

!

!

route-policy rpf-for-one

set core-tree mldp-default

Configurazione del router PE in ingresso:

vrf one

vpn id 1:1

address-family ipv4 unicast

import route-target

1:1

!

export route-target

1:1

!

!

router pim

vrf one

address-family ipv4

!

interface GigabitEthernet0/1/0/0

enable

!

!

!

multicast-routing

vrf one

address-family ipv4

mdt source Loopback0

interface all enable

!

mdt default ipv4 232.1.1.1

mdt default mldp ipv4 10.1.100.7

mdt data 255

mdt data 232.1.2.0/24

!

!

!

mpls ldp

mldp

logging notifications

address-family ipv4

!

!

!

Il router PE in entrata deve avere una famiglia di indirizzi BGP IPv4 MDT, corrispondente a quella del router PE legacy.

Il file PE in ingresso deve essere inoltrato su entrambi i tipi di MDT:

Ingress-PE#show mrib vrf one route 232.100.1.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, MF - MPLS Encap, 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.2.9,232.100.1.1) RPF nbr: 10.2.2.9 Flags: RPF MT

MT Slot: 0/1/CPU0

Up: 00:56:09

Incoming Interface List

GigabitEthernet0/1/0/0 Flags: A, Up: 00:56:09

Outgoing Interface List

mdtone Flags: F NS MI MT MA, Up: 00:22:59      <<< PIM-based tree

Lmdtone Flags: F NS LMI MT MA, Up: 00:56:09    <<< mLDP-based tree

Il file PE in entrata dovrebbe vedere il file PE legacy sul segnale modale dell'interfaccia e il file PE del profilo 1 sull'interfaccia Lmdtone come router adiacente PIM:

Ingress-PE#show pim vrf one neighbor

PIM neighbors in VRF one

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.100.1                   Lmdtone 6w1d     00:01:29 1     P

10.1.100.2*                  Lmdtone               6w1d     00:01:15 1 (DR) P

10.1.100.2*                  mdtone                 5w0d     00:01:30 1     P

10.1.100.3                   mdtone 00:50:20 00:01:30 1 (DR) P

"debug pim vrf one mdt data" sul file PE in ingresso:

Viene inviato un TLV di unione PIM di tipo 1 (PIM core tree) e di tipo 2 (mLDP core tree). Il primo su mdtone e il secondo su Lmdtone.

pim[1140]: [13] MDT Grp lookup: Return match for grp 232.1.2.4 src 10.1.100.2 in local list (-)

pim[1140]: [13] In mdt timers process...

pim[1140]: [13] Processing MDT JOIN SEND timer for MDT null core mldp pointer in one

pim[1140]: [13] In join_send_update_timer: route->mt_head 50c53b44

pim[1140]: [13] Create new MDT tlv buffer for one for type 0x1

pim[1140]: [13] Buffer allocated for one mtu 1348 size 0

pim[1140]: [13] TLV type set to 0x1

pim[1140]: [13] TLV added for one mtu 1348 size 16

pim[1140]: [13] MDT cache upd: pe 0.0.0.0, (10.2.2.9,232.100.1.1), mdt_type 0x1, core (10.1.100.2,232.1.2.4), for vrf one [local, -], mt_lc 0x11, mdt_if 'mdtone', cache NULL

pim[1140]: [13] Looked up cache pe 0.0.0.0(10.2.2.9,232.100.1.1) mdt_type 0x1 in one (found) - No error

pim[1140]: [13] Cache get: Found entry for 0.0.0.0(10.2.2.9,232.100.1.1) mdt_type 0x1 in one

pim[1140]: [13] pim_mvrf_mdt_cache_update:946, mt_lc 0x11, copied mt_mdt_ifname 'mdtone'

pim[1140]: [13] Create new MDT tlv buffer for one for type 0x2

pim[1140]: [13] Buffer allocated for one mtu 1348 size 0

pim[1140]: [13] TLV type set to 0x2, o_type 0x2

pim[1140]: [13] TLV added for one mtu 1348 size 36

pim[1140]: [13] MDT cache upd: pe 0.0.0.0, (10.2.2.9,232.100.1.1), mdt_type 0x2, core src 10.1.100.2, id [mdt 1:1 1], for vrf one [local, -], mt_lc 0x11, mdt_if 'Lmdtone', cache NULL

pim[1140]: [13] Looked up cache pe 0.0.0.0(10.2.2.9,232.100.1.1) mdt_type 0x2 in one (found) - No error

pim[1140]: [13] Cache get: Found entry for 0.0.0.0(10.2.2.9,232.100.1.1) mdt_type 0x2 in one

pim[1140]: [13] pim_mvrf_mdt_cache_update:946, mt_lc 0x11, copied mt_mdt_ifname 'Lmdtone'

pim[1140]: [13] Set next send time for core type (0x0/0x2) (v: 10.2.2.9,232.100.1.1) in one

pim[1140]: [13] 2. Flush MDT Join for one on Lmdtone(10.1.100.2) 6 (Cnt:1, Reached size 36 MTU 1348)

pim[1140]: [13] 2. Flush MDT Join for one (Lo0) 10.1.100.2

pim[1140]: [13] 2. Flush MDT Join for one on mdtone(10.1.100.2) 6 (Cnt:1, Reached size 16 MTU 1348)

pim[1140]: [13] 2. Flush MDT Join for one (Lo0) 10.1.100.2

Ingress-PE#show pim vrf one mdt cache

Core Source     Cust (Source, Group)               Core Data       Expires

10.1.100.2       (10.2.2.9, 232.100.1.1)             232.1.2.4       00:02:36

10.1.100.2       (10.2.2.9, 232.100.1.1)             [mdt 1:1 1]     00:02:36

Nota: il valore TLV (PIM Join Type Length Value) è un messaggio PIM inviato tramite l'MDT predefinito e utilizzato per segnalare l'MDT dati. Viene inviato periodicamente, una volta ogni minuto.

Il sistema PE legacy in uscita:

"debug ip pim vrf one 232.10.1.1":

PIM(1): Receive MDT Packet (55759) from 10.1.100.2 (Tunnel3), length (ip: 44, udp: 24), ttl: 1PIM(1): TLV type: 1 length: 16 MDT Packet length: 16

Il file PE legacy memorizza nella cache il TLV di unione PIM:

Legacy-PE#show ip pim vrf one mdt receive

Joined MDT-data [group/mdt number : source] uptime/expires for VRF: one

[232.1.2.4 : 10.1.100.2] 00:01:10/00:02:45

Il file PE legacy unisce l'MDT dei dati nel core:

Legacy-PE#show ip mroute vrf one 232.100.1.1

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

L - Local, P - Pruned, R - RP-bit set, F - Register flag,

T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,

X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

U - URD, I - Received Source Specific Host Report,

Z - Multicast Tunnel, z - MDT-data group sender,

Y - Joined MDT-data group, y - Sending to MDT-data group,

G - Received BGP C-Mroute, g - Sent BGP C-Mroute,

N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,

Q - Received BGP S-A Route, q - Sent BGP S-A Route,

V - RD & Vector, v - Vector, p - PIM Joins on route,

x - VxLAN group

Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join

Timers: Uptime/Expires

Interface state: Interface, Next-Hop or VCD, State/Mode

(10.2.2.9, 232.100.1.1), 00:08:48/00:02:34, flags: sTY

Incoming interface: Tunnel3, RPF nbr 10.1.100.2, MDT:[10.1.100.2,232.1.2.4]/00:02:46

Outgoing interface list:

GigabitEthernet1/1, Forward/Sparse, 00:08:48/00:02:34

Il ricevitore-PE Profile 1 riceve anche il TLV di aggiunta PIM, ma per il Data MDT basato su mLDP:

Egress-PE#debug pim vrf one mdt data

pim[1161]: [13] Received MDT Packet on Lmdtone (vrf:one) from 10.1.100.2, len 36

pim[1161]: [13] Processing type 2 tlv

pim[1161]: [13] Received MDT Join TLV from 10.1.100.2 for cust route 10.2.2.9,232.100.1.1

MDT number 1 len 36

pim[1161]: [13] Looked up cache pe 10.1.100.2(10.2.2.9,232.100.1.1) mdt_type 0x2 in one

(found) - No error

pim[1161]: [13] MDT cache upd: pe 10.1.100.2, (10.2.2.9,232.100.1.1), mdt_type 0x2, core

src 10.1.100.2, id [mdt 1:1 1], for vrf one [remote, -], mt_lc 0xffffffff, mdt_if 'xxx',

cache NULL

pim[1161]: [13] Looked up cache pe 10.1.100.2(10.2.2.9,232.100.1.1) mdt_type 0x2 in one

(found) - No error

pim[1161]: [13] Cache get: Found entry for 10.1.100.2(10.2.2.9,232.100.1.1) mdt_type 0x2

in one

RP/0/RP1/CPU0:Nov 27 16:04:02.726 : Return match for [mdt 1:1 1] src 10.1.100.2 in remote

list (one)

pim[1161]: [13] Remote join: MDT [mdt 1:1 1] known in one. Refcount (1, 1)

Egress-PE#show pim vrf one mdt cache

Core Source     Cust (Source, Group)               Core Data       Expires

10.1.100.2       (10.2.2.9, 232.100.1.1)             [mdt 1:1 1]     00:02:12

Egress-PE#show mrib vrf one route 232.100.1.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, MF - MPLS Encap, 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.2.9,232.100.1.1) RPF nbr: 10.1.100.2 Flags: RPF

Up: 00:45:20

Incoming Interface List

Lmdtone Flags: A LMI, Up: 00:45:20

Outgoing Interface List

GigabitEthernet0/0/0/9 Flags: F NS LI, Up: 00:45:20

Scenario 2.

Sono presenti uno o più router PE legacy come router Receiver-PE.

Uno o più router PE come router Receiver-PE eseguono il profilo 9 (MDT predefinito - mLDP MP2MP BGP-AD PIM C-mcast Signaling).

È coinvolto BGP AD, ma non è presente alcuna segnalazione multicast BGP C.

Configurazione del router Receiver-PE con profilo 9:

vrf one

vpn id 1:1

address-family ipv4 unicast

import route-target

1:1

!

export route-target

1:1

!

!

router pim

vrf one

address-family ipv4

rpf topology route-policy rpf-for-one

!

interface GigabitEthernet0/1/0/0

enable

!

!

!

!

route-policy rpf-for-one

set core-tree mldp-default

end-policy

!

multicast-routing

vrf one

address-family ipv4

mdt source Loopback0

rate-per-route

interface all enable

accounting per-prefix

bgp auto-discovery mldp

!

mdt default mldp ipv4 10.1.100.7

!

!

!

router bgp 1

!

address-family vpnv4 unicast

!

!

address-family ipv4 mvpn

!

!

neighbor 10.1.100.7     <<< iBGP neighbor

remote-as 1

update-source Loopback0

address-family vpnv4 unicast

!

address-family ipv4 mvpn

!

!

vrf one

rd 1:1

address-family ipv4 unicast

redistribute connected

!

address-family ipv4 mvpn

!

!

mpls ldp

mldp

logging notifications

address-family ipv4

!

!

!

Il router PE in entrata deve avere una famiglia di indirizzi BGP IPv4 MDT, corrispondente a quella del router PE legacy. Il router PE in entrata deve avere una VPN IPv4 della famiglia di indirizzi BGP, corrispondente a quella del router PE in uscita Profile 9.

Configurazione del router PE in ingresso:

vrf one

vpn id 1:1

address-family ipv4 unicast

import route-target

1:1

!

export route-target

1:1

!

!

address-family ipv6 unicast

!

!

router pim

vrf one

address-family ipv4

mdt c-multicast-routing pim

announce-pim-join-tlv

!

interface GigabitEthernet0/1/0/0

enable

!

!

!

!

multicast-routing

vrf one

address-family ipv4

mdt source Loopback0

interface all enable

bgp auto-discovery mldp

!

mdt default ipv4 232.1.1.1

mdt default mldp ipv4 10.1.100.7

mdt data 255

mdt data 232.1.2.0/24

!

!

!

router bgp 1

address-family vpnv4 unicast

!

address-family ipv4 mdt

!

address-family ipv4 mvpn

!

neighbor 10.1.100.7     <<< iBGP neighbor

remote-as 1

update-source Loopback0

address-family vpnv4 unicast

!

address-family ipv4 mdt

!

address-family ipv4 mvpn

!

!

vrf one

rd 1:2

address-family ipv4 unicast

redistribute connected

!

address-family ipv4 mvpn

!

mpls ldp

mldp

logging notifications

address-family ipv4

!

!

!

Senza il comando "notice-pim-join-tlv", il router PE in ingresso non invia i messaggi TLV di aggiunta PIM sugli MDT predefiniti, se è abilitato il rilevamento automatico BGP (AD). Senza questo comando, il router PE in ingresso invia solo un aggiornamento del tipo di route 3 mvpn BGP IPv4. Il router Profile 9 Egress PE non riceve l'aggiornamento BGP e installa il messaggio Data MDT nella sua cache. Il router PE legacy non esegue BGP AD e pertanto non viene in grado di apprendere il messaggio di join MDT dati tramite BGP.

Il PE in ingresso deve inoltrare il traffico multicast C su entrambi i tipi di MDT:

Ingress-PE#show mrib vrf one route 232.100.1.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, MF - MPLS Encap, 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.2.9,232.100.1.1) RPF nbr: 10.2.2.9 Flags: RPF MT

MT Slot: 0/1/CPU0

Up: 05:03:56

Incoming Interface List

GigabitEthernet0/1/0/0 Flags: A, Up: 05:03:56

Outgoing Interface List

mdtone Flags: F NS MI MT MA, Up: 05:03:56

Lmdtone Flags: F NS LMI MT MA, Up: 05:03:12

Il file PE in entrata dovrebbe vedere il file PE legacy sul segnale modale dell'interfaccia e il file PE Profile 9 sull'interfaccia Lmdtone come router adiacente PIM:

Ingress-PE#show pim vrf one neighbor

PIM neighbors in VRF one

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.100.1                   Lmdtone               6w1d     00:01:18 1     P

10.1.100.2*                  Lmdtone               6w1d     00:01:34 1 (DR) P

10.1.100.2*                  mdtone                5w0d     00:01:18 1     P

10.1.100.3                   mdtone                06:00:03 00:01:21 1 (DR)

Il server PE di uscita Profile 9 riceve il messaggio Data MDT come aggiornamento BGP per una route di tipo 3 nella VPN IPv4 della famiglia di indirizzi:

Egress-PE#show bgp ipv4 mvpn vrf one

BGP router identifier 10.1.100.1, local AS number 1

BGP generic scan interval 60 secs

BGP table state: Active

Table ID: 0x0   RD version: 1367879340

BGP main routing table version 92

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: 1:1 (default for vrf one)

*> [1][10.1.100.1]/40 0.0.0.0                               0 i

*>i[1][10.1.100.2]/40 10.1.100.2                   100     0 i

*>i[3][32][10.2.2.9][32][232.100.1.1][10.1.100.2]/120

10.1.100.2                   100     0 i

Processed 3 prefixes, 3 paths

Egress-PE#show bgp ipv4 mvpn vrf one [3][32][10.2.2.9][32][232.100.1.1][10.1.100.2]/120

BGP routing table entry for [3][32][10.2.2.9][32][232.100.1.1][10.1.100.2]/120, Route

Distinguisher: 1:1

Versions:

Process           bRIB/RIB SendTblVer

Speaker                 92         92

Last Modified: Nov 27 20:25:32.474 for 00:44:22

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.1.100.2 (metric 12) from 10.1.100.7 (10.1.100.2)

Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate,

imported

Received Path ID 0, Local Path ID 1, version 92

Community: no-export

Extended community: RT:1:1

Originator: 10.1.100.2, Cluster list: 10.1.100.7

PMSI: flags 0x00, type 2, label 0, ID

0x060001040a016402000e02000b0000010000000100000001

Source VRF: default, Source Route Distinguisher: 1:2

Questa route BGP è una route di tipo 3, per il protocollo tunnel di tipo 2, che è LSP P2MP m mLDP (Data MDT basato su LSP mLSP P2MP). Nessuna voce BGP route-type 3 per alcuna struttura PIM, poiché BGP AD non è abilitato per PIM.

"debug pim vrf one mdt data" sul file PE in ingresso:

pim[1140]: [13] In mdt timers process...

pim[1140]: [13] Processing MDT JOIN SEND timer for MDT null core mldp pointer in one

pim[1140]: [13] In join_send_update_timer: route->mt_head 50c53b44

pim[1140]: [13] Create new MDT tlv buffer for one for type 0x1

pim[1140]: [13] Buffer allocated for one mtu 1348 size 0

pim[1140]: [13] TLV type set to 0x1

pim[1140]: [13] TLV added for one mtu 1348 size 16

pim[1140]: [13] MDT cache upd: pe 0.0.0.0, (10.2.2.9,232.100.1.1), mdt_type 0x1, core

(10.1.100.2,232.1.2.5), for vrf one [local, -], mt_lc 0x11, mdt_if 'mdtone', cache NULL

pim[1140]: [13] Looked up cache pe 0.0.0.0(10.2.2.9,232.100.1.1) mdt_type 0x1 in one

(found) - No error

pim[1140]: [13] Cache get: Found entry for 0.0.0.0(10.2.2.9,232.100.1.1) mdt_type 0x1 in

one

pim[1140]: [13] pim_mvrf_mdt_cache_update:946, mt_lc 0x11, copied mt_mdt_ifname 'mdtone'

pim[1140]: [13] Create new MDT tlv buffer for one for type 0x2

pim[1140]: [13] Buffer allocated for one mtu 1348 size 0

pim[1140]: [13] TLV type set to 0x2, o_type 0x2

pim[1140]: [13] TLV added for one mtu 1348 size 36

pim[1140]: [13] MDT cache upd: pe 0.0.0.0, (10.2.2.9,232.100.1.1), mdt_type 0x2, core src

10.1.100.2, id [mdt 1:1 1], for vrf one [local, -], mt_lc 0x11, mdt_if 'Lmdtone', cache

NULL

: pim[1140]: [13] Looked up cache pe 0.0.0.0(10.2.2.9,232.100.1.1) mdt_type 0x2 in one

(found) - No error

pim[1140]: [13] Cache get: Found entry for 0.0.0.0(10.2.2.9,232.100.1.1) mdt_type 0x2 in

one

pim[1140]: [13] pim_mvrf_mdt_cache_update:946, mt_lc 0x11, copied mt_mdt_ifname 'Lmdtone'

pim[1140]: [13] Set next send time for core type (0x0/0x2) (v: 10.2.2.9,232.100.1.1) in

one

pim[1140]: [13] 2. Flush MDT Join for one on Lmdtone(10.1.100.2) 6 (Cnt:1, Reached size

36 MTU 1348)

pim[1140]: [13] 2. Flush MDT Join for one (Lo0) 10.1.100.2

pim[1140]: [13] 2. Flush MDT Join for one on mdtone(10.1.100.2) 6 (Cnt:1, Reached size 16

MTU 1348)

pim[1140]: [13] 2. Flush MDT Join for one (Lo0) 10.1.100.2

Il file PE in ingresso invia un TLV di unione PIM per l'MDT dei dati basato su PIM e su mLDP.

Nella versione precedente di PE:

"debug ip pim vrf one 232.10.1.1":

PIM(1): Receive MDT Packet (56333) from 10.1.100.2 (Tunnel3), length (ip: 44, udp: 24), ttl: 1

PIM(1): TLV type: 1 length: 16 MDT Packet length: 16

Il file PE legacy riceve e memorizza nella cache il TLV di unione PIM:

Legacy-PE#show ip pim vrf one mdt receive

Joined MDT-data [group/mdt number : source] uptime/expires for VRF: one

[232.1.2.5 : 10.1.100.2] 00:23:30/00:02:33

Il file PE legacy unisce l'MDT dei dati nel core:

Legacy-PE#show ip mroute vrf one 232.100.1.1

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

L - Local, P - Pruned, R - RP-bit set, F - Register flag,

T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,

X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

U - URD, I - Received Source Specific Host Report,

Z - Multicast Tunnel, z - MDT-data group sender,

Y - Joined MDT-data group, y - Sending to MDT-data group,

G - Received BGP C-Mroute, g - Sent BGP C-Mroute,

N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,

Q - Received BGP S-A Route, q - Sent BGP S-A Route,

V - RD & Vector, v - Vector, p - PIM Joins on route,

x - VxLAN group

Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join

Timers: Uptime/Expires

Interface state: Interface, Next-Hop or VCD, State/Mode

(10.2.2.9, 232.100.1.1), 05:13:35/00:03:02, flags: sTY

Incoming interface: Tunnel3, RPF nbr 10.1.100.2, MDT:[10.1.100.2,232.1.2.5]/00:02:37

Outgoing interface list:

GigabitEthernet1/1, Forward/Sparse, 05:13:35/00:03:02

Il ricevitore Profile 9-PE.

"debug pim vrf one mdt data" in Profile 9 Egress PE:

pim[1161]: [13] Received MDT Packet on Lmdtone (vrf:one) from 10.1.100.2, len 36

pim[1161]: [13] Processing type 2 tlv

pim[1161]: [13] Received MDT Join TLV from 10.1.100.2 for cust route 10.2.2.9,232.100.1.1

MDT number 1 len 36

pim[1161]: [13] Looked up cache pe 10.1.100.2(10.2.2.9,232.100.1.1) mdt_type 0x2 in one

(found) - No error

pim[1161]: [13] MDT cache upd: pe 10.1.100.2, (10.2.2.9,232.100.1.1), mdt_type 0x2, core

src 10.1.100.2, id [mdt 1:1 1], for vrf one [remote, -], mt_lc 0xffffffff, mdt_if 'xxx',

cache NULL

pim[1161]: [13] Looked up cache pe 10.1.100.2(10.2.2.9,232.100.1.1) mdt_type 0x2 in one

(found) - No error

pim[1161]: [13] Cache get: Found entry for 10.1.100.2(10.2.2.9,232.100.1.1) mdt_type 0x2

in one

pim[1161]: [13] MDT lookup: Return match for [mdt 1:1 1] src 10.1.100.2 in remote list

(one)

pim[1161]: [13] Remote join: MDT [mdt 1:1 1] known in one. Refcount (1, 1)

Il ricevitore-PE Profile 9 riceve e memorizza nella cache il TLV di aggiunta del PIM. Il ricevitore-PE Profile 9 ha inoltre appreso l'MDT dei dati a causa della ricezione del messaggio di aggiornamento BGP per un tipo di route 3 dal modulo PE in ingresso. Il TLV di join PIM e il tipo di route del messaggio di aggiornamento BGP sono equivalenti e contengono le stesse informazioni relative al tunnel della struttura principale per il Data MDT.

Egress-PE#show pim vrf one mdt cache

Core Source     Cust (Source, Group)               Core Data       Expires

10.1.100.2       (10.2.2.9, 232.100.1.1)             [mdt 1:1 1]     00:02:35

Egress-PE#show mrib vrf one route 232.100.1.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, MF - MPLS Encap, 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.2.9,232.100.1.1) RPF nbr: 10.1.100.2 Flags: RPF

Up: 05:10:22

Incoming Interface List

Lmdtone Flags: A LMI, Up: 05:10:22

Outgoing Interface List

GigabitEthernet0/0/0/9 Flags: F NS LI, Up: 05:10:22

Scenario 3.

Uno o più router PE legacy come router Receiver-PE.

Uno o più router PE come router Receiver-PE eseguono il profilo 13 (MDT predefinito - mLDP MP2MP BGP-AD BGP C-mcast Signaling).

Sono coinvolti BGP AD e la segnalazione multicast BGP C.

Configurazione del router Receiver-PE con profilo 13:

vrf one

vpn id 1:1

address-family ipv4 unicast

import route-target

1:1

!

export route-target

1:1

!

!

router pim

vrf one

address-family ipv4

rpf topology route-policy rpf-for-one

mdt c-multicast-routing bgp

!

interface GigabitEthernet0/1/0/0

enable

!

!

!

!

route-policy rpf-for-one

set core-tree mldp-default

end-policy

!

multicast-routing

vrf one

address-family ipv4

mdt source Loopback0

rate-per-route

interface all enable

accounting per-prefix

bgp auto-discovery mldp

!

mdt default mldp ipv4 10.1.100.7

!

!

!

router bgp 1

!

address-family vpnv4 unicast

!

!

address-family ipv4 mvpn

!

!

neighbor 10.1.100.7     <<< iBGP neighbor

remote-as 1

update-source Loopback0

!

address-family vpnv4 unicast

!

address-family ipv4 mvpn

!

!

vrf one

rd 1:1

address-family ipv4 unicast

redistribute connected

!

address-family ipv4 mvpn

!

!

mpls ldp

mldp

logging notifications

address-family ipv4

!

!

!

Configurazione del router PE in ingresso:

vrf one

vpn id 1:1

address-family ipv4 unicast

import route-target

1:1

!

export route-target

1:1

!

!

address-family ipv6 unicast

!

!

router pim

vrf one

address-family ipv4

mdt c-multicast-routing bgp

announce-pim-join-tlv

!

interface GigabitEthernet0/1/0/0

enable

!

!

!

!

multicast-routing

vrf one

address-family ipv4

mdt source Loopback0

interface all enable

mdt default ipv4 232.1.1.1

mdt default mldp ipv4 10.1.100.7

mdt data 255

mdt data 232.1.2.0/24

!

!

!

router bgp 1

address-family vpnv4 unicast

!

address-family ipv4 mdt

!

address-family ipv4 mvpn

!

neighbor 10.1.100.7      <<< iBGP neighbor

remote-as 1

update-source Loopback0

address-family vpnv4 unicast

!

address-family ipv4 mdt

!

address-family ipv4 mvpn

!

!

vrf one

rd 1:2

address-family ipv4 unicast

redistribute connected

!

address-family ipv4 mvpn

!

mpls ldp

mldp

logging notifications

address-family ipv4

!

!

!

Se BGP AD è abilitato, il router PE in ingresso non invia i messaggi TLV di aggiunta PIM tramite l'MDT predefinito senza il comando notice-pim-join-tlv. Senza questo comando, il router PE in ingresso invia solo un aggiornamento del tipo di route 3 mvpn BGP IPv4. Il router Profile 13 Egress PE non riceve l'aggiornamento BGP e installa il messaggio Data MDT nella sua cache. Il router PE legacy non esegue BGP AD e pertanto non viene in grado di apprendere il messaggio di join MDT dati tramite BGP.

Il file PE in ingresso deve essere inoltrato su entrambi i tipi di MDT:

Ingress-PE#show mrib vrf one route 232.100.1.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, MF - MPLS Encap, 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.2.9,232.100.1.1) RPF nbr: 10.2.2.9 Flags: RPF MT

MT Slot: 0/1/CPU0

Up: 19:49:27

Incoming Interface List

GigabitEthernet0/1/0/0 Flags: A, Up: 19:49:27

Outgoing Interface List

mdtone Flags: F MI MT MA, Up: 19:49:27

Lmdtone Flags: F LMI MT MA, Up: 01:10:15

Il file PE in entrata dovrebbe vedere il file PE legacy sul segnale modulare dell'interfaccia come un router adiacente PIM. Tuttavia, non è necessario che Profile 13 PE su Lmdtone di interfaccia sia adiacente a PIM, in quanto BGP è ora utilizzato come protocollo di segnalazione multicast C.

"debug pim vrf one mdt data" sul file PE in ingresso:

pim[1140]: [13] In mdt timers process...

pim[1140]: [13] Processing MDT JOIN SEND timer for MDT null core mldp pointer in one

pim[1140]: [13] In join_send_update_timer: route->mt_head 50c53b44

pim[1140]: [13] Create new MDT tlv buffer for one for type 0x1

pim[1140]: [13] Buffer allocated for one mtu 1348 size 0

pim[1140]: [13] TLV type set to 0x1

pim[1140]: [13] TLV added for one mtu 1348 size 16

pim[1140]: [13] MDT cache upd: pe 0.0.0.0, (10.2.2.9,232.100.1.1), mdt_type 0x1, core (10.1.100.2,232.1.2.5), for vrf one [local, -], mt_lc 0x11, mdt_if 'mdtone', cache NULL

pim[1140]: [13] Looked up cache pe 0.0.0.0(10.2.2.9,232.100.1.1) mdt_type 0x1 in one (found) - No error

pim[1140]: [13] Cache get: Found entry for 0.0.0.0(10.2.2.9,232.100.1.1) mdt_type 0x1 in one

pim[1140]: [13] pim_mvrf_mdt_cache_update:946, mt_lc 0x11, copied mt_mdt_ifname 'mdtone'

pim[1140]: [13] Create new MDT tlv buffer for one for type 0x2

pim[1140]: [13] Buffer allocated for one mtu 1348 size 0

pim[1140]: [13] TLV type set to 0x2, o_type 0x2

pim[1140]: [13] TLV added for one mtu 1348 size 36

pim[1140]: [13] MDT cache upd: pe 0.0.0.0, (10.2.2.9,232.100.1.1), mdt_type 0x2, core src 10.1.100.2, id [mdt 1:1 1], for vrf one [local, -], mt_lc 0x11, mdt_if 'Lmdtone', cache NULL

pim[1140]: [13] Looked up cache pe 0.0.0.0(10.2.2.9,232.100.1.1) mdt_type 0x2 in one (found) - No error

pim[1140]: [13] Cache get: Found entry for 0.0.0.0(10.2.2.9,232.100.1.1) mdt_type 0x2 in one

pim[1140]: [13] pim_mvrf_mdt_cache_update:946, mt_lc 0x11, copied mt_mdt_ifname 'Lmdtone'

pim[1140]: [13] Set next send time for core type (0x0/0x2) (v: 10.2.2.9,232.100.1.1) in one

pim[1140]: [13] 2. Flush MDT Join for one on Lmdtone(10.1.100.2) 6 (Cnt:1, Reached size 36 MTU 1348)

pim[1140]: [13] 2. Flush MDT Join for one (Lo0) 10.1.100.2

pim[1140]: [13] 2. Flush MDT Join for one on mdtone(10.1.100.2) 6 (Cnt:1, Reached size 16 MTU 1348)

pim[1140]: [13] 2. Flush MDT Join for one (Lo0) 10.1.100.2

pim[1140]: [13] MDT Grp lookup: Return match for grp 232.1.2.5 src 10.1.100.2 in local list (-)

Il file PE in ingresso invia TLV di unione PIM per l'MDT dei dati basato su PIM e su mLDP.

"debug ip pim vrf one 232.100.1.1" sul sistema PE legacy:

PIM(1): Receive MDT Packet (57957) from 10.1.100.2 (Tunnel3), length (ip: 44, udp: 24), ttl: 1

PIM(1): TLV type: 1 length: 16 MDT Packet length: 16

Il file PE legacy memorizza nella cache il TLV di unione PIM:

Legacy-PE#show ip pim vrf one mdt receive

Joined MDT-data [group/mdt number : source]  uptime/expires for VRF: one

[232.1.2.5 : 10.1.100.2]  00:03:36/00:02:24

Il file PE legacy unisce l'MDT dei dati nel core:

Legacy-PE#show ip mroute vrf one 232.100.1.1

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

L - Local, P - Pruned, R - RP-bit set, F - Register flag,

T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,

X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

U - URD, I - Received Source Specific Host Report,

Z - Multicast Tunnel, z - MDT-data group sender,

Y - Joined MDT-data group, y - Sending to MDT-data group,

G - Received BGP C-Mroute, g - Sent BGP C-Mroute,

N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,

Q - Received BGP S-A Route, q - Sent BGP S-A Route,

V - RD & Vector, v - Vector, p - PIM Joins on route,

x - VxLAN group

Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join

Timers: Uptime/Expires

Interface state: Interface, Next-Hop or VCD, State/Mode

(10.2.2.9, 232.100.1.1), 18:53:53/00:02:50, flags: sTY

Incoming interface: Tunnel3, RPF nbr 10.1.100.2, MDT:[10.1.100.2,232.1.2.5]/00:02:02

Outgoing interface list:

GigabitEthernet1/1, Forward/Sparse, 18:53:53/00:02:50

Il modulo Profile 13 Receiver-PE:

"debug pim vrf one mdt data" sul profilo 13 in uscita PE:

pim[1161]: [13] Received MDT Packet on Lmdtone (vrf:one) from 10.1.100.2, len 36

pim[1161]: [13] Processing type 2 tlv

pim[1161]: [13] Received MDT Join TLV from 10.1.100.2 for cust route 10.2.2.9,232.100.1.1 MDT number 1 len 36

pim[1161]: [13] Looked up cache pe 10.1.100.2(10.2.2.9,232.100.1.1) mdt_type 0x2 in one (found) - No error

pim[1161]: [13] MDT cache upd: pe 10.1.100.2, (10.2.2.9,232.100.1.1), mdt_type 0x2, core src 10.1.100.2, id [mdt 1:1 1], for vrf one [remote, -], mt_lc 0xffffffff, mdt_if 'xxx', cache NULL

pim[1161]: [13] Looked up cache pe 10.1.100.2(10.2.2.9,232.100.1.1) mdt_type 0x2 in one (found) - No error

pim[1161]: [13] Cache get: Found entry for 10.1.100.2(10.2.2.9,232.100.1.1) mdt_type 0x2 in one

pim[1161]: [13] MDT lookup: Return match for [mdt 1:1 1] src 10.1.100.2 in remote list (one)

pim[1161]: [13] Remote join: MDT [mdt 1:1 1] known in one. Refcount (1, 1)

RP/0/RP1/CPU0:Legacy-PE#show pim vrf one mdt cache

Core Source      Cust (Source, Group)                Core Data        Expires

10.1.100.2       (10.2.2.9, 232.100.1.1)             [mdt 1:1 1]      00:02:21

Il modulo Profile 13 Receiver-PE riceve e memorizza nella cache il valore TLV di aggiunta del PIM per l'MDT basato su mLDP. Il modulo Profile 13 Receiver-PE ha anche appreso della MDT dei dati a causa della ricezione del messaggio di aggiornamento BGP per un tipo di route 3 dal modulo PE in ingresso. Il TLV di join PIM e il tipo di route del messaggio di aggiornamento BGP sono equivalenti e contengono le stesse informazioni relative al tunnel della struttura principale per il Data MDT.

Ingress-PE#show bgp ipv4 mvpn vrf one

BGP router identifier 10.1.100.1, local AS number 1

BGP generic scan interval 60 secs

BGP table state: Active

Table ID: 0x0   RD version: 1367879340

BGP main routing table version 93

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: 1:1 (default for vrf one)

*> [1][10.1.100.1]/40 0.0.0.0                                0 i

*>i[1][10.1.100.2]/40 10.1.100.2                    100      0 i

*>i[3][32][10.2.2.9][32][232.100.1.1][10.1.100.2]/120

10.1.100.2                    100      0 i

*> [7][1:2][1][32][10.2.2.9][32][232.100.1.1]/184

0.0.0.0                                0 i

Processed 4 prefixes, 4 paths

Egress-PE#show bgp ipv4 mvpn vrf one [3][32][10.2.2.9][32][232.100.1.1][10.1.100.2]/120

BGP routing table entry for [3][32][10.2.2.9][32][232.100.1.1][10.1.100.2]/120, Route Distinguisher: 1:1

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                 92          92

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.1.100.2 (metric 12) from 10.1.100.7 (10.1.100.2)

Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported

Received Path ID 0, Local Path ID 1, version 92

Community: no-export

Extended community: RT:1:1

Originator: 10.1.100.2, Cluster list: 10.1.100.7

PMSI: flags 0x00, type 2, label 0, ID 0x060001040a016402000e02000b0000010000000100000001

Source VRF: default, Source Route Distinguisher: 1:2

Questa route BGP è una route di tipo 3, per il protocollo tunnel di tipo 2, che è LSP P2MP m mLDP (Data MDT basato su LSP mLSP P2MP). Nessun tipo di route BGP 3 per alcun albero PIM, poiché BGP AD non è abilitato per PIM.

È disponibile anche un route-type 7 perché la segnalazione multicast C è attivata tra il Profile 13 Egress PE e il Ingress PE. L'aggiornamento BGP del tipo di route 7 viene inviato dal file PE di profilo 13 in uscita al file PE in entrata.

Scenario 4.

In questo scenario, nel contesto VPN è disponibile la modalità di sparsità PIM.

Uno o più router PE legacy come router Source-PE.

Uno o più router PE come router Receiver-PE eseguono il profilo 13 (MDT predefinito - mLDP MP2MP BGP-AD BGP C-mcast Signaling). Sono coinvolti BGP AD e la segnalazione multicast BGP C. Poiché questi router PE devono essere in grado di ricevere il traffico direttamente dal router PE di origine, ovvero il router PE legacy, devono eseguire anche il profilo 0.

L'RP-PE è un router PE che esegue il profilo 13 (MDT predefinito - mLDP MP2MP BGP-AD BGP C-mcast Signaling). Sono coinvolti BGP AD e la segnalazione multicast BGP C. Poiché il router RP-PE deve essere in grado di ricevere il traffico direttamente dal router Source-PE, ovvero il router PE legacy, è necessario che esegua anche il profilo 0.

Il routing multicast ha funzionato nello scenario 3, ma potrebbe funzionare solo per SSM (Source-Specific Multicast). Se la segnalazione C è in modalità sparse, il multicast potrebbe non riuscire. Ciò dipende dalla posizione del punto di Rendez-Vous (RP). Se la segnalazione nella sovrapposizione è solo (S, G), il routing multicast funzionerà come nello scenario 3. Ciò si verifica se l'RP si trova nella sede del ricevitore. Se l'RP si trova sul sito di un ricevitore, il ricevitore-PE non invierà un (*, G) Join in overlay, né da PIM né da BGP. Se invece l'RP si trova nella sorgente PE, o in un altro PE, nella sovrapposizione vi saranno (*, G) e (S, G) segnali. Il routing multicast potrebbe avere esito negativo se si esegue questa operazione con la configurazione come nello scenario 3.

Vedere la Figura 2. Mostra una rete con un Source-PE (Legacy-PE), un RP-PE (PE2) e un Receiver-PE (PE1).

Figura 2.

I router PE in uscita devono inviare join per (*,G). Il protocollo da utilizzare dipende dalla configurazione. Egress-PE utilizzerà BGP e il router Legacy-Source-PE utilizzerà PIM se ha anche un ricevitore. L'albero condiviso verrà quindi segnalato correttamente. Si verificherà un problema quando l'origine inizia l'invio: la struttura di origine non verrà segnalata.

Il problema

Una volta che l'origine ha iniziato l'invio, l'RP riceve i pacchetti di registro dal PIM First Hop Router (FHR). Potrebbe trattarsi del router Legacy-Source-PE. L'RP-PE dovrebbe quindi inviare un'unione PIM (S, G) verso il Legacy-Source-PE, poiché il Legacy-Source-PE non esegue BGP come protocollo di segnalazione di sovrapposizione. Tuttavia, l'RP-PE ha BGP configurato come protocollo di segnalazione overlay. Pertanto, Legacy-Source-PE non riceverà mai un messaggio PIM (S, G) Join dall'RP-PE e pertanto non è possibile segnalare l'albero di origine da Source a RP. L'installazione è bloccata nella fase di registrazione. L'elenco di interfacce in uscita (OIL) in Legacy-Source-PE sarà vuoto:

Legacy-PE#show ip mroute vrf one 225.1.1.1

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

L - Local, P - Pruned, R - RP-bit set, F - Register flag,

T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,

X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

U - URD, I - Received Source Specific Host Report,

Z - Multicast Tunnel, z - MDT-data group sender,

Y - Joined MDT-data group, y - Sending to MDT-data group,

G - Received BGP C-Mroute, g - Sent BGP C-Mroute,

N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,

Q - Received BGP S-A Route, q - Sent BGP S-A Route,

V - RD & Vector, v - Vector, p - PIM Joins on route,

x - VxLAN group

Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join

Timers: Uptime/Expires

Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 225.1.1.1), 00:05:47/stopped, RP 10.2.100.9, flags: SPF

Incoming interface: Tunnel3, RPF nbr 10.1.100.2

Outgoing interface list: Null

(10.2.3.10, 225.1.1.1), 00:05:47/00:02:42, flags: PFT

Incoming interface: GigabitEthernet1/1, RPF nbr 10.2.3.10

Outgoing interface list: Null

Per risolvere questo problema, è necessario che l'RP-PE invii un join PIM per (S, G) al Legacy-Source-PE, mentre l'RP-PE dispone ancora di BGP abilitato come protocollo di segnalazione sovrapposto per i router non legacy. Se un'origine è connessa dietro un router non legacy, l'RP-PE deve inviare un messaggio di aggiornamento BGP di tipo route 7 verso tale router non legacy.

L'RP-PE può utilizzare sia PIM che BGP come segnalazione di sovrimpressione. La scelta di uno dei due verrà determinata da una regola di route. È necessario disporre del comando di migrazione in PIM router per il VRF. Per la rete illustrata nella Figura 2, questa è la configurazione necessaria sull'RP-PE:

router pim

vrf one

address-family ipv4

rpf topology route-policy rpf-for-one

mdt c-multicast-routing bgp

migration route-policy PIM-to-BGP

announce-pim-join-tlv

!

interface GigabitEthernet0/1/0/0

enable

!

!

!

!

route-policy rpf-for-one

if next-hop in (10.1.100.3/32) then

set core-tree pim-default

else

set core-tree mldp-default

endif

end-policy

!

route-policy PIM-to-BGP

if next-hop in (10.1.100.3/32) then

set c-multicast-routing pim

else

set c-multicast-routing bgp

endif

end-policy

!

multicast-routing

vrf one

address-family ipv4

mdt source Loopback0

rate-per-route

interface all enable

accounting per-prefix

bgp auto-discovery mldp

!

mdt default ipv4 232.1.1.1

mdt default mldp ipv4 10.1.100.7

!

!

!

Il parametro route-policy PIM-to-BGP specifica che se il router PE remoto è 10.1.100.3 (Legacy-Source-PE), utilizzare PIM come protocollo di segnalazione in sovrimpressione. In caso contrario (per il router PE non legacy), il protocollo BGP viene utilizzato come protocollo di segnalazione in sovrimpressione. In questo modo, l'RP-PE invia un'unione PIM (S, G) verso l'unità Legacy-Source-PE sull'MDT di default basato su PIM. Legacy-Source-PE include ora la voce (S, G):

Legacy-PE#show ip mroute vrf one 225.1.1.1

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

L - Local, P - Pruned, R - RP-bit set, F - Register flag,

T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,

X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

U - URD, I - Received Source Specific Host Report,

Z - Multicast Tunnel, z - MDT-data group sender,

Y - Joined MDT-data group, y - Sending to MDT-data group,

G - Received BGP C-Mroute, g - Sent BGP C-Mroute,

N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,

Q - Received BGP S-A Route, q - Sent BGP S-A Route,

V - RD & Vector, v - Vector, p - PIM Joins on route,

x - VxLAN group

Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join

Timers: Uptime/Expires

Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 225.1.1.1), 00:11:56/stopped, RP 10.2.100.9, flags: SPF

Incoming interface: Tunnel3, RPF nbr 10.1.100.2

Outgoing interface list: Null

(10.2.3.10, 225.1.1.1), 00:11:56/00:03:22, flags: FT

Incoming interface: GigabitEthernet1/1, RPF nbr 10.2.3.10

Outgoing interface list:

Tunnel3, Forward/Sparse, 00:00:11/00:03:18

Il ricevitore può ricevere i pacchetti multicast se l'RP-PE li instrada: inoltra i pacchetti multicast ricevuti dall'MDT all'albero Lmdt.

Nota: verificare se il router RP-PE è in grado di supportare la funzionalità di risposta PE su tale piattaforma e software.

RP/0/3/CPU1:PE2#show mrib vrf one route 225.1.1.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, MF - MPLS Encap, 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

(*,225.1.1.1) RPF nbr: 10.2.2.9 Flags: C RPF

Up: 00:53:59

Incoming Interface List

GigabitEthernet0/1/0/0 Flags: A, Up: 00:53:59

Outgoing Interface List

Lmdtone Flags: F LMI, Up: 00:53:59

(10.2.3.10,225.1.1.1) RPF nbr: 10.1.100.3 Flags: RPF

Up: 00:03:00

Incoming Interface List

mdtone Flags: A MI, Up: 00:03:00

Outgoing Interface List

Lmdtone Flags: F NS LMI, Up: 00:03:00

Indipendentemente dal fatto che il router LHR (Last Hop Router) abbia o meno configurato lo switchover SPT, il traffico multicast continua a essere inoltrato attraverso la struttura condivisa, verso l'RP-PE. Vedere la Figura 3. per verificare come viene inoltrato il traffico multicast.

Figura 3.

L'Egress-PE non ha voce (S, G):

RP/0/RP1/CPU0:PE1#show mrib vrf one route 225.1.1.1

IP Multicast Routing Information Bas

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, MF - MPLS Encap, 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

(*,225.1.1.1) RPF nbr: 10.1.100.2 Flags: C RPF

Up: 04:35:36

Incoming Interface List

Lmdtone Flags: A LMI, Up: 03:00:24

Outgoing Interface List

GigabitEthernet0/0/0/9 Flags: F NS, Up: 04:35:36

Se Egress-PE è l'LHR, non avrà una voce (S, G). Il motivo per cui l'uscita-PE non può passare alla voce (S, G) è che non ha ricevuto una route attiva all'origine BGP da un router PE. Il traffico multicast viene inoltrato come mostrato nella Figura 3.

Tuttavia, è possibile che l'Egress-PE non sia l'LHR, ma che un router CE sul sito Egress-PE sia l'LHR. Se il router CE non passa all'albero di origine, l'uscita PE riceve un'unione PIM (S, G) e installa la voce (S, G).

RP/0/RP1/CPU0:PE1#show mrib vrf one route 225.1.1.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, MF - MPLS Encap, 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

(*,225.1.1.1) RPF nbr: 10.1.100.2 Flags: C RPF

Up: 00:04:51

Incoming Interface List

Lmdtone Flags: A LMI, Up: 00:04:51

Outgoing Interface List

GigabitEthernet0/0/0/9 Flags: F NS, Up: 00:04:51

(10.2.3.10,225.1.1.1) RPF nbr: 10.1.100.3 Flags: RPF

Up: 00:00:27

Incoming Interface List

Lmdtone Flags: A LMI, Up: 00:00:27

Outgoing Interface List

GigabitEthernet0/0/0/9 Flags: F NS, Up: 00:00:27

Tuttavia, Egress-PE ora eseguirà il RPF sull'origine e troverà il router Legacy-Source-PE come router adiacente:

RP/0/RP1/CPU0:PE1#show pim vrf one rpf 10.2.3.10

Table: IPv4-Unicast-default

* 10.2.3.10/32 [200/0]

via Lmdtone with rpf neighbor 10.1.100.3

Connector: 1:3:10.1.100.3, Nexthop: 10.1.100.3

Poiché non esiste alcun MDT tra Egress-PE e Legacy-Source-PE, Egress-PE non può inviare un join a Legacy-Source-PE. Tenere presente che Egress-PE crea solo alberi mLDP e segnala i clienti BGP. Tenere presente che il sistema Legacy-Source-PE crea solo alberi basati su PIM e segnala solo i clienti PIM.

Tuttavia, poiché l'interfaccia Egress-PE dispone di informazioni RPF che puntano all'interfaccia in ingresso Lmdt e il traffico multicast arriva ancora su tale MDT dall'RP-PE, il traffico multicast verrà inoltrato verso il destinatario e non avrà esito negativo in RPF. Il motivo è che l'RPF non esegue un controllo rigoroso dell'RPF per verificare se il traffico multicast arriva effettivamente dal router 10.1.100.3 adiacente all'RPF, il router Legacy-PE. Si noti che non esiste alcuna adiacenza PIM per 10.1.100.3 in PE1 su Lmdt, poiché Legacy-PE non può avere Lmdt perché esegue PIM solo come protocollo dell'albero principale (Profilo 0):

RP/0/RP1/CPU0:PE1#show pim vrf one neighbor

PIM neighbors in VRF one

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.100.1*                  Lmdtone               01:32:46 00:01:32 100 (DR) P

10.1.100.2                   Lmdtone               01:30:46 00:01:16 1     P

10.1.100.4                   Lmdtone               01:30:38 00:01:24 1     P

10.1.100.1*                  mdtone                 01:32:46 00:01:34 100 (DR) P

10.1.100.2                   mdtone                 01:32:45 00:01:29 1     P

10.1.100.3                   mdtone                 01:32:17 00:01:29 1     P

10.1.100.4                   mdtone                 01:32:43 00:01:20 1     P

10.2.1.1*                    GigabitEthernet0/0/0/9 01:32:46 00:01:18 100     B P E

10.2.1.8                     GigabitEthernet0/0/0/9 01:32:39 00:01:16 100 (DR)

Il motivo per cui PE1 sceglie Lmdt come interfaccia in ingresso è che si tratta delle informazioni ricevute dal comando di topologia RPF in PE1:

route-policy rpf-for-one

set core-tree mldp-default

end-policy

!

Se l'RPF è ancora accettabile in PE1, il traffico multicast può raggiungere il ricevitore dietro PE1. Tuttavia, il traffico non prende il percorso più breve da Legacy-PE a PE1 nel nucleo.

La soluzione

Per risolvere questo problema, è necessario configurare Egress-PE (PE1) in modo che segnali MDT e BGP basati su PIM anche come segnale di overlay. Questa configurazione è necessaria sul modulo Egress-PE in questo caso:

router pim

vrf one

address-family ipv4

rpf topology route-policy rpf-for-one

mdt c-multicast-routing bgp

migration route-policy PIM-to-BGP

announce-pim-join-tlv

!

rp-address 10.2.100.9 override

!

interface GigabitEthernet0/0/0/9

enable

!

!

!

!

route-policy rpf-for-one

if next-hop in (10.1.100.3/32) then

set core-tree pim-default

else

set core-tree mldp-default

endif

end-policy

!

route-policy PIM-to-BGP

if next-hop in (10.1.100.3/32) then

set c-multicast-routing pim

else

set c-multicast-routing bgp

endif

end-policy

!

multicast-routing

vrf one

address-family ipv4

mdt source Loopback0

rate-per-route

interface all enable

accounting per-prefix

bgp auto-discovery mldp

!

mdt default ipv4 232.1.1.1

mdt default mldp ipv4 10.1.100.7

!

!

!

Vedere la Figura 4. Tra Legacy-PE ed Egress-PE è ora disponibile un MDT basato su PIM.

Figura 4.

Il modulo Egress-PE invia messaggi di unione PIM attraverso l'MDT basato su PIM verso il Legacy-Source-PE per (S, G) dopo lo switchover SPT. L'interfaccia in ingresso sul modulo Egress-PE è ora in formato mdtone. L'RP-PE non è più un router di risposta per il traffico multicast.

RP/0/RP1/CPU0:PE1#show mrib vrf one route 225.1.1.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, MF - MPLS Encap, 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

(*,225.1.1.1) RPF nbr: 10.1.100.2 Flags: C RPF

Up: 00:09:59

Incoming Interface List

Lmdtone Flags: A LMI, Up: 00:09:59

Outgoing Interface List

GigabitEthernet0/0/0/9 Flags: F NS, Up: 00:09:59

(10.2.3.10,225.1.1.1) RPF nbr: 10.1.100.3 Flags: RPF

Up: 00:14:29

Incoming Interface List

mdtone Flags: A MI, Up: 00:14:29

Outgoing Interface List

GigabitEthernet0/0/0/9 Flags: F NS, Up: 00:14:29

In PE1 sono disponibili le seguenti informazioni PIM RPF per l'origine:

RP/0/RP1/CPU0:PE1#show pim vrf one rpf 10.2.3.10

Table: IPv4-Unicast-default

* 10.2.3.10/32 [200/0]

via mdtone with rpf neighbor 10.1.100.3

RT:1:1 ,Connector: 1:3:10.1.100.3, Nexthop: 10.1.100.3

Ciò significa che il traffico ora scorre direttamente da Legacy-Source-PE a Egress-PE nella rete principale attraverso l'MDT basato su PIM. Vedere la Figura 5.

Figura 5.

Conclusioni

Tutti i router PE non legacy, che sono router Receiver-PE o RP-PE, devono disporre della configurazione per la migrazione dei protocolli core-tree e la migrazione dei protocolli di segnalazione C.

In alternativa, per evitare lo switchover SPT, è possibile usare una soluzione alternativa. In questo caso, tuttavia, il routing del traffico multicast potrebbe non trovarsi sul percorso più breve nel nucleo della rete.