Miért nem kel át a multicast egy VPN-en terv nélkül
Az elérhetőség unicast kérdés. Nézze át a csoportot, annak hatókörét, a továbbítási állapotot és egy forrásból egy vevőhöz vezető utat, mielőtt hidat vagy ismétlőt ad hozzá.
Két telephely unicasttal tökéletesen elérheti egymást, mégis viselkedhet úgy, mintha az egyik nem látná a nyomtató felderítési hirdetményét, az IPTV-folyamot vagy a klaszter szívverését. Ez nem elromlott alagút; ez a cél és a csoport közötti különbség. A multicast kézbesítéséhez tagsági modellre, az útvonal menti továbbítási állapotra és a forgalom hordozására kész interfészre van szükség, és ezek egyike sem származik unicast útvonalból. Az alkalmazás csoportjától egy működő vevőig eljutni a legrövidebb út a válaszhoz.
Kezdje a csoporttal és az alkalmazással
Kérdezze meg, melyik csoportcímet használja az alkalmazás, és mi a forgalom célja. A szolgáltatásokat hirdető felderítési protokoll, a streamelő adatfolyam és egy forgalomirányító protokoll hello-csomagjai három különböző probléma három különböző elfogadható válasszal. A csoportcím maga mondja meg a hatókört: a helyi hálózati vezérlőblokk címeit nem arra szánták, hogy közönséges forgalomirányítás a kapcsolatról kifelé továbbítsa őket, és az ezeket használó alkalmazások általában egyetlen üzenetszóró tartományt feltételeznek. A globális hatókörű csoporton futó adatfolyam más tervezés, mint a felderítési protokoll, amely elvárja, hogy minden eszköz minden lekérdezést halljon, és csak az utóbbit érdekli az üzenetszóró tartomány mérete.
Döntse el, hogy a követelmény a szolgáltatás vagy a felderítési mechanizmus, mert ezek a válaszok költségben egy nagyságrenddel különböznek. Az egyik olyan címet kér, amely nem változik; a másik egy nagy kiterjedésű kapcsolaton át kiterjesztett üzenetszóró tartományt kér mindennel, ami ebből következik.
A helyi felderítésnek meg kell állnia
A RFC 6762-ban leírt Multicast DNS egyetlen kapcsolat köré épül: a lekérdezések egy rögzített csoporthoz mennek, a válaszok ugyanahhoz a csoporthoz mennek, és a protokoll arra számít, hogy minden résztvevő mindenkit hall. Az útválasztók alapértelmezés szerint nem továbbítják ezt a forgalmat, és ez tervezési döntés, nem mulasztás. A határ azért létezik, hogy az egyik épület eszköze ne hirdethesse magát könnyedén egy másikba. Az az alagút, amely látszólag rendbe hozza a felderítést azzal, hogy mindenhová viszi a csoportot, minden alkalmazás elől eltávolította ezt a határt, nem csak attól, amelyiknek segítségre volt szüksége.
Ismétlők és tükrözők léteznek, és valódi szolgáltatások valódi következményekkel: minden név, amelyet az egyik telephelyen hirdetnek, láthatóvá válik a másikon, beleértve az embereket vagy berendezéseket azonosító eszközneveket is. Ha a valódi követelmény az, hogy egy adott szolgáltatás megtalálható legyen, a DNS-ben közzétett szolgáltatásrekord általában a kisebb változás, és egyetlen nevet tár fel a nevük folyama helyett.
Három dolog, amire a forgalomirányított multicastnak szüksége van
A forgalomirányított multicastnak három dologra van szüksége együtt: a csoporthoz csatlakozó vevőkre, a számára továbbítási állapotot fenntartó útválasztókra és egy alagútra, amely a csoportcímeket hordozandó forgalomként kezeli. Az olyan alagút, amelynek irányelve csak unicast alhálózatokat sorol fel, a titkosítási határon eldobja a csoport forgalmát, ezért az első tünet gyakran a csend, nem pedig a hiba. Az útvonalalapú interfész, például a GRE vagy VTI alagút, azt hordozza, amit a forgalomirányítási tábla küld bele, ami elérhetővé teszi a csoportot, amint a multicast állapot létezik.
A forrás elérhetősége a második fél. A PIM-hez hasonló multicast forgalomirányító protokollok elosztó fákat építenek annak ellenőrzésével, hogy a forráshoz visszavezető út a várt-e, ezért a máshová mutató unicast útvonal akkor is eltöri a fát, ha a csoporttagság helyes. A vevő számára telepített útvonal semmit sem tesz ezért az ellenőrzésért, és ez az a hiba, amely működő pinget és meghiúsuló adatfolyamot eredményez. Először a forrás visszauti útját ellenőrizze, aztán adja hozzá a tagságot, és csak azután nézze meg az alkalmazást.
ip maddr show dev tun0
ip mroute show
ss -gnu | grep 239.255.0.10
ip route get 10.20.5.20
Az első két sor azt mutatja, mihez csatlakozott a gazdagép, és mit továbbít a kernel, a harmadik az alkalmazás saját tagságát mutatja, az utolsó pedig azt az unicast utat, amelyet a fordított útvonal ellenőrzése használni fog. Együtt olvasva megkülönbözteti a soha nem csatlakozó alkalmazást a soha nem továbbító hálózattól.
Bizonyítsa egyetlen forrással és egyetlen vevővel
Mielőtt hozzányúlna egy konfigurációhoz, erősítse meg, hogy az alkalmazás egyetlen szegmensen működik. Ha helyben meghiúsul, a multicast forgalomirányítás nem a probléma, és semmilyen alagútváltozás nem segít. Ezután ismételje meg egy vevővel az alagúton keresztül, és figyelje a csomagokat a titkosítási határ mindkét oldalán.
tcpdump -ni tun0 -c 10 'ip multicast'
tcpdump -ni eth0 -c 10 'ip multicast and host 239.255.0.10'
Az alagúton belül látható, kívül hiányzó csomagok beágyazásra vagy irányelvre utalnak; a mindkét oldalon látható, de az alkalmazásban előrehaladást nem mutató csomagok a vevő tagságára vagy az alkalmazás kötésére utalnak. Tartsa a rögzítéseket rövidnek és szűrtnek, mert egy széles multicast rögzítés forgalmas szegmensen többnyire zaj.
Akkor válasszon szolgáltatási címet, ha csak a szolgáltatás kell
A felderítés azért létezik, hogy megtaláljon valamit, ami mozog. A stabil nevű kiszolgálónak nincs szüksége felderítésre, és a privát DNS-ben dokumentált cím válaszol a felhasználó valódi kérdésére anélkül, hogy üzenetszóró tartományt terjesztene ki egy nagy kiterjedésű kapcsolaton át. Ugyanez az érvelés érvényes a nyomtatókra, készülékekre és belső webes szolgáltatásokra. A DNS-beli név minden olyan telephelyről elérhető, amelynek szüksége van rá, miközben semmit sem hirdet azoknak, amelyeknek nincs, és tovább működik, amikor az eszközt másik, eltérő című eszközre cserélik.
Amikor egy protokoll valóban multicastot igényel, korlátozza a csoportra és azokra a telephelyekre, amelyeknek szüksége van rá, dokumentálja az okot, és változzon az alkalmazás, vizsgálja felül a döntést. A felderítés mindenhol való kiterjesztése egyszer könnyű, és nehéz visszavonni egy év után olyan eszközök mellett, amelyek csendben függenek tőle.