Kvifor multicast ikkje kryssar ein VPN utan ein plan

To stader kan nå kvarandre perfekt via unicast og likevel oppføre seg som om ein av dei ikkje ser oppdagingsmeldinga frå skrivaren, IPTV-straumen eller hjarteslaget til klynga. Det er ikkje ein øydelagd tunnel; det er skillnaden mellom ein destinasjon og ei gruppe. Multicast-levering krev ein medlemsskapsmodell, vidaresendingstilstand langs vegen og eit grensesnitt som er viljug til å bere trafikken, og ingen av desse kjem frå ein unicast-rute. Å gå frå gruppa til applikasjonen til éin fungerande mottakar er den kortaste vegen til eit svar.

Start med gruppa og applikasjonen

Spør kva gruppeadresse applikasjonen brukar og kva trafikken er til. Ein oppdagingsprotokoll som annonserer tenester, ein straumefeed og helo-pakkane til ein rutingsprotokoll er tre ulike problem med tre ulike akseptable svar. Sjølve gruppeadressa fortel omfanget: adresser i den lokale nettverkskontrollblokka er ikkje meinte å bli vidaresende ut av lenkja av vanleg ruting, og applikasjonar som brukar dei, føreset vanlegvis eitt einskilt kringkastingsdomene. Ein straumefeed på ei gruppe med globalt omfang er eit anna design enn ein oppdagingsprotokoll som ventar at kvar eining høyrer kvar førespurnad, og berre den andre bryr seg om storleiken på kringkastingsdomenet.

Avgjer om kravet er tenesta eller oppdagingsmekanismen, fordi dei svara skil seg i kostnad med ein storleiksorden. Det eine ber om ei adresse som ikkje endrar seg; det andre ber om eit kringkastingsdomene utvida over ei lenkje for vidstrekt nett med alt som følgjer av det.

Lokal oppdaging skal stoppe

Multicast DNS som skildra i RFC 6762 er designa rundt éi lenkje: førespurnader går til ei fast gruppe, svar blir sende til den same gruppa, og protokollen er avhengig av at kvar deltakar høyrer alle. Rutarar vidaresender ikkje den trafikken som standard, og det er eit designval, ikkje ei gløymsle. Grensa finst for at ei eining i ein bygning ikkje berre skal kunne annonsere seg i ein annan. Ein tunnel som tilsynelatande rettar oppdaging ved å bere gruppa overalt, har fjerna den grensa for kvar applikasjon, ikkje berre for den som trong hjelp.

Repeterarar og reflektørar finst, og dei er ekte tenester med ekte følgjer: kvart namn som blir annonsert på ein stad, blir synleg på den andre, inkludert einingnamn som identifiserer folk eller utstyr. Viss det eigentlege kravet er at ei bestemd teneste skal vere søkbar, er ein tenestepost publisert i DNS vanlegvis den minste endringa, og han avdekkjer eitt namn i staden for ein straum av dei.

Tre ting rutta multicast treng

Rutta multicast treng tre ting som verkar saman: mottakarar som melder seg inn i gruppa, rutarar som held ved like vidaresendingstilstand for henne, og ein tunnel som behandlar gruppeadressene som trafikk som skal berast. Ein tunnel med ein politikk som berre listar unicast-subnett, vil sleppe trafikken til gruppa ved krypteringsgrensa, og difor er det første symptomet ofte stille i staden for ein feil. Eit rutebasert grensesnitt, som ein GRE- eller VTI-tunnel, ber det rutetabellen sender inn i det, noko som gjer gruppa tilgjengeleg så snart multicast-tilstanden finst.

Rekkjevidd til kjelda er den andre halvdelen. Multicast-rutingsprotokollar som PIM byggjer distribusjonstre ved å kontrollere at vegen attende til kjelda er den venta, så ein unicast-rute som peikar ein annan stad, bryt treet sjølv når gruppemedlemskapen er rett. Å installere ei rute for mottakaren gjer ingenting for den kontrollen, og det er feilen som gjev ein ping som verkar og ein straum som sviktar. Kontroller returvegen til kjelda først, legg deretter til medlemskap, og sjå først då på applikasjonen.

ip maddr show dev tun0
ip mroute show
ss -gnu | grep 239.255.0.10
ip route get 10.20.5.20

Dei to første linjene viser kva verten har meldt seg inn i, og kva kjernen vidaresender, den tredje viser medlemskapen til applikasjonen sjølv, og den siste viser den unicast-vegen som returvegkontrollen vil bruke. Å lese dei saman skil ein applikasjon som aldri melde seg inn, frå eit nettverk som aldri vidaresende.

Prov det med éi kjelde og éin mottakar

Før du rører ein konfigurasjon, stadfest at applikasjonen verkar på eitt einskilt segment. Viss han sviktar lokalt, er multicast-ruting ikkje problemet, og ingen tunnelendring vil hjelpe. Gjenta deretter med éin mottakar gjennom tunnelen og sjå på pakkane på begge sider av krypteringsgrensa.

tcpdump -ni tun0 -c 10 'ip multicast'
tcpdump -ni eth0 -c 10 'ip multicast and host 239.255.0.10'

Pakkar som er synlege inne i tunnelen, men fråverande utanfor han, peikar på innkapsling eller politikk; pakkar som er synlege på begge sider utan framgang i applikasjonen, peikar på medlemskapen til mottakaren eller bindinga til applikasjonen. Hald opptak korte og filtrerte, sidan eit breitt multicast-opptak på eit travelt segment mest er støy.

Vel ein tenesteadresse når du berre treng tenesta

Oppdaging finst for å finne noko som flyttar seg. Ein tenar med eit stabilt namn treng ikkje oppdaging, og ei dokumentert adresse i privat DNS svarar på det eigentlege spørsmålet til brukaren utan å utvide eit kringkastingsdomene over ei lenkje for vidstrekt nett. Same resonnementet gjeld skrivarar, apparat og interne wektenester. Eit namn i DNS er tilgjengeleg frå kvar stad som treng det, medan det ikkje annonserer noko til stadene som ikkje treng det, og det held fram å verke når eininga blir erstatta av ei med ei anna adresse.

Når ein protokoll verkeleg krev multicast, avgrens det til gruppa og stadene som treng det, dokumenter kvifor, og ta avgjerda opp til vurdering når applikasjonen endrar seg. Å utvide oppdaging overalt er lett å gjere éin gong, og vanskeleg å rulle tilbake etter eit år med einingar som stille er avhengige av det.