PIM-protokolla on joukko protokollia ryhmälähetysten lähettämiseksi verkossa reitittimien välillä. Naapuruussuhteet rakennetaan samalla tavalla kuin dynaamisten reititysprotokollien tapauksessa. PIMv2 lähettää Hello-viestejä 30 sekunnin välein varattuun monilähetysosoitteeseen 224.0.0.13 (All-PIM-reitittimet). Viesti sisältää pitoajastimet - yleensä 3.5* Hello Timer, eli oletuksena 105 sekuntia.
PIM käyttää kahta pääkäyttötilaa - Tiheä ja Harva tila. Aloitetaan tiheästä tilasta.
Lähdepohjaiset jakelupuut.
Tiheätilatilaa suositellaan käytettäväksi, kun on olemassa suuri määrä eri monilähetysryhmien asiakkaita. Kun reititin vastaanottaa monilähetysliikennettä, se tarkistaa ensimmäisenä RPF-säännön varalta. RPF - tätä sääntöä käytetään monilähetyksen lähteen tarkistamiseen unicast-reititystaulukon avulla. On välttämätöntä, että liikenne saapuu rajapinnalle, jonka taakse tämä isäntä on piilotettu unicast-reititystaulukon version mukaan. Tämä mekanismi ratkaisee monilähetyksen aikana esiintyvän silmukan ongelman.
R3 tunnistaa monilähetyslähteen (Source IP) ryhmälähetyssanomasta ja tarkistaa kaksi virtaa R1:stä ja R2:sta käyttämällä unicast-taulukkoa. Taulukon osoittamasta liitännästä (R1 - R3) tuleva stream välitetään edelleen ja virta R2:sta pudotetaan, koska multicast-lähteeseen pääsemiseksi on lähetettävä paketteja S0/1:n kautta.
Kysymys kuuluu, mitä tapahtuu, jos sinulla on kaksi vastaavaa reittiä samalla mittarilla? Tässä tapauksessa reititin valitsee seuraavan hypyn näiltä reiteiltä. Se, jolla on korkeampi IP-osoite, voittaa. Jos sinun on muutettava tätä toimintaa, voit käyttää ECMP:tä. Lisätietoja .
RPF-säännön tarkistamisen jälkeen reititin lähettää monilähetyspaketin kaikille PIM-naapureilleen, paitsi sille, jolta paketti vastaanotettiin. Muut PIM-reitittimet toistavat tämän prosessin. Polku, jonka monilähetyspaketti on kulkenut lähteestä lopullisiin vastaanottajiin, muodostaa puun, jota kutsutaan lähdepohjaiseksi jakelupuuksi, lyhimmän polun puuksi (SPT), lähdepuuksi. Kolme eri nimeä, valitse mikä tahansa.
Miten ratkaista ongelma, että jotkut reitittimet eivät luopuneet jostain monilähetysvirrasta eikä ole kenellekään lähettää sitä, mutta ylävirran reititin lähettää sen hänelle. Prune-mekanismi keksittiin tätä varten.
Leikkaa Viesti.
Esimerkiksi R2 jatkaa monilähetyksen lähettämistä R3:lle, vaikka R3 RPF-säännön mukaan katkaisee sen. Miksi ladata kanava? R3 lähettää PIM Prune -sanoman ja R2, saatuaan tämän viestin, poistaa liitännän S0/1 tämän vuon lähtevien liitäntöjen luettelosta, luettelosta liitännöistä, joista tämä liikenne tulee lähettää.
Seuraava on PIM Prune -viestin muodollisempi määritelmä:
Yksi reititin lähettää PIM Prune -sanoman toiselle reitittimelle saadakseen toisen reitittimen poistamaan linkin, jolla karsi on vastaanotettu tietystä (S,G) SPT:stä.
Vastaanotettuaan Karsi-viestin R2 asettaa Karsi-ajastimen 3 minuuttiin. Kolmen minuutin kuluttua se alkaa lähettää liikennettä uudelleen, kunnes se vastaanottaa uuden Prune-viestin. Tämä on PIMv1:ssä.
Ja PIMv2:een on lisätty State Refresh -ajastin (oletusarvoisesti 60 sekuntia). Heti kun Karsi-viesti on lähetetty R3:lta, tämä ajastin käynnistyy R3:lla. Ajastimen umpeuduttua R3 lähettää tilapäivitysviestin, joka nollaa tämän ryhmän R3:n 2 minuutin leikkausajastimen.
Syitä Prune-viestin lähettämiseen:
- Kun monilähetyspaketti epäonnistuu RPF-tarkistuksessa.
- Kun ei ole paikallisesti yhdistettyjä asiakkaita, jotka ovat pyytäneet ryhmälähetysryhmää (IGMP Join), eikä ole PIM-naapureita, joille voidaan lähettää ryhmälähetysliikennettä (ei-prunne-liitäntä).
Siirrä viesti.
Oletetaan, että R3 ei halunnut liikennettä R2:lta, lähetti Prunen ja vastaanotti ryhmälähetyksen R1:ltä. Mutta yhtäkkiä kanava R1-R3 välillä putosi ja R3 jäi ilman monilähetystä. Voit odottaa 3 minuuttia, kunnes R2:n leikkausajastin vanhenee. 3 minuuttia on pitkä odotus, jotta et joutuisi odottamaan, sinun on lähetettävä viesti, joka nostaa tämän S0/1-liitännän R2:lle välittömästi karsitusta tilasta. Tämä viesti on siirreviesti. Vastaanotettuaan Graft-viestin R2 vastaa Graft-ACK:lla.
Leikkaamisen ohitus.
Katsotaanpa tätä kaaviota. R1 lähettää monilähetyksen segmentille, jossa on kaksi reititintä. R3 vastaanottaa ja lähettää liikennettä, R2 vastaanottaa, mutta sillä ei ole ketään, jolle lähettää liikennettä. Se lähettää karsia sanoman R1:lle tässä segmentissä. R1:n pitäisi poistaa Fa0/0 luettelosta ja lopettaa lähetykset tässä segmentissä, mutta mitä tapahtuu R3:lle? Ja R3 on samassa segmentissä, sai myös tämän viestin Prunelta ja ymmärsi tilanteen tragedian. Ennen kuin R1 lopettaa lähetyksen, se asettaa 3 sekunnin ajastimen ja lopettaa lähetyksen 3 sekunnin kuluttua. 3 sekuntia - juuri tämän verran aikaa R3:lla on, jotta se ei menetä monilähetystään. Siksi R3 lähettää Pim Join -viestin tälle ryhmälle mahdollisimman pian, eikä R1 enää ajattele lähetyksen lopettamista. Tietoja Liity-viesteistä alla.
Vahvista viesti.
Kuvitellaanpa tämä tilanne: kaksi reititintä lähettää samaan verkkoon kerralla. Ne vastaanottavat saman virran lähteestä ja molemmat lähettävät sen samaan verkkoon rajapinnan e0 takana. Siksi heidän on määritettävä, kuka on tämän verkon ainoa lähetystoiminnan harjoittaja. Assert-viestejä käytetään tähän. Kun R2 ja R3 havaitsevat monilähetysliikenteen päällekkäisyyden, eli R2 ja R3 vastaanottavat monilähetyksen, jonka he itse lähettävät, reitittimet ymmärtävät, että tässä on jotain vialla. Tässä tapauksessa reitittimet lähettävät Assert-sanomia, jotka sisältävät hallinnollisen etäisyyden ja reittimittarin, jolla monilähetyslähde saavutetaan - 10.1.1.10. Voittaja määritetään seuraavasti:
- Se, jolla on pienempi AD.
- Jos AD ovat yhtä suuret, kenellä on alempi mittari.
- Jos tässä on tasa-arvoa, niin se, jolla on korkeampi IP-osoite verkossa, johon he lähettävät tämän monilähetyksen.
Tämän äänestyksen voittajasta tulee nimetty reititin. Pim Hellota käytetään myös DR:ien valitsemiseen. Artikkelin alussa näytettiin PIM Hello -viesti, näet siellä DR-kentän. Se, jolla on korkein IP-osoite tässä linkissä, voittaa.
Hyödyllinen merkki:
MROUTE Taulukko.
Ensimmäistä kertaa PIM-protokollan toiminnan jälkeen meidän on ymmärrettävä, kuinka toimia monilähetysreititystaulukon kanssa. mroute-taulukko tallentaa tiedot siitä, mitä virtoja asiakkailta pyydettiin ja mitkä virrat virtaavat monilähetyspalvelimista.
Esimerkiksi kun IGMP-jäsenyysraportti tai PIM-liittyminen vastaanotetaan jossain rajapinnassa, tyypin ( *, G ) tietue lisätään reititystaulukkoon:
Tämä merkintä tarkoittaa, että liikennepyyntö vastaanotettiin osoitteella 238.38.38.38. DC-lippu tarkoittaa, että monilähetys toimii tiheässä tilassa ja C tarkoittaa, että vastaanottaja on suoraan yhteydessä reitittimeen, eli reititin on vastaanottanut IGMP-jäsenyysraportin ja PIM-liitoksen.
Jos tietue on tyyppiä (S,G), se tarkoittaa, että meillä on monilähetysvirta:
S-kenttään - 192.168.1.11 - olemme rekisteröineet monilähetyslähteen IP-osoitteen, RPF-sääntö tarkistaa tämän. Jos ongelmia ilmenee, sinun on ensin tarkistettava yksilähetystaulukosta reitti lähteeseen. Saapuva liitäntä -kentässä osoittaa liitännän, johon monilähetys vastaanotetaan. Unicast-reititystaulukossa reitin lähteeseen on viitattava tässä määritettyyn rajapintaan. Outgoing Interface määrittää, minne ryhmälähetys uudelleenohjataan. Jos se on tyhjä, reititin ei ole vastaanottanut pyyntöjä tälle liikenteelle. Lisätietoa kaikista lipuista löytyy .
PIM Sparse-tila.
Sparse-tilan strategia on päinvastainen kuin Dense-mode. Kun Sparse-mode vastaanottaa monilähetysliikennettä, se lähettää liikennettä vain niiden rajapintojen kautta, joissa tätä kulkua varten oli pyyntöjä, esimerkiksi Pim Join- tai IGMP-raporttiviestit, jotka pyytävät tätä liikennettä.
Samanlaiset elementit SM:lle ja DM:lle:
- Naapuruussuhteet rakennetaan samalla tavalla kuin PIM DM:ssä.
- RPF-sääntö toimii.
- DR-valikoima on samanlainen.
- Karsi ohitus- ja vahvistusviestien mekanismit ovat samanlaisia.
Yhteistä tietokeskusta tarvitaan valvomaan, kuka, missä ja millaista monilähetysliikennettä verkossa tarvitaan. Keskustamme on Rendezvous Point (RP). Jokainen, joka haluaa jonkinlaista multicast-liikennettä tai joku alkoi vastaanottaa monilähetysliikennettä lähteestä, lähettää sen sitten RP:lle.
Kun RP vastaanottaa monilähetysliikennettä, se lähettää sen niille reitittimille, jotka ovat aiemmin pyytäneet tätä liikennettä.
Kuvitellaan topologiaa, jossa RP on R3. Heti kun R1 vastaanottaa liikennettä S1:ltä, se kapseloi tämän monilähetyspaketin unicast PIM Register -viestiksi ja lähettää sen RP:lle. Mistä hän tietää, kuka RP on? Tässä tapauksessa se konfiguroidaan staattisesti, ja puhumme dynaamisesta RP-konfiguroinnista myöhemmin.
ip pim rp-osoite 3.3.3.3
RP tarkastelee - oliko tietoa joltakin, joka haluaisi vastaanottaa tämän liikenteen? Oletetaan, ettei se ollut. Sitten RP lähettää R1:lle PIM Register-Stop -viestin, mikä tarkoittaa, että kukaan ei tarvitse tätä monilähetystä, rekisteröinti evätään. R1 ei lähetä ryhmälähetystä. Mutta monilähetyslähdeisäntä lähettää sen, joten R1, vastaanotettuaan Register-Stop-ilmoituksen, käynnistää rekisteröinnin eston ajastimen, joka vastaa 60 sekuntia. 5 sekuntia ennen tämän ajastimen umpeutumista R1 lähettää tyhjän rekisterisanoman Null-Register-bitillä (eli ilman kapseloitua monilähetyspakettia) kohti RP:tä. RP puolestaan toimii seuraavasti:
- Jos vastaanottajia ei ollut, se vastaa Register-Stop -viestillä.
- Jos vastaanottajia ilmestyy, hän ei vastaa siihen millään tavalla. R1, joka ei ole saanut rekisteröintikieltoa 5 sekunnin kuluessa, on tyytyväinen ja lähettää RP:lle kapseloidun monilähetyksen sisältävän rekisteröintiviestin.
Näyttää siltä, että olemme selvittäneet, kuinka monilähetys saavuttaa RP:n, yritetään nyt vastata kysymykseen, kuinka RP toimittaa liikennettä vastaanottajille. Tässä on tarpeen ottaa käyttöön uusi käsite - root-path tree (RPT). RPT on RP:hen juurtunut puu, joka kasvaa vastaanottajia kohti ja haarautuu jokaisessa PIM-SM-reitittimessä. RP luo sen vastaanottamalla PIM Join -viestejä ja lisää uuden haaran puuhun. Ja niin tekee jokainen loppupään reititin. Yleissääntö näyttää tältä:
- Kun PIM-SM-reititin vastaanottaa PIM Join -viestin missä tahansa muussa kuin rajapinnassa, jonka taakse RP on piilotettu, se lisää puuhun uuden haaran.
- Haara lisätään myös, kun PIM-SM-reititin vastaanottaa IGMP-jäsenyysraportin suoraan yhdistetystä isännästä.
Kuvitellaan, että meillä on ryhmälähetysasiakas R5-reitittimessä ryhmälle 228.8.8.8. Heti kun R5 vastaanottaa IGMP-jäsenyysraportin isännältä, R5 lähettää PIM-liitoksen RP:n suuntaan ja lisää itse puuhun rajapinnan, joka katsoo isäntäkonetta. Seuraavaksi R4 vastaanottaa PIM Joinin R5:ltä, lisää liitännän Gi0/1 puuhun ja lähettää PIM Joinin RP:n suuntaan. Lopuksi RP ( R3 ) vastaanottaa PIM Joinin ja lisää Gi0/0 puuhun. Siten monilähetyksen vastaanottaja on rekisteröity. Rakennamme puun juurella R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Tämän jälkeen PIM Join lähetetään R1:lle ja R1 alkaa lähettää ryhmälähetysliikennettä. On tärkeää huomata, että jos isäntä pyysi liikennettä ennen monilähetyksen alkamista, RP ei lähetä PIM Join -ohjelmaa eikä lähetä mitään R1:lle.
Jos yhtäkkiä monilähetystä lähetettäessä isäntä lakkaa haluamasta vastaanottaa sitä, heti kun RP vastaanottaa PIM-luukun Gi0/0-liitännässä, se lähettää välittömästi PIM-rekisteripysähdyksen suoraan R1:lle ja sitten PIM-luukun. viestin Gi0/1-liitännän kautta. PIM Register-stop lähetetään unicastin kautta siihen osoitteeseen, josta PIM-rekisteri tuli.
Kuten aiemmin sanoimme, heti kun reititin lähettää PIM-liitoksen toiselle, esimerkiksi R5 - R4, tietue lisätään R4:ään:
Ja ajastin käynnistetään, että R5:n on jatkuvasti nollattava tämä ajastin PIM Join viestit jatkuvasti, muuten R4 suljetaan pois lähtevien viestien luettelosta. R5 lähettää joka 60. PIM Join -viestin.
Lyhimmän polun puun vaihto.
Lisäämme rajapinnan R1:n ja R5:n välille ja katsomme kuinka liikenne kulkee tällä topologialla.
Oletetaan, että liikennettä lähetettiin ja vastaanotettiin vanhan kaavan R1-R2-R3-R4-R5 mukaisesti, ja tässä liitimme ja konfiguroimme liitännän R1:n ja R5:n välille.
Ensinnäkin meidän on rakennettava uudelleen unicast-reititystaulukko R5:ssä ja nyt verkko 192.168.1.0/24 saavutetaan R5 Gi0/2 -liitännän kautta. Nyt R5, joka vastaanottaa monilähetystä rajapinnalla Gi0/1, ymmärtää, että RPF-sääntö ei täyty ja olisi loogisempaa vastaanottaa ryhmälähetystä Gi0/2:lla. Sen pitäisi katkaista yhteys RPT:hen ja rakentaa lyhyempi puu nimeltä Shortest-Path Tree (SPT). Tätä varten hän lähettää PIM Joinin R0:lle Gi2/1:n kautta ja R1 alkaa lähettää ryhmälähetystä myös Gi0/2:n kautta. Nyt R5:n on peruutettava RPT:n tilaus, jotta se ei saa kahta kopiota. Tätä varten hän lähettää Prunelle viestin, jossa ilmoitetaan lähteen IP-osoite ja lisätään erityinen bitti - RPT-bit. Tämä tarkoittaa, että sinun ei tarvitse lähettää minulle liikennettä, minulla on parempi puu täällä. RP lähettää myös PIM Prune -viestejä R1:lle, mutta ei lähetä Register-Stop -viestiä. Toinen ominaisuus: R5 lähettää nyt jatkuvasti PIM Prunea RP:lle, kun R1 jatkaa PIM-rekisterin lähettämistä RP:lle minuutin välein. Kunnes ei ole uusia ihmisiä, jotka haluavat tätä liikennettä, RP kieltäytyy siitä. R5 ilmoittaa RP:lle, että se jatkaa monilähetyksen vastaanottamista SPT:n kautta.
Dynaaminen RP-haku.
Auto-RP.
Tämä tekniikka on Ciscon oma, eikä se ole erityisen suosittu, mutta se on edelleen elossa. Auto-RP-toiminta koostuu kahdesta päävaiheesta:
1) RP lähettää RP-Announce-viestejä varattuun osoitteeseen - 224.0.1.39, ilmoittaen itsensä RP:ksi joko kaikille tai tietyille ryhmille. Tämä viesti lähetetään minuutin välein.
2) Tarvitaan RP-kartoitusagentti, joka lähettää RP-Discovery-sanomia ilmoittaen, mille ryhmille mitä RP:tä tulee kuunnella. Tästä viestistä tavalliset PIM-reitittimet määrittävät RP:n itse. Mapping Agent voi olla joko itse RP-reititin tai erillinen PIM-reititin. RP-Discovery lähetetään osoitteeseen 224.0.1.40 minuutin ajastuksella.
Katsotaanpa prosessia tarkemmin:
Määritetään R3 RP:ksi:
ip pim send-rp-announce loopback 0 soveltamisala 10
R2 kartoitusagenttina:
ip pim send-rp-discovery loopback 0 soveltamisala 10
Ja kaikissa muissa odotamme RP:tä Auto-RP:n kautta:
ip pim autorp-kuuntelija
Kun olemme määrittäneet R3:n, se alkaa lähettää RP-Announce:
Ja R2, määritettyään kartoitusagentin, alkaa odottaa RP-Announce-sanomaa. Vasta kun se löytää vähintään yhden RP:n, se alkaa lähettää RP-Discovery:tä:
Tällä tavalla, kun tavalliset reitittimet (PIM RP Listener) saavat tämän viestin, he tietävät mistä etsiä RP:tä.
Yksi Auto-RP:n suurimmista ongelmista on, että RP-Announce- ja RP-Discovery-viestien vastaanottamiseksi sinun on lähetettävä PIM Join osoitteisiin 224.0.1.39-40, ja lähettääksesi sinun on tiedettävä, mihin RP sijaitsee. Klassinen kana-munaongelma. Tämän ongelman ratkaisemiseksi keksittiin PIM Sparse-Dense-Mode. Jos reititin ei tunne RP:tä, se toimii tiheässä tilassa, jos tietää, niin harvassa. Kun PIM Sparse-mode ja ip pim autorp listener -komento on konfiguroitu tavallisten reitittimien liitäntöihin, reititin toimii Dense-tilassa vain monilähetyksessä suoraan Auto-RP-protokollasta (224.0.1.39-40).
BootStrap-reititin (BSR).
Tämä toiminto toimii samalla tavalla kuin Auto-RP. Jokainen RP lähettää viestin kartoitusagentille, joka kerää kartoitustiedot ja kertoo sitten kaikille muille reitittimille. Kuvataan prosessi samalla tavalla kuin Auto-RP:
1) Kun määritämme R3:n ehdokkaaksi RP:ksi, komennolla:
ip pim rp-kandidaatti loopback 0
Silloin R3 ei tee mitään; aloittaakseen erikoisviestien lähettämisen, hänen on ensin löydettävä kartoitusagentti. Joten siirrymme toiseen vaiheeseen.
2) Määritä R2 kartoitusagentiksi:
ip pim bsr-candidate loopback 0
R2 alkaa lähettää PIM Bootstrap -viestejä, joissa se ilmoittaa olevansa kartoitusagentti:
Tämä viesti lähetetään osoitteeseen 224.0.013, jota PIM-protokolla käyttää myös muissa viesteissään. Se lähettää ne kaikkiin suuntiin ja siksi ei ole kana ja muna -ongelmaa kuten Auto-RP:ssä.
3) Heti kun RP vastaanottaa viestin BSR-reitittimeltä, se lähettää välittömästi unicast-viestin BSR-reitittimen osoitteeseen:
Tämän jälkeen BSR, saatuaan tiedon RP:istä, lähettää ne monilähetyksellä osoitteeseen 224.0.0.13, jota kaikki PIM-reitittimet kuuntelevat. Siksi komennon analogi ip pim autorp-kuuntelija tavallisille reitittimille, jotka eivät ole BSR:ssä.
Anycast RP Multicast Source Discovery Protocol (MSDP) -protokollalla.
Auto-RP ja BSR mahdollistavat RP:n kuormituksen jakamisen seuraavasti: Jokaisella monilähetysryhmällä on vain yksi aktiivinen RP. Yhden monilähetysryhmän kuormaa ei voida jakaa useille RP:ille. MSDP tekee tämän antamalla RP-reitittimille saman IP-osoitteen maskilla 255.255.255.255. MSDP oppii tiedot jollakin menetelmistä: staattinen, Auto-RP tai BSR.
Kuvassa meillä on Auto-RP konfiguraatio MSDP:llä. Molemmat RP:t on määritetty IP-osoitteella 172.16.1.1/32 Loopback 1 -liitännässä ja niitä käytetään kaikissa ryhmissä. RP-Announce-toiminnolla molemmat reitittimet ilmoittavat itsestään viittaamalla tähän osoitteeseen. Auto-RP-kartoitusagentti, saatuaan tiedon, lähettää RP:tä koskevan RP-Discoveryn osoitteella 172.16.1.1/32. Kerromme reitittimille verkosta 172.16.1.1/32 IGP:n avulla ja vastaavasti. Siten PIM-reitittimet pyytävät tai rekisteröivät vuotoja RP:stä, joka on määritetty seuraavaksi hyppyksi reitillä verkkoon 172.16.1.1/32. Itse MSDP-protokolla on suunniteltu RP:ille itse vaihtamaan viestejä ryhmälähetystiedoista.
Harkitse tätä topologiaa:
Switch6 lähettää liikennettä osoitteeseen 238.38.38.38 ja toistaiseksi vain RP-R1 tietää siitä. Switch7 ja Switch8 pyysivät tätä ryhmää. Reitittimet R5 ja R4 lähettävät PIM-liitoksen R1:lle ja R3:lle. Miksi? Reitti 13.13.13.13 R5:lle viittaa R1:een käyttäen IGP-metriikkaa, aivan kuten R4:lle.
RP-R1 tietää streamista ja alkaa lähettää sitä kohti R5, mutta R4 ei tiedä siitä mitään, koska R1 ei yksinkertaisesti lähetä sitä. Siksi MSDP on välttämätön. Määritämme sen R1:lle ja R5:lle:
ip msdp peer 3.3.3.3 connect-source Loopback1 R1:ssä
ip msdp peer 1.1.1.1 connect-source Loopback3 R3:ssä
He aloittavat istunnon toistensa välillä ja kun he vastaanottavat virtauksen, he raportoivat siitä RP-naapurilleen.
Heti kun RP-R1 vastaanottaa virran Switch6:lta, se lähettää välittömästi unicast MSDP Source-Active -sanoman, joka sisältää tietoja, kuten (S, G) - tietoa monilähetyksen lähteestä ja kohteesta. Nyt kun RP-R3 tietää, että lähde, kuten Switch6, vastaanottaessaan pyynnön R4:ltä tätä kulkua varten, se lähettää PIM Joinin Switch6:een reititystaulukon ohjaamana. Tämän seurauksena R1, joka on vastaanottanut tällaisen PIM-liitoksen, alkaa lähettää liikennettä kohti RP-R3:a.
MSDP toimii TCP:n yli, RP:t lähettävät toisilleen säilytysviestejä tarkistaakseen elävyyden. Ajastin on 60 sekuntia.
MSDP-vertaisten jakaminen eri toimialueisiin jää epäselväksi, koska Keepalive- ja SA-viestit eivät osoita jäsenyyttä mihinkään toimialueeseen. Lisäksi testasimme tässä topologiassa eri verkkotunnuksia osoittavaa konfiguraatiota - suorituskyvyssä ei ollut eroa.
Jos joku osaa selventää, luen sen mielelläni kommenteissa.
Lähde: will.com