Protocollum PIM protocollum est copia protocolla in retis inter iter itineris transmittendi. Necessitudines vicinitatis aedificantur eodem modo ac in casu progressionis dynamicorum protocolla. PIMv2 mittit Salve nuntios singulas 30 seconds ad inscriptionem multicastam reservatam 224.0.0.13 (All-PIM-Routers). Epistula contine Timers - plerumque = 3.5* Salve Timer, id est, 105 secundis defaltis.
PIM duobus modis principalibus operandi utitur - Modus densus et sparsus. Densa sit amet modus.
Source-Substructio Arborum Distributio.
Modus densi-modus opportune uti videtur in magno numero clientium diversarum coetuum multicastrarum. Cum iter commercium multicastrium recipit, primum illud est ob regulam RPF. RPF - haec regula ad reprimendam fontem multicasti cum mensa unicast excitanda adhibita est. Necesse est ut negotiatio ad interfacem post perveniat qua haec hospes latet secundum versionem tabulae unicast excitantis. Haec mechanismus quaestionem solvit de ansa facta in transmissione multicast.
R3 cognoscet fontem multicastum (Source IP) e nuntio multicasti et duos fluxiones ex R1 et R2 utentem mensa unicast agnoscet. Rivus ab interfacie ad mensam (R1 ad R3) monstratus ulterius transmittetur, et rivus e R2 demittetur, cum ut ad fontem multicastum perveniat, fasciculos per S0/1 mittere debes.
Quaeritur, quid fit, si duas aequivalentes vias cum eodem metrico habeas? Hoc in casu, iter proximum ex his itineribus salit. Quicunque IP superiorem vincit. Si mores huiusmodi mutare debes, EMP uti potes. More details .
Post RPF regulam inhibito, iter fasciculum multicastanum mittit omnibus vicinis suis PIM, excepto illo a quo fasciculus receptus est. Aliae PIM iter itineris hunc processum repetunt. Semita quam fasciculus multicasti a fonte ad extremum recipientes sumit arborem format quae vocatur fons distributionis arboris, arbor brevissima (SPT), fons arboris. Tribus nominibus unum elige.
Quam quaestionem solvere non nulli iter in multicasti amnis dimiserunt neque est, qui mitteret, sed iter ad eum mittit. Puta machina ad hoc inventa est.
Puta Nuntius.
Exempli gratia, R2 perget multicastum ad R3 mittere, quamvis R3 secundum regulam RPF deponat. Cur alveum oneratis? R3 mittit PIM Puta Nuntius et R2, hoc nuntio accepto, interfaciem S0/1 removebit ab indicem interfaciendi huius fluxus, indicem interfaciendi ex quibus haec negotiatio mittenda est.
Haec definitio formalior est nuntius PIM Puta:
Nuntium PIM Prune ab uno iter ad alterum iter mittitur ut alterum iter moveat ut nexum removeat in qua Puta a certo (S,G) SPT recipitur.
Recepta Puta nuntium, R2 timoris Putaminis ad 3 minutas ponit. Post tres minutas commercium iterum incipiet mittere donec alium Puta nuntium recipiat. Haec in PIMv1.
Et in PIMv2 timor Renovare rem publicam adiecit (60 seconds per defaltam). Quamprimum nuntius Prune e R3 missus est, hic timor incepit R3. Hoc timore elapso, R3 nuntium Civitatis Renovare mittet, quod 3-minutum Prune Timer in R2 huic sodalitati reddet.
Causae mittendae putamen nuntium:
- Cum fasciculus multicast defecerit, RPF sequatur.
- Cum clientibus localiter coniuncti non sunt, qui catervam multicastam petiverunt (IGMP Join) nec desunt PIM finitimi ad quos negotiatio multicast mitti potest (Interface Non-puta).
Insere Nuntius.
Fingamus R3 mercaturam noluisse ex R2, Prune missam esse et multicastam ex R1. Subito autem canalis inter R1-R3 cecidit et R3 sine multicasti relictus est. Exspectare potes 3 minuta donec putaveris Timer in R2 exspirat. 3 minuta longa exspectatio est, ut non exspectandum, nuntium mittere debes qui hunc interfaciem S0/1 ad R2 e statu putationis statim afferet. Haec epistula nuntius insitus erit. Accepto insito nuntio, R2 respondebit cum Graft-ACK.
Prune Override.
Intueamur hoc schemate. R1 emissarii multicast ad segmentum cum duobus itineribus. R3 accipit et commercium radiophonicum, R2 accipit, sed neminem habet ad mercaturam iaciendam. Putabis nuntium ad R1 in hac parte mittit. R1 Fa0/0 e indice removere et in hoc segmento diffundere desinas, sed quid R3 fiet? Et R3 in eodem segmento, etiam hoc nuntium accepit a Prune et tragoediam de situ intellexit. Priusquam R1 emittere desinat, timerarium 3 secundis ponit et post 3 secundis evulgationem cessabit. 3 seconds - hoc prorsus quantum temporis R3 habet ut multicast non amittat. Ideo R3 mittit Pim Join nuntium huius coetus quam primum, et R1 non iam cogitat de mora evulgandas. De nuntiis infra coniunge.
Nuntius assere.
Hanc condicionem fingamus: duo itinera ad unam retis statim emittunt. Recipiunt eundem rivum a fonte, et utrumque spargunt ad idem retis post medium e0. Ergo determinare oportet quis sit unus et solus in hoc retis radiophonicus. Nuntios asseres ad hoc adhibitos esse. Cum R2 et R3 duplicationem multicast negotiationis deprehendunt, hoc est, R2 et R3 multicastam accipiunt, ut ipsi iaciantur, iter itineris intellegunt aliquid hic esse falsum. Hoc in casu, iter itineris miserunt nuntios Assert, qui includunt distantiam administrativam et viam metricam quacum multicasti fons attingitur - 10.1.1.10. Victor enira talis est;
- Vna inferior AD.
- Si AD aequales sunt, qui metricam inferiorem habet.
- Si aequalitas hic sit, ille qui superiorem IP habet in reticulo ad quod multicast iaciant.
Victor huius suffragii fit iter itineris designatum. Pim Hello is also used to select DRs. In principio articuli, nuntius in PIM Hello monstratus est, campum DR ibi videre potes. Una cum summa IP inscriptione in hac pagina vincit.
Signum utile:
MROUTE Table.
Post initialem inspiciendum quomodo opera PIM protocollo, intellegere oportet quomodo opus sit cum multicast fusa mensa. Tabulae mroute informationes de thesauris quae rivi a clientibus petiti sunt et quae rivi a servientibus multicast fluunt.
Exempli gratia, cum relatio IGMP Sodalitas seu PIM Join recipitur in aliquo interfacie, index generis (*, G) tabulae excitandae additur:
Hic ingressum significat petitionem negotiationis acceptae cum inscriptione 238.38.38.38. Vexillum DC significat quod multicast operabitur in modo denso et C significat recipiens directe coniunctum itineris, hoc est, iter acceptum IGMP Sodalitas Report et PIM Join.
Si typus exstat (S,G) significat nos rivum multicastum habere;
In agro S - 192.168.1.11, inscriptionem electronicam multicasti fontis IP descripsimus, haec est quae a RPF regula cohibebitur. Si problemata sunt, primum quod debes facere est mensa unicast perscriptio itineris ad fontem. In ineunte agro interface, indicat interfacem cui multicast recipitur. In tabula unicast fusa, iter ad fontem referri debet ad interfaces hic specificatas. Interfaces Exitus dat speciem ubi multicast redirected erit. Si vacua sit, nulla petita pro hoc negocio iter itineris non accepit. Plura de omnibus vexillis possunt inveniri .
PIM Sparse-modus.
Consilium-modium Sparse est oppositum modo densi. Cum Sparse-modus multicast commercium acceperit, tantum commercium mittet per interfaces ubi petitiones huius fluxus fuerunt, exempli gratia Pim Join or IGMP Referre epistulas quae hoc negotiationis postulabant.
Similia elementa pro SM et DM:
- Necessitudo vicinitatis aedificatur eodem modo ac in PIM DM.
- R. P. Regula operatur.
- DR similis lectio est.
- Mechanismus Putaminis Overrides et nuntii similes asserimus.
Ad regendum qui, ubi et quales negotiationum multicastarum in retiaculis opus est, commune notitiarum centrum opus est. Centrum nostrum erit punctum Rendezvous (RP). Quicumque volet negotiationem multicastam vel aliquem ex fonte multicasti accipere incepit, tunc ad RP mittit.
Cum RP multicast mercaturam acceperit, eam ad itinera mittet qui antehac negotiationem hanc petierunt.
Cogitemus topologiam ubi RP est R3. Quamprimum R1 commercium ex S1 accipit, hunc fasciculum multicastanum in unicast PIM Register nuntium encapsulat et ad RP mittit. Quomodo scit qui sit RP? In hoc casu, configuratur stabiliter, et postea de dynamica RP configuratione loquemur.
ip pim rp-electronica 3.3.3.3
Videbit RP - fuitne informationes ab aliquo qui hoc negotium accipere vellet? Demus non erat. Tunc RP R1 mittet nuntium R1 a PIM Register-Stop, quod significat multicast nemo indigere, adnotatione negatur. R1 non multicast mittet. Sed multicastus fons exercitum mittet, ut R60, recepto Register-Stop, incipiet timor subcriptio-suppressionis 5 secundis aequalem. 1 seconds antequam timer hoc exspirat, RXNUMX mittet nuntium inanem mandare cum frenum Null-Register (id est, sine fasciculo multicasti encapsulato) versus RP. R. P. Invicem sic aget;
- Si non fuerunt recipientes, respondebit cum nuntio actis mandare.
- Si recipientes apparent, non respondebit ei aliquo modo. R1, cum recusatio non recepta intra 5 secundas subcriptio, laetus erit et nuntium registri mittet cum multicasti encapsulato ad RP.
Figuratum videmur quomodo multicast RP attingit, nunc conetur respondere quomodo RP negotiatio recipientibus liberat. Hic necesse est novum conceptum inducere - arbor radicis-path (RPT). RPT est arbor in RP radicata, versus recipientes crescens, inter PIM-SM iter faciens. RP creat eam accipiendo PIM nuntios coniunge et novum ramum ad arborem addit. Omne itaque iter amni facit. Regula generalis sic spectat:
- Cum iter itineris PIM-SM accipit PIM Nuntium in quolibet interfacie praeter interfaciem post quem RP latet, novum ramum ad arborem addit.
- Ramus etiam additur, cum iter itineris PIM-SM recipiat Relatione IGMP Sodalitas ex hospite directe connexo.
Fingamus nos clientem multicastum in R5 iter itineris pro sodalitate 228.8.8.8. Quamprimum R5 IGMP Sodalitas Renuntiatio ab hospite accipit, R5 PIM in directionem RP mittit, et ipsa interfaciem addit ligno spectanti ad exercitum. Deinde R4 recipit PIM Join ex R5, addit interfaciem Gi0/1 ad arborem et PIM junge in directione RP. Denique RP ( R3 ) recipit PIM Join et Gi0/0 ad arborem addit. Sic recipiens multicast relatus est. R3-Gi0/0 β R4-Gi0/1 β R5-Gi0/0 arborem aedificamus.
Post hoc, PIM Join mittetur ad R1 et R1 commercium multicasti mittendum incipiet. Gravis est notare quod si exercitus negotiationem postulavit antequam multi iaci coepti essent, RP non mittet PIM Join et nihil R1 omnino mitteret.
Si subito dum multicast mittitur, hospes recipere desiit, statim ac RP PIM Prune in Gi0/0 accipit, statim PIM Register-Sistere directe ad R1 mittet, et deinde PIM Prune. nuntius per Gi0/1 interface. PIM Register-stop via unicast mittitur ad electronicam e qua PIM Register venit.
Ut supra diximus, quamprimum iter itineris ad PIM alii mittit, exempli gratia R5 ad R4, deinde R4 recordum additur;
Et timer incepit R5 constanter reset hoc timoris PIM nuntiis constanter coniunge, alioquin R4 a indice exitu excludetur. R5 mittet singulas 60 PIM nuntios coniunge.
Arbor brevissima-Path Switchover.
Interfaciem inter R1 et R5 addemus et videbimus quomodo negotiatio cum hac topologia fluit.
Demus commercium missum et receptum secundum antiquum schema R1-R2-R3-R4-R5, et hic inter R1 et R5 interfaciem contexuimus et figuravimus.
Primum omnium, mensam unicast excitandam in R5 reficere debemus et nunc retis 192.168.1.0/24 per R5 Gi0/2 interface pervenit. Nunc R5, accepto multicasti in interface Gi0/1, intelligit regulam RPF non esse contentam et magis logicum esse multicastum in Gi0/2 recipere. Ab RPT disiungere debet et arborem breviorem quae Arbor brevissima appellata est (SPT). Hoc facere, PIM Join to R0 per Gi2/1 mittit et R1 multicastum etiam per Gi0/2 mittere incipit. Nunc R5 subscribere debet ex RPT ne duo exemplaria recipiant. Ad hoc faciendum, Puta nuntium mittit qui fontem IP inscriptionis indicans et peculiarem particulam - RPT-bit inserens. Hoc significat quod mercaturam me mittere non debes, hic arborem meliorem habeo. RP etiam PIM Puta nuntios ad R1 mittit, sed nuntium actis mandare non mittit. Aliud pluma: R5 nunc continenter mittet PIM Prune ad RP, ut R1 pergit PIM Register ad RP minutatim mittere. Donec nullae sunt novae qui huic negotiationi deerant, RP recusabit. R5 notificat RP quod multicast per SPT recipiat.
Quaerere RP Edidit.
Auto- RP.
Haec ars proprietatis e Cisco est et non peculiariter popularis est, sed adhuc vivit. Auto-RP operatio duobus principalibus gradibus consistit:
1) RP mittit RP-Nuntia nuntios in inscriptione reservata - 224.0.1.39, se RP declarans vel pro omnibus vel pro certis coetibus. Haec epistula minutatim mittitur.
2) An RP tabularum faciendarum actor requiratur, qui RP-Inventum nuntios mittet indicans pro quibus coetibus RP audiendi erunt. Ex hoc nuntio PIM regulares iter itineris sibi RP determinabunt. Agens Mapping esse potest vel ipsum iter RP vel iter separatum PIM. RP-Inventio electronica mittitur 224.0.1.40 cum horario unius minuti.
Inspice processum planius:
R3 ut RP configurare:
IP pim mitte-rp annunciate loopback 0 scope 10
R2 ut tabularum faciendarum;
IP pim mitte-rp-inventio loopback 0 scope 10
Et in omnibus aliis exspectabimus RP per Auto- RP:
IP pim auditorem autorp
Cum R3 configuramus, incipiet RP-Annuntiate:
Et R2, cum destinata agente instituto, nuntium RP-Annuntiate exspectare incipiet. Solum cum unum saltem invenit RP, incipiet mittere RP-Inventio:
Hoc modo, quam primum iter itineris ordinarii (PIM RP Auditor) hunc nuntium accipient, scient ubi RP quaeram.
Una principalium problematum cum Auto-RP est, quod ut RP-Annuntia et RP-Inventa mandata accipias, debes PIM mittere ad conciones 224.0.1.39-40, et ut mittas, debes scire ubinam. RP hic sita est. Classicum pullum et ovum dubium. Ad hanc quaestionem solvendam inventa PIM Sparse-Dense-Modo est. Si iter RP nescit, agit in modo densi, si se habet, in modo sparsim. Cum PIM Sparse-modus et mandatum audientis ip pim autorp figurantur in interfationibus iter itineris regularium, iter in modo denso operabitur tantum ad multiplicandum directe ab auto-RP protocollo (224.0.1.39-40).
BootStrap Router (BSR).
Hoc munus simile cum Auto-RP operatur. Unusquisque RP nuntium mittit ad procuratorem destinatum, qui notitias destinata colligit ac deinde omnes alios iter narrat. Similiter processus Auto-RP describemus:
1) Configuramus olim R3 candidatum esse RP, cum mandato;
ip pim rp-petebat loopback 0
Tunc R3 nihil faciet, ut epistulas speciales mittere incipias, prius necesse est ut procuratorem destinatum inveniat. Et sic proceditur ad secundum gradum.
2) Configure R2 ut tabularum faciendarum;
IP pim bsr-candidatum loopback 0
R2 incipit mittere nuntios PIM Bootstrap, ubi se indicat quasi tabularum faciendarum:
Epistula electronica 224.0.013 mittitur, qua PIM protocollum etiam aliis nuntiis utitur. Eos in omnes partes mittit ideoque non est quaestio pulli et ovi sicut in Auto-RP erat.
3) Cum primum RP nuntium accipit de itineris BSR, statim nuntium unicumst ad BSR inscriptionem electronicam mittet;
Post quem, BSR, nuntio de RPs accepto, eos multicast mittet ad electronicam 224.0.0.13, quae ab omnibus PIM iter auditur. ergo analogia praecepti IP pim auditorem autorp regularis iter in BSR.
Anycast RP cum Multicast Source Inventionis Protocollum (MSDP).
Auto-RP et BSR permittunt nos sarcinam in RP distribuere hoc modo: Circulus multicastus unum tantum activum RP habet. Non poterit sarcinam pro uno globo multicasti super plures RPs distribuere. MSDP hoc facit iteratis IP editis RP eadem persona cum 255.255.255.255. MSDP informationes discit utens uno modorum: static, auto-RP vel BSR.
In pictura habemus configurationem auto-RP cum MSDP. Ambae RPs cum IP inscriptione 172.16.1.1/32 configurantur in Loopback 1 interfacies et pro omnibus coetibus adhibetur. Cum RP-Annuntiate, ambo itinerarii se nuntiant cum hac inscriptione referendo. Procurator Auto-RP destinata, indicio accepto, RP-Inventum de RP mittit cum inscriptione 172.16.1.1/32. Iteras narramus circa retiaculum 172.16.1.1/32 utens IGP ac proinde. Ita, PIM iter itineris petitio seu actis mandare profluit ex RP quod est specificatum sicut proximum hop in itinere ad retis 172.16.1.1/32. Protocollum ipsum MSDP destinatum est pro ipsis RPs ut nuntiis de informationibus multicastis permutarent.
Vide topologiam hanc:
Switch6 transmissionum transmissionum ad electronicam 238.38.38.38 et sic tantum RP-R1 de eo cognoscit. Switch7 and Switch8 petivit this group. Iter R5 et R4 mittent PIM Join cum R1 et R3, respective. Quare? Iter ad 13.13.13.13 pro R5 referet ad R1 utens metrica IGP, sicut pro R4.
RP-R1 circa rivum scit et in R5 incipiet emittere, sed R4 de illo nihil scit, cum R1 illud simpliciter non mittet. Est ergo MSDP necessarium. Configuramus illud R1 et R5;
ip msdp parem 3.3.3.3 connect-source Loopback1 in R1
ip msdp parem 1.1.1.1 connect-source Loopback3 in R3
Sessionem inter se excitabunt et, cum quemlibet fluxum acceptum, proximo suo RP renuntiabunt.
Cum primum RP-R1 rivum ex Switch6 acceperit, statim nuntium unicumst MSDP fonte-activum mittet, qui informationes sicut (S, G) continebit - informationes de fonte et destinatione multicasti. Nunc RP-R3 scit fontem talem esse ut Switch6, petens ab R4 pro hoc fluxu, mittet PIM Join versus Switch6, ductus a mensa fusura. Quocirca R1 accepto tali PIM Join incipiet mercaturam versus RP-R3 mittere.
MSDP percurrit TCP, RPs nuntios servativos inter se mittunt ad vitam reprimendam. Timor LX seconds est.
Munus parium dividendi MSDP in diversas ditiones obscurum manet, quia mandata custodis et SA in quavis ditione adscriptionem non indicant. Etiam in hac topologia probavimus configurationem ostendens diversis dominiis - nulla differentia in effectu fuit.
Si quis enucleare potest, libenter ea in commentarios perlegere velim.
Source: www.habr.com