Varför multicast inte korsar en VPN utan en plan

Två platser kan nå varandra perfekt via unicast och ändå bete sig som om en av dem inte ser skrivarens upptäcktsmeddelande, IPTV-strömmen eller klustrets hjärtslag. Det är inte en trasig tunnel; det är skillnaden mellan en destination och en grupp. Multicast-leverans kräver en medlemskapsmodell, vidarebefordringstillstånd längs vägen och ett gränssnitt som är villigt att bära trafiken, och inget av det kommer från en unicast-rutt. Att gå från applikationens grupp till en fungerande mottagare är den kortaste vägen till ett svar.

Börja med gruppen och applikationen

Fråga vilken gruppadress applikationen använder och vad trafiken är till för. Ett upptäcktsprotokoll som annonserar tjänster, en strömningsfeed och hello-paketen från ett routingprotokoll är tre olika problem med tre olika acceptabla svar. Själva gruppadressen säger omfattningen: adresser i det lokala nätverkskontrollblocket är inte avsedda att vidarebefordras utanför länken av vanlig routing, och applikationer som använder dem antar vanligtvis en enda broadcast-domän. En strömningsfeed på en grupp med global omfattning är en annan design än ett upptäcktsprotokoll som förväntar sig att varje enhet hör varje fråga, och bara den andra bryr sig om broadcast-domänens storlek.

Bestäm om kravet är tjänsten eller upptäcktsmekanismen, eftersom de svaren skiljer sig i kostnad med en storleksordning. Den ena ber om en adress som inte ändras; den andra ber om en broadcast-domän utsträckt över en länk för vittomfattande nät med allt som följer av det.

Lokal upptäckt ska stanna

Multicast DNS som beskrivs i RFC 6762 är designat kring en enda länk: frågor går till en fast grupp, svar skickas till samma grupp, och protokollet förlitar sig på att varje deltagare hör alla. Routrar vidarebefordrar inte den trafiken som standard, och det är ett designbeslut, inte en förbiseende. Gränsen finns för att en enhet i en byggnad inte bara ska kunna annonsera sig i en annan. En tunnel som verkar reparera upptäckt genom att bära gruppen överallt har tagit bort den gränsen för varje applikation, inte bara för den som behövde hjälp.

Repetrar och reflektorer finns, och de är riktiga tjänster med riktiga konsekvenser: varje namn som annonseras på en plats blir synligt på den andra, inklusive enhetsnamn som identifierar personer eller utrustning. Om det egentliga kravet är att en viss tjänst ska gå att hitta är en tjänstepost publicerad i DNS vanligtvis den mindre ändringen, och den avslöjar ett namn i stället för en ström av dem.

Tre saker som routad multicast behöver

Routad multicast behöver tre saker som samverkar: mottagare som går med i gruppen, routrar som upprätthåller vidarebefordringstillstånd för den, och en tunnel som behandlar gruppadresserna som trafik att bära. En tunnel med en policy som bara listar unicast-subnät kommer att tappa gruppens trafik vid krypteringsgränsen, och därför är det första symptomet ofta tystnad i stället för ett fel. Ett ruttbaserat gränssnitt, som en GRE- eller VTI-tunnel, bär det som routingtabellen skickar in i det, vilket gör gruppen nåbar så snart multicast-tillståndet finns.

Källans nåbarhet är den andra hälften. Multicast-routingprotokoll som PIM bygger distributionsträd genom att kontrollera att vägen tillbaka till källan är den förväntade, så en unicast-rutt som pekar någon annanstans bryter trädet även när gruppmedlemskapet är korrekt. Att installera en rutt för mottagaren gör ingenting för den kontrollen, och det är felet som ger en ping som fungerar och en ström som misslyckas. Kontrollera källans returväg först, lägg sedan till medlemskap och titta först därefter 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 två första raderna visar vad värden har gått med i och vad kärnan vidarebefordrar, den tredje visar applikationens eget medlemskap, och den sista visar den unicast-väg som kontrollen av omvänd väg kommer att använda. Att läsa dem tillsammans skiljer en applikation som aldrig gick med från ett nätverk som aldrig vidarebefordrade.

Bevisa det med en källa och en mottagare

Innan du rör en konfiguration, bekräfta att applikationen fungerar på ett enda segment. Om den misslyckas lokalt är multicast-routing inte problemet och ingen tunneländring kommer att hjälpa. Upprepa sedan med en mottagare genom tunneln och titta på paketen på båda sidor av krypteringsgränsen.

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

Paket som syns inne i tunneln men saknas utanför den pekar på inkapsling eller policy; paket som syns på båda sidor utan framsteg i applikationen pekar på mottagarens medlemskap eller applikationens bindning. Håll fångsterna korta och filtrerade, eftersom en bred multicast-fångst på ett upptaget segment mest är brus.

Välj en tjänstadress när du bara behöver tjänsten

Upptäckt finns för att hitta något som rör sig. En server med ett stabilt namn behöver ingen upptäckt, och en dokumenterad adress i privat DNS besvarar användarens egentliga fråga utan att sträcka ut en broadcast-domän över en länk för vittomfattande nät. Samma resonemang gäller skrivare, apparater och interna webbtjänster. Ett namn i DNS är nåbart från varje plats som behöver det medan det inte annonserar något till platserna som inte behöver det, och det fortsätter att fungera när enheten ersätts av en med en annan adress.

När ett protokoll verkligen kräver multicast, begränsa det till gruppen och platserna som behöver det, dokumentera varför och ompröva beslutet när applikationen ändras. Att sträcka ut upptäckt överallt är lätt att göra en gång, och svårt att rulla tillbaka efter ett år av enheter som tyst är beroende av det.