Hvorfor multicast ikke krysser en VPN uten en plan

To steder kan nå hverandre perfekt via unicast og likevel oppføre seg som om ett av dem ikke ser oppdagelsesmeldingen fra skriveren, IPTV-strømmen eller hjerteslaget til klyngen. Det er ikke en ødelagt tunnel; det er forskjellen mellom en destinasjon og en gruppe. Multicast-levering krever en medlemskapsmodell, videresendingstilstand langs veien og et grensesnitt som er villig til å bære trafikken, og ingenting av det kommer fra en unicast-rute. Å gå fra applikasjonens gruppe til én fungerende mottaker er den korteste veien til et svar.

Start med gruppen og applikasjonen

Spør hvilken gruppeadresse applikasjonen bruker og hva trafikken er til. En oppdagelsesprotokoll som annonserer tjenester, en strømmefeed og hello-pakkene til en rutingsprotokoll er tre ulike problemer med tre ulike akseptable svar. Selve gruppeadressen forteller omfanget: adresser i den lokale nettverkskontrollblokken er ikke ment å videresendes ut av lenken av vanlig ruting, og applikasjoner som bruker dem antar vanligvis ett enkelt kringkastingsdomene. En strømmefeed på en gruppe med globalt omfang er et annet design enn en oppdagelsesprotokoll som forventer at hver enhet hører hver forespørsel, og bare den andre bryr seg om størrelsen på kringkastingsdomenet.

Bestem om kravet er tjenesten eller oppdagelsesmekanismen, fordi de svarene skiller seg i kostnad med en størrelsesorden. Det ene ber om en adresse som ikke endrer seg; det andre ber om en kringkastingsdomene utvidet over en lenke for vidstrakt nett med alt som følger av det.

Lokal oppdagelse skal stoppe

Multicast DNS som beskrevet i RFC 6762 er designet rundt én lenke: forespørsler går til en fast gruppe, svar sendes til den samme gruppen, og protokollen er avhengig av at hver deltaker hører alle. Rutere videresender ikke den trafikken som standard, og det er en designbeslutning, ikke en forglemmelse. Grensen finnes for at en enhet i én bygning ikke bare skal kunne annonsere seg i en annen. En tunnel som tilsynelatende retter oppdagelse ved å bære gruppen overalt, har fjernet den grensen for hver applikasjon, ikke bare for den som trengte hjelp.

Repeterere og reflektorer finnes, og de er ekte tjenester med ekte konsekvenser: hvert navn som annonseres på ett sted, blir synlig på det andre, inkludert enhetsnavn som identifiserer personer eller utstyr. Hvis det egentlige kravet er at en bestemt tjeneste skal være søkbar, er en tjenestepost publisert i DNS vanligvis den minste endringen, og den avslører ett navn i stedet for en strøm av dem.

Tre ting rutet multicast trenger

Rutet multicast krever tre ting som virker sammen: mottakere som melder seg inn i gruppen, rutere som vedlikeholder videresendingstilstand for den, og en tunnel som behandler gruppeadressene som trafikk som skal bæres. En tunnel med en policy som bare lister unicast-subnett, vil slippe trafikken til gruppen ved krypteringsgrensen, og derfor er det første symptomet ofte stillhet i stedet for en feil. Et rutebasert grensesnitt, som en GRE- eller VTI-tunnel, bærer det rutetabellen sender inn i det, noe som gjør gruppen tilgjengelig så snart multicast-tilstanden finnes.

Kildens rekkevidde er den andre halvdelen. Multicast-rutingsprotokoller som PIM bygger distribusjonstrær ved å kontrollere at veien tilbake til kilden er den forventede, så en unicast-rute som peker et annet sted, bryter treet selv når gruppemedlemskapet er riktig. Å installere en rute for mottakeren gjør ingenting for den kontrollen, og det er feilen som gir en ping som virker og en strøm som feiler. Kontroller kildens returvei først, legg deretter til medlemskap, og se først da på applikasjonen.

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

De to første linjene viser hva verten har meldt seg inn i, og hva kjernen videresender, den tredje viser applikasjonens eget medlemskap, og den siste viser den unicast-veien som returveikontrollen vil bruke. Å lese dem sammen skiller en applikasjon som aldri meldte seg inn, fra et nettverk som aldri videresendte.

Bevis det med én kilde og én mottaker

Før du rører en konfigurasjon, bekreft at applikasjonen virker på ett enkelt segment. Hvis den feiler lokalt, er multicast-ruting ikke problemet, og ingen tunnelendring vil hjelpe. Gjenta deretter med én mottaker gjennom tunnelen og se på pakkene på begge sider av krypteringsgrensen.

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

Pakker som er synlige inne i tunnelen, men fraværende utenfor den, peker på innkapsling eller policy; pakker som er synlige på begge sider uten fremgang i applikasjonen, peker på mottakerens medlemskap eller applikasjonens binding. Hold opptak korte og filtrerte, siden et bredt multicast-opptak på et travelt segment mest er støy.

Foretrekk en tjenesteadresse når du bare trenger tjenesten

Oppdagelse finnes for å finne noe som beveger seg. En server med et stabilt navn trenger ikke oppdagelse, og en dokumentert adresse i privat DNS besvarer brukerens egentlige spørsmål uten å utvide et kringkastingsdomene over en lenke for vidstrakt nett. Samme resonnement gjelder skrivere, apparater og interne webtjenester. Et navn i DNS er tilgjengelig fra hvert sted som trenger det, mens det ikke annonserer noe til stedene som ikke trenger det, og det fortsetter å virke når enheten erstattes av en med en annen adresse.

Når en protokoll virkelig krever multicast, begrens det til gruppen og stedene som trenger det, dokumenter hvorfor, og ta beslutningen opp til vurdering når applikasjonen endrer seg. Å utvide oppdagelse overalt er lett å gjøre én gang, og vanskelig å rulle tilbake etter et år med enheter som stille er avhengige av det.