Modalità densa Pim multicast

Nella lezione precedente abbiamo discusso le basi del routing multicast e io ha spiegato alcune delle differenze tra i protocolli di routing multicast della modalità densi e sparsi. L’unico protocollo di routing multicast che è completamente supportato su dispositivi Cisco IOS è PIM (protocollo indipendente multicast).

La parte indipendente è un po ‘confusa … PIM dipende al 100% sulle informazioni nella tabella di routing unicast ma Non importa quale protocollo di routing Unicast che usi per riempirlo. Altri protocolli di routing multicast come DVMRP e MOSPF non utilizzare la tabella di routing Unicast, ma costruire le proprie tabelle.

PIM supporta tre diverse modalità:

• Modalità Dense Pim
• Modalità PIM SPARY PIM
• PIM MODALITÀ SPARSE-DENSENTE-DENSE

Ecco la differenza chiave tra modalità sparsa e densa:

• Modalità densa: inoltreremo il traffico multicast su tutte le interfacce fino a quando un router a valle ci richiede di interrompere la possibilità di smettere.
• modalità sparse: non inoltreremo il traffico multicast su qualsiasi interfaccia fino a quando un router a valle richiede di inoltrarlo .

In questa lezione, faremo uno sguardo da vicino alla modalità Dense Pim.

PIM DENSE MODE è un metodo push in cui usiamo alberi basati su origini. Cosa significa questo? Diamo un’occhiata ad un esempio:

sopra vediamo un server video che invia un pacchetto multicast verso R1. Non appena R1 riceve questo pacchetto multicast creerà una voce nella sua tabella di routing multicast in cui memorizza l’indirizzo sorgente e l’indirizzo del gruppo multicast. Quindi inonda il traffico su tutte le sue interfacce.

Altri router che ricevono questo pacchetto multicast farà la stessa cosa, il pacchetto multicast è allagato su tutte le loro interfacce. Ciò causa alcuni problemi, un problema è che avremo loop di routing multicast. Ad esempio è possibile vedere che il pacchetto che R1 riceve viene inoltrato a R2 > R4 > R5 e Torna a R1 (e dall’altra parte in giro). Come ci occupiamo di questo? Dai un’occhiata qui sotto:

Ogni router che non è interessato al traffico multicast invierà una prugna al suo router upstream, richiedendolo di smettere di inoltrarlo. Il router upstream è il router in cui riceviamo traffico multicast da, un router a valle è un router in cui inoltreremo il traffico multicast a. Le frecce rosse sopra sono i messaggi di prugna che i router invieranno. Ci sono un paio di motivi per cui un router può inviare un messaggio di prugna:

• quando non abbiamo host direttamente connessi che sono interessati a ricevere il traffico multicast.
• Quando non ci sono router a valle interessati a ricevere il traffico multicast.
• quando riceviamo il traffico su un’interfaccia non RPF.

RPF (Inoltro del percorso inverso) è un Controllo aggiuntivo che aiuta a prevenire i loop di routing multicast:

Quando un router riceve un pacchetto multicast controllerà l’indirizzo IP di origine di questo pacchetto nella tabella di routing Unicast. Controllerà la prossima interfaccia hop e in uscita che usiamo per raggiungere la fonte.

• Quando il pacchetto multicast è stato ricevuto sull’interfaccia che usiamo per raggiungere la fonte, il controllo RPF ha esito positivo.
• Quando il pacchetto multicast è stato ricevuto su un’altra interfaccia, non riesce il controllo RPF e il pacchetto viene scartato.

Il risultato finale sarà simile a questo:

Abbiamo una bella topologia pulita in cui il traffico multicast è inondato da R1 a R2 > r6 h1. Questo comportamento di inondazione e prugna si verificherà ogni tre minuti.

Chiamiamo questa topologia l’albero di distribuzione basato su sorgente o SPT (albero del percorso più breve). A volte è anche chiamato l’albero sorgente:

• L’albero definisce il percorso dalla sorgente al ricevitore (s).
• La sorgente è la radice del nostro albero.
• I router in mezzo che stanno inoltrando il traffico sono i nodi.
• Le sottoretiche con i ricevitori sono i rami e le foglie dell’albero.

A seconda Sui gruppi sorgente e / o multicast che usiamo, potresti avere più di un albero di origine nella tua rete. Una volta che guardiamo alla configurazione, vedremo che usiamo la notazione per fare riferimento a un particolare albero di origine:

• s: l’indirizzo sorgente
• g: il multicast Indirizzo di gruppo

Ora hai un’idea di quale modalità Dense Pim è di circa, vediamo cosa sembra su alcuni router reali dovremmo?

Configurazione

Utilizzeremo la seguente topologia per questa dimostrazione:

sopra abbiamo un server video Sul lato sinistro che sarà la fonte del nostro traffico multicast. H2 e H3 sono due dispositivi host che vogliono ricevere il traffico multicast.R1, R2 e R3 saranno configurati per utilizzare la modalità densi PIM.

Unicast Routing

Prima configureremo un protocollo di routing su tutti i router, prenderò OSPF. Tutte le interfacce saranno pubblicizzate:

R1(config)#router ospf 1R1(config-router)#network 192.168.1.0 0.0.0.255 area 0R1(config-router)#network 192.168.12.0 0.0.0.255 area 0R1(config-router)#network 192.168.13.0 0.0.0.255 area 0

R2(config)#router ospf 1R2(config-router)#network 192.168.2.0 0.0.0.255 area 0R2(config-router)#network 192.168.12.0 0.0.0.255 area 0R2(config-router)#network 192.168.23.0 0.0.0.255 area 0

R3(config)#router ospf 1R3(config-router)#network 192.168.3.0 0.0.0.255 area 0R3(config-router)#network 192.168.13.0 0.0.0.255 area 0R3(config-router)#network 192.168.23.0 0.0.0.255 area 0

ORA Possiamo concentrarci sulla configurazione multicast.

Modalità Dense PIM

Routing multicast è disabilitato per impostazione predefinita sui router Cisco IOS, quindi dobbiamo abilitarlo:

R1, R2 & R3(config)#ip multicast-routing

Ora possiamo configurare PIM. Iniziamo con R1:

R1(config)#interface GigabitEthernet 0/1R1(config-if)#ip pim dense-mode

Non appena abilito la modalità DENSE PIM sull’interfaccia Il nostro router inizierà a inviare Pim Hello Packet. Ecco cosa assomiglia a Wireshark:

sopra puoi vedere il tipo di pacchetto (ciao ) E mostra anche il tempo di attesa. Per qualsiasi motivo, Wireshark (versione 2.0.1) mi mostra un valore di 1 ma il valore predefinito è di 105 secondi. Se vuoi dare un’occhiata a questo pacchetto da solo, ecco la cattura del cloud shark:

Modalità Denso PIM Ciao pacchetto

Mostra il tempo di attesa corretto di 105 secondi.

Abilitiamo il PIM DENSO su R2 pure:

R2(config)#interface GigabitEthernet 0/1R2(config-if)#ip pim dense-mode 

Non appena lo facciamo, R1 e R2 diventeranno vicini da quando si ricevono gli altri Pim Ciao Pacchetti. Continuano a riceverli prima che il timer di attesa sia scaduto, continueranno a vedere l’un l’altro come vicini Pim.:

R1#%PIM-5-NBRCHG: neighbor 192.168.12.2 UP on interface GigabitEthernet0/1

Abilitiamo tutte le altre interfacce . È inoltre necessario abilitare PIM sulle interfacce che si connettono ai dispositivi host:

R1(config)#interface GigabitEthernet 0/2R1(config-if)#ip pim dense-mode R1(config)#interface GigabitEthernet 0/3R1(config-if)#ip pim dense-mode

R2(config)#interface GigabitEthernet 0/2R2(config-if)#ip pim dense-modeR2(config)#interface GigabitEthernet 0/3R2(config-if)#ip pim dense-mode

R3(config)#interface GigabitEthernet 0/1R3(config-if)#ip pim dense-mode R3(config)#interface GigabitEthernet 0/2R3(config-if)#ip pim dense-modeR3(config)#interface GigabitEthernet 0/3R3(config-if)#ip pim dense-mode

PIM DENSE VICINIRI

Accerciamo che tutti i router siano diventati vicini:

R1#show ip pim neighbor PIM Neighbor TableMode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority, P - Proxy Capable, S - State Refresh Capable, G - GenID Capable, L - DR Load-balancing CapableNeighbor Interface Uptime/Expires Ver DRAddress Prio/Mode192.168.12.2 GigabitEthernet0/1 00:05:59/00:01:37 v2 1 / DR S P G192.168.13.3 GigabitEthernet0/2 00:00:48/00:01:26 v2 1 / DR S P G

R2#show ip pim neighbor PIM Neighbor TableMode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority, P - Proxy Capable, S - State Refresh Capable, G - GenID Capable, L - DR Load-balancing CapableNeighbor Interface Uptime/Expires Ver DRAddress Prio/Mode192.168.12.1 GigabitEthernet0/1 00:06:18/00:01:22 v2 1 / S P G192.168.23.3 GigabitEthernet0/2 00:01:00/00:01:43 v2 1 / DR S P G

R3#show ip pim neighbor PIM Neighbor TableMode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority, P - Proxy Capable, S - State Refresh Capable, G - GenID Capable, L - DR Load-balancing CapableNeighbor Interface Uptime/Expires Ver DRAddress Prio/Mode192.168.13.1 GigabitEthernet0/1 00:01:14/00:01:29 v2 1 / S P G192.168.23.2 GigabitEthernet0/2 00:01:09/00:01:33 v2 1 / S P G

sopra possiamo vedere che tutti i router sono diventati vicini di Pim. La versione predefinita su Cisco IOS è la versione 2. I tempi di scadenza sono il timer di supporto che conta in basso. Ogni volta in cui il router riceve un pacchetto Pim Hello, si ripristinerà a 00:01:45 (105 secondi).

Routing multicast

Diamo un’occhiata al routing multicast Tabelle:

R1#show ip mroute IP Multicast Routing TableFlags: 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 groupOutgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode(*, 224.0.1.40), 00:12:12/00:02:48, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: GigabitEthernet0/2, Forward/Dense, 00:03:06/stopped GigabitEthernet0/1, Forward/Dense, 00:12:12/stopped

R2#show ip mroute IP Multicast Routing TableFlags: 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 groupOutgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode(*, 224.0.1.40), 00:08:33/00:02:35, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: GigabitEthernet0/2, Forward/Dense, 00:03:15/stopped GigabitEthernet0/1, Forward/Dense, 00:08:33/stopped

R3#show ip mroute IP Multicast Routing TableFlags: 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 groupOutgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode(*, 224.0.1.40), 00:03:24/00:02:10, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: GigabitEthernet0/2, Forward/Dense, 00:03:20/stopped GigabitEthernet0/1, Forward/Dense, 00:03:24/stopped

In questo momento noi don Sono in corso qualsiasi traffico multicast ma vediamo un gruppo multicast nelle tabelle, 224.0.1.40. Questo può essere confuso se sei nuovo a Multicast, lasciami spiegare:

Modalità PIM sparse (che discuteremo in altre lezioni) utilizza un RP (Rendezvous Point) e i router Cisco supportano un protocollo chiamato “Auto Discovery RP “per trovare automaticamente il RP nella rete. AUTO RP utilizza questo indirizzo del gruppo multicast, 224.0.1.40.

Modalità Denso PIM non utilizza RPS Quindi non c’è motivo per i nostri router Ascolta l’indirizzo del gruppo 224.0.1.40. Per qualsiasi motivo, non appena si abilita PIM, quindi Autorp è abilitato e il router ascolterà questo indirizzo di gruppo. È possibile ignorare completamente questa voce quando si lavora con la modalità DENSE PIM.

Se si effettua uno sguardo chiuso, puoi vedere che nessuno dei router riceve o inoltra il traffico per questo gruppo:

• L’interfaccia in entrata è null.
• L’elenco dell’interfaccia in uscita mostra interrotta.

Generiamo a noi stessi un po ‘di traffico multicast. Per prima cosa dovrò configurare uno dei padroni di casa per aderire a un gruppo multicast. Configurare H2 per aderire a 239.1.1.1:

H2(config)#interface GigabitEthernet 0/1H2(config-if)#ip igmp join-group 239.1.1.1

Controlla il modo in cui questo influenza la tabella di routing multicast di R2:

R2#show ip mroute 239.1.1.1(*, 239.1.1.1), 00:00:19/00:02:51, RP 0.0.0.0, flags: DC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: GigabitEthernet0/3, Forward/Dense, 00:00:19/stopped GigabitEthernet0/2, Forward/Dense, 00:00:19/stopped GigabitEthernet0/1, Forward/Dense, 00:00:19/stopped

sopra possiamo vedere che R2 ha creato una voce *, 239.1.1.1 per il gruppo multicast 239.1.1.1. In questo momento, tuttavia non riceviamo alcun traffico per questo gruppo, quindi non sappiamo cosa sia la fonte e non possiamo inoltrare nulla.

Lo cambiamo. Il metodo più semplice per generare il traffico multicast è quello di inviare un ping dall’indirizzo del gruppo multicast:

S1#ping 239.1.1.1 repeat 2147483647Type escape sequence to abort.Sending 2147483647, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:Reply to request 0 from 192.168.2.2, 132 msReply to request 1 from 192.168.2.2, 7 msReply to request 2 from 192.168.2.2, 6 ms

sopra puoi vedere che H2 sta rispondendo. Controlliamo le tabelle di routing multicast:

R1#show ip mroute 239.1.1.1IP Multicast Routing TableFlags: 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 groupOutgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode(*, 239.1.1.1), 00:01:16/stopped, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: GigabitEthernet0/2, Forward/Dense, 00:01:16/stopped GigabitEthernet0/1, Forward/Dense, 00:01:16/stopped(192.168.1.1, 239.1.1.1), 00:01:16/00:01:43, flags: T Incoming interface: GigabitEthernet0/3, RPF nbr 0.0.0.0 Outgoing interface list: GigabitEthernet0/1, Forward/Dense, 00:01:16/stopped GigabitEthernet0/2, Prune/Dense, 00:01:15/00:01:43

Discutiamo cosa vediamo sopra:

• r1 sta ricevendo il traffico multicast per 239.1 .1.1 Dal 192.168.1.1 sulla sua interfaccia GI0 / 3 e ha aggiunto questa voce nella sua tabella di routing multicast. Questa è la voce che ho spiegato prima.
• r1 ha inoltrato questo traffico per un minuto e 16 secondi sull’interfaccia GI0 / 1.
• Quando non inoltreremo pacchetti Per un minuto e 43 secondi, questa voce verrà rimossa dalla tabella di routing multicast. Finché continuiamo a ricevere i pacchetti, questo timer verrà reimpostato a tre minuti.
• I flag T significa che stiamo usando l’albero di origine del percorso più breve.
• il vicino RPF per R1 è 0.0.0.0, questo valore è vuoto poiché è un’interfaccia collegata direttamente.
• r1 sta inoltrando il traffico sulla sua interfaccia GI0 / 1 collegata a R2. Lo ha fatto per un minuto e 16 secondi e non c’è scadenza. Continuerà a farlo finché non verrà potato.
• r1 ha smesso di inoltrare il traffico sulla sua interfaccia GI0 / 2 poiché è potato.

Poiché R3 non è interessato a Ricevere questo traffico multicast e ha inviato un messaggio di prugna a R1, chiedendolo di interrompere l’inoltro di questo traffico. Ecco cosa assomiglia a questo messaggio di prugna:

PIM D786877F95″> PIM multicast Denso Pruzzo di pacchetto” width=”973″ height=”423″ srcset=”https://networklessons.com/wp-content/uploads/2016/01/multicast-pim-dense-prune-packet.png 973w, https://networklessons.com/wp-content/uploads/2016/01/multicast-pim-dense-prune-packet-300×130.png 300w, https://networklessons.com/wp-content/uploads/2016/01/multicast-pim-dense-prune-packet-768×334.png 768w” sizes=”(max-width: 973px) 100vw, 973px” class=”aligncenter”>

sopra puoi vedere che questo pacchetto è stato inviato da R3 (192.168.13.3) e destinata al 224.0.0.13 (PIM versione 2).

PIM utilizza un singolo pacchetto per messaggi Join e Propection, in questo pacchetto possiamo vedere che R3 richiede una prugna per 239.1.1.1 dal 192.168.1.1. Questo pacchetto è pensato per il 192.168.13.1.

un’interfaccia è potato per tre minuti e ogni volta che inviamo un messaggio di prugna, questo timer verrà reimpostato. Se Smettiamo di inviare messaggi di prugna, quindi l’interfaccia tornerà in avanti dopo tre minuti.

Vuoi vedere questo pacchetto per te? Dai un’occhiata qui:

Pim Dense Prage Message

Controlliamo r2:

R2#show ip mroute 239.1.1.1(*, 239.1.1.1), 00:03:47/stopped, RP 0.0.0.0, flags: DC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: GigabitEthernet0/3, Forward/Dense, 00:03:47/stopped GigabitEthernet0/2, Forward/Dense, 00:03:47/stopped GigabitEthernet0/1, Forward/Dense, 00:03:47/stopped (192.168.1.1, 239.1.1.1), 00:01:22/00:01:37, flags: T Incoming interface: GigabitEthernet0/1, RPF nbr 192.168.12.1 Outgoing interface list: GigabitEthernet0/2, Prune/Dense, 00:01:22/00:01:37 GigabitEthernet0/3, Forward/Dense, 00:01:22/stopped

Discutiamo cosa abbiamo sopra:

• r2 ha impostato il DC Bandiere per questo gruppo. La D significa che stiamo usando la modalità densa e il C significa che abbiamo un host collegato direttamente che desidera ricevere questo traffico (H2).
• r2 ha ricevuto il traffico dal 192.168.1.1 a 239.1.1.1 sulla sua interfaccia GI0 / 1. Il vicino del RPF è il 192.1 68.12.1 (R1).
• r2 ha smesso di inoltrare il traffico sulla sua interfaccia GI0 / 2 verso R3.
• R2 sta inoltrando il traffico sulla sua interfaccia GI0 / 3 verso H2.

Che dire di r3?

R3#show ip mroute 239.1.1.1(*, 239.1.1.1), 00:01:27/stopped, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: GigabitEthernet0/2, Forward/Dense, 00:01:27/stopped GigabitEthernet0/1, Forward/Dense, 00:01:27/stopped(192.168.1.1, 239.1.1.1), 00:01:27/00:01:32, flags: PT Incoming interface: GigabitEthernet0/1, RPF nbr 192.168.13.1 Outgoing interface list: GigabitEthernet0/2, Prune/Dense, 00:01:27/00:01:32, A

Vediamo:

• r3 sta ricevendo il traffico per 239.1.1.1 Dal 192.168.1.1 sulla sua interfaccia GI0 / 1 che si collega a R1. Il vicino del RPF è il 192.168.13.1.
• La bandiera P significa che questo traffico è stato potato.
• r3 ha potato la sua interfaccia GI0 / 2. La bandiera è una bandiera per Assert Winner.

Quindi la grande domanda … Cos’è un vincitore di Assert?

R2 e R3 sono entrambi collegati al 192.168.23.0/24 Subnet e entrambi stanno ricevendo il traffico da R1.

Immaginiamo di avere un host nella sottorete del 192.168.23.0/24 che vuole ricevere traffico multicast. Quale router inoltrerà questo traffico? R2 o R3? Se entrambi i router in avanti traffico multicast, l’host riceverebbe pacchetti multicast duplicati.