Multicast Draft-Rosen MVPN feature MDT
06.04 2020 | by massimilianoMulticast Draft-Rosen MVPN features MDT Draft Rosen conosciuto come Rosen-6 L3-Multicast opera con ASM (Any Source Multicast); le principali […]
https://www.ingegnerianetworking.com/wp-content/uploads/2020/04/mdt-only-b57.png
Multicast Draft-Rosen MVPN features MDT
Draft Rosen conosciuto come Rosen-6 L3-Multicast opera con ASM (Any Source Multicast); le principali implementazioni sono
Multicast Domain
Default MDT only
Default MDT e Data MDT
Draft Rosen-7 L3-Multicast, invece, opera con SSM (Source Specific Multicast) con utilizzo di SP (services provider) Tunnel, permettendo ai P router del backbone di non mantenere informazioni riguardo le specifiche PIM legate alla VPN.
Consiste in una VPN Multicast con PIM (Protocol Indipendent Multicast) configurato sia all’interno della VPN stessa che a livello di backbone del Services Provider (control plane);
Definisce per il trasporto dei dati il protocollo GRE oppure IP-in-IP (data plane);
Ad ogni VRF corrisponde un Multicast Domain (MD); un router PE le cui interfaccie sono associate alla VRF instances, appartiene al corrispondente Multicast Domain
Per ogni MD esiste una Default Multicast Distribution Tree, cioè un tunnel P2MP GRE tunnel attraverso il backbone del Services Provider, al quale sono connessi tutti i PE routers appartenenti al corrispondente MD; ciascun PE routers configurato con un default MDT group address multicast può essere sorgente di un default MDT
PIM è presente all’interno del backbone CORE con la funzione di ruotare questi tunnel-GRE (il tunnel destination è il multicast group)
Le caratteristiche principali di un MDT-only sono:
- – fllooding di mcast data verso tutti i PE VPN-member
- – è efficiente in caso di poche azioni di prunes e quando vi è un low-data-rate groups
- – con STP (SSM) è possibile gestire un valore di state pari al numero di gruppi (N) per il numero di PE router (M) appartenenti ad una specifica VPN
- – con Shared-Trees (ASM o Bidir) abbiamo solo un valore di state pari al solo numero di gruppi
Quando vi è una trasmissione di tipo VRF traffic, il PE incapsula il traffico come (S,G) state, dove:
-
- – G è il group address,
- – S è il source per il PE
- attraverso il joining via (S,G) il MDT (Distribution Tree) è parte del PE neighbors, ed è attivo per ricevere il traffico multicast incapsulato per quella VRF.
- Per supportare MVPN, i nodi PE routers hanno solo bisogno di supportare native multicast routing enable;
PIM sparse-mode è attivato in tutte le interfacce fisiche dove il multicast per una determinata MVPN deve transitare (e questo vale sia in global routing oppure all’interno delle VRF) e sulle loopback interface.
Quindi:
– PIM adjacencies between PEs to exchange mVPN routing information;
– unique multicast address per VPN;
– per-VPN PIM adjacencies between PEs and Ces;
– per-VPN MDT (GRE) tunnels between Pes;
– data MDT tunnels for optimization
Con MPLS/BGP MVPN (NG-MVPN) abbiamo:
– BGP peerings between PEs to exchange mVPN routing information;
– PIM messages are carried in BGP:
– BGP autodiscovery for inter-PE tunnels;
– MPLS P2MP inclusive tunnels between PE;
– selective tunnels for optimization.
DATA-MDT:
Anzichè avere un MDT per-VRF, si utilizzano multiple MDT
il MDT di default dinamicamente crea un nuovo MDT per un determinato VPN data groups
Il traffico di controllo e quello a low-rate resta nel MDT di default
Quando un traffico eccede i valori di threshold , questo traffico passa al MDT-Data
Utilizza il protocollo UDP per la segnalazione tra PE per stabilire e commutare dal default al MDT-Data
Gli svantaggi di MDT-Data possono essere cosi riassunti:
- – ogni gruppo definito come C-VPN può creare uno state mcast nella rete backbone core del SP
- I router di un Provider supportano un valore di state pari a M x N x G dove:
- M = numero di PE
- N = numero di VPN
- G = numero di gruppi per VPN (quando utilizzato SPT)
– ogni gruppo C-VPN può creare un nuovo MDT interface in un PE; questo può supportare un numero finito di logical-interface
– i PE di ricezione che non riescono ad unirsi ad un MDT-Data possono andare in blackholed in quanto nessun meccanismo di feedback informa i PE sorgenti che tutti i PE hanno commutato nel MDT-Data con successo
Esempio di configurazione IOS:
ip multicast-routing
!
ip pim ssm default
!
interface Loopback0
ip pim sparse-mode
!
interface X
ip pim sparse-mode
!
ip multicast-routing vrf VPN
!
vrf definition VPN
address-family ipv4
mdt default x.x.x.x
mdt data x.x.x.x y.y.y.y
exit-address-family
!
router bgp X
address-family ipv4 mdt
neighbor x.x.x.x activate
exit-address-family
Esempio di configurazione IOS-XR:
multicast-routing
address-family ipv4
interface Loopback0
enable
!
mdt source Loopback0
!
vrf VPN
address-family ipv4
mdt default ipv4 239.x.y.z
mdt data 239.x.a.0/24 threshold < value >
interface all enable
!
router bgp X
address-family ipv4 mdt
!
neighbor x.x.x.x
address-family ipv4 mdt
!
router pim
address-family ipv4
log neighbor changes
interface Loopback0
enable
!
interface TenGigE0/0/0/0
enable
!
interface TenGigE0/0/0/1
enable
!
NOTE
“MDT source” è richiesto in IOS-XR (può esssre configurato sotto la VRF se questo è specifico per-VRF).
Sparse mode deve essere attivo in tutte le interfacce fisiche dove il traffico multicast passa attraverso (global or VRF) e gli indirizzi di loopback usate per BGP VPNv4 peerings.
La configurazione RP lato CE deve trovare accordo con il RP VRF del PE (in caso di configurazione manuale (static RP) nel CE, poi questo deve essere fatto anche nel PE all’interno della VRF.