Multicast-servicereslectie met PIM-SM op IOS-XE: Multicast naar Unicast
Inhoud
Inleiding
Het doel van dit artikel is om u een begrip van het fundamentele werken van MSR (Multicast de replicatie van de Dienst) te geven die IOS-XE platforms, door de vorm van een gids van het configuratielab gebruiken.
Voorwaarden
Vereisten
Basiskennis van PIM-SM
Gebruikte componenten
ASR 1000 (R2&R4), ISR 4300 (R3), ISR 2900 (R1&R5)
Configureren
We tonen hieronder end-to-end configuraties op basis van het onderstaande schema voor het vertalen van de multicast.
Netwerkdiagram
Configuraties
In het bovenstaande diagram fungeert de knooppunt R1 als de ontvanger die alleen unicast multicast-gegevensfeed uit de multicast-bron krijgt.
De knooppunt R5 fungeert als de multicast bron die multicast ICMP-verkeer genereert dat afkomstig is van de loopback 0-interface.
Het knooppunt R2 bevindt zich onder het multicast core-domein van Content Providers en voert PIM-SM uit met onderliggend OSPF-profiel.
De knooppunt R3 fungeert als de router die de Multicast-servicereplicatietoepassing uitvoert en is in dit geval de multicast-grensrouter van waaruit het multicast-gegevensverkeer naar de ontvanger moet worden vertaald in een unicast-gegevenspakket. Het gebruikt OSPF en EIGRP met de Content Provider en ISP respectievelijk en het huisvest de RP (Rendezvouz Point) op zijn loopback interface in het multicast kerndomein.
De knooppunt R4 valt onder de ISP Core-controle en is niet multicast ingeschakeld en begrijpt alleen hoe de R3-knooppunt kan worden bereikt met behulp van onderliggende EIGRP-routing.
Hieronder, kunt u de relevante configuraties vinden huidig op de knooppunten huidig in het bovengenoemde topologiediagram:
R1:
!
no ip domain lookup
ip cef
no ipv6 cef
!
interface GigabitEthernet0/2
ip address 10.10.20.1 255.255.255.0
duplex auto
speed auto
end
!
router eigrp 100
network 10.10.20.0 0.0.0.255
!R2:
!
interface GigabitEthernet0/0/0
ip address 10.10.20.2 255.255.255.0
negotiation auto
!
interface GigabitEthernet0/0/2
ip address 10.10.10.1 255.255.255.0
negotiation auto
!
router eigrp 100
network 10.10.10.0 0.0.0.255
network 10.10.20.0 0.0.0.255
!R3:
!
ip multicast-routing distributed
!
interface Loopback0
ip address 192.168.2.1 255.255.255.255
ip pim sparse-mode
ip ospf 1 area 0
!
interface GigabitEthernet0/0/0
ip address 192.168.30.1 255.255.255.0
ip pim sparse-mode
ip ospf 1 area 0
negotiation auto
!
interface GigabitEthernet0/0/1
ip address 10.10.10.2 255.255.255.0
negotiation auto
!
interface Vif1
ip address 192.169.169.1 255.255.255.0
ip pim sparse-mode
ip service reflect GigabitEthernet0/0/0 destination 224.1.1.0 to 10.10.20.0 mask-len 24 source 192.169.169.169 <<<<
ip igmp static-group 224.1.1.1
ip ospf 1 area 0
!
router eigrp 100
network 10.10.10.0 0.0.0.255
!
router ospf 1
!
ip pim rp-address 192.168.2.1
!R4:
!
ip multicast-routing distributed
!
interface GigabitEthernet0/0/0
ip address 192.168.30.2 255.255.255.0
ip pim sparse-mode
ip ospf 1 area 0
negotiation auto
!
interface GigabitEthernet0/0/2
ip address 192.168.20.1 255.255.255.0
ip pim sparse-mode
ip ospf 1 area 0
negotiation auto
!
router ospf 1
!
ip pim rp-address 192.168.2.1
!R5:
!
ip multicast-routing
ip cef
no ipv6 cef
!
interface Loopback0
ip address 192.168.168.168 255.255.255.255
ip pim sparse-mode
ip ospf 1 area 0
!
interface GigabitEthernet0/2
ip address 192.168.20.2 255.255.255.0
ip pim sparse-mode
ip ospf 1 area 0
duplex auto
speed auto
!
router ospf 1
!
ip pim rp-address 192.168.2.1
!Verifiëren
We kunnen de configuraties valideren door een test uit te voeren en multicast verkeer te simuleren van de R5 router met een bron van zijn loopback 0 interface [192.168.168.168] bestemd voor het multicast adres 224.1.1.1. Controleer vervolgens de routegegevens op de knooppunt waarop de MSR-toepassing wordt uitgevoerd, d.w.z. R3 :
R5(config)#do ping 224.1.1.1 sou lo 0 rep 10000000
Type escape sequence to abort.
Sending 10000000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.168.168
.............................R3#sh ip mroute 224.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, c - PFP-SA cache created entry
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.1.1.1), 00:47:41/stopped, RP 192.168.2.1, flags: SJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Vif1, Forward/Sparse, 00:46:36/00:01:23 <<<<
(192.168.168.168, 224.1.1.1), 00:00:20/00:02:43, flags: T
Incoming interface: GigabitEthernet0/0/0, RPF nbr 192.168.30.2
Outgoing interface list:
Vif1, Forward/Sparse, 00:00:20/00:02:39 <<<<R3#sh ip mroute 224.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 2938 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: 224.1.1.1, Source count: 1, Packets forwarded: 1455, Packets received: 1458 <<<<
RP-tree: Forwarding: 1/0/100/0, Other: 1/0/0
Source: 192.168.168.168/32, Forwarding: 1454/1/113/0, Other: 1457/3/0
R3#sh ip mroute 224.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 2938 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: 224.1.1.1, Source count: 1, Packets forwarded: 1465, Packets received: 1468 <<<<
RP-tree: Forwarding: 1/0/100/0, Other: 1/0/0
Source: 192.168.168.168/32, Forwarding: 1464/1/113/0, Other: 1467/3/0Ook kunt u opnamen maken om te verifiëren dat de pakketten inderdaad worden vertaald naar het beoogde unicast-bestemmingsadres op de R2-knooppunt door de EPC-functie (Embedded Packet Capture) op de IOS-XE router te gebruiken:
R2#mon cap TAC int gi 0/0/2 both match any
R2#mon cap TAC buff siz 50 circular
R2#mon cap TAC start
Started capture point : TAC
R2#
*Aug 12 06:50:40.195: %BUFCAP-6-ENABLE: Capture Point TAC enabled.
R2#sh mon cap TAC buff br | i ICMP
6 114 10.684022 192.169.169.169 -> 10.10.20.1 0 BE ICMP <<<<
7 114 10.684022 192.169.169.169 -> 10.10.20.1 0 BE ICMP <<<<
8 114 12.683015 192.169.169.169 -> 10.10.20.1 0 BE ICMP <<<<
9 114 12.683015 192.169.169.169 -> 10.10.20.1 0 BE ICMP <<<<Hier, het belangrijke punt om op te merken is dat regelmatig wanneer u multicast ICMP pings in "laboratoriummilieu's"uitvoert, u gewoonlijk zou verwachten dat u terug de ICMP echo antwoordpakketten van de ontvangerkant aan de bron ontvangt, veronderstellend dat er volledige bereikbaarheid tussen twee (bron en ontvanger) is. Echter, in dit scenario is het belangrijk om op te merken dat zelfs als we proberen om het NATted bronadres voor de multicast ICMP-pakketten, d.w.z. 192.169.169.169 tot de ontvanger, d.w.z. R1 via EIGRP, te adverteren, de unicast ICMP-echoantwoorden de R3 router niet zullen kruisen, aangezien de omgekeerde NAT niet op de MSR-toepassingsknooppunt is geconfigureerd. Wij kunnen dit testen, door te proberen om de EIGRP routerreclame van Vif 1 interface op R3 in EIGRP (ISP Core routing) uit te voeren:
ISR4351(config)#router eigrp 100
ISR4351(config-router)#network 192.169.169.0 0.0.0.255 <<<<Nu, kunnen wij de opnamen controleren die op de R2 knoop op de echoantwoorden ICMP worden genomen die naar R3 worden verzonden:
R2#sh mon cap TAC buff br | i ICMP
249 114 317.847948 192.169.169.169 -> 10.10.20.1 0 BE ICMP
250 114 317.847948 192.169.169.169 -> 10.10.20.1 0 BE ICMP
251 114 317.847948 10.10.20.1 -> 192.169.169.169 0 BE ICMP <<<<
252 114 317.847948 10.10.20.1 -> 192.169.169.169 0 BE ICMP <<<<
253 114 319.847948 192.169.169.169 -> 10.10.20.1 0 BE ICMP
254 114 319.847948 192.169.169.169 -> 10.10.20.1 0 BE ICMP
255 114 319.848955 10.10.20.1 -> 192.169.169.169 0 BE ICMP <<<<
256 114 319.848955 10.10.20.1 -> 192.169.169.169 0 BE ICMP <<<<
259 114 321.848955 192.169.169.169 -> 10.10.20.1 0 BE ICMP
260 114 321.848955 192.169.169.169 -> 10.10.20.1 0 BE ICMP
261 114 321.848955 10.10.20.1 -> 192.169.169.169 0 BE ICMP <<<<
262 114 321.848955 10.10.20.1 -> 192.169.169.169 0 BE ICMP <<<< Maar de pings zouden nog steeds falen zoals gezien op de bron R5:
R5(config)#do ping 224.1.1.1 sou lo 0 rep 10000000
Type escape sequence to abort.
Sending 10000000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.168.168
......................................................................
......................................................................
Nu om de antwoorden te krijgen om tot de bron volledig te bereiken, kunnen wij NAT haven vormen door:sturen op de MSR toepassingsknoop R3 om het voorbestemde verkeer naar 192.169.169.169.169 tot 192.168.168.168 te vertalen, door verlengbare NAT te vormen:
R3(config)#int gi 0/0/1
R3(config-if)#ip nat out
R3(config-if)#int gi 0/0/0
R3(config-if)#ip nat ins
R3(config-if)#exit
R3(config)#ip nat inside source static 192.168.168.168 192.169.169.169 extendable <<<<Bij het controleren van de bron R5 knoop, kunnen wij de reactie zien terugkomen:
R5(config)#do ping 224.1.1.1 sou lo 0 rep 10000000
Type escape sequence to abort.
Sending 10000000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.168.168
......................................................................
Reply to request 716 from 10.10.20.1, 1 ms
Reply to request 716 from 10.10.20.1, 1 ms
Reply to request 717 from 10.10.20.1, 1 ms
Reply to request 717 from 10.10.20.1, 1 ms
Reply to request 718 from 10.10.20.1, 1 ms
Reply to request 718 from 10.10.20.1, 1 ms Het bovenstaande is alleen uitgevoerd om de pakketstroom te verklaren en te begrijpen hoe u het omgekeerde unicastpad/de omgekeerde stroom voor het gegevensverkeer en het downstream multicast-verkeer kunt instellen. Aangezien in de reguliere productiescenario's, zou u gewoonlijk niet komen in gevallen/instanties waar de multicast toepassingen die op de server/bronkant lopen een omgekeerde erkenningspakketten van de ontvangers in een unicastvorm vereisen.
Door de bovenstaande tests en valideringen moet het een kort overzicht hebben gegeven van de manier waarop multicast-servicereplicatie-toepassing op een van de multicast-grensknooppunten kan worden uitgevoerd en hoe hetzelfde kan worden geïmplementeerd als het hierboven weergegeven bestand moet worden uitgebreid naar een implementatie op grote schaal.
Feedback