A következő címkéjű bejegyzések mutatása: cdp. Összes bejegyzés megjelenítése
A következő címkéjű bejegyzések mutatása: cdp. Összes bejegyzés megjelenítése

2012-02-29

Alapvető biztonsági beállítások MikroTiken

Néhány poszttal ezelőtt volt szó a Mikrotik eszközök ISR routerként történő használatáról, akkor egy-két teljesen szokványos lehetőséget (SNAT, DNAT, DHCP kliens WAN oldalon, DHCP szerver LAN oldalon, NTP kliens, WPA2 PSK wifi) vettünk elő CLI-ben, viszont tárva-nyitva hagytuk a rendszert, így valószínűleg nem élne túl a konfigurációnk pár napnál hosszabb időt érintetlenül publikus interneten. A biztonságosabb működés érdekében a legelső lépés az alapértelmezett admin jelszó megváltoztatása:
[admin@Tik] > /password
old password: password
new password: *************
retype new password: *************
Ez már önmagában sokat jelent, itt azonban semmiképp se pihenjünk még le, következhet a nem használt szolgáltatások kikapcsolása. Amire ténylegesen is szükség lehet, az az SSH, a többit bátran le lehet tiltani:
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set www-ssl disabled=yes
set api disabled=yes
set winbox disabled=yes
Akár le is ellenőrizhetjük, hogy mindent sikerült-e kikapcsolni:
[admin@Tik] > /ip service print Flags: X - disabled, I - invalid 
#   NAME        PORT ADDRESS            CERTIFICATE                                     
0 X telnet                23
1 X ftp                   21
2 X www                   80
3   ssh                   22
4 X www-ssl              443                   none
5 X api                 8728
6 X winbox              8291
A RouterOS-en alapértelmezésben figyel UDP-n a bandwidth-server. Ez az IPerf-hez hasonló eszköz, amivel sávszélesség teszteket végezhetünk, érdemes ezt is addig pihentetni, amíg nincs rá ténylegesen szükség. A bandwidth-server szolgáltatás beállítása nem az IP service-ek közt található:
/tool bandwidth-server
set enabled=no
Végül tanácsos legalább a WAN és a WLAN interfészen letiltani a MikroTik Neighbor Discovery protocolt (MNDP) és a CDP-t, hogy ne szivárogtassunk feleslegesen információkat a rendszerről:
/ip neighbor discovery
set wlan1 disabled=yes
set ether1 disabled=yes
Ezzel az alapvető biztonsági beállításokon túl is vagyunk, a környezettől függően természetesen sok egyéb lehetőségünk van még a RouterOS alatt: tűzfalszabályok beállítása, központi RADIUS authentikáció, SNMPv3, BGP MD5 authentikáció, stb. ebben a posztban csupán a legáltalánosabb lehetőségeket vettük sorra.

2012-02-03

Link Layer Discovery protokollok használata (5.) - CDP MikroTiken és Vyattán

Tulajdonképpen egész könnyen meg lehet szokni a MikroTik szoftverplatformját, a RouterOS-t, valójában igazi MikroTik eszköz sem kell ahhoz, hogy kipróbálhassuk, ugyanis van belőle x86-osra fordított változat, így akár virtuális gépre is telepíthető. A legfrissebb, 5.12-es kiadás IPSec-kel, MPLS-sel, NetFlow v9 exporttal, SNMP v3-mal és még számtalan lehetőséggel együtt sem több ~20MB-nál, ami bizony igen kevés, bármilyen mércével mérve, így aztán ideális választásnak tűnik nagyobb virtuális infrastruktúrák hálózati igényeinek kielégítésére.

De nem is erről szólna ez a poszt, hanem a MikroTik és a Vyatta CDP-kompatibilitásáról. A jó hír az, hogy mindkettőn működik, valódi Cisco eszközökkel tesztelve is, szerintem a Mikrotik megoldása a jobb, ugyanis a RouterOS alatt nagyon egyértelműen lehet kezelni a CDP-be bevont interfészeket, míg a Vyattán csak globálisan lehet ki- és bekapcsolni a CDP támogatást, bár állítólag dolgoznak az interfészenkénti ki- és bekapcsoláson. Ugyanakkor a Vyatta ismeri a CDP v2-t is, míg a RouterOS kizárólag CDP v1-et tud. A parancsok részletes leírogatása helyett ezúttal néhány beszédes képernyőképet készítettem, a képekre kattintva nagyobb felbontású változat is elérhető.

A Cisco eszköz látja mindkét CDP-s versenyzőt, a platform információk, a szoftververzió, a kapcsolódó fizikai portok teljesen korrekt módon jelennek meg az IOS-ben:


A MikroTik-es virtuális gép szintén hibátlanul teszi a dolgát, a gyártónál alapértelmezésben minden interfészen aktív a CDP, kivéve a vezeték-nélküli interfészeket, és mintha tunnel interfészeken sem kapcsolná be alapból a CDP-t a RouterOS; a lényeg, hogy vegyük a CDP-t is számításba (elsősorban biztonsági szempontból), amikor MikroTiket teszünk be a hálózatba. A képernyőképen a szomszédok listázása után példa látható arra is, hogyan kapcsolható ki egy adott interfészen a CDP, illetve arra, hogyan listázható az interfészek aktuális CDP-s állapota.


A CDP alapból nem fut a Vyattán, külön be kell kapcsolni (configure > set service lldp legacy-protocols cdp > commit > save). Az IOS CDP kereteitől a rendszer egy kissé megilletődött, kétszer is betette a neighbor táblázatba a Cisco AP-t, egyszer CDP v1-es, egyszer pedig CDP v2-es eszközként, ezt a kis botlást, valamint a többihez képest rendkívüli szószátyárságot leszámítva azonban nagyjából itt is minden rendben van:


Ugyanebben a témában a korábbi írásaim a Nortel, a 3Com (új HP) majd a HP (ProCurve, régi HP) Layer 2-es discovery protokolljainak alapvető használatát mutatták be, illetve az IOS-es LLDP-t.

2011-12-10

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.

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:

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.

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:

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.