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

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.

Link Layer Discovery protokollok használata (3.) - HP ProCurve - CDP és LLDP

Az előző részekben a Nortel és a 3Com saját layer2-es discovery protokolljának használata volt terítéken, a mai poszt ugyanezt tenné a HP régebbi termékei (ProCurve) kapcsán, ha lett volna a HP-nek saját layer2-es discovery protokollja. Ilyesmivel azonban a HP a ProCurve termékeiben nem jelentkezett, van viszont ezeken az eszközökön Cisco CDP támogatás, ami valójában sokkal inkább praktikus, mint a korábbi gyártóknál látott egyedi protokoll implementálása.

Egyetlen gond van a HP CDP támogatásával, nevezetesen az, hogy a legtöbb mostanában használt HP eszközön ez már csak egyirányú, pusztán olvassa a szomszédos Cisco ketyerék CDP üzeneteit, ő maga viszont nem küld semmiféle CDP információt. Nem volt ez mindig így, az előző mondat nagyjából 2007 óta érvényes, korábbi firmware-ekben ugyanis teljes CDP támogatás volt a HP-nél, boldogan küldték és fogadták a HP eszközök a CDP-s layer2 PDU-kat. 2006-ban azonban véglegessé vált az LLDP (802.1ab), amelynek a létrejöttében jelentős szerepet töltött be a HP, így gyakorlatilag ők voltak az első olyan nagyobb hálózatieszköz-gyártók, akik letették a vevőik elé az új protokollt. Azóta LLDP-t küldenek és fogadnak is a HP cuccok, CDP-t viszont csak fogadni tudnak.

Maga a CDP támogatás a régi HP platformon (ProCurve) roppant ismerősen kezelhető, nincs érdemi eltérés az IOS-hez képest, priv exec módban show cdp-vel kérdezhetjük le a protokoll állapotát, a szomszédokat a show cdp neighbors [detail] parancsokkal nézegethetjük, konfig módban pedig a [no] cdp run-nal kapcsolhatjuk globálisan ki és be. Az egyes CLI üzemmódok (exec, priv exec, config stb.) közt ugyanúgy lehet váltani mint az IOS-ben, szóval itt nagy meglepetések nem érhetik az embert.

Az LLDP kezelése felhasználói szemmel nem sokban különbözik, ezt is konfig módban kell engedélyezni (lldp run / no lldp run), alapértelmezésben fut. A show cdp neighbors parancshoz hasonló az outputja a show lldp info remote-device parancsnak:

HP-SW# show lldp info remote-device
 

  LLDP Remote Devices Information

  LocalPort | ChassisId                 PortId PortDescr SysName             
  --------- + ------------------------- ------ --------- ----------------------
  24        | 00 23 ac 33 3b 00         Gi0/1  Gigabi... CiscoSW             
 

A show cdp neighbor detail LLDP-s párja pedig a show lldp info remote-device<portszám> parancs, ahol a portszámot a show lldp info remote-device kimenetéből mazsolázgathatjuk ki, a fenti esetben például csak egy szomszéd van, a 24-es porton:

HP-SW# show lldp info remote-device 24
 

 LLDP Remote Device Information Detail

  Local Port   : 24
  ChassisType  : mac-address       
  ChassisId    : 00 23 ac 33 3b 00      
  PortType     : interface-name
  PortId       : Gi0/1                  
  SysName      : CiscoSW                     
  System Descr : Cisco IOS Software, C2960 Software (C2960-LANBASEK9-M), V...
  PortDescr    : GigabitEthernet0/1                                        

  System Capabilities Supported  : bridge
  System Capabilities Enabled    : bridge

  Remote Management Address
     Type    : ipv4
     Address : 10.10.136.250

Ahhoz, hogy mindez látható legyen a HP switchen, Cisco oldalon az alapértelmezettől eltérő konfiguráció szükséges, be kell kapcsolnunk az IOS-ben az LLDP támogatást, amihez relatíve friss IOS szükséges. A fenti példában szereplő 2960-as például 2008-as gyártású, mégsem volt rajta LLDP, frissítenem kellett, de a protokoll elvileg elérhető már az IOS 12.2-es verzióira is.

Mivel minden más gyártó is szépen sorban kiadta az LLDP-t támogató szoftververzióit, a Cisco-nak egyre gyakrabban kell szembenéznie azzal a kérdéssel, hogy meddig szeretné cipelni még a CDP-t. Szerintem nagyjából ugyanazt a folyamatot láthatjuk majd a layer2-es discovery protokoll témában is, mint ami a VLAN trönkölés estén történt, és úgy fogja apránként lenyomni a CDP-t az 802.1ab (LLDP), ahogyan az ISL-t felváltotta szinte mindenhol a 802.1q. A CDP-LLDP párharcban teljesen új frontot nyitottak az IP telefonok, illetve az LLDP-MED (azaz LLDP for Media Endpoint Devices). Az LLDP-MED nem más, mint a LLDP bővítése olyan végponti berendezések számára hasznos lehetőségekkel, mint a Voice VLAN automatikus egyeztetése a telefon és a switch közt, vagy az áramfelvétellel kapcsolatos igények és lehetőségek egyeztetése a PoE switch és a telefon közt.

Link Layer Discovery protokollok használata (2.) - 3Com NDP

Az előző részben a Nortel NDP (SONMP) volt terítéken, a mai poszt a 3Com eszközökön futó, a Nortel megoldásához hasonlóan szintén gyártóspecifikus 3Com Neighbor Discovery Protocol használatát mutatja be röviden. Az NDP alapértelmezésben engedélyezve van a 3Com eszközön, de csak azokon támogatott, amelyek a 3ComOS-t használják (kb. a 2004-től megjelenő enterprise 3Com termékek, pl. 4500-as, 5500-as, switchek, 6000-es routerek, 7700-as és 8800-as moduláris switchek stb.). Ugyanezt a protokollt megtaláljuk a genetikailag rokon márkákban, gondolok itt a H3C és a Huwaei kütyüire, valamint a HP egyes termékeire, amelyeken az itt bemutatott példák ugyanúgy működnek.

A protokoll ki- illetve bekapcsolása System View-ban történik, alapértelmezésben fut az NDP minden porton. A norteles megoldáshoz hasonlóan itt sincs túlbonyolítva a dolog, két parancsot kell ismernünk az NDP használatához:

<3ComSwitch>display ndp
 Neighbor Discovery Protocol is disabled.
 Neighbor Discovery Protocol Ver: 1, Hello Timer: 60(s), Aging Timer: 180(s)
<3ComSwitch>sys
System View: return to User View with Ctrl+Z.
[3ComSwitch]ndp enable
[3ComSwitch]quit
<3ComSwitch>display ndp
 Neighbor Discovery Protocol is enabled.
 Neighbor Discovery Protocol Ver: 1, Hello Timer: 60(s), Aging Timer: 180(s)
 Interface: GigabitEthernet1/0/1
    Status: Enabled, Pkts Snd: 211909, Pkts Rvd: 210588, Pkts Err: 0
    Neighbor 1:  Aging Time: 122(s)
       MAC Address : 0018-6e43-59c0
       Host Name   : SZSW-184R0
       Port Name   : GigabitEthernet1/0/49
       Software Ver: 3Com OS V3.03.02s168ep10
       Device Name : Switch 5500-EI
       Port Duplex : AUTO
       Product Ver : 5500-EI-1702P12
       BootROM Ver : 4.04

 Interface: GigabitEthernet1/0/2
    Status: Enabled, Pkts Snd: 211909, Pkts Rvd: 211997, Pkts Err: 0
    Neighbor 1:  Aging Time: 129(s)
       MAC Address : 0016-e0ee-7d80
       Host Name   : SZSW-204OB2
       Port Name   : GigabitEthernet1/0/24
       Software Ver: 3Com OS V3.03.02s168p07
       Device Name : Switch 5500G-EI
       Port Duplex : AUTO
       Product Ver : 5500G-EI-1702P11   
       BootROM Ver : 5.03

 Interface: GigabitEthernet1/0/3
    Status: Enabled, Pkts Snd: 211909, Pkts Rvd: 0, Pkts Err: 0

 Interface: GigabitEthernet1/0/4
    Status: Enabled, Pkts Snd: 211909, Pkts Rvd: 212034, Pkts Err: 0
    Neighbor 1:  Aging Time: 179(s)
       MAC Address : 0012-a9a6-5f80
       Host Name   : SZSW-201OB2
       Port Name   : GigabitEthernet1/0/24
       Software Ver: 3Com OS V3.03.02s168p07
       Device Name : Switch 5500G-EI
       Port Duplex : AUTO
       Product Ver : 5500G-EI-1702P11
       BootROM Ver : 5.03

 Interface: GigabitEthernet1/0/5
    Status: Enabled, Pkts Snd: 0, Pkts Rvd: 0, Pkts Err: 0

 Interface: GigabitEthernet1/0/6
    Status: Enabled, Pkts Snd: 0, Pkts Rvd: 0, Pkts Err: 0

 Interface: GigabitEthernet1/0/7
    Status: Enabled, Pkts Snd: 0, Pkts Rvd: 0, Pkts Err: 0

 Interface: GigabitEthernet1/0/8
    Status: Enabled, Pkts Snd: 0, Pkts Rvd: 0, Pkts Err: 0

A display ndp parancs vagy nagyon rövid vagy igen hosszas kimenet ad. Az első esetben mindössze annyit közöl a felhasználóval, hogy tiltva van az NDP (és ha futna, akkor milyen protokollverziót futtatna az eszköz, illetve milyen időzítésekkel dolgozna az NDP táblázat kitöltésekor). A másik esetben, amikor működik az NDP, minden porthoz kilistázza az oda tartozó szomszédokat, ezt lehet még szűkíteni a listázandó interfészek definiálásával (pl. display ndp interface GigabitEthernet 1/0/1). Az NDP letiltása egy bizonyos porton az undo ndp enable interface <interfésznév> paranccsal történik.

A 3Com NDP sem kompatibilis semmilyen szinten a CDP-vel vagy egyéb hasonló protokollokkal, ilyesmit majd csak az LLDP-től várhatunk, amiről a sorozat későbbi részében lesz szó.

Parancssori SNMP eszközök (5.) - STP

A korábbi részekben (első, második és harmadik) ezt-azt már kiolvasgattunk az SNMP fából, a negyedikben írtunk is bele alapvető dolgokat, a mai részben újra előveszem a BRIDGE MIB-et, van ebben ugyanis egy fontos ág, amit eddig nem érintettünk, az .1.3.6.1.2.1.17.2, azaz a dot1dStp, ami minden lényeges információt tartalmaz az eszközünkön futó feszítőfa (feszítőfák) állapotáról, illetve annak (azoknak) időbeli változásairól.

Kezdjük a Bridge ID prioritás mezőjének kiolvasásával, ennek az értéke az .1.3.6.1.2.1.17.2.2.0 OID-jű levélre van írva (dot1dStpPriority). Egyébként ez is read-write objektumként van a MIB-ben definiálva, így visszautalva az előző, snmpwrite-os részre: tényleg figyeljünk az eszközeinkre az SNMP RW jogosultságok tekintetében, legyünk rettenetesen szűkmarkúak, és ahol csak módunk van rá, használjuk az SNMP v3 titkosítási lehetőségeit. Gondoljunk csak bele, hogy mekkora galibát tud okozni egy olyan szkript, ami időnként ciklusban végigfut egy subnet minden hostján és ahol tudja, átírogatja a Bridge ID-kat... szinkronizálatlan SQL adatbázisok, szétesett clusterek, TCP sessionök véres cafatkái maradnak mindenhol a nyomában. Ehelyett mi inkább újra csak olvasunk SNMP-n keresztül:

admin@NMS:~$ snmpwalk -v1 -cpublic 10.10.10.250 .1.3.6.1.2.1.17.2.2.0
SNMPv2-SMI::mib-2.17.2.2.0 = INTEGER: 32769

Ez nagyjából minden nagyobb gyártónál hasonlóan működik, ugyanakkor vegyük azt is figyelembe, hogy nem minden gyártónál van alapból bekapcsolva az STP/RSTP/MSTP támogatás, például a HP ProCurve szériákon, így az általam teszteszközként használt 2824-esen sincs, ennek megfelelően amíg be nem kapcsoljuk az STP-t, természetesen nem lehet kiolvasni semmit erről az OID-ről. A közvetlen ezután következő két levél (dot1dStpTimeSinceTopologyChange, illetve a dot1dStpTopChanges) is informatív, ha ismeretlen rendszereket térképezünk fel:

admin@NMS:~$ snmpwalk -v1 -cpublic 10.10.10.250 .1.3.6.1.2.1.17.2.3.0
SNMPv2-SMI::mib-2.17.2.3.0 = Timeticks: (134700) 0:22:27.00
admin@NMS:~$ snmpwalk -v1 -cpublic 10.10.10.250 .1.3.6.1.2.1.17.2.4.0
SNMPv2-SMI::mib-2.17.2.4.0 = Counter32: 78

A példa szerint a 10.10.10.250 feszítőfája 22 perce változatlan és az SNMP processz elindulása óta 78 alkalommal történt a STP topológiaváltozás. Talán egy kicsit kevésbé érdekes, de legalább annyira fontos a többi adat is, ami még innen kiolvasható:

admin@NMS:~$ snmpwalk -m +BRIDGE-MIB -v1 -cpublic 10.10.10.250 .1.3.6.1.2.1.17.2
BRIDGE-MIB::dot1dStpProtocolSpecification.0 = INTEGER: ieee8021d(3)
BRIDGE-MIB::dot1dStpPriority.0 = INTEGER: 32769
BRIDGE-MIB::dot1dStpTimeSinceTopologyChange.0 = Timeticks: (255600) 0:22:36.00
BRIDGE-MIB::dot1dStpTopChanges.0 = Counter32: 78
BRIDGE-MIB::dot1dStpDesignatedRoot.0 = Hex-STRING: 00 00 00 16 E0 18 74 00
BRIDGE-MIB::dot1dStpRootCost.0 = INTEGER: 39
BRIDGE-MIB::dot1dStpRootPort.0 = INTEGER: 1
BRIDGE-MIB::dot1dStpMaxAge.0 = INTEGER: 2000
BRIDGE-MIB::dot1dStpHelloTime.0 = INTEGER: 200
BRIDGE-MIB::dot1dStpHoldTime.0 = INTEGER: 100
BRIDGE-MIB::dot1dStpForwardDelay.0 = INTEGER: 1500
BRIDGE-MIB::dot1dStpBridgeMaxAge.0 = INTEGER: 2000
BRIDGE-MIB::dot1dStpBridgeHelloTime.0 = INTEGER: 200
BRIDGE-MIB::dot1dStpBridgeForwardDelay.0 = INTEGER: 1500
...

A kimenetből megtudhatjuk, hogy az STP root egy 0 prioritású 00 16 E0 18 74 00 MAC című eszköz, ami közvetve csatlakozik csupán, 100Mbit/s-os nagyságrendű linkeken (távolság: 39, emlékeztetőül az IEEE cost értékek: 100 - 10Mb/s, 19 - 100Mb/s, 4 - 1Gb/s, 2 - 10Gb/s) a port 1-en keresztül, illetve láthatjuk az STP időzítési adatait. Ezek után egy táblázat következik (dot1dStpPortTable, 1.3.6.1.2.1.17.2.15) az egyes portok STP állapotairól, a porthoz társított költségekről stb. amit csak három ponttal jelöltem, hiszen ahhoz külön parancs dukál:

admin@NMS:~$ snmptable -m +BRIDGE-MIB -Cl -Cb -v1 -cpublic 172.17.136.250 .1.3.6.1.2.1.17.2.15

Ám ezzel még nincs vége, a legtöbb eszköz, ha képes per VLAN STP-re, MSTP-re akkor is belegyömöszöli az egyes portok státusz információit egyetlen .1.3.6.1.2.1.17.2, azaz dot1dStp ágba, ami időnként félrevezető lehet, hiszen elvileg előfordulhat olyan eset mondjuk, hogy a VLAN1-en egy adott port forwarding státuszban van, míg mondjuk VLAN2-ben pedig blokkol. A Cisco eszközökön ez a dilemma megintcsak a VLAN ID alapján indexelt community stringekkel, illetve a VLAN-onként külön nyilvántartott BRIDGE MIB adatokkal van feloldva, így nem mindegy, hogy a community stringünk public (=public@1) vagy éppen public@2, hiszen az első a VLAN1-ben futogató feszítőfa adatairól ad információkat, a másik pedig a VLAN2-es feszítőfáról:

admin@NMS:~$ snmpwalk -m +BRIDGE-MIB -v1 -cpublic 172.17.136.250 .1.3.6.1.2.1.17.2
BRIDGE-MIB::dot1dStpProtocolSpecification.0 = INTEGER: ieee8021d(3)
BRIDGE-MIB::dot1dStpPriority.0 = INTEGER: 32769
BRIDGE-MIB::dot1dStpTimeSinceTopologyChange.0 = Timeticks: (491200) 1:21:52.00
BRIDGE-MIB::dot1dStpTopChanges.0 = Counter32: 78
BRIDGE-MIB::dot1dStpDesignatedRoot.0 = Hex-STRING: 00 00 00 16 E0 18 74 00
BRIDGE-MIB::dot1dStpRootCost.0 = INTEGER: 39
BRIDGE-MIB::dot1dStpRootPort.0 = INTEGER: 1
BRIDGE-MIB::dot1dStpMaxAge.0 = INTEGER: 2000
BRIDGE-MIB::dot1dStpHelloTime.0 = INTEGER: 200
BRIDGE-MIB::dot1dStpHoldTime.0 = INTEGER: 100
BRIDGE-MIB::dot1dStpForwardDelay.0 = INTEGER: 1500
BRIDGE-MIB::dot1dStpBridgeMaxAge.0 = INTEGER: 2000
BRIDGE-MIB::dot1dStpBridgeHelloTime.0 = INTEGER: 200
BRIDGE-MIB::dot1dStpBridgeForwardDelay.0 = INTEGER: 1500
BRIDGE-MIB::dot1dStpPort.1 = INTEGER: 1
BRIDGE-MIB::dot1dStpPort.45 = INTEGER: 45
BRIDGE-MIB::dot1dStpPortPriority.1 = INTEGER: 128
BRIDGE-MIB::dot1dStpPortPriority.45 = INTEGER: 128
BRIDGE-MIB::dot1dStpPortState.1 = INTEGER: forwarding(5)
BRIDGE-MIB::dot1dStpPortState.45 = INTEGER: forwarding(5)
BRIDGE-MIB::dot1dStpPortEnable.1 = INTEGER: enabled(1)
BRIDGE-MIB::dot1dStpPortEnable.45 = INTEGER: enabled(1)
BRIDGE-MIB::dot1dStpPortPathCost.1 = INTEGER: 19
BRIDGE-MIB::dot1dStpPortPathCost.45 = INTEGER: 19
BRIDGE-MIB::dot1dStpPortDesignatedRoot.1 = Hex-STRING: 00 00 00 16 E0 18 74 00
BRIDGE-MIB::dot1dStpPortDesignatedRoot.45 = Hex-STRING: 00 00 00 16 E0 18 74 00
BRIDGE-MIB::dot1dStpPortDesignatedCost.1 = INTEGER: 20
BRIDGE-MIB::dot1dStpPortDesignatedCost.45 = INTEGER: 39
BRIDGE-MIB::dot1dStpPortDesignatedBridge.1 = Hex-STRING: 80 00 00 1A C1 56 10 40
BRIDGE-MIB::dot1dStpPortDesignatedBridge.45 = Hex-STRING: 80 01 00 23 AC 33 3B 00
BRIDGE-MIB::dot1dStpPortDesignatedPort.1 = Hex-STRING: 80 DE
BRIDGE-MIB::dot1dStpPortDesignatedPort.45 = Hex-STRING: 80 2D
BRIDGE-MIB::dot1dStpPortForwardTransitions.1 = Counter32: 1
BRIDGE-MIB::dot1dStpPortForwardTransitions.45 = Counter32: 1
 
admin@NMS:~$ snmpwalk -m +BRIDGE-MIB -v1 -cpublic@2 172.17.136.250 .1.3.6.1.2.1.17.2
BRIDGE-MIB::dot1dStpProtocolSpecification.0 = INTEGER: ieee8021d(3)
BRIDGE-MIB::dot1dStpPriority.0 = INTEGER: 32770
BRIDGE-MIB::dot1dStpTimeSinceTopologyChange.0 = Timeticks: (4994600) 13:52:26.00
BRIDGE-MIB::dot1dStpTopChanges.0 = Counter32: 0
BRIDGE-MIB::dot1dStpDesignatedRoot.0 = Hex-STRING: 00 00 00 16 E0 18 74 00
BRIDGE-MIB::dot1dStpRootCost.0 = INTEGER: 39
BRIDGE-MIB::dot1dStpRootPort.0 = INTEGER: 3
BRIDGE-MIB::dot1dStpMaxAge.0 = INTEGER: 2000
BRIDGE-MIB::dot1dStpHelloTime.0 = INTEGER: 200
BRIDGE-MIB::dot1dStpHoldTime.0 = INTEGER: 100
BRIDGE-MIB::dot1dStpForwardDelay.0 = INTEGER: 1500
BRIDGE-MIB::dot1dStpBridgeMaxAge.0 = INTEGER: 2000
BRIDGE-MIB::dot1dStpBridgeHelloTime.0 = INTEGER: 200
BRIDGE-MIB::dot1dStpBridgeForwardDelay.0 = INTEGER: 1500
BRIDGE-MIB::dot1dStpPort.3 = INTEGER: 3
BRIDGE-MIB::dot1dStpPortPriority.3 = INTEGER: 128
BRIDGE-MIB::dot1dStpPortState.3 = INTEGER: forwarding(5)
BRIDGE-MIB::dot1dStpPortEnable.3 = INTEGER: enabled(1)
BRIDGE-MIB::dot1dStpPortPathCost.3 = INTEGER: 19
BRIDGE-MIB::dot1dStpPortDesignatedRoot.3 = Hex-STRING: 00 00 00 16 E0 18 74 00
BRIDGE-MIB::dot1dStpPortDesignatedCost.3 = INTEGER: 20
BRIDGE-MIB::dot1dStpPortDesignatedBridge.3 = Hex-STRING: 80 00 00 1A C1 56 10 40
BRIDGE-MIB::dot1dStpPortDesignatedPort.3 = Hex-STRING: 80 D9
BRIDGE-MIB::dot1dStpPortForwardTransitions.3 = Counter32: 1

Huawei switchek portkiosztása

Vegyes környezetben dolgozó networkösök a megmondhatói, hogy mennyi idegeskedés, bohóckodás lenne megspórolható, ha a gyártók ugyanolyan portkiosztást használnának az eszközeiken. Nyilvánvaló, hogy aki világéletében Cisco-n dolgozott, nem is érti a problémát, ott tiszta sor, hogy amióta Cisco a Cisco, a switcheken a portok számozása fentről lefelé, oszlopokban növekszik, az oszlopok pedig balról jobbra haladnak:

1  3  5  ...  47
2  4  6  ...  48

Kb. ugyanígy megy a Nortel, az Avaya, a HP vagy éppen a H3C eszközökön. De nem minden gyártó gondolkodik így. Ott van, illetve volt, példának okáért a 3Com, ahol a sor erősebb szervezőelv mint az oszlop:

1  2  3  ...  24
25 26 27 ...  48

És persze vannak ennél is hajmeresztőbbek, mint amilyen mondjuk a Huawei, ahol kíméletlenül, a legősibb tízéves holmijaiktól a legújabb eszközökig az alábbi logika alapján tolják:

2  4  6  ...  48
1  3  5  ...  47

No, ehhez még adjuk hozzá az emberi gyarlóságot, és ezekkel a rém egyszerű dolgokkal lehet aztán szopni vég nélkül, különösen akkor, ha vakon dolgozunk és mondjuk telefonon, idegen nyelven instruáljuk a másik végen lévő kollégát, vagy fordítva: ha éppen minket ugráltatnak. Valamilyen szoftverhibából eredően nekem például a "Nortel" márkanévhez időről időre a 3Com portkiosztás kapcsolódik, ha nem koncentrálok eléggé, és volt már olyan, hogy egy több VLAN-os Layer 2-es site-to-site VPN-t nulláról újrakonfiguráltam mindkét oldalon, mire végre beláttam, hogy csupán egy lukkal arrébb kellett volna próbálkozni. Persze tudja az eszével az ember, meg oda is van írva, sorban, számokkal, még világít is, ám hiába: mégsem kettes az a port, hanem hármas. A Huawei portkiosztására viszont szerintem nincs mentség, akármennyire is megtanultak jó eszközöket építeni, alulról kezdeni a számozást nem finom. Egy ideig azt gondoltam, hogy biztos a kínai írásrendszerben ez a tradicionális irány, mármint a lentől felfelé történő írás, de nem, így nem marad más, nyilvánvalóan a puhány nyugatiaknak szánt fricska az egész, és a belpiacos eszközök rendesen vannak számozva. :)

Egy kis érdekesség az SFP kompatibilitásról

Ma egy régóta porosodó 3Com 5500EI (3CR17161-91) access switchen frissítettem szoftvert, a legutolsó kiadott szoftververzió ehhez a hardverhez 2010 júniusban jött ki (3Com OS v.3.3.2ep10), már a HP-től. A szoftverezés után még gyorsan leellenőriztem, hogy az SFP bővítőhelyek mindegyike működik-e, egy 1000BaseT modult bedugtam az első SFP slotba, majd kötöttem egy csinos hurkot az SFP modulos port és a sima port1 között, hogy lássam, feljön-e a LED zöldben, illetve ezt a műveletet a másik három SFP helyen is megismételtem. Aztán csak úgy poénból bedugtam egy Cisco SFP modult a switchbe (GLC-SX-MM), amire egyből jött egy ilyen üzenet a konzolon:

<5500-EI>
%Nov 11 17:39:55:667 2011 5500-EI L2INF/5/PORT PHY TYPE CHANGE:- 1 -
 GigabitEthernet1/0/25 is 1000_BASE_SX_SFP

Nézek, mint a luki nyúl, nem éppen erre számítottam. Ilyen eddig szerintem nem volt, meg úgy általában a nagy gyártók ügyelnek arra, hogy az SFP moduljaik ID-jai különbözzenek annyira, hogy ne legyenek egymással kompatibilisek, szóval alig akartam hinni a szememnek. Nosza, gyorsan bepattintottam egy másik SFP slotba egy standard 3Com SX modult (3CSFP91), elővettem egy LC-LC kábelt, összekötöttem, és mindkét port feljött, sőt forgalom is volt rajta, olyannyira, hogy az STP el is vágta a hurkot, szóval biztosan működik:

<5500-EI>display stp brief
 MSTID     Port                   Role  STP State    Protection
   0     GigabitEthernet1/0/25    DESI  FORWARDING     NONE 
   0     GigabitEthernet1/0/26    BACK  DISCARDING     NONE 

 (*) means port in aggregation group

<5500-EI>

Besza-behu, vérszemet kaptam, elkezdtem túrni egyéb SFP modulok után, találtam Nortel SX modult (AA1419013), működik ez is. Avago SX HFBR-5710LP: megy, a D-Link DEM-311GT v.E1 szintén működik. Többféle SX modul nem volt a kezem ügyében, de akadt még két HP J4859B is, ezek LX-esek, és ezek is mennek. Létezik, hogy a HP kiszedte a korlátozást a megörökölt 3Com cuccokból esetleg azért, hogy a saját moduljait szállíthassa a legacy rendszerekhez? Érdekes. Emlékeim szerint, amikor először csináltam ilyen különböző gyártós modulcsereberét, az nem volt valami nagy sikertörténet. Annyira mélyen azért sosem merültem el ezekben a Layer 1 kompatibilitási dolgokban, hogy tudjam, melyik gyártótól érdemes modulokat venni, azonos optikai szabványon belül (pl. SX vagy LX) melyik beszállítót érdemes választani, nagyjából mindig mindenhez az eredeti gyártó hivatalos moduljait használtam. No, mindegy, így poszt vége felé már elfogyott a lendület. Annyira már lehet, hogy nem is érdekes :)

Update (2011-11-15): kipróbáltam 3Com 4500-ason és 5500G-n régebbi szoftverekkel is, a jelek szerint 3Com utolsó szériái mindenevők, legalábbis a switchek azok. Jó tudni.

LACP Cisco és HP ProCurve eszközök közt

Mivel még megvan a tegnapi tesztkörnyezet, gondoltam, kipróbálom egy régebbi HP eszközzel is, egy ProCurve 2824-es kallódott itt a környéken, leporolgattam, kiütöttem róla a régi konfigot. Az előző LACP-s teszthez hasonlóan egy két VLAN-os LACP összeköttetés létrehozása volt a cél. A Cisco 2960-as 47-es portja a HP 2824-es 23-as portjára van kötve, a 48-as pedig a HP 24-es portjára. Az IOS konfiguráció teljesen megegyzik a tegnapival:

Switch#configure terminal
Switch(config)#interface port-channel 1
Switch(config-if)#exit
Switch(config)#interface range Fa0/47 - 48
Switch(config-if-range)#channel-group 1 mode active
Switch(config-if-range)#exit
Switch(config)#interface port-channel 1
Switch(config-if)#switchport mode trunk
Switch(config-if)#switchport trunk allowed vlan 1-2
Switch(config-if)#exit
Switch(config)#exit

A HP Procurve switchen a konfiguráció az egyéb network OS-ekhez képest hihetetlenül egyszerű, ugyanakkor azt érdemes tudni, hogy a régi HP rendszereken "trunk" a neve ugyanannak a dolognak, amit mondjuk a Cisco EtherChannel néven illett, vagy amit éppen a 3Com link aggregationnek nevez. Szóval a régi HP terminológiában a "trunk" véletlenül sem a VLAN trönköléssel kapcsolatos fogalom, a VLAN-ok esetében a tagged és untagged fogalmakkal operálnak. Az aggregált link létrehozását az alábbi parancsokkal tehetjük meg:

ProCurve Switch 2824#configure
ProCurve Switch 2824(config)# trunk 23-24 trk1 lacp
ProCurve Switch 2824(config)# vlan 1 untagged trk1
ProCurve Switch 2824(config)# vlan 2 tagged trk1
ProCurve Switch 2824(config)# exit

A trunk paranccsal a korábbiakhoz hasonlóan (3Com manual mód) létrehozhatunk LACP nélküli aggregált linket is (trunk x-x trkX trunk), ám erre, ahogy arról szintén volt már korábban szó, aligha lesz szükségünk. A Cisco rendszerekhez hasonlóan a HP ProCurve switchen a virtuális interfész (trk1) módosításával lehet az aggregált link fizikai interfészeinek tulajdonságait állítgatni, ahogy a fenti példában is látható, a 23-as és 24-es portok a trk1-en keresztül kapják a VLAN tagságukra vonatkozó beállításokat. A linkek állapotát a show trunks és a show lacp paranccsal vizsgálhatjuk:

ProCurve Switch 2824# show trunks

Load Balancing

  Port | Name                             Type      | Group Type
  ---- + -------------------------------- --------- + ----- -----
  23   |                                  100/1000T | Trk1  LACP
  24   |                                  100/1000T | Trk1  LACP  

ProCurve Switch 2824# show lacp

                           LACP

   PORT   LACP      TRUNK     PORT      LACP      LACP
   NUMB   ENABLED   GROUP     STATUS    PARTNER   STATUS
   ----   -------   -------   -------   -------   -------
   1      Passive   1         Up        No        Success
   2      Passive   2         Down      No        Success
   3      Passive   3         Down      No        Success
   4      Passive   4         Down      No        Success
   5      Passive   5         Down      No        Success
   6      Passive   6         Down      No        Success
   7      Passive   7         Down      No        Success
   8      Passive   8         Down      No        Success
   9      Passive   9         Down      No        Success
   10     Passive   10        Down      No        Success
   11     Passive   11        Down      No        Success
   12     Passive   12        Down      No        Success
   13     Passive   13        Down      No        Success
   14     Passive   14        Down      No        Success
   15     Passive   15        Down      No        Success
   16     Passive   16        Down      No        Success
   17     Passive   17        Down      No        Success
   18     Passive   18        Down      No        Success
   19     Passive   19        Down      No        Success
   20     Passive   20        Down      No        Success
   21     Passive   21        Down      No        Success
   22     Passive   22        Down      No        Success
   23     Active    Trk1      Up        Yes       Success
   24     Active    Trk1      Up        Yes       Success

Reguláris kifejezések a különféle network OS-ekben (1.)

Az előző posztban említett kézi hálózatfelderítés során többször is alkalmaztam IOS alatt reguláris kifejezéseket a különféle parancsok kimenetének szűrésére, nem kell bonyolult dolgokra gondolni, csak nagyjából ilyesféle szűrésekre:

DEVICE#sh mac-address-table | include Gi1/0/1
   1    0001.e674.baa6    DYNAMIC     Gi1/0/13
   1    0001.e674.bab8    DYNAMIC     Gi1/0/1
   1    0001.e6a2.02b6    DYNAMIC     Gi1/0/13
   1    0002.e33c.5203    DYNAMIC     Gi1/0/13
   1    0002.e33c.5316    DYNAMIC     Gi1/0/15
   1    0002.e34f.08fd    DYNAMIC     Gi1/0/13
   1    0002.e34f.0a42    DYNAMIC     Gi1/0/13
   1    0002.e352.8dbb    DYNAMIC     Gi1/0/13
   1    000f.fe02.3f48    DYNAMIC     Gi1/0/13
   1    000f.fe30.880e    DYNAMIC     Gi1/0/13
   1    000f.fe31.920d    DYNAMIC     Gi1/0/15

DEVICE#sh mac-address-table | include Gi1/0/1$
   1    0001.e674.bab8    DYNAMIC     Gi1/0/1


Nyilván egyértelmű a különbség azok számára is, akik nem ismerik a regexpeket. A $ kifejezés a keresendő minta végéhez illeszkedik, tehát az az megelőző szöveges mintának a sorvégeken kell szerepelnie, ezért nem jelenik meg egy olyan sor sem a második példában, amelynek a végén nem pontosan a "Gi1/0/1" karaktersor áll. Ez persze az egyik legegyszerűbb példa, számtalan egyéb dolgot bevethetünk még, a regexpek használatának lehetősége átszövi az IOS-t, legtöbbször persze a különféle show kimeneteket szűrjük meg velük, de vannak más alkalmazási lehetőségek is, többek közt ilyen a BGP AS-path szűrés. Vajon mi a helyzet az egyéb OS-ekben?

A márciusban kiadott legújabb FortiOS-ben (4.0MR3) a CLI referencia kézikönyv szerint az alábbi területeken nyílik lehetőségünk regexp használatra:

• Data Leakage Prvention (DLP) szabályok definiálásakor
• BGP AS-path szűrésre
• Különféle e-mail szűrésekhez (e-mail cím alapú levélszűrésre, spamszűrőkben, MIME header szűrésre)
• Weboldalak tartalom- illetve URL alapú szűrésére
• CLI-ben a get, show és diagnose parancsok kimenetének szűrésére (a szokásosnak mondható include, exclude parancsok helyett itt egyszerűen csak grep a szűrő parancs)

A H3C/3Com örökséget tovább vivő HP Networking termékekben szintén megtalálható a regexp támogatás, hogy pontosan mire is használható, arról a  "Reguláris kifejezések a különféle network OS-ekben" következő részében lesz szó.

Cisco, HP, 3Com, H3C, Huawei CLI referencia

Gyanítom, az senkinek nem új hír, hogy a HP 2010-ben bekebelezte a 3Com-ot, azt viszont még a networkös szakmán belül sem szokás tudni, hogy a 3Com termékeken futó operációs rendszer, a 3Com OS gyakorlatilag megegyezik a Huawei eszközökön használt "Huawei Versatile Routing Platform Software" (VRP) rendszerrel, illetve a 3Com és a Huawei által még 2003-ban közösen gründolt H3C eszközein futó "H3C Comware Platform Software" (Comware) rendszerrel. Vagyis a 3Com OS, a Huawei VRP és a H3C Comware ugyanannak a network OS-nek változatai, nem különböznek jobban egymástól, mint a Cisco IOS különféle verziói: vannak bennük itt-ott apróbb eltérések, de ha valaki kiismeri magát a mondjuk a Comware-ben, az otthonosan fog mozogni a 3Com OS vagy a VRP alatt is. Sőt, a rokonság még ennél is szorosabb a volt 3Com, a jelenlegi Huawei, illetve a H3C termékek közt, az egyes termékeknek (persze nem mindnek) megvan (vagy volt) a maga testvére a másik két márka termékpalettáján, és ezek a testvérek bizony közös alkatrészeken is osztoznak. A kompatibilitás olyannyira létezik, hogy például e három márka SFP moduljai is csereszabatosak, használhatunk egy 3Com optikai modult Huawei vagy H3C eszközben és persze a dolog fordítva is igaz.

A HP megjelenésével tovább bővült ezt a nagyjából azonos hardver- és szoftverplatformot felhasználó márkák száma, a HP Networking termékek ezt a közös, illetve most már a HP tulajdonában lévő platformot használják. Csupa öröm egy ilyen platformot megtanulni, hiszen egycsapásra lehet bővíteni az önéletrajzunkat 3Com, Huawei, H3C és HP termékek ismeretével :). Ráadásul ebben a HP hatékony segítséget ad, most találtam rá a "HP Networking and Cisco CLI Reference Guide"-ra, amiben funkcióról funkcióra haladva összevetik a régi HP ProCurve termékeken futó ProVision, a 3Com-Huawei-H3C-HPN-féle Comware és a Cisco IOS parancsokat. A doksi kellően alapos, semmi sallang, nem próbálja megmagyarázni a különféle protokollokat, szabványokat, parancsok és példák gyűjteménye kevesebb mint háromszáz oldalon, kötelező minden networkös számára. Jó néhány évig még biztosan hasznát lehet venni, amíg el nem távolodik nagyon egymástól a régi 3Com-féle legacy rendszerek és a legújabb H3C/HPN rendszerek tudása.