Streng RPF-controle op mVPN
Inhoud
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.
Feedback