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.

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 :)

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.

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

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:

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)

Vyatta image-based telepítés, frissítés

Egy jó ideje már figyelemmel kísérem a Vyatta network OS fejlődését, és gyakorlatilag a 4-es verzióktól kezdve mindig használtam is valamire az éppen aktuális kiadást. Nem feltétlenül nagy dolgokra, de egyre több éles, nem kritikus rendszerünk ezt futtatja. Most, kb. egy hónappal az új, 6.3-as verzió kiadása után, eljött az idő a frissítésre.

A frissítés lehetősége függ attól, hogy hogyan telepítettük rendszert, amit lehet disk-based (install-system parancs) és image-based (install-image parancs) módban is telepíteni. Az OS image kezelés a hatos verziók újdonsága volt, image alapon sokkal rugalmasabb felállást kapunk, egyszerre több image-ünk is lehet feltelepítve, amelyek közül a boot menüben kiválaszthatjuk, melyiket futtatnánk. Minden image-hez külön, független konfiguráció tartozik, amit importálhatunk, exportálhatunk az image-ek közt.

Úgy tűnik, hogy a fejlesztők is inkább az image alapú irányt szeretnék hosszabb távon továbbvinni: a 6.3-as kiadásban ugyanis már nincs lehetőség a frissítésre a disk-based telepítés esetében a full-upgrade paranccsal. Nem lennék meglepődve, ha néhány kiadás múlva teljesen ki is kopna a rendszerből disk-based telepítési lehetőség.

Hogyan néz ki egy image alapú telepítés? Nagyjából úgy, mint akármelyik live Linux. Felkerül a merevlemezre vagy flash memóriára a bootloader (sima GRUB2), illetve minden egyes feltelpített Vyatta image-hez készül egy könyvtár, amiben négy fontos dolog van: a legnagyobb falat az adott image (egy squashfs fájlrendszer, kb. 190MB), aztán van itt még a rendszer bebootolásához egy kernel, az intitrd és egy live-rw nevű alkönyvtár.

A bekapcsolás után a bootloader betölti a kiválasztott image-hez tartozó kernelt, majd az initrd-n keresztül behúzza az adott image-hez tarozó squashfs read only fájlrendszert (ez egyetlen image fájl a tényleges, fizikai fájlrendszerünkön), végül unionfs-sel összefésüli a squashfs tartalmát a már említett live-rw könytár tartalmával. Minden squashfsbe "fagyasztott" állapothoz képest történő változás fizikailag ebbe a live-rw könyvtárba kerül, többek közt a felhasználó által létrehozott konfiguráció is, ám az unionfs a végfelhasználó elől ezt teljesen elrejti, a felhasználó csak a hagyományos UNIX fájlrendszerstruktúrát látja a rendszer működése közben.

Mindezekről, hogy squashfs így, meg unionfs úgy, initrd erre, bootloader amarra, a Vyatta felhasználónak semmit sem kell tudnia, annyi féle Vyatta szoftver image-t tarthat a gépén, amennyit az elbír, az a néhány dolog, amit érdemes megjegyezni a következő:

• Ha jön az új Vyatta verzió, akkor az legegyszerűbben az add system image http://www.vyatta.com/downloads/verzioszam.iso paranccsal telepíthető. A rendszer az ISO fájlból kimásolja a squashfs image-t és a többi tartozékot. A folyamat közben felajánlja az éppen futó image-hez tartozó konfiguráció átmásolását az új imagehez (bemásolja az ahhoz tartozó live-rw könyvtárba, a felhasználó számára persze az unionfs-en keresztül mutatott konfiguráció mindig a /config könyvtárában lesz megtalálható).
• A rendszer bootolásakor kiválasztható, hogy melyik image-t szeretnénk futtatni, az alapértelmezett a set system image default-boot <image neve> paranccsal adható meg (ez beállítja a GRUB-ot).
• A már nem használt image-től a delete system image <image neve> paranccsal lehet végleg megszabadulni.
• A konfiguráció másolható a különféle image-ek közt, például az épp futó image-ről a "VPNteszt" nevű másik image-be így másolható át: copy file running://config/ to VPNteszt://config/

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

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

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

Switch#configure terminal
Switch(config)#interface port-channel 1
Switch(config-if)#exit
Switch(config)#interface range Fa0/47 - 48
Switch(config-if-range)#channel-group 1 mode on
Switch(config-if-range)#exit
Switch(config)#interface port-channel 1
Switch(config-if)#switchport mode trunk
Switch(config-if)#switchport trunk allowed vlan 1-2
Switch(config-if)#exit
Switch(config)#exit

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

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

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

BS5510-24T#show mlt utilization 1

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

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

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

LACP Cisco és HP ProCurve eszközök közt

Mivel még megvan a tegnapi tesztkörnyezet, gondoltam, kipróbálom egy régebbi HP eszközzel is, egy ProCurve 2824-es kallódott itt a környéken, leporolgattam, kiütöttem róla a régi konfigot. Az előző LACP-s teszthez hasonlóan egy két VLAN-os LACP összeköttetés létrehozása volt a cél. A Cisco 2960-as 47-es portja a HP 2824-es 23-as portjára van kötve, a 48-as pedig a HP 24-es portjára. Az IOS konfiguráció teljesen megegyzik a tegnapival:

Switch#configure terminal
Switch(config)#interface port-channel 1
Switch(config-if)#exit
Switch(config)#interface range Fa0/47 - 48
Switch(config-if-range)#channel-group 1 mode active
Switch(config-if-range)#exit
Switch(config)#interface port-channel 1
Switch(config-if)#switchport mode trunk
Switch(config-if)#switchport trunk allowed vlan 1-2
Switch(config-if)#exit
Switch(config)#exit

A HP Procurve switchen a konfiguráció az egyéb network OS-ekhez képest hihetetlenül egyszerű, ugyanakkor azt érdemes tudni, hogy a régi HP rendszereken "trunk" a neve ugyanannak a dolognak, amit mondjuk a Cisco EtherChannel néven illett, vagy amit éppen a 3Com link aggregationnek nevez. Szóval a régi HP terminológiában a "trunk" véletlenül sem a VLAN trönköléssel kapcsolatos fogalom, a VLAN-ok esetében a tagged és untagged fogalmakkal operálnak. Az aggregált link létrehozását az alábbi parancsokkal tehetjük meg:

ProCurve Switch 2824#configure
ProCurve Switch 2824(config)# trunk 23-24 trk1 lacp
ProCurve Switch 2824(config)# vlan 1 untagged trk1
ProCurve Switch 2824(config)# vlan 2 tagged trk1
ProCurve Switch 2824(config)# exit

A trunk paranccsal a korábbiakhoz hasonlóan (3Com manual mód) létrehozhatunk LACP nélküli aggregált linket is (trunk x-x trkX trunk), ám erre, ahogy arról szintén volt már korábban szó, aligha lesz szükségünk. A Cisco rendszerekhez hasonlóan a HP ProCurve switchen a virtuális interfész (trk1) módosításával lehet az aggregált link fizikai interfészeinek tulajdonságait állítgatni, ahogy a fenti példában is látható, a 23-as és 24-es portok a trk1-en keresztül kapják a VLAN tagságukra vonatkozó beállításokat. A linkek állapotát a show trunks és a show lacp paranccsal vizsgálhatjuk:

ProCurve Switch 2824# show trunks

Load Balancing

  Port | Name                             Type      | Group Type
  ---- + -------------------------------- --------- + ----- -----
  23   |                                  100/1000T | Trk1  LACP
  24   |                                  100/1000T | Trk1  LACP  

ProCurve Switch 2824# show lacp

                           LACP

   PORT   LACP      TRUNK     PORT      LACP      LACP
   NUMB   ENABLED   GROUP     STATUS    PARTNER   STATUS
   ----   -------   -------   -------   -------   -------
   1      Passive   1         Up        No        Success
   2      Passive   2         Down      No        Success
   3      Passive   3         Down      No        Success
   4      Passive   4         Down      No        Success
   5      Passive   5         Down      No        Success
   6      Passive   6         Down      No        Success
   7      Passive   7         Down      No        Success
   8      Passive   8         Down      No        Success
   9      Passive   9         Down      No        Success
   10     Passive   10        Down      No        Success
   11     Passive   11        Down      No        Success
   12     Passive   12        Down      No        Success
   13     Passive   13        Down      No        Success
   14     Passive   14        Down      No        Success
   15     Passive   15        Down      No        Success
   16     Passive   16        Down      No        Success
   17     Passive   17        Down      No        Success
   18     Passive   18        Down      No        Success
   19     Passive   19        Down      No        Success
   20     Passive   20        Down      No        Success
   21     Passive   21        Down      No        Success
   22     Passive   22        Down      No        Success
   23     Active    Trk1      Up        Yes       Success
   24     Active    Trk1      Up        Yes       Success

LACP Cisco és 3Com/HPN/H3C/Huawei eszközök közt

A Cisco eszközökön az aggregált linkeket EtherChannelnek hívják, amit kétféle port aggregation protokoll is működtethet, az egyik a PAgP, a másik az LACP (IEEE 802.3ad, újabban 802.3ax). Más gyártóknál nem divat ennyire tolni a saját tervezésű protokollokat, így például az általam rendszeresen egy kalap alá sorolt 3Com, HPN, H3C és Huawei eszközöknél csak az IEEE szabvány LACP támogatott. Hogy ezek mennyire működnek együtt? Nézzük meg!

A teszthez egy Cisco 2960-ast és egy 3Com 5500-as switchet használtam, a két eszközt fizikailag összekötöttem, 47-es portot a 47-es porttal, 48-ast a 48-assal. Minden gyártónál közös alapelv, hogy az aggregálandó portoknak a típusa, sebessége, duplexitása, a VLAN trönkölési beállításai meg kell, hogy egyezzenek, egyébként gondok lehetnek az aggregált linkkel. Általánosságban azt is érdemes tudni, hogy az aggregált linkeken realizálható tényleges sebesség nem feltétlenül áll egyenes arányban az abban szereplő portok számával, tehát pl. egy nyolc darab gigabites fizikai portból felépülő aggregált link nem feltétlenül muzsikál majd 8Gb/s-on, érdemes a részleteknek mindig utánaolvasni az LACP-re használt eszköz dokumentációjában. Például a Cisco ISR routerek (28xx, 38xx) összesen két EtherChannel létrehozását támogatják, amelyekben a fizikai interfészek maximális száma négy, és a ténylegesen mérhető sebesség a routerben használt  egyéb funkcióktól is függ. A switcheken, tisztán Layer 2-es LACP linkeken persze nem jellemző az ilyesfajta korlát. A cégünknél eddig a gyakorlatban nem is a sávszélesség növelése miatt használtunk LACP-t, sokkal inkább a redundancia miatt, Layer 2-ben ez is egy lehetőség a sima STP-vel megvalósított redundancia mellett/helyett.

A két teszteszközön gyári alapbeállításokról indultam, a bemutatandó konfigurációban nincs feltüntetve a management IP cím beállítása, illetve a VLAN2 létrehozása. A cél egy működő, két interfészes Layer 2-es LACP kapcsolat létrehozása a Cisco 2960-as és a 3Com 5500-as eszköz között 802.1q VLAN trönköléssel. Ez utóbbi egyébként apró csalás: a 802.1q-t nem is kell a teszteszközökön állítani, a 3Com ezer éve kizárólag 802.1q-t implementált, a Cisco 2960-ason pedig már csak 802.1q van, ISL nincs, ennek megfelelően nincs is switchport trunk encapsulation parancs.

A konfiguráció során először az IOS-en elkészül a port-channel 1 interfész, üres konfigurációval, majd a channel-group 1 paranccsal hozzáadom az aggregációban részt vevő interfészeket (Fa0/47, Fa0/48), végül ezen port-channel 1 interfészen keresztül minden channel-group 1 port megkapja a VLAN trönk konfigurációt:

Switch#configure terminal
Switch(config)#interface port-channel 1
Switch(config-if)#exit
Switch(config)#interface range Fa0/47 - 48
Switch(config-if-range)#channel-group 1 mode active
Switch(config-if-range)#exit
Switch(config)#interface port-channel 1
Switch(config-if)#switchport mode trunk
Switch(config-if)#switchport trunk allowed vlan 1-2
Switch(config-if)#exit
Switch(config)#exit

Az alábbi példában szépen látszik, hogy nem nyúltunk ugyan közvetlenül az Fa0/47 és az Fa0/48 VLAN beállításaihoz, mégis megörökölték a beállításokat a Port-channel 1 virtuális interfésztől:

Switch#sh run | begin 0/47
interface FastEthernet0/47
 switchport trunk allowed vlan 1,2
 switchport mode trunk
 channel-group 1 mode active
!
interface FastEthernet0/48
 switchport trunk allowed vlan 1,2
 switchport mode trunk
 channel-group 1 mode active
!

Egy kis kiegészítő még a channel-group parancshoz: a mode active az LACP protokollt engedélyezi az adott porton, az "active" érték esetén a port küld és fogad is LACP üzeneteket, míg a "passive" érték esetén csak fogad. Mindez azért érdekes, mert a 3Com oldalon megvan ezeknek a beállításoknak a párjai, ám a 3ComOS alatt nem a portoknál kell megadnunk ezt a beállítást, hanem az aggregation group konfigurációjánál.

<5500-EI>sys
[5500-EI]link-aggregation group 1 mode static
[5500-EI]interface Ethernet 1/0/47
[5500-EI-Ethernet1/0/47]port link-aggregation group 1
[5500-EI-Ethernet1/0/47]quit
[5500-EI]interface Ethernet 1/0/48
[5500-EI-Ethernet1/0/48]port link-aggregation group 1
[5500-EI-Ethernet1/0/48]port link-type trunk
[5500-EI-Ethernet1/0/48]port trunk permit vlan 1 2
[5500-EI-Ethernet1/0/48]quit
[5500-EI]quit

A 3ComOS-ben háromféle aggregáció lehetséges. A "manual" esetén az aggregált portok egyáltalán nem használnak LACP-t, ilyenkor nincsenek az aggregációra vonatkozó metaüzenet-váltások az eszközök közt, nincs LACP statisztika, márpedig a statisztikákat a networkösök általában kedvelik. Személy szerint jobb szeretem, ha egy protokoll felügyeli magát az aggregációt, folyamatosan egyeztet a partner eszközzel, valahogy nyugodtabb az ember, és gond esetén könnyebb a hibakeresés is, látszanak az LACP partner eszköznek az azonosítói. A "static" beállítás esetében működik az LACP az aggregált portokon, ám nekünk magunknak kell létrehozni az aggregation group-okat, illetve azokba nekünk kell portokat pakolnunk, legjobban ezt a beállítást szeretem, és nem mellesleg a fenti példa is ilyen. Létezik még a "dynamic" típus is, ám ezt nem kell külön beállítani, semmiféle aggregation group-ot nem kell létrehoznunk, csupán a megfelelő portokon kiadni az lacp enable parancsot, és az OS magától kitalálja, hogy melyik port milyen aggregation groupba tartozik, majd lekezel mindent. Értelemszerűen ezt a "dynamic" típust sok aggregált link esetén bátor dolog használni, főképp ha dokumentálni is szeretnénk az aggregált linkjeinket.

A 3Com "manual" módról a Cisco IOS azt gondolja, hogy az a channel-group x mode passive beállítással egyezik meg, míg a 3Com "static" módja IOS alatt "active" beállításnak felel meg.

Még egy érdekesség: az IOS-ben a VLAN trönkölést a port-channel 1 interfészen végeztük el, ahonnan a fizikai portok megörökölték a beállításokat. 3ComOS-ben nincs ilyen virtuális interfész, azonban ha már él az aggregált linkünk, akkor annak bármelyik portját konfiguráljuk át, a beállításokat megkapja a többi port is. A példában fent csak a 48-as porton állítottam be a VLAN trönkölést, ám ezek a beállítások érvényre jutnak az adott aggregation group minden egyéb portján, esetünkben a például a 47-esen. Az viszont elengedhetetlen, hogy az aggregation groupban lévő portok konfigurációja a groupba való helyezéskor egyforma legyen.


Diagnosztika, hibakeresés IOS alatt: show lacp parancsok, különösen a show lacp x neighbor, show lacp sys-id, illetve a show etherchannel parancsok, különösen a show etherchannel summary, valamint a show etherchannel x detail. 3ComOS-en a display lacp system-id, valamint a display link-aggregation summary, illetve a display link-aggregetion interface <interfész>.

Némi Nortel/Avaya tapasztalat

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

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

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

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

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

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

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

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