Az OSPF designated router (DR) illetve backup DR (BDR) választás a broadcast/multicast képes interfészeken RouterOS alatt sem mindig úgy történik, ahogy az ember előre elképzeli, elég egy kis figyelmetlenség, az eszközök rossz sorrendben való konfigurálása, vagy egy kimaradt prioritás paraméter, és máris olyan eszközre kerülhet a DR funkció, ahol nem szeretnénk látni. A Cisco IOS-es megoldásokat, vagy éppen furcsaságokat több helyen el lehet olvasni, a Mikrotik RouterOS doksikban, fórumokon viszont nincs bő lére eresztve az ezzel kapcsolatos tudnivaló.
Mivel az OSPF interfészeken kézzel beállítható prioritás nem preemptív, és a routerek az éppen beállított prioritástól függetlenül elfogadják a már élő DR-t, alapvetően RouterOS alatt sincs más dolgunk, mint valahogy elérni, hogy az OSPF neigborship megszakadjon, és ezzel kierőszakoljuk a DR/BDR választást.
Talán a legegyszerűbb, és egyben a legrondább megoldás a megfelelő sorrendben újraindítgatni a Mikrotik eszközeinket. Egy modern RouterBoard, amin gigaherzes processzorok vannak, szó szerint másodpercek alatt újra tud bootolni. Nyilván ez nem minden környezetben kivitelezhető, ennél sokkal elegánsabb megoldás az, ami nagyjából a "clear ip ospf process" IOS parancsnak feleltethető meg (feltételezve, hogy csak egyetlen OSPF példányunk fut):
/routing ospf instance
/routing ospf instance> disable default; enable default
Amennyiben még ez is túlságosan destruktív parancs lenne, lehetséges az OSPF interfész reset (a fizikai interfész konfigurációjának piszkálása nélkül):
/routing ospf interface
print (az interfészek listájához)
disable 0; enable 0
Ugyanezek a dolgok hasonló útvonalon elérhetőek a grafikus felületen, WinBoxban is, azonban a kattintgatásoknál jó, ha tisztában vagyunk vele, hogy amennyiben a management IP-hez is OSPF route-okon férünk hozzá, akkor esetleg megszakadhat az admin sessionünk mielőtt visszaengedélyezzük az adott interfészt. A legjobban persze akkor járunk, ha még az OSPF neighborship kialakulása előtt bevéssük a konfigba a prioritást (1-255), és a "jó" sorrendben konfiguráljuk az OSPF-et az eszközeinken :)
/routing ospf interface
add interface=ether2 priority=255 disabled=no
2013-11-15
BGPlay: mikor és mi történt a UPC hálózatával?
Biztos többen emlékeznek, hogy UPC hálózatával nemzetközi irányokban komoly problémák voltak november első két napjában. Nemrég bukkantam rá a BGPlay nevű Java utilra, amivel a BGP AS prefix hirdetéseket, path változásokat és visszavonásokat lehet a RouteViews projekt naplói alapján historikusan nyomon követni egy megadott prefixre. Általában nem szeretem a grafikus eszközöket, de ez tényleg klassz. Nézzük meg, hogy mi történt a UPC ASN6830-ból eredő 89.134.0.0/15 prefixszel a BGPlay-ben elérhető összes adatforrás szerint:
Felül az információs sávban látszik az időpont, az AS path változás, illetve annak a BGP peernek az IP-je, ahonnan az adott információ be lett gyűjtve. A grafikonon minden egyes AS path-t egy-egy vonal jelöl, ami áthalad az érintett AS-eken. A szaggatott vonalak azt jelzik, hogy az adott időintervallum alatt az adott AS path nem változott, míg színes, folyamatos vonalak a változásokat mutatják.
A HUP.hu fórum vonatkozó témájában azonban egy ennél is jobb eszközt linkeltek be. A RIPE májusban adott ki közleményt arról, hogy az eredeti BGPlay-t továbbfejlesztett formában elérhetővé teszi. A szervezet által működtetett BGPplay változat nagyobb adatforrásból dolgozik, a felület is tovább finomodott, így az előzőnél is látványosabb, ahogy a 34655-ös DoclerWeb AS eltéríti a 89.134.0.0/15 prefixet.
Előtte:
Utána:
Felül az információs sávban látszik az időpont, az AS path változás, illetve annak a BGP peernek az IP-je, ahonnan az adott információ be lett gyűjtve. A grafikonon minden egyes AS path-t egy-egy vonal jelöl, ami áthalad az érintett AS-eken. A szaggatott vonalak azt jelzik, hogy az adott időintervallum alatt az adott AS path nem változott, míg színes, folyamatos vonalak a változásokat mutatják.
A HUP.hu fórum vonatkozó témájában azonban egy ennél is jobb eszközt linkeltek be. A RIPE májusban adott ki közleményt arról, hogy az eredeti BGPlay-t továbbfejlesztett formában elérhetővé teszi. A szervezet által működtetett BGPplay változat nagyobb adatforrásból dolgozik, a felület is tovább finomodott, így az előzőnél is látványosabb, ahogy a 34655-ös DoclerWeb AS eltéríti a 89.134.0.0/15 prefixet.
Előtte:
Utána:
2013-11-14
SDM template-ek Cisco switcheken
Meglehetősen könnyű olyan esetekbe belefutni Cisco switcheken, amelyek az SDM template módosítását igénylik, tipikusan ilyenek:
A CAM vagyis Content Addressable Memory olyan jószág, amely a neki átadott adatot (switchnél MAC címet) keresi meg a memóriaterületen és visszatér azzal a címmel (switch esetén portindex) ahol egyezést talált. A RAM-ok épp fordítva működnek: az általunk megadott címről olvasunk ki adatot, és nem az adattal keressük ki a címet. A switchek a CAM memória segítségével tudják villámgyorsan, hardveresen megállapítani, hogy mely portjukra kell az adott cél MAC című keretet továbbítani.
A TCAM-ok, azaz ternary, hármas CAM-ok a bináris CAM-októl eltérően, amelyek csak nullákat vagy egyeseket képesek tárolt adatként elfogadni, használnak egy harmadik, "nem számít" állapotot is az adat tárolása során. A TCAM ideális memóriatípus a például a route táblákban való keresések hardveres gyorsítására. Ha CPU-val végezzük a route táblában való keresést, akkor a cél IP-t össze kell ÉS-elgetni a route tábla minden egyes bejegyzéséhez tartozó maszkkal, majd az így megkapott hálózatcímet összehasonlítani az adott route bejegyzéssel, amíg egyezést nem találunk. A TCAM esetén a megfelelő biteket (a route tábla bejegyzéseinek host bitjeit) "nem számít" állapotban tárolva a továbbítandó csomag cél IP-je azonnal illeszkedik a megfelelő bejegyzésre, így nem kell minden egyes route tábla bejegyzéshez ÉS műveleteket majd egy összehasonlítást is elvégeztetni a CPU-val.
Ha a CAM megtelik egy switchben, akkor az eszköz nem tud új MAC címeket betanulni, így a még nem ismert eszközök MAC címeivel érkező kereteket minden portján továbbítani fogja, azaz floodolja. Ha a TCAM telik meg, akkor az újabb, a TCAM-be már nem férő route bejegyzések feldolgozása CPU-ból történik meg, ami jelentős terhelést ró az általában nem túl izmos switch CPU-ra. Minkét esetet érdemes elkerülni, ebben segít a Cisco switcheken az SDM template, hogy a rendelkezésre álló CAM és TCAM erőforrásokat az igényeinknek megfelelően, hatékonyan tudjuk a felhasználási területek közt szétosztani. Az ezzel kapcsolatos két legfontosabb parancs a "sh sdm prefer" enable módban, illetve az "sdm prefer" konfig módban. A template módosítás után mindig újra kell indítani az eszközt a beállítások érvényre jutásához.
DEVICE#show sdm prefer
The current template is "desktop routing" template.
The selected template optimizes the resources in
the switch to support this level of features for
8 routed interfaces and 1024 VLANs.
number of unicast mac addresses: 3K
number of IPv4 IGMP groups + multicast routes: 1K
number of IPv4 unicast routes: 11K
number of directly-connected IPv4 hosts: 3K
number of indirect IPv4 routes: 8K
number of IPv4 policy based routing aces: 512
number of IPv4/MAC qos aces: 512
number of IPv4/MAC security aces: 1K
DEVICE#conf t
Enter configuration commands, one per line. End with CNTL/Z.
DEVICE(config)#sdm prefer ?
access Access bias
default Default bias
dual-ipv4-and-ipv6 Support both IPv4 and IPv6
routing Unicast bias
vlan VLAN bias
A poszt elején említettem, hogy az SDM template módosításával a Cisco 2960-asok is Layer3-as képességekkel ruházhatók fel, egy volt kollégám mutatta ezt kb. másfél éve. Csodákra azért ne számítsunk, a 2960-ason nem lesz se PBR, se dinamikus routeolás, statikus route-okból is csak max. 16 darab, kizárólag SVI interfésszel. Szoftverigény: legalább LANBASE 12.2.55 IOS.
- 2960-ason statikus routolás (igen!)
- 3560-ason PBR
- 3560/3750-esen IPv6 routeolás
A CAM vagyis Content Addressable Memory olyan jószág, amely a neki átadott adatot (switchnél MAC címet) keresi meg a memóriaterületen és visszatér azzal a címmel (switch esetén portindex) ahol egyezést talált. A RAM-ok épp fordítva működnek: az általunk megadott címről olvasunk ki adatot, és nem az adattal keressük ki a címet. A switchek a CAM memória segítségével tudják villámgyorsan, hardveresen megállapítani, hogy mely portjukra kell az adott cél MAC című keretet továbbítani.
A TCAM-ok, azaz ternary, hármas CAM-ok a bináris CAM-októl eltérően, amelyek csak nullákat vagy egyeseket képesek tárolt adatként elfogadni, használnak egy harmadik, "nem számít" állapotot is az adat tárolása során. A TCAM ideális memóriatípus a például a route táblákban való keresések hardveres gyorsítására. Ha CPU-val végezzük a route táblában való keresést, akkor a cél IP-t össze kell ÉS-elgetni a route tábla minden egyes bejegyzéséhez tartozó maszkkal, majd az így megkapott hálózatcímet összehasonlítani az adott route bejegyzéssel, amíg egyezést nem találunk. A TCAM esetén a megfelelő biteket (a route tábla bejegyzéseinek host bitjeit) "nem számít" állapotban tárolva a továbbítandó csomag cél IP-je azonnal illeszkedik a megfelelő bejegyzésre, így nem kell minden egyes route tábla bejegyzéshez ÉS műveleteket majd egy összehasonlítást is elvégeztetni a CPU-val.
Ha a CAM megtelik egy switchben, akkor az eszköz nem tud új MAC címeket betanulni, így a még nem ismert eszközök MAC címeivel érkező kereteket minden portján továbbítani fogja, azaz floodolja. Ha a TCAM telik meg, akkor az újabb, a TCAM-be már nem férő route bejegyzések feldolgozása CPU-ból történik meg, ami jelentős terhelést ró az általában nem túl izmos switch CPU-ra. Minkét esetet érdemes elkerülni, ebben segít a Cisco switcheken az SDM template, hogy a rendelkezésre álló CAM és TCAM erőforrásokat az igényeinknek megfelelően, hatékonyan tudjuk a felhasználási területek közt szétosztani. Az ezzel kapcsolatos két legfontosabb parancs a "sh sdm prefer" enable módban, illetve az "sdm prefer" konfig módban. A template módosítás után mindig újra kell indítani az eszközt a beállítások érvényre jutásához.
DEVICE#show sdm prefer
The current template is "desktop routing" template.
The selected template optimizes the resources in
the switch to support this level of features for
8 routed interfaces and 1024 VLANs.
number of unicast mac addresses: 3K
number of IPv4 IGMP groups + multicast routes: 1K
number of IPv4 unicast routes: 11K
number of directly-connected IPv4 hosts: 3K
number of indirect IPv4 routes: 8K
number of IPv4 policy based routing aces: 512
number of IPv4/MAC qos aces: 512
number of IPv4/MAC security aces: 1K
DEVICE#conf t
Enter configuration commands, one per line. End with CNTL/Z.
DEVICE(config)#sdm prefer ?
access Access bias
default Default bias
dual-ipv4-and-ipv6 Support both IPv4 and IPv6
routing Unicast bias
vlan VLAN bias
A poszt elején említettem, hogy az SDM template módosításával a Cisco 2960-asok is Layer3-as képességekkel ruházhatók fel, egy volt kollégám mutatta ezt kb. másfél éve. Csodákra azért ne számítsunk, a 2960-ason nem lesz se PBR, se dinamikus routeolás, statikus route-okból is csak max. 16 darab, kizárólag SVI interfésszel. Szoftverigény: legalább LANBASE 12.2.55 IOS.
2013-09-25
Nyolcportosok
Benne vagyok mostanában egy "mikro switch" projektben, amelynek a célja az, hogy minden nem menedzselhető hálózati eszköz eltűnjön az általunk felügyelt hálózatokból. Azon kár is töprengeni, hogy ilyesmi elvileg nem alakulhat ki: ahol ethernet végpont igény van, oda ki kell építtetni a strukturált hálózatot, a területet lefedő rendezőben pedig az igényeknek megfelelően bővíteni a menedzselhető eszközök kapacitását. Tudjuk azonban, hogy a szakmai szempontokat gyakran felülírják egyéb szempontok, és sajnos minden látszat ellenére a legtöbb cégnek nem alapvető célja a hálózatos kollégák állandó kütyüigényének kielégítése, helyette vannak az úgynevezett ügyfelek meg a termelési folyamat és az ezen entitásokkal való bíbelődés leköti a céges erőforrások jelentős részét. Kemény világ ez, olykor szemet kell hunynia a network adminnak bizonyos dolgok felett. Egy ilyen mikro switch projekt annak a részleges beismerése, hogy mégis a network adminnak volt igaza, nyilván a teljes beismerés a strukturált alapokhoz való visszatérés lenne. :)
A problémák tűzoltásszerű megoldásához tehát x db. nyolcportos switchre van szükség. Az elvárások nagyjából arról szólnak, hogy menedzselhető legyen az eszköz, tudjon VLAN-okat, (M|R)STP-t, Syslogot, SNMP-t, (S)NTP-t, minden más, amit tudnak a szóba jöhető típusok, pl. rackelhetőség, SFP hely, 802.1x támogatása, management login RADIUS authentikációval, már csak extra. Nincsenek korlátok, előítéletetek a gyártók tekintetében, és büdzsé természetesen korlátozott. Két olyan eszközt szeretnék röviden bemutatni a merítésből, amit ezért vagy azért érdekesnek találtam.
Az egyik a HP 1910-8G (JG348A). Ahhoz képest, hogy a HP smart switchként árulja ezt az eszközt, meglepően hosszú a támogatott protokollok listája, ráadásul van benne CLI, amit konzolon, telneten és SSH-n is lehet támadni. Első ránézésre a CLI ki van herélve: lehet benne pingelni, IP-t, jelszót és firmware-t cserélni, minden másra pedig ott a webGUI. Némi fórumolvasgatás után kiderült, hogy a HP a jelenleg kapható legokosabb smart switchébe rendes, a 3Com-H3C-Huawei vonalról ismert Comware oprendszert tett, a lebutított felület pedig egyetlen paranccsal visszaváltoztatható:
<TESZT>_cmdline-mode on
All commands can be displayed and executed. Continue? [Y/N]y
Please input password:******
Warning: Now you enter an all-command mode for developer's testing, some commands may affect operation by wrong use, please carefully use it with our engineer's direction.
<TESZT>
A butítást feloldó jelszó "512900", ez a nyáron kiadott legújabb firmware-rel (Comware Software, Version 5.20, Release 1513P62) is megy. Aki nem túl jártas a Comware-ben, az a HP-nél talál egy Procurve-Comware-IOS gyorstalpalót. A verdikt tehát annyi, hogy jelenleg ez a piac legolcsóbb nyolcportos switche, amiben tejes értékű OS található, és gyakorlatilag mindent tud, amire egy ilyen access switchet értelmes keretek közt használnánk, IPv6, LLDP, LACP, MSTP, STP root guard, BPDU protection, loopback detection, 802.1x, Layer 3-as VLAN interfészek, 32 db. statikus route... stb. Mindez egyébként a webes felületen is egész jól beállítható. Hab a tortán, hogy teljes CLI van a rendszerben, még ha nem is támogatott módon. Egy problémát fedeztem fel teszt közben: a legújabb firmware verzióval két-három kattintás után kidob a switch a webes felületről Firefoxban és IE-ben is, Chrome-mal viszont működik. A szoftverfrissítést tehát nem érdemes elkapkodnunk, ennek ellenére jelenleg a nyolcportosok közt ár-érték arányban minden másnál jobb ez a típus.
A másik típus, amit figyelemre méltónak tartok (nagy levegő...), a TP-Link TL-SG3210, a gyártó JetStream sorozatából. Szemérmetlenül azt állítják, hogy ez egy enterprise switch, ami nem teljesen igaz ugyan, de meglepően jó úton járnak, és lehet, hogy pár év múlva a JetStream sorozat tagjai már nem fognak kilógni sorból. Jelen állapotában nem ajánlanám jó szívvel komolyabb helyre, inkább egy picit több pénzért vegyük meg például az előbbi HP-t. A TL-SG3210 külsőre nem szép, de nagyon egyben van az eszköz, masszív a ház, két (nem combo) SFP portot kapunk a 8 db. gigás port mellé, rack-es füleket, és a ház aljára felragasztható desktop tappancsokat is találunk a dobozban. Az eszközt konzolporton, SSH-n és weben is tudjuk adminisztrálni, eddig tehát rendben volnánk. Az OS sok tekintetben IOS-szerű, van parancs history, enable mód, config mód, itt-ott picit más a parancs neve, különös a kínai szintaxis, de a CLI guide olvasgatása nélkül is elboldogul az ember. Nem kell azonban túl sokáig használni a switchet ahhoz, hogy szépséghibákra (pl. ok nélkül hosszú parancsokra), sőt olykor komolyabb hiányosságokra bukkanjon az ember.
Azon nem akadtam fent, hogy a soros porton nem tudom a session-t "exit"-tel bezárni, mert azonnal visszalép, ez már csak ilyen. Az viszont kifejezetten bosszató volt, hogy az első tesztkonfigot, amit összeállítottam, eldobta a firmware frissítésekor, azaz egyik verzióról a következőre való váltáskor egyszerűen visszaállt gyári alap konfigurációra (admin IP: 192.168.0.1), amit enterprise eszköz nem engedhet meg magának. Ez majdnem egyenlő azzal, hogy a switch távolról nem frissíthető. Aztán amit még a rövid próba alatt észrevettem: a log funkcióhoz hiába van hét különböző szint, az 5-ös szintig szerintem semmit sem naplóz, a hatos szinttől viszont még a betanult MAC címeket is bejegyzi, ami a sok felesleges sor miatt használhatatlanná teszi logot. Az SNMP fából nem lehet elérni az FDB-t (CAM tábla), a trunk portokon pedig szó nélkül taggeli a default VLAN-t (van benne viszont olyan, hogy "switchport mode general", ahol VLAN-onként ki-be lehet kapcsolni a taggelést). A 802.1x csak olyan windowsos kliensekkel működik, ahol telepítve van a TP-Link saját "TPSupplicant v2.0" szoftvere. De hogy ne csak a negatívumokat soroljam: a webes felület gyors, logikus, látszik, hogy azt szánták elsődleges adminisztrációs felületnek, és alaposabban tesztelgették.
Összességében különben nem kelt rossz benyomást az eszköz, mégsem mernék a szoftver jelen állapotában komolyabb feladatot rábízni. A release notes-okat átolvasgatva kiderült, hogy a szöveges konfgurációs fájl intézménye a TP-Linknél még nincs egy éves sem, tavaly novemberben debütált a "show running-config" paranccsal együtt, mindez persze megmosolyogtató, de elképzelhetőnek tartom, hogy a legégetőbb hiányosságokat a következő néhány verzióban pótolják, a nyomott áron adott "enterprise" eszközök pedig idővel letarolják a piacot. Az informatikában nem ez lenne az első olyan történet, amikor az alulról jövő, egyre okosodó eszközök egy bizonyos pont után rettenetesen vonzóvá válnak a vásárlók többsége számára.
A problémák tűzoltásszerű megoldásához tehát x db. nyolcportos switchre van szükség. Az elvárások nagyjából arról szólnak, hogy menedzselhető legyen az eszköz, tudjon VLAN-okat, (M|R)STP-t, Syslogot, SNMP-t, (S)NTP-t, minden más, amit tudnak a szóba jöhető típusok, pl. rackelhetőség, SFP hely, 802.1x támogatása, management login RADIUS authentikációval, már csak extra. Nincsenek korlátok, előítéletetek a gyártók tekintetében, és büdzsé természetesen korlátozott. Két olyan eszközt szeretnék röviden bemutatni a merítésből, amit ezért vagy azért érdekesnek találtam.
Az egyik a HP 1910-8G (JG348A). Ahhoz képest, hogy a HP smart switchként árulja ezt az eszközt, meglepően hosszú a támogatott protokollok listája, ráadásul van benne CLI, amit konzolon, telneten és SSH-n is lehet támadni. Első ránézésre a CLI ki van herélve: lehet benne pingelni, IP-t, jelszót és firmware-t cserélni, minden másra pedig ott a webGUI. Némi fórumolvasgatás után kiderült, hogy a HP a jelenleg kapható legokosabb smart switchébe rendes, a 3Com-H3C-Huawei vonalról ismert Comware oprendszert tett, a lebutított felület pedig egyetlen paranccsal visszaváltoztatható:
<TESZT>_cmdline-mode on
All commands can be displayed and executed. Continue? [Y/N]y
Please input password:******
Warning: Now you enter an all-command mode for developer's testing, some commands may affect operation by wrong use, please carefully use it with our engineer's direction.
<TESZT>
A butítást feloldó jelszó "512900", ez a nyáron kiadott legújabb firmware-rel (Comware Software, Version 5.20, Release 1513P62) is megy. Aki nem túl jártas a Comware-ben, az a HP-nél talál egy Procurve-Comware-IOS gyorstalpalót. A verdikt tehát annyi, hogy jelenleg ez a piac legolcsóbb nyolcportos switche, amiben tejes értékű OS található, és gyakorlatilag mindent tud, amire egy ilyen access switchet értelmes keretek közt használnánk, IPv6, LLDP, LACP, MSTP, STP root guard, BPDU protection, loopback detection, 802.1x, Layer 3-as VLAN interfészek, 32 db. statikus route... stb. Mindez egyébként a webes felületen is egész jól beállítható. Hab a tortán, hogy teljes CLI van a rendszerben, még ha nem is támogatott módon. Egy problémát fedeztem fel teszt közben: a legújabb firmware verzióval két-három kattintás után kidob a switch a webes felületről Firefoxban és IE-ben is, Chrome-mal viszont működik. A szoftverfrissítést tehát nem érdemes elkapkodnunk, ennek ellenére jelenleg a nyolcportosok közt ár-érték arányban minden másnál jobb ez a típus.
A másik típus, amit figyelemre méltónak tartok (nagy levegő...), a TP-Link TL-SG3210, a gyártó JetStream sorozatából. Szemérmetlenül azt állítják, hogy ez egy enterprise switch, ami nem teljesen igaz ugyan, de meglepően jó úton járnak, és lehet, hogy pár év múlva a JetStream sorozat tagjai már nem fognak kilógni sorból. Jelen állapotában nem ajánlanám jó szívvel komolyabb helyre, inkább egy picit több pénzért vegyük meg például az előbbi HP-t. A TL-SG3210 külsőre nem szép, de nagyon egyben van az eszköz, masszív a ház, két (nem combo) SFP portot kapunk a 8 db. gigás port mellé, rack-es füleket, és a ház aljára felragasztható desktop tappancsokat is találunk a dobozban. Az eszközt konzolporton, SSH-n és weben is tudjuk adminisztrálni, eddig tehát rendben volnánk. Az OS sok tekintetben IOS-szerű, van parancs history, enable mód, config mód, itt-ott picit más a parancs neve, különös a kínai szintaxis, de a CLI guide olvasgatása nélkül is elboldogul az ember. Nem kell azonban túl sokáig használni a switchet ahhoz, hogy szépséghibákra (pl. ok nélkül hosszú parancsokra), sőt olykor komolyabb hiányosságokra bukkanjon az ember.
Azon nem akadtam fent, hogy a soros porton nem tudom a session-t "exit"-tel bezárni, mert azonnal visszalép, ez már csak ilyen. Az viszont kifejezetten bosszató volt, hogy az első tesztkonfigot, amit összeállítottam, eldobta a firmware frissítésekor, azaz egyik verzióról a következőre való váltáskor egyszerűen visszaállt gyári alap konfigurációra (admin IP: 192.168.0.1), amit enterprise eszköz nem engedhet meg magának. Ez majdnem egyenlő azzal, hogy a switch távolról nem frissíthető. Aztán amit még a rövid próba alatt észrevettem: a log funkcióhoz hiába van hét különböző szint, az 5-ös szintig szerintem semmit sem naplóz, a hatos szinttől viszont még a betanult MAC címeket is bejegyzi, ami a sok felesleges sor miatt használhatatlanná teszi logot. Az SNMP fából nem lehet elérni az FDB-t (CAM tábla), a trunk portokon pedig szó nélkül taggeli a default VLAN-t (van benne viszont olyan, hogy "switchport mode general", ahol VLAN-onként ki-be lehet kapcsolni a taggelést). A 802.1x csak olyan windowsos kliensekkel működik, ahol telepítve van a TP-Link saját "TPSupplicant v2.0" szoftvere. De hogy ne csak a negatívumokat soroljam: a webes felület gyors, logikus, látszik, hogy azt szánták elsődleges adminisztrációs felületnek, és alaposabban tesztelgették.
Összességében különben nem kelt rossz benyomást az eszköz, mégsem mernék a szoftver jelen állapotában komolyabb feladatot rábízni. A release notes-okat átolvasgatva kiderült, hogy a szöveges konfgurációs fájl intézménye a TP-Linknél még nincs egy éves sem, tavaly novemberben debütált a "show running-config" paranccsal együtt, mindez persze megmosolyogtató, de elképzelhetőnek tartom, hogy a legégetőbb hiányosságokat a következő néhány verzióban pótolják, a nyomott áron adott "enterprise" eszközök pedig idővel letarolják a piacot. Az informatikában nem ez lenne az első olyan történet, amikor az alulról jövő, egyre okosodó eszközök egy bizonyos pont után rettenetesen vonzóvá válnak a vásárlók többsége számára.
2013-07-04
Hirschmann HIPER-Ring: villámgyors Spanning Tree alternatíva
A napokban volt nálunk tesztelésen két Hirschmann MACH1000-es L3-as switch. Szégyen-gyalázat, eddig soha nem hallottam róla, hogy a Hirschmann Ethernet eszközökben is nyomul, pedig nem ma kezdték, 1984-ben a Stuttgarti Egyetem számára optikai szálas Ethernetet építettek -- a világon elsőként. Azóta is gyártanak Ethernet eszközöket, elsősorban ipari felhasználásra, mostoha körülmények közé. Ezek a MACH1000-esek is jóféle, vastag lemezekkel borított, súlyos eszközök, nincs bennük semmilyen mozgó alkatrész, és egészen tág hőmérséklet-tartományban üzemeltethetők. Engem elsősorban persze nem ezek a technikai paraméterek érdekeltek, hanem a Hirschmann specialitása, a gyűrűs Ethernet, ami szintén nem újdonság ennél a cégnél, már jó húsz éve szállítanak ilyen rendszereket, mégis le merném fogadni, hogy a legtöbb netwörkös szaki sosem hallott róluk.
A MACH1000-esek nem adták könnyen magukat, hiába volt két tápegység is bennük, a tápcsatlakozó nem szabványos rajtuk, úgy kellett külön blankolni és ónnal futtatni tápkábelt hozzá. Aztán jött a második akadály: a teszteszközök ismeretlen konfigurációval érkeztek, se IP-t, se jelszót nem kaptunk hozzájuk, a konzol port meg V.24-es csatlakozót kért, nekem viszont nagyon nem akaródzott konzolkábelt is gyártani. Helyette Wiresharkkal sniffeltem egy pöttyet, hátha mondanak valamit magukról. Így is történt, nagyon helyes LLDP kereteket küldözgettek az eszközök, amiből már gyorsan meglett az IP-jük, a user/jelszó páros pedig szerencsére az alapértelmezett volt.
A webes management felület kifejezetten tetszett, ennél vannak sokkal-sokkal rosszabbak is más gyártóknál. A parancssor is a jobbik fajta, nagyjából az IOS-re hajaz, legalábbis az a pár parancs, amit kipróbáltam, de most kivételesen sok időt nem töltöttem a CLI-ben, mert minden értelmesen össze volt állítva a webes felületen.
A Hirschmann Ethernet gyűrűk felépítése egyszerű: minden eszközünkön két portot kell áldozni rá, felfűzzük őket láncba, aztán a végét összekötjük az elejével. Előtte minden eszközt önállóan, külön kell konfigurálni, és csak utána lehet összedugni fizikailag. A gyűrűben részt vevő eszközök maximális számára konkrét korlátokat nem találtam sem a webes felület helpjében, sem az interneten, de több helyen is példaként említenek 50 switches gyűrűket, ami már önmagában elég nagy ahhoz, hogy ne kelljen a skálázhatóság miatt már az elején aggódnunk.
A gyűrűt alkotó portokon értelemszerűen nem futhat semmilyen STP változat, illetve a port speed és duplex beállítások sem állhatnak akárhogy, optikai link és 100BaseT esetén "autonegotiation off", "FD" a helyes kombináció, míg 1000BaseT esetén az "autonegotiation on". A gyűben az egyik eszközt ki kell neveznünk Ring Managernek, nála ér össze a gyűrű eleje és vége, a már kész gyűrűben csak a Ring Manageren világít (zölden, tartalékra álláskor sárgán) az RM LED. Gondoljuk csak végig, mennyire kényelmes, hogy itt egyetlen LED állapotán látszik, használunk-e L2-ben tartalék útvonalat, míg ugyanez mondjuk egy Cisco PVST+ konfiguráció esetén messze nem ennyire egyértelmű...
Többféle gyűrűtípust (HIPER-Ring, Fast HIPER-Ring) is válaszhatunk a beállítás során, a típus persze konzisztens kell legyen az összes, gyűrűt alkotó switch esetében.
A HIPER-Ring RM switch valami egészen fantasztikusan gyorsan tud váltani a fő- és a backup irányok közt, az STP/RSTP/MSTP másodperces tartományban mozgó váltási idejéhez képest itt ezredmásodpercekről beszélünk: 50 eszközig kb. 80 ms az átállási idő. Aki várt már kínosan hosszú másodperceket még akár RSTP esetén is, annak a biztos tudatában, hogy éppen most timeoutolnak el a legkritikusabb felhasználók SAP sessionjei, és már nyúlnak a telefonjaik után után, ami mindjárt megcsörren az ember zsebében, az biztosan értékeli ezt a 80 ms-ot. A MACH1000-esben azonban itt az új Fast HIPER-Ring is, amiről nem kevesebbet állít a dokumentáció, mint hogy 5 eszközig nagyjából 5 ms alatt megvan a váltás, 5 eszköz fölött pedig elkezd lassan növekedni ez az idő.
De vajon mit csinál egy ilyen HIPER-Ring? Természetesen belenéztem a ring portok forgalmába, az alábbi képernyőképen látható, hogy az RM switch mindkét ring portjáról (1-es port: ec:e5:55:49:11:03, 2-es port: ec:e5:55:49:11:04) 60 ms-onként felváltva hol innen, hol onnan körbeküldözget a gyűrűn valami hirschmannos L2 LLC üzenetet, és sejthető, ha valamelyik kimarad, akkor a következő sikertelen újrapróbálkozás után egyszerűen átáll az RM a valódi forgalommal az addig kihasználatlan másik gyűrűs portjára.
Mivel a Hirschmann doksik azt is mondják, hogy nem beszélhetünk a ring technológiájuk esetén ideiglenes hurkokról és egyes frame-ek többszöröződéséről (amelyek az R/M/STP esetén előfordulhatnak), és ugye az átállási idők nagyon rövidek, valamilyen egyéb trükk is lehet még a tarsolyban, pl. el tudom képzelni, hogy az FDB-t (CAM-tábla) átírják a topológiaváltásnak megfelelően, így nem kell a switchnek újratanulnia a MAC címeket, de ez pusztán spekuláció, csak annyi biztos, hogy az LLC üzenetes link detektáláson kívül valamit még trükköznek.
A Fast HIPER-Ring beállítása nagyon hasonló, ám itt még két dolgot meg kell adnunk: a gyűrűben részt vevő switchek számát és azt a (tagged) VLAN ID-t amelyik VLAN-ban a Fast HIPER-Ring LLC-k köröznek majd. Azt sajnos nem próbáltam ki, hogy a sima HIPER-Ring hogyan kezeli a VLAN-okat, a dokumentáció alapján ott mintha az RM LLC-k mindig untaggedként köröznének VLAN1-ben, a többit meg tagged-ként rá lehet tenni a gyűrűre.
Igazi élmény volt bohóckodni egy picit ezzel a technológiával, azt persze látnunk kell, hogy a HIPER-Ring előnyei az STP-hez képest egyben súlyos kompromisszumokat is jelentenek, hiszen nincs másik HIPER-Ring gyártó a piacon (vendor lock-in), és a L2 topológia sem alakítható annyira szabadon mint az STP-s hálózatokban, még akkor sem, ha egyetlen gyűrű helyett több gyűrűre (pl. egy core és több access gyűrű) is bonthatjuk hálózatunkat a Hirschmann eszközeivel.
 |
| Inkább villanyszerelőknek való az efféle tápcsatlakozó |
A MACH1000-esek nem adták könnyen magukat, hiába volt két tápegység is bennük, a tápcsatlakozó nem szabványos rajtuk, úgy kellett külön blankolni és ónnal futtatni tápkábelt hozzá. Aztán jött a második akadály: a teszteszközök ismeretlen konfigurációval érkeztek, se IP-t, se jelszót nem kaptunk hozzájuk, a konzol port meg V.24-es csatlakozót kért, nekem viszont nagyon nem akaródzott konzolkábelt is gyártani. Helyette Wiresharkkal sniffeltem egy pöttyet, hátha mondanak valamit magukról. Így is történt, nagyon helyes LLDP kereteket küldözgettek az eszközök, amiből már gyorsan meglett az IP-jük, a user/jelszó páros pedig szerencsére az alapértelmezett volt.
 |
| Az 1-es táp még nincs bedugva, ezért világít a "FAULT", a konzol V.24-es, az USB porton meg valami gyártóspecifikus ketyerével megy csak a konfigurálás |
A webes management felület kifejezetten tetszett, ennél vannak sokkal-sokkal rosszabbak is más gyártóknál. A parancssor is a jobbik fajta, nagyjából az IOS-re hajaz, legalábbis az a pár parancs, amit kipróbáltam, de most kivételesen sok időt nem töltöttem a CLI-ben, mert minden értelmesen össze volt állítva a webes felületen.
A Hirschmann Ethernet gyűrűk felépítése egyszerű: minden eszközünkön két portot kell áldozni rá, felfűzzük őket láncba, aztán a végét összekötjük az elejével. Előtte minden eszközt önállóan, külön kell konfigurálni, és csak utána lehet összedugni fizikailag. A gyűrűben részt vevő eszközök maximális számára konkrét korlátokat nem találtam sem a webes felület helpjében, sem az interneten, de több helyen is példaként említenek 50 switches gyűrűket, ami már önmagában elég nagy ahhoz, hogy ne kelljen a skálázhatóság miatt már az elején aggódnunk.
A gyűrűt alkotó portokon értelemszerűen nem futhat semmilyen STP változat, illetve a port speed és duplex beállítások sem állhatnak akárhogy, optikai link és 100BaseT esetén "autonegotiation off", "FD" a helyes kombináció, míg 1000BaseT esetén az "autonegotiation on". A gyűben az egyik eszközt ki kell neveznünk Ring Managernek, nála ér össze a gyűrű eleje és vége, a már kész gyűrűben csak a Ring Manageren világít (zölden, tartalékra álláskor sárgán) az RM LED. Gondoljuk csak végig, mennyire kényelmes, hogy itt egyetlen LED állapotán látszik, használunk-e L2-ben tartalék útvonalat, míg ugyanez mondjuk egy Cisco PVST+ konfiguráció esetén messze nem ennyire egyértelmű...
 |
| RM switch HIPER-Ringben |
Többféle gyűrűtípust (HIPER-Ring, Fast HIPER-Ring) is válaszhatunk a beállítás során, a típus persze konzisztens kell legyen az összes, gyűrűt alkotó switch esetében.
 |
| Mezei, nem RM switch HIPER-Ringben |
A HIPER-Ring RM switch valami egészen fantasztikusan gyorsan tud váltani a fő- és a backup irányok közt, az STP/RSTP/MSTP másodperces tartományban mozgó váltási idejéhez képest itt ezredmásodpercekről beszélünk: 50 eszközig kb. 80 ms az átállási idő. Aki várt már kínosan hosszú másodperceket még akár RSTP esetén is, annak a biztos tudatában, hogy éppen most timeoutolnak el a legkritikusabb felhasználók SAP sessionjei, és már nyúlnak a telefonjaik után után, ami mindjárt megcsörren az ember zsebében, az biztosan értékeli ezt a 80 ms-ot. A MACH1000-esben azonban itt az új Fast HIPER-Ring is, amiről nem kevesebbet állít a dokumentáció, mint hogy 5 eszközig nagyjából 5 ms alatt megvan a váltás, 5 eszköz fölött pedig elkezd lassan növekedni ez az idő.
De vajon mit csinál egy ilyen HIPER-Ring? Természetesen belenéztem a ring portok forgalmába, az alábbi képernyőképen látható, hogy az RM switch mindkét ring portjáról (1-es port: ec:e5:55:49:11:03, 2-es port: ec:e5:55:49:11:04) 60 ms-onként felváltva hol innen, hol onnan körbeküldözget a gyűrűn valami hirschmannos L2 LLC üzenetet, és sejthető, ha valamelyik kimarad, akkor a következő sikertelen újrapróbálkozás után egyszerűen átáll az RM a valódi forgalommal az addig kihasználatlan másik gyűrűs portjára.
Mivel a Hirschmann doksik azt is mondják, hogy nem beszélhetünk a ring technológiájuk esetén ideiglenes hurkokról és egyes frame-ek többszöröződéséről (amelyek az R/M/STP esetén előfordulhatnak), és ugye az átállási idők nagyon rövidek, valamilyen egyéb trükk is lehet még a tarsolyban, pl. el tudom képzelni, hogy az FDB-t (CAM-tábla) átírják a topológiaváltásnak megfelelően, így nem kell a switchnek újratanulnia a MAC címeket, de ez pusztán spekuláció, csak annyi biztos, hogy az LLC üzenetes link detektáláson kívül valamit még trükköznek.
 |
| Fast HIPER-Ring RM és mezei switch |
Igazi élmény volt bohóckodni egy picit ezzel a technológiával, azt persze látnunk kell, hogy a HIPER-Ring előnyei az STP-hez képest egyben súlyos kompromisszumokat is jelentenek, hiszen nincs másik HIPER-Ring gyártó a piacon (vendor lock-in), és a L2 topológia sem alakítható annyira szabadon mint az STP-s hálózatokban, még akkor sem, ha egyetlen gyűrű helyett több gyűrűre (pl. egy core és több access gyűrű) is bonthatjuk hálózatunkat a Hirschmann eszközeivel.
2013-06-17
VARP: aktív-aktív FHRP megoldás
A legutóbb egy kevéssé ismert Cisco IOS HSRP feature volt terítéken, most sem megyünk sokkal messzebb: olvastam a napokban egy másik FHRP-ről, a VARP-ról (Virtual ARP). Ez a jószág az Arista EOS-t futtató L3 switchek egyik érdekessége, egy-két éve létező lehetőség, ami a többi hasonló protokollal ellentétben aktív-aktív redundanciát biztosít.
A VARP helyes működéséhez (a többi protokollhoz hasonlóan) kézzel vagy valamilyen irányító protokollal tökéletes szinkronban kell tartani az eszközök route tábláját, és a megfelelő VLAN interfészen az IP cím mellé fel kell venni azt a virtuális IP címet, amit a hostjaink átjáróként fognak használni. Amiben különbözik társaitól a VARP, az a virtuális MAC cím, amit mindkét L3-as Arista eszközön konfigurálni kell, hogy ezzel a MAC címmel válaszoljanak a virtuális IP-s ARP kérésekre, illetve ezt a MAC címet szórják gratuitous ARP-pal.
A többi protokollnál (HSRP, VRRP) kizárólag aktív-passzív redundanciára van lehetőségünk, ahol a forgalom kelet-nyugati és észak-déli irányban is megterheli az aktív eszköz összeköttetéseit, a VARP ezzel szemben egyenletesebb terhelést nyújt észak-déli irányban, és egyáltalán nem terheli feleslegesen a kelet-nyugati kapcsolatokat:
Az egyetlen furcsa dolog a VARP működésében az lehet, hogy amikor egy kliens megkérdezi ARP-vel, hogy mi az átjárójának a MAC címe, akkor szerintem mindkét Arista eszköz el fogja neki küldeni a virtuális MAC címet, azaz kétszer kap választ. Ha szigorú biztonsági felügyelet van a hálózatban, ezek a dupla válaszok kiverhetik a biztosítékot. De ha egyszer a kliens megtudja a virtuális IP-hez tartozó virtuális MAC címet, akkor már csak úgy süvítenek kifelé a bitek a legközelebbi Arista L3 switchen (ezért kell mindegyiken ugyanazt a virtuális MAC címet beállítani). A VARP konfigurálásához a részletes útmutató megtalálható az Arista User Manualban.
A VARP helyes működéséhez (a többi protokollhoz hasonlóan) kézzel vagy valamilyen irányító protokollal tökéletes szinkronban kell tartani az eszközök route tábláját, és a megfelelő VLAN interfészen az IP cím mellé fel kell venni azt a virtuális IP címet, amit a hostjaink átjáróként fognak használni. Amiben különbözik társaitól a VARP, az a virtuális MAC cím, amit mindkét L3-as Arista eszközön konfigurálni kell, hogy ezzel a MAC címmel válaszoljanak a virtuális IP-s ARP kérésekre, illetve ezt a MAC címet szórják gratuitous ARP-pal.
A többi protokollnál (HSRP, VRRP) kizárólag aktív-passzív redundanciára van lehetőségünk, ahol a forgalom kelet-nyugati és észak-déli irányban is megterheli az aktív eszköz összeköttetéseit, a VARP ezzel szemben egyenletesebb terhelést nyújt észak-déli irányban, és egyáltalán nem terheli feleslegesen a kelet-nyugati kapcsolatokat:
Az egyetlen furcsa dolog a VARP működésében az lehet, hogy amikor egy kliens megkérdezi ARP-vel, hogy mi az átjárójának a MAC címe, akkor szerintem mindkét Arista eszköz el fogja neki küldeni a virtuális MAC címet, azaz kétszer kap választ. Ha szigorú biztonsági felügyelet van a hálózatban, ezek a dupla válaszok kiverhetik a biztosítékot. De ha egyszer a kliens megtudja a virtuális IP-hez tartozó virtuális MAC címet, akkor már csak úgy süvítenek kifelé a bitek a legközelebbi Arista L3 switchen (ezért kell mindegyiken ugyanazt a virtuális MAC címet beállítani). A VARP konfigurálásához a részletes útmutató megtalálható az Arista User Manualban.
2013-06-14
DHCP relay agent HSRP mellett IOS-en
Eddig még sosem kellett HSRP-s virtual router groupon (VRG) DHCP-t relayeznem, ma ez is megtörtént. Nem egy bonyolult dolog, de az mégiscsak érdekes, hogy a VRG-ben lévő eszközök közül akkor pontosan melyik fogja ellátni a relay funkciót. Addig ugye világos, hogy semmiképp nem állhatunk meg ott, hogy csupán az elsődleges eszközön konfigurálunk az IOS-ben ip helpert, hiszen akkor nem lesz redundáns a megoldás.
Ha a fenti topológiában mindkét eszközön (R2, R3) beállítjuk az ip helper funkciót a következők szerint:
R2
interface Fa0/1
ip address 10.10.25.2 255.255.255.0
ip helper-address 10.10.1.4
standby 25 ip 10.10.25.1
standby 25 priority 101
standby 25 preempt
R3
interface Fa0/1
ip address 10.10.25.3 255.255.255.0
ip helper-address 10.10.1.4
standby 25 ip 10.10.25.1
standby 25 priority 99
standby 25 preempt
...akkor arra számíthatunk, hogy a DHCP szerverünk a 10.10.25.0/24-ből érkező DHCP kéréseket duplán fogja kiszolgálni, mert az R2 és az R3 külön ip helper processzei nem tudnak egymásról semmit, csak figyelik az UDP broadcast forgalmat, és teszik a dolgukat süketen és vakon: kétszer fog eljutni minden klienstől minden DHCP üzenet a DHCP szerverre és vissza.
Ahogy az a fenti példában (a kliens szemszögéből) láthatjuk, jámbor kliensünk megpróbálja megújítani a régi IP-jét a 22-es keretben, ám a zord relay agentek egyszerre ráförmednek a DHCP szerver nevében, hogy dobja el, de rögtön (27 és 29), ekkor emberünk belekezd egy új cím igénylésébe (31), amit minden ügynök továbbít a szerver felé, majd a szerver válaszát meg vissza a kliensnek, és így tovább, amíg le nem zárul a folyamat. Ha nem túl háklis a DHCP szerverünk, akkor ezekből a dupla üzenetekből különösebb problémánk nem adódhat.
A Cisco vonatkozó oldalán jelzett szoftververzióktól kezdve azonban véget vethetünk az ip helperek süketelésének, ugyanis a fenti konfigurációt egy-két aprósággal kiegészítve már a VRG állapotától tehetjük függővé az ip helper ténykedését. A relaying kizárólag a VRG-ben éppen aktív eszközön fog működni, azaz megszűnik a fent leírt jelenség, ha minden eszközt hasonlóan konfigurálunk:
R2
interface Fa0/1
ip address 10.10.25.2 255.255.255.0
ip helper-address 10.10.1.4 redundancy nemsuket
standby 25 ip 10.10.25.1
standby 25 priority 101
standby 25 preempt
standby 25 name nemsuket
R2
interface Fa0/1
ip address 10.10.25.2 255.255.255.0
ip helper-address 10.10.1.4
standby 25 ip 10.10.25.1
standby 25 priority 101
standby 25 preempt
R3
interface Fa0/1
ip address 10.10.25.3 255.255.255.0
ip helper-address 10.10.1.4
standby 25 ip 10.10.25.1
standby 25 priority 99
standby 25 preempt
...akkor arra számíthatunk, hogy a DHCP szerverünk a 10.10.25.0/24-ből érkező DHCP kéréseket duplán fogja kiszolgálni, mert az R2 és az R3 külön ip helper processzei nem tudnak egymásról semmit, csak figyelik az UDP broadcast forgalmat, és teszik a dolgukat süketen és vakon: kétszer fog eljutni minden klienstől minden DHCP üzenet a DHCP szerverre és vissza.
Ahogy az a fenti példában (a kliens szemszögéből) láthatjuk, jámbor kliensünk megpróbálja megújítani a régi IP-jét a 22-es keretben, ám a zord relay agentek egyszerre ráförmednek a DHCP szerver nevében, hogy dobja el, de rögtön (27 és 29), ekkor emberünk belekezd egy új cím igénylésébe (31), amit minden ügynök továbbít a szerver felé, majd a szerver válaszát meg vissza a kliensnek, és így tovább, amíg le nem zárul a folyamat. Ha nem túl háklis a DHCP szerverünk, akkor ezekből a dupla üzenetekből különösebb problémánk nem adódhat.
A Cisco vonatkozó oldalán jelzett szoftververzióktól kezdve azonban véget vethetünk az ip helperek süketelésének, ugyanis a fenti konfigurációt egy-két aprósággal kiegészítve már a VRG állapotától tehetjük függővé az ip helper ténykedését. A relaying kizárólag a VRG-ben éppen aktív eszközön fog működni, azaz megszűnik a fent leírt jelenség, ha minden eszközt hasonlóan konfigurálunk:
R2
interface Fa0/1
ip address 10.10.25.2 255.255.255.0
ip helper-address 10.10.1.4 redundancy nemsuket
standby 25 ip 10.10.25.1
standby 25 priority 101
standby 25 preempt
standby 25 name nemsuket
2013-05-13
Tikpásztor
A Tikpásztor egy nem túl szofisztikált shell és expect szkript, a MikroTik ketyerékből álló tyúkudvarok rendben tartásának lehetséges eszköze. Azonnal használatba lehet venni, szereti az öreg, az SSH kulcsokról mit sem tudó (RouterOS 2.9.13 előtti) tikokat, mivel nem igényel előzetes SSH kulcs terítést, három dolgot azonban tudnia minden egyes eszközről: a management IP címet, az admin user nevét, illetve jelszavát. Ezen kívül természetesen az SSH szolgáltatásnak futnia kell a Tikpásztor által kezelt eszközökön. A szkript nem csodaszer, csak annyira hasznos, amennyire értünk a RouterOS CLI-jéhez, összesen két dologra képes ugyanis: RouterOS parancsot futtatni sok eszközön, illetve komplett beállításmentést készíteni (licenc, export, backup) sok eszközről.
A csoport neve az lesz, amilyen néven elmentjük a fájlt, azzal az apró megkötéssel, hogy tartalmaznia kell a "csoport" prefixet, tehát "csoport.AP", "csoport.szamvitel", stb.
A felhasználónév ettől még ugyanaz marad, csupán a login során átpasszolunk két olyan paramétert a RouterOS-nek, amelyek segítik az expect szkriptek és a RouterOS közötti együttműködést. Ez a funkció a 3-as RouterOS szériában mutatkozott be, 2-es verziókon viszont semmiképp ne használjuk, mert ott a felhasználónév részeként fogja kezelni a RouterOS a plusz karaktereket.
Mielőtt egyszerre levágnánk az összes MikroTik eszközünket, javasolt átolvasni, hogy melyik csoportra, milyen parancsot futtatunk, ezt annyiban segíti a szkript, hogy futás előtt rákérdez, hogy valóban folytatni szeretnénk-e. Pozitív válasz esetén a csoportban lévő minden egyes eszközre, egymás után, for ciklusban ráereszti azt az expect szkriptet, ami bejelentkezik SSH-n, majd lefuttatja a megadott parancsot.
A másik működési mód mentést készít az eszközről. A mentés három dolog mentését jelenti, a RouterOS szoftverlicenc-klucsát, egy "/export" paranccsal készített szöveges konfigurációs fájlt, illetve egy "/system backup save" paranccsal készített bináris konfig mentést. Ez utóbbit csak azon az eszközön lehet visszaállítani ahol készült, míg az "/export" kimenete némi mókolást követően más MikroTiken is behúzható. A mentés során a MikroTikek flash memóriáján a három mentett dolognak megfelelő három fájl jön létre, egy ".key" kiterjesztésű fájl a licenckulccsal, egy ".rsc" fájl az exporttal, és egy ".backup" kiterjesztésű bináris fájl. A fájlok lementése SSH/SFTP protokollon keresztül történik, majd a másolás végeztével törlődnek is az eszközről. A mentés menete:
A mentés során az eszközökről lementett fájlok abba a könyvtárba kerülnek, ahol a "tikpasztor.sh" található. Backup módban a szkript folyamatosan fut, amint végzett egy eszközön, azonnal kezdi a következőt a csoportból, nem igényel interakciót.
Függőségek
Néhány elterjedt szoftvernek telepítve kell lennie, hogy a Tikpásztor működőképes legyen, a legfontosabb ezek közül az "expect" nevű, Tcl alapú, interaktív szkriptelést támogató csomag, ami nem része az alapértelmezett telepítésnek a legtöbb Linuxon. Szükség van továbbá olyan standard eszközökre mint a "bash", az "ssh" és az "sftp".Csoportok
Az első, amit tudnunk kell a Tikpásztorról, hogy csoportokban kezeli az eszközeinket. Azt, hogy mi szerint szervezzük a csoportokat, a szkript szempontjából nem fontos. Ha nincsenek különböző jellegű feladatokat ellátó eszközeink, akkor elegendő egyetlen csoportot létrehoznunk, de készíthetünk csoportot az eszközök fizikai elhelyezkedése alapján (pl. egy csoportba kerülnek az azonos telephelyen lévő Mikrotikek) vagy az eszközök funkciója alapján (pl. egy csoportba kerülnek az AP-ként funkcionáló eszközök, egy másikba pedig a routeolást végző eszközök). A csoport egy szöveges, pontosvesszővel tagolt fájl, ami nem tartalmazhat üres sorokat és kommentárokat, csupán IP-t, usernevet és jelszót minden egyes sorban:192.168.0.1;admin;bejohetsz
192.168.0.2;admin;password
192.168.0.3;admin;admin
A csoport neve az lesz, amilyen néven elmentjük a fájlt, azzal az apró megkötéssel, hogy tartalmaznia kell a "csoport" prefixet, tehát "csoport.AP", "csoport.szamvitel", stb.
Felhasználónevek
Előre különösnek tűnik, de a felhasználónevekhez lehet hozzácsapni a RouterOS SSH login alkalmával, hogy miképp kezelje a konzolt a RouterOS, legyenek-e színek, hány sor, hány oszlop, detektáljon-e és társaik. Ha tudjuk a tikokról, hogy nem túl régiek, 4-es, 5-ös RouterOS-t futtatnak, akkor bátran véssük be a felhasználónév mögé, a "+ct" karaktersort a csoportfájlban, pl:192.168.0.1;admin+ct;bejohetsz
A felhasználónév ettől még ugyanaz marad, csupán a login során átpasszolunk két olyan paramétert a RouterOS-nek, amelyek segítik az expect szkriptek és a RouterOS közötti együttműködést. Ez a funkció a 3-as RouterOS szériában mutatkozott be, 2-es verziókon viszont semmiképp ne használjuk, mert ott a felhasználónév részeként fogja kezelni a RouterOS a plusz karaktereket.
Használat
A csoportfájlok feltöltése után a Tikpásztor azonnal használható. A "tikpasztor.sh" legyen ugyanabban a könyvtárban, ahol a csoportfájlok, a /tmp könyvtáron pedig legyen írási jogunk, és már mehet is. A szkriptnek két működési módja van, az egyikben az első paraméterként megadott csoport minden egyes eszközén a második paraméterben megadott RouterOS parancsot fogja lefuttatni:root@tesztgep:~/mikrotik# ./tikpasztor.sh teszt "/system license print"
* "teszt" csoport (3 eszköz)
* "/system license print" RouterOS parancs
Folytatod (i/n)? i
###### 192.168.0.1 START #########################################################
spawn ssh -l admin 192.168.0.1
admin@192.168.0.1's password:
MMM MMM KKK TTTTTTTTTTT KKK
MMMM MMMM KKK TTTTTTTTTTT KKK
MMM MMMM MMM III KKK KKK RRRRRR OOOOOO TTT III KKK KKK
MMM MM MMM III KKKKK RRR RRR OOO OOO TTT III KKKKK
MMM MMM III KKK KKK RRRRRR OOO OOO TTT III KKK KKK
MMM MMM III KKK KKK RRR RRR OOOOOO TTT III KKK KKK
MikroTik RouterOS 2.9.50 (c) 1999-2007 http://www.mikrotik.com/
Terminal xterm detected, using multiline input mode
[admin@MikroTik1] > /system license print
software-id: "K8FN-PTT"
upgradable-to: v4.x
nlevel: 4
features:
[admin@MikroTik1] > /quit
Connection to 192.168.0.1 closed.
########################################################## 192.168.0.1 STOP ######
Nyomj meg egy gombot a folytatáshoz...
###### 192.168.0.2 START #########################################################
spawn ssh -l admin+ct 192.168.0.2
admin@192.168.0.2's password:
MMM MMM KKK TTTTTTTTTTT KKK
MMMM MMMM KKK TTTTTTTTTTT KKK
MMM MMMM MMM III KKK KKK RRRRRR OOOOOO TTT III KKK KKK
MMM MM MMM III KKKKK RRR RRR OOO OOO TTT III KKKKK
MMM MMM III KKK KKK RRRRRR OOO OOO TTT III KKK KKK
MMM MMM III KKK KKK RRR RRR OOOOOO TTT III KKK KKK
MikroTik RouterOS 5.25 (c) 1999-2013 http://www.mikrotik.com/
[admin@MikroTik2] > /system license print
software-id: H0N3-48VJ
upgradable-to: v7.x
nlevel: 4
features:
[admin@MikroTik2] > /quit
interrupted
Connection to 192.168.0.2 closed.
########################################################## 192.168.0.2 STOP ######
Nyomj meg egy gombot a folytatáshoz...
###### 192.168.0.3 START #########################################################
spawn ssh -l admin+ct 192.168.0.3
admin+ct@192.168.0.3's password:
MMM MMM KKK TTTTTTTTTTT KKK
MMMM MMMM KKK TTTTTTTTTTT KKK
MMM MMMM MMM III KKK KKK RRRRRR OOOOOO TTT III KKK KKK
MMM MM MMM III KKKKK RRR RRR OOO OOO TTT III KKKKK
MMM MMM III KKK KKK RRRRRR OOO OOO TTT III KKK KKK
MMM MMM III KKK KKK RRR RRR OOOOOO TTT III KKK KKK
MikroTik RouterOS 5.25 (c) 1999-2013 http://www.mikrotik.com/
[admin@MikroTik3] > /system license print
software-id: RGED-3LWV
upgradable-to: v6.x
nlevel: 4
features:
[admin@MikroTik3] > /quit
interrupted
Connection to 192.168.0.3 closed.
########################################################## 192.168.0.3 STOP ######
Nyomj meg egy gombot a folytatáshoz...
root@tesztgep:~/mikrotik#
Mielőtt egyszerre levágnánk az összes MikroTik eszközünket, javasolt átolvasni, hogy melyik csoportra, milyen parancsot futtatunk, ezt annyiban segíti a szkript, hogy futás előtt rákérdez, hogy valóban folytatni szeretnénk-e. Pozitív válasz esetén a csoportban lévő minden egyes eszközre, egymás után, for ciklusban ráereszti azt az expect szkriptet, ami bejelentkezik SSH-n, majd lefuttatja a megadott parancsot.
A másik működési mód mentést készít az eszközről. A mentés három dolog mentését jelenti, a RouterOS szoftverlicenc-klucsát, egy "/export" paranccsal készített szöveges konfigurációs fájlt, illetve egy "/system backup save" paranccsal készített bináris konfig mentést. Ez utóbbit csak azon az eszközön lehet visszaállítani ahol készült, míg az "/export" kimenete némi mókolást követően más MikroTiken is behúzható. A mentés során a MikroTikek flash memóriáján a három mentett dolognak megfelelő három fájl jön létre, egy ".key" kiterjesztésű fájl a licenckulccsal, egy ".rsc" fájl az exporttal, és egy ".backup" kiterjesztésű bináris fájl. A fájlok lementése SSH/SFTP protokollon keresztül történik, majd a másolás végeztével törlődnek is az eszközről. A mentés menete:
root@tesztgep:~/mikrotik# ./tikpasztor.sh teszt BACKUP ###### 192.168.0.1 START ######################################################### spawn ssh -l admin 192.168.0.1
admin@192.168.0.1's password: MMM MMM KKK TTTTTTTTTTT KKK MMMM MMMM KKK TTTTTTTTTTT KKK MMM MMMM MMM III KKK KKK RRRRRR OOOOOO TTT III KKK KKK MMM MM MMM III KKKKK RRR RRR OOO OOO TTT III KKKKK MMM MMM III KKK KKK RRRRRR OOO OOO TTT III KKK KKK MMM MMM III KKK KKK RRR RRR OOOOOO TTT III KKK KKK MikroTik RouterOS 2.9.50 (c) 1999-2007 http://www.mikrotik.com/ Terminal xterm detected, using multiline input mode [admin@MikroTik1] > /system license output [admin@MikroTik1] > /system backup save name=2013-05-13 Saving system configuration Configuration backup saved [admin@MikroTik1] > /export file=2013-05-13 [admin@MikroTik1] > /quit Connection to 192.168.0.1 closed. FÁJLOK MENTÉSE: spawn sftp admin@192.168.0.1 admin@192.168.0.1's password: Connected to 192.168.0.1. sftp> get ????-???*.key 2013-05-13_192.168.0.1.key Fetching /K8FN-PTT.key to 2013-05-13_192.168.0.1.key /K8FN-PTT.key 100% 203 0.2KB/s 00:00 sftp> get 2013-05-13.backup 2013-05-13_192.168.0.1.backup Fetching /2013-05-13.backup to 2013-05-13_192.168.0.1.backup /2013-05-13.backup 100% 10KB 10.5KB/s 00:00 sftp> get 2013-05-13.rsc 2013-05-13_192.168.0.1.rsc Fetching /2013-05-13.rsc to 2013-05-13_192.168.0.1.rsc /2013-05-13.rsc 100% 13KB 12.8KB/s 00:00 sftp> rm ????-???*.key Removing /K8FN-PTT.key sftp> rm 2013-05-13.backup Removing /2013-05-13.backup sftp> rm 2013-05-13.rsc Removing /2013-05-13.rsc sftp> exit ########################################################## 192.168.0.1 STOP ######
A mentés során az eszközökről lementett fájlok abba a könyvtárba kerülnek, ahol a "tikpasztor.sh" található. Backup módban a szkript folyamatosan fut, amint végzett egy eszközön, azonnal kezdi a következőt a csoportból, nem igényel interakciót.
Korlátok
A szkript nem kezeli le az SSH szerverek fingerprint változását (pl. formázással egybekötött RouterOS újratelepítés után), ezt nekünk kell megtennünk. Nincs külön összesítés vagy figyelemfelhívás a szkript lefutása közben/után ha egy MikroTik eszköz elérhetetlen, csupán az SSH kliens hibaüzenetét láthatjuk ilyenkor ("No route to host"). A szkript jelen formájában Debian / Ubuntu rendszereken fut, máshol nem is próbáltam. Stb. Stb. Stb.
Feliratkozás:
Bejegyzések (Atom)