Kiel funkcias la PIM-protokolo

La PIM-protokolo estas aro de protokoloj por elsendado de multirolantaro en reto inter enkursigiloj. Najbaraj rilatoj estas konstruitaj en la sama maniero kiel en la kazo de dinamikaj vojprotokoloj. PIMv2 sendas Saluton-mesaĝojn ĉiujn 30 sekundojn al la rezervita multielsenda adreso 224.0.0.13 (Ĉiuj-PIM-Routers). La mesaĝo enhavas Hold Timers - kutime egala al 3.5*Hello Timer, tio estas, 105 sekundoj defaŭlte.

PIM uzas du ĉefajn operaciumojn - Densa kaj Maldensa reĝimo. Ni komencu per Densa reĝimo.
Font-Bazitaj Distribuaj Arboj.
Densa reĝimo estas konsilinde uzi en la kazo de granda nombro da klientoj de malsamaj multirolantaj grupoj. Kiam enkursigilo ricevas multrolan trafikon, la unua afero, kiun ĝi faras, estas kontroli ĝin por la RPF-regulo. RPF - ĉi tiu regulo estas uzata por kontroli la fonton de multielsendo kun unuelsenda vojtabelo. Necesas, ke la trafiko alvenu al la interfaco malantaŭ kiu ĉi tiu gastiganto estas kaŝita laŭ la versio de la unicast-vojigtabelo. Ĉi tiu mekanismo solvas la problemon de buklo okazanta dum multirolanta dissendo.

R3 rekonos la multirolanta fonton (Fonto IP) de la multirolanta mesaĝo kaj kontrolos la du fluojn de R1 kaj R2 uzante ĝian unuelsantan tablon. La fluo de la interfaco indikita de la tabelo (R1 al R3) estos elsendita plu, kaj la fluo de R2 estos forigita, ĉar por atingi la multirolanta fonto, vi devas sendi pakaĵojn per S0/1.
La demando estas, kio okazas se vi havas du ekvivalentajn itinerojn kun la sama metriko? En ĉi tiu kazo, la enkursigilo elektos la sekvan salton el ĉi tiuj itineroj. Kiu havas la pli altan IP-adreson gajnas. Se vi bezonas ŝanĝi ĉi tiun konduton, vi povas uzi ECMP. Pli da detaloj tie.
Post kontrolado de la RPF-regulo, la enkursigilo sendas multirolanta paketon al ĉiuj siaj PIM-najbaroj, krom tiu de kiu la pakaĵeto estis ricevita. Aliaj PIM-enkursigiloj ripetas ĉi tiun procezon. La pado kiun multirolantarbo prenis de la fonto ĝis la finaj ricevantoj formas arbon nomitan font-bazita distribuarbo, plej mallonga-vojarbo (SPT), fontarbo. Tri malsamaj nomoj, elektu iun ajn.
Kiel solvi la problemon, ke iuj enkursigiloj ne rezignis pri iu multielsenda fluo kaj estas neniu al kiu sendi ĝin, sed la kontraŭflua enkursigilo sendas ĝin al li. La mekanismo Prune estis inventita por tio.
Prune Mesaĝo.
Ekzemple, R2 daŭre sendos multirolantaron al R3, kvankam R3, laŭ la RPF-regulo, faligas ĝin. Kial ŝargi la kanalon? R3 sendas PIM Prune Message kaj R2, ricevinte ĉi tiun mesaĝon, forigos interfacon S0/1 de la eliranta interfaca listo por ĉi tiu fluo, la listo de interfacoj de kiuj ĉi tiu trafiko devus esti sendita.

La sekvanta estas pli formala difino de PIM Prune-mesaĝo:
La PIM Prune-mesaĝo estas sendita per unu enkursigilo al dua enkursigilo por igi la duan enkursigilon forigi la ligon sur kiu la Prune estas ricevita de speciala (S,G) SPT.

Post ricevi la mesaĝon de Prune, R2 fiksas la tempigilon de Prune al 3 minutoj. Post tri minutoj, ĝi komencos sendi trafikon denove ĝis ĝi ricevos alian mesaĝon pri Prune. Ĉi tio estas en PIMv1.
Kaj en PIMv2 Ŝtata Refreŝiga tempigilo estis aldonita (60 sekundoj defaŭlte). Tuj kiam Prune-mesaĝo estas sendita de R3, ĉi tiu tempigilo komenciĝas sur R3. Post eksvalidiĝo de ĉi tiu tempigilo, R3 sendos Ŝtata Refreŝigan mesaĝon, kiu restarigos la 3-minutan Prune-Temigilon sur R2 por ĉi tiu grupo.
Kialoj por sendi mesaĝon pri Prune:

• Kiam multirolanta pakaĵeto malsukcesas la RPF-kontrolon.
• Kiam ne ekzistas loke konektitaj klientoj, kiuj petis multirolantaron (IGMP Join) kaj ne ekzistas PIM-najbaroj, al kiuj multielsenda trafiko povas esti sendita (Non-prune Interface).

Greft Mesaĝo.
Ni imagu, ke R3 ne volis trafikon de R2, sendis Prunon kaj ricevis multielsendon de R1. Sed subite, la kanalo inter R1-R3 falis kaj R3 restis sen multielsendo. Vi povas atendi 3 minutojn ĝis la Prune Timer sur R2 eksvalidiĝos. 3 minutoj estas longa atendado, por ne atendi, vi devas sendi mesaĝon, kiu tuj elportos ĉi tiun interfacon S0/1 al R2 el la pritondita stato. Ĉi tiu mesaĝo estos Graft-mesaĝo. Post ricevi la mesaĝon Graft, R2 respondos per Graft-ACK.
Prune Override.

Ni rigardu ĉi tiun diagramon. R1 dissendas multirolas al segmento per du enkursigiloj. R3 ricevas kaj elsendas trafikon, R2 ricevas, sed havas neniun al kiu dissendi trafikon. Ĝi sendas Prune-mesaĝon al R1 en ĉi tiu segmento. R1 devus forigi Fa0/0 de la listo kaj ĉesi dissendi en ĉi tiu segmento, sed kio okazos al R3? Kaj R3 estas en la sama segmento, ankaŭ ricevis ĉi tiun mesaĝon de Prune kaj komprenis la tragedion de la situacio. Antaŭ ol R1 ĉesas dissendi, ĝi fiksas tempigilon de 3 sekundoj kaj ĉesos dissendi post 3 sekundoj. 3 sekundoj - jen ĝuste kiom da tempo havas R3 por ne perdi sian multicast. Tial, R3 sendas Pim Join-mesaĝon por ĉi tiu grupo kiel eble plej baldaŭ, kaj R1 ne plu pensas ĉesi dissendi. Pri Aliĝu al mesaĝoj sube.
Aserti Mesaĝon.

Ni imagu ĉi tiun situacion: du enkursigiloj elsendas al unu reto samtempe. Ili ricevas la saman rivereton de la fonto, kaj ambaŭ dissendas ĝin al la sama reto malantaŭ interfaco e0. Sekve, ili devas determini kiu estos la sola kaj sola dissendanto por ĉi tiu reto. Asert-mesaĝoj estas uzataj por tio. Kiam R2 kaj R3 detektas duobligon de multielsenda trafiko, tio estas, multielsendo alvenas ĉe R2 kaj R3, kiujn ili mem elsendas, la enkursigiloj komprenas, ke io estas malĝusta ĉi tie. En ĉi tiu kazo, enkursigiloj sendas Assert-mesaĝojn, kiuj inkluzivas Administran Distancon kaj la itinermetrikon per kiu la multirolantaro estas atingita - 10.1.1.10. La gajninto estas determinita jene:

1. Tiu kun pli malalta AD.
2. Se AD estas egala, tiam kiu havas la pli malaltan metrikon.
3. Se estas egaleco ĉi tie, tiam tiu, kiu havas la pli altan IP en la reto, al kiu ili elsendas ĉi tiun multielsendon.

La gajninto de ĉi tiu voĉdono iĝas la Nomumita enkursigilo. Pim Hello ankaŭ estas uzata por elekti DRojn. Komence de la artikolo, la mesaĝo de PIM Saluton estis montrita, vi povas vidi la DR-kampon tie. Venkas tiu kun la plej alta IP-adreso en ĉi tiu ligilo.
Utila signo:

MROUTE Tablo.
Post komenca rigardo pri kiel funkcias la PIM-protokolo, ni devas kompreni kiel labori kun multirolanta enrutiga tablo. La mroute-tabelo konservas informojn pri kiuj fluoj estis petitaj de klientoj kaj kiuj fluoj fluas de multirolantaro-serviloj.
Ekzemple, kiam IGMP-Membreca Raporto aŭ PIM-Aliĝo estas ricevita sur iu interfaco, rekordo de tipo ( *, G ) estas aldonita al la vojigtabelo:

Ĉi tiu eniro signifas, ke trafikpeto estis ricevita kun la adreso 238.38.38.38. La DC-flago signifas, ke la multirolantaro funkcios en Densa reĝimo kaj C signifas, ke la ricevanto estas rekte konektita al la enkursigilo, tio estas, la enkursigilo ricevis la IGMP-Membrecan Raporton kaj PIM-Aliĝi.
Se estas rekordo de tipo (S,G) tio signifas, ke ni havas multirolantan fluon:

En la S-kampo - 192.168.1.11, ni registris la IP-adreson de la multielsenda fonto, estas ĉi tio, kio estos kontrolita de la RPF-regulo. Se estas problemoj, la unua afero, kiun vi devas fari, estas kontroli la unuelsendan tabelon por la itinero al la fonto. En la Envenanta Interfaco kampo, indikas la interfacon al kiu la multielsendo estas ricevita. En unuelsenda vojigtabelo, la itinero al la fonto devas rilati al la interfaco specifita ĉi tie. La Elira Interfaco precizigas kie la multielsendo estos alidirektita. Se ĝi estas malplena, tiam la enkursigilo ne ricevis petojn por ĉi tiu trafiko. Pliaj informoj pri ĉiuj flagoj troveblas tie.
PIM Maldensa-reĝimo.
La strategio de Maldensa-reĝimo estas la kontraŭo de Densa-reĝimo. Kiam Sparse-mode ricevas multrolan trafikon, ĝi nur sendos trafikon tra tiuj interfacoj kie estis petoj por ĉi tiu fluo, ekzemple Pim Join aŭ IGMP Report mesaĝojn petante ĉi tiun trafikon.
Similaj elementoj por SM kaj DM:

• Najbaraj rilatoj estas konstruitaj en la sama maniero kiel en PIM DM.
• La RPF-regulo funkcias.
• La elekto de DR estas simila.
• La mekanismo de Prune Overrides kaj Asert-mesaĝoj estas similaj.

Por kontroli kiu, kie kaj kia speco de multielsenda trafiko necesas en la reto, necesas komuna informcentro. Nia centro estos Rendezvous Point (RP). Ĉiu, kiu volas ian multrolan trafikon aŭ iu komencis ricevi multielsantan trafikon de la fonto, tiam li sendas ĝin al RP.
Kiam la RP ricevas multrolan trafikon, ĝi sendos ĝin al tiuj enkursigiloj, kiuj antaŭe petis ĉi tiun trafikon.

Ni imagu topologion kie RP estas R3. Tuj kiam R1 ricevas trafikon de S1, ĝi enkapsuligas ĉi tiun multirolanta paketon en unuelsantan PIM Register-mesaĝon kaj sendas ĝin al RP. Kiel li scias, kiu estas la RP? En ĉi tiu kazo, ĝi estas agordita statike, kaj ni parolos pri dinamika RP-agordo poste.

ip pim rp-adreso 3.3.3.3

RP aspektos - ĉu estis informoj de iu, kiu ŝatus ricevi ĉi tiun trafikon? Ni supozu, ke ĝi ne estis. Tiam RP sendos al R1 mesaĝon de PIM Register-Stop, kio signifas, ke neniu bezonas ĉi tiun multielsendon, registrado estas rifuzita. R1 ne sendos multicast. Sed la plurelsenda fontogastiganto sendos ĝin, tiel ke R1, post ricevo de Register-Stop, komencos Register-Suppression-tempigilon egalan al 60 sekundoj. 5 sekundojn antaŭ ol tiu tempigilo eksvalidiĝas, R1 sendos malplenan Register-mesaĝon kun Null-Register-bito (t.e., sen enkapsuligita multirolantpakaĵo) direkte al RP. RP, siavice, agos jene:

• Se ne estis ricevantoj, tiam ĝi respondos per mesaĝo Register-Stop.
• Se aperos ricevantoj, li neniel respondos al ĝi. R1, ne ricevinte rifuzon registri ene de 5 sekundoj, estos feliĉa kaj sendos Register-mesaĝon kun enkapsuligita multielsendo al RP.

Ŝajnas, ke ni eksciis, kiel multielsendo atingas RP, nun ni provu respondi la demandon pri kiel RP liveras trafikon al ricevantoj. Ĉi tie necesas enkonduki novan koncepton - radikvoja arbo (RPT). RPT estas arbo radikita en RP, kreskanta al la ricevantoj, disbranĉiĝante sur ĉiu PIM-SM-enkursigilo. RP kreas ĝin ricevante mesaĝojn de PIM Join kaj aldonas novan branĉon al la arbo. Kaj tiel, ĉiu laŭflua enkursigilo faras. La ĝenerala regulo aspektas jene:

• Kiam PIM-SM-enkursigilo ricevas PIM Join-mesaĝon sur iu ajn interfaco krom la interfaco malantaŭ kiu la RP estas kaŝita, ĝi aldonas novan branĉon al la arbo.
• Branĉo ankaŭ estas aldonita kiam la PIM-SM-enkursigilo ricevas IGMP-Membrecan Raporton de rekte ligita gastiganto.

Ni imagu, ke ni havas multrolan klienton sur la R5-enkursigilo por grupo 228.8.8.8. Tuj kiam R5 ricevas la IGMP-Membrecan Raporton de la gastiganto, R5 sendas PIM-Aliĝi direkte al la RP, kaj mem aldonas interfacon al la arbo kiu rigardas la gastiganton. Poste, R4 ricevas PIM Join de R5, aldonas interfacon Gi0/1 al la arbo kaj sendas PIM Join direkte al RP. Fine, RP ( R3 ) ricevas PIM Join kaj aldonas Gi0/0 al la arbo. Tiel, la multirolanta ricevanto estas registrita. Ni konstruas arbon kun la radiko R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Post ĉi tio, PIM-Aliĝo estos sendita al R1 kaj R1 komencos sendi multirolan trafikon. Gravas noti, ke se la gastiganto petis trafikon antaŭ ol la multielsendo komenciĝis, tiam RP ne sendos PIM-Aliĝi kaj tute ne sendos ion al R1.
Se subite dum multielsendo estas sendita, la gastiganto ĉesas voli ricevi ĝin, tuj kiam RP ricevas PIM Prune sur la interfaco Gi0/0, ĝi tuj sendos PIM Register-Stop rekte al R1, kaj tiam PIM Prune. mesaĝo per la interfaco Gi0/1. PIM-Registro-halto estas sendita per unuelsendo al la adreso de kiu la PIM-Registro venis.
Kiel ni diris antaŭe, tuj kiam enkursigilo sendas PIM-Join al alia, ekzemple R5 al R4, tiam rekordo estas aldonita al R4:

Kaj tempigilo estas komencita, ke R5 devas konstante restarigi ĉi tiun tempigilon PIM-Aliĝi al mesaĝoj konstante, alie R4 estos ekskludita el la eliranta listo. R5 sendos ĉiujn 60 mesaĝojn de PIM Join.
Plej Mallonga Voja Arba Ŝanĝo.
Ni aldonos interfacon inter R1 kaj R5 kaj vidos kiel trafiko fluas kun ĉi tiu topologio.

Ni supozu, ke trafiko estis sendita kaj ricevita laŭ la malnova skemo R1-R2-R3-R4-R5, kaj ĉi tie ni konektis kaj agordis la interfacon inter R1 kaj R5.
Antaŭ ĉio, ni devas rekonstrui la unicast-enrutigan tablon sur R5 kaj nun la reto 192.168.1.0/24 estas atingita per la interfaco R5 Gi0/2. Nun R5, ricevanta multicast sur interfaco Gi0/1, komprenas ke la RPF-regulo ne estas kontentigita kaj estus pli logike ricevi multicast sur Gi0/2. Ĝi devus malkonekti de RPT kaj konstrui pli mallongan arbon nomatan Plej Mallonga Voja Arbo (SPT). Por fari tion, li sendas PIM Join al R0 tra Gi2/1 kaj R1 komencas sendi multicast ankaŭ tra Gi0/2. Nun R5 bezonas malaboni de RPT por ne ricevi du ekzemplerojn. Por fari tion, li sendas al Prune mesaĝon indikante la fontan IP-adreson kaj enigante specialan biton - RPT-bit. Ĉi tio signifas, ke vi ne bezonas sendi al mi trafikon, mi havas pli bonan arbon ĉi tie. RP ankaŭ sendas PIM Prune-mesaĝojn al R1, sed ne sendas mesaĝon Register-Stop. Alia funkcio: R5 nun senĉese sendos PIM Prune al RP, ĉar R1 daŭre sendas PIM-Registron al RP ĉiun minuton. Ĝis ne estos novaj homoj dezirantaj ĉi tiun trafikon, RP rifuzos ĝin. R5 sciigas al RP ke ĝi daŭre ricevas multirolantaron per SPT.
Dinamika RP-serĉo.
Aŭtomata-RP.
Ĉi tiu teknologio estas proprieta de Cisco kaj ne estas precipe populara, sed daŭre vivas. Aŭtomata-RP-operacio konsistas el du ĉefaj stadioj:
1) RP sendas RP-Anonci mesaĝojn al la rezervita adreso - 224.0.1.39, deklarante sin RP aŭ por ĉiuj aŭ por specifaj grupoj. Ĉi tiu mesaĝo estas sendita ĉiuminute.
2) RP-mapa agento estas postulata, kiu sendos RP-Discovery-mesaĝojn indikante por kiuj grupoj kiun RP devus esti aŭskultita. Estas de ĉi tiu mesaĝo, ke regulaj PIM-enkursigiloj determinos la RP por si mem. La Mapping Agent povas esti aŭ la RP-enkursigilo mem aŭ aparta PIM-enkursigilo. RP-Discovery estas sendita al adreso 224.0.1.40 kun tempigilo de unu minuto.
Ni rigardu la procezon pli detale:
Ni agordu R3 kiel RP:

ip pim send-rp-announce loopback 0 amplekso 10

R2 kiel mapa agento:

ip pim send-rp-discovery loopback 0 amplekso 10

Kaj ĉe ĉiuj aliaj ni atendos RP per Aŭtomata-RP:

ip pim autorp aŭskultanto

Post kiam ni agordas R3, ĝi komencos sendi RP-Announce:

Kaj R2, post agordo de la mapa agento, komencos atendi la RP-Anonci-mesaĝon. Nur kiam ĝi trovos almenaŭ unu RP, ĝi komencos sendi RP-Discovery:

Tiel, tuj kiam regulaj enkursigiloj (PIM RP Listener) ricevos ĉi tiun mesaĝon, ili scios kie serĉi la RP.
Unu el la ĉefaj problemoj kun Aŭtomata-RP estas, ke por ricevi mesaĝojn RP-Announce kaj RP-Discovery, vi devas sendi PIM Join al adresoj 224.0.1.39-40, kaj por sendi, vi devas scii kie la RP situas. Klasika problemo de kokido kaj ovo. Por solvi ĉi tiun problemon, la PIM Sparse-Dense-Mode estis inventita. Se la enkursigilo ne konas RP, tiam ĝi funkcias en Densa-reĝimo; se jes, tiam en Maldensa-reĝimo. Kiam PIM Sparse-reĝimo kaj la ip pim autorp aŭskultanto-komando estas agordita sur la interfacoj de regulaj enkursigiloj, la enkursigilo funkcios en Densa-reĝimo nur por multielsendo rekte de la Aŭtomata-RP-protokolo (224.0.1.39-40).
BootStrap Router (BSR).
Ĉi tiu funkcio funkcias simile al Aŭtomata-RP. Ĉiu RP sendas mesaĝon al la mapa agento, kiu kolektas mapajn informojn kaj tiam rakontas ĉiujn aliajn enkursigilojn. Ni priskribu la procezon simile al Aŭtomata-RP:
1) Post kiam ni agordas R3 kiel kandidaton por esti RP, kun la komando:

ip pim rp-kandidato loopback 0

Tiam R3 nenion faros; por komenci sendi specialajn mesaĝojn, li unue devas trovi mapan agenton. Tiel, ni transiru al la dua paŝo.
2) Agordu R2 kiel mapagento:

ip pim bsr-kandidato loopback 0

R2 komencas sendi mesaĝojn PIM Bootstrap, kie ĝi indikas sin kiel mapagento:

Ĉi tiu mesaĝo estas sendita al la adreso 224.0.013, kiun la PIM-protokolo ankaŭ uzas por siaj aliaj mesaĝoj. Ĝi sendas ilin en ĉiuj direktoj kaj tial ne ekzistas problemo pri kokido kaj ovo kiel en Aŭtomata-RP.
3) Tuj kiam la RP ricevas mesaĝon de la BSR-enkursigilo, ĝi tuj sendos unuelsantan mesaĝon al la BSR-enkursigilo:

Post tio, la BSR, ricevinte informojn pri la RP-oj, sendos ilin per multielsendo al la adreso 224.0.0.13, kiu estas aŭskultata de ĉiuj PIM-enkursigiloj. Tial, analogo de la komando ip pim autorp aŭskultanto por regulaj enkursigiloj ne en BSR.
Anycast RP kun Multicast Source Discovery Protocol (MSDP).
Aŭto-RP kaj BSR permesas al ni distribui la ŝarĝon sur RP jene: Ĉiu multirolantaro havas nur unu aktivan RP. Ne eblos distribui la ŝarĝon por unu multrolantaro super pluraj RP-oj. MSDP faras tion eldonante RP-enkursigilojn la saman IP-adreson kun masko de 255.255.255.255. MSDP lernas informojn uzante unu el la metodoj: statika, Aŭtomata-RP aŭ BSR.

En la bildo ni havas Aŭtomatan-RP-agordon kun MSDP. Ambaŭ RP-oj estas agorditaj kun IP-adreso 172.16.1.1/32 sur Loopback 1-interfaco kaj estas uzataj por ĉiuj grupoj. Kun RP-Announce, ambaŭ enkursigiloj anoncas sin per referenco al ĉi tiu adreso. La aŭtomatemapa agento, ricevinte la informojn, sendas RP-Discovery pri la RP kun la adreso 172.16.1.1/32. Ni rakontas al enkursigiloj pri la reto 172.16.1.1/32 uzante IGP kaj, laŭe. Tiel, PIM-enkursigiloj petas aŭ registras fluojn de la RP kiu estas specifita kiel la sekva-salteto sur la itinero al la reto 172.16.1.1/32. La MSDP-protokolo mem estas dizajnita por la RPoj mem por interŝanĝi mesaĝojn pri multirolantinformoj.
Konsideru ĉi tiun topologion:

Switch6 elsendas trafikon al la adreso 238.38.38.38 kaj ĝis nun nur RP-R1 scias pri ĝi. Switch7 kaj Switch8 petis ĉi tiun grupon. Enkursigiloj R5 kaj R4 sendos PIM Join al R1 kaj R3, respektive. Kial? La itinero al 13.13.13.13 por R5 raportos al R1 uzante la IGP-metrikon, same kiel por R4.
RP-R1 scias pri la fluo kaj komencos dissendi ĝin al R5, sed R4 nenion scias pri ĝi, ĉar R1 ne simple sendos ĝin. Tial MSDP estas necesa. Ni agordas ĝin sur R1 kaj R5:

ip msdp peer 3.3.3.3 connect-source Loopback1 sur R1

ip msdp peer 1.1.1.1 connect-source Loopback3 sur R3

Ili levos sesion inter si kaj ricevinte ajnan fluon ili raportos ĝin al sia RP-najbaro.
Tuj kiam RP-R1 ricevos fluon de Switch6, ĝi tuj sendos unicast MSDP Font-Aktivan mesaĝon, kiu enhavos informojn kiel (S, G) - informojn pri la fonto kaj celloko de la multielsendo. Nun, ke RP-R3 scias, ke fonto kiel Switch6, ricevinte peton de R4 por ĉi tiu fluo, ĝi sendos PIM Join al Switch6, gvidita de la envojiga tablo. Sekve, R1 ricevinte tian PIM-Aliĝon komencos sendi trafikon al RP-R3.
MSDP kuras super TCP, RP-oj sendas unu la alian daŭrajn mesaĝojn por kontroli vivecon. La tempigilo estas 60 sekundoj.
La funkcio de dividado de MSDP-kunuloj en malsamaj domajnoj restas neklara, ĉar Keepalive kaj SA-mesaĝoj ne indikas membrecon en iu domajno. Ankaŭ, en ĉi tiu topologio, ni testis agordon indikantan malsamajn domajnojn - ne estis diferenco en rendimento.
Se iu povas klarigi, mi volonte legus ĝin en la komentoj.

fonto: www.habr.com