Streng RPF-controle op mVPN

Downloadopties

  • PDF     (211.3 KB)
    Met Adobe Reader op diverse apparaten bekijken
  • ePub     (125.1 KB)
    Bekijken in diverse apps op iPhone, iPad, Android, Sony Reader of Windows Phone
  • Mobi (Kindle)     (119.7 KB)
    Op Kindle-apparaat of via Kindle-app op meerdere apparaten bekijken
Bijgewerkt:17 december 2014
Document-id:118677

Inclusief taalgebruik

De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.

Over deze vertaling

Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.

Inleiding

Dit document beschrijft de optie Streng Reverse Path Forwarding (RPF) voor Multicast over VPN (mVPN). Dit document gebruikt een voorbeeld en de implementatie in Cisco IOS® om het gedrag te illustreren.

Achtergrondinformatie

RPF impliceert dat de inkomende interface naar de bron wordt gecontroleerd. Hoewel de interface wordt gecontroleerd om te bepalen dat het juiste is in de richting van de bron, wordt niet gecontroleerd om te bepalen dat het de juiste RPF-buur op die interface is. Op een interface met meerdere aansluitingen kan er meer dan één buur zijn waarop u PDF-bestanden kunt uitvoeren. Het resultaat zou kunnen zijn dat de router tweemaal de zelfde multicast stroom op die interface ontvangt en beide door:sturen.

In netwerken waar Protocol Independent Multicast (PIM) in de multi-access interface draait, is dit geen probleem, omdat het duplicaat multicast stream het assert mechanisme laat lopen en één multicast stream niet meer wordt ontvangen. In sommige gevallen werkt PIM niet in de Multicast Distribution Tree (MDT), een multi-access interface. In die gevallen is Border Gateway Protocol (BGP) het overlay signaleringsprotocol.

In de profielen met gepartitioneerde MDT, zelfs als PIM als overlay protocol loopt, kan het onmogelijk zijn om te hebben om te bevestigen. De reden voor dit is dat één Ingrress Provider Edge (PE) zich niet aansluit bij de gepartitioneerde MDT van een andere Ingoers-PE in de scenario's waar twee of meer Ingoers-PE-routers zijn. Elke Ingeress PE-router kan de multicast-stream naar zijn gedistribueerde MDT doorsturen zonder dat de andere Ingress PE-router het multicast-verkeer bekijkt. Het feit dat twee verschillende IP-routers elk zich aansluiten bij een MDT in de richting van een verschillende IP-router voor dezelfde multicast-stream is een geldig scenario: het wordt Anycast Bron genoemd. Dit maakt het mogelijk dat verschillende ontvangers zich bij dezelfde multicast stream aansluiten maar via een ander pad in de MPLS-kern (Multiprotocol Label Switching). Zie Afbeelding 1 voor een voorbeeld van een anycast-bron.

Figuur 1

Er zijn twee Ingress PE-routers: PE1 en PE2. Er zijn twee Groot-PE routers: PE3 en PE4. Elke PE-router van het Groot heeft een verschillende PE-router van Ingress als zijn RPF-buur. PE3 heeft PE1 als RPF-buur. PE4 heeft PE2 als RPF-buur. De Groot PE routers kiezen hun dichtstbijzijnde router van Ingress PE als hun RPF-buurman.

De stream (S1,G) gaat van S1 naar ontvanger 1 via het bovenste pad en van S1 naar ontvanger 2 via het onderste pad. Er is geen kruispunt van de twee stromen over de twee paden (elk pad in de MPLS-kern is een andere gedistribueerde MDT).

Als MDT een standaard MDT was - zoals in de standaard MDT-profielen - dan zou dit niet werken omdat de twee multicast-stromen op dezelfde standaard MDT zouden staan en het activeringsmechanisme zou worden uitgevoerd. Als MDT in de standaardprofielen van MDT een Data MDT is, dan voegen alle Ingreress PE routers zich bij de Data MDT van de andere IP-routers en zien ze als zodanig het multicast verkeer van elkaar en loopt het activeringsmechanisme opnieuw. Als het overlay protocol BGP is, dan is er Upstream Multicast Hop (UMH) selectie en slechts één Ingoers PE router wordt geselecteerd als expediteur, maar dit is per MDT.

Anycast-bron is een van de grote voordelen van het uitvoeren van Gedeeltelijk MDT.

Probleem

De regelmatige controle RPF bevestigt dat de pakketten in de router van de correcte interface RPF aankomen. Er is geen controle om te bevestigen dat de pakketten van de juiste RPF buur op die interface worden ontvangen.

Zie Afbeelding 2. Het toont een probleem waar het dubbele verkeer permanent in een scenario met Gedistribueerde MDT wordt doorgestuurd. Hieruit blijkt dat de reguliere VPF-controle in het geval van een partitionering MDT niet voldoende is om dubbel verkeer te voorkomen.

Figuur 2

Er zijn twee ontvangers. De eerste ontvanger is ingesteld om verkeer te ontvangen voor (S1,G) en (S2,G). De tweede ontvanger is ingesteld om alleen verkeer te ontvangen voor S2,G. Er is partitionated MDT, en BGP is het overlay signaleringsprotocol. Merk op dat Bron S1 bereikbaar is via zowel PE1 als PE2. Het kernboomprotocol is Multipoint Label Distribution Protocol (mLDP).

Elke PE-router adverteert een Type 1 BGP IPv4 mVPN-route, die aangeeft dat het een kandidaat is om de wortel van een gedistribueerde MDT te zijn.

PE3#show bgp ipv4 mvpn vrf one              
BGP table version is 257, local router ID is 10.100.1.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
             r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
             x best-external, a additional-pah, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
 
     Network         Next Hop           Metric LocPrf Weight Path
Route Distinguisher: 1:3 (default for vrf one)
*>i [1][1:3][10.100.1.1]/12
                      10.100.1.1               0   100     0 ?
*>i [1][1:3][10.100.1.2]/12
                       10.100.1.2               0   100     0 ?
*> [1][1:3][10.100.1.3]/12
                       0.0.0.0                           32768 ?
*>i [1][1:3][10.100.1.4]/12
                       10.100.1.4               0   100     0 ?

PE3 vindt PE1 als RPF-buur voor S1 na raadpleging voor de éénastroute voor S1.

PE3#show bgp vpnv4 unicast vrf one 10.100.1.6/32
BGP routing table entry for 1:3:10.100.1.6/32, version 16
Paths: (2 available, best #2, table one)
Advertised to update-groups:
     5        
Refresh Epoch 2
65001, imported path from 1:2:10.100.1.6/32 (global)
   10.100.1.2 (metric 21) (via default) from 10.100.1.5 (10.100.1.5)
     Origin incomplete, metric 0, localpref 100, valid, internal
     Extended Community: RT:1:1 MVPN AS:1:0.0.0.0 MVPN VRF:10.100.1.2:1
     Originator: 10.100.1.2, Cluster list: 10.100.1.5
     mpls labels in/out nolabel/20
     rx pathid: 0, tx pathid: 0
Refresh Epoch 2
65001, imported path from 1:1:10.100.1.6/32 (global)
   10.100.1.1 (metric 11) (via default) from 10.100.1.5 (10.100.1.5)
     Origin incomplete, metric 0, localpref 100, valid, internal, best
     Extended Community: RT:1:1 MVPN AS:1:0.0.0.0 MVPN VRF:10.100.1.1:1
     Originator: 10.100.1.1, Cluster list: 10.100.1.5
     mpls labels in/out nolabel/29
     rx pathid: 0, tx pathid: 0x0
PE3#show ip rpf vrf one 10.100.1.6
RPF information for ? (10.100.1.6)
  RPF interface: Lspvif0
  RPF neighbor: ? (10.100.1.1)
  RPF route/mask: 10.100.1.6/32
  RPF type: unicast (bgp 1)
  Doing distance-preferred lookups across tables
  RPF topology: ipv4 multicast base, originated from ipv4 unicast base

PE3 selecteert PE1 als RPF buurman voor (S1,G) en sluit zich aan bij de Gedeelte MDT met PE1 als wortel. PE3 selecteert PE2 als RPF buurman voor (S2,G) en sluit zich aan bij de Gedeelte MDT met PE2 als wortel.

PE3#show bgp vpnv4 unicast vrf one 10.100.1.7/32
BGP routing table entry for 1:3:10.100.1.7/32, version 18
Paths: (1 available, best #1, table one)
Advertised to update-groups:
     6        
Refresh Epoch 2
65002, imported path from 1:2:10.100.1.7/32 (global)
     10.100.1.2 (metric 21) (via default) from 10.100.1.5 (10.100.1.5)
     Origin incomplete, metric 0, localpref 100, valid, internal, best
     Extended Community: RT:1:1 MVPN AS:1:0.0.0.0 MVPN VRF:10.100.1.2:1
     Originator: 10.100.1.2, Cluster list: 10.100.1.5
     mpls labels in/out nolabel/29
     rx pathid: 0, tx pathid: 0x0
PE3#show ip rpf vrf one 10.100.1.7
RPF information for ? (10.100.1.7)
  RPF interface: Lspvif0
  RPF neighbor: ? (10.100.1.2)
  RPF route/mask: 10.100.1.7/32
  RPF type: unicast (bgp 1)
  Doing distance-preferred lookups across tables
  RPF topology: ipv4 multicast base, originated from ipv4 unicast base

PE4 selecteert PE2 als RPF-buur voor (S1,G) en sluit zich aan bij de Gedeelte MDT met PE1 als wortel.

PE4#show bgp vpnv4 unicast vrf one 10.100.1.6/32
BGP routing table entry for 1:4:10.100.1.6/32, version 138
Paths: (2 available, best #1, table one)
Advertised to update-groups:
     2        
Refresh Epoch 2
65001, imported path from 1:2:10.100.1.6/32 (global)
     10.100.1.2 (metric 11) (via default) from 10.100.1.5 (10.100.1.5)
     Origin incomplete, metric 0, localpref 100, valid, internal, best
     Extended Community: RT:1:1 MVPN AS:1:0.0.0.0 MVPN VRF:10.100.1.2:1
     Originator: 10.100.1.2, Cluster list: 10.100.1.5
     mpls labels in/out nolabel/20
     rx pathid: 0, tx pathid: 0x0
Refresh Epoch 2
65001, imported path from 1:1:10.100.1.6/32 (global)
   10.100.1.1 (metric 21) (via default) from 10.100.1.5 (10.100.1.5)
     Origin incomplete, metric 0, localpref 100, valid, internal
     Extended Community: RT:1:1 MVPN AS:1:0.0.0.0 MVPN VRF:10.100.1.1:1
     Originator: 10.100.1.1, Cluster list: 10.100.1.5
     mpls labels in/out nolabel/29
     rx pathid: 0, tx pathid: 0
PE4#show ip rpf vrf one 10.100.1.6
RPF information for ? (10.100.1.6)
  RPF interface: Lspvif0
  RPF neighbor: ? (10.100.1.2)
  RPF route/mask: 10.100.1.6/32
  RPF type: unicast (bgp 1)
  Doing distance-preferred lookups across tables
  RPF topology: ipv4 multicast base, originated from ipv4 unicast base

Merk op dat de RPF-interface Lspvif0 is voor zowel S1 (10.100.1.6) als S2 (10.100.1.7).

PE3 sluit zich aan bij de gepartitioneerde MDT van PE2 voor (S2,G), en PE4 maakt deel uit van de gepartitioneerde MDT van PE2 voor (S1,G). PE1 sluit zich aan bij de gepartitioneerde MDT van PE1 voor (S1,G). U kunt dit zien op de type 7 BGP IPv4 mVPN-routes die op PE1 en PE2 zijn ontvangen.

PE1#show bgp ipv4 mvpn vrf one
BGP table version is 302, local router ID is 10.100.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
             r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
             x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
 
     Network         Next Hop           Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf one)
*>i [7][1:1][1][10.100.1.6/32][232.1.1.1/32]/22
                       10.100.1.3               0   100     0 ?
PE2#show bgp ipv4 mvpn vrf one
BGP table version is 329, local router ID is 10.100.1.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
             r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
             x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
 
   Network         Next Hop           Metric LocPrf Weight Path
Route Distinguisher: 1:2 (default for vrf one)
*>i [7][1:2][1][10.100.1.6/32][232.1.1.1/32]/22
                       10.100.1.4               0   100     0 ?
*>i [7][1:2][1][10.100.1.7/32][232.1.1.1/32]/22
                       10.100.1.3               0   100     0 ?

De multicast-vermeldingen op PE3 en PE4:

PE3#show ip mroute vrf one 232.1.1.1
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.100.1.7, 232.1.1.1), 21:18:24/00:02:46, flags: sTg
 Incoming interface: Lspvif0, RPF nbr 10.100.1.2
 Outgoing interface list:
   Ethernet0/0, Forward/Sparse, 00:11:48/00:02:46

(10.100.1.6, 232.1.1.1), 21:18:27/00:03:17, flags: sTg
 Incoming interface: Lspvif0, RPF nbr 10.100.1.1
 Outgoing interface list:
   Ethernet0/0, Forward/Sparse, 00:11:48/00:03:17
PE4#show ip mroute vrf one 232.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
 
(10.100.1.6, 232.1.1.1), 20:50:13/00:02:37, flags: sTg
 Incoming interface: Lspvif0, RPF nbr 10.100.1.2
 Outgoing interface list:
   Ethernet0/0, Forward/Sparse, 20:50:13/00:02:37

Dit toont aan dat PE3 zich aansluit bij de Point-to-Multipoint (P2MP)-boom, geworteld in PE1 en ook de boom geworteld in PE2:

PE3#show mpls mldp database
* Indicates MLDP recursive forwarding is enabled
 
LSM ID : A   Type: P2MP   Uptime : 00:18:40
 FEC Root           : 10.100.1.1 
 Opaque decoded     : [gid 65536 (0x00010000)]
 Opaque length     : 4 bytes
 Opaque value       : 01 0004 00010000
 Upstream client(s) :
   10.100.1.1:0   [Active]
     Expires       : Never         Path Set ID : A
     Out Label (U) : None         Interface   : Ethernet5/0*
     Local Label (D): 29           Next Hop     : 10.1.5.1
 Replication client(s):
   MDT (VRF one)
     Uptime         : 00:18:40     Path Set ID : None
     Interface     : Lspvif0      
 
LSM ID : B   Type: P2MP   Uptime : 00:18:40
 FEC Root           : 10.100.1.2 
 Opaque decoded     : [gid 65536 (0x00010000)]
 Opaque length     : 4 bytes
 Opaque value       : 01 0004 00010000
 Upstream client(s) :
   10.100.1.5:0  [Active]
     Expires       : Never         Path Set ID : B
     Out Label (U) : None         Interface   : Ethernet6/0*
     Local Label (D): 30           Next Hop     : 10.1.3.5
 Replication client(s):
   MDT (VRF one)
     Uptime       : 00:18:40     Path Set ID : None
     Interface     : Lspvif0      

Dit laat zien dat PE4 zich aansluit bij de P2MP-boom geworteld in PE2:

PE4#show mpls mldp database      
* Indicates MLDP recursive forwarding is enabled
 
LSM ID : 3   Type: P2MP   Uptime : 21:17:06
 FEC Root           : 10.100.1.2 
 Opaque decoded     : [gid 65536 (0x00010000)]

 Opaque value       : 01 0004 00010000
 Upstream client(s) :
   10.100.1.2:0   [Active]
     Expires       : Never         Path Set ID : 3
     Out Label (U) : None         Interface   : Ethernet5/0*
     Local Label (D): 29           Next Hop     : 10.1.6.2
 Replication client(s):
   MDT (VRF one)
     Uptime         : 21:17:06     Path Set ID : None
     Interface     : Lspvif0      

S1 en S2 stream voor groep 232.1.1.1 met 10 pps. U kunt de stromen zien op PE3 en PE4. Maar op PE3 zie je het percentage voor (S1,G) 20 pps.

PE3#show ip mroute vrf one 232.1.1.1 count
Use "show ip mfib count" to get better response time for a large number of mroutes.
 
IP Multicast Statistics
3 routes using 1692 bytes of memory
2 groups, 1.00 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
 
Group: 232.1.1.1, Source count: 2, Packets forwarded: 1399687, Packets received:
2071455
  Source: 10.100.1.7/32, Forwarding: 691517/10/28/2, Other: 691517/0/0
  Source: 10.100.1.6/32, Forwarding: 708170/20/28/4, Other: 1379938/671768/0
PE4#show ip mroute vrf one 232.1.1.1 count
Use "show ip mfib count" to get better response time for a large number of mroutes.
 
IP Multicast Statistics
2 routes using 1246 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
 
Group: 232.1.1.1, Source count: 1, Packets forwarded: 688820, Packets received:
688820
  Source: 10.100.1.6/32, Forwarding: 688820/10/28/2, Other: 688820/0/0
PE3#show interfaces ethernet0/0 | include rate
 Queueing strategy: fifo 
  30 second input rate 0 bits/sec, 0 packets/sec
  30 second output rate 9000 bits/sec, 30 packets/sec

Er is een dubbele stream. Deze verdubbeling is het gevolg van de aanwezigheid van stroom (S1,G) op de gesplitste MDT van PE1 en op de gesplitste MDT van PE2. Deze tweede gesplitste MDT van PE2 werd samengevoegd door PE3 om de stroom te verkrijgen (S2,G). Maar omdat PE4 zich bij de gepartitioneerde MDT van PE2 heeft aangesloten om (S1,G) te krijgen, is (S1,G) ook aanwezig op de gepartitioneerde MDT van PE2. Daarom ontvangt PE3 de stroom (S1,G) van beide gepartitioneerde MDT's die het heeft aangesloten.

PE3 kan geen onderscheid maken tussen de pakketten voor (S1,G) het ontvangt van PE1 en PE2. Beide stromen worden ontvangen op de juiste RPF-interface: Lspvif0.

PE3#show ip multicast vrf one mpls vif
 
Interface   Next-hop            Application     Ref-Count   Table / VRF name   Flags
 Lspvif0     0.0.0.0             MDT               N/A       1   (vrf one) 0x1

De pakketten kunnen op verschillende inkomende fysieke interfaces op PE3 of op dezelfde interface aankomen. In elk geval komen de pakketten van de verschillende stromen voor (S1,G) wel aan met een ander MPLS-label op PE3:

PE3#show mpls forwarding-table vrf one
Local     Outgoing   Prefix           Bytes Label   Outgoing   Next Hop  
Label     Label     or Tunnel Id     Switched     interface            
29   [T] No Label   [gid 65536 (0x00010000)][V]   \
                                       768684       aggregate/one
30   [T] No Label   [gid 65536 (0x00010000)][V]   \
                                       1535940       aggregate/one
 
[T]     Forwarding through a LSP tunnel.
       View additional labelling info with the 'detail' option

Oplossing

De oplossing is een strenger RPF. Met strikt RPF, controleert de router van welke buur de pakketten op de interface RPF worden ontvangen. Zonder Streng RPF, is de enige controle om te bepalen of de inkomende interface de interface van RPF is, maar niet als de pakketten van de juiste RPF buur op die interface worden ontvangen.

Opmerkingen voor Cisco IOS

Hier zijn een paar belangrijke opmerkingen over PDF-bestanden met Cisco IOS.

  • Wanneer u van of naar de strikte RPF-modus verandert, moet u deze configureren voordat u de gesplitste MDT configureren of BGP verwijderen. Als u slechts het strikte RPF bevel vormt, zal het geen andere Lspvif interface onmiddellijk creëren.

  • Streng RPF wordt niet standaard ingeschakeld in Cisco IOS.

  • Deze functie wordt niet ondersteund om de opdracht Streng-rpf te hebben met standaard MDT-profielen.

Configuratie

U kunt Streng RPF op PE3 voor het Virtuele Routing en Forwarding (VRF) configureren.

vrf definition one
 rd 1:3
 !
 address-family ipv4
  mdt auto-discovery mldp
  mdt strict-rpf interface
  mdt partitioned mldp p2mp
  mdt overlay use-bgp
  route-target export 1:1
  route-target import 1:1
 exit-address-family
!

De PDF-informatie is gewijzigd:

PE3#show ip rpf vrf one 10.100.1.6
RPF information for ? (10.100.1.6)
  RPF interface: Lspvif0
  Strict-RPF interface: Lspvif1
  RPF neighbor: ? (10.100.1.1)
  RPF route/mask: 10.100.1.6/32
  RPF type: unicast (bgp 1)
  Doing distance-preferred lookups across tables
  RPF topology: ipv4 multicast base, originated from ipv4 unicast base
PE3#show ip rpf vrf one 10.100.1.7
RPF information for ? (10.100.1.7)
  RPF interface: Lspvif0
  Strict-RPF interface: Lspvif2
  RPF neighbor: ? (10.100.1.2)
  RPF route/mask: 10.100.1.7/32
  RPF type: unicast (bgp 1)
  Doing distance-preferred lookups across tables
  RPF topology: ipv4 multicast base, originated from ipv4 unicast base

PE3 creëerde een Lspvif interface per Ingreress PE. De LSPVIF interface wordt gecreëerd per Ingreress PE, per adresfamilie (AF) en per VRF. Het PF voor 10.100.1.6 richt nu op interface Lspvif1 en het RPF voor 10.100.1.7 nu punten om Lspvif2 in te zetten.

PE3#show ip multicast vrf one mpls vif
 
Interface   Next-hop           Application     Ref-Count   Table / VRF name   Flags
Lspvif0     0.0.0.0              MDT               N/A       1   (vrf one) 0x1
Lspvif1     10.100.1.1           MDT               N/A       1   (vrf one) 0x1
Lspvif2     10.100.1.2           MDT               N/A       1   (vrf one) 0x1

Nu wordt de controle van RPF op pakketten (S1,G) van PE1 gecontroleerd tegen RPF interface Lspvif1. Deze pakketten komen in met MPLS etiket 29. De controle van RPF op pakketten (S2,G) van PE2 wordt gecontroleerd tegen RPF interface Lspvif2. Deze pakketten komen in met MPLS etiket 30. De stromen komen op PE3 door verschillende inkomende interfaces, maar dit zou ook kunnen zijn dezelfde interface. Omdat mLDP echter nooit gebruik maakt van Pentern-Popping (PHP), is er altijd een regelmatig MPLS-label bovenop de multicast-pakketten. De (S1,G) pakketten die uit PE1 en uit PE2 komen, zijn op twee verschillende Gedeelte MDTs en hebben daarom een ander MPLS-etiket. Daarom kan PE3 discrimineren tussen de (S1,G) stroom die uit PE1 komt en de (S1,G) stroom die uit PE2 komt. Op deze manier kunnen de pakketten door PE3 worden gescheiden en kan een RPF worden uitgevoerd tegen verschillende IP-routers.

De mLDP-database op PE3 toont nu de verschillende Lspvif-interfaces per inkomende PE.

PE3#show mpls mldp database
* Indicates MLDP recursive forwarding is enabled
 
LSM ID : C   Type: P2MP   Uptime : 00:05:58
FEC Root           : 10.100.1.1
Opaque decoded     : [gid 65536 (0x00010000)]
Opaque length     : 4 bytes
Opaque value       : 01 0004 00010000
Upstream client(s) :
   10.100.1.1:0   [Active]
     Expires       : Never         Path Set ID : C
     Out Label (U) : None         Interface   : Ethernet5/0*
     Local Label (D): 29           Next Hop     : 10.1.5.1
Replication client(s):
   MDT (VRF one)
     Uptime         : 00:05:58     Path Set ID : None
     Interface     : Lspvif1      
 
LSM ID : D   Type: P2MP   Uptime : 00:05:58
FEC Root           : 10.100.1.2
Opaque decoded     : [gid 65536 (0x00010000)]
Opaque length     : 4 bytes
Opaque value       : 01 0004 00010000
Upstream client(s) :
   10.100.1.5:0   [Active]
     Expires       : Never         Path Set ID : D
     Out Label (U) : None         Interface   : Ethernet6/0*
     Local Label (D): 30           Next Hop     : 10.1.3.5
Replication client(s):
   MDT (VRF one)
     Uptime         : 00:05:58     Path Set ID : None
     Interface     : Lspvif2      

Streng RPF of RPF per Ingress PE werkt door het feit dat de multicast stromen naar Ingress PE komen met een ander MPLS-label per instap PE:

PE3#show mpls forwarding-table vrf one
Local     Outgoing   Prefix           Bytes Label   Outgoing   Next Hop  
Label     Label     or Tunnel Id     Switched     interface            
29   [T] No Label   [gid 65536 (0x00010000)][V]   \
                                       162708       aggregate/one
30   [T] No Label   [gid 65536 (0x00010000)][V]   \
                                       162750       aggregate/one
 
[T]     Forwarding through a LSP tunnel.
       View additional labelling info with the 'detail' option

Het bewijs dat strikt RPF werkt, is dat er niet langer een dubbele stroom (S1,G) op PE3 is doorgestuurd. De dubbele stroom komt nog steeds op PE3 aan, maar deze wordt afgebroken als gevolg van de storing in RPF. De RPF-storingteller is 676255 en stijgt constant met 10 pps.

PE3#show ip mroute vrf one 232.1.1.1 count
Use "show ip mfib count" to get better response time for a large number of mroutes.
 
IP Multicast Statistics
3 routes using 1692 bytes of memory
2 groups, 1.00 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
 
Group: 232.1.1.1, Source count: 2, Packets forwarded: 1443260, Packets received:
2119515
Source: 10.100.1.7/32, Forwarding: 707523/10/28/2, Other: 707523/0/0
Source: 10.100.1.6/32, Forwarding: 735737/10/28/2, Other: 1411992/676255/0

Het uitvoeringspercentage bij PE3 is nu 20 pps, wat 10 pps is voor elke stroom (S1,G) en (S2,G):

PE3#show interfaces ethernet0/0 | include rate
Queueing strategy: fifo
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 6000 bits/sec, 20 packets/sec

Conclusie

De strikte Controle RPF moet voor de mVPN implementatiemodellen worden gebruikt die Gedistribueerde MDT gebruiken.

De dingen lijken te werken, zelfs als u niet de strikte controle van RPF voor de mVPN implementatiemodellen met Gedistribueerde MDT vormt: de multicast stromen worden aan de ontvangers geleverd . Er is echter de mogelijkheid dat er dubbel multicast verkeer is wanneer bronnen worden aangesloten op meerdere IP-routers. Dit leidt tot een verspilling van bandbreedte in het netwerk en kan de multicast toepassing op de ontvangers nadelig beïnvloeden. Vandaar, is het een moet om de strikte Controle van RPF voor de mVPN implementatiemodellen te configureren die Gedeelte MDT gebruiken.

TAC Authored

Bijgedragen door Cisco-engineers

  • Luc De Ghein
    Cisco TAC Engineer.

Was dit document nuttig?

FeedbackFeedback

Contact Cisco