Link Layer Discovery protokollok használata (4.) - LLDP Cisco IOS-en

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.

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

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

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

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

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

HP-SW# show lldp info remote-device
 

  LLDP Remote Devices Information

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

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

HP-SW# show lldp info remote-device 24
 

 LLDP Remote Device Information Detail

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

  System Capabilities Supported  : bridge
  System Capabilities Enabled    : bridge

  Remote Management Address
     Type    : ipv4
     Address : 10.10.136.250

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ESC-8600-001:5# show sys topology

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

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