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:

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.1.3.6.1.2.1.17.4.3.1.2.170.170.170.170.0.4 = INTEGER: 138

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

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

.1.3.6.1.2.1.17.1.4.1.2.138 = INTEGER: 146800833

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

.1.3.6.1.2.1.31.1.1.1.1.146800833 = STRING: GigabitEthernet3/0/22

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

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

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

Ugyanez IOS-ben:

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

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

Parancssori SNMP eszközök (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>.