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.

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.

Parancssori SNMP eszközök (3.) - CAM tábla kiolvasása

A korábbiakban már volt szó az alapvető rendszerinformációkról, illetve az interfész tábla és az ARP tábla adatainak "kézi" kiolvasásáról SNMP-n keresztül, a mai poszt a switchek CAM táblájának adaihoz való hozzáférésről szól. Ezt az információt általában valamilyen show (display) alparanccsal kaphatjuk meg a network OS-ek alatt, és alapvetően ugye azt az információt adja meg, hogy egy adott MAC című host fizikailag mely switchporton keresztül érhető el, a kapcsolási folyamat e táblázat alapján dolgozgat.

Mielőtt rátérnénk a lényegre, nem árt egy rövid kitérőt tennünk, ugyanis az eddig kiolvasott adatok mind az RFC1213-ben voltak definiálva, a mostani adatok viszont túl specifikusak, hiszen nem minden SNMP-s eszköz képes Ethernet kapcsolásra. Ennek megfelelően az erre vonatkozó objektumok külön MIB-et kaptak: a BRIDGE-MIB (RFC 1493) írja le őket. Félreértés ne essék, ha egy SNMP agent támogatja a BRIDGE-MIB-et, akkor abból az SNMP kliens eszközünkkel OID alapján nagyjából minden kiolvasható, ám az OID-k helyett egyszerűbb a nevek használata, ehhez pedig elengedhetetlen a megfelelő MIB megléte SNMP kliens oldalon is.

A net-snmp csomagnak nem része alapból a BRIDGE-MIB, így ezt érdemes importálnunk, mielőtt tovább haladnánk. Több helyen is részletes útmutatót olvashatunk arról, miképp okosíthatjuk fel a net-snmp-t extra MIB-ekkel, itt most talán a legegyszerűbb módszert érdemes követnünk, amihez elegendő felhasználói szintű hozzáférés:

user@NMS:~$ wget ftp://ftp.cisco.com/pub/mibs/v1/BRIDGE-MIB.my
--2011-09-06 19:28:58--  ftp://ftp.cisco.com/pub/mibs/v1/BRIDGE-MIB.my
           => `BRIDGE-MIB.my'
Resolving ftp.cisco.com... 72.163.7.54
Connecting to ftp.cisco.com|72.163.7.54|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD (1) /pub/mibs/v1 ... done.
==> SIZE BRIDGE-MIB.my ... 47013
==> PASV ... done.    ==> RETR BRIDGE-MIB.my ... done.

    [   <=>                                    ] 47,013      59.6K/s   in 0.8s  

2011-09-06 19:29:02 (59.6 KB/s) - `BRIDGE-MIB.my' saved [47013]

user@NMS:~$ mkdir .snmp .snmp/mibs
user@NMS:~$ echo "BRIDGE-MIB BRIDGE-MIB.my" > .snmp/mibs/.index
user@NMS:~$ mv BRIDGE-MIB.my .snmp/mibs/

A CAM tábla információi nem állnak közvetlenül, egységesen SNMP táblázat formájában a rendelkezésünkre, az információkat az SNMP fa külön ágaiból, táblázataiból kell összeszedegetni, nagyobb részük persze a BRIDGE-MIB-en belüli adat, de a végső választ például a "Melyik switchporton keresztül érhető el az AA-AA-AA-AA-00-04 MAC című host?" kérdésre az IF-MIB-ből (ifName) nyerjük majd ki.

Az első lépés a dot1dTpFdbTable (.1.3.6.1.2.1.17.4.3) táblázat   dot1dTpFdbAddress (.1.3.6.1.2.1.17.4.3.1.1) mezőjének snmpwalkkal való bejárása. A parancs kimeneteként megkapjuk azokat a MAC címeket, amelyekről a switch forwarding adatbázisa (Fdb) információt tartalmaz, ezt a kimenetet nagyobb hálózatok esetén célszerű leszűrni a keresett MAC címre egy grep-pel:

user@NMS:~$ snmpwalk -m +BRIDGE-MIB -v1 -cpublic -On -Cc 10.10.10.1 \
dot1dTpFdbAddress | grep "AA AA AA AA 00 04"

.1.3.6.1.2.1.17.4.3.1.1.170.170.170.170.0.4 = Hex-STRING: AA AA AA AA 00 04 

Apróságok az snmpwalk kapcsolói közt: a -m segítségével beolvassuk a BRIDGE-MIB-et is, így használható a dot1dTpFdbAddress név az OID helyett, a -Cc pedig biztos, ami biztos alapon került a parancsba, a tapasztalataim alapján ugyanis nem minden SNMP agent kezeli rendesen ezt a táblázatot, van hogy az OID-k nem szigorúan monoton növekvő rendben követik egymást a fában, ami zavarba hozhatja az snmpwalk-ot, a -Cc kapcsolóval viszont az ilyen rendetlen fákban is eligazodik a program. A parancs kimeneteként kapott OID-ből az .1.3.6.1.2.1.17.4.3.1.1 (dot1dTpFdbAddress) utáni részt (esetünkben a 170.170.170.170.0.4-et [figyelem: 170 = hex AA, akinek megy a hex->dec, az akár az első lépést át is ugorhatta volna :)]) másoljuk ki vágólapra, szükségünk lesz rá a következő parancs grep-es szűrésénél:

user@NMS:~$ snmpwalk -m +BRIDGE-MIB -v1 -cpublic -On -Cc 10.10.10.1 \
dot1dTpFdbPort | grep "170.170.170.170.0.4"

.1.3.6.1.2.1.17.4.3.1.2.170.170.170.170.0.4 = INTEGER: 138

A fenti parancs szintén dot1dTpFdbTable (.1.3.6.1.2.1.17.4.3) táblázatban turkál, ezúttal a dot1dTpFdbPort (.1.3.6.1.2.1.17.4.3.1.2) mezőben. A grep segítségével a táblázat ezen oszlopából kiválasztjuk az első parancsban már megtalált sort. Vagyis a parancs az AA-AA-AA-AA-00-04 MAC címet betanuló port számát adja vissza. Sajnos ez a szám még nem olyan szám, amit a felhasználó közvetlenül értelmezhet, a legtöbb implementációban csupán egy közbülső azonosító. Kivétel persze mindig akad, a nálam járt Nortel 5500-as switcheken például a dot1dTpFdbPort már a valódi portszámot tartalmazta, de kivétel ide vagy oda, ezt a számot a legtöbb esetben valahogy át kell váltanunk emberi fogyasztásra alkalmas adatra. A következő parancsot már e nagy cél elérésének reményében adhatjuk ki, a dot1dBasePortIfIndex (.1.3.6.1.2.1.17.1.4.1.2) egy másik táblázatnak, a dot1dBasePortTable-nek (.1.3.6.1.2.1.17.1.4) a mezője. Ez a táblázat (szintén a BRIDGE-MIB része) felsorolja az összes olyan portot az SNMP agentet futtató eszközön, amely részt vesz a kapcsolási folyamatban. Ezek közül kell kiválasztanunk a példánkban az előző parancs kimenete alapján a 138-as azonosítójú sort a greppel. A második parancs a dot1dBasePortIfIndex oszlopból kinyert ifIndex számot fordítja stringre:

user@NMS:~$ snmpwalk -m +BRIDGE-MIB -v1 -cpublic -On -Cc 10.10.10.1 \
dot1dBasePortIfIndex  | grep ".138"

.1.3.6.1.2.1.17.1.4.1.2.138 = INTEGER: 146800833

user@NMS:~$ snmpwalk -v 1 -c eqnetwork -On -Cc 10.10.10.1 \
ifName | grep "146800833"

.1.3.6.1.2.1.31.1.1.1.1.146800833 = STRING: GigabitEthernet3/0/22

A végeredmény tehát: az AA AA AA AA 00 04 MAC című eszköz az adott switch GE3/0/22-es portján keresztül érhető el. Ez nem feltétlenül jelenti azt, hogy az AA AA AA AA 04 eszköz közvetlenül a GE3/0/22-es porton lóg, lehetséges, hogy az adott porton csak egy újabb switch csatlakozik, amelyből természetesen hasonló módon kinyerhetők a CAM információk. A módszer nem igényel CLI bejelentkezést a switchekre, viszonylag jól szkriptelhető, elvileg sok-sok munkával egész érdekes adatbázis építhető belőle, ha periodikusan mentjük minden switchünkről a CAM adatokat, így ugyanis nyomon követhetjük a hostjaink mozgását a hálózaton belül.

A bemutatott módszer jól működik a legtöbb gyártó esetében, 3Com és Nortel eszközökön biztosan, Cisco switchek esetén még egy csavar van a dologban: a Cisco-féle SNMP implementációban a BRIDGE-MIB adatai VLAN specifikusak, ha a bemutatott parancsokat adjuk ki, akkor csak a natív VLAN-ra vonatkozó adatokat kapjuk vissza. Magyarul míg egy Nortel switch esetén az "snmpwalk -v1 -cpublic -On -Cc 10.10.10.1 dot1dTpFdbAddress" az összes VLAN-on betanult MAC címet listázza, addig egy Cisco switchen ez alapesetben kizárólag a VLAN1-ben forgó MAC-eket adja vissza, ezért ezeken az eszközökön a VLAN ID alapján indexelt SNMP community stringes lekérdezéseket kell összeállítanunk. A részletes magyarázat a bekezdésben lévő linkeken elérhető, a végére már csak egy ilyen Cisco eszközös példa maradt:

user@NMS:~$ snmpwalk -v1 -cpublic@2 -Cc 10.10.10.7 \
.1.3.6.1.2.1.17.4.3.1.1 | grep "AA AA AA 00 12"
SNMPv2-SMI::mib-2.17.4.3.1.1.170.170.170.170.0.18 = Hex-STRING: AA AA AA AA 00 12
 
user@NMS:~$ snmpwalk -v1 -cpublic@2 -Cc 10.10.10.7 \
.1.3.6.1.2.1.17.4.3.1.2 | grep "170.170.170.0.18"
SNMPv2-SMI::mib-2.17.4.3.1.2.170.170.170.170.0.18 = INTEGER: 3
 
user@NMS~$ snmpwalk -v1 -cpublic@2 -Cc 10.10.10.7 \
.1.3.6.1.2.1.17.1.4.1.2 | grep ".3"
SNMPv2-SMI::mib-2.17.1.4.1.2.3 = INTEGER: 10003
 
user@NMS:~$ snmpwalk -v1 -cpublic -Cc 10.10.10.7 ifName | grep 10003
IF-MIB::ifName.10003 = STRING: Fa0/3

Ugyanez IOS-ben:

Switch#show mac-address-table dynamic vlan 2
          Mac Address Table
-------------------------------------------

Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
...
   2    aaaa.aaaa.0012    DYNAMIC     Fa0/3
...
Total Mac Addresses for this criterion: 24

Parancssori SNMP eszközök (1.)

Említettem korábban, hogy ismeretlen hálózatok feltérképezésekor nagy segítség egyebek mellett, ha az azt működtető eszközökön fut az SNMP. Az sem elképzelhetetlen szituáció, hogy a networkös számára semmilyen más lehetőség nem adódik, csak az SNMP, mert az eszköz, illetve az az ahhoz kapcsolódó szolgáltatás ki van szervezve, így nincs más interfész a real-time információszerzésre.

Az SNMP fában tárolt információk kiolvasására számos lehetőség adódik. Ha ismerjük a gyártót, illletve az eszköz típusát, akkor jó eséllyel megtalálhatjuk a gyártó weboldalán az adott típushoz ajánlott menedzsment szoftvert, vagy használhatunk gyártófüggetlen, általában minden SNMP implementációval működő programokat is, mint amilyen például az iReasoning MIB Browser. Az ilyen általános MIB browserekkel általában kevesebb információhoz juthatunk hozzá közvetlenül, mint amennyihez a gyártóspecifikus programokkal, illetve nem árt ismerni az SNMP fa felépítését, objektumtípusait, az objektumok közötti összefüggéseket, ha közvetlenül az SNMP fával dolgozunk. Végül, de nem utolsó sorban léteznek olyan általános parancssori eszközök is, amelyek még a MIB browsereknél is több figyelmet igényelnek, no ezekről szól most ez a poszt(sorozat).

A legtöbb Linux disztribúcióban, BSD-ben alapból megtalálhatók a net-snmp programcsomag parancssori SNMP eszközei, sőt ugyanezek elérhetőek egyéb platformokon például Windowson is. Ha tudjuk az SNMP agentet futtató eszköz IP címét (az alábbi példákban ez a 10.10.10.1), és a community stringet (a példákban "public"), akkor már próbálkozhatunk is az snmpget paranccsal.

Érdemes elsőre valami olyan OID-t lekérdezni, amit minden SNMP agentnek támogatnia kell, ilyen például a .1.3.6.1.2.1.1.1.0, ez az SNMP agentet futtató hardver és szoftver teljes szöveges leírását kell, hogy tartalmazza az RFC1213 szerint:

user@NMS:~$ snmpget -v 1  -c public 10.10.10.1 .1.3.6.1.2.1.1.1.0
SNMPv2-MIB::sysDescr.0 = STRING: Cisco Internetwork Operating System Software
IOS (tm) 3700 Software (C3725-IK9S-M), Version 12.3(6b), RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2004 by cisco Systems, Inc.
Compiled Wed 19-May-04 17:31 by dchih

Ugyanezt az eredményt elérhetjük úgy is, ha az azonosító helyett névvel hivatkozunk az objektumra (.iso.org.dod.internet.mgmt.mib-2.system.sysDescr.0), illetve használható a rövid név is (sysDescr.0):

user@NMS:~$ snmpget -v 1  -c public 10.10.10.1 sysDescr.0
SNMPv2-MIB::sysDescr.0 = STRING: Cisco Internetwork Operating System Software
IOS (tm) 3700 Software (C3725-IK9S-M), Version 12.3(6b), RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2004 by cisco Systems, Inc.
Compiled Wed 19-May-04 17:31 by dchih

Nem mindenhol mernek azonban megmaradni a cleartext-et használó SNMP v1-nél. Biztonság terén nincs lényeges eltérés az SNMP v2-ben sem, a v3 azonban mind az authentikációban, mind a forgalom titkosításában előrelépést jelenthet a korábbi változatokhoz képest. A fenti példa egy SNMP v3-as, authNoPriv biztonsági szinten, MD5 hash algoritmust használó agent esetében (ekkor az authentikáció során csak az MD5 hash utazik a hálózaton, a tényleges jelszavak nem, viszont az adatforgalom továbbra is titkosítatlan) így módosul:

user@NMS:~$ snmpget -v3 -l authNoPriv -a MD5 -u nev -A jelszo 10.10.10.2 sysDescr.0
SNMPv2-MIB::sysDescr.0 = STRING: Cisco IOS Software, C1200 Software (C1200-K9W7-M), Version 12.3(8)JED, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2009 by Cisco Systems, Inc.
Compiled Fri 18-Sep-09 10:32 by tinhuang

Az snmpget minden erénye ellenére ritkábban használt program, hiszen csak egyetlen OID adatait tudja lekérdezni egyszerre, így aztán inkább csak a net-snmp-re épülő szkriptekben szokták használni. Célravezetőbb lehet az snmpwalk használata, ez a program az SNMP fában bejárja a megadott OID alatti részt, és kilistáz minden ott szereplő értéket. Az snmpget ezzel szemben csupán az SNMP fa leveleit tudja megjeleníteni. A példákat folytatva megnézhetjük mondjuk, hogy mi van még a .iso.org.dod.internet.mgmt.mib-2.system alatt a sysDescr érkékén kívül, és tehetjük mindezt úgy, hogy fogalmunk sincs a system alatti többi objektumról:

user@NMS:~$ snmpwalk -v 3 -l authNoPriv -a MD5 -u nev -A jelszo 10.10.10.2 system 
SNMPv2-MIB::sysDescr.0 = STRING: Cisco IOS Software, C1200 Software (C1200-K9W7-M), Version 12.3(8)JED, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2009 by Cisco Systems, Inc.
Compiled Fri 18-Sep-09 10:32 by tinhuang
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.9.1.525
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (555997901) 64 days, 8:26:19.01
SNMPv2-MIB::sysContact.0 = STRING:
SNMPv2-MIB::sysName.0 = STRING: AP_SZ_O_Finance.corp.elcoteq.com
SNMPv2-MIB::sysLocation.0 = STRING:
SNMPv2-MIB::sysServices.0 = INTEGER: 2

user@NMS:~$ snmpwalk -v 1 -c public 10.10.10.3 system
SNMPv2-MIB::sysDescr.0 = STRING: 3Com Switch 5500G-EI 24-Port Software Version 3Com OS V3.03.02s168p07
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.43.1.16.4.3.7
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (555844367) 64 days, 8:00:43.67
SNMPv2-MIB::sysContact.0 = STRING: KR, PP
SNMPv2-MIB::sysName.0 = STRING: SZSW-202R0
SNMPv2-MIB::sysLocation.0 = STRING: OB, R0
SNMPv2-MIB::sysServices.0 = INTEGER: 78

Egyből két mintát is megvizsgálhatunk, ráadásul két különböző gyártótól. Az első ránézésre látszik, hogy a system ág szerkezete teljesen azonos mindkét eszköznél, ugyanazok az objektumok szerepelnek benne: sysDescr, sysObjectID, sysUpTimeInstance, sysContact, sysName, sysLocation és sysServices. Ezek közül kilóg a sorból a sysUpTimeInstance, pedig mindössze annyi a különbség, hogy az snmpwalk ennek az objektumnak a definícióját a DISMAN-EVENT-MIB-ből veszi, míg a többi objektum az SNMPv2-MIB-ben van definiálva. A legtöbb SNMP kliensben egyébként külön funkció van a sztenderd MIB-eken kívüli, gyártó- és/vagy termékspecifikus MIB-ek importálására. A MIB-ek definiálják ASN.1 nyelven az SNMP fa minden egyes elemét, a MIB-ből olvashatók ki a szimbolikus nevek (pl. .iso.org.dod.internet.mgmt.mib-2.system.sysDescr) és a hozzájuk tartozó OID, itt definiálják minden egyes OID-hez, hogy milyen típusú adatot tartalmazhat, illetve hogy írható-olvasható vagy csak olvasható az adott objektum.

A sysDescr  objektumot már ismerjük, a sysObjectID egy gyártóspecifikus azonosítót tartalmaz, amellyel egyértelmű módon lehet hivatkozni az SNMP agentet futtató eszköz típusára, mellesleg az itt feltüntetett OID létezik is az SNMP fában. A sysUpTimeInstance az SNMP agent indítása óta eltelt időt mutatja, ez az esetek túlnyomó részében az eszköz indítása óta eltelt idővel egyezik meg, azt azonban nem árt tudnunk, hogy a network OS is ugyanolyan OS mint a többi, tehát egy processzt általában le lehet állítani rajtuk, vagy éppen újra lehet azt indítani. A sysContact, a sysName és a sysLocation a rendszer üzemeltetésére vonatkozó információkat ad: hová, kihez lehet a rendszerrel kapcsolatban fordulni, mi az SNMP agentet futtató eszköz hostneve és hol található fizikailag. Ezek az értékek nincsenek feltétlenül kitöltve, vagy nem biztos, hogy értelmes, ami ide van írva, minden a rendszer üzemeltetőjétől függ.

A sysServices mező értelmezése egy kicsit több időt igényel, ez egy integer érték, de mindenképp érdemes átváltanunk decimálisról binárisra, hogy értelmezhessük. Az itt szereplő szám bináris reprezentációja megmutatja, hogy mely ISO OSI rétegekben kínál szolgáltatásokat az SNMP agentet futtató eszköz. A legkisebb helyiértéken a Layer 1-es szolgáltatások vannak, a második helyiérték a Layer2, stb. Egytől hétig, csak éppen visszafelé. Így például, egy managelhető hubon, ami támogatja az SNMP-t, a sysServices elvileg 1 kell, hogy legyen. A Cisco AP azt mondta magáról, hogy sysServices = 2, ami binárisan ugye 0000 0010, tehát ő egy Layer 2-es eszköz volna tulajdonképpen, és valóban, tényleg az. A 3Com 5500G-EI viszont nagy büszkén bejelentette, hogy 78 (bin 0100 1110), eszerint ez az eszköz switch (Layer2, 2^1=2), ami routeol is ha kell (Layer3, 2^2=4), illetve vannak Layer 4-es (2^3=8) funkciói (pl. tud tűzfalazni TCP portszám alapján), arról viszont fogalmam sincs, hogy milyen érdemi funkcióra gondolhattak a 3Com fejlesztői, hogy 1-est tettek a Layer7-es bitre is (2^6=64), gyanítom hogy ez már az ő titkuk marad, az érték viszont 2+4+8+64=78. De hogy nem csak a 3Comnál van gond az értelmezéssel, arra kiváló példa az egyik nálunk futó Nortel 8600-as, ami egy elég komoly moduláris switch, rengeteg funkcióval, a "78"-as 3Com 5500G, ami kellemes ugyan, ám egy kategóriával lejjebb, a stackelhető switchek közt szerepel, a kanyarban sincs hozzá képest, szóval ez a Nortel 8600-as szerényen csak 6-ost mond a sysServicesben (bin 0000 0110), mintha valami akármilyen Layer2-es & Layer 3-as eszköz lenne. Szóval ebben a mezőben, bármi is van beleírva, nem feltétlenül kell vakon megbíznunk. (Folytatása következik.)

Aggregált link Cisco és Nortel eszközök közt

A mai posztnak kis híján az lett a címe, hogy "LACP Cisco és Nortel eszközök közt", ám menet közben kiderült, hogy a tesztelt Nortel 5510-24T eszközön futó réges-régi NNCLI verzió (4.2.0.11) nem támogatja az LACP protokollt. Mivel Nortel eszközről van szó, és ez az LACP dolog alapvetően csak tesztjelleggel kellett volna, így esélyem sem volt újabb szoftververziót letölteni, ahogy arról már egy korábbi posztban is szó volt. A cél azonban a korábbiakhoz hasonlóan ugyanaz: több VLAN-t átvinni két linkből álló aggregált linken különböző gyártóktól származó eszközök közt. Ismét ugyanazt a Cisco 2960-ast vettem elő ma is mint korábban, a másik oldal pedig a már említett Nortel 5510-es volt. A kiindulópont szintén a szokásos, az eszközök majdnem gyári alapkonfigurációról indulnak (csupán VLAN1-ben kerül rájuk egy menedzsment IP, illetve egy VLAN 2 definíció).

Mivel most nincs LACP-nk, az IOS oldali konfiguráció egy hangyányit különbözik az előzőektől (pirossal), az EtherChannel-hez nem engedélyeztem az LACP-t, így az aggregációhoz nincs kontroll protokollunk, nem fogjuk ismerni az LACP partner ID-t, nem lesznek LACP statisztikák, csak egy sima, "kézzel", statikusan összefogott EtherChannelünk:

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 on
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 Nortel/Avaya vonalon az aggregált linkek neve MLT (Multi-Link Trunking), az aggregált linkkel kapcsolatos beállítások mindegyike valamilyen mlt parancs lesz. A tesztben a Nortel 23-as és 24-es portját kötöttem össze a Cisco switch 47-es és 48-as portjával:

BS5510-24T#configure terminal
BS5510-24T(config)#vlan create 2 type port
BS5510-24T(config)#vlan ports 23,24 pvid 1
BS5510-24T(config)#vlan ports 23,24 tagging untagPvidOnly
BS5510-24T(config)#vlan members add 2 23,24
BS5510-24T(config)#mlt 1 member 23,24
BS5510-24T(config)#mlt 1 enable
BS5510-24T(config)#exit

Ebben a pár sornyi parancsban benne van a VLAN2 definíciója, a 23-as és 24-es portok natív VLAN-jának beállítása (PVID), ugyanezen portokon a 802.1q taggelés módjának beállítása a Cisco switchhez (natív VLAN untagged, a többi tagged), a VLAN2 port membership kezelése, majd végül az MLT 1 nevű aggregált kapcsolat létrehozása. A diagnosztikai lehetőségeknek némileg híján van az NNCLI, csupán a show mlt paranccsal vizsgálódhatunk probléma esetén:

BS5510-24T#show mlt utilization 1

Trunk   Traffic Type   Port   Last 5 Minutes  Last 30 Minutes   Last Hour
-----   ------------   ----   --------------  ---------------   ---------
  1     Rx and Tx        23     < 0.1%          < 0.1%            < 0.1%
  1     Rx               23     < 0.1%          < 0.1%            < 0.1%
  1     Tx               23       0.0%             0.0%             < 0.1%
  1     Rx and Tx        24     < 0.1%          < 0.1%            < 0.1%
  1     Rx               24     < 0.1%          < 0.1%            < 0.1%
  1     Tx               24       0.0%             0.0%             0.0%

BS5510-24T#show mlt              
Trunk Name                 Members             STP Learning Mode  Status
----- -------------------- ------------------- ------------ ----- --------
1     Trunk #1             23-24               Normal       Basic Enabled
2     Trunk #2             NONE                Normal       Basic Disabled
3     Trunk #3             NONE                Normal       Basic Disabled
4     Trunk #4             NONE                Normal       Basic Disabled
5     Trunk #5             NONE                Normal       Basic Disabled
6     Trunk #6             NONE                Normal       Basic Disabled

Az összeköttetés persze LACP nélkül is működőképes, a VLAN1-ben és a VLAN2-ben lévő hostok az aggregált linken keresztül képesek voltak kommunikálni egymással, illetve az aggregált link bármelyik fizikai portját kihúzva a kommunikáció folyamatos maradt.

Némi Nortel/Avaya tapasztalat

No, az elmúlt pár hétben, már amikor nem nyaraltunk, volt alkalmam egy kicsit birizgálni a korábban már emlegetett Nortel holmikat. A legtöbb megörökölt eszköz Nortel 470-es, Nortel 5510-es és a Nortel 8600-as, persze vannak ezen kívül is típusok (egy-két 5530-as, ősrégi 450-esek, 3510-es, stb.), nagyjából igyekeztem korlátozott számú típusra leszűkíteni a palettát, mindenkinek egyszerűbb lesz így a későbbiek folyamán is. Szóval hosszabb távon szükség lesz a 470-esekre (szigorúan access switchként), az 5510/5530-asok sok mindenre jó stackelhető switchek, kisebb telephelyeken a LAN routeolást is rájuk lehet bízni, és mivel gigabitesek, még akár szerverekhez is jók, a 8600-as moduláris switchek meg egyértelműen core eszközök.

Nagy vonalakban az eddigi tapasztalataimról: A 470-es és 5500-as eszközök nagyjából azonos dolgokat tudnak firmware szinten, az egyetlen lényeges különbség, hogy van routeolás az 5500-asokon. A 470-eseinken az NNCLI (Nortel Networks Command Line Interface) 3-as verziói futnak, az 5510-eseinken meg mindenféle verziók, főleg  4-es és 5-ös NNCLI. Ha Cisco vonalon kellene megfelelő termékeket megneveznem, akkor a 470-esek nagyjából a 2900-as switcheknek felelnének meg, míg az 5500-asok a Cisco 3000-es sorozatban lennének valahol. Nagy hátránynak tartom, hogy a Nortel 8600-as teljesen külön állatfajta, tök más CLI-vel, szóval a Nortel/Avaya switching termékpaletta OS szinten nem egységes, ahogy mondjuk a Cisco-nál is volt (van) CatOS a nagyobb switcheken.

A Nortel 8600-asok története egyben megmagyarázza a különbségeket: az elődnek számító Accelar 1000 típust 1996-ban dobta piacra a Rapid City Communications, ezt a céget felvásárolta 1997-ben a Bay Networks, majd a Bay Networks 1998-ban beolvadt a Nortelbe, ahol volt nagyjából tíz évnyi fejlődési lehetősége a terméknek, amit időközben átneveztek Passport 8600-ra, majd ERS (Ethernet Routing Switch) 8600-ra, és jelenleg Avaya márkanév alatt kapható. Egyébként a posztban leírt tapasztalatok nem erre a típusra vonatkoznak, hanem a 470-esekre és az 5500-asokra.

VIsszatérve a konkrét tapasztalatokra: nem túl előnyös, hogy a firmware frissítéseket a Nortel 2006 óta csak előfizetéses konstrukcióban kínálta, nem lehet csak úgy letölteni egy akármilyen régebbi eszközhöz az új szoftvereket, még akkor sem, ha egyébként a termék még nem futott ki, és ezt a szoftverpolitikát sajnos az Avaya is továbbvitte. Persze mi most nem fogunk semmilyen szerződést kötni az Avayával, épp az ennek az egész dolognak a lényege, hogy a semmiből, meglévő, elfeledett, félretett eszközökből kell összehozni valamit.

Ha már a firmware-ekről van szó: ilyet eddig más gyártóknál még nem láttam, nem lehet az eszközön futó rendszert lementeni. Úgy értem, hogy nincs rá parancs sem, arra van csupán lehetőség, hogy frissítsük a firmware-t, de magáról az eszközön aktuálisan futó firmware-ről nem lehet másolatot készíteni, nem ad semmilyen hozzáférési lehetőséget az OS.

Érdekes koncepciót követett a Nortel a konfigurációs változások mentésének kérdésében is, a rendszer 60 másodpercenként ellenőrzi, hogy történt-e változás a konfigurációban, amennyiben igen, akkor azt elmenti az NVRAM-ba is. Ezért aztán olyan tanács olvasható a System Configuration Guide-ban, hogy a változtatások után ne indítsuk újra az eszközt azonnal, várjunk egy percet, különben elveszhetnek a módosításaink. Persze ki lehet kapcsolni ezt az autosave funkciót, illetve a copy config nvram paranccsal mi magunk is menthetjük a beállításokat.

Az már inkább fájdalmas, hogy a konfigurációt binárisan kezeli a rendszer, azaz az iparágban széles körben használt szöveges konfigurációs fájlok hagyománya ehhez a gyártóhoz nem ért el (vannak egyéb furcsaságok is). Persze el lehet menteni így is a konfigurációt TFTP-n keresztül, de valahogy az ember olyan kényelmetlenül érzi magát, hogy megvan ugyan a beállítás, de bináris a fájl, nem sok értelme van belenézni. Létezik "ASCII configuration file" lehetőség is, ilyenkor a bináris fájlt átkonvertálja a rendszer NNCLI parancsokra, ennek viszont az a hátulütője, hogy a dokumentációk szerint az ASCII konfigurációs fájlt csakis gyári alapbeállításokkal rendelkező eszközre javasolják feltölteni, ami mondjuk nem tesz túl jót a távmenedzsmentnek.

De hogy ne csak a negatívumokat soroljam, a rendszer adminisztrálására több lehetőségünk van, mint a legtöbb rivális terméknél, ugyanis a hagyományos CLI-n, HTTP(S) és SNMP felületen kívül a konzolban (soros porton, Telneten, SSH-n) elérhető egy szöveges felületű, szerintem nagyon kezes menürendszer, amiben a legfontosabb dolgokat be lehet állítani a VLAN-októl kezdve a trönkölésen át a per VLAN STP-n, Radiuson, port alapbeállításon, port mirroringon, SNMP-n keresztül a stack kezelésig. Ritkán mondok ilyet, de a legtöbb egyszerűbb feladathoz jobb, mint a sima CLI, miközben nem igényel többet annál (ugyanazokon az interfészeken, protokollokon keresztül érhető el, mint a CLI). Persze mondjuk egy DHCP relay agent beröffentése az 5500-asokon már parancssort kíván, nem mintha olyan bonyolult lenne, csak egyszerűen nem fér bele minden a menürendszerbe.

Nortel bemelegítés

Mostanában barátkozgatunk, én meg a kikukázott Nortelek. Azért nem egy felhőtlen kapcsolat ez, már az elején sem volt minden rendben. Életem első Nortel eszköze egy viszonylag friss, jelenleg ugye már Avaya márkanév alatt futó Nortel 5510-24T volt kb. két hete, előtte soha semmilyen Nortel kütyüt nem piszkáltam, leszámítva egy Nortel 1010-es VPN routert, ami ugyan nem a cégé volt, de zörgött a ventillátora, ezért belenéztem, és kiderült, hogy egy Celeron 300-as van benne (persze, hogy mások is észrevették már ezt: van, aki Slackware-t futtat rajta). De vissza a tárgyhoz, szóval az első Nortel switchem marhára nem akart konzolon életjelet adni, próbálgathattam én sebességet állítgatni vagy bármi mást, nem sok visszajelzést adott. Persze ilyenkor elkezd guglizni az ember, de mindenütt csak annyit írtak, hogy 9600/8/N/1, szóval mennie kellett volna. A kábelemben is biztos voltam, de azért kipróbáltam egy Cisco AP-n, az természetesen azonnal működött a Minicomban. Az 5510-es sem úgy nézett ki, mint amit ütöttek-vertek volna mindenféle kiégett adminok, szóval gyanús volt, hogy valami disznóság van a konzolkábel körül, lehetséges, hogy annyira különc a Nortel, hogy más lábkiosztást használjon?

Van a fiókomban egy-két apróság, épp az ilyen estekre, többek közt olyan RJ45-DB9 átalakító is, ami nem megy a "rendes" eszközökkel, na majd most bizonyíthat, gondoltam. Így is lett, ez az Avocent Cyclades out-of-band konzol appliance-hez való RJ45-DB9 átalakító mindent megoldott a Nortel 5510-zel kapcsolatban, és még csak forrasztani sem kellett.

A Cisco, HP, 3Com, Huawei, Fortigate stb. eszközökhöz való DB9 átalakító így néz ki (3-4. oszlop, további részletek a cisco.com-on):

Console Port (DTE)	RJ-45-to-RJ-45 Rollover Cable		RJ-45-to-DB-9 Terminal Adapter	Console Device
Signal	RJ-45 Pin	RJ-45 Pin	DB-9 Pin	Signal
RTS	1	8	8	CTS
DTR	2	7	6	DSR
TxD	3	6	2	RxD
GND	4	5	5	GND
GND	5	4	5	GND
RxD	6	3	3	TxD
DSR	7	2	4	DTR
CTS	8	1	7	RTS

A működő RJ45-DB9 átalakító (Cyclades) lábkiosztásáról némi multiméteres bohóckodás után következőt derítettem ki:

RJ-45 PIN	DB-9 female
8	4
7	4
6	3
5	7
4	5
3	2
2	1, 6
1	8

Igazából csak az RJ45 3, 4, 6-os (DB9 2, 5, 3) lábakra van szükség, és ha összevetjük a legfelső táblázattal, akkor láthatjuk, hogy a Cisco eszközökön is ugyanezek a lábak vannak használatban, csak épp a TXD helyett RXD, illetve RXD helyett TXD van rákötve, a Nortel Install Guide szerint ugyanis a Nortel eszközökön a konzol port kivezetések a következők szerint alakulnak:

PIN #	Signal
1	Not used
2	TXD
3	RXD
4	Not used
5	GND
6	Not used
7	Not used
8	Not used
9	Not used