Inhoud

Inleiding

Wat is standaard MDT?

Wat is MDT?

BGP

Multicastadressering voor SSM-groep

Aanbevelingen

Overlay-out signalering

Topologie

Multicast voor VPN-routing en -doorsturen en multicastdomeinen

Configuratie-taken

Verifiëren

Task 1: Controleer de fysieke connectiviteit.

Task 2: Controleer BGP-adresfamilie VPNv4-unicast.

Task 3: Controleer de BGP-adresomzetting in VPN-unicast.

Taken 4: Controleer of het multicast verkeer is voltooid.

Hoe tunnelinterfaces worden gecreëerd?

Creatie van MDT-tunnels

PIM-buurt

Gerelateerde informatie

Inleiding

Dit document beschrijft de Default Multicast Distribution Tree (MDT) GRE (BGP AD - PIM C) voor Multicast via VPN (mVPN). Het gebruikt een voorbeeld en de implementatie in Cisco IOS om het gedrag te illustreren.

Wat is standaard MDT?

Het wordt gebruikt om multicast in één VRF op alle PE te verbinden. Standaard wordt alle PE-routers aangesloten. Standaard vervoert het alle verkeer. Het PIM-controleverkeer en het gegevensverkeer. Voorbeeld: (*,G) Verkeer en het (S,G) verkeer. De standaardinstelling is de must. Deze standaard MDT sluit alle PE router aan om aan te sluiten. Dit staat voor meerdere punten. Iedereen kan sturen en iedereen kan van de boom ontvangen.

Wat is MDT?

Het is optioneel en wordt op aanvraag gecreëerd. Het vervoert specifiek (S,G) verkeer. In de meest recente IOS release hebt u drempelwaarden ingesteld als 0 en oneindig. Wanneer een eerste pakket VRF raakt, geïnitialiseerd de Data MDT, en als oneindig, dan wordt de Data MDT nooit gecreëerd, en het verkeer beweegt vooruit in de standaard MDT. De Data MDT is altijd de ontvangende boom, ze sturen nooit verkeer. Data MDT is alleen voor het (S,G) verkeer.

De drempel waarop de MDT wordt gecreëerd kan op een per-router of een per-VRF-basis worden geconfigureerd. Wanneer de multicast transmissie de gedefinieerde drempel overschrijdt, creëert de verzendende PE-router de gegevens MDT en verstuurt een User Datagram Protocol (UDP)-bericht, dat informatie over de gegevensMDT naar alle routers op de standaard MDT bevat. De statistieken om te bepalen of een multicaststroom de MDT-drempel heeft overschreden worden eens per seconde onderzocht.

Opmerking: Nadat een PE-router het UDP-bericht verstuurt, wacht hij nog 3 seconden voordat hij overschakelt; 13 seconden is de slechtst denkbare overschakelingstijd en 3 seconden is de beste case.

Data MDTs wordt slechts gecreëerd voor (S, G) multicast routeingangen binnen de VRF multicast routing tabel. Ze worden niet gemaakt voor (*, G)-posten, ongeacht de waarde van de individuele brongegevens

- Hiermee kan PE zich rechtstreeks bij een bronboom aansluiten voor een MDT.

- Het netwerk heeft geen rendezvous points nodig.

- RP's zijn een mogelijk mislukkingspunt en extra overheadkosten.

- Maar ze maken gedeelde en BiDir-bomen (minder sterk) mogelijk.

- Verminder de verzendvertraging.

- Vermijd beheersoverhead om group/RP-mapping en redundante RP’s voor betrouwbaarheid te beheren.

- Overdracht is meer staatsschuld nodig.

- (S, G) voor elk mVPN in een PE.

Als er 5 PE's zijn met elk mVRF RED, dan zijn er 5 x (S, G) ingangen.

1. Configureer de opdracht van het ip pim ssm-bereik op zowel P- als PE-routers (vermijdt dat er onnodige (*, G) items worden gecreëerd).

2. SSM aanbevolen voor Data-MDT’s.

3. Gebruik BiDir indien mogelijk voor Default-MDT (ondersteuning van BiDir is platformspecifiek).

Als SSM niet wordt gebruikt voor het instellen van MDT's:

- Elke VRF moet worden geconfigureerd met een unieke set multicast P-adressen; twee VRF's in dezelfde MD kunnen niet met dezelfde set adressen worden geconfigureerd.

- Veel meer multicast P-adressen zijn nodig.

- Compilatie van activiteiten en beheer.

- Het SSM vereist dat de PE zich aansluit bij een (S, G) niet (*, G).

G is bekend omdat het is geconfigureerd, maar PE weet niet direct de waarde van S (S, G) van standaard MDT die door MP-BGP wordt gepropageerd.

Het voordeel van SSM is dat het niet afhankelijk is van het gebruik van een RP om de bron PE-router voor een bepaalde MDT-groep af te leiden.

Het IP-adres van de bron-PE en de standaard-MDT-groep wordt verzonden via Border Gateway Protocol (BGP)

Er zijn twee manieren waarop BGP deze informatie kan verzenden:

- Uitgebreide gemeenschap

- Cisco eigen oplossing

- Niet-transitieve eigenschap (niet geschikt voor inter-AS)

- BGP-adresfamilie MDT SAFI (66)

- ontwerp-nalawade-idr-mdt-safi

Opmerking: GRE VPN’s werden ondersteund voordat MDT SAFI werd gebruikt; feitelijk, zelfs nog vóór MDT SAFI met behulp van RD type 2. Technisch gezien, voor Profile 3, mag MDT SAFI niet worden geconfigureerd, maar beide SAFI's worden tegelijkertijd ondersteund voor migratie.

BGP

- Bron PE en MDT Default Group gecodeerd in NLRI van MP_REACH_NLRI.

- RD is hetzelfde als de MVRF waarvoor de MDT Default Group is ingesteld.

- RD type 0 of 1

PMSI-eigenschap heeft het bronadres en het groepsadres. Om de MT-tunnel te vormen.

Multicastadressering voor SSM-groep

232.0.0.0 - 232.255.255.255 is gereserveerd voor mondiale bronspecifieke multicasttoepassingen.

239.0.0.0 - 239.255.255.255 is het administratief opgenomen IPv4 multicast adresbereik

Plaatselijk bereik IPv4-organisatie - 239.192.0.0/14

De lokale reikwijdte is de minimale omslagruimte en is dus niet meer deelbaar.

De marges 239.0.0.0/10, 239.64.0.0/10 en 239.128.0.0/10 zijn niet toegewezen en beschikbaar voor expansie van deze ruimte.

Deze marges moeten niet zijn toegewezen totdat de ruimte 239.192.0.0/14 niet langer voldoende is.

Aanbevelingen

- Standaard-MDT dient adressen te tekenen van de 239/8 ruimte beginnend met het bereik dat gedefinieerd is met de Organisationele lokale scope van 239.192.0.0/14

- Data-MDT moet adressen van het organisationele lokale gebied tekenen.

- Het is ook mogelijk om het wereldwijde SSM - bereik 232.0.0.0 - 232.255.255.255 te gebruiken

- Aangezien SSM altijd een unieke (S, G) staat gebruikt, is er geen mogelijkheid van overlapping, aangezien de multicast-stream van het SSM door verschillende bronnen (met verschillende adressen) zal worden geïnitieerd, of het nu binnen het providernetwerk of het grotere internet is.

- Gebruik de zelfde Data-MDT pool voor elk mVRF binnen een bepaald multicast domein (waar de Standaard-MDT normaal is).

Bijvoorbeeld, zouden alle VRFs die Standaard-MDT 239.192.10.1 gebruiken het zelfde getal MDT 239.232.1.0/24 bereik moeten gebruiken

Overlay-out signalering

Het overlay signaleren van Rosen GRE wordt in de afbeelding weergegeven.

Topologie

De topologie van Rosen GRE wordt in de afbeelding getoond.

Multicast voor VPN-routing en -doorsturen en multicastdomeinen

MVPN introduceert multicast routing informatie naar de VPN-routing en -verzendtabel. Wanneer een PE-router (Provider Edge) multicast gegevens of controlepakketten van een CE-router (Customer Edge) ontvangt, wordt het verzenden uitgevoerd volgens de informatie in de MVRF-instantie (Multicast VPN Routing and Forwarding Instance). MVPN gebruikt geen label switching.

Een reeks MVRFs die multicast verkeer naar elkaar kan verzenden vormt een multicast domein. Bijvoorbeeld, het multicast domein voor een klant die bepaalde types van multicast verkeer naar alle mondiale werknemers wilde verzenden zou uit alle routers bestaan die met die onderneming verbonden zijn.

Configuratie-taken

1. Multicast voor routing op alle knooppunten inschakelen.

2. Laat Protocol Independent Multicast (PIM) in alle interface los.

3. Met bestaande VRF moet u een standaardMDT configureren.

4. Configureer de VRF op de interface-Ethernet0/x.

5. Schakel multicast routing op VRF in.

6. Configuratie van PIM SSM Standaard in alle knooppunten binnen de kern.

7. Configuratie BGP adresfamilie VPN.

8. Configureer BSR in CE Node.

9. Vooringesteld:

VRF SSM-BGP

mBGP: Address family VPNv4

VRF Routing Protocol

Verifiëren

Task 1: Controleer de fysieke connectiviteit.

Controleer of alle aangesloten interface UP is.

Task 2: Controleer BGP-adresfamilie VPNv4-unicast.

- Controleer dat BGP in alle routers is ingeschakeld voor AF VPNv4 unicast en BGP-buren zijn UP.

- Controleer dat de BGP VPNv4 unicast-tabel alle prefixes van de klant heeft.

Task 3: Controleer de BGP-adresomzetting in VPN-unicast.

- Controleer dat BGP in alle routers is ingeschakeld voor AF IPv4 VPN en BGP-buren zijn UP.

- Controleer dat alle PE elkaar ontdekt, met Type 1 Route.

Taken 4: Controleer of het multicast verkeer is voltooid.

- Controleer de PIM buurt.

- Controleer dat de multicast toestand in het VRF is gecreëerd.

- Controleer de vermelding van MRIB op PE1, PE2 en PE3.

- Controleer dat (S, G) mFIB-ingang, pakketverhoging bij het verzenden van software.

- Controleer ICMP-pakketten die bereik van CE naar CE krijgen.

Hoe tunnelinterfaces worden gecreëerd?

Creatie van MDT-tunnels

Zodra we mdt standaard 239.232.0.0 configureren

Tunnel 0 kwam naar boven en toegewezen zijn Loopback 0-adres als bron.

%LINEPROTO-5-UPDOWN: Het protocol van de lijn op Interface Tunnel0, veranderde staat in omhoog

PIM(1): Check DR after interface: Tunnel0 came up!

PIM(1): Changing DR for Tunnel0, from 0.0.0.0 to 1.1.1.1 (this system)

%PIM-5-DRCHG: VRF SSM-BGP: DR change from neighbor 0.0.0.0 to 1.1.1.1 on interface Tunnel0

Deze afbeelding toont de vorming van MDT Tunnel.

PE1#sh int tunnel 0

Tunnel0 is up, line protocol is up

Hardware is Tunnel

Interface is unnumbered. Using address of Loopback0 (1.1.1.1)

MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation TUNNEL, loopback not set

Keepalive not set

Tunnel source 1.1.1.1 (Loopback0)

Tunnel Subblocks:

src-track:

Tunnel0 source tracking subblock associated with Loopback0

Set of tunnels with source Loopback0, 1 member (includes iterators), on interface <OK>

Tunnel protocol/transport multi-GRE/IP

Key disabled, sequencing disabled

Checksumming of packets disabled

Zodra BGP MVPN omhoog komt, ontdekt alle PE elkaar via Type 1 route. Multicast voor tunnels gevormd. BGP heeft het PE-adres van groep en bron in de PMSI-eigenschap.

Deze afbeelding toont Exchange van type 1-route.

Deze afbeelding toont PCAP-1.

PE1#sh ip mroute

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,

(3.3.3.3, 239.232.0.0), 00:01:41/00:01:18, flags: sTIZ

Incoming interface: Ethernet0/1, RPF nbr 10.0.1.2

Outgoing interface list:

MVRF SSM-BGP, Forward/Sparse, 00:01:41/00:01:18

(2.2.2.2, 239.232.0.0), 00:01:41/00:01:18, flags: sTIZ

Incoming interface: Ethernet0/1, RPF nbr 10.0.1.2

Outgoing interface list:

MVRF SSM-BGP, Forward/Sparse, 00:01:41/00:01:18

“Z” Multicast Tunnel formed after BGP mVPN comes up, as it advertises the Source PE and Group Address in PMSI attribute.

PIM-buurt

PE1#sh ip pim vrf SSM-BGP neighbor

PIM Neighbor Table

Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,

P - Proxy Capable, S - State Refresh Capable, G - GenID Capable

Neighbor          Interface                Uptime/Expires    Ver   DR

Address                                                            Prio/Mode

10.1.0.2          Ethernet0/2           00:58:18/00:01:31 v2  1 / DR S P G

3.3.3.3           Tunnel0                00:27:44/00:01:32 v2    1 / S P G

2.2.2.2           Tunnel0                 00:27:44/00:01:34 v2    1 / S P G

Zodra u RP-informatie configureren:

%LINEPROTO-5-UPDOWN: Het protocol van de lijn op Interface Tunnel1, veranderde staat in omhoog

De bootstrap berichtenuitwisseling via MDT-tunnel

PIM(1): Received v2 Bootstrap on Tunnel0 from 2.2.2.2

PIM(1): pim_add_prm:: 224.0.0.0/240.0.0.0, rp=22.22.22.22, repl = 0, ver =2, is_neg =0, bidir = 0, crp = 0

PIM(1): Update

prm_rp->bidir_mode = 0 vs bidir = 0 (224.0.0.0/4, RP:22.22.22.22), PIMv2

*May 18 10:28:42.764: PIM(1): Received RP-Reachable on Tunnel0 from 22.22.22.22

Deze afbeelding toont de berichtenuitwisseling via MDT-tunnel.

PE2#sh int tunnel 1

Tunnel1 is up, line protocol is up

Hardware is Tunnel

Description: Pim Register Tunnel (Encap) for RP 22.22.22.22 on VRF SSM-BGP

Interface is unnumbered. Using address of Ethernet0/2 (10.2.0.1)

MTU 17912 bytes, BW 100 Kbit/sec, DLY 50000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation TUNNEL, loopback not set

Keepalive not set

Tunnel source 10.2.0.1 (Ethernet0/2), destination 22.22.22.22

Tunnel Subblocks:

src-track:

Tunnel1 source tracking subblock associated with Ethernet0/2

Set of tunnels with source Ethernet0/2, 1 member (includes iterators), on interface <OK>

Tunnel protocol/transport PIM/IPv4

Tunnel TOS/Traffic Class 0xC0,  Tunnel TTL 255

Tunnel transport MTU 1472 bytes

Tunnel is transmit only

Twee tunnels vormden PIM-registratietunnel en MDT Tunnel.

- Tunnel 0 wordt gebruikt om de PIM Samenvoegen en Laag bandbreedte multicast verkeer te verzenden.

- Tunnel 1 wordt gebruikt om het ingesloten PIM-bericht te verzenden.

Te controleren opdracht:

**MDT BGP:

PE1#sh ip pim vrf m-SSM mdt bgp

** gegevens FHR verzenden:

PE1#sh ip pim vrf m-SSM mdt

Gerelateerde informatie

- https://tools.ietf.org/html/rfc4760

- https://tools.ietf.org/html/rfc5110

- https://tools.ietf.org/html/rfc6513

- Technische ondersteuning en documentatie – Cisco Systems