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ó.

Link Layer Discovery protokollok használata (1.) - Nortel NDP (SONMP)

Ismerjük, szeretjük a CDP-t, sokszor szó szerint életet ment, ha futtatjuk az eszközeinken, pótolhatatlan a hálózati dokumentációk készítésekor, jelentősen megkönnyíti a diagnosztikát, de természetesen ennek a protokollnak is, mint annyi minden másnak, megvannak a hátrányai, biztonsági kockázatai, amikkel nem árt, ha tisztában vagyunk.

A könnyebb kezelhetőség persze nagy úr, nem véletlen, hogy a Cisco versenytársai is kifejlesztették a saját Layer2-es protokolljaikat, amelyek a CDP-hez hasonlóan működnek, ilyen például a Nortel eszközökön futó NDP - Nortel Discovery Protocol, ugyanennek a korábbi verziói még SynOptics Network Management Protocol, SONMP néven futottak, aztán a 3Com eszközökben létezik egy másik NDP, a Neighbor Discovery Protocol (ami, tegyük hozzá, nem azonos egy harmadik NDP-vel, az IPv6 Neighbor Discovery Protocol-lal). Illetve pár éve itt van a nyakunkon az LLDP (Link Layer Discovery Protocol), ami a Layer 2-es eszközfelderítés új szabványa, és minden kurrens terméknek illik ismernie. A CDP használatát azt hiszem, felesleges külön részletezni, a többit pedig lássuk csak sorjában.

A Nortel eszközökön nagyjából három parancsot kell ismernünk az NDP használatához, ezek a következők:

Nortel-SW#show autotopology settings
Autotopology:  Disabled
Last NMM Table Change:  0 days, 00:00:20
Maximum NMM Table Entries:  100
Current NMM Table Entries:  1
Nortel-SW#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Nortel-SW(config)#autotopology
Nortel-SW(config)#exit
Nortel-SW#show autotopology settings
Autotopology:  Enabled
Last NMM Table Change:  0 days, 00:00:00
Maximum NMM Table Entries:  100
Current NMM Table Entries:  4
Nortel-SW#show autotopology nmm-table
LSlot                                                                     RSlot
LPort IP Addr         Seg ID   MAC Addr     Chassis Type     BT LS  CS    RPort
----- --------------- -------- ------------ ---------------- -- --- ----  -----
 0/ 0 10.16.0.48      0x000000 0019E1D65401 5510-24T         12 Yes NEW   NA
 1/ 1 10.16.0.49      0x000101 001A8FAB3001 5510-24T         12 Yes TPCH  1/ 1
 1/23 10.16.0.2       0x000104 0017654A0003 Passport 8610    12 Yes HTBT  1/ 4
 1/24 10.16.0.3       0x000104 0016CAB68003 Passport 8610    12 Yes HTBT  1/ 4

A fenti példában először ellenőriztem, hogy egyáltalán fut-e a discovery protokoll (show autotopology settings), a negatív eredmény láttán gyorsan elindítottam (conf t, autotopology, exit), újra leellenőriztem, hogy fut-e, majd megnéztem a protokoll által összeszedett szomszédos eszközök listáját (show autotopology nmm-table). Az eredmény első sorában az éppen nyüstölt Nortel 5510-24T switch látszik, aminek három szomszédja van: ezek az 1/1-es, 1/23-as és 1/24-es porton csatlakoznak, kettő közülük core eszköz a Passport 8600-as sorozatból. Nortel fronton ennyit lehet kiszedni az eszközökből, az IOS-en meglévő show cdp neighbors detail parancsnak Nortel oldalon nincs megfelelője, így csak a legalapvetőbb alapvető információkhoz tudunk hozzáférni.

A Nortel 8600-asokkal kapcsolatban már korábban említettem, hogy teljesen más operációs rendszert futtatnak, semmiben sem hasonlíthatók a kisebb Nortelekhez, és ezekkel a nagy eszközökkel valahogy még nem sikerült igazán megbarátkoznom, különös logikával épül fel a CLI, de azért ezekben is listázni lehet a szomszédokat, zölddel jelöltem a 10.16.0.48-as eszközön már listázott eszközöket.

ESC-8600-001:5# show sys topology

================================================================================
                                 Topology Table
================================================================================
Local                                                                   Rem
Port  IpAddress   SegmentId MacAddress   ChassisType       BT LS  CS    Port
--------------------------------------------------------------------------------
 0/0  10.16.0.2   0x000000  0017654a0000 ERS8610           12 Yes HtBt  0/0
 1/1  10.16.0.51  0x000118  0019e1d4d000 mBayStack5510-24T 12 Yes HtBt  1/24
 1/2  10.16.0.52  0x000118  0019e1d6a400 mBayStack5510-24T 12 Yes HtBt  1/24
 1/4  10.16.0.48  0x000117  0019e1d65401 mBayStack5510-24T 12 Yes HtBt  1/23
 1/8  10.16.0.56  0x000101  000f6a7dcbe1 mBayStack420      12 Yes HtBt  1/1
 1/45 10.16.0.53  0x000116  0019e1d6f800 mBayStack5510-24T 12 Yes HtBt  1/22
 1/47 10.16.0.3   0x00012f  0016cab68036 ERS8610           12 Yes HtBt  1/47
 1/48 10.16.0.3   0x000130  0016cab68037 ERS8610           12 Yes HtBt  1/48

Ha feltételezzük, hogy ez a képzeletbeli LAN csak Nortel eszközökből áll, akkor nincs is szükségünk egyébre egy részletes topológia megrajzolásához, mint hogy  a core eszközök (10.16.0.2 és 10.16.0.3) NDP-vel összegyűjtött információi alapján végigmenjünk a switcheken, úgy, ahogy azt megtettük fentebb a 10.16.0.48 esetében. Ha más gyártó eszközeit is beépítettük, akkor viszont nem jutunk sokra kizárólag a Nortel NDP-re hagyatkozva. A következő részben a 3Com NDP lesz terítéken.

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.