Dotaz: OpenWRT - využití VLAN pro IPTV (multicast) - obrovský provoz

[Petr Maleček]

Příloha:

• vlan-home-iptv.png (65835 bytů)

Zdravím Vás,

řeším tu jeden takový problém.

Mám router TP-Link TL-WDR4300 s poslední verzí OpenWRT (15.05.1) a využívám ho v kombinaci s poskytovatelem, který po VLANě s ID 999 poskytuje přístup k internetu a VLANě s ID 11 přístup k IPTV (pomocí multicastu).

Můj Router je nastavený podle obrázku v příloze.

A teď v čem je problém - když vezmu nejlevnější router, který tu mám - Netis a nastavím ho tak, jak se má (tzn. IP na WANu, DHCP a IP na LANu, VLANy 1 pro LAN, 11 pro IPTV+přiřadím fyzický port a VLAN 999 pro INET), tak funguje vše správně. Když udělám to samé na tom TP-Linku s OWRT (podle obrázku v příloze), tak sice vše funguje, ale jen chvíli. Během chvilky začnou do routeru na VLANě 11 (IPTV) téct desetitisíce paketů a cca 140Mbit v multicastech.

Jak je to možné? Router nijak traffic na VLANě 11 neomezuje (žádný FW, dokonce v ní nemá ani nemá IP). Předpokládám, že router prostě data z TAGované VLANy 11 posílá do určeného portu pro IPTV (netagovaný). Nebo se pletu? Děje se tam i něco jiného?

Děkuji za nápady a případné rady.

---

---

Odpovědi

[Michal Kubeček]

Ten popis je hodně mlhavý a lze si ho domyslet mnoha různými způsoby, ale tipoval bych, že se vám podařilo vyrobit smyčku tím, že jste na dvou místech probridgoval netagovanou síť a nějakou VLAN. Potom vám každý broadcast paket (třeba ARP dotaz) bude běhat pořád dokola a jak jich bude přibývat, síť se nakonec úplně zahltí.

[Petr Maleček]

Ano, omlouvám se, nevím, jak to lépe popsat. Je to prostě základní konfigurace routeru, který NATuje VLAN999 (inet) do VLAN1 (lokální síť) + doplněná VLANa pro IPTV (protože STB neumí vlany, tak musí mít netagovaný port pro sebe).

Myslíte, že podle toho obrázku v příloze je to špatně nastavené?

[Michal Kubeček]

Ten obrázek toho moc neříká, to je jen screenshot nějakého konfiguračního rozhraní jakéhosi zařízení, to je něco platné jen tomu, kdo zná to konkrétní zařízení. Užitečnější by byl nákres, jak a kam jsou jednotlivá síťová rozhraní zapojena a jaké jsou mezi nimi vztahy.

[Petr Maleček]

Konkrétní zařízení není potřeba znát, konfigurace je pro všechna zařízení s OpenWRT totožná. Obrázek jasně říká rozdělení portů a konfiguraci VLAN, tam je to také zcela zřejmé. CPU je potřeba jen v případě, že chceme nějak provoz na daném rozhraní / VLANě ovlivňovat, což já nechci, chci to jakýsi vlan-bridge.

[Michal Kubeček]

Obrázek jasně říká rozdělení portů a konfiguraci VLAN, tam je to také zcela zřejmé.

Vám možná, mně ne. Ne každý běžně konfiguruje OpenWRT přes grafické (webové?) rozhraní.

chci to jakýsi vlan-bridge

V tom případě je problém téměř jistě v tom, co jsem jako hypotézu napsal hned v prvním příspěvku.

[Petr Maleček]

Jasně, to bylo asi řečeno trošku s nadsázkou. Spíše nechápu co by se tam mělo cyklit, když ten port pro IPTV není součástí žádné jiné VLANy a není ani nijak řízen CPU.

[Petr Šobáň]

Právě že tam může být nějaká zrada z default nastavení.

Jinak ten setobox funguje když ho připojíš přímo na kabel od providera?

Co nechat ten wan a lan pro IPTV untaget oba prostě co přijde na WAN projde na lan IPTV.

Co nastavení firewallu a ty zony nemůže být někde tam zrada v blbém propojení vlan a zon ve firewallu + nat.

Prostě podle mě tam nějaká smyčka bude, třeba zjistit kde....

Prostě co na wan portu dát na internet off a pak to blbne taky (je jasné že nepůjde internet). Tak stejně pak skusit internet že dáš off na IPTV a pak se to zacyklí taky?

Co tak skouknout jaké eth zařízení tam jsou vytvořené ip addr atd....

[Petr Maleček]

Nene, nefunguje, získává IP z DHCP na té VLANě 11, včetně multicast provozu. I internetový provoz má svou VLANu (999).

[Michal Kubeček]

Jestli je to switch, bude se to chovat jako bridge i bez toho, aby pakety zpracovával CPU. Jestli dobře chápu ten obrázek, tak jste netagovanou síť nastavil na jeden port switche a VLAN na druhý, takže je máte v bridgi automaticky. Když tohle uděláte na dvou místech, máte smyčku se všemi negativními důsledky.

[Petr Maleček]

Nastavil jsem TAGovanou VLANu 11 z WAN portu na samostatný neTAGovaný port pro IPTV (STB neumí VLANy, proto potřebuje "surová" data na portu). CPU jsem nechal mimo, neměl by tam být potřeba.

Nevím, co by se tam mělo jiného cyklit. Mělo by to přece fungovat jako kdybych to připojil přímo na port od providera (a ten by do něj pouštěl přímo data z VLANy 11).

Nebo se pletu?

[Petr Šobáň]

Prostě tam smyčka někde je.

Tak prostě skuste ten router použít pouze jako switch, z wan udělat vlan na jeden port kde bude IPTV a druhý vlan z wan na druhý port kde bude internet a cpu uplně vynechat zda pak stb a PC pošlape.

Samozřejmě nezapomeň si třeba z lan5 udělat vlan na cpu ať to můžeš ovládat....

[Petr Šobáň]

Prostě budeš tam mít nějakou smyčku jak už psal na začátku.

Skoukni toto: Konfiguracja switcha i vlan na podstawie swconfig w routerze WR1043ND pod OpenWrt

Vlastně poslední příklad je něco podobného o co se snažíš, ovšem tam je IPTV tagovaná i na CPU pokud jsem to sledoval správně....

Hlavně skoukni eth zařízení jak jsou provázaná s vlany tam podle mě někde bude zrada.

[Petr Maleček]

Přesně takhle to mám nastavené, jen s tím rozdílem, že IPTV nemám na portu 4, ale na portu 1. Konfiguračně správně. Spíše si říkám, jestli nemůže být nějaký bug v modulu jádra.

[lertimir]

doinstalovat tcpdump a monitorovat pakety. Samozřejmě ne tak že monitoruji rozhraní na kterém tcpdump bude reportovat. Pak se uvidí cos e děje.

[Michal Kubeček]

Samozřejmě ne tak že monitoruji rozhraní na kterém tcpdump bude reportovat.

To ničemu nevadí, jen je potřeba použít vhodný filtr.

[lertimir]

Souhlas, ale jednodušší bude, když si na vnějším rozhraní odmonitoruje všechno a pošle to do někého storage na lokální síti a pak si to v klidu prohlédne co se děje. Jinak je to zase křištálová koule.

[Petr Maleček]

Rozumím, díky. Zatím to řeším tak, že VLANu s internetem (999) i nadále NATuje tento router a zároveň WAN port bridguji do druhého portu, kam je připojen jiný router (Netis), který už obhospodařuje VLANu 11 a S-T-B. Takhle to funguje. Je to sice hnusné řešení, ale nemám moc prostoru ke zkoumání, protože tento provoz, který to generuje ovlivňuje všechny klienty poskytovatele (což si nemůžu dovolit).

[Petr Šobáň]

Čili je jasné že tam ta smyčka je.

Prostě proč se tu bavíme pouze kdyby a možná atd......

To je takovej problém sem dát konfiguráky aby se daly shlédnout a možná se přišlo na problém? Přímo na www se dá vygenerovat konfigurák a sem jako přílohu přiložit, samozřejmě hesla můžeš ze souboru smazat.

[Michal Kubeček]

Mě to připadá za směšné. Je to jak léčení u léčitele, který na mne bude vkládat ruce a sledovat "energie" misto toho zajít k lékaři, který odebere krev a laboratorně ji vyšetří a následně se rozhodne, jak postupovat. Smyčka tam je, ale není jasné, jaké pakety v ní kolují. Dokážu si i představit situaci, kdy chyba není u vás, ale u poskytovatele. S tím, že mnoho těch malých krabiček, má některé věci oflikované, tak se u nich chyba neprojeví a korektní implementace RFC v openWRT odpoví tak, že se chyba projeví.

Kdykoliv jsem měl jakékoliv problémy na síťové komunikaci, kdy se to chovalo jinak než jsem očekával, jsem primárně odchytával pakety a zjišťoval, co se děje, protože jen tak se dalo zjistit, proč.

[Petr Maleček]

Já jsem to nakonec vyřešil. Vůbec netuším, jestli je chyba přímo v LUCI, nebo jestli jsem jen něco špatně pochopil, ale zde je řešení:

https://forum.openwrt.org/viewtopic.php?pid=316565#p316565

Nesedělo mi číslo option vlan a option vid, takže se pravděpodobně směřoval provoz jinam, než měl. Ale proč to nesedělo, to netuším.