Modul multicast pim dense

În lecția anterioară am discutat despre elementele de bază ale rutei multicast și i a explicat unele dintre diferențele dintre protocoalele de rutare multicast mai mici și rare. Singurul protocol de rutare multicast care este complet acceptat pe dispozitivele Cisco IOS este PIM (Protocol Independent Multicast).

Partea independentă este un pic confuz … PIM depinde 100% pe informațiile din tabelul de rutare unicast, dar Nu contează ce protocol de rutare unicast pe care îl utilizați pentru al umple. Alte protocoale de rutare multicast, cum ar fi DVMRP și MOSPF, nu utilizează tabelul de rutare unicast, dar își construiesc propriile mese.

PIM suportă trei moduri diferite:

• Modul de dense PIM
• Modul PIM rar
• PIM rar-dens mod

Iată diferența cheie dintre modul redus și denne:

• Modul dens: transmitem traficul multicast pe toate interfețele până când un router din aval ne cere să oprim fowarding-ul .

În această lecție, vom face o privire atentă la modul de dense PIM.

PIM DNENS MODE este o metodă de împingere în care folosim copacii bazați pe surse. Ce inseamna asta? Să ne uităm la un exemplu:

Mai sus văd un server video care trimite un pachet multicast spre R1. De îndată ce R1 primește acest pachet multicast, va crea o intrare în tabelul său de rutare multicast, unde stochează adresa sursă și adresa grupului multicast. Apoi va inunda traficul pe toate interfețele sale.

Alte routere care primesc acest pachet multicast vor face același lucru, pachetul multicast este inundat pe toate interfețele lor. Acest lucru provoacă unele probleme, o problemă este că vom avea bucle de rutare multicast. De exemplu, puteți vedea că pachetul pe care R1 îl primește este redirecționat către R2 > r4 > R5 și înapoi la R1 (și invers în jurul). Cum ne confruntăm cu asta? Uitați-vă mai jos:

Fiecare router care nu este interesat de traficul multicast va trimite o prunere la routerul său din amonte, solicitându-l să îl oprească. Router-ul din amonte este routerul în care primim traficul multicast de la, un router din aval este un router în care transmitem traficul multicast. Săgețile roșii de mai sus sunt mesajele prune pe care le vor trimite routerele. Există câteva motive pentru care un router poate trimite un mesaj prune:

• când nu avem gazde conectate direct care sunt interesate să primească traficul multicast.
• Când nu există routere din aval să fie interesate să primească traficul multicast.
• când primim trafic pe o interfață non-RPF.

rpf (redirecționarea traseului invers) este un Verificare suplimentară care ajută la prevenirea buclelor de rutare multicast:

Când un router primește un pachet multicast, acesta va verifica adresa IP sursă a acestui pachet în tabelul de rutare unicast. Va verifica următoarea interfață hop și ieșire pe care o folosim pentru a ajunge la sursă.

• Când pachetul multicast a fost primit pe interfața pe care o folosim pentru a ajunge la sursă, verificarea RPF reușește.
• Când pachetul multicast a fost primit pe o altă interfață, acesta nu reușește verificarea RPF și pachetul este aruncat.

Rezultatul final va arăta astfel:

Avem acum o topologie frumoasă curată în care traficul multicast este inundat de la R1 la R2 > r6 > h1. Acest comportament de inundații și prune vor avea loc la fiecare trei minute.

Noi numim această topologie arborele de distribuție bazate pe surse sau SPT (cel mai scurt copac de cale). Uneori este numit și arborele sursă:

• arborele definește calea de la sursă la receptorul (receptorul).
• Sursa este rădăcina copacului nostru.
• Routerele dintre care sunt traficul sunt nodurile.
• subrețele cu receptoare sunt ramurile și frunzele copacului.

În funcție de Pe grupurile sursă și / sau multicast pe care le folosim, ați putea avea mai mult de un copac sursă în rețeaua dvs. Odată ce ne uităm la configurație, veți vedea că vom folosi notația pentru a se referi la un anumit copac sursă:

• s: adresa sursă
• g: multicast Adresa grupului.

Acum aveți o idee despre modul în care este vorba de Modul PIN, să vedem cum se pare că vom avea niște routere reale?

configurare

Vom folosi următoarea topologie pentru această demonstrație:

de mai sus Avem un server video pe partea stângă, care va fi sursa traficului nostru multicast. H2 și H3 sunt două dispozitive gazdă care doresc să primească traficul multicast.R1, R2 și R3 vor fi configurate pentru a utiliza modul PIN dens.

Routing Unicast

Mai întâi vom configura un protocol de rutare pe toate routerele, voi alege OSPF. Toate interfețele vor fi anunțate:

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

iv id = „CE0A918917”

acum Putem să ne concentrăm pe configurația multicast.

Modul PIM dens

Routing multicast este dezactivat în mod implicit pe routerele Cisco IOS, astfel încât trebuie să le permitem:

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

Acum putem configura PIM. Să începem cu R1:

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

De îndată ce activez modul de dense PIN pe interfață, routerul nostru va începe să trimită pachete PIM Hello. Iată cum arată în wireshark:

de mai sus puteți vedea tipul pachetului (Hello ) Și arată, de asemenea, timpul de așteptare. Din orice motiv, Wireshark (versiunea 2.0.1) îmi arată o valoare de 1, dar implicit este de 105 secunde. Dacă doriți să aruncați o privire la acest pachet dvs., iată-l pe Cloudshark captura:

PIM DNENS MODE HELLO PACKET

Afișează păstrarea corectă de 105 secunde.

Să permitem lui Pim dens pe R2, de asemenea:

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

de îndată ce facem acest lucru, R1 și R2 vor deveni vecini de când primesc fiecare PIM Hello Pachete. Dacă ei continuă să le primească înainte de expirarea temporizatorului de așteptare, atunci ei se vor continua să se vadă reciproc ca vecini PIM.:

iv id = „5933DA2EF”

Să permitem toate celelalte interfețe . De asemenea, trebuie să activați PIM pe interfețele care se conectează la dispozitivele gazdă:

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 dens vecinii

hai să ne asigurăm că toate routerele au devenit vecini:

iv id = „bc4cc09d5c”

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

de mai sus putem vedea că toate routerele au devenit vecini PIM. Versiunea implicită pe Cisco IOS este versiunea 2. Timpul de expirare este cronometrul de așteptare care numără în jos. De fiecare dată când routerul primește un pachet PIM Hello, se va reseta la 00:01:45 (105 secunde).

rutare multicast

hai să aruncăm o privire la rutarea multicast Mese:

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

iv id = „39178CF28c”

În acest moment nu suntem „Continuarea unui trafic multicast, dar vedem un grup multicast în tabele, 224.0.1.40. Acest lucru poate fi confuz dacă sunteți nou la multicast, permiteți-mi să explic: Modul spatric PIM (pe care îl vom discuta în alte lecții) utilizează un RP (Rendezvous punct) și routere Cisco susțin un protocol numit „Auto RP Discovery „pentru a găsi automat rp în rețea. Auto RP utilizează această adresă de grup multicast, 224.0.1.40.

PIM Dense Mode nu folosește RPS, astfel încât nu există niciun motiv pentru routerele noastre Ascultați adresa grupului de 224.0.1.40. Din orice motiv, de îndată ce activați PIM, atunci Autorp este activat și routerul va asculta această adresă de grup. Puteți ignora această intrare complet când lucrați cu modul de dense PIM.

Dacă faceți o privire apropiată, atunci puteți vedea că niciuna dintre routere primește sau redirecționează traficul pentru acest grup:

• Interfața de intrare este nulă.
• Lista de interfață de ieșire s-au oprit.

Să generăm un trafic multicast pe noi înșine. Mai întâi va trebui să configurez unul dintre gazdele să se alăture unui grup multicast. Să configuram H2 să se alăture 239.1.1.1:

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

Să verificăm cum influențează această masă de rutare multicast a 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

de mai sus putem vedea că R2 a creat un *, 239.1.1.1 intrare pentru grupul multicast 239.1.1.1. În acest moment, însă nu primim niciun trafic pentru acest grup, așa că nu știm ce este sursa și nu putem transmite nimic.

Să schimbăm asta. Cea mai simplă metodă de a genera traficul multicast este de a trimite o ping de la adresa grupului 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

de mai sus puteți vedea că H2 răspunde. Să verificăm tabelele de rutare 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

Să discutăm ceea ce vedem mai sus:

• R1 primește trafic multicast pentru 239.1 .1.1 din 192.168.1.1 pe interfața GI0 / 3 și a adăugat această intrare în tabelul său de rutare multicast. Aceasta este intrarea pe care am explicat-o înainte.
• R1 a transmis acest trafic timp de un minut și 16 secunde pe interfața GI0 / 1.
• Când nu transmitem pachete timp de un minut și 43 de secunde, această intrare va fi scoasă din tabelul de rutare multicast. Atâta timp cât continuăm să primim pachete, acest cronometru va fi resetat la trei minute.
• steagurile T înseamnă că folosim cel mai scurt copac sursă de cale.
• RPF vecin pentru r1 este 0.0.0.0, această valoare este goală, deoarece este o interfață conectată direct.
• R1 redirecționează traficul pe interfața GI0 / 1 care este conectată la R2. A făcut acest lucru timp de un minut și 16 secunde și nu există nici o expirare. Va continua să facă acest lucru până se prăbușește.
• R1 a încetat să redirecționeze traficul pe interfața GI0 / 2, deoarece este tăiată.

Deoarece R3 nu este interesat de Primirea acestui trafic multicast și a trimis un mesaj prune la R1, cerându-l să oprească transmiterea acestui trafic. Iată ce arată acest mesaj prune:

de mai sus puteți vedea că acest pachet a fost trimis de R3 (192.168.13.3) și destinată lui 224.0.0.13 (versiunea PIM 2).

PIM utilizează un singur pachet pentru conectarea și prune, în acest pachet putem vedea că R3 solicită o prune pentru 239.1.1.1 din 192.168.1.1. Acest pachet este destinat pentru 192.168.13.1.

O interfață este tăiată timp de trei minute și de fiecare dată când trimitem un mesaj prune, acest timer va fi resetat. Dacă Oprim trimiterea mesajelor Prune, apoi interfața se va întoarce în redirecționare după trei minute.

Doriți să vedeți acest pachet pentru dvs.? Aruncă o privire aici:

PIM DNENS PRUNE MESAJ

Să verificăm 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

hai să discutăm ceea ce avem mai sus:

• r2 a stabilit dc Steaguri pentru acest grup. D înseamnă că folosim modul dens și c înseamnă că avem o gazdă conectată direct care dorește să primească acest trafic (H2).
• R2 a primit trafic din 192.168.1.1 la 239.1.1.1 pe interfața GI0 / 1. Vecinul RPF este 192.1 68.12.1 (R1).
• R2 a încetat să redirecționeze traficul pe interfața GI0 / 2 spre R3.
• R2 este traficul de trafic pe interfața GI0 / 3 spre H2.

Cum rămâne cu 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

hai să vedem:

• R3 primește traficul 239.1.1.1 din 192.168.1.1 pe interfața GI0 / 1 care se conectează la R1. Vecinul RPF este 192.168.13.1.
• pavilionul P înseamnă că acest trafic a fost tăiat.
• R3 a tăiat interfața GI0 / 2. Un pavilion reprezintă câștigătorul ASSERT.

atât de mare întrebare … Ce este un câștigător de afirmație?

R2 și R3 sunt conectate la 192.168.23.0 / 24 Subnet și ambii primesc trafic de la R1.

Să ne imaginăm că avem o gazdă în subrețea din 192.168.23.0 / 24, care dorește să primească trafic multicast. Ce router va transmite acest trafic? R2 sau R3? Dacă ambele routere oferă traficul multicast, atunci gazda ar primi pachete multicast duplicat.