Hvorfor multicast ikke krydser en VPN uden en plan

To steder kan nå hinanden perfekt via unicast og alligevel opføre sig, som om et af dem ikke kan se printerens opdagelsesmeddelelse, IPTV-strømmen eller klyngens hjerteslag. Det er ikke en brudt tunnel; det er forskellen mellem en destination og en gruppe. Multicast-levering kræver en medlemskabsmodel, videresendelsestilstand langs vejen og et interface, der er villigt til at bære trafikken, og intet af det kommer fra en unicast-rute. At gå fra applikationens gruppe til én fungerende modtager er den korteste vej til et svar.

Start med gruppen og applikationen

Spørg hvilken gruppeadresse applikationen bruger, og hvad trafikken er til. En opdagelsesprotokol, der annoncerer tjenester, et streaming-feed og en routingprotokols hello-pakker er tre forskellige problemer med tre forskellige acceptable svar. Selve gruppeadressen fortæller omfanget: adresser i den lokale netværkskontrolblok er ikke beregnet til at blive videresendt ud af linket af almindelig routing, og applikationer, der bruger dem, antager normalt et enkelt broadcast-domæne. Et streaming-feed på en gruppe med globalt omfang er et andet design end en opdagelsesprotokol, der forventer, at hver enhed hører hver forespørgsel, og kun den anden bekymrer sig om broadcast-domænets størrelse.

Beslut, om kravet er tjenesten eller opdagelsesmekanismen, fordi de svar adskiller sig i pris med en størrelsesorden. Det ene beder om en adresse, der ikke ændrer sig; det andet beder om et broadcast-domæne udstrakt over et WAN-link med alt, hvad der følger af det.

Link-lokal opdagelse skal stoppe

Multicast DNS som beskrevet i RFC 6762 er designet omkring et enkelt link: forespørgsler går til en fast gruppe, svar sendes til den samme gruppe, og protokollen afhænger af, at hver deltager hører alle. Routere videresender ikke den trafik som standard, og det er en designbeslutning, ikke en forglemmelse. Grænsen findes, så en enhed i én bygning ikke bare kan annoncere sig selv i en anden. En tunnel, der tilsyneladende retter opdagelse ved at bære gruppen overalt, har fjernet den grænse for hver applikation, ikke kun for den, der havde brug for hjælp.

Repeaters og reflektorer findes, og de er rigtige tjenester med rigtige konsekvenser: hvert navn, der annonceres på ét sted, bliver synligt på det andet, inklusive enhedsnavne, der identificerer personer eller udstyr. Hvis det faktiske krav er, at en bestemt tjeneste kan findes, er en servicerecord offentliggjort i DNS normalt den mindre ændring, og den afslører ét navn i stedet for en strøm af dem.

Tre ting som routet multicast kræver

Routet multicast kræver tre ting, der arbejder sammen: modtagere, der melder sig ind i gruppen, routere, der vedligeholder videresendelsestilstand for den, og en tunnel, der behandler gruppeadresserne som trafik, der skal bæres. En tunnel med en politik, der kun lister unicast-subnet, vil tabe gruppens trafik ved krypteringsgrænsen, og derfor er det første symptom ofte tavshed frem for en fejl. Et rutebaseret interface som en GRE- eller VTI-tunnel bærer, hvad routingtabellen sender ind i det, hvilket gør gruppen tilgængelig, når multicast-tilstanden først findes.

Kildens rækkevidde er den anden halvdel. Multicast-routingprotokoller som PIM bygger distributionstræer ved at kontrollere, at vejen tilbage til kilden er den forventede, så en unicast-rute, der peger et andet sted hen, bryder træet, selv når gruppemedlemskabet er korrekt. At installere en rute til modtageren gør intet for den kontrol, og det er fejlen, der giver en ping, der virker, og en strøm, der fejler. Kontroller kildens returvej først, tilføj derefter medlemskab, og se først da på applikationen.

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 linjer viser, hvad værten har meldt sig ind i, og hvad kernen videresender, den tredje viser applikationens eget medlemskab, og den sidste viser den unicast-vej, som returvejskontrollen vil bruge. At læse dem sammen skelner en applikation, der aldrig meldte sig ind, fra et netværk, der aldrig videresendte.

Bevis det med én kilde og én modtager

Før du rører en konfiguration, skal du bekræfte, at applikationen virker på et enkelt segment. Hvis den fejler lokalt, er multicast-routing ikke problemet, og ingen tunnelændring vil hjælpe. Gentag derefter med én modtager gennem tunnelen, og se på pakkerne på begge sider af krypteringsgrænsen.

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

Pakker, der er synlige inde i tunnelen, men fraværende uden for den, peger på indkapsling eller politik; pakker, der er synlige på begge sider uden fremskridt i applikationen, peger på modtagerens medlemskab eller applikationens binding. Hold optagelser korte og filtrerede, da en bred multicast-optagelse på et travlt segment mest er støj.

Foretræk en serviceadresse, når du kun har brug for tjenesten

Opdagelse findes for at finde noget, der flytter sig. En server med et stabilt navn har ikke brug for opdagelse, og en dokumenteret adresse i privat DNS besvarer brugerens egentlige spørgsmål uden at udstrække et broadcast-domæne over et WAN-link. Samme ræsonnement gælder printere, apparater og interne webtjenester. Et navn i DNS kan nås fra hvert sted, der har brug for det, mens det ikke annoncerer noget til de steder, der ikke har, og det bliver ved med at virke, når enheden erstattes af en med en anden adresse.

Når en protokol virkelig kræver multicast, skal du begrænse det til gruppen og de steder, der har brug for det, dokumentere hvorfor og tage beslutningen op igen, når applikationen ændrer sig. At udstrække opdagelse overalt er let at gøre én gang og svært at rulle tilbage efter et år med enheder, der stille afhænger af det.