OpenVPN skickar multicast till varje klient, inte till prenumeranter
Servern i användarutrymmet kopierar ett grupppaket per klient, inte per prenumerant. Budgetera utskicket, bevisa det med tunnelräknare och begränsa sedan designen.
"Stöder multicast" besvarar en protokollfråga och lämnar kapacitetsfrågan orörd. Det som spelar roll operativt är hur många kopior servern sänder för ett grupppaket och vilka tunnlar som bär dem. Ett prenumererat program som tar emot strömmen bevisar bara att leveransen fungerar någonstans. Det bevisar inte att ointresserade klienter skonades från bandbredden.
Tre frågor inuti ett enda funktionspåstående
Gruppmedlemskap frågar om mottagaren gick med i gruppen. Tunneleverans frågar om paketet alls korsade tunneln. Replikeringspolicy frågar hur många kopior servern gjorde och till vem. Ett leverantörsuttalande kan vara sant för det första och tyst om det tredje, och det är där kostnaden bor.
Håll dem åtskilda när du dimensionerar en förbindelse. Bara den tredje frågan sätter utgångsbudgeten på serversidan.
Vad servern i användarutrymmet gör med ett grupppaket
I den traditionella servern i användarutrymmet för OpenVPN 2.6 klassificeras ett ankommande broadcast- eller multicastpaket i TUN/TAP-ingångsvägen och lämnas till broadcast-utspridningsrutinen i stället för en sökning per grupp. Den rutinen går igenom klientinstanserna, hoppar över avsändaren och varje stoppad instans, tillämpar sin VLAN-kontroll där en är konfigurerad och ställer en kopia i kö för varje kvarvarande klient. Inget steg i den loopen rådfrågar en medlemstabell. Det är replikering i broadcast-stil, och det är hela mekanismen.
Behandla detta som en egenskap hos den kodvägen, inte som en universell lag. Accelererade datavägar, andra implementeringar och olika versioner kan bete sig annorlunda, och inget av detta gör TAP till ett krav eller en reparation.
Budgetera kopiorna innan du mäter något
Ta nyttolasttakten och multiplicera den med antalet kvalificerade klienter. En ström som skickar en megabit per sekund till tjugo klienter producerar tjugo megabit per sekund nyttolast som lämnar servern, före inkapsling, omsändning och varje overhead per klient. Den aritmetiken är en budget, inte en mätning av din driftsättning.
ip -s link show tun0Läs byte-räknaren för sändning före och efter ett fast intervall med en känd aktiv avsändare. Dividera med intervallet och jämför med nyttolasttakten multiplicerad med klientantalet. En siffra nära enkelströmtakten betyder att replikeringen är begränsad; en siffra nära den multiplicerade takten betyder att varje klient får en kopia.
Räknaren omfattar också din egen tunneltrafik, så håll testfönstret kort och värden i övrigt tyst. Precision spelar mindre roll än storleksordningen, och det är allt du behöver för att skilja en kopia från tjugo.
Ett test med två klienter som avgör omfattningsfrågan
Anslut en klient som ska ta emot strömmen och en andra som inte ska. Starta avsändaren och titta sedan på den andra klientens tunnelräknare under samma intervall. Tillväxt hos den andra klienten är direkta bevis på bred replikering, vad funktionslistan än sa.
Filtrera fångsten till gruppadressen så att du inte läser orelaterad trafik, och håll den till tunnelgränssnittet. Att fånga det fysiska gränssnittet på en upptagen värd ger en fil som ingen kan tolka och kan behålla användardata som du inte avsåg att samla in.
Byt sedan roller. Om resultatet följer mottagaren och inte gruppen tittar du på något medlemskapsmedvetet, och det tidigare antagandet var fel till din fördel.
Välja en begränsad design i stället för att ta bort gränser
När utskicket är för brett är lösningen ett stött begränsat distributionsarrangemang, inte att radera varje kontroll du har. Alternativen inkluderar att flytta distributionspunkten närmare mottagarna, använda en källspecifik prenumerationsmodell som bär källidentiteten tillsammans med gruppen, eller dela strömmen så att ointresserade platser aldrig sitter på samma distributionsgräns.
Håll käll- och gruppidentiteten åtskild från det bara faktum att en destination är multicast. En mottagare som känner igen gruppen men inte källan är en annan prenumerant än en som bad om en specifik kanal. Att blanda de två gör senare kapacitetsplanering till gissning.
Modellen för källspecifik multicast-kanal är referensen för den distinktionen. Vilken design du än väljer, skriv ned uppsättningen kvalificerade parter, replikeringsägaren och räknaren du kommer att läsa nästa gång; den anteckningen är det som förvandlar en bandbreddsöverraskning till en känd kostnad.