Multicast PIM Mode dens

Contingut de la lliçó

En la lliçó anterior, vam parlar dels conceptes bàsics de l’encaminament de multidifusió i Va explicar algunes de les diferències entre els protocols d’encaminament multicast dens i escàs. L’únic protocol d’encaminament multicast que està totalment compatible amb els dispositius CISCO iOS és PIM (Protocol Independent MultiCast).

La part independent és una mica confusa … PIM depèn del 100% de la informació en la taula d’encaminament unicast però No importa quin protocol d’encaminament unicast utilitzeu per omplir-lo. Altres protocols d’encaminament multicast com DVMRP i MOSPF No utilitzen la taula d’encaminament unicast, sinó que construeixen les seves pròpies taules.

PIM suporta tres modes diferents:

  • PIM Dense mode
  • PIM MODE escàs
  • PIM MODE escarella-densa

Aquí teniu la diferència clau entre el mode escàs i dens:

  • Mode dens: reenvia el trànsit de multicast a totes les interfícies fins que un router avall ens demana que deixi de deixar de fer-ho.
  • Mode escàs: no reenviem trànsit multicast a cap interfície fins que un router descendent ens demana .

En aquesta lliçó, anem a mirar molt de prop el mode PIM dens.

El mode PIM dens és un mètode push on utilitzem arbres basats en fonts. Què vol dir això? Vegem un exemple:

multicast PIM densa inundacions

A dalt veiem un servidor de vídeo que envia un paquet de multicast cap a R1. Tan aviat com R1 rep aquest paquet multicast, crearà una entrada en la seva taula d’encaminament multicast on emmagatzema l’adreça d’origen i l’adreça del grup multicast. A continuació, inundarà el trànsit a totes les seves interfícies.

Altres routers que reben aquest paquet multicast faran el mateix, el paquet multicast està inundat en totes les seves interfícies. Això provoca alguns problemes, un problema és que tindrem bucles d’encaminament multicast. Per exemple, podeu veure que el paquet que rep R1 es reenvia a R2 > r4 r5 i de tornada a R1 (i l’altra manera al voltant). Com ens ocupem d’això? Fer una ullada a continuació:

Multicast PIM densa mode de poda

Cada router que no està interessat en el trànsit multicast enviarà una pruna al seu router ascendent, demanant-li que deixi de reenviar-lo. El router ascendent és el router on rebem trànsit de multicast, un router aigües avall és un router on reenviem el trànsit multicast. Les fletxes vermelles superiors són els missatges de prunes que enviaran els routers. Hi ha un parell de raons per les quals un router pot enviar un missatge de pruna:

  • quan no tenim cap amfitrió connectat directament que estiguin interessats a rebre el trànsit de multicast.
  • Quan cap rutó descendent estigui interessat en rebre el trànsit de multicast.
  • quan rebem trànsit en una interfície no rpf.

rpf (reenviament de camins inversos) és un Comprovació addicional que ajuda a prevenir bucles d’encaminament multicast:

Quan un router rep un paquet multicast, comprovarà l’adreça IP d’origen d’aquest paquet a la taula d’encaminament unicast. Comproveu la següent interfície de salt i sortint que utilitzem per arribar a la font.

  • Quan es va rebre el paquet multicast a la interfície que utilitzem per arribar a la font, la comprovació de RPF té èxit.
  • Quan es va rebre el paquet multicast en una altra interfície, falla la comprovació de RPF i el paquet es descarta.

El resultat final es veurà així:

Multicast PIM densa Mode arbre font

Ara tenim una bonica topologia neta on el trànsit multicast està inundat de R1 a R2 r6 h1. Aquest comportament inundable i de podar es produirà cada tres minuts.

Ens anomenem aquesta topologia l’arbre de distribució o SPT (arbre de ruta més curta). De vegades també es diu l’arbre de la font:

  • L’arbre defineix el camí de la font al receptor (s).
  • La font és l’arrel del nostre arbre.
  • Els routers entre els quals estan reenviament de trànsit són els nodes.
  • Les subxarxes amb receptors són les branques i les fulles de l’arbre.

depenent Als grups d’origen i / o multicast que utilitzem, és possible que tingueu més d’un arbre de font a la vostra xarxa. Un cop mirem la configuració, veurem que utilitzem la notació per referir-nos a un arbre de font concret:

  • s: l’adreça font
  • g: la multicast Adreça de grup.

Ara teniu una idea de què es tracta de mode pim densa, anem a veure el que sembla en alguns routers reals?

configuració

Utilitzarem la següent topologia per a aquesta demostració:

Multicast pim densa topologia

A dalt tenim un servidor de vídeo A la part esquerra que serà la font del nostre trànsit multicast. H2 i H3 són dos dispositius amfitrions que volen rebre el trànsit de multicast.R1, R2 i R3 es configuraran per utilitzar el mode PIM dens.

Enrutament unicast

Primer configurarem un protocol d’encaminament a tots els routers, triaré OSPF. Es publiquen totes les interfícies:

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

ara Podem centrar-nos en la configuració de la multicast.

Mode pim dens

L’encaminament multicast està desactivat per defecte als routers de Cisco iOS, de manera que hem d’habilitar-la:

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

Ara podem configurar pim. Comencem amb R1:

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

Tan aviat com permeto el mode pim dens a la interfície que el nostre router començarà a enviar paquets pim hola. Això és el que sembla a Wireshark:

Multicast pim dens hola paquets

A dalt es pot veure el tipus del paquet (hola) ) I també mostra el temps de retenció. Per qualsevol motiu, Wireshark (versió 2.0.1) em mostri un valor d’1, però el valor per defecte és de 105 segons. Si voleu fer una ullada a aquest paquet vosaltres mateixos, aquí teniu la captura de clousshark:

Pim densa mode hola paquets

Mostra el temps de suport correcte de 105 segons.

Activem també PIM dens a R2:

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

Tan aviat com fem això, R1 i R2 es convertiran en veïns, ja que reben els altres pim hola Paquets. Si continuen rebent-los abans que el temporitzador de Holdown hagi caducat, seguiran veient-se com a veïns PIM .:

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

Anem a totes les altres interfícies . També haureu d’habilitar PIM a les interfícies que es connectin a dispositius d’amfitrió:

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 densos veïns

Assegurem-vos que tots els routers s’han convertit en veïns:

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

A dalt podem veure que tots els routers s’han convertit en veïns pim. La versió predeterminada a Cisco IOS és la versió 2. Els temps de caducitat són el temporitzador de HoldDown que es compta. Cada vegada que el router rep un paquet PIM Hello, es restablirà a 00:01:45 (105 segons).

Enrutament multicast

Fem una ullada a l’encaminament de la multicast Taules:

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

En aquest moment “Tenir algun trànsit multicast continuat, però veiem un grup multicast a les taules, 224.0.1.40. Això pot resultar confús si sou nous per a multicast, deixeu-me explicar:

Mode escàs PIM (que discutirem en altres lliçons) utilitza un RP (punt de rendezvous) i els routers Cisco donen suport a un protocol anomenat “Auto RP Discovery “Per trobar automàticament el RP a la xarxa. Auto RP utilitza aquesta adreça de grup multicast, 224.0.1.40.

El mode PIM dens no utilitza RPS perquè no hi ha cap raó per als nostres routers Escolteu l’adreça del grup 224.1.40. Per qualsevol motiu, tan aviat com hàgiu activat PIM, Autorp també està habilitat i el router escoltarà aquesta adreça de grup. Podeu ignorar completament aquesta entrada quan esteu treballant amb el mode PIM dens.

Si es fa molt de prop, es pot veure que cap dels routers està rebent o reenviament de trànsit per a aquest grup:

  • La interfície entrant és nul.
  • La llista d’interfície de sortida es va aturar.
Podeu veure que la taula d’encaminament multicast té moltes banderes diferents. No et preocupis massa De moment, discutirem alguns d’ells en altres lliçons.

Generem un trànsit multicast a nosaltres mateixos. Primer hauré de configurar un dels amfitrions per unir-vos a un grup multicast. Configurem H2 per unir-vos a 239.1.1.1:

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

Anem a comprovar com això influeix en la taula d’encaminament multicast de 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

A dalt podem veure que R2 ha creat una entrada *, 239.1.1.1 per al grup multicast 239.1.1.1. En aquest moment, però no rebem cap trànsit per a aquest grup, de manera que no sabem quina és la font i no podem reenviar res.

Anem a canviar això. El mètode més senzill per generar trànsit multicast és enviar un ping de l’adreça del grup 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

A dalt es pot veure que h2 respon. Comproveu les taules d’encaminament de 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

Anem a parlar del que veiem a dalt:

  • R1 està rebent un trànsit multicast per 239,1 .1.1 De 192.168.1.1 a la seva interfície GI0 / 3 i ha afegit aquesta entrada a la seva taula d’encaminament multicast. Aquesta és l’entrada que vaig explicar abans.
  • R1 ha estat reenovant aquest trànsit durant un minut i 16 segons a la interfície GI0 / 1.
  • Quan no enviem cap paquet Durant un minut i 43 segons, aquesta entrada s’eliminarà de la taula d’encaminament de la multicast. Mentre seguim rebent paquets, aquest temporitzador es restablirà a tres minuts.
  • Les banderes T vol dir que estem utilitzant l’arbre de la font més curta.
  • El veí RPF per a R1 és 0.0.0.0, aquest valor està buit ja que és una interfície connectada directament.
  • R1 està reenviament de trànsit a la seva interfície GI0 / 1 que està connectada a R2. Ha estat fent això durant un minut i 16 segons i no hi ha caducitat. Seguirà fent això fins que es pogui.
  • R1 ha deixat de reenviar el trànsit a la seva interfície GI0 / 2, ja que és poda.

ja que R3 no està interessat Rebent aquest trànsit multicast i ha enviat un missatge de podar a R1, demanant que deixi de reenviar aquest trànsit. Això és el que sembla aquest missatge de prune:

Pim densa multicast Pim densa

A dalt es pot veure que aquest paquet va ser enviat per R3 (192.168.13.3) i destinats a 224.0.0.13 (PIM versió 2).

PIM utilitza un sol paquet per unir-se i els missatges de podar, en aquest paquet podem veure que R3 sol·licita una pruna per 239.1.1.1 De 192.168.1.1. Aquest paquet està destinat a 192.168.13.1.

a pim versió 1 una interfície es podrà podar durant tres minuts. Després d’aquests tres minuts, el trànsit es tornaria a enviar fins que enviem un altre missatge de podar. Aquest comportament “inundació i podar” és bastant ineficient, de manera que a PIM versió 2 utilitzeu alguna cosa anomenada “Actualització de l’estat”. Els missatges de poda s’envien periòdicament. Cada vegada que rebem un missatge de pruna, el temporitzador de podar es restableix a tres minuts que impedeix el comportament “inundació i podar”.

Segons la vostra versió iOS, és possible que l’actualització de l’estat estigui desactivada per defecte. Podeu activar-lo Amb l’ordre ip pim state-refresh origination-interval
.

Una interfície és poda durant tres minuts i cada vegada que enviem un missatge de pruna, aquest temporitzador es restablirà. Si Aturem l’enviament de missatges de podar, la interfície es tornarà a reenviar després de tres minuts.

Voleu veure aquest paquet per a vosaltres mateixos? Fes una ullada aquí:

Pim dens Missatge de pruna

Anem a comprovar 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

Anem a parlar del que tenim per sobre:

  • R2 ha definit el DC Banderes d’aquest grup. El D significa que estem utilitzant el mode dens i el C significa que tenim un host connectat directament que vol rebre aquest trànsit (H2).
  • R2 ha anat rebent trànsit des de 192.168.1.1 a 239.1.1.1 a la seva interfície GI0 / 1. El veí RPF és de 192,1 68.12.1 (R1).
  • R2 ha deixat de reenviar el trànsit a la seva interfície GI0 / 2 cap a R3.
  • R2 està reenviament de trànsit a la seva interfície GI0 / 3 cap a H2.

Què hi ha de 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

Vegem:

  • R3 està rebent trànsit 239.1.1.1 De 192.168.1.1 a la seva interfície GI0 / 1 que es connecta a R1. El veí RPF és el 192.168.13.1.
  • La b forma de p significa que aquest trànsit ha estat podat.
  • R3 ha podat la seva interfície GI0 / 2. La bandera suposa el guanyador d’afirmació.

Així que la gran pregunta … Què és un guanyador de l’assert?

R2 i R3 estan connectats al 192.168.23.0/24 Subnet i tots dos estan rebent trànsit de R1.

Imaginem que tenim un amfitrió de la subxarxa 192.168.23.0/24 que vol rebre trànsit multicast. Quin router reenviarà aquest trànsit? R2 o R3? Si els dos routers avancen el trànsit multicast, l’amfitrió rebrà paquets duplicats multicast.

Deixa un comentari

L'adreça electrònica no es publicarà. Els camps necessaris estan marcats amb *