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.