Strict RPF Check für mVPN
Inhalt
Einführung
In diesem Dokument wird die Funktion Strict Reverse Path Forwarding (RPF) für Multicast over VPN (mVPN) beschrieben. In diesem Dokument wird ein Beispiel und die Implementierung in Cisco IOS® verwendet, um das Verhalten zu veranschaulichen.
Hintergrundinformationen
RPF impliziert, dass die eingehende Schnittstelle an die Quelle geprüft wird. Obwohl die Schnittstelle überprüft wird, um festzustellen, ob sie der Quelle entspricht, wird nicht überprüft, ob sie der richtige RPF-Nachbar auf dieser Schnittstelle ist. Auf einer Multiaccess-Schnittstelle kann es mehrere Nachbarn geben, zu denen Sie RPF erstellen können. Das Ergebnis könnte sein, dass der Router doppelt denselben Multicast-Stream auf dieser Schnittstelle empfängt und beide weiterleitet.
In Netzwerken, in denen Protocol Independent Multicast (PIM) auf der Multiaccess-Schnittstelle ausgeführt wird, stellt dies kein Problem dar, da der doppelte Multicast-Stream die Ausführung des Assertionsmechanismus bewirkt und ein Multicast-Stream nicht mehr empfangen wird. In einigen Fällen wird PIM nicht auf dem Multicast Distribution Tree (MDT) ausgeführt, einer Schnittstelle mit mehreren Zugriffen. In diesen Fällen ist Border Gateway Protocol (BGP) das Overlay-Signalisierungsprotokoll.
In Profilen mit partitioniertem MDT kann es selbst dann unmöglich sein, Asserts zu haben, wenn PIM als Overlay-Protokoll ausgeführt wird. Der Grund dafür ist, dass ein Eingangs-Provider-Edge (PE) in Szenarien, in denen es zwei oder mehr Eingangs-PE-Router gibt, nicht mit dem partitionierten MDT eines anderen Eingangs-PE verbunden ist. Jeder Eingangs-PE-Router kann den Multicast-Stream an seinen Partitionierten MDT weiterleiten, ohne dass der andere Eingangs-PE-Router den Multicast-Datenverkehr sieht. Die Tatsache, dass zwei verschiedene Egress-PE-Router jeweils einem MDT zu einem anderen Ingress-PE-Router für denselben Multicast-Stream gehören, ist ein gültiges Szenario: wird als Anycast Source bezeichnet. Dadurch können verschiedene Empfänger demselben Multicast-Stream beitreten, jedoch über einen anderen Pfad im MPLS-Core (Multiprotocol Label Switching). Ein Beispiel für Anycast Source finden Sie in Abbildung 1.
Abbildung 1
Es gibt zwei Eingangs-PE-Router: PE1 und PE2. Es gibt zwei Egress-PE-Router: PE3 und PE4. Jeder Egress-PE-Router hat einen anderen Ingress-PE-Router als seinen RPF-Nachbarn. PE3 hat PE1 als RPF-Nachbarn. PE4 hat PE2 als RPF-Nachbarn. Die Egress-PE-Router wählen ihren nächsten Eingangs-PE-Router als RPF-Nachbarn aus.
Der Stream (S1,G) wechselt von S1 zum Empfänger 1 über den oberen Pfad und von S1 zum Empfänger 2 über den unteren Pfad. Es gibt keine Überschneidung der beiden Streams über die beiden Pfade (jeder Pfad im MPLS-Core ist ein anderer partitionierter MDT).
Wenn der MDT ein Standard-MDT ist (wie in den Standard-MDT-Profilen), würde dies nicht funktionieren, da sich die beiden Multicast-Streams im gleichen Standard-MDT befinden und der Assert-Mechanismus ausgeführt wird. Wenn der MDT ein Daten-MDT in den Standard-MDT-Profilen ist, werden alle Eingangs-PE-Router dem Daten-MDT von den anderen Eingangs-PE-Routern hinzugefügt. Daher wird der Multicast-Datenverkehr zwischen den Routern überwacht, und der Assert-Mechanismus wird erneut ausgeführt. Wenn das Overlay-Protokoll BGP lautet, wird Upstream Multicast Hop (UMH) ausgewählt, und es wird nur ein Ingress-PE-Router als Forwarder ausgewählt, jedoch pro MDT.
Anycast Source ist einer der großen Vorteile der Ausführung von Partitioniertem MDT.
Problem
Die reguläre RPF-Prüfung bestätigt, dass die Pakete über die richtige RPF-Schnittstelle am Router ankommen. Es wird nicht überprüft, ob die Pakete vom richtigen RPF-Nachbarn auf dieser Schnittstelle empfangen werden.
Siehe Abbildung 2. Es zeigt ein Problem, bei dem doppelter Datenverkehr in einem Szenario mit partitioniertem MDT dauerhaft weitergeleitet wird. Es zeigt, dass die reguläre RPF-Prüfung bei einem partitionierten MDT nicht ausreicht, um doppelten Datenverkehr zu vermeiden.
Abbildung 2
Es gibt zwei Empfänger. Der erste Empfänger ist so eingerichtet, dass er Datenverkehr für (S1,G) und (S2,G) empfängt. Der zweite Empfänger ist so eingerichtet, dass er nur Datenverkehr für (S2,G) empfängt. Es gibt einen partitionierten MDT, und BGP ist das Overlay-Signalisierungsprotokoll. Beachten Sie, dass die Quelle S1 sowohl über PE1 als auch über PE2 erreichbar ist. Das Core-Tree-Protokoll ist Multipoint Label Distribution Protocol (mLDP).
Jeder PE-Router kündigt eine BGP-IPv4-mVPN-Route vom Typ 1 an, was anzeigt, dass er der Root eines partitionierten MDT sein kann.
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 findet PE1 nach einer Suche nach der Unicast-Route für S1 als RPF-Nachbar für 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 wählt PE1 als RPF-Nachbar für (S1,G) aus und bindet den partitionierten MDT mit PE1 als Root an. PE3 wählt PE2 als RPF-Nachbar für (S2,G) und fügt sich dem partitionierten MDT als Root PE2 hinzu.
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 wählt PE2 als RPF-Nachbar für (S1,G) aus und bindet den partitionierten MDT mit PE1 als Root an.
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
Beachten Sie, dass die RPF-Schnittstelle LSPVIF0 für S1 (10.100.1.6) und S2 (10.100.1.7) ist.
PE3 fügt sich dem partitionierten MDT von PE2 für (S2,G) bei, und PE4 bindet den partitionierten MDT von PE2 für (S1,G) ein. PE1 fügt sich in den partitionierten MDT von PE1 für (S1,G) ein. Sie sehen dies anhand der BGP-IPv4-mVPN-Routen vom Typ 7, die auf PE1 und PE2 empfangen wurden.
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 ?
Die Multicast-Einträge auf PE3 und 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
Dies zeigt, dass PE3 mit dem Point-to-Multipoint (P2MP)-Tree verbunden ist, dessen Ursprung PE1 ist, sowie mit dem Tree, dessen Ursprung PE2 ist:
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
Dies zeigt, dass PE4 mit dem P2MP-Tree verbunden ist, dessen Ursprung PE2 ist:
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- und S2-Stream für die Gruppe 232.1.1.1 mit 10 pps. Sie können die Streams an PE3 und PE4 sehen. Bei PE3 können Sie die Rate für (S1,G) jedoch als 20 pps anzeigen.
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
Es gibt einen doppelten Stream. Diese Duplizierung ist das Ergebnis des Streams (S1,G) auf dem partitionierten MDT von PE1 und dem partitionierten MDT von PE2. Dieser zweite partitionierte MDT aus PE2 wurde von PE3 hinzugefügt, um den Stream (S2,G) abzurufen. Da jedoch PE4 dem partitionierten MDT von PE2 beigetreten ist, um (S1,G) zu erhalten, ist (S1,G) auch auf dem partitionierten MDT von PE2 vorhanden. Daher empfängt PE3 den Stream (S1,G) von beiden partitionierten MDTs, zu denen er gehört.
PE3 kann nicht zwischen den Paketen für (S1,G) unterscheiden, die er von PE1 und PE2 empfängt. Beide Streams werden auf der richtigen RPF-Schnittstelle empfangen: 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
Die Pakete können auf verschiedenen eingehenden physischen Schnittstellen auf PE3 oder auf derselben Schnittstelle eingehen. Auf jeden Fall werden die Pakete aus den verschiedenen Streams für (S1,G) mit einem anderen MPLS-Label am PE3 empfangen:
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
Lösung
Die Lösung ist eine strengere RPF. Bei striktem RPF überprüft der Router, von welchem Nachbarn die Pakete auf der RPF-Schnittstelle empfangen werden. Ohne die strikte RPF-Methode kann nur geprüft werden, ob die eingehende Schnittstelle die RPF-Schnittstelle ist, nicht jedoch, ob die Pakete vom richtigen RPF-Nachbarn auf dieser Schnittstelle empfangen werden.
Hinweise zu Cisco IOS
Hier einige wichtige Hinweise zu RPF mit Cisco IOS.
- Wenn Sie in den/vom strikten RPF-Modus wechseln, konfigurieren Sie ihn entweder vor der Konfiguration des Partitionierten MDT oder des BGP-Leerstellen. Wenn Sie nur den Befehl strict RPF konfigurieren, wird nicht sofort eine weitere Lspvif-Schnittstelle erstellt.
- Strict RPF ist in Cisco IOS standardmäßig nicht aktiviert.
- Es wird nicht unterstützt, den Befehl strict-rpf mit Standard-MDT-Profilen zu verwenden.
Konfiguration
Sie können auf PE3 für VRF (Virtual Routing and Forwarding) ein striktes RPF konfigurieren.
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
!
Die RPF-Informationen haben sich geändert:
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 hat pro Eingangs-PE eine LSPVIF-Schnittstelle erstellt. Die LSPVIF-Schnittstelle wird pro Eingangs-PE, pro Adressfamilie (AF) und pro VRF erstellt. Der RPF für 10.100.1.6 zeigt nun auf die Schnittstelle Lspvif1 und der RPF für 10.100.1.7 auf die Schnittstelle Lspvif2.
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
Jetzt wird die RPF-Prüfung auf Pakete (S1,G) von PE1 mit der RPF-Schnittstelle Lspvif1 abgeglichen. Diese Pakete werden mit dem MPLS-Label 29 geliefert. Die RPF-Prüfung auf Pakete (S2,G) von PE2 wird mit der RPF-Schnittstelle Lspvif2 abgeglichen. Diese Pakete werden mit dem MPLS-Label 30 geliefert. Die Streams gelangen über verschiedene eingehende Schnittstellen auf PE3, aber auch über dieselbe Schnittstelle. Da mLDP jedoch niemals Penultimate-Hop-Popping (PHP) verwendet, wird auf den Multicast-Paketen immer ein reguläres MPLS-Label angezeigt. Die (S1,G)-Pakete, die von PE1 und PE2 eintreffen, befinden sich in zwei verschiedenen partitionierten MDTs und verfügen daher über ein anderes MPLS-Label. Daher kann PE3 zwischen dem (S1,G)-Stream von PE1 und dem (S1,G)-Stream von PE2 unterscheiden. Auf diese Weise können die Pakete vom PE3 getrennt gehalten werden, und ein RPF kann für verschiedene Eingangs-PE-Router ausgeführt werden.
Die mLDP-Datenbank auf PE3 zeigt jetzt die verschiedenen LSPVIF-Schnittstellen pro Eingangs-PE an.
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
Strict RPF oder RPF pro Eingangs-PE ist darauf zurückzuführen, dass die Multicast-Streams mit einem anderen MPLS-Label pro Eingangs-PE in den Eingangs-PE eingehen:
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
Der Beweis für die Funktion eines strikten RPF besteht darin, dass auf PE3 kein doppelter Stream (S1,G) weitergeleitet wird. Der doppelte Stream kommt weiterhin auf PE3 an, wird aber aufgrund des RPF-Ausfalls verworfen. Der RPF-Fehlerzähler liegt bei 676255 und erhöht sich konstant um 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
Die Ausgangsrate bei PE3 beträgt jetzt 20 pps, d. h. 10 pps für jeden Stream (S1,G) und (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
Schlussfolgerung
Für die mVPN-Bereitstellungsmodelle, die einen partitionierten MDT verwenden, muss eine strikte RPF-Prüfung verwendet werden.
Es scheint, dass die Dinge funktionieren, selbst wenn Sie die strenge RPF-Prüfung für die mVPN-Bereitstellungsmodelle mit partitioniertem MDT nicht konfigurieren: die Multicast-Streams werden an die Empfänger übertragen. Es besteht jedoch die Möglichkeit, dass Multicast-Datenverkehr dupliziert wird, wenn Quellen mit mehreren Eingangs-PE-Routern verbunden sind. Dies führt zu einer Verschwendung von Bandbreite im Netzwerk und kann die Multicast-Anwendung auf den Empfängern negativ beeinflussen. Daher muss eine strenge RPF-Prüfung für die mVPN-Bereitstellungsmodelle konfiguriert werden, die einen partitionierten MDT verwenden.
Feedback