Multicast Draft-Rosen MVPN feature MDT

06.04 2020 | by massimiliano

Multicast 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)

mdt only

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

mdt data traffic

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.