A korábbiakban a Nortel, a 3Com (új HP) majd a HP (ProCurve, régi HP) layer2-es discovery protokolljainak alapvető használatát vizsgáltuk. A HP-s posztban a korábbi gyártóspecifikus protokollok után előkerült az LLDP, az egyéb hasonló protokollokat felváltó nemzetközi szabvány. A mai poszt egy többgyártós rém egyszerű kis teszthálózatban mutatja meg az LLDP fontosabb képességeit Cisco oldalról. Nem fogunk túlságosan belemászni az LLDP konfigurációjába, így az olyan lehetőségeket, mint hogy a szomszédokról begyűjtött információt mennyi ideig tárolja a hostunk (LLDP holdtime), vagy éppen azt, hogy milyen időközönként szórjuk meg a szomszédos eszközöket LLDP PDU-kkal (LLDP update frequency), vagy hogy egyáltalán milyen TLV (Type-Lenght-Value) rekordokkal foglalkozzon az LLDP-s eszközünk, most átugorjuk, az alapértelmezésekre hagyatkozunk, ami egyébként az esetek túlnyomó részében tökéletesen elegendő is.
Cisco eszközökön az LLDP nagyjából a CDP-hez hasonlóan kezelhető, sőt egyszerre mindkettő futhat, az más kérdés, hogy van-e ilyesminek értelme, evidens, hogy amennyiben lehetséges, nem érdemes keverni a kettőt, vegyes környezetben várhatóan az LLDP lesz a favorit, homogén Cisco környezetben pedig a CDP.
A LLDP-vel kapcsolatos fontosabb konfigurációs parancsok IOS-en: globális konfig módban a (no) lldp run ki- vagy bekapcsolja az LLDP-t, illetve interfész konfigurációs módban hasznos lehet a no lldp transmit, továbbá a no lldp receive, ezekkel interfészenként tilthatjuk az LLDP küldést és fogadást, amit mindig érdemes legalább a hálózatunk külső csatlakozási pontjain megtenni. Az LLDP-s információs parancsokat az alábbi példák mutatják be:
CiscoSW#show lldp
Global LLDP Information:
Status: ACTIVE
LLDP advertisements are sent every 30 seconds
LLDP hold time advertised is 120 seconds
LLDP interface reinitialisation delay is 2 seconds
CiscoSW#show lldp neighbors
Capability codes:
(R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
(W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
Device ID Local Intf Hold-time Capability Port ID
3Com-SW Fa0/1 120 B,R Ethernet5/0/14
HP-SW Gi0/1 120 B 24
Vyatta1 Fa0/48 120 R 001e.3734.d09c
Total entries displayed: 3
CiscoSW#show lldp neighbors detail
------------------------------------------------
Chassis id: 001a.c156.1040
Port id: Ethernet5/0/14
Port Description: Ethernet5/0/14
System Name: 3Com-SW
System Description:
Switch 5500-EI
Time remaining: 91 seconds
System Capabilities: B,R
Enabled Capabilities: B,R
Management Addresses - not advertised
Auto Negotiation - supported, enabled
Physical media capabilities:
1000baseX(FD)
1000baseX(HD)
Symm Pause(FD)
Asym Pause(FD)
100base-T4
10base-T(FD)
10base-T(HD)
Other/unknown
Media Attachment Unit type: 16
Vlan ID: 1
------------------------------------------------
Chassis id: 0016.b90b.e8a0
Port id: 24
Port Description: 24
System Name: HP-SW
System Description:
ProCurve J4903A Switch 2824, revision I.10.77, ROM I.08.07 (/sw/code/build/mako(mkfs))
Time remaining: 115 seconds
System Capabilities: B,R
Enabled Capabilities: B
Management Addresses:
IP: 172.17.136.247
Auto Negotiation - not supported
Physical media capabilities - not advertised
Media Attachment Unit type - not advertised
Vlan ID: - not advertised
------------------------------------------------
Chassis id: 001e.3734.d09c
Port id: 001e.3734.d09c
Port Description: eth0
System Name: Vyatta1
System Description:
Vyatta Router running on Vyatta Core 6.3 2011.07.21
Time remaining: 111 seconds
System Capabilities: B,W,R
Enabled Capabilities: R
Management Addresses:
IP: 172.17.136.253
Auto Negotiation - supported, enabled
Physical media capabilities:
1000baseT(FD)
100base-TX(FD)
100base-TX(HD)
10base-T(FD)
10base-T(HD)
Media Attachment Unit type: 16
Vlan ID: - not advertised
MED Information:
MED Codes:
(NP) Network Policy, (LI) Location Identification
(PS) Power Source Entity, (PD) Power Device
(IN) Inventory
H/W revision: ThinkCentre M57
F/W revision: 2RKT41AUS
S/W revision: 2.6.37-1-586-vyatta
Serial number: LMBKVN2
Manufacturer: LENOVO
Model: 6089W25
Asset id:
Capabilities: LI, IN
Device type: Network connectivity
Network Policies - not advertised
Power requirements - not advertised
Location - not advertised
Total entries displayed: 3
Látható, hogy a Cisco eszközünknek három LLDP-s szomszédja van, egy 3Com 5500-EI, egy HP 2824, valamint egy Lenovo ThinkCentre M57 PC, amin Vyatta 6.3 fut. A figyelmesebbeknek az is feltűnhet, hogy mindegyik LLDP implementáció másféle TLV készlettel dolgozik, így nincsenek, nem is lehetnek egységesen kitöltve a megjelenő mezők a részletes nézetben.
2011-12-10
2011-11-29
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:
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:
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.
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 InformationLocalPort | 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 DetailLocal 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.
2011-11-21
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ó.
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ó.
2011-11-17
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:
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.
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
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.
2011-11-16
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
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
2011-11-15
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:
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:
É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:
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. :)
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. :)
2011-11-11
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.
<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.
2011-10-31
Parancssori SNMP eszközök (4.) - snmpset
Az első, második és harmadik részben hol keveset, hol sokat, de mindig csak olvastuk az adatokat az SNMP fából, pedig ez olyan, mint a karácsonyfa, nem csak szedegetni lehet róla a dolgokat, de ráaggatni is. Természetesen van parancssori eszköz erre is, snmpset a program neve, és éppúgy a Net-SNMP csomag része, mint az snmpget, az snmpwalk, snmptable.
Az snmpset néhány paraméterrel többet igényel mint az egyéb eszközök. Az első és talán a legfontosabb különbség, hogy olyan community stringet kell megadnunk neki, amellyel írni is lehet a fába. Tipikusan az alapértelmezett RO string a "public" szokott lenni, az alapértelmezett RW string pedig a "private". Ökölszabály, hogy soha nem használjuk az RW stringet (főleg SNMPv1 és SNMPv2 esetén), csak akkor, amikor tényleg írunk is a fába -- de erre még később visszatérünk. Persze önmagában a community string nem elég, pontosan meg kell adnunk, hogy hol, illetve azt is, hogy milyen típusú adatot szeretnénk tárolni. A következő példában egy Nortel 5510-esen a system ágat kilistázzuk, majd átírjuk az egyik levelét és újra kilistázzuk:
admin@NMS:~$ snmpwalk -v1 -cpublic 10.10.10.1 system
SNMPv2-MIB::sysDescr.0 = STRING: Ethernet Routing Switch 5510-24T HW:32 FW:4.2.0.12 SW:v4.2.0.002
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.45.3.52.1
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (1132653378) 131 days, 2:15:33.78
SNMPv2-MIB::sysContact.0 = STRING: Telecom Team
SNMPv2-MIB::sysName.0 = STRING: TESTSW-01
SNMPv2-MIB::sysLocation.0 = STRING: Testlab
SNMPv2-MIB::sysServices.0 = INTEGER: 3
admin@NMS:~$ snmpset -v1 -cprivate 10.10.10.1 SNMPv2-MIB::sysContact.0 s NINCS
SNMPv2-MIB::sysContact.0 = STRING: NINCS
admin@NMS:~$ snmpwalk -v1 -cpublic 10.10.10.1 system
SNMPv2-MIB::sysDescr.0 = STRING: Ethernet Routing Switch 5510-24T HW:32 FW:4.2.0.12 SW:v4.2.0.002
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.45.3.52.1
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (1132667603) 131 days, 2:17:56.03
SNMPv2-MIB::sysContact.0 = STRING: NINCS
SNMPv2-MIB::sysName.0 = STRING: TESTSW-01
SNMPv2-MIB::sysLocation.0 = STRING: Testlab
SNMPv2-MIB::sysServices.0 = INTEGER: 3
Az snmpset paraméterei a példa alapján nagyjából egyértelműek lehetnek, az egyetlen kérdéses elem az az adattípus megadása, ez közvetlenül az érték előtt szerepel a parancssori paramétereinkben, ami esetünkben egy "s", azaz string érték volt. Értelemszerűen egy adott OID-be csak a MIB-ben definiált típusú adatot tudunk beírni. Az egyéb lehetséges típusok felsorolása az snmpset --help outputjának a végéről:
TYPE: one of i, u, t, a, o, s, x, d, b
i: INTEGER, u: unsigned INTEGER, t: TIMETICKS, a: IPADDRESS
o: OBJID, s: STRING, x: HEX STRING, d: DECIMAL STRING, b: BITS
U: unsigned int64, I: signed int64, F: float, D: double
Nem csak a típuson csúszhat meg az írás. Vannak ugyanis a fában igen terbélyes ágak, ahová egyáltalán nem írhatunk be semmit, még RW community stringgel sem, ezen OID-k esetén a MIB-ben a MAX-ACCESS tulajdonság "read-only" értékű, így a felülírásuk nem lehetséges, például nem tudjuk átírni egyebek mellett az interfészek neveit sem, pedig a string mint adattípus stimmelne:
admin@NMS:~$ snmpwalk -v1 -cpublic 10.10.10.1 IfName
IF-MIB::ifName.1 = STRING: ifc1 (Slot: 1 Port: 1)
IF-MIB::ifName.2 = STRING: ifc2 (Slot: 1 Port: 2)
IF-MIB::ifName.3 = STRING: ifc3 (Slot: 1 Port: 3)
IF-MIB::ifName.4 = STRING: ifc4 (Slot: 1 Port: 4)
IF-MIB::ifName.5 = STRING: ifc5 (Slot: 1 Port: 5)
IF-MIB::ifName.6 = STRING: ifc6 (Slot: 1 Port: 6)
IF-MIB::ifName.7 = STRING: ifc7 (Slot: 1 Port: 7)
IF-MIB::ifName.8 = STRING: ifc8 (Slot: 1 Port: 8)
IF-MIB::ifName.9 = STRING: ifc9 (Slot: 1 Port: 9)
IF-MIB::ifName.10 = STRING: ifc10 (Slot: 1 Port: 10)
IF-MIB::ifName.11 = STRING: ifc11 (Slot: 1 Port: 11)
IF-MIB::ifName.12 = STRING: ifc12 (Slot: 1 Port: 12)
IF-MIB::ifName.13 = STRING: ifc13 (Slot: 1 Port: 13)
IF-MIB::ifName.14 = STRING: ifc14 (Slot: 1 Port: 14)
IF-MIB::ifName.15 = STRING: ifc15 (Slot: 1 Port: 15)
IF-MIB::ifName.16 = STRING: ifc16 (Slot: 1 Port: 16)
IF-MIB::ifName.17 = STRING: ifc17 (Slot: 1 Port: 17)
IF-MIB::ifName.18 = STRING: ifc18 (Slot: 1 Port: 18)
IF-MIB::ifName.19 = STRING: ifc19 (Slot: 1 Port: 19)
IF-MIB::ifName.20 = STRING: ifc20 (Slot: 1 Port: 20)
IF-MIB::ifName.21 = STRING: ifc21 (Slot: 1 Port: 21)
IF-MIB::ifName.22 = STRING: ifc22 (Slot: 1 Port: 22)
IF-MIB::ifName.23 = STRING: ifc23 (Slot: 1 Port: 23)
IF-MIB::ifName.24 = STRING: ifc24 (Slot: 1 Port: 24)
IF-MIB::ifName.10001 = STRING: ifc10001 VLAN #1
IF-MIB::ifName.10101 = STRING: ifc10101 VLAN #101
IF-MIB::ifName.10111 = STRING: ifc10111 VLAN #111
IF-MIB::ifName.10112 = STRING: ifc10112 VLAN #112
IF-MIB::ifName.11099 = STRING: ifc11099 VLAN #1099
admin@NMS:~$ snmpset -v1 -cprivate 10.10.10.1 IF-MIB::ifName.1 s IFACE1
Error in packet.
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: IF-MIB::ifName.1
Hiába van azonban korlátozva már MIB szinten az SNMP fába való írás, nem rohangászhatunk állandóan SNMP RW stringekkel a hálózaton, hiszen SNMP v3 alatt minden kódolatlanul jön és megy, ami a legtöbb környezetben kockázatokat hordoz. Hogy ez mennyire így van, megosztok egy konkrét példát, ami a jelenlegi H3C / HPN eszközök nagyjából két generációval ezelőtti felmenőit érinti. Konkrétan a 3Com 4000-es széria darabjairól van szó, pl. a 4050-es, 4060-as, 4070-es, 4400-as, 4900-as stb. eszközökről, amelyek kb. 2004-2006-ban számítottak frissnek a piacon. Ezeken az eszközökön alapértelmezetten létezik az "admin", a "manager" és a "monitor" nevű felhasználó, és ha emlékeim nem csalnak, akkor az SNMP is alapértelmezetten be van kapcsolva, ráadásul olyan szörnyen "valószerűtlen" alapértékekkel, mint a "public" RO és a "private" RW community string. Ha pedig ismerjük az RW stringet, akkor tudunk írni az SNMP fába, például arra a helyre is, ahol a "monitor" nevű felhasználó jelszava van:
root@NMS:~# snmpset -v1 -cprivate 10.10.10.2 .1.3.6.1.4.1.43.10.4.2.1.4.7.109.111.110.105.116.111.114 s titok
SNMPv2-SMI::enterprises.43.10.4.2.1.4.7.109.111.110.105.116.111.114 = STRING: "titok"
root@NMS:~# telnet 10.10.10.2
Entering character mode
Escape character is '^]'.
Login: monitor
Password: titok
Menu options: ---------------------3Com Switch 4070---------------------
bridge - Administer bridge-wide parameters
fabric - Administer XRN fabrics
feature - Administer system features
logout - Logout of the Command Line Interface
physicalInterface - Administer physical interfaces
protocol - Administer protocols
system - Administer system-level functions
trafficManagement - Administer traffic management
Type ? for help
-------------------------------------TESTSW-2 (1)-----------------------
Select menu option: logout
exiting session....
Connection closed by foreign host
root@NMS:~#
Még egy érdekesség a 3Com-os felhasználónevekkel kapcsolatban, ha megnézzük az OID-t ahová írtunk, láthatjuk, hogy az OID vége az, hogy: "109.111.110.105.116.111.114". Ha most utánanézünk, hogy mi is az ASCII kódja a "monitor" egyes karaktereinek, akkor már nem is olyan nehéz kitalálni, hogyan lehet a jóval több jogosultsággal bíró "manager" felhasználó jelszavát átírni. Az "admin" OID-je egy picit különbözik, de nem sokban:
Az snmpset néhány paraméterrel többet igényel mint az egyéb eszközök. Az első és talán a legfontosabb különbség, hogy olyan community stringet kell megadnunk neki, amellyel írni is lehet a fába. Tipikusan az alapértelmezett RO string a "public" szokott lenni, az alapértelmezett RW string pedig a "private". Ökölszabály, hogy soha nem használjuk az RW stringet (főleg SNMPv1 és SNMPv2 esetén), csak akkor, amikor tényleg írunk is a fába -- de erre még később visszatérünk. Persze önmagában a community string nem elég, pontosan meg kell adnunk, hogy hol, illetve azt is, hogy milyen típusú adatot szeretnénk tárolni. A következő példában egy Nortel 5510-esen a system ágat kilistázzuk, majd átírjuk az egyik levelét és újra kilistázzuk:
admin@NMS:~$ snmpwalk -v1 -cpublic 10.10.10.1 system
SNMPv2-MIB::sysDescr.0 = STRING: Ethernet Routing Switch 5510-24T HW:32 FW:4.2.0.12 SW:v4.2.0.002
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.45.3.52.1
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (1132653378) 131 days, 2:15:33.78
SNMPv2-MIB::sysContact.0 = STRING: Telecom Team
SNMPv2-MIB::sysName.0 = STRING: TESTSW-01
SNMPv2-MIB::sysLocation.0 = STRING: Testlab
SNMPv2-MIB::sysServices.0 = INTEGER: 3
admin@NMS:~$ snmpset -v1 -cprivate 10.10.10.1 SNMPv2-MIB::sysContact.0 s NINCS
SNMPv2-MIB::sysContact.0 = STRING: NINCS
admin@NMS:~$ snmpwalk -v1 -cpublic 10.10.10.1 system
SNMPv2-MIB::sysDescr.0 = STRING: Ethernet Routing Switch 5510-24T HW:32 FW:4.2.0.12 SW:v4.2.0.002
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.45.3.52.1
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (1132667603) 131 days, 2:17:56.03
SNMPv2-MIB::sysContact.0 = STRING: NINCS
SNMPv2-MIB::sysName.0 = STRING: TESTSW-01
SNMPv2-MIB::sysLocation.0 = STRING: Testlab
SNMPv2-MIB::sysServices.0 = INTEGER: 3
Az snmpset paraméterei a példa alapján nagyjából egyértelműek lehetnek, az egyetlen kérdéses elem az az adattípus megadása, ez közvetlenül az érték előtt szerepel a parancssori paramétereinkben, ami esetünkben egy "s", azaz string érték volt. Értelemszerűen egy adott OID-be csak a MIB-ben definiált típusú adatot tudunk beírni. Az egyéb lehetséges típusok felsorolása az snmpset --help outputjának a végéről:
TYPE: one of i, u, t, a, o, s, x, d, b
i: INTEGER, u: unsigned INTEGER, t: TIMETICKS, a: IPADDRESS
o: OBJID, s: STRING, x: HEX STRING, d: DECIMAL STRING, b: BITS
U: unsigned int64, I: signed int64, F: float, D: double
Nem csak a típuson csúszhat meg az írás. Vannak ugyanis a fában igen terbélyes ágak, ahová egyáltalán nem írhatunk be semmit, még RW community stringgel sem, ezen OID-k esetén a MIB-ben a MAX-ACCESS tulajdonság "read-only" értékű, így a felülírásuk nem lehetséges, például nem tudjuk átírni egyebek mellett az interfészek neveit sem, pedig a string mint adattípus stimmelne:
admin@NMS:~$ snmpwalk -v1 -cpublic 10.10.10.1 IfName
IF-MIB::ifName.1 = STRING: ifc1 (Slot: 1 Port: 1)
IF-MIB::ifName.2 = STRING: ifc2 (Slot: 1 Port: 2)
IF-MIB::ifName.3 = STRING: ifc3 (Slot: 1 Port: 3)
IF-MIB::ifName.4 = STRING: ifc4 (Slot: 1 Port: 4)
IF-MIB::ifName.5 = STRING: ifc5 (Slot: 1 Port: 5)
IF-MIB::ifName.6 = STRING: ifc6 (Slot: 1 Port: 6)
IF-MIB::ifName.7 = STRING: ifc7 (Slot: 1 Port: 7)
IF-MIB::ifName.8 = STRING: ifc8 (Slot: 1 Port: 8)
IF-MIB::ifName.9 = STRING: ifc9 (Slot: 1 Port: 9)
IF-MIB::ifName.10 = STRING: ifc10 (Slot: 1 Port: 10)
IF-MIB::ifName.11 = STRING: ifc11 (Slot: 1 Port: 11)
IF-MIB::ifName.12 = STRING: ifc12 (Slot: 1 Port: 12)
IF-MIB::ifName.13 = STRING: ifc13 (Slot: 1 Port: 13)
IF-MIB::ifName.14 = STRING: ifc14 (Slot: 1 Port: 14)
IF-MIB::ifName.15 = STRING: ifc15 (Slot: 1 Port: 15)
IF-MIB::ifName.16 = STRING: ifc16 (Slot: 1 Port: 16)
IF-MIB::ifName.17 = STRING: ifc17 (Slot: 1 Port: 17)
IF-MIB::ifName.18 = STRING: ifc18 (Slot: 1 Port: 18)
IF-MIB::ifName.19 = STRING: ifc19 (Slot: 1 Port: 19)
IF-MIB::ifName.20 = STRING: ifc20 (Slot: 1 Port: 20)
IF-MIB::ifName.21 = STRING: ifc21 (Slot: 1 Port: 21)
IF-MIB::ifName.22 = STRING: ifc22 (Slot: 1 Port: 22)
IF-MIB::ifName.23 = STRING: ifc23 (Slot: 1 Port: 23)
IF-MIB::ifName.24 = STRING: ifc24 (Slot: 1 Port: 24)
IF-MIB::ifName.10001 = STRING: ifc10001 VLAN #1
IF-MIB::ifName.10101 = STRING: ifc10101 VLAN #101
IF-MIB::ifName.10111 = STRING: ifc10111 VLAN #111
IF-MIB::ifName.10112 = STRING: ifc10112 VLAN #112
IF-MIB::ifName.11099 = STRING: ifc11099 VLAN #1099
admin@NMS:~$ snmpset -v1 -cprivate 10.10.10.1 IF-MIB::ifName.1 s IFACE1
Error in packet.
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: IF-MIB::ifName.1
Hiába van azonban korlátozva már MIB szinten az SNMP fába való írás, nem rohangászhatunk állandóan SNMP RW stringekkel a hálózaton, hiszen SNMP v3 alatt minden kódolatlanul jön és megy, ami a legtöbb környezetben kockázatokat hordoz. Hogy ez mennyire így van, megosztok egy konkrét példát, ami a jelenlegi H3C / HPN eszközök nagyjából két generációval ezelőtti felmenőit érinti. Konkrétan a 3Com 4000-es széria darabjairól van szó, pl. a 4050-es, 4060-as, 4070-es, 4400-as, 4900-as stb. eszközökről, amelyek kb. 2004-2006-ban számítottak frissnek a piacon. Ezeken az eszközökön alapértelmezetten létezik az "admin", a "manager" és a "monitor" nevű felhasználó, és ha emlékeim nem csalnak, akkor az SNMP is alapértelmezetten be van kapcsolva, ráadásul olyan szörnyen "valószerűtlen" alapértékekkel, mint a "public" RO és a "private" RW community string. Ha pedig ismerjük az RW stringet, akkor tudunk írni az SNMP fába, például arra a helyre is, ahol a "monitor" nevű felhasználó jelszava van:
root@NMS:~# snmpset -v1 -cprivate 10.10.10.2 .1.3.6.1.4.1.43.10.4.2.1.4.7.109.111.110.105.116.111.114 s titok
SNMPv2-SMI::enterprises.43.10.4.2.1.4.7.109.111.110.105.116.111.114 = STRING: "titok"
root@NMS:~# telnet 10.10.10.2
Entering character mode
Escape character is '^]'.
Login: monitor
Password: titok
Menu options: ---------------------3Com Switch 4070---------------------
bridge - Administer bridge-wide parameters
fabric - Administer XRN fabrics
feature - Administer system features
logout - Logout of the Command Line Interface
physicalInterface - Administer physical interfaces
protocol - Administer protocols
system - Administer system-level functions
trafficManagement - Administer traffic management
Type ? for help
-------------------------------------TESTSW-2 (1)-----------------------
Select menu option: logout
exiting session....
Connection closed by foreign host
root@NMS:~#
Még egy érdekesség a 3Com-os felhasználónevekkel kapcsolatban, ha megnézzük az OID-t ahová írtunk, láthatjuk, hogy az OID vége az, hogy: "109.111.110.105.116.111.114". Ha most utánanézünk, hogy mi is az ASCII kódja a "monitor" egyes karaktereinek, akkor már nem is olyan nehéz kitalálni, hogyan lehet a jóval több jogosultsággal bíró "manager" felhasználó jelszavát átírni. Az "admin" OID-je egy picit különbözik, de nem sokban:
2011-09-19
FQDN alapú tűzfalszabályok diagnosztikája FortiOS alatt
A legtöbb komolyabb tűzfalplatform biztosít lehetőséget FQDN alapú tűzfalszabályok létrehozására, nincs ez másként a FortiOS alatt sem. Az FQDN-es szabályok alkalmazása azonban nem feltétlenül jó ötlet, hiszen a forgalom átengedése vagy visszatartása a tűzfal szempontjából egy másik, független rendszerre, a DNS-re épít, illetve megbízik annak a másik rendszernek az integritásában. Többek közt ezért is érdemes mindig a belső DNS szervereinket beállítani a tűzfalon (bár ettől még önmagában nem lesz biztonságosabb vagy megbízhatóbb a DNS rendszerünk). Mindenesetre ha alkalmazunk ilyen domain neves szabályokat is a tűzfalon, akkor további talányokhoz vezethet, ha az FQDN-es szabály mégsem működik, látszólag mégis minden tökéletesen rendben van.
A Fortigate tűzfalakon a webes felület nem ad sok lehetőséget arra, hogy leellenőrizzük, hogy egy FQDN-es szabály éppen milyen IP-kre helyettesíti a domain nevet, ugyanakkor van egy remek parancs a CLI-ben, amivel utánajárhatunk a tűzfalunk által a domian nevek helyett használt épp aktuális IP-knek:
FORTIGATE ~ $ diagnose firewall fqdn list
www.google.hu: ID(27) REF(1) ADDR(209.85.148.103) ADDR(209.85.148.104) ADDR(209.85.148.105) ADDR(209.85.148.106) ADDR(209.85.148.147) ADDR(209.85.148.99)
srp.eu.blackberry.net: ID(33) REF(2) ADDR(93.186.25.33) ADDR(193.109.81.33)
interwetten.com: ID(38) REF(1) ADDR(195.10.192.12)
energia.eon-hungaria.com: ID(52) REF(2) ADDR(217.67.35.141)
kkk.vam.gov.hu: ID(56) REF(2) ADDR(84.206.40.1)
microsoft.com: ID(67) REF(1) ADDR(207.46.197.32) ADDR(207.46.232.182)
login.live.com: ID(356) REF(1) ADDR(65.54.186.19) ADDR(65.54.186.47) ADDR(65.54.186.77) ADDR(65.54.165.136) ADDR(65.54.165.169) ADDR(65.54.165.175) ADDR(65.54.165.177) ADDR(65.54.186.17)
symantec.com: ID(209) REF(1) ADDR(206.204.52.31) ADDR(216.12.145.20)
update.microsoft.com: ID(244) REF(1) ADDR(65.55.25.59)
Ezeket a DNS cache információkat összevethetjük a DNS-ben elérhető információkkal, gyakran csak annyiról van ugyanis szó, hogy a tűzfal nincs szinkronban a DNS-sel, becache-elt valamilyen IP-t egy adott névhez, míg a valódi közben megváltozott. A parancs kimenetében minden egyes domain névhez tartozik ADDR mezőn vagy mezőkön kívül egy ID és egy REF mező is: fogalmam sincs mit jelenthetnek. Az ID-ról azt gondoltam, hogy a FortiOS tűzfal policyjeiben használt, és külön listában is (get firewall address) kezelt címek ID-jairól van szó, de semmi jele, hogy ezekhez tartozna ID, még a konfigurációs fájlban sem, szóval ezt a teóriát sem megerősíteni sem cáfolni nem tudom. A másik mezőről, a REF-ről elsőre úgy véltem, hogy arra utal, hány referencia van az adott névre a tűzfal policy-kben, de ez sem stimmelt, szóval passz, nem tudni mik ezek. A CLI Reference Guide-ot sem üthetjük fel ezekkel kapcsolatban, ott ugyanis nincs egy szó sem erről a parancsról.
A fenti diagnose firewall fqdn list parancsnak van egyébként még két testvére, az fqdn flush eldobja a cache-ben lévő IP-ket, míg az fqdn purge egyszerűen kipucolja a névlistából az összes olyan domain nevet, amit nem használ a tűzfal. Van továbbá arra is lehetőség, szintén csak a CLI alatt, hogy a DNS cache-be bekerülő nevekhez mi magunk definiáljuk, hogy milyen időközönként ellenőrizze a rendszer a DNS-ben az IP címeket (set ttl <másodperc> a config firewall address / edit domain_név alatt) -- felülvágva ezzel a rendes DNS-ből származó TTL információkat.
A Fortigate tűzfalakon a webes felület nem ad sok lehetőséget arra, hogy leellenőrizzük, hogy egy FQDN-es szabály éppen milyen IP-kre helyettesíti a domain nevet, ugyanakkor van egy remek parancs a CLI-ben, amivel utánajárhatunk a tűzfalunk által a domian nevek helyett használt épp aktuális IP-knek:
FORTIGATE ~ $ diagnose firewall fqdn list
www.google.hu: ID(27) REF(1) ADDR(209.85.148.103) ADDR(209.85.148.104) ADDR(209.85.148.105) ADDR(209.85.148.106) ADDR(209.85.148.147) ADDR(209.85.148.99)
srp.eu.blackberry.net: ID(33) REF(2) ADDR(93.186.25.33) ADDR(193.109.81.33)
interwetten.com: ID(38) REF(1) ADDR(195.10.192.12)
energia.eon-hungaria.com: ID(52) REF(2) ADDR(217.67.35.141)
kkk.vam.gov.hu: ID(56) REF(2) ADDR(84.206.40.1)
microsoft.com: ID(67) REF(1) ADDR(207.46.197.32) ADDR(207.46.232.182)
login.live.com: ID(356) REF(1) ADDR(65.54.186.19) ADDR(65.54.186.47) ADDR(65.54.186.77) ADDR(65.54.165.136) ADDR(65.54.165.169) ADDR(65.54.165.175) ADDR(65.54.165.177) ADDR(65.54.186.17)
symantec.com: ID(209) REF(1) ADDR(206.204.52.31) ADDR(216.12.145.20)
update.microsoft.com: ID(244) REF(1) ADDR(65.55.25.59)
Ezeket a DNS cache információkat összevethetjük a DNS-ben elérhető információkkal, gyakran csak annyiról van ugyanis szó, hogy a tűzfal nincs szinkronban a DNS-sel, becache-elt valamilyen IP-t egy adott névhez, míg a valódi közben megváltozott. A parancs kimenetében minden egyes domain névhez tartozik ADDR mezőn vagy mezőkön kívül egy ID és egy REF mező is: fogalmam sincs mit jelenthetnek. Az ID-ról azt gondoltam, hogy a FortiOS tűzfal policyjeiben használt, és külön listában is (get firewall address) kezelt címek ID-jairól van szó, de semmi jele, hogy ezekhez tartozna ID, még a konfigurációs fájlban sem, szóval ezt a teóriát sem megerősíteni sem cáfolni nem tudom. A másik mezőről, a REF-ről elsőre úgy véltem, hogy arra utal, hány referencia van az adott névre a tűzfal policy-kben, de ez sem stimmelt, szóval passz, nem tudni mik ezek. A CLI Reference Guide-ot sem üthetjük fel ezekkel kapcsolatban, ott ugyanis nincs egy szó sem erről a parancsról.
A fenti diagnose firewall fqdn list parancsnak van egyébként még két testvére, az fqdn flush eldobja a cache-ben lévő IP-ket, míg az fqdn purge egyszerűen kipucolja a névlistából az összes olyan domain nevet, amit nem használ a tűzfal. Van továbbá arra is lehetőség, szintén csak a CLI alatt, hogy a DNS cache-be bekerülő nevekhez mi magunk definiáljuk, hogy milyen időközönként ellenőrizze a rendszer a DNS-ben az IP címeket (set ttl <másodperc> a config firewall address / edit domain_név alatt) -- felülvágva ezzel a rendes DNS-ből származó TTL információkat.
2011-09-06
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:
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:
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:
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:
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
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/
--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"
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
user@NMS:~$ snmpwalk -m +BRIDGE-MIB -v1 -cpublic -On -Cc 10.10.10.1 \
dot1dTpFdbPort | grep "170.170.170.170.0.4"
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"
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"
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
2011-08-30
Parancssori SNMP eszközök (2.) - ifTable, IfName, ipNetToMediaTable
A legalapvetőbb információkhoz tehát meglehetősen egyszerű SNMP-n keresztül hozzájutni, azonban az SNMP fa nem csak skalár információkat tartalmaz. Az SNMP-ben skalárnak nevezik azokat az objektumokat, amelyek csak egyszer fordulnak elő a fában. Ezzel szemben léteznek táblázat objektumok is, ezek adatszekvenciákból állnak, amelyekből egy kétdimenziós táblázatot tudunk összerakni. Ilyen például az interfészekről fontos részleteket tartalmazó ifTable objektum (1.3.6.1.2.1.2.2), amire erőteljesen támaszkodik szinten minden SNMP alapú monitorozó rendszer, és ami nagyjából így fest még kevés interfész esetén is egy jó snmpwalk-kal bejárva:
user@NMS:~$ snmpwalk -v 1 -c public 10.10.10.1 ifTable
IF-MIB::ifIndex.1 = INTEGER: 1
IF-MIB::ifIndex.2 = INTEGER: 2
IF-MIB::ifIndex.3 = INTEGER: 3
IF-MIB::ifIndex.4 = INTEGER: 4
IF-MIB::ifIndex.7 = INTEGER: 7
IF-MIB::ifDescr.1 = STRING: FastEthernet0/0
IF-MIB::ifDescr.2 = STRING: FastEthernet0/1
IF-MIB::ifDescr.3 = STRING: Null0
IF-MIB::ifDescr.4 = STRING: E1 0/0
IF-MIB::ifDescr.7 = STRING: Tunnel0
IF-MIB::ifType.1 = INTEGER: ethernetCsmacd(6)
IF-MIB::ifType.2 = INTEGER: ethernetCsmacd(6)
IF-MIB::ifType.3 = INTEGER: other(1)
IF-MIB::ifType.4 = INTEGER: ds1(18)
IF-MIB::ifType.7 = INTEGER: tunnel(131)
IF-MIB::ifMtu.1 = INTEGER: 1500
IF-MIB::ifMtu.2 = INTEGER: 1500
IF-MIB::ifMtu.3 = INTEGER: 1500
IF-MIB::ifMtu.7 = INTEGER: 1514
IF-MIB::ifSpeed.1 = Gauge32: 100000000
IF-MIB::ifSpeed.2 = Gauge32: 100000000
IF-MIB::ifSpeed.3 = Gauge32: 4294967295
IF-MIB::ifSpeed.4 = Gauge32: 2048000
IF-MIB::ifSpeed.7 = Gauge32: 9000
IF-MIB::ifPhysAddress.1 = STRING: 0:16:46:78:6c:60
IF-MIB::ifPhysAddress.2 = STRING: 0:16:46:78:6c:61
IF-MIB::ifPhysAddress.3 = STRING:
IF-MIB::ifPhysAddress.4 = STRING:
IF-MIB::ifPhysAddress.7 = STRING:
IF-MIB::ifAdminStatus.1 = INTEGER: up(1)
IF-MIB::ifAdminStatus.2 = INTEGER: up(1)
IF-MIB::ifAdminStatus.3 = INTEGER: up(1)
IF-MIB::ifAdminStatus.4 = INTEGER: up(1)
IF-MIB::ifAdminStatus.7 = INTEGER: up(1)
IF-MIB::ifOperStatus.1 = INTEGER: up(1)
IF-MIB::ifOperStatus.2 = INTEGER: up(1)
IF-MIB::ifOperStatus.3 = INTEGER: up(1)
IF-MIB::ifOperStatus.4 = INTEGER: down(2)
IF-MIB::ifOperStatus.7 = INTEGER: up(1)
IF-MIB::ifLastChange.1 = Timeticks: (56321) 0:09:23.21
IF-MIB::ifLastChange.2 = Timeticks: (56120) 0:09:21.20
IF-MIB::ifLastChange.3 = Timeticks: (0) 0:00:00.00
IF-MIB::ifLastChange.4 = Timeticks: (0) 0:00:00.00
IF-MIB::ifLastChange.7 = Timeticks: (1905060) 5:17:30.60
IF-MIB::ifInOctets.1 = Counter32: 3421853959
IF-MIB::ifInOctets.2 = Counter32: 5264155
IF-MIB::ifInOctets.3 = Counter32: 384832
IF-MIB::ifInOctets.7 = Counter32: 165117
IF-MIB::ifInUcastPkts.1 = Counter32: 16650
IF-MIB::ifInUcastPkts.2 = Counter32: 2877
IF-MIB::ifInUcastPkts.3 = Counter32: 766
IF-MIB::ifInUcastPkts.7 = Counter32: 2015
IF-MIB::ifInNUcastPkts.1 = Counter32: 14238470
IF-MIB::ifInNUcastPkts.2 = Counter32: 10262
IF-MIB::ifInNUcastPkts.3 = Counter32: 0
IF-MIB::ifInNUcastPkts.7 = Counter32: 0
IF-MIB::ifInDiscards.1 = Counter32: 532
IF-MIB::ifInDiscards.2 = Counter32: 0
IF-MIB::ifInDiscards.3 = Counter32: 0
IF-MIB::ifInDiscards.7 = Counter32: 0
IF-MIB::ifInErrors.1 = Counter32: 5
IF-MIB::ifInErrors.2 = Counter32: 0
IF-MIB::ifInErrors.3 = Counter32: 0
IF-MIB::ifInErrors.7 = Counter32: 0
IF-MIB::ifInUnknownProtos.1 = Counter32: 1868685
IF-MIB::ifInUnknownProtos.2 = Counter32: 1143
IF-MIB::ifInUnknownProtos.3 = Counter32: 0
IF-MIB::ifInUnknownProtos.7 = Counter32: 0
IF-MIB::ifOutOctets.1 = Counter32: 8919871
IF-MIB::ifOutOctets.2 = Counter32: 4995771
IF-MIB::ifOutOctets.3 = Counter32: 454347
IF-MIB::ifOutOctets.7 = Counter32: 3123000
IF-MIB::ifOutUcastPkts.1 = Counter32: 53111
IF-MIB::ifOutUcastPkts.2 = Counter32: 44239
IF-MIB::ifOutUcastPkts.3 = Counter32: 4560
IF-MIB::ifOutUcastPkts.7 = Counter32: 2691
IF-MIB::ifOutNUcastPkts.1 = Counter32: 7026
IF-MIB::ifOutNUcastPkts.2 = Counter32: 7016
IF-MIB::ifOutNUcastPkts.3 = Counter32: 0
IF-MIB::ifOutNUcastPkts.7 = Counter32: 0
IF-MIB::ifOutDiscards.1 = Counter32: 0
IF-MIB::ifOutDiscards.2 = Counter32: 0
IF-MIB::ifOutDiscards.3 = Counter32: 0
IF-MIB::ifOutDiscards.7 = Counter32: 1
IF-MIB::ifOutErrors.1 = Counter32: 0
IF-MIB::ifOutErrors.2 = Counter32: 0
IF-MIB::ifOutErrors.3 = Counter32: 0
IF-MIB::ifOutErrors.7 = Counter32: 0
IF-MIB::ifOutQLen.1 = Gauge32: 0
IF-MIB::ifOutQLen.2 = Gauge32: 0
IF-MIB::ifOutQLen.3 = Gauge32: 0
IF-MIB::ifOutQLen.7 = Gauge32: 0
IF-MIB::ifSpecific.1 = OID: SNMPv2-SMI::zeroDotZero
IF-MIB::ifSpecific.2 = OID: SNMPv2-SMI::zeroDotZero
IF-MIB::ifSpecific.3 = OID: SNMPv2-SMI::zeroDotZero
IF-MIB::ifSpecific.7 = OID: SNMPv2-SMI::zeroDotZero
A táblázat oszlopai a következők: ifIndex, ifDescr, ifType stb. az ifSpecific-ig, minden egyes mező annyiszor ismétlődik az IfTable alatt, ahány interfész létezik az adott eszközön. Fontos az ifIndex érték, ugyanis ez alapján lehet SNMP-n keresztül egyértelműen azonosítani az interfészeket. Bizonyos esetekben, például PPP interfészek, tunnel interfészek esetén, amelyek forgalomtól függően le-föl kapcsolódnak, nem feltétlenül marad konzisztens az ifIndex értéke. Az ifIndex és a interfészek nevének összerendelése az ifName objektumban (1.3.6.1.2.1.31.1.1.1.1) található:
user@NMS:~$ snmpwalk -v 1 -c public 10.10.10.1 ifName
IF-MIB::ifName.1 = STRING: Fa0/0
IF-MIB::ifName.2 = STRING: Fa0/1
IF-MIB::ifName.3 = STRING: Nu0
IF-MIB::ifName.4 = STRING: E1 0/0
IF-MIB::ifName.7 = STRING: Tu0
Az SNMP táblázatok egyes oszlopai külön-külön is megjeleníthetőek az snmpwalk-kal, egyszerűen csak meg kell adnunk annak az oszlopnak az OID-jét, amely a kérdéses adatokat tartalmazza, az snmpwalk pedig ki fogja listázni az összes ilyen OID-t a fából, majd a már ismert módszerrel (ifName) kiirathatjuk azt is, hogy melyik adat melyik interfészhez tartozik.
Az ifTable adatai rettenetesen sokat elárulnak az eszközről: mely interfészek vannak up-ban, mennyi a forgalom rajtuk, milyen az unicast és az egyéb (broadcast, muticast) forgalom aránya, mennyire bírják az interfészek a terhelést, vannak-e rajta hibák, eldobott csomagok, a mezőnevek önmagukért beszélnek. Ha mindezt le tudjuk periodikusan, például percenként, ötpercenként kérdezni, társíthatunk hozzá némi programozott felügyeletet, például, hogy figyelmeztessen az NMS rendszer e-mailben, SMS-ben, ha az SNMP agentről kiolvasott ifTable adatok interfész hibákat mutatnak, vagy ha folyamatosan a maximális érték közelében tartózkodik queue length, vagy éppen ha felborult az unicast és az egyéb típusú forgalom aránya stb. A legtöbb komplex hálózatmonitorozó rendszer ilyen és ehhez hasonló szabályokból építkezik.
Ha elég nagy felbontásban használjuk a képernyőnket, megpróbálkozhatunk egy újabb paranccsal is, ami az SNMP táblázatokat egydimenziós lista helyett táblázatos formában jeleníti meg: ez az snmptable. A fenti ifTable snmpwalkkal való bejárása helyett a parancs a következő: snmptable -v1 -Cl -Cb -c public 10.10.10.1 ifTable. A -Cl balra rendezi a cellákat, a -Cb pedig a mezőneveket rövidíti le (pl. ifDescr helyett csak Descr jelenik meg):
Az interfészek adatain kívül mást is lehet táblázatokba tenni, a hálózatok feltérképezésekor jó hasznát vehetjük annak, hogy SNMP-n keresztül hozzáférünk az eszközök ARP táblájához, ami az IP (Layer 3-as) és a MAC (Layer 2-es) címösszerendeléseket tartalmazza. Az ARP táblázat ipNetToMediaTable néven található meg, OID-je: 1.3.6.1.2.1.4.22.
user@NMS:~$ snmptable -v1 -Cl -Cb -c public 10.10.20.1 ipNetToMediaTable
SNMP table: IP-MIB::ipNetToMediaTable
IfIndex PhysAddress NetAddress Type
1 0:15:60:55:64:a5 172.17.136.11 dynamic
1 0:14:7c:59:5e:e0 172.17.136.253 dynamic
1 0:1e:37:34:d1:5a 172.17.136.255 dynamic
2 0:16:46:78:6c:61 10.10.20.1 static
2 0:1e:37:34:d0:9c 10.10.20.2 dynamic
Ennél már csak az lehetne szebb, ha az access eszközökön a MAC - fizikai port hozzárendeléseket tartalmazó adatokhoz, azaz a switchek CAM táblájához is hozzáférhetnénk valahogyan SNMP-n keresztül. De erről majd a következő részben.
user@NMS:~$ snmpwalk -v 1 -c public 10.10.10.1 ifTable
IF-MIB::ifIndex.1 = INTEGER: 1
IF-MIB::ifIndex.2 = INTEGER: 2
IF-MIB::ifIndex.3 = INTEGER: 3
IF-MIB::ifIndex.4 = INTEGER: 4
IF-MIB::ifIndex.7 = INTEGER: 7
IF-MIB::ifDescr.1 = STRING: FastEthernet0/0
IF-MIB::ifDescr.2 = STRING: FastEthernet0/1
IF-MIB::ifDescr.3 = STRING: Null0
IF-MIB::ifDescr.4 = STRING: E1 0/0
IF-MIB::ifDescr.7 = STRING: Tunnel0
IF-MIB::ifType.1 = INTEGER: ethernetCsmacd(6)
IF-MIB::ifType.2 = INTEGER: ethernetCsmacd(6)
IF-MIB::ifType.3 = INTEGER: other(1)
IF-MIB::ifType.4 = INTEGER: ds1(18)
IF-MIB::ifType.7 = INTEGER: tunnel(131)
IF-MIB::ifMtu.1 = INTEGER: 1500
IF-MIB::ifMtu.2 = INTEGER: 1500
IF-MIB::ifMtu.3 = INTEGER: 1500
IF-MIB::ifMtu.7 = INTEGER: 1514
IF-MIB::ifSpeed.1 = Gauge32: 100000000
IF-MIB::ifSpeed.2 = Gauge32: 100000000
IF-MIB::ifSpeed.3 = Gauge32: 4294967295
IF-MIB::ifSpeed.4 = Gauge32: 2048000
IF-MIB::ifSpeed.7 = Gauge32: 9000
IF-MIB::ifPhysAddress.1 = STRING: 0:16:46:78:6c:60
IF-MIB::ifPhysAddress.2 = STRING: 0:16:46:78:6c:61
IF-MIB::ifPhysAddress.3 = STRING:
IF-MIB::ifPhysAddress.4 = STRING:
IF-MIB::ifPhysAddress.7 = STRING:
IF-MIB::ifAdminStatus.1 = INTEGER: up(1)
IF-MIB::ifAdminStatus.2 = INTEGER: up(1)
IF-MIB::ifAdminStatus.3 = INTEGER: up(1)
IF-MIB::ifAdminStatus.4 = INTEGER: up(1)
IF-MIB::ifAdminStatus.7 = INTEGER: up(1)
IF-MIB::ifOperStatus.1 = INTEGER: up(1)
IF-MIB::ifOperStatus.2 = INTEGER: up(1)
IF-MIB::ifOperStatus.3 = INTEGER: up(1)
IF-MIB::ifOperStatus.4 = INTEGER: down(2)
IF-MIB::ifOperStatus.7 = INTEGER: up(1)
IF-MIB::ifLastChange.1 = Timeticks: (56321) 0:09:23.21
IF-MIB::ifLastChange.2 = Timeticks: (56120) 0:09:21.20
IF-MIB::ifLastChange.3 = Timeticks: (0) 0:00:00.00
IF-MIB::ifLastChange.4 = Timeticks: (0) 0:00:00.00
IF-MIB::ifLastChange.7 = Timeticks: (1905060) 5:17:30.60
IF-MIB::ifInOctets.1 = Counter32: 3421853959
IF-MIB::ifInOctets.2 = Counter32: 5264155
IF-MIB::ifInOctets.3 = Counter32: 384832
IF-MIB::ifInOctets.7 = Counter32: 165117
IF-MIB::ifInUcastPkts.1 = Counter32: 16650
IF-MIB::ifInUcastPkts.2 = Counter32: 2877
IF-MIB::ifInUcastPkts.3 = Counter32: 766
IF-MIB::ifInUcastPkts.7 = Counter32: 2015
IF-MIB::ifInNUcastPkts.1 = Counter32: 14238470
IF-MIB::ifInNUcastPkts.2 = Counter32: 10262
IF-MIB::ifInNUcastPkts.3 = Counter32: 0
IF-MIB::ifInNUcastPkts.7 = Counter32: 0
IF-MIB::ifInDiscards.1 = Counter32: 532
IF-MIB::ifInDiscards.2 = Counter32: 0
IF-MIB::ifInDiscards.3 = Counter32: 0
IF-MIB::ifInDiscards.7 = Counter32: 0
IF-MIB::ifInErrors.1 = Counter32: 5
IF-MIB::ifInErrors.2 = Counter32: 0
IF-MIB::ifInErrors.3 = Counter32: 0
IF-MIB::ifInErrors.7 = Counter32: 0
IF-MIB::ifInUnknownProtos.1 = Counter32: 1868685
IF-MIB::ifInUnknownProtos.2 = Counter32: 1143
IF-MIB::ifInUnknownProtos.3 = Counter32: 0
IF-MIB::ifInUnknownProtos.7 = Counter32: 0
IF-MIB::ifOutOctets.1 = Counter32: 8919871
IF-MIB::ifOutOctets.2 = Counter32: 4995771
IF-MIB::ifOutOctets.3 = Counter32: 454347
IF-MIB::ifOutOctets.7 = Counter32: 3123000
IF-MIB::ifOutUcastPkts.1 = Counter32: 53111
IF-MIB::ifOutUcastPkts.2 = Counter32: 44239
IF-MIB::ifOutUcastPkts.3 = Counter32: 4560
IF-MIB::ifOutUcastPkts.7 = Counter32: 2691
IF-MIB::ifOutNUcastPkts.1 = Counter32: 7026
IF-MIB::ifOutNUcastPkts.2 = Counter32: 7016
IF-MIB::ifOutNUcastPkts.3 = Counter32: 0
IF-MIB::ifOutNUcastPkts.7 = Counter32: 0
IF-MIB::ifOutDiscards.1 = Counter32: 0
IF-MIB::ifOutDiscards.2 = Counter32: 0
IF-MIB::ifOutDiscards.3 = Counter32: 0
IF-MIB::ifOutDiscards.7 = Counter32: 1
IF-MIB::ifOutErrors.1 = Counter32: 0
IF-MIB::ifOutErrors.2 = Counter32: 0
IF-MIB::ifOutErrors.3 = Counter32: 0
IF-MIB::ifOutErrors.7 = Counter32: 0
IF-MIB::ifOutQLen.1 = Gauge32: 0
IF-MIB::ifOutQLen.2 = Gauge32: 0
IF-MIB::ifOutQLen.3 = Gauge32: 0
IF-MIB::ifOutQLen.7 = Gauge32: 0
IF-MIB::ifSpecific.1 = OID: SNMPv2-SMI::zeroDotZero
IF-MIB::ifSpecific.2 = OID: SNMPv2-SMI::zeroDotZero
IF-MIB::ifSpecific.3 = OID: SNMPv2-SMI::zeroDotZero
IF-MIB::ifSpecific.7 = OID: SNMPv2-SMI::zeroDotZero
A táblázat oszlopai a következők: ifIndex, ifDescr, ifType stb. az ifSpecific-ig, minden egyes mező annyiszor ismétlődik az IfTable alatt, ahány interfész létezik az adott eszközön. Fontos az ifIndex érték, ugyanis ez alapján lehet SNMP-n keresztül egyértelműen azonosítani az interfészeket. Bizonyos esetekben, például PPP interfészek, tunnel interfészek esetén, amelyek forgalomtól függően le-föl kapcsolódnak, nem feltétlenül marad konzisztens az ifIndex értéke. Az ifIndex és a interfészek nevének összerendelése az ifName objektumban (1.3.6.1.2.1.31.1.1.1.1) található:
user@NMS:~$ snmpwalk -v 1 -c public 10.10.10.1 ifName
IF-MIB::ifName.1 = STRING: Fa0/0
IF-MIB::ifName.2 = STRING: Fa0/1
IF-MIB::ifName.3 = STRING: Nu0
IF-MIB::ifName.4 = STRING: E1 0/0
IF-MIB::ifName.7 = STRING: Tu0
Az SNMP táblázatok egyes oszlopai külön-külön is megjeleníthetőek az snmpwalk-kal, egyszerűen csak meg kell adnunk annak az oszlopnak az OID-jét, amely a kérdéses adatokat tartalmazza, az snmpwalk pedig ki fogja listázni az összes ilyen OID-t a fából, majd a már ismert módszerrel (ifName) kiirathatjuk azt is, hogy melyik adat melyik interfészhez tartozik.
user@NMS:~$ snmpwalk -v1 -c public 10.10.10.1 ifInErrors
IF-MIB::ifInErrors.1 = Counter32: 5
IF-MIB::ifInErrors.2 = Counter32: 0
IF-MIB::ifInErrors.3 = Counter32: 0
IF-MIB::ifInErrors.7 = Counter32: 0
Az ifTable adatai rettenetesen sokat elárulnak az eszközről: mely interfészek vannak up-ban, mennyi a forgalom rajtuk, milyen az unicast és az egyéb (broadcast, muticast) forgalom aránya, mennyire bírják az interfészek a terhelést, vannak-e rajta hibák, eldobott csomagok, a mezőnevek önmagukért beszélnek. Ha mindezt le tudjuk periodikusan, például percenként, ötpercenként kérdezni, társíthatunk hozzá némi programozott felügyeletet, például, hogy figyelmeztessen az NMS rendszer e-mailben, SMS-ben, ha az SNMP agentről kiolvasott ifTable adatok interfész hibákat mutatnak, vagy ha folyamatosan a maximális érték közelében tartózkodik queue length, vagy éppen ha felborult az unicast és az egyéb típusú forgalom aránya stb. A legtöbb komplex hálózatmonitorozó rendszer ilyen és ehhez hasonló szabályokból építkezik.
Ha elég nagy felbontásban használjuk a képernyőnket, megpróbálkozhatunk egy újabb paranccsal is, ami az SNMP táblázatokat egydimenziós lista helyett táblázatos formában jeleníti meg: ez az snmptable. A fenti ifTable snmpwalkkal való bejárása helyett a parancs a következő: snmptable -v1 -Cl -Cb -c public 10.10.10.1 ifTable. A -Cl balra rendezi a cellákat, a -Cb pedig a mezőneveket rövidíti le (pl. ifDescr helyett csak Descr jelenik meg):
 |
| Ehhez kell a nagy monitor :) |
user@NMS:~$ snmptable -v1 -Cl -Cb -c public 10.10.20.1 ipNetToMediaTable
SNMP table: IP-MIB::ipNetToMediaTable
IfIndex PhysAddress NetAddress Type
1 0:15:60:55:64:a5 172.17.136.11 dynamic
1 0:14:7c:59:5e:e0 172.17.136.253 dynamic
1 0:1e:37:34:d1:5a 172.17.136.255 dynamic
2 0:16:46:78:6c:61 10.10.20.1 static
2 0:1e:37:34:d0:9c 10.10.20.2 dynamic
Ennél már csak az lehetne szebb, ha az access eszközökön a MAC - fizikai port hozzárendeléseket tartalmazó adatokhoz, azaz a switchek CAM táblájához is hozzáférhetnénk valahogyan SNMP-n keresztül. De erről majd a következő részben.
2011-08-29
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.)
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.)
2011-08-26
GRE/IPSec tunnel Cisco és Vyatta eszközök közt
Korábban volt már egy hasonló című poszt (GRE tunnel IPSec-ben Cisco és Vyatta eszközök közt), gyanús lehet, hogy most ugyanazt elsütöm mégegyszer, pedig nem, a mostani pár sorban különbözik :). Akkor Adrian F. Dimcev ötletére épülve egy loopback interfészes trükk közbeiktatásával készült kézzel összedrótozgatott GRE/IPSec-hez hasonló megoldás, azonban a Vyatta 6.3 új IPSec VPN lehetőségeinek hála egyszerűbben is megoldható a probléma. A mostani teszt során az alábbi topológia készült el:
A környezet felépítéséhez egy Cisco 3725-ös routert, illetve Vyatta oldalon egy Vyatta Core 6.3-assal telepített mezei PC-t használtam. A Cisco oldali konfiguráció a következőképp alakul:
GRE/IPSec esetén crypto map-et, crypto ACL-t, nem kell megadnunk (milyen subnetből milyen subnetbe megy az IPSec-kel védett forgalom), hiszen az a GRE tunnelben fog utazni, az IPSec-nek pedig itt csak annyit kell tudnia, hogy mi a két IP a GRE tunnel két végén, és hogy e két IP között a GRE forgalom legyen titkosítva. A minimalista tesztkonfigot a GRE szomszédra mutató, a túloldali védett subnethez tartozó route zárja. A Vyatta konfiguráció sem bonyolultabb, sőt szerintem áttekinthetőbb, jobban csoportosított, pirossal emeltem ki a Vyatta 6.3-ban bemutatkozó új lehetőséget (az IPSec processz által lekezelendő forgalom megadása protokollal):
A végeredmény a korábban bemutatott megoldáshoz képest egyszerűbb, a két eszköz mögötti védett hálózatok forgalma azonban a korábbiakhoz hasonlóan IPSec tunnelben, azon belül GRE tunnelben utazik az egyik routertől a másikig. A megoldás tesztelését könnyen megejthetjük mondjuk egy telnet sessionnel pl. a 10.10.10.2-es hostról a 10.10.20.2-es hostra, nyilvánvalóan ezeket a hostokat is fel kell konfigurálni (IP cím, default route, telnet szolgáltatás). Ha a már működő telnet sessionbe belehallgatunk a megfelelő Vyatta interfészen tsharkkal, akkor viszont csak az ESP payloadot láthatjuk, várakozásainknak megfelelően:
A környezet felépítéséhez egy Cisco 3725-ös routert, illetve Vyatta oldalon egy Vyatta Core 6.3-assal telepített mezei PC-t használtam. A Cisco oldali konfiguráció a következőképp alakul:
interface FastEthernet0/0
ip address 172.17.136.254 255.255.248.0
no shutdown
exit
interface FastEthernet0/1
ip address 10.10.20.1 255.255.255.0
no shutdown
exit
crypto isakmp policy 10
encr aes 256
hash sha
authentication pre-share
lifetime 28800
group 5
exit
crypto isakmp key TITOK address 172.17.136.255
crypto ipsec transform-set TESZTSET esp-aes 128 esp-md5-hmac
exit
crypto ipsec security-association lifetime seconds 3600
crypto ipsec profile TESZTPROFIL
set transform-set TESZTSET
exit
interface Tunnel 0
ip address 10.0.0.2 255.255.255.252
tunnel source 172.17.136.254
tunnel destination 172.17.136.255
tunnel protection ipsec profile TESZTPROFIL
exit
ip route 10.10.10.0 255.255.255.0 10.0.0.1
GRE/IPSec esetén crypto map-et, crypto ACL-t, nem kell megadnunk (milyen subnetből milyen subnetbe megy az IPSec-kel védett forgalom), hiszen az a GRE tunnelben fog utazni, az IPSec-nek pedig itt csak annyit kell tudnia, hogy mi a két IP a GRE tunnel két végén, és hogy e két IP között a GRE forgalom legyen titkosítva. A minimalista tesztkonfigot a GRE szomszédra mutató, a túloldali védett subnethez tartozó route zárja. A Vyatta konfiguráció sem bonyolultabb, sőt szerintem áttekinthetőbb, jobban csoportosított, pirossal emeltem ki a Vyatta 6.3-ban bemutatkozó új lehetőséget (az IPSec processz által lekezelendő forgalom megadása protokollal):
set interfaces ethernet eth0 address 172.17.136.255/21
set interfaces ethernet eth1 address 10.10.10.1/24
set interfaces tunnel tun1 address 10.0.0.1/30
set interfaces tunnel tun1 encapsulation gre
set interfaces tunnel tun1 local-ip 172.17.136.255
set interfaces tunnel tun1 remote-ip 172.17.136.254
set vpn ipsec ike-group TESZT-IKE-GROUP
set vpn ipsec ike-group TESZT-IKE-GROUP lifetime 28800
set vpn ipsec ike-group TESZT-IKE-GROUP proposal 10
set vpn ipsec ike-group TESZT-IKE-GROUP proposal 10 dh-group 5
set vpn ipsec ike-group TESZT-IKE-GROUP proposal 10 encryption aes256
set vpn ipsec ike-group TESZT-IKE-GROUP proposal 10 hash sha1
set vpn ipsec esp-group TESZT-ESP-GROUP
set vpn ipsec esp-group TESZT-ESP-GROUP proposal 10 encryption aes128
set vpn ipsec esp-group TESZT-ESP-GROUP proposal 10 hash md5
set vpn ipsec esp-group TESZT-ESP-GROUP lifetime 3600
set vpn ipsec ipsec-interfaces interface eth0
set vpn ipsec site-to-site peer 172.17.136.254
set vpn ipsec site-to-site peer 172.17.136.254 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 172.17.136.254 authentication pre-shared-secret TITOK
set vpn ipsec site-to-site peer 172.17.136.254 ike-group TESZT-IKE-GROUP
set vpn ipsec site-to-site peer 172.17.136.254 local-ip 172.17.136.255
set vpn ipsec site-to-site peer 172.17.136.254 tunnel 1
set vpn ipsec site-to-site peer 172.17.136.254 tunnel 1 esp-group TESZT-ESP-GROUP
set vpn ipsec site-to-site peer 172.17.136.254 tunnel 1 protocol gre
set protocols static route 10.10.20.0/24 next-hop 10.0.0.2
A végeredmény a korábban bemutatott megoldáshoz képest egyszerűbb, a két eszköz mögötti védett hálózatok forgalma azonban a korábbiakhoz hasonlóan IPSec tunnelben, azon belül GRE tunnelben utazik az egyik routertől a másikig. A megoldás tesztelését könnyen megejthetjük mondjuk egy telnet sessionnel pl. a 10.10.10.2-es hostról a 10.10.20.2-es hostra, nyilvánvalóan ezeket a hostokat is fel kell konfigurálni (IP cím, default route, telnet szolgáltatás). Ha a már működő telnet sessionbe belehallgatunk a megfelelő Vyatta interfészen tsharkkal, akkor viszont csak az ESP payloadot láthatjuk, várakozásainknak megfelelően:
vyatta@vyatta:~$ sudo tshark -i eth0
Running as user "root" and group "root". This could be dangerous.
Capturing on eth0
0.000000 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
0.018434 172.17.136.254 -> 172.17.136.255 ESP ESP (SPI=0xdf68cfb5)
0.018748 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
0.179962 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
0.198421 172.17.136.254 -> 172.17.136.255 ESP ESP (SPI=0xdf68cfb5)
0.198757 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
0.319907 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
0.338476 172.17.136.254 -> 172.17.136.255 ESP ESP (SPI=0xdf68cfb5)
0.338800 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
0.459966 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
0.478455 172.17.136.254 -> 172.17.136.255 ESP ESP (SPI=0xdf68cfb5)
0.478774 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
0.879923 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
0.898456 172.17.136.254 -> 172.17.136.255 ESP ESP (SPI=0xdf68cfb5)
0.898779 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
1.027966 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
1.048497 172.17.136.254 -> 172.17.136.255 ESP ESP (SPI=0xdf68cfb5)
1.048816 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
1.067968 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
1.088483 172.17.136.254 -> 172.17.136.255 ESP ESP (SPI=0xdf68cfb5)
1.126881 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
1.239920 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
1.258538 172.17.136.254 -> 172.17.136.255 ESP ESP (SPI=0xdf68cfb5)
1.258873 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
1.379974 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
1.398574 172.17.136.254 -> 172.17.136.255 ESP ESP (SPI=0xdf68cfb5)
1.398900 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
1.759984 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
1.778730 172.17.136.254 -> 172.17.136.255 ESP ESP (SPI=0xdf68cfb5)
1.779053 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
Feliratkozás:
Bejegyzések (Atom)