VLAN tagging script általi automatizálása.

Fórumok

Sziasztok!

Adott egy 10 darab kijelzőből álló információs rendszer, ahol eddig csak statikus adatok jelentek meg egy hdmi-to-ip alapú extenderekből álló rendszer által.
Adott egy darab pc, amely hdmi kábelen átadja egy TX HDMI-TO-IP Extendernek a jelet, ez a TX egység egy Zyxel GS-1900-24 Portos switchbe csatlakozik be, és az ugyanacsak ebbe a switchbe csatlakozó RX egységek innen kapják a TX által küldött jelet és játszák tovább HDMI kimeneten a TV készülékek felé a statikus adatokat.

A switch managelhető, így vlanokra bontva 2 tx jelét is ki lehet küldeni a tv készülékekre, oly módon, hogy az 1es port a 2002-es VLAN csoport tagja a 3-5-7-9-11 portba csatlakozó RX egységekkel, a 2es port pedig a 3003-as VLAN csoport tagjaként a 4-6-8-10-12 portba csatlakozó tv készülékeknek küldi az adatokat, amelyek már nem statikusak, hanem napi szinten változnak, és egy mediaboxról kerülnek lejátszásra.

A vezetőség kitalálta, hogy ez így nem jó, mert nem eléggé figyelemfelkeltő, ezért azt kellene szerdáig megoldanom, hogy az 1-es és 2-es portba legyenek továbbra is a TX azaz a jelküldő egységek, a 2002-es VLAN csoportban, majd a 3-4-5-6-7-8-9-10-11-12 portba csatlakozó tv készülékek pedig kerüljenek a 3003-as VLAN-ba, ezt követően pedig 30 másodpercig az 1-es port legyen a 3003-as VLAN csoport tagja, utána pedig ez kerüljön ki, és a 2-es port legyen a 3003-as VLAN csoport tagja a további 30 másodpercben, azaz fél percig az egyik adóról jelenjen meg információ, fél percig pedig a másik adóról.

A switchet lehet web management alapon managelni, illetve telneten.

Eddig még soha nem volt alkalmam ilyen jellegű scriptet írni, mert ugye egy alap hálózat nem igényli a folyamatosan VLAN csoportok módosítgatását, főként nem 30 másodpercenként.

Az pedig, hogy a switch csak telneten fogad parancsokat, számomra elég érdekes, soha nem scripteltem még telneten, csak alap diagokat futtatam általa.

Szerintetek bírna egy ilyen switch erőforrással a folyamatosan VLAN csoportok módosítgatását, illetve, ti hogyan kezdenétek neki ennek az automatizálásnak?

Köszönöm a segítséget előre is.

Hozzászólások

Maga a terv elég ... -nak hangzik elsőre.

De telnet-es scripteléshez ez jó lehet, ha meg tudod szerezni:
"Python Network Programming for Network Engineers"

UPD: Ha megnézed, pont van egy ingyenes preview rész a telnetes témában, az is elég lehet.

Mé' a pájton?! Tudom, akinek f...a van, annak mindenről a 3.14..a jut az eszébe :-)
Én leraknám a switch valamennyi állapotához tartozó konfigot egy tftp-szerverre, és expect-tel lejátszanám telnet-en a konfigurációnak tftp-ről a switchre lehúzását. Ezzel az összes beállítást normálisan lehetne reszelni/bővíteni - egy nagyonhűdeokos switch konfigja sem ordenáré randa és bonyolult - ha épp úgy adódik, hogy lóugrásban kell a vlan-oknak változni, akkor olyan confokat kell generálni, oszt' jónapot.

Igen, agyroggyantnak néz ki az egész, de vedd úgy, hogy a switch egy n portos HDMI-átkapcsoló, amiben tetszőleges kombinációban össze lehet kapcsolni az egyes eszközöket, és máris ésszerű megoldás - a csilliom Ft-ba fájó hasonlóan rugalmas és számítógéppel vezérelhető natív hdmi switchboxhoz képest.

Az snmp jó - lehet. Viszont ehhez kell egy olyan "körítés", ami egy jól értelmezhető/kezelhető konfigurációs fájlban/fájlokban lévő beállításokat juttat alkalmanként érvényre - illetve kell hozzá megfelelő szintű perverzió, hogy az snmp-t úgy a szükséges szinten megértse/átlássa a kérdező, és megtanulja használni ilyen célra... Márpedig ez utóbbi erősen a sajtreszelős szint szerintem...

> Én leraknám a switch valamennyi állapotához tartozó konfigot egy tftp-szerverre, és expect-tel lejátszanám telnet-en a konfigurációnak tftp-ről a switchre lehúzását.

"Mé'?! Tudom, akinek f...a van, annak mindenről a 3.14..a jut az eszébe :-)" ;-)
Tuti isten, hogy expecthez csak akkor nyúlnék, ha nincs semmi normálisan megszólítható "API".

Nem tudod inkább a vevőket baszogtatni, hogy honnan vegyék az adást? Vagy egy vevőadó (szerk.), és annak a bemenő jelét változtatod inkább? Egyébként így nem akadna meg a kép 30 másodpercenként, amikor váltasz?

Én ezt tuti felsőbb rétegben oldanám meg.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Telnetes konfigot nagyon jól lehet automatizálni expect-el, azt meg crontabból.

Ez tuti fix, hogy idióta management ötlet. Ne menj bele szerintem. Szakmailag nem kivitelezhető szépen és csak a szart építed magasabbra sztem. a fent vázolt megoldással. A sima switch nem erre van kitalálva szerintem, hogy VLAN-okat kapcsolgass rajta 30 másodpercenként.

Sajnos nem vagyok otthon kimenetek mixelésében, de biztos van rá hardver/szoftver, ami ezt képes normálisan stream-be szervezni és a megfelelő kijelzőkre kitolni. Ez már innentől nem informatika kérdés :)

Mikrotik alatt meg lehetne oldani, van feladatütemezője.

Én egy ilyen telnet-es cuccot annó Java-ból buzergáltam (telefonközpont hajnali újraindítása), de szerintem bármely nyelv alól lehet, csak kell egy szerver, amin futkorászik.
Annyi a nyűgje még a telnetnek, hogy be kell iktatni x másodperc várakozási időket a felhasználónév majd a jelszó megadása után, mert kvázi vakon jelentkezik be a kliens és nem teljesen tudni, (ha csak nem akarod elemezgetni a switch telnet üzeneteit), hogy mikor engedett be az eszköz.

Ha kicsit is kézre áll neked a RouterOS, akkor meg nézz ki egy olcsóbb SW-t és tedd a vezetés elé, hogy ez kell a projekthez. Bár VLAN terén az olcsóbb Mikrotik cuccok elég lassúak, igaz lehet külön az sw chippet is konfigolni, csak az bonyolultabb.

php-val nagyon egyszeruen megcsinalhatod (hibakezeles nincs benne, azt ird meg hozza):


$socket = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
$result = socket_connect($socket, $address, $service_port);
$in = "conf t\n";
socket_write($socket, $in, strlen($in));
usleep(100000);
$in = "int Gi1/12\n";
socket_write($socket, $in, strlen($in));
usleep(100000);
$in = "switchport access vlan 2002\n";
socket_write($socket, $in, strlen($in));
usleep(100000);
socket_close($socket);

ez a hdmi over ip ilyenkor udp-n beszelget? fog az mukodni hogy a vevo hirtelen elkezd egy masik "streamet" kapni? kiprobaltad hogy mi tortenik ha csak siman atdugod egyik portbol a masikba a kivetito?

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Az, hogy mit csinál egy access portnál akkor, ha egy másik vlan-ra konfigurálod ilyen módon, az a switch firmware-étől (meg akár annak a verziójától is) függ. Pont emiatt problémás egyesével mókolni a beállításokat, mert pontosan kell tudni, hogy egy adott parancsra valójábanmi történik. Ha a switch cli-jét használja, akkor a tftp-ről visszatöltött konfiggal jobban jár...

Az snmp persze ezért is jó - viszont az oid-ekkel bűvészkedés azért elég riasztó első körben - pláne úgy, hogy a-fene-se-tudja, valójában mi micsoda, illetve hogy később lesz-e olyan elmeroggyant ötlet, amit bele lehetne/kéne reszelni ebbe a konfigváltogatóba, de snmp-n nem sikerül majd összerakni.
Ronda a konfigfájlokat visszatöltögetni - az viszont tény, hogy az egyes beállítási "csomagokat" jóval egyszerűbb szerkesztgetni, illetve szükség esetén kézzel beavatkozva berántani a switchbe.

Itt többen leírták, hogy milyen technológiákat lehet arra használni, hogy a switchet átkonfiguráld.
Én viszont felteszem a kérdést: vajon ki lett-e próbálva, hogy egy vlan váltás után hány másodpercig nincs kép? Mert ha engem kérdezel, a vlanozás nem erre való. Ebből következően ez így vagy fog működni, vagy nem.

Hülye ötlet, de biztos csak telnet van, SNMP nincs?

Én csináltam hasonlót, D-Link DES-1228 switchekre toltam le a VLAN konfigot egy scripttel, adatbázisból, SNMP-n. Igaz nem 30 másodpercenként, hanem óránként, de jól működött.

szerk: Ez alapján: https://businessforum.zyxel.com/discussion/486/gs1900-8hp-snmp-support akár működhet, próbálj rá SNMP-n hogy tudod-e állítani a VLAN-okat.

"Szerintetek bírna egy ilyen switch erőforrással a folyamatosan VLAN csoportok módosítgatását, illetve, ti hogyan kezdenétek neki ennek az automatizálásnak?"
10 darab Rasberry PI hálózatba kötve...

A VLAN kapcsolgatást felejtsd el.

Ma ki szerettem volna próbálni, hogy mennyi idő alatt vált csatornát a fogadó eszköz.

A Switch 1-12 portjai az 1es default VLAN-ba tartoztak, itt pedig 13 porttól 23-as portig excluded lett, a 2es kézileg létrehozott VLAN-ban pedig 1-12as port excluded állapotra tettem, 13-23 portok pedig tagged állapotra állítottam.

A Switch fizikai 1es portjára az egyes adó eszköz csatlakozik, a 13as portra pedig a 2es adó.
4 TV-t tettem az egyes vlanba, és 4et a 2es vlanba, így 4tvn kellett volna, hogy megjelenjen az 1es adóról küldött adat, 4tv-n pedig a 2es adóról küldött adat.

Ennek ellenére mind a 2 adóról ment volna minden tv-re az adat, de nem tudtak a keszulekek eldönteni, hogy honnan kapjak az adatot, így az egész csak villódzott, és pixelesedett.

Soha nem kellett még VLAN-t konfigurálnom, így teljesen kezdő vagyok ezen a téren.
A switchen minden módosítást mentettem, az erőforrás használata is normális, nyilván nem ezért nem működik a dolog.

Mit rontok el szerintetek, gondolom nem jól konfigurálom a vlanokat, de ötletem sincs, hogyan kellene úgy beállítanom, hogy 1-12 ig illetve 13-23 tól külön 2 vlan legyen.

A segítségeteket előre is köszönöm!

n+1 snmp

Sokkal kormonfontabb dolgok is megoldhatok vele, erteni kell az nem hatrany.

Egyetertenek azokkal, akik szerint a VLAN nem egeszen erre valo. Talan jobb megoldas volna egy tagged VLAN port, ahol pl. egy RPi veszi a ket streamet es valtogat koztuk.

Adodik, hogy a switch csak erre lesz hasznalva. Barmilyen hozzad kozeli nyelven (akar bash) is megirhatod a scriptet es eltotyog majd szepen. Nem kell sok konfigot menteni tftp-re es akkor az osszes tobbi beallitast kezelheted weben keresztul is. Nem kell hozza SNMP-t se tanulni, csak egy kis pepeceles a kedvenc script nyelveden.
Ket kerdes merul fel nalam:
- Mennyi ideig tart, amig VLAN valtasnal atall a vevo az uj jelre?
- A switch minden config valtozast ment majd a flash memoriajabe. Tegyuk fel, hogy az olcso menedzselt switchben hasznalt memoriacsip 1M torles/ujrairas ciklust bir el es minden modositas 2 irast eredmenyez. Ha nem szamoltam el magam, akkor kb.6-7 havonta cserelheted a dobozt egy ujra. Rendelj elore legalabb 4-5 dobozt, mert nagyon nem lesz kedved rendszeresen ujrairni a progidat. (amit megintcsak futtatni kell valahol - RPi?)

Nem ismerem a HDMI2IP dobozkatokat, de egy kis jatszadozassal megfejtheto, amire szukseged van. Ha nem te, akkor egy programozo osszetaknyolhat 1-2 nap alatt egy par soros programot, ami a ket stream kozott vakon valtogat. De ez meg mindig nem oldja meg az elso kerdest. Azt ki kene probalni.

Nem ismerem a HDMI2IP dobozkatokat, de egy kis jatszadozassal megfejtheto, amire szukseged van. Ha nem te, akkor egy programozo osszetaknyolhat 1-2 nap alatt egy par soros programot, ami a ket stream kozott vakon valtogat. De ez meg mindig nem oldja meg az elso kerdest. Azt ki kene probalni.

Esélyes, hogy még programozó sem kell hozzá, elég egy jól felparaméterezett ffmpeg, ha lusta volt a cucc gyártója saját protokollt/crypto-t beletenni (én így használom egy ilyen HDMI-over-IP cucc adó felét hdmi capture eszközként, fogadó oldalon ffmpeg/VLC/OBS Studio-val :) ).

Ha nincs sehol specifikálva, hogy mit használ, akkor wireshark és lehet nézegetni a forgalmat, ha bármi standard izé, akkor ffmpeg tud rá jelet küldeni :)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)