sFlow beállítása régebbi HP Procurve típusokon

Bizonyára nem én vagyok az egyetlen, aki beleszaladt már abba a problémába, hogy némelyik régebbi Layer3-as HP Procurve típuson jól láthatóan van sFlow támogatás az OS-ben, létezik például a "show sflow all" parancs is, ám konfig módban mégsincs semmilyen sflow kezdetű parancsunk. Azaz: CLI-ből lekérdezni ugyan le tudjuk az sFlow agent állapotát, beállítani viszont nem. A teljesség igénye nélkül, ilyen tudomásom szerint az összes 2800-as sorozatú eszköz, pl. a 2824-es, illetve rémlik, mintha a 2610-esen is tapasztaltam volna ugyanezt.

Szerencsére minden beállítható, de kizárólag SNMP-n keresztül, a konfiguráláshoz szükség lesz SNMP írási jogra az eszközünkhöz. Ez már önmagában is elég érdekes koncepció, tulajdonképpen olyan, mintha valaki valamit elfelejtett volna az OS fejlesztése alatt, de a dologba sikerült még egy csavart is tenniük a fejlesztőknek: ha bekonfiguráltuk a megfelelő SNMP OID-eken keresztül az sFlow-t, az akkor sem fog örökké futni, van ugyanis az sFlow destination értékek között egy folyamatosan csökkenő "Timeout" paraméter is, ami azt mutatja, hogy hány másodpercig fog még az OS adatokat küldeni az adott sFlow collector számára. A Timeout maximális értéke "10000000" szekundum, vagyis legkésőbb 115 naponként újra be kell állítani a switchet, különben befejezi a collectorral a kommunikációt. Azon pedig igazán nem érdemes csodálkozni, hogy a beállításokat a switch elfelejti újrainduláskor: lehet hozzá barkácsolni mindenféle szkripteket, nyilván célszerű ezt a feladatot ízlés szerint egy napi/heti/havi cronjobbal megoldani, és rendszeres időközönként megnövelni a "Timeout" értéket is.

Ennyi bevezető után pedig következzen egy egyszerű shellszkript, ami egy I.10.101-es OS verziót futtató HP 2824-es 20-as portján beállítja az sFlow-t a 10.10.10.10:9996-os collectorhoz:

#!/bin/sh
 
# collector: IP hexában
snmpset -v1 -cpublic 10.3.2.2 1.3.6.1.4.1.14706.1.1.4.1.6.1 x 0a0a0a0a
sleep 1

# collector: port decimálisan
snmpset -v1 -cpublic 10.3.2.2 1.3.6.1.4.1.14706.1.1.4.1.7.1 i 9996
sleep 1

# collector owner info
snmpset -v1 -cpublic 10.3.2.2 1.3.6.1.4.1.14706.1.1.4.1.2.1 s sFlow_collector
sleep 1

# hány mp-ig fusson az sflow agent a switchen (ez a max ~115 nap)
snmpset -v1 -cpublic 10.3.2.2 1.3.6.1.4.1.14706.1.1.4.1.3.1 i 10000000
sleep 1

# sampling: minden 4096. packet a 20-as porton (a .1 előtt az OID legvégén)
snmpset -v1 -cpublic 10.3.2.2 1.3.6.1.4.1.14706.1.1.5.1.4.11.1.3.6.1.2.1.2.2.1.1.20.1 i 4096
sleep 1

# polling: 20 mp a 20-as porton (a .1 előtt az OID legvégén)
snmpset -v1 -cpublic 10.3.2.2 1.3.6.1.4.1.14706.1.1.6.1.4.11.1.3.6.1.2.1.2.2.1.1.20.1 i 20
sleep 1

# port sflow enable a 20-as porton
snmpset -v1 -cpublic 10.3.2.2 1.3.6.1.4.1.14706.1.1.5.1.3.11.1.3.6.1.2.1.2.2.1.1.20.1 i 1

exit

Ha minden klappol, akkor valami ilyesmi lesz a "show sflow all" kimenete:

HP2824# sh sflow all

 sflow agent

  Version       : 1.3;HP;I.10.101
  Agent Address : 10.11.12.13

 sflow destination

  sflow                     : Enabled
  Datagrams Sent            : 4935
  Destination Address       : 10.10.10.10
  Receiver Port             : 9996
  Owner                     : sFlow_collector
  Timeout (seconds)         : 9996908
  Max Datagram Size         : 1400
  Datagram Version Support  : 5

 sflow sampling-polling

 sflow destination Enabled

 Port  | Sampling                 Dropped    | Polling
       | Enabled  Rate     Header Samples    | Enabled Interval
 ----- + -------  -------- ------ ---------- + ------- --------
 1       No       0        128    0            Yes     20
 2       No       0        128    0            Yes     20
 3       No       0        128    0            Yes     20
 4       No       0        128    0            Yes     20
 5       No       0        128    0            Yes     20
 6       No       0        128    0            Yes     20
 7       No       0        128    0            Yes     20
 8       No       0        128    0            Yes     20
 9       No       0        128    0            Yes     20
 10      No       0        128    0            Yes     20
 11      No       0        128    0            Yes     20
 12      No       0        128    0            Yes     20
 13      No       0        128    0            Yes     20
 14      No       0        128    0            Yes     20
 15      No       0        128    0            Yes     20
 16      No       0        128    0            Yes     20
 17      No       0        128    0            Yes     20
 18      No       0        128    0            Yes     20
 19      No       0        128    0            Yes     20
 20      Yes      4096     128    0            Yes     20
 21      No       0        128    0            Yes     20
 22      No       0        128    0            Yes     20
 23      No       0        128    0            Yes     20
 24      No       0        128    0            Yes     20

OSPF DR/BDR választás kierőszakolása RouterOS-en

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

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:

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:

• 2960-ason statikus routolás (igen!)
• 3560-ason PBR
• 3560/3750-esen IPv6 routeolás

Túl sokat sosem gondolkodtam azon, mi ez az SDM, mindig megtettem, amit az éppen aktuális problémára vonatkozó Cisco útmutató írt, de sosem jártam alaposabban utána, hogy mi ez egészen pontosan. Természetesen semmi olyasmire nem kell gondolnunk, aminek az SDM GUI-hoz lenne köze, ebben a kontextusban az SDM jelentése: Switch Database Management, és a switchekben lévő CAM, illetve TCAM memóriák felhasználási módjait lehet beállítani vele.

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.

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.

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.

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

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.

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.

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

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.

 

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.

NTP szinkron ellenőrzése

Kétségbeejtően sokat foglalkozom Linuxszal mostanában, szerencsére itt is utolér néha egy-egy érdekesebb hálózati feladat. Nemrég például arra kellett választ adnom, hogy mekkora differenciával jár tetszőleges két Linux szerver órája egymáshoz képest egy adott LAN egy adott subnetjében. Természetesen van kiépített belső NTP infrastruktúra, szóval akár csípőből megválaszolható egy ilyen kérdés azzal, hogy általában LAN esetén egy-két ms körül lehet ez az érték, annál nem valószínű, hogy több lenne az eltérés bármelyik két hoszt között, ha jól működik az NTP. Ez persze egyrészt nem pontos válasz, másrészt ha nem elég meggyőző az ember, és nincs ott a prompt válasz előkészítve, amikor mondjuk egy konferenciahívás alatt felmerül a kérdés, könnyen olyan helyzetben találhatja magát, hogy már meg is kapta az egészet feladatként.

Ebben az esetben a fókusz tehát nem azon volt, hogy mennyire pontosak az órák vmilyen abszolútnak tekinthető stratum 1-es forráshoz képest, hanem hogy az adott subnet linuxos szerverein egymáshoz képest mennyire megbízhatók a logokban és adatbázisokban található timestampek, amely feladat első lépése annak a kiderítése, hogy mennyire pontosak a rendszerórák egymáshoz képest. Az NTP implementációval érkező diagnosztikai eszközök, pl. az ntpq ezeket az adatokat csak NTP szerver - NTP kliens viszonylatban tudja megmondani, nekünk általánosabb megoldásra volt szükségünk.

Egy rövid kis megbeszélés után arra jutottunk az egyik kollégával, hogy a legegyszerűbb talán az lenne, ha valamilyen multicast programmal szórnánk az aktuális timestampet valamelyik hostról (a timestamp lenne a tartalma a multicast a UDP csomagoknak), a többi szerveren meg sniffelnénk a hálózati forgalmat ngreppel, a multicast csomagok beérkezésének timestampjét pedig a csomagban lévő timestamppel összehasonlítanánk. Utána már csak a szerepeket kell forgatni a hostok közt, ha egy teljes mátrixot szeretnénk feltölteni az eredményekkel. Persze az eredmények nem lesznek teljesen pontosak, hiszen nem az órák közti differenciát fogják mutatni, benne lesz a timestamp feldolgozási ideje, UDP + IP + Ethernet csomagolása, az Ethernet késleltetése, stb. de azért adhat egy jó közelítést az órák pontosságáról. Ha például azt találjuk majd, hogy átlagosan +10 ms körüli az eltérés az átküldött timestamp és annak sniffelési ideje között, akkor az nem lesz túl rózsás eredmény, míg mondjuk ha csak 1 ms az átlagos eltérés az imént felsorolt feldolgozási idők hozzáadódása ellenére is, akkor nyugodtan hátradőlhetünk, minden rendben (üzleti oldalról az 1 ms-os pontosság az elvárás). El is kezdtem ilyesmire alkalmas programokat keresgélni, aztán persze addig faragtam a paramétereken, míg kiderült, hogy semmilyen extra programra nincs szükség, az egész tesztet meg lehet oldani az alap Ubuntu telepítéssel érkező programokkal.

A teszthez használt "szerver", ami az aktuális időbélyeget kiteszi hálózatra, nem kell hogy bonyolultabb legyen, mint egy date és netcat parancs, multicastra sincs szükség, hiszen subneten belül ugyanúgy megteszi a broadcast is:

date +%Y/%m/%d\ %k\:%M\:%S.%N | nc -b -u 192.168.0.255 6666

A parancs az ngrep kimenetének megfelelően formázott timestamp stringet fog elküldeni a megadott broadcast cím megadott portjára. Ubuntu 10.04-ben ez működik is, a 12.04-esben viszont lecserélték a netcat csomagot az OpenBSD netcatjére, ami sajnos nem tud broadcastolni, így Precise alatt a "netcat-traditional" csomagot is telepítenünk kell. A "kliens" oldal, ami a subnet összes gépén akár párhuzamosan is futhat, az ngrep megfelelően paraméterezve:

root@betazed:~# ngrep -q -t -d eth0 port 6666
interface: eth0 (192.168.0.0/255.255.255.0)
filter: (ip or ip6) and ( port 6666 )

U 2012/12/27 23:17:54.698920 192.168.0.4:60071 -> 192.168.0.255:6666
  2012/12/27 23:17:54.698705783.

U 2012/12/27 23:18:09.858924 192.168.0.4:36778 -> 192.168.0.255:6666
  2012/12/27 23:18:09.858708142.

U 2012/12/27 23:18:13.428859 192.168.0.4:38310 -> 192.168.0.255:6666
  2012/12/27 23:18:13.428650913.

Az adatok értelmezésére érdemes némi időt fordítani, az ngrep timestamp mikroszekundumban értendő, a közvetlenül alatta lévő sor pedig az UDP payload, ahol a date parancs által a másik hoszton előállított timestamp szerepel nanoszekundumos pontossággal. Itt például látszik, hogy az időbélyeg teljes feldolgozása, hálózaton átküldése és kliens oldali feldolgozása átlagban 213 mikroszekundum volt három különböző "szerver" futtatás alkalmával. Pontosan ugyanezek a a "szerver" lefutások természetesen más eredményt adnak egy másik hosztról nézve:

root@trill:~# ngrep -q -t -d eth0 port 6666
interface: eth0 (192.168.0.0/255.255.255.0)
filter: (ip or ip6) and ( port 6666 )

U 2012/12/27 23:17:54.699099 192.168.0.4:60071 -> 192.168.0.255:6666
  2012/12/27 23:17:54.698705783.

U 2012/12/27 23:18:09.859099 192.168.0.4:36778 -> 192.168.0.255:6666
  2012/12/27 23:18:09.858708142.

U 2012/12/27 23:18:13.429031 192.168.0.4:38310 -> 192.168.0.255:6666
  2012/12/27 23:18:13.428650913. 

Itt 388 mikroszekundum az átlagos eltérés a "szerver" által küldött időpont és az UDP szegmens "kliensre" beérkezésének időpontja között. Megint más lesz az eredmény egy harmadik "kliensről" vizsgálódva, ami sok tényezőtől függhet, például attól is, hogy hány switchen keresztül vezet az UDP broadcast útja, hiszen minden egyes switch hozzáadja a maga késleltetését. Rosszul járó órára akkor gyanakodhatunk, ha valamelyik hostról a küldött és fogadott adatok eredményei szignifikánsan eltérnek a többieken mértektől. A konklúzió nálunk az volt, hogy az órák egymáshoz képest meglepően pontosan járnak abban a subnetben, ahol a vizsgálatot végeztem, és a Wikipédián említett 1ms-os LAN-on elérhető NTP pontosságot messze túlteljesítjük. 

Hogyan nem találtam hibát a TSharkban

Miután két napon keresztül bohóckodtam egy AWK szkripttel, ami TShark által lesniffelt, majd a TShark prokoll dekóderén áthajtott adatokat dolgoz fel, és capture file-ból már hibátlanul működött mind a TShark-os dekódolós rész, mint az AWK szkript, gondoltam ideje kipróbálni valódi környezetben is dolgot. Felkerült egy tesztrendszerre, pár módosítás a capture-t végző szkriptben, hogy valódi sniffelés legyen, ne capture fájlból olvasson, aztán mindenkit odacsődítettem, hogy na, ezt nézzétek, elkészült, és... kopp. Nem megy. Á... igen, rövid hegesztgetés a capture filteren, apróbb állítgatás a protokoll dekóderen, na, majd most... kopp. Még egy kis mókolgatás, és... kopp, kopp, kopp.

Egy jó másfél órás túrás után kiderült, hogy a szkript lelkének számító "tshark ... | magic.awk > /dev/tcp/1.1.1.1/1111" szerkezetű sorban (a /dev/tcp/IP/port Bash specifikus) már a legelején elkerülik a pipe-ot az adatok. Persze én a másik végéről visszafelé haladva ellenőriztem mindent, ez nem is kérdés. A probléma egyébként roppant egyszerű: capture filter használata esetén az STDOUT-ra nem ad semmit a TShark, ami nem valami szép dolog tőle. Az alábbi egyszerű példák megvilágítják, hogy mi is a gond. Tegyük fel, hogy folyamatos ICMP forgalmunk van a 192.168.0.1 és a 192.168.0.2 között.

Capture filter és pipe nélkül minden rendben:

betazed:~# tshark -i eth2
Running as user "root" and group "root". This could be dangerous.
Capturing on eth2
  0.000000 192.168.0.1 -> 192.168.0.2  ICMP Echo (ping) request
  0.000118  192.168.0.2 -> 192.168.0.1 ICMP Echo (ping) reply
  ...

Capture filterrel, de pipe nélkül is OK:

betazed:~# tshark -i eth2 icmp
Running as user "root" and group "root". This could be dangerous.
Capturing on eth2
  0.000000 192.168.0.1 -> 192.168.0.2  ICMP Echo (ping) request
  0.000103  192.168.0.2 -> 192.168.0.1 ICMP Echo (ping) reply
  ...

Capture filter nékül, pipe-pal:

betazed:~# tshark -i eth2 | grep .
Running as user "root" and group "root". This could be dangerous.
Capturing on eth2
  0.541318 192.168.0.1 -> 192.168.0.2  ICMP Echo (ping) request
  0.541418  192.168.0.2 -> 192.168.0.1 ICMP Echo (ping) reply
  ...

Capture filterrel és pipe-pal:

betazed:~# tshark -i eth2 icmp | grep .
Running as user "root" and group "root". This could be dangerous.
Capturing on eth2
^C26 packets captured

Az STDERR-re kikerül a CTRL+C megnyomása után, hogy 26 csomagot fogott a TShark. Szép, szép, de hová tette azt a 26 csomagot? A grep tutira nem nyeli le őket, hiszen ebben a formában mindent átenged, ergo meg sem kapja az STDIN-jén az adatokat. Akkor vajon mi lehet gond? Rövid töprengés után (vö. Gyalog galopp boszorkányégetős jelenet) megvan az itélet: biztosan a TShark vacak, máglyára vele. Nincs is szebb annál, mint amikor a hülyeség szorgalommal párosul, lejelentettem hibára a bugs.wireshark.org-on. Nem tudom, hogy a véletlenül kapott mágikus erejű bug ID (7777) hatására, vagy azért, mert egyébként is jól felépített szervezetet tolt a Riverbed a Wireshark alá, de húsz perc múlva volt megoldás: user error. Khm... nos, igen, körülbelül iyen "Operációs rendszerek" szeminárium első évfolyam, első félév, második alkalom szintű dologról van szó, nem tudtam, hogy az STDOUT pufferelt, és ha nincs elég sok adat a TShark kimeneten, akkor bizony sokáig a pufferben ragadnak a dolgok. Ezért abban az esetben, ha TShark van a pipe elején, "-l" kapcsolóval érdemes elindítani, akkor azonnal ürül a puffer minden egyes csomag feldolgozása után. Innen persze már működött a csoda szkriptem is, az más kérdés, hogy a végső változatban mégsem TShark-kal sniffeltem, hanem ngrep-pel, és a TShark parancssori protokoll dekódere helyett mindent AWK-val oldottam meg, nem is ez a fontos, hanem az, hogy a szakmában töltött évek száma semmilyen kapcsolatban nincs az ember valós vagy inkább vélt tévedhetetlenségével.

Multicast light: statikus multicast routing Linuxon (2.)

Az előző részben elkészült egyszerű multicast rendszert valahogy le kell tesztelni. Sokan a VLC média playert használják ehhez, ami teljesen rendjén is van, de azért sosem árt, ha van valami igazán igénytelen, CLI-s eszközünk, amivel valódi multicast forgalmat generálhatunk. Pontosan ilyen program az "mcsender", ami az "smcroute" csomaggal együtt érkezik (legalábbis Ubuntu/Debian alatt). Ennek segítségével kipróbálhatóak az előző részben beállított statikus multicast route-ok. A topológiánk most is a következő:

A "bajor" hostról legalább 3-as IP TTL értékkel (hiszen három hálózaton kell átjutnia a multicast üzenetnek ebben a topológiában), 192.168.1.100-as forrás IP-vel, a 225.1.2.3-as csoportnak címezve, 3000-es UDP porton a következő paranccsal küldetünk teszt UDP streamet:

robert@bajor:~$ mcsender -t3 -ieth0 225.1.2.3:3000

Igen ám, de mi fogja ezt fogadni? Az "andoria" hoston szükségünk lesz egy másik multicastos teszteszközre, az "emcast"-ra. Az "emcast" multicast streamet képes fogadni, és a stream tartalmát kiteszi az STDOUT-ra, valahogy így:

robert@andoria:~$ emcast 225.1.2.3:3000
this is the test message from mclab/mcsender
this is the test message from mclab/mcsender
this is the test message from mclab/mcsender
this is the test message from mclab/mcsender
this is the test message from mclab/mcsender
this is the test message from mclab/mcsender
this is the test message from mclab/mcsender
this is the test message from mclab/mcsender
...

Annyi csavar van a dologban, hogy az "emcast" csomagot az Ubuntu 11.04-es verzió után kidobták a hivatalos repókból, így vagy fordítunk magunknak, vagy feltesszük a 11.04-esben lévő deb-et (12.04-en csont nélkül megy). Ha mégsem működne a multicast rendszerünk, ellenőrizzük, hogy fut-e egyáltalán az smcroute démon (pgrep smcroute), nézzük végig minden multicast routeren a multicast route-okat az "ip mroute show" paranccsal, illetve bizonyosodjunk meg arról, hogy a bejövő és kimenő multicast interfészek benne vannak-e a kernel multicast interfész táblázatában (cat /proc/net/ip_mr_vif).

További hibalehetőség lehet az, ha az smcroute démon indításakor még nem él valamelyik, a multicast route-ok által hivatkozott interfész. Tipikusan ilyen lehet a VPN tunnel interfész, ha le-föl kapcsolgatjuk. Ilyenkor hiába él már a tun1 utólag, az smcroute démon indítása után:

root@trill:~# ifconfig tun1
tun1      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:172.31.255.1  P-t-P:172.31.255.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Nem lehet hozzáadni a statikus multicast route-ot:

root@trill:~# smcroute -a eth0 192.168.1.100 225.1.2.3 tun1
Daemon error: Warn: invalid output interface

...és a multicast interfészek közt sincs benne a kernel szerint:

root@trill:~# cat /proc/net/ip_mr_vif
Interface      BytesIn  PktsIn  BytesOut PktsOut Flags Local    Remote
 0 eth0              0       0         0       0 00000 0101A8C0 00000000
 1 eth1              0       0         0       0 00000 010A0A0A 00000000

Újra kell az smcroute-ot indítani, és megint megpróbálni a route hozzáadást:

root@trill:~# service smcroute stop
Stopping static multicast router daemon: smcroute.
root@trill:~# service smcroute start
Starting static multicast router daemon: smcroute.
root@trill:~# cat /proc/net/ip_mr_vif
Interface      BytesIn  PktsIn  BytesOut PktsOut Flags Local    Remote
 0 eth0              0       0         0       0 00000 0101A8C0 00000000
 1 eth1              0       0         0       0 00000 010A0A0A 00000000
 2 tun1              0       0         0       0 00000 01FF1FAC 00000000
root@trill:~# smcroute -a eth0 192.168.1.100 225.1.2.3 tun1
root@trill:~# ip mroute show
(192.168.1.100, 225.1.2.3)       Iif: eth0       Oifs: tun1

Multicast light: statikus multicast routing Linuxon (1.)

Mostanában szinte kizárólag Linuxokkal foglalkozom, és egyre többször találkozom sajátos megoldásokkal. Az egyik ilyen sajátosan linuxos megoldás a minden nélküli multicast, avagy "multicast light" lehetőség, ami valószínűleg eléggé unortodox, viszont cserébe egyszerű mint az ék, kevésbé összetett multicast környezetekben kiválóan alkalmazható.

A korrekt IPv4 multicast rendszerek működéséhez LAN oldalon IGMP-s hostok, IGMP querier a router(ek)en, illetve a switcheken IGMP snooping szükségeltetik, a routerek pedig egymás közt valamilyen multicast routing protokollal (pl. PIM vagy DVMRP) lerendezik, hogy melyik multicast csoportnak címzett forgalmat hová kell továbbítani. Az „smcroute” multicast routing megoldással tulajdonképpen ebből a listából mindent el lehet hagyni, ha elfogadhatóak számunkra az ezekkel járó kompromisszumok.

LAN oldalon a legfájóbb pont IGMP snooping hiánya lehet. Layer 2-ben a multicast forgalom alapesetben, extra konfiguráció nélkül, minden hosthoz eljut (flood), max. azok nem törődnek vele, ha nem tagjai az adott multicast csoportnak. Attól függően, hogy mekkora ez a multicast forgalom, hogy csak egy vékonyka, mondjuk 20Kbit/s-os tőzsdei árfolyam-streamről beszélünk, vagy durva, sok Mbit/s-os video streamről, ez az elárasztásos forgalom lehet szinte észrevehetetlen, megtűrt vagy éppen nagyon is zavaró. Az IGMP snoopinggal felvértezett switchek megértik a multicast hostok és az IGMP querier közötti IGMP üzenetváltásokat, és pontosan tudják, hogy egy adott pillanatban melyik portjuk mely multicast streamekre van feliratkozva, így nem árasztják el a teljes LAN-t, célzottan jutnak el a multicast csomagok a végállomásokra.

WAN oldalon a dinamikus multicast routing hiánya okozhat kényelmetlenséget, az smcroute-ot, és a vele járó statikus multicast útvonalakat ennek megfelelően olyan helyeken érdemes alkalmazni, ahol viszonylag kevés hostra kell eljuttatni a multicast streamünket. Az smcroute teszteléséhez a létező legegyszerűbb, a valódi környezetketől nem túlságosan távoli multicast tesztkörnyezet a következőképp nézne ki linuxos multicast routerekkel:

IP konfiguráció a hostokon (a teszt alatt használt OS egységesen Ubuntu 12.04.1, i386):

root@bajor:~# cat /etc/network/interfaces 
auto lo eth0

iface lo inet loopback

iface eth0 inet static
address 192.168.1.100
netmask 255.255.255.0
gateway 192.168.1.1
---
root@trill:~# cat /etc/network/interfaces 
auto lo eth0 eth1

iface lo inet loopback

iface eth0 inet static
address 192.168.1.1
netmask 255.255.255.0

iface eth1 inet static
address 10.10.10.1
netmask 255.255.255.0
---
root@vulcan:~# cat /etc/network/interfaces 
auto lo eth0 eth1

iface lo inet loopback

iface eth0 inet static
address 192.168.2.1
netmask 255.255.255.0

iface eth1 inet static
address 10.10.10.2
netmask 255.255.255.0
---
root@andoria:~# cat /etc/network/interfaces 
auto lo eth0

iface lo inet loopback

iface eth0 inet static
address 192.168.2.100
netmask 255.255.255.0
gateway 192.168.2.1

A Layer3-as VPN interfészek, azaz WAN VPN kapcsolat esetünkben OpenVPN „tun” tunnelt jelent a „trill” és a „vulcan” hoston, PSK-val. Először generáljuk le a PSK-t:

root@trill:~# cd /etc/openvpn/
root@trill:/etc/openvpn# openvpn --genkey --secret s2stunnel.psk
root@trill:/etc/openvpn# cat s2stunnel.psk
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
06d0ae16e16150f850462271490e1055
e0c516af702ccf95986660889f4f02ee
0abe658cebb12b326e32214a659ba70f
ee79a55158526101ed6c6477d05a03e7
40293591d110af3c45801f537c41d71b
59304d171084e6f174e44aba2c32766b
6a88b617a6ca8e0e371f040858c289ed
b83a5c943030ec4758065ee556a458f3
ce266b42e956a5c867586fde20f4d51a
396ebdade3f55d27fe12aa184b134298
aeaa91fdaf40f2d80bcb001969608c94
9daae5a2bbf03149b93cf076b80532cd
eb68c84c314bfc0eae8ba008c19a00f9
425b80005fb26e7bc2140442794813ec
e2718ce0df00f17473ac23561c4fd088
987f8ffb9864e448fb0f6a18d170bf2c
-----END OpenVPN Static key V1-----

Ezt a fájlt másoljuk át a „vulcan” ugyanezen a könyvtárba, úgy, hogy közben lehetőleg ne publikáljuk az interneten a PSK-t, majd folytathatjuk a „trill” konfigurációját a tunnel beállításával:

root@trill:/etc/openvpn# cat s2stunnel.conf 
daemon
verb            3
#ubuntu openvpn init script handles this:
#writepid       /var/run/openvpn-s2stunnel.pid
#ubuntu openvpn init script handles this:
#status         /var/run/openvpn-s2stunnel.status 30
log             /var/log/openvpn-s2stunnel.log
log-append      /var/log/openvpn-s2stunnel.log
dev-type        tun
dev             tun1
ping            10
ping-restart    60
ifconfig        172.31.255.1 172.31.255.2
local           10.10.10.1
lport           1194
remote          10.10.10.2
rport           1194
route           192.168.2.0 255.255.255.0
cipher          bf-cbc
keysize         128
auth            sha1
secret          /etc/openvpn/s2stunnel.psk

A „vulcan”-on egy nagyon hasonló konfigurációs fájlt kell összeállítanunk, figyelve arra, hogy a helyi és a távoli IP-k, subnetek értelemszerűen változzanak. Ha készen vagyunk, indítsuk újra mindkét VPN gateway-en az OpenVPN szolgáltatást a „service openvpn restart” paranccsal. Ne feledjük az IP forwarding engedélyezését a procfs-en keresztül; amennyiben mindent jól csináltunk, kapunk egy új, „tun1” nevű, multicastra képes virtuális interfészt mindkét gépen, és a két „tun1” IP tudja pingelni egymást:

root@trill:/# ifconfig tun1
tun1      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:172.31.255.1  P-t-P:172.31.255.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:7 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:588 (588.0 B)  TX bytes:588 (588.0 B)

Ezzel eljutottunk a tulajdonképpeni témához, a multicast routeolás beállításához. Linux alatt ehhez a funkcióhoz egy multicast routing démont kell telepíteni, amennyire tudom, összesen három ilyen szoftver létezik Linuxra, az „mrouted” (DVMRP), a „pimd” (PIM) és az „smcroute”. Egyszerre csak egy multicast routing démon futhat, teljesen felesleges mindegyiket felpakolni. Az „smcroute” sajátossága, hogy egyáltalán nem dinamikus, nem valósít meg semmilyen multicast routing protokollt, így a démon elindulása után nekünk magunknak kell kézzel felvennünk a multicast útvonalakat.

Ubuntuban az smcroute az „apt-get install smcroute” paranccsal telepíthető. Sajnálatos hiányosságnak érzem az aktuális LTS-ben, hogy az alapértelmezett repóból feltett csomag SEGFAULT-tal elszáll, amint egynél több multicast képes interfészt talál a rendszeren -- ez némiképp megnehezíti a rendeltetésszerű használatát. Remélhetőleg a problémát hamarosan javítani fogják, a teszt alatt egyszerűen lecseréltem az "/usr/sbin/smcroute" binárist egy saját fordítású, friss, 1.99-es verziójú binárisra, de minden mást meghagytam a repóból feltett csomagból.

Amennyiben fut a multicast démon (service smcroute start), azonnal életre kelnek a procfs-en a multicastos virtuális fájlok, a /proc/net/ip_mr_vif például tartalmazza a multicastra fogható interfészek jellemzőit:

root@trill:/# cat /proc/net/ip_mr_vif 
Interface  BytesIn  PktsIn  BytesOut PktsOut Flags Local    Remote
 0 eth0          0       0         0       0 00000 0101A8C0 00000000
 1 eth1          0       0         0       0 00000 010A0A0A 00000000
 2 tun1          0       0         0       0 00000 01FF1FAC 00000000

Mindössze annyi dolgunk marad még, hogy felvegyük a megfelelő helyre mutató multicast route-okat a „trill”-en és persze a „vulcan”-on, a következő paranccsal: „smcroute -a <in-ifname> <source-ip> <multicast-group>  <out-ifname> [<out-ifname> ...]”.

root@trill:/# smcroute -a eth0 192.168.1.100 225.1.2.3 tun1
---
root@vulcan:/# smcroute -a tun1 192.168.1.100 225.1.2.3 eth0 

A -r kapocsolóval törölhetők a korábban felvett multicast útvonalak, az éppen érvényben lévő listát pedig az ip mroute show paranccsal kérdezhetjük le. Ezzel a két statikus bejegyzéssel biztosítottuk, hogy a 192.168.1.100-as forrásról a 225.1.2.3-as csoportnak küldött adatok átjussanak a WAN-on. A következő részben a parancssorból teszteljük a megoldást.

RIverbed offtopic érdekességek

Egy kis érdekesség egy Riverbed Steelhead 550-es WAN optimizer CLI-jéből. A legmenőbb networkös cégeknél mindig vannak magyarok:

amnesiac > show ver

Product name:      rbt_sh

Product release:   7.0.1

Build ID:          #202_11

Build date:        2012-02-09 17:16:08

Build arch:        i386

Built by:          root@miskolc

Uptime:            2m 29s

Product model:     550

System memory:     1549 MB used / 475 MB free / 2024 MB total

Number of CPUs:    2

CPU load averages: 1.85 / 0.76 / 0.28

amnesiac >

Ha már Riverbed, akkor még egy dolog, amiről érdemes tudni: kb. két éve megvették kilóra a Wireshark mögött álló céget, persze maga a kód GPL-es, de a tudás, a kulcsemberek, mind-mind Riverbed alkalmazottak. A legszebb az egészben, hogy itt nem történtek olyan baklövések, mint amelyek például az OpenOffice és az Oracle esetében a LibreOffice forkhoz vezettek -- szintén ugye két éve. Nem tépték szét a fejlesztői közösséget, nem akarták kisajátítani a Wiresharknak a protokoll analizátorok közötti páratlan népszerűségét, építettek rá egy üzleti modellt, tök jó termékek kaphatók, egy Cascade Shark appliance-t például egyszer szívesen meghajtanék.

Szóval riszpekt, köszi, hogy nem kúrtátok el, és persze üdv a magyar kollégá(k)nak.

Mekkora egy switch késleltetése?

A napokban egy összetett alkalmazáskésleltetés-mérési projekt kapcsán felmerült a kérdés, hogy hol legyen az első mérési pont a rendszerben. Maga a rendszer egy több hostos elosztott alkalmazás, amiben mindenfelé létre lettek hozva mérési pontok. Nyilvánvaló, hogy az első mérési pont ott kell, hogy legyen, ahol bejutnak az adatok a rendszerbe, ezt történetesen egy Linux. A teljes elosztott alkalmazás késleltetési ideje sok milliszekundumos nagyságrendben mozog, nekem meg sem fordult a fejemben, hogy az említett első mérési pontot nem ezen a gateway Linux rendszeren kellene létrehozni, de egy kolléga felvetette, hogy van ám az előtt a Linux előtt egy switch is, és hogy gyakorlatilag az az első eszköz a teljes rendszerben, azon kellene egy monitor portot konfigurálni, hogy valóban a legkorábbi ponton kapjuk el a bejövő adatokat.

Ekkor kibújt belőlem a networkös, hiszen a switching, akár a gyorsabb cut-through de még a lassabb store-and-forward esetében is a milliszekundumos nagyságrend alatt, mikroszekundumos berkekben mozog. Arról nem is szólva, hogy az elosztott rendszer hostjai közötti NTP szinkronizációnak is vannak korlátai, sosem törtem ilyenen a fejem, de állítólag LAN-on az NTP szinkronizáció precizitása jó, ha megüti a 20 mikroszekundumos tartományt. Ergo felesleges vesződni a monitor porttal, ha nem is tudjuk olyan precízen jegyzetelni az adatokat, amennyit az egyetlen switcheléssel korábbi sniffing jelentene.

Ennek apropóján utánanéztem, hogy tulajdonképpen mennyi az annyi: mekkora manapság a switchek késleltetése? Átpörgettem pár adatlapot különböző gyártóktól, és arra jutottam, hogy az enterprise termékek esetében a mezei 100Mb/s-es eszközöktől a 10Gb/s-es Ethernet eszközökig nagyjából néhány tíz mikroszekundumos késleltetéssel lehet számolni. Persze nehéz ezeket az adatokat összehasonlítani, hiszen nem ugyanazokkal a módszerekkel dolgoznak a különböző műhelyek a mérések során, van ahol a beérkező keret első bitjétől megy a stopper a kimenő keret első bitjéig, máshol (store-and-forward méréseknél) a beérkező keret utolsó bitjétől a kimenő első bitjéig. Gyakran nincs feltüntetve, hogy mekkora Ethernet keretméret mellett végezték a mérést, máshol egész adatsorok vannak egészen jumbo frame méretig. De úgy körülbelül a néhány tíz mikroszekundum jó közelítést ad, és ez nagyjából a kilencvenes évek közepe, az ASIC áramkörök switchekben való megjelenése óta így van. Az alapok a cisco.com-on elolvashatók a "Cut-Through and Store-and-Forward Ethernet Switching for Low-Latency Environments" doksiban.

Persze vannak extrém igényeket kielégítő termékek is. Úgy tűnik, hogy mostanában a low latency switching piacot leginkább a tőzsdei rendszerek, illetve azoknak is egy speciális szegmense, a High-Frequency Trading rendszerek fűtik. Az egyik, erre a piacra szakosodott gyártó, az Arista például 600 nanoszekundumos késleltetésű cut-through switchekkel hergeli a vevőit már a tervezési dokumentumaiban is, így rackek között is már 2,4 mikroszekundomot képesek elérni.

No, ettől messze vannak azok az eszközök, amikhez én hozzáférek, de épp volt kéznél egy 3Com 5500-EI, gondoltam kipróbálom, hogy mekkora a késleltetése, nem éppen mai darab, de legalább enterprise cucc. Az adatlap pusztán annyit közöl, hogy "Store-and-forward switching; latency <10 μs". Lássuk. Elővettem a Systimax patchkábeleket, két egyforma laptopot, egyforma OS-szel (Ubuntu 12.04.1), és céleszköz híján ment a ping, először 1000 bájtos mérettel:

50 packets transmitted, 50 received, 0% packet loss, time 48998ms
rtt min/avg/max/mdev = 0.462/0.495/0.528/0.036 ms

Hm... 495μs átlagos RTT-re, annak a fele 247,5μs, igaz ebben benne van az is, hogy a switchtől független két OS-en át kell verekednie magát, valószínűleg maga a kapcsolás sokkal rövidebb ideig tart, mint amennyi idő alatt a két végen lévő TCP/IP stacken átjut az ICMP, de valahogy akkor is kevesebbre számítottam. Aztán kipróbáltam 32 bájtos mérettel is:

50 packets transmitted, 50 received, 0% packet loss, time 48998ms
rtt min/avg/max/mdev = 0.167/0.184/0.218/0.021 ms

Így már csak 184μs az átlagos RTT, azaz egy átlagos odaút már csak 92μs, úgy, hogy ebben a két Linux TCP/IP stackje is benne van, nem csak a kapcsolás. Ez valóban sokkal közelebb van az adatlap alapján megcélzott <10μs-hez, gyakorlatilag én ezt a a <10μs adatot már simán el is hiszem.