Egytől hétig

VLAN-ok kezelése MikroTiken

2012-02-26T23:07:00.003+01:00

Vannak bizonyos megoldások a MikroTik RouterOS-en, amelyek, hát... legalábbis furcsának tűnnek egyéb network OS-ekhez képest, az egyik ilyen a VLAN-ok kezelése. Nem létezik olyasmi RouterOS alatt, hogy access port vagy trunk port, az van, amit összedrótozgatunk. Az alábbi parancsok például VLAN 1-3-ig, tagged VLAN kezelést biztosítanak az ether1 interfészen:

/interface vlan
add name="VLAN1" vlan-id=1 interface=ether1 disabled=no
add name="VLAN2" vlan-id=2 interface=ether1 disabled=no
add name="VLAN3" vlan-id=3 interface=ether1 disabled=no

Persze ezzel önmagában sokra nem megyünk, hiszen valahová tovább is kell kapcsolni ezeket a VLAN-okat, mondjuk access portokra. A következő döbbenet akkor éri a kezdő mikrotikest (például engem is), amikor kiderül, hogy amit mindenhol máshol access portnak hívnak, az itt tulajdonképpen nincs, de amit tehetünk, hogy mégis legyen, az sem az, hogy VLAN-okba tesszük a portokat, hanem:

/interface bridge
add name="BR1" disabled=no
add name="BR2" disabled=no
add name="BR3" disabled=no
/interface bridge port
add bridge=BR1 interface=ether2 disabled=no
add bridge=BR1 interface=ether3 disabled=no
add bridge=BR2 interface=ether4 disabled=no
add bridge=BR2 interface=ether5 disabled=no
add bridge=BR3 interface=ether6 disabled=no
add bridge=BR3 interface=ether7 disabled=no

Amint az a példából látható, a BR1 nevű bridge-hez az ether2-3, illetve a wlan1 port tartozik, a BR2-höz a ether4-5, a BR3-hoz pedig az ether6-7. Az itt definiált portcsoportok különálló VLAN-okként viselkednek, de természetesen az égvilágon semmi közük nincs az ether1 interfészen létrehozott trönkhöz, és az azon élő három tagged VLAN-hoz (némiképp emlékeztet egyébként mindez az autonóm Cisco AP-ken használatos BVI bridge group interfészekre). Az uplinken bejövő tagged VLAN-ok és a BR1, BR2, BR3 bridge-ek között úgy hozhatunk létre kapcsolatot, hogy a VLAN neveinkhez tartozó virtuális interfészeket szintén bepakoljuk a bridge-ekbe:

/interface bridge port
add bridge=BR1 interface=VLAN1 disabled=no
add bridge=BR2 interface=VLAN2 disabled=no
add bridge=BR3 interface=VLAN3 disabled=no

Ezzel eljutottunk oda, hogy az ether1-en bejövő tagged adatok megtalálják az útjukat az adott VLAN-on belül a MikroTik eszközre kapcsolt hostokig. De itt még nincs vége, ez csak az a módszer, ami minden MikroTik-en működik, egyes RouterBOARD-oknál ettől eltérő megoldást is lehet használni, attól függően, hogy milyen switch chip található a NYÁK-on. A RouterOS ugyanis nem fedi el a hardveres lehetőségeket, vannak hardverspecifikus parancsok a VLAN-ok kezelésére. A wiki.mikrotik.com-on található egy táblázat, ebből ki kell keresni, hogy a MikroTik eszközünkben milyen switch chip található, hogy támogatja-e a chip a port tükrözést, mekkora CAM táblát tud kezelni (MikroTik esetén ezt host table-nek hívják), vagy éppen azt, hogy hány VLAN-nal képes megbirkózni, és utána készíthetünk az adott switch chipre szabott VLAN konfigurációt, ami más RouterBOARD-on működésképtelen lehet. Beteges, nem igaz?

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

2012-02-03T22:14:00.005+01:00

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

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

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

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

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

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

MikroTik wifi rulez: spektrum analízis CLI-ben

2012-02-01T22:16:00.007+01:00

Minden WiFi eszközben helye lenne egy olyan tesztlehetőségnek, mint amilyet a MikroTik RouterOS-ben találtam. A szomorú valóság ezzel szemben az, hogy ilyesmi az Aruba cuccokon van, meg valami hasonló a Cisco AP-ken, de a legtöbb gyártó nem büszkélkedhet azzal, hogy a szabad felhasználású 2,4 Ghz-es illetve 5GHz-es tartományban spektrum analízist biztosítana.

Hogy mire jó ez? WiFi hibakeresésnél kiválóan használható az ugyanezekben a frekvenciatartományokban jelen lévő bármilyen fizikai jel kimutatására, aminek az egyéb WiFi eszközökön kívül lehet a forrása mikohullámú sütő, DECT telefon, autós riasztórendszer, rádiós kamerarendszer stb.

A MikroTik eszközökben - már amelyik támogatja ezt a lehetőséget, a RouterBoard 493-as történetesen ilyen - roppant egyszerű ennek a használata: interface wireless spectral-history wlan1:

Az itt látható rádiós környezetben például kiválóan megfigyelhető, hogy a 2437 MHz-es center frekvenciájú 6-os WiFi csatornára (2427-2447 MHz) nem érdemes jelet kitenni, sokkal jobbak a fizikai jel interferencia nélküli túlélésének esélyei az 1-es vagy a 11-es csatornán, igazán jól pedig a 13-as, vagy ha támogatják eszözeink, akkor 14-es csatornán érezné magát.

ISR router funkciók MikroTiken

2012-02-01T21:40:00.015+01:00

Tesztelésre nálam van egy MikroTik eszköz (RouterBoard 493-as), 5.11-es RouterOS-szel, 9 darab tetszés szerint konfigurálható (Layer 2 / Layer 3) Ethernet interfésszel és egy WiFi interfésszel. Soha nem használtam még MikroTiket meg RouterOS-t korábban, egy picit irigykedve olvasgattam mások tapasztalatairól fórumokon, erre-arra, hogy ez linuxos cucc, mennyire megbízható, olcsóbb, mint a Cisco, ezt is tudja, azt is tudja.

Azért be kell vallanom, nem volt túl rózsás a kezdet, ugye a webes GUI meg a WinBox nevű windowsos konfiguráló csodák eleve nem is nagyon izgattak, hiszen ha használni fogunk MikroTiket, akkor az olyan környezetben lesz, ahol csak CLI jöhet szóba, és a CLI-t azt bizony szokni kell mondjuk egy IOS vagy bármi hasonló után. A hivatalos CLI dokumentáció sincs túl bő lére eresztve, úgyhogy MikroTik vonalon sokat segít, ha az ember konzolkábelt ragad, és megpróbál mindenféle konfigurációkat összerakosgatni. Meglehet, hogy lesz még néhány hasonló poszt.

Elsőre arra gondoltam, hogy egy viszonylag általános ISR (Integrated Services Router) konfigurációt dobok össze: bridge a LAN portokon, SRC NAT, esetleg egy DNAT, WiFi (WPA2-PSK), WAN oldalon DHCP kliens, LAN oldalon DHCP szerver, NTP kliens... De még mielőtt belekezdenénk: a soros konzolport sebességét toljuk fel a terminálkliensünkön a sztenderd 9600-ról 115200-ra, ennél a típusnál ugyanis ez az alapértelmezés (gyors- és gépírók előnyben :)). A első dolog, amit érdemes beállítani, az a hostnév, itt persze véletlenül sem hostnévnek hívják:

/system identity
set name=TESZTROUTER

Jöhet a bridge interfész létrehozása. Fontos tudni, hogy ezen a boardon switch chip is van, így nem szoftverből történik a kapcsolás, hanem ASIC alapon megy, ami mindenképp dicséretes. A portok tetszőleges csoportját össze lehet bridge-elni, ebben a konfigurációban az ether1 porton kívül minden egyéb port a LAN oldali bridge groupban lesz:

/interface bridge
add name=bridge1
/interface bridge port
add bridge=bridge1 disabled=no interface=ether2
add bridge=bridge1 disabled=no interface=ether3
add bridge=bridge1 disabled=no interface=ether4
add bridge=bridge1 disabled=no interface=ether5
add bridge=bridge1 disabled=no interface=ether6
add bridge=bridge1 disabled=no interface=ether7
add bridge=bridge1 disabled=no interface=ether8
add bridge=bridge1 disabled=no interface=ether9
add bridge=bridge1 disabled=no interface=wlan1

Adjunk a WAN és LAN oldali interfészeinknek címet, a WAN port az ether1 lesz, a LAN oldalon pedig a bridge1 interfész fogja kiszolgálni a klienseket:

/ip dhcp-client
add default-route-distance=1 disabled=no interface=ether1
/ip address
add address=10.100.202.1/24 disabled=no interface=bridge1

A következő lépés a DHCP szerver beállítása LAN oldalon. Ehhez létre kell hozni egy IP poolt, azt hozzárendelni egy DHCP szerverhez (TEST_DHCP_SRV), illetve egy interfészhez (bridge1). Csak alapinformációkat adunk át a klienseknek, a default gw és egy Google DNS IP minden, amit az IP címen kívül megkapnak egy félórára. Egy pici csavart azért vittem bele, hogy megnézzem a static (v. reserved) DHCP funkciót is, a 00:0C:42:B5:8C:48-as MAC című kliensünk mindig a 10.100.202.200-as IP címet fogja megkapni:

/ip pool
add name=TEST_DHCP_POOL ranges=10.100.202.200-10.100.202.254
/ip dhcp-server
add name=TEST_DHCP_SRV address-pool=TEST_DHCP_POOL disabled=no interface=bridge1 lease-time=30m
/ip dhcp-server network
add address=10.100.202.0/24 dns-server=8.8.8.8 gateway=10.100.202.1
/ip dhcp-server lease
add address=10.100.202.200 disabled=no mac-address=00:0C:42:B5:8C:48

Következzék a NAT beállítása: egyrészt szeretnénk a 10.100.202.0/24-ben lévő LAN oldali klienseket betenni SRC NAT mögé, másrészt a WAN IP-re érkező TCP 2323 kapcsolatokat DNAT-tal áttesszük az imént static DHCP-re állított LAN oldali host 23-as TCP portjára. Itt mind a SRC, mind a DST NAT esetében olyan parancsváltozatokat használtam, amelyekkel el lehet kerülni a külső IP-re való hivatkozást (mivel ebben a konfigurációban dinamikus a WAN IP-cím), de természetesen a RouterOS kelléktárában vannak ennél komolyabb NAT szabályokat is lehetővé tevő eszközök:

/ip firewall nat
add action=masquerade chain=srcnat disabled=no out-interface=ether1
add action=dst-nat chain=dstnat disabled=no protocol=tcp dst-port=2323 to-port=23 to-addresses=10.100.202.200

Érdemes szinkronizálni a rendszer óráját valami közeli NTP szerverrel:

/system clock
set time-zone-name=Europe/Budapest
/system ntp client
set enabled=yes mode=unicast primary-ntp=148.6.0.1

Végül következhet a WiFi beállítása. Először egy biztonsági profilt kell létrehoznunk, amit utána rá lehet aggatni az SSID-nkre. A "TEST_PROFILE_WIFI" profil WPA2-PSK authentikációt használ és AES titkosítást, a profilt használó "TEST_MIKROTIK" SSID-t 802.11b, g és n szabványt ismerő klienseknek szórjuk az 1-es csatornán (2412 MHz):

/interface wireless security-profiles
add name=TEST_PROFILE_WIFI authentication-types=wpa2-psk group-ciphers=aes-ccm group-key-update=5m mode=dynamic-keys wpa2-pre-shared-key=12345678
/interface wireless
enable wlan1
set name=wlan1 mode=ap-bridge band=2ghz-b/g/n bridge-mode=enabled frequency=2412 hide-ssid=no security-profile=TEST_PROFILE_WIFI ssid=TEST_MIKROTIK

Ebben a formában a konfigurációnk még nem igazán internetképes, mindenféle biztonsági problémák lehetnek vele, alapból például fut a RouterOS-en a telnet szolgáltatás, tűzfalat is kellene konfigurálni, jelszót beállítani az admin usernek stb. de kezdetnek megteszi, a többit talán majd egy másik alkalommal.

Interfész információk Vyattán

2012-01-24T00:11:00.001+01:00

Elképzelni is nehéz, mit össze nem keresgéltem a múltkor, hogy miképp lehet Vyatta alatt megnézni egy Ethernet interfészen a hozzá tartozó speed és duplex beállításokat. A legtöbb network OS alatt ugye ez eléggé egyértelmű, egy sima show interface vagy mondjuk 3Com/HP/Huawei vonalon egy display interface parancs kiírja, hogy 10, 100 vagy 1000 M, full vagy half duplex, auto, nem auto. A Vyatta OS azonban nem követi ezt a konvenciót, úgyhogy eddig, ha szükségem volt ilyen jellegű információra, mindig "kiléptem" a Vyatta shellből sudo -i-vel és vagy a mii-tool vagy az ethtool parancsot használtam:

root@Vyatta:~# mii-tool eth1
eth1: negotiated 1000baseT-FD flow-control, link ok

root@Vyatta:~# ethtool eth1
Settings for eth1:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: g
Wake-on: g
Current message level: 0x000000ff (255)
Link detected: yes

Szép, szép, de ezek mégiscsak linuxos parancsok, tulajdonképpen mindig is bosszantott, hogy miért nem lehet ezt a sima Vyatta shellben megnézni. Aztán persze tök véletlenül kiderült, hogy a user a béna, természetesen benne van ez a Vyatta shellben is, csak nem egészen ott kerestem eddig, ahol kellett volna; az ethtool kimenetét adja a a következő parancs:

admin@Vyatta:~$ show interfaces ethernet eth1 physical
Settings for eth1:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: g
Wake-on: g
Current message level: 0x000000ff (255)
Link detected: yes
driver: tg3
version: 3.115
firmware-version: 5703-v2.22
bus-info: 0000:02:02.0

DNAT szabályok tűzfalazása Vyatta alatt

2012-01-10T21:57:00.006+01:00

Rég nem volt már teljes egészében Vyattának szentelt írás az oldalon, a napokban épp szóba is került a rendszernek egy érdekesebb tulajdonsága a munkahelyemen, így most semmi sem tarthat vissza attól, hogy mindazt, amiről ott szó volt, közzé ne tegyem. Alapvetően egyszerű dologról van szó, a Vyatta port forwarding vagy DNAT lehetőségéről, ami kombinálva némi szűréssel, könnyen káromkodásba fordulhat (megjegyzem, minden Linux rendszeren ugyanezen szisztéma szerint működik a DNAT). Mi is ez az egész pontosan? Íme a Vyatta dokumentációból kiollózott ábra, mely az egyes NAT alrendszerek, a routing folyamat és a tűzfalazás viszonyát szemlélteti:

Az ábrán a témánk szempontjából két fontos dolgot láthatunk, az egyik az, hogy a DNAT (destination NAT, avagy port forwarding, esetleg szolgáltatás publikálás) minden egyéb feldolgozási folyamat, routeolás, szűrés előtt történik meg egy beérkező csomagon. Ezzel szemben az SNAT (source NAT) a legutolsó lépés, ami csak a routeolás és a tűzfalazás után történik. A szűrés szempontjából az SNAT sima ügy, bejön a klienstől a csomag mondjuk a 192.168.0.100-as forrás IP-vel, a célcím nem a Vyatta rendszer (Dest=local? No), a tűzfal szépen átkergeti az IN, majd az OUT irányú szabályokon, végül az SNAT dobozkában leszerelik róla a 192.168.0.100-as feladói címet és ráhegesztik mondjuk feladóként az 1.2.3.4 publikus címet, illetve ezt fel is jegyzik egy táblázatba, hogy a visszatérő forgalmat le lehessen kezelni és eljusson az eredeti feladóhoz.

A DNAT egy kicsit más, arról van ugye szó, hogy az 1.2.3.4-re irányuló, pl. TCP 80-as forgalmat valójában nem a Vyatta webszervere emésztgeti, hanem a mögötte lévő NAT-olt hálóban mondjuk a 192.168.0.101-es host. Bemegy a DNAT dobozba a 1.2.3.4:80-ra küldött üzenet, odabent átalakul, és ami kijön, annak már 192.168.0.101:80 lesz a célja. Persze a dobozban ezt a csereberét megintcsak jól feljegyzik. Ezek után a routing megmondja, hogy ez a 192.168.0.101 a Vyatta LAN oldalán található cím (Dest=local? No), átmegy az IN, majd az OUT szűrőn, és kimegy a LAN-ba.

Mindez azért érdekes, mert az ember - főképp, ha vállalati tűzfalak GUI-jához szokott - a tűzfalszabályok írásakor alapból nincs NAT üzemmódban, és egy ilyen DNAT-olt 80-as portot simán úgy vesz fel a Vyatta tűzfalszabályokban, hogy a külső IP címmel számol, az 1.2.3.4:80-ra engedi be a népeket, pedig mire a tűzfalhoz eljut az 1.2.3.4:80-as csomag, addigra az már keresztülverekedte magát a DNAT-on, és 192.168.0.101:80 van benne.

Következzék egy konkrét konfig példa, ami kívülről elérhetővé teszi az 1.2.3.4:22-es és 1.2.3.4:80-as TCP portokat, a különbség annyi, hogy az SSH a Vyattán fut, a HTTP viszont NAT mögött, másik hoston. A Vyatta külső interfészének (eth0) bejövő szűrőjében mégis egy privát, belső IP cím szerepel:

firewall {
name INET_to_INTERNAL {
default-action drop
rule 100 {
action accept
description "Allowing HTTP traffic to internal host 101"
destination {
address 192.168.0.101
port 80
}
protocol tcp
}
}
name INET_to_LOCAL {
default-action drop
rule 100 {
action accept
protocol icmp
}
rule 200 {
action accept
description "SSH access on port 22"
destination {
address 1.2.3.4
port 22
}
protocol tcp
}
}
}
interfaces {
ethernet eth0 {
address 1.2.3.4/24
firewall {
in {
name INET_to_INTERNAL
}
local {
name INET_to_LOCAL
}
}
}
ethernet eth1 {
address 192.168.1.1/24
}
loopback lo {
}
}
protocols {
static {
route 0.0.0.0/0 {
next-hop 1.2.3.1 {
}
}
}
}
service {
nat {
rule 100 {
description "DNAT for HTTP on 192.168.0.101"
destination {
address 1.2.3.4
port 80
}
inbound-interface eth0
inside-address {
address 192.168.0.101
}
protocol tcp
type destination
}
rule 200 {
description "SNAT for internal subnet"
outbound-interface eth0
outside-address {
address 1.2.3.4
}
source {
address 192.168.0.0/24
}
type source
}
}
ssh {
port 22
protocol-version v2
}
}

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

2011-12-10T23:09:00.003+01:00

A korábbiakban a Nortel, a 3Com (új HP) majd a HP (ProCurve, régi HP) layer2-es discovery protokolljainak alapvető használatát vizsgáltuk. A HP-s posztban a korábbi gyártóspecifikus protokollok után előkerült az LLDP, az egyéb hasonló protokollokat felváltó nemzetközi szabvány. A mai poszt egy többgyártós rém egyszerű kis teszthálózatban mutatja meg az LLDP fontosabb képességeit Cisco oldalról. Nem fogunk túlságosan belemászni az LLDP konfigurációjába, így az olyan lehetőségeket, mint hogy a szomszédokról begyűjtött információt mennyi ideig tárolja a hostunk (LLDP holdtime), vagy éppen azt, hogy milyen időközönként szórjuk meg a szomszédos eszközöket LLDP PDU-kkal (LLDP update frequency), vagy hogy egyáltalán milyen TLV (Type-Lenght-Value) rekordokkal foglalkozzon az LLDP-s eszközünk, most átugorjuk, az alapértelmezésekre hagyatkozunk, ami egyébként az esetek túlnyomó részében tökéletesen elegendő is.

Cisco eszközökön az LLDP nagyjából a CDP-hez hasonlóan kezelhető, sőt egyszerre mindkettő futhat, az más kérdés, hogy van-e ilyesminek értelme, evidens, hogy amennyiben lehetséges, nem érdemes keverni a kettőt, vegyes környezetben várhatóan az LLDP lesz a favorit, homogén Cisco környezetben pedig a CDP.

A LLDP-vel kapcsolatos fontosabb konfigurációs parancsok IOS-en: globális konfig módban a (no) lldp run ki- vagy bekapcsolja az LLDP-t, illetve interfész konfigurációs módban hasznos lehet a no lldp transmit, továbbá a no lldp receive, ezekkel interfészenként tilthatjuk az LLDP küldést és fogadást, amit mindig érdemes legalább a hálózatunk külső csatlakozási pontjain megtenni. Az LLDP-s információs parancsokat az alábbi példák mutatják be:

CiscoSW#show lldp

Global LLDP Information:
    Status: ACTIVE
    LLDP advertisements are sent every 30 seconds
    LLDP hold time advertised is 120 seconds
    LLDP interface reinitialisation delay is 2 seconds

CiscoSW#show lldp neighbors
Capability codes:
    (R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
    (W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other

Device ID           Local Intf     Hold-time Capability      Port ID
3Com-SW         Fa0/1          120        B,R             Ethernet5/0/14
HP-SW               Gi0/1          120        B               24
Vyatta1             Fa0/48         120        R               001e.3734.d09c

Total entries displayed: 3

CiscoSW#show lldp neighbors detail
------------------------------------------------
Chassis id: 001a.c156.1040
Port id: Ethernet5/0/14
Port Description: Ethernet5/0/14
System Name: 3Com-SW

System Description:
Switch 5500-EI

Time remaining: 91 seconds
System Capabilities: B,R
Enabled Capabilities: B,R
Management Addresses - not advertised
Auto Negotiation - supported, enabled
Physical media capabilities:
    1000baseX(FD)
    1000baseX(HD)
    Symm Pause(FD)
    Asym Pause(FD)
    100base-T4
    10base-T(FD)
    10base-T(HD)
    Other/unknown
Media Attachment Unit type: 16
Vlan ID: 1

------------------------------------------------
Chassis id: 0016.b90b.e8a0
Port id: 24
Port Description: 24
System Name: HP-SW

System Description:
ProCurve J4903A Switch 2824, revision I.10.77, ROM I.08.07 (/sw/code/build/mako(mkfs))

Time remaining: 115 seconds
System Capabilities: B,R
Enabled Capabilities: B
Management Addresses:
    IP: 172.17.136.247
Auto Negotiation - not supported
Physical media capabilities - not advertised
Media Attachment Unit type - not advertised
Vlan ID: - not advertised

------------------------------------------------
Chassis id: 001e.3734.d09c
Port id: 001e.3734.d09c
Port Description: eth0
System Name: Vyatta1

System Description:
Vyatta Router running on Vyatta Core 6.3 2011.07.21

Time remaining: 111 seconds
System Capabilities: B,W,R
Enabled Capabilities: R
Management Addresses:
    IP: 172.17.136.253
Auto Negotiation - supported, enabled
Physical media capabilities:
    1000baseT(FD)
    100base-TX(FD)
    100base-TX(HD)
    10base-T(FD)
    10base-T(HD)
Media Attachment Unit type: 16
Vlan ID: - not advertised

MED Information:

    MED Codes:
          (NP) Network Policy, (LI) Location Identification
          (PS) Power Source Entity, (PD) Power Device
          (IN) Inventory

    H/W revision: ThinkCentre M57
    F/W revision: 2RKT41AUS
    S/W revision: 2.6.37-1-586-vyatta
    Serial number: LMBKVN2
    Manufacturer: LENOVO
    Model: 6089W25
    Asset id:
    Capabilities: LI, IN
    Device type: Network connectivity
    Network Policies - not advertised
    Power requirements - not advertised
    Location - not advertised

Total entries displayed: 3

Látható, hogy a Cisco eszközünknek három LLDP-s szomszédja van, egy 3Com 5500-EI, egy HP 2824, valamint egy Lenovo ThinkCentre M57 PC, amin Vyatta 6.3 fut. A figyelmesebbeknek az is feltűnhet, hogy mindegyik LLDP implementáció másféle TLV készlettel dolgozik, így nincsenek, nem is lehetnek egységesen kitöltve a megjelenő mezők a részletes nézetben.

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

2011-11-29T16:21:00.003+01:00

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

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

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

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

HP-SW# show lldp info remote-device 
 

LLDP Remote Devices Information

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

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

HP-SW# show lldp info remote-device 24 
  

LLDP Remote Device Information Detail

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

System Capabilities Supported : bridge
System Capabilities Enabled    : bridge

Remote Management Address
     Type    : ipv4
     Address : 10.10.136.250

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

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

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

2011-11-21T08:11:00.008+01:00

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

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

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

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

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

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

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

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

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

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

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

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

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

2011-11-17T21:54:00.012+01:00

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

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

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

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

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

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

ESC-8600-001:5# show sys topology

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

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

Parancssori SNMP eszközök (5.) - STP

2011-11-16T23:35:00.002+01:00

A korábbi részekben (első, második és harmadik) ezt-azt már kiolvasgattunk az SNMP fából, a negyedikben írtunk is bele alapvető dolgokat, a mai részben újra előveszem a BRIDGE MIB-et, van ebben ugyanis egy fontos ág, amit eddig nem érintettünk, az .1.3.6.1.2.1.17.2, azaz a dot1dStp, ami minden lényeges információt tartalmaz az eszközünkön futó feszítőfa (feszítőfák) állapotáról, illetve annak (azoknak) időbeli változásairól.

Kezdjük a Bridge ID prioritás mezőjének kiolvasásával, ennek az értéke az .1.3.6.1.2.1.17.2.2.0 OID-jű levélre van írva (dot1dStpPriority). Egyébként ez is read-write objektumként van a MIB-ben definiálva, így visszautalva az előző, snmpwrite-os részre: tényleg figyeljünk az eszközeinkre az SNMP RW jogosultságok tekintetében, legyünk rettenetesen szűkmarkúak, és ahol csak módunk van rá, használjuk az SNMP v3 titkosítási lehetőségeit. Gondoljunk csak bele, hogy mekkora galibát tud okozni egy olyan szkript, ami időnként ciklusban végigfut egy subnet minden hostján és ahol tudja, átírogatja a Bridge ID-kat... szinkronizálatlan SQL adatbázisok, szétesett clusterek, TCP sessionök véres cafatkái maradnak mindenhol a nyomában. Ehelyett mi inkább újra csak olvasunk SNMP-n keresztül:

admin@NMS:~$ snmpwalk -v1 -cpublic 10.10.10.250 .1.3.6.1.2.1.17.2.2.0
SNMPv2-SMI::mib-2.17.2.2.0 = INTEGER: 32769

Ez nagyjából minden nagyobb gyártónál hasonlóan működik, ugyanakkor vegyük azt is figyelembe, hogy nem minden gyártónál van alapból bekapcsolva az STP/RSTP/MSTP támogatás, például a HP ProCurve szériákon, így az általam teszteszközként használt 2824-esen sincs, ennek megfelelően amíg be nem kapcsoljuk az STP-t, természetesen nem lehet kiolvasni semmit erről az OID-ről. A közvetlen ezután következő két levél (dot1dStpTimeSinceTopologyChange, illetve a dot1dStpTopChanges) is informatív, ha ismeretlen rendszereket térképezünk fel:

admin@NMS:~$ snmpwalk -v1 -cpublic 10.10.10.250 .1.3.6.1.2.1.17.2.3.0
SNMPv2-SMI::mib-2.17.2.3.0 = Timeticks: (134700) 0:22:27.00
admin@NMS:~$ snmpwalk -v1 -cpublic 10.10.10.250 .1.3.6.1.2.1.17.2.4.0
SNMPv2-SMI::mib-2.17.2.4.0 = Counter32: 78

A példa szerint a 10.10.10.250 feszítőfája 22 perce változatlan és az SNMP processz elindulása óta 78 alkalommal történt a STP topológiaváltozás. Talán egy kicsit kevésbé érdekes, de legalább annyira fontos a többi adat is, ami még innen kiolvasható:

admin@NMS:~$ snmpwalk -m +BRIDGE-MIB -v1 -cpublic 10.10.10.250 .1.3.6.1.2.1.17.2
BRIDGE-MIB::dot1dStpProtocolSpecification.0 = INTEGER: ieee8021d(3)
BRIDGE-MIB::dot1dStpPriority.0 = INTEGER: 32769
BRIDGE-MIB::dot1dStpTimeSinceTopologyChange.0 = Timeticks: (255600) 0:22:36.00
BRIDGE-MIB::dot1dStpTopChanges.0 = Counter32: 78
BRIDGE-MIB::dot1dStpDesignatedRoot.0 = Hex-STRING: 00 00 00 16 E0 18 74 00
BRIDGE-MIB::dot1dStpRootCost.0 = INTEGER: 39
BRIDGE-MIB::dot1dStpRootPort.0 = INTEGER: 1
BRIDGE-MIB::dot1dStpMaxAge.0 = INTEGER: 2000
BRIDGE-MIB::dot1dStpHelloTime.0 = INTEGER: 200
BRIDGE-MIB::dot1dStpHoldTime.0 = INTEGER: 100
BRIDGE-MIB::dot1dStpForwardDelay.0 = INTEGER: 1500
BRIDGE-MIB::dot1dStpBridgeMaxAge.0 = INTEGER: 2000
BRIDGE-MIB::dot1dStpBridgeHelloTime.0 = INTEGER: 200
BRIDGE-MIB::dot1dStpBridgeForwardDelay.0 = INTEGER: 1500
...

A kimenetből megtudhatjuk, hogy az STP root egy 0 prioritású 00 16 E0 18 74 00 MAC című eszköz, ami közvetve csatlakozik csupán, 100Mbit/s-os nagyságrendű linkeken (távolság: 39, emlékeztetőül az IEEE cost értékek: 100 - 10Mb/s, 19 - 100Mb/s, 4 - 1Gb/s, 2 - 10Gb/s) a port 1-en keresztül, illetve láthatjuk az STP időzítési adatait. Ezek után egy táblázat következik (dot1dStpPortTable, 1.3.6.1.2.1.17.2.15) az egyes portok STP állapotairól, a porthoz társított költségekről stb. amit csak három ponttal jelöltem, hiszen ahhoz külön parancs dukál:

admin@NMS:~$ snmptable -m +BRIDGE-MIB -Cl -Cb -v1 -cpublic 172.17.136.250 .1.3.6.1.2.1.17.2.15

Ám ezzel még nincs vége, a legtöbb eszköz, ha képes per VLAN STP-re, MSTP-re akkor is belegyömöszöli az egyes portok státusz információit egyetlen .1.3.6.1.2.1.17.2, azaz dot1dStp ágba, ami időnként félrevezető lehet, hiszen elvileg előfordulhat olyan eset mondjuk, hogy a VLAN1-en egy adott port forwarding státuszban van, míg mondjuk VLAN2-ben pedig blokkol. A Cisco eszközökön ez a dilemma megintcsak a VLAN ID alapján indexelt community stringekkel, illetve a VLAN-onként külön nyilvántartott BRIDGE MIB adatokkal van feloldva, így nem mindegy, hogy a community stringünk public (=public@1) vagy éppen public@2, hiszen az első a VLAN1-ben futogató feszítőfa adatairól ad információkat, a másik pedig a VLAN2-es feszítőfáról:

admin@NMS:~$ snmpwalk -m +BRIDGE-MIB -v1 -cpublic 172.17.136.250 .1.3.6.1.2.1.17.2
BRIDGE-MIB::dot1dStpProtocolSpecification.0 = INTEGER: ieee8021d(3)
BRIDGE-MIB::dot1dStpPriority.0 = INTEGER: 32769
BRIDGE-MIB::dot1dStpTimeSinceTopologyChange.0 = Timeticks: (491200) 1:21:52.00
BRIDGE-MIB::dot1dStpTopChanges.0 = Counter32: 78
BRIDGE-MIB::dot1dStpDesignatedRoot.0 = Hex-STRING: 00 00 00 16 E0 18 74 00
BRIDGE-MIB::dot1dStpRootCost.0 = INTEGER: 39
BRIDGE-MIB::dot1dStpRootPort.0 = INTEGER: 1
BRIDGE-MIB::dot1dStpMaxAge.0 = INTEGER: 2000
BRIDGE-MIB::dot1dStpHelloTime.0 = INTEGER: 200
BRIDGE-MIB::dot1dStpHoldTime.0 = INTEGER: 100
BRIDGE-MIB::dot1dStpForwardDelay.0 = INTEGER: 1500
BRIDGE-MIB::dot1dStpBridgeMaxAge.0 = INTEGER: 2000
BRIDGE-MIB::dot1dStpBridgeHelloTime.0 = INTEGER: 200
BRIDGE-MIB::dot1dStpBridgeForwardDelay.0 = INTEGER: 1500
BRIDGE-MIB::dot1dStpPort.1 = INTEGER: 1
BRIDGE-MIB::dot1dStpPort.45 = INTEGER: 45
BRIDGE-MIB::dot1dStpPortPriority.1 = INTEGER: 128
BRIDGE-MIB::dot1dStpPortPriority.45 = INTEGER: 128
BRIDGE-MIB::dot1dStpPortState.1 = INTEGER: forwarding(5)
BRIDGE-MIB::dot1dStpPortState.45 = INTEGER: forwarding(5)
BRIDGE-MIB::dot1dStpPortEnable.1 = INTEGER: enabled(1)
BRIDGE-MIB::dot1dStpPortEnable.45 = INTEGER: enabled(1)
BRIDGE-MIB::dot1dStpPortPathCost.1 = INTEGER: 19
BRIDGE-MIB::dot1dStpPortPathCost.45 = INTEGER: 19
BRIDGE-MIB::dot1dStpPortDesignatedRoot.1 = Hex-STRING: 00 00 00 16 E0 18 74 00
BRIDGE-MIB::dot1dStpPortDesignatedRoot.45 = Hex-STRING: 00 00 00 16 E0 18 74 00
BRIDGE-MIB::dot1dStpPortDesignatedCost.1 = INTEGER: 20
BRIDGE-MIB::dot1dStpPortDesignatedCost.45 = INTEGER: 39
BRIDGE-MIB::dot1dStpPortDesignatedBridge.1 = Hex-STRING: 80 00 00 1A C1 56 10 40
BRIDGE-MIB::dot1dStpPortDesignatedBridge.45 = Hex-STRING: 80 01 00 23 AC 33 3B 00
BRIDGE-MIB::dot1dStpPortDesignatedPort.1 = Hex-STRING: 80 DE
BRIDGE-MIB::dot1dStpPortDesignatedPort.45 = Hex-STRING: 80 2D
BRIDGE-MIB::dot1dStpPortForwardTransitions.1 = Counter32: 1
BRIDGE-MIB::dot1dStpPortForwardTransitions.45 = Counter32: 1

admin@NMS:~$ snmpwalk -m +BRIDGE-MIB -v1 -cpublic@2 172.17.136.250 .1.3.6.1.2.1.17.2
BRIDGE-MIB::dot1dStpProtocolSpecification.0 = INTEGER: ieee8021d(3)
BRIDGE-MIB::dot1dStpPriority.0 = INTEGER: 32770
BRIDGE-MIB::dot1dStpTimeSinceTopologyChange.0 = Timeticks: (4994600) 13:52:26.00
BRIDGE-MIB::dot1dStpTopChanges.0 = Counter32: 0
BRIDGE-MIB::dot1dStpDesignatedRoot.0 = Hex-STRING: 00 00 00 16 E0 18 74 00
BRIDGE-MIB::dot1dStpRootCost.0 = INTEGER: 39
BRIDGE-MIB::dot1dStpRootPort.0 = INTEGER: 3
BRIDGE-MIB::dot1dStpMaxAge.0 = INTEGER: 2000
BRIDGE-MIB::dot1dStpHelloTime.0 = INTEGER: 200
BRIDGE-MIB::dot1dStpHoldTime.0 = INTEGER: 100
BRIDGE-MIB::dot1dStpForwardDelay.0 = INTEGER: 1500
BRIDGE-MIB::dot1dStpBridgeMaxAge.0 = INTEGER: 2000
BRIDGE-MIB::dot1dStpBridgeHelloTime.0 = INTEGER: 200
BRIDGE-MIB::dot1dStpBridgeForwardDelay.0 = INTEGER: 1500
BRIDGE-MIB::dot1dStpPort.3 = INTEGER: 3
BRIDGE-MIB::dot1dStpPortPriority.3 = INTEGER: 128
BRIDGE-MIB::dot1dStpPortState.3 = INTEGER: forwarding(5)
BRIDGE-MIB::dot1dStpPortEnable.3 = INTEGER: enabled(1)
BRIDGE-MIB::dot1dStpPortPathCost.3 = INTEGER: 19
BRIDGE-MIB::dot1dStpPortDesignatedRoot.3 = Hex-STRING: 00 00 00 16 E0 18 74 00
BRIDGE-MIB::dot1dStpPortDesignatedCost.3 = INTEGER: 20
BRIDGE-MIB::dot1dStpPortDesignatedBridge.3 = Hex-STRING: 80 00 00 1A C1 56 10 40
BRIDGE-MIB::dot1dStpPortDesignatedPort.3 = Hex-STRING: 80 D9
BRIDGE-MIB::dot1dStpPortForwardTransitions.3 = Counter32: 1

Huawei switchek portkiosztása

2011-11-15T21:26:00.009+01:00

Vegyes környezetben dolgozó networkösök a megmondhatói, hogy mennyi idegeskedés, bohóckodás lenne megspórolható, ha a gyártók ugyanolyan portkiosztást használnának az eszközeiken. Nyilvánvaló, hogy aki világéletében Cisco-n dolgozott, nem is érti a problémát, ott tiszta sor, hogy amióta Cisco a Cisco, a switcheken a portok számozása fentről lefelé, oszlopokban növekszik, az oszlopok pedig balról jobbra haladnak:

1  3  5  ...  47
2  4  6  ...  48

Kb. ugyanígy megy a Nortel, az Avaya, a HP vagy éppen a H3C eszközökön. De nem minden gyártó gondolkodik így. Ott van, illetve volt, példának okáért a 3Com, ahol a sor erősebb szervezőelv mint az oszlop:

1  2  3  ...  24
25 26 27 ...  48

És persze vannak ennél is hajmeresztőbbek, mint amilyen mondjuk a Huawei, ahol kíméletlenül, a legősibb tízéves holmijaiktól a legújabb eszközökig az alábbi logika alapján tolják:

2  4  6  ...  48
1  3  5  ...  47

No, ehhez még adjuk hozzá az emberi gyarlóságot, és ezekkel a rém egyszerű dolgokkal lehet aztán szopni vég nélkül, különösen akkor, ha vakon dolgozunk és mondjuk telefonon, idegen nyelven instruáljuk a másik végen lévő kollégát, vagy fordítva: ha éppen minket ugráltatnak. Valamilyen szoftverhibából eredően nekem például a "Nortel" márkanévhez időről időre a 3Com portkiosztás kapcsolódik, ha nem koncentrálok eléggé, és volt már olyan, hogy egy több VLAN-os Layer 2-es site-to-site VPN-t nulláról újrakonfiguráltam mindkét oldalon, mire végre beláttam, hogy csupán egy lukkal arrébb kellett volna próbálkozni. Persze tudja az eszével az ember, meg oda is van írva, sorban, számokkal, még világít is, ám hiába: mégsem kettes az a port, hanem hármas. A Huawei portkiosztására viszont szerintem nincs mentség, akármennyire is megtanultak jó eszközöket építeni, alulról kezdeni a számozást nem finom. Egy ideig azt gondoltam, hogy biztos a kínai írásrendszerben ez a tradicionális irány, mármint a lentől felfelé történő írás, de nem, így nem marad más, nyilvánvalóan a puhány nyugatiaknak szánt fricska az egész, és a belpiacos eszközök rendesen vannak számozva. :)

Egy kis érdekesség az SFP kompatibilitásról

2011-11-11T19:07:00.012+01:00

Ma egy régóta porosodó 3Com 5500EI (3CR17161-91) access switchen frissítettem szoftvert, a legutolsó kiadott szoftververzió ehhez a hardverhez 2010 júniusban jött ki (3Com OS v.3.3.2ep10), már a HP-től. A szoftverezés után még gyorsan leellenőriztem, hogy az SFP bővítőhelyek mindegyike működik-e, egy 1000BaseT modult bedugtam az első SFP slotba, majd kötöttem egy csinos hurkot az SFP modulos port és a sima port1 között, hogy lássam, feljön-e a LED zöldben, illetve ezt a műveletet a másik három SFP helyen is megismételtem. Aztán csak úgy poénból bedugtam egy Cisco SFP modult a switchbe (GLC-SX-MM), amire egyből jött egy ilyen üzenet a konzolon:

<5500-EI>
%Nov 11 17:39:55:667 2011 5500-EI L2INF/5/PORT PHY TYPE CHANGE:- 1 -
GigabitEthernet1/0/25 is 1000_BASE_SX_SFP

Nézek, mint a luki nyúl, nem éppen erre számítottam. Ilyen eddig szerintem nem volt, meg úgy általában a nagy gyártók ügyelnek arra, hogy az SFP moduljaik ID-jai különbözzenek annyira, hogy ne legyenek egymással kompatibilisek, szóval alig akartam hinni a szememnek. Nosza, gyorsan bepattintottam egy másik SFP slotba egy standard 3Com SX modult (3CSFP91), elővettem egy LC-LC kábelt, összekötöttem, és mindkét port feljött, sőt forgalom is volt rajta, olyannyira, hogy az STP el is vágta a hurkot, szóval biztosan működik:

<5500-EI>display stp brief
MSTID     Port                   Role STP State    Protection
   0     GigabitEthernet1/0/25    DESI FORWARDING     NONE
   0     GigabitEthernet1/0/26    BACK DISCARDING     NONE

(*) means port in aggregation group

<5500-EI>

Besza-behu, vérszemet kaptam, elkezdtem túrni egyéb SFP modulok után, találtam Nortel SX modult (AA1419013), működik ez is. Avago SX HFBR-5710LP: megy, a D-Link DEM-311GT v.E1 szintén működik. Többféle SX modul nem volt a kezem ügyében, de akadt még két HP J4859B is, ezek LX-esek, és ezek is mennek. Létezik, hogy a HP kiszedte a korlátozást a megörökölt 3Com cuccokból esetleg azért, hogy a saját moduljait szállíthassa a legacy rendszerekhez? Érdekes. Emlékeim szerint, amikor először csináltam ilyen különböző gyártós modulcsereberét, az nem volt valami nagy sikertörténet. Annyira mélyen azért sosem merültem el ezekben a Layer 1 kompatibilitási dolgokban, hogy tudjam, melyik gyártótól érdemes modulokat venni, azonos optikai szabványon belül (pl. SX vagy LX) melyik beszállítót érdemes választani, nagyjából mindig mindenhez az eredeti gyártó hivatalos moduljait használtam. No, mindegy, így poszt vége felé már elfogyott a lendület. Annyira már lehet, hogy nem is érdekes :)

Update (2011-11-15): kipróbáltam 3Com 4500-ason és 5500G-n régebbi szoftverekkel is, a jelek szerint 3Com utolsó szériái mindenevők, legalábbis a switchek azok. Jó tudni.

Parancssori SNMP eszközök (4.) - snmpset

2011-10-31T15:43:00.012+01:00

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

2011-09-19T17:17:00.002+02:00

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

2011-09-06T23:18:00.017+02:00

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

2011-08-30T14:12:00.009+02:00

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

2011-08-29T21:50:00.019+02:00

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

2011-08-26T08:11:00.002+02:00

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 ha 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

2011-08-25T10:33:00.004+02:00

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

2011-08-19T15:56:00.003+02:00

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

2011-08-18T14:52:00.004+02:00

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

2011-08-17T22:39:00.003+02:00

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

2011-08-16T12:43:00.008+02:00

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.

Nortel bemelegítés

2011-06-30T22:55:00.024+02:00

Mostanában barátkozgatunk, én meg a kikukázott Nortelek. Azért nem egy felhőtlen kapcsolat ez, már az elején sem volt minden rendben. Életem első Nortel eszköze egy viszonylag friss, jelenleg ugye már Avaya márkanév alatt futó Nortel 5510-24T volt kb. két hete, előtte soha semmilyen Nortel kütyüt nem piszkáltam, leszámítva egy Nortel 1010-es VPN routert, ami ugyan nem a cégé volt, de zörgött a ventillátora, ezért belenéztem, és kiderült, hogy egy Celeron 300-as van benne (persze, hogy mások is észrevették már ezt: van, aki Slackware-t futtat rajta). De vissza a tárgyhoz, szóval az első Nortel switchem marhára nem akart konzolon életjelet adni, próbálgathattam én sebességet állítgatni vagy bármi mást, nem sok visszajelzést adott. Persze ilyenkor elkezd guglizni az ember, de mindenütt csak annyit írtak, hogy 9600/8/N/1, szóval mennie kellett volna. A kábelemben is biztos voltam, de azért kipróbáltam egy Cisco AP-n, az természetesen azonnal működött a Minicomban. Az 5510-es sem úgy nézett ki, mint amit ütöttek-vertek volna mindenféle kiégett adminok, szóval gyanús volt, hogy valami disznóság van a konzolkábel körül, lehetséges, hogy annyira különc a Nortel, hogy más lábkiosztást használjon?

Van a fiókomban egy-két apróság, épp az ilyen estekre, többek közt olyan RJ45-DB9 átalakító is, ami nem megy a "rendes" eszközökkel, na majd most bizonyíthat, gondoltam. Így is lett, ez az Avocent Cyclades out-of-band konzol appliance-hez való RJ45-DB9 átalakító mindent megoldott a Nortel 5510-zel kapcsolatban, és még csak forrasztani sem kellett.

A Cisco, HP, 3Com, Huawei, Fortigate stb. eszközökhöz való DB9 átalakító így néz ki (3-4. oszlop, további részletek a cisco.com-on):

Console Port (DTE)	RJ-45-to-RJ-45 Rollover Cable		RJ-45-to-DB-9 Terminal Adapter	Console Device
Signal	RJ-45 Pin	RJ-45 Pin	DB-9 Pin	Signal
RTS	1	8	8	CTS
DTR	2	7	6	DSR
TxD	3	6	2	RxD
GND	4	5	5	GND
GND	5	4	5	GND
RxD	6	3	3	TxD
DSR	7	2	4	DTR
CTS	8	1	7	RTS

A működő RJ45-DB9 átalakító (Cyclades) lábkiosztásáról némi multiméteres bohóckodás után következőt derítettem ki:

RJ-45 PIN	DB-9 female
8	4
7	4
6	3
5	7
4	5
3	2
2	1, 6
1	8

Igazából csak az RJ45 3, 4, 6-os (DB9 2, 5, 3) lábakra van szükség, és ha összevetjük a legfelső táblázattal, akkor láthatjuk, hogy a Cisco eszközökön is ugyanezek a lábak vannak használatban, csak épp a TXD helyett RXD, illetve RXD helyett TXD van rákötve, a Nortel Install Guide szerint ugyanis a Nortel eszközökön a konzol port kivezetések a következők szerint alakulnak:

PIN #	Signal
1	Not used
2	TXD
3	RXD
4	Not used
5	GND
6	Not used
7	Not used
8	Not used
9	Not used

A LAN mint szolgáltatás

2011-06-03T00:14:00.010+02:00

Már az előző poszt is esélyes volt a legalja címkére, de ott a mókolási faktor sokat emelt rajta, ez viszont tipikus legalja lesz, valahogy nálam ez gyakran a kiszervezéssel párosul. Van két telephelyünk messze-messze, ahol a LAN-t eszközöstül, mindenestül szolgáltatásként vesszük egy helyi IT-s cégtől. Ez teljesen rendben lévőnek hangzik, elvileg ugye a szerződésben definiálva vannak a szolgáltatási szintek (SLA), reakcióidők, felelősök stb. ezt a szolgáltatást legalább öt éve igénybe vesszük, bizonyos időközönként automatikusan megújul, az azért mindenesetre furcsa, hogy a pontos részleteket a network team nem ismeri, illetve az utóbbi időkben kiderültek érdekes dolgok. Mentségünkre szóljon, hogy senki nincs már a cégnél, akinek köze lehetett ennek a szerződésnek megkötéséhez, és valahogy a pozíciók átadása-átvétele körül elsikkadtak a részletek.

Az egyik ilyen dolog, hogy a szolgáltató reakciói alapján meg voltunk győződve, hogy legjobb esetben is csak 5/8-as támogatást várhatunk tőlük nem túl sebes megoldási időkkel. Bizonyos WAN átszervezések kapcsán az egyik említett telephelyen szükség volt némi LAN változtatásra, új VLAN-ok, link subnetek, ilyesmi, és sehogy nem tudtuk a karbantartási ablakot beletuszkolni az 5/8-as munkaidőkeretbe. Szóval már épp azon gondolkodtunk, hogy megkérjük a LAN szolgáltató céget, hogy vállaljanak az 5/8-as időkereten kívül munkát, amikor a főnököm főnöke közölte a szerződésre hivatkozva, hogy bizony 7/24 Gold++++ supportunk van, bármikor kérhetünk módosításokat.

Voltak azonban korábban is gyanús jelek: tavaly bekértem tőlük mindkét telephelyről a layer2-es dokumentációt, mert semmit nem találtam ezekről a site-okról, de azt válaszolták, hogy ilyesmi nekik sincs, viszont tudnak készíteni, ha kérjük. Különösebb gondolkodás nélkül rávágtam, hogy kérjük, bár már akkor sem értettem, hogyan tudnak támogatni olyasmit, amiről alapvető dokumentációk hiányoznak. No, el is készült a kért anyag, mivel nem túl nagyok a telephelyek, 2-300 port mindkettő, a layer2-es ábrák eszközökkel, VLAN színekkel, IP-kkel együtt is csupán 2 oldalt tettek ki. Egy hónap múlva jött egy belsős telefon, hogy milyen szolgáltatást kértem ettől a cégtől, és hol van az általuk küldött dokumentáció, merthogy dokumentáció címén egy 1000 euró + forgalmi adós tételünk van. Mondanom sem kell, azóta is nagy becsben tartjuk azt a PDF-et, mind a két oldalát.

Ezek után már azon cseppet sem csodálkoztam, amikor jöttek az újabb telefonok, hogy a konfiguráció módosításáért, akkor is, ha az csak egyetlen sor, száz eurót számolnak fel, a több ezer eurós havidíjon felül. Ilyenből is gyűjtöttünk egy párat az elmúlt időszakban.

A legjobb viszont mostanában történt, az egyik ilyen kiszervezett LAN-os telephelyen a felhasználók elkezdtek panaszkodni, hogy szakadozik a kapcsolatuk, hálózati problémáik vannak. A WAN hibakeresés semmilyen gondot nem mutatott, sőt, WAN szempontból kivételesen jó helyzetben van az említett telephely mind sávszélességet, mint késleltetést illetően, csomagvesztésről pedig gyakorlatilag nem volt historikus adat a monitorozó rendszerben, így hamar előkerült a LAN, mint lehetséges hibaforrás. Igen ám, de mi nem férünk hozzá az ottani eszközökhöz, így hibajegyet nyittatunk a szolgáltatónál, részletes hibajelenségekkel, időpontokkal, user kontakt információkkal stb. Ez történt egy pénteki napon. Aznap a hibajegy megnyitásán túl sokra nem jutottak (7/24-es support, néhány órás elhárítási idővel!). A következő hét elején már állt a bál, mert a probléma még mindig élt, megoldás sehol, mi meg csak a kezünket tudtuk széttárni, hiszen az adott telephelynek még a közelében sincs networkös, az eszközöket pedig nem akartuk újraindíttatni hátha van valami a logokban. Ekkor már direkben megadtuk a szolgáltató elérhetőségét a felhasználóknak is, és végül sikerült nekik szerdára (!) kihívatni egy hálózati mérnököt. A mérnök kijött, szétnézett a rendezőhelyiségekben, tett néhány megjegyzést arra vonatkozólag, hogy 10+ éves eszközökön fut a LAN (amit ők szolgáltatnak), és hogy látott egy-két kósza hub-ot is, meg hogy milyen kevés log-ot tudnak tárolni ezek az öreg eszközök, majd elment úgy, hogy nem volt megoldás. Naivan azt gondoltam, hogy átnézi majd legalább a trönk portok konfigurációit, az STP beállításokat, vagy végez valamilyen tesztet, hoz esetleg gyártóspecifikus szoftvert, amivel adatokat gyűjt, leszűkíti a probléma forrását bizonyos eszközre, eszközökre, vagy hogy egyáltalán csinál valamit, bármit. A végén a mérnök távozása után maguk a felhasználók lokalizálták a probléma forrásaként az egyik switchet, majd arról átköttettek mindent az ottani IT-s sráccal más eszközökre. Máig nem tudjuk, mi baja lehetett annak a switchnek. Arra azért kíváncsi lennék, mennyit fizethettünk a kiszállásért, csak gyanítom, hogy ez ismét az ezer eurós kategória lehetett...

Ez az esemény viszont végre beindított valamit: döntés született arról, hogy ennek a cégnek mennie kell, és insourceolva lesz a LAN, mert ezt a szolgáltatási szintet lazán megugorjuk belső erőforrásokkal, több országnyi távolságból is. Azt már végképp nem értem, hogy miképp és miért, de mindkét telephelyen kiderült, hogy raktárban állnak öt év körüli Nortel eszközeink az 5000-es szériából, 8000-es szériából, nem is kevés, összesen kb. 1300 portnyi, szóval van miből kukázni -- enyém a megtisztelő feladat, hamarosan utazhatok. Addig is fel kell szívnom magam Nortel (mostanában Avaya) CLI-ből, legalább az olyan alap témákban mint a VLAN, STP, naplózás, SNMP, port security, basic routing, DHCP relaying, stacking, firmware kezelés, mert annyira nem mozgok otthonosan Nortel/Avaya fronton, viszont néhány hét múlva már rutinosan kell mennie.

Hogyan készüljünk fel hat nap alatt az IPv6 napra?

2011-06-02T11:35:00.002+02:00

Régi kedvencem Ivan Pepelnjak szlovén kolléga, illetve ez így túlzás, hogy kolléga, hiszen ő több Cisco Press-es szakkönyv szerzője, igazi networkös veterán, és semmiképp sem állunk egy szinten. Mindenesetre a blogját szeretem olvasgatni, és a mai posztja egyértelműen olyan, ami szerintem a magyar szakmabeliek számára is tanulságos: hogyan tákoljunk össze valamit a soron következő IPv6 napra kevesebb mint egy hét alatt, ha a PR-esek hirtelen úgy döntenek, hogy részt kell vennünk a hype-ban?

Az Ivan posztjában belinkelt prezentációból a kedvencem az F5 Big-IP-s dolog, az F5-öt gondolom nem nagyon kell bemutatni, load balancer és data center interconnection témában igen otthonosan mozgó cégről van szó, akik mostanában elérhetővé tették fontos termékük, az F5 Big-IP Local Traffic Manager Virtual Editionjét (VE) VMware infrastruktúrára, és ebből a VE-ből elérhető egy trial kiadás (korlátozás: 90 nap, 1Mb/s áteresztőképesség).

No, az egészben az a lényeg, és ez az Iván által a túléléshez javasolt receptek egyike, hogy használjuk a Big-IP-t IPv6-to-IPv4 átalakításra. A rendszer egyébként képes load balancingra IPv6-ról IPv4-es szerverek felé is (nem akarok hülyeséget mondani, de mintha tavaly valamilyen előadáson hallottam volna, hogy a Facebook F5 Big-IP vasakkal biztosítja az IPv6-os jelenlétét). Szóval a VE trialt csak a meglévő IPv4 szerverek elé kell tenni, IPv6-on csatlakoztatni a publikus hálózathoz, majd a megfelelő AAAA rekordokat felvenni DNS-ben még június 8-a előtt. Gányolás a legfölsőbb szinteken, lehet, hogy megért volna egy "legalja" címkét is :)

32 bitnél hosszabb IPv4 kompatibilis címek: A+P címzés

2011-05-30T00:03:00.006+02:00

Az előző posztban hivatkozott egyik szerző, Steven M. Bellovin publikációi közt egy érdekes dologra akadtam: A better approach than carrier-grade-NAT. IPv4 exhaustion / IPv6 témakörben nagyjából mindenki arra számít, hogy előbb-utóbb, dual stackkel vagy anélkül, de megjelennek a Carrier Grade NAT-ok (CGN), azaz a szolgáltatók a saját hálózatukon közbeiktatnak egy NAT lépést, hogy minél kevesebb publikus IPv4 cím kerüljön közvetlenül felhasználóikhoz. Bár ez nem ördögtől való ötlet, azért annyira nem is kellemes dolog. Gondoljunk csak bele, hogy amikor egy NAT-on osztozunk esetleg több száz egyéb felhasználóval, milyen kérdések vetődhetnek fel:

Limitált számú párhuzamos session nyitására lesz lehetőségünk, valószínűleg kevesebbre, mint CGN nélkül, hiszen a CGN eszközön rendelkezésre álló TCP/UDP portok száma számos felhasználó közt oszlik szét.
Az UPnP, port forwarding (DNAT) felejtős, hacsak nem tudjuk meggyőzni a szolgáltatót, hogy nekünk ezt vagy azt a külső portot adja át fixen, ami lássuk be, nem túl valószínű.
A CGN külső IP-je egy esetleges rossz belső CGN szomszédság miatt felkerülhet ilyen-olyan tiltólistákra.
Nehéz kérdés a CGN esetén a nyomon követhetőség a végfelhasználóig, bár ez elsősorban nem az ügyfelek, hanem a szolgáltatók problémája, mindenesetre az ügyfelek megbízható azonosítása érdekében igen gyakori CGN NAT tábla mentésekre lenne szükség.

De vajon hogyan élhetnénk túl az IPv6 elterjedéséig hátralévő időszakot? Hogyan lehetne többet kihozni az IPv4-ből? Van-e jobb módszer a CGN-nél? Az belinkelt tanulmány szerzői azzal az ötlettel álltak elő 2008-ban, hogy ki lehetne bővíteni a IPv4 címtartományt bitek átcsoportosításával a TCP/UDP portszámokból. Ez lenne az address + port címzés (A+P), ahol a hálózati címbe beleszámítana a TCP vagy UDP forgalom multiplexelését lehetővé tevő portszám mező valahány bitje.

Az ötlet persze zseniális, de alapvetően patkolás, nem megoldás, és azon túl, hogy ez is igényel változásokat mind CPE oldalon, mind a szolgáltatói eszközökben, a legtöbb CGN-es kérdést nem tudja megoldani. Előrelépés egyedül a DNAT témában lenne, hiszen az A+P-vel minden végfelhasználóra juthatna valamekkora fix szeletke az átcsoportosított portszám bitektől függően, amellyel szabadon rendelkezhetnének. Ugyanakkor nem választhatnának akármilyen portot a kívülről elérhető szolgáltatások számára, hiszen az adott szolgáltatáshoz tartozó well-known portok egyáltalán nem biztos, hogy abba a szeletkébe esnek, ami az adott felhasználónak jutott.

Az A+P címzés inkább tűnik egy érdekes ötletnek, mint ténylegesen megvalósítható dolognak, jelzi ezt az is, hogy az elmúlt pár évben nem volt nagy visszhangja a javaslatnak, összességében mégis szórakoztató volt végiglapozgatni, ki gondolta volna, hogy IPv4 címzés témában még lehet újat mondani?

NAT detektálás és szűrés

2011-05-29T18:25:00.017+02:00

Bizonyára másokban is felmerült már, hogy miképp lehet egyszerűen kiszűrni a NAT-os eszközök forgalmát. Általában ezek adminisztratív szemszögből vizsgálva elég nyűgös holmik, amelyekkel akár a RADIUS authentikációt vagy az access switchek port security beállításait (pl. hogy egy portról csak egy MAC címet tanuljon meg a switch) is át lehet verni.

A NAT a külvilág számára nem transzparens, a külső szemlélő számára egyetlen MAC címről és egyetlen IP-ről érkezik minden NAT mögötti hostról a forgalom, maga a NAT-ot végző host persze lehet, hogy minden biztonsági feltételnek megfelel, a NAT mögötti eszközök azonban általában nem. A NAT-os eszközt sem hálózati szakember szokta konfigurálni, gyakran csak arról van szó, hogy a biztonságra nem túl sokat adó felhasználók -- rosszabb esetben kollégák -- szeretnének egyszerűbben hozzáférni bizonyos erőforrásokhoz, így összekötnek egy SOHO IPv4 NAT routerrel két hálózatot, például a vendégek számára fenntartott internetet subnetet mondjuk valamelyik belső subnettel. Így a SOHO routeren keresztül, ha az tud statikus route-okat (szinte mind ilyen) egyszerre férnek hozzá belső erőforrásokhoz valamint a Facebookkal, Napiszarral, akármivel felturbózott internethez. Máskor az egyetlen MAC címre redukált hozzáférést többszörözik meg egy NAT-os host segítségével, és akkor még nem is beszéltünk olyan gondokról, amikor a NAT-hoz wi-fi is társul. Akárhogy is, azért az ilyesmi előbb-utóbb valakinek feltűnik, rosszabb esetben a SOHO router DHCP szervere "elszabadul", vagy éppen az válik érdekessé, hogy egy-egy host milyen gyanúsan sokat forgalmaz, és akkor derül ki róla, hogy NAT-ol még jó pár egyéb host számára.

A NAT detektálása külön művészet, több módszer létezik rá, egy dolog azonban közös bennük: nagyjából mind megbízhatatlan. Nyolc-kilenc éve jelentek meg a NAT detektálásról az első komolyabb tanulmányok, az egyik sokat hivatkozott publikáció a "Detecting NAT devices using sFlow", melyben a szerző (Peter Phaal) rögtön két módszert is bemutat. Az IP TTL alapú módszer igen egyszerű, abból indul ki, hogy az egyes OS-ek TTL kezdőértéke jól tudható, a mostanában használt Windowsok például 128-as TTL-lel indítják útnak a csomagjaikat, a Linuxok 64-gyel (egyéb default TTL értékek itt), így a hálózatunk topológiájának ismeretében viszonlag egyszerű meghatározni, hogy a topológia adott helyén milyen TTL-eket kellene látnunk a IP fejlécekben. Nyilván, ha ezeknél épp eggyel kevesebbet látunk, az beszédes, és könnyen lehet, hogy egy NAT routeren áthaladva lett a TTL mező értéke eggyel kisebb, mint a normál hostokról származó csomagok TTL mezejének értéke.

A másik módszer az IP ID mező értéke alapján történő statisztika készítése, amivel meg lehet becsülni, hogy mennyi host található egy-egy NAT eszköz mögött. Az IP ID módszer azonban leginkább Windows rendszerekkel működik jól, ugyanis ezeken kiszámítható az IP ID mező kezelése, a rendszer mindig eggyel növeli az értéket. Linuxon sessiononként random a kezdőérték, míg például az OpenBSD alatt minden egyes csomagban random az IP ID értéke. Az IP ID mezőre építő megoldásról egyébként külön értekezik a Columbia Egyetem egyik professzora, Steven M. Bellovin is az "A Technique for Counting NATted Hosts" című munkájában.

További módszer az eszközeinken áthaladó forgalmon végzett passzív OS fingerprinting, ennek lényege, hogy egy adott host nem fog rövid időn belül különféle OS-ekre jellemző tulajdonságokat mutatni, amennyiben mégis így történik, valószínű, hogy NAT-os eszközről van szó. Az OS fingerprinting és az IP ID módszer hátránya, hogy ezek sokkal inkább illenek mondjuk egy auditor eszköztárába, viszonylag erőforrásigényesek, ráadásul nem lehet őket real time szűrésre felhasználni. Ezzel szemben az IP TTL módszer egyszerű, mint az ék, és ha ismerjük a ránk bízott hálózatokat, akár real time szűréseket is be tudunk vezetni, bízva abban, hogy felhasználóink nem birizgálják a TTL kezdőértéket. IOS-ben extended ACL szükséges a TTL-re építő szűréshez, Linux alatt, a Netfilterben pedig külön modul (-m ttl) áll rendelkezésünkre.

Végül vannak természetesen törekvések komplex módszerek kialakítására is, amelyekben a fenti eljárások mindegyikét használják egymással párhuzamosan, hogy megbízhatóbb eredményeket kapjanak, egy ilyenről olvashatunk a "NetFlow Based System for NAT Detection" című szösszenetben.

BGP neighbor ellenőrzés FortiOS alatt

2011-05-23T22:48:00.003+02:00

Igen rugalmas a Fortigate eszközök webes felülete, valóban szinte mindent el lehet intézni a webGUI-n keresztül, a BGP routeolás épp a kivételek közé tartozik, legalábbis keresgéltem egy ideig menüben rejtett opciókat, amivel több információt ki lehetne szedni a BGP-ről, aztán persze, mint oly sok egyéb esetben is, a vége CLI lett. Érdekes különben összevetni, hogy mennyire hasonlít az IOS show ip bgp neighbors x.x.x.x kimenetére a parancs FortiOS alatti párja:

FORTIGATE $ get router info bgp neighbors 10.10.10.10

BGP neighbor is 10.10.10.10, remote AS 65200, local AS 65100, external link

  BGP version 4, remote router ID 10.1.1.1

  BGP state = Established, up for 05w5d16h

  Last read 00:00:28, hold time is 180, keepalive interval is 60 seconds

  Configured hold time is 180, keepalive interval is 60 seconds

  Neighbor capabilities:

    Route refresh: advertised and received (old and new)

    Address family IPv4 Unicast: advertised and received

    Address family IPv6 Unicast: advertised and received

  Received 295328 messages, 159 notifications, 0 in queue

  Sent 297947 messages, 170 notifications, 0 in queue

  Route refresh request: received 0, sent 0

  Minimum time between advertisement runs is 30 seconds

 For address family: IPv4 Unicast

  BGP table version 7017, neighbor version 6997

  Index 0, Offset 0, Mask 0x1

  Community attribute sent to this neighbor (both)

  Outbound path policy configured

  Route map for outgoing advertisements is *SET-COMMUNITY-OUTroot

  1 accepted prefixes

  66 announced prefixes

 For address family: IPv6 Unicast

  BGP table version 1, neighbor version 1

  Index 0, Offset 0, Mask 0x1

  0 accepted prefixes

  0 announced prefixes

 Connections established 44; dropped 43

Local host: 10.10.10.1, Local port: 7864

Foreign host: 10.10.10.10, Foreign port: 179

Nexthop: 10.10.10.1

Nexthop global: ::

Nexthop local: ::

BGP connection: non shared network

Last Reset: 05w5d16h, due to BGP Notification sent

Notification Error Message: (CeaseUnspecified Error Subcode)

A legfontosabb sorok egy az egyben az IOS kimenetét imitálják. A BGP peer IP-je után, szintén az IOS-es mintára, biggyeszthetünk mindenféle kiegészítőket, például, hogy mit hirdetünk a szomszéd felé, mit kapunk tőle, stb.:

FORTIGATE $ get router info bgp neighbors 10.10.10.10 ? 
<WORD>    (advertised-routes|received prefix-filter|received-routes|routes)

NAT444 dual stack modell az átálláshoz

2011-05-20T00:11:00.005+02:00

Újabb modell az IPv6 átálláshoz, ami jelenleg nincs még fent a Wikipedián sem: NAT444. Persze annyira azért nem új (januári), és forradalmi dolgokat nem érdemes várni tőle, leginkább maga az elnevezés volt újdonság nekem még most, májusban is. Ahogy az is, hogy a NAT64 mintájára egyre több helyen lehet olvasni NAT44-ről is, ami nem más, mint a megszokott IPv4 NAT, aminek ugye mindkét oldalán IPv4-es címek vannak, innen a 44. No, a NAT444 lényegében ugyanez, csak kétszer: az IPv4-es csomagoknak két NAT táblán kell átküzdeniük magukat, az első a szolgáltató által biztosított IPv4/IPv6 dual stack végberendezés, a második pedig az LSN (Large Scale NAT) vagy más néven CGN (Carrier Grade NAT) eszköz a szolgáltatónál. Rendes NAT444-es ábra sem volt sehol, így rajzoltam egyet én:

Bár nincs belső információm a hazai szolgáltatóktól, azért szemernyi kétségem sincs afelől, hogy ebből a modellből az LSN/CGN rész előbb-utóbb meg fog valósulni az otthoni felhasználók számára, vagy akár olyasmit is elképzelhetőnek tartok, hogy a szolgáltatók drágábban adják majd az LSN/CGN nélküli előfizetéseket mint a szolgáltatói NAT-os és/vagy IPv6-os előfizetéseket. Ami viszont a dual stack végberendezések (SOHO router) tömeges elterjedéseset illeti, itt azért vannak kétségeim, évtizedes távlatban bizonyára reális lehet, hogy a felhasználók jelentős százalékánál megjelennek ilyen eszközök.

Visszatérve a NAT444-re: komoly hátránya, hogy viszonylag bonyolult CPE eszközre van szükség ahhoz, hogy a végfelhasználó hozzáférhessen mind az IPv4-es, mind IPv6-os erőforrásokhoz (ez az átmenet alatt az alapvető elvárás), ráadásul ehhez a végfelhasználó eszközein (PC, notebook, egyéb kütyük) is dual stack kell, hogy fusson.

BGP gondok Juniper és Fortigate eszközök közt

2011-05-11T10:11:00.002+02:00

Másfél hete volt egy igen kellemes leállásunk. Az ERP rendszerünk ki van szervezve külső szolgáltatóhoz, ahová rendeltünk egy bérelt vonalat és van egy backup VPN tunnelünk is. Ez elvileg ugye teljesen kerek, a bérelt vonal és a VPN-hez használt internet két különböző szolgáltatótól jön, BGP-t futtatunk mindenhol, a megoldás ki volt tesztelve átadáskor, gond egy szál sem, minden ment, a BGP peerek látták egymást bérelt vonalon és a VPN-en is, a bérelt vonal megszakításakor a forgalom gond nélkül átállt a backup VPN-re, ráadásul a peer-ek maguk is redundáns eszközök, szóval nagyjából tankönyvi megoldás volt, látszólag.

Na, ehhez képest két hete pénteken világvége volt, megállt az ERP site felé a bérelt vonal, mert valahol Észak-Európában elvágtak egy optikát, a backup VPN tunnel pedig hiába működött, az ERP site-ról nem jöttek a BGP frissítések, így nem volt elérhető az ERP rendszerünk.

Villámgyors megoldásként néhány jól irányzott statikus route jól jött volna, de a site-to-site VPN ki van szervezve (network teamen kívüli, felülről jött döntés), a VPN eszközeinkhez kizárólag read only hozzáférésünk van, csak a VPN szolgáltató helpdeskjén keresztül kérhetők módosítások. A másik oldal, az ERP site szintén ki van szervezve, az ottani VPN eszköz része az ERP szolgáltatáscsomagnak, szintén csak (egy másik) helpdesken keresztül érhető el. Na most el lehet képzelni, hogy micsoda tempóban oldódnak meg az ilyen helpdesk kérések, főleg ha két, egymástól független szolgáltatónak kell együttműködnie. Nagyjából mire megjavult a bérelt vonal, addigra állt össze a BGP peering is az ERP site és a VPN hubunk közt. A network team meg begyűjtött egy kb. hatórás ERP leállást.

Az az érdekes, hogy senki nem tudja, mitől állt meg a backup VPN-en a BGP. Illetve nem is állt meg teljesen, a VPN hubtól érkező prefixeket ERP site-on futó eszköz látja, viszont az ERP site-ról nem érkezik semmi a VPN hubhoz. A VPN hub egy Fortigate 620B cluster, az ERP site-on pedig valamilyen Juniper holmikon futó virtuális eszközöket kaptunk VRRP-ben. Az ERP-s network supportosok szerint a Juniper virtuális eszközünkön nincs olyan parancs, mint az IOS-ben show ip bgp neighbors x.x.x.x advertised-routes, így nem tudják megnézni, hogy mit küldenek adott BGP peer felé. A Forigate eszközön pedig eltűnt a neighborök közül a Juniper eszköz.

Megoldás gyanánt mind a Fortigate mind a Juniper eszközökön újraindították a BGP processzt, amitől a dolog megjavult (tehát nem tűzfalas gond volt), de nem vagyok meggyőződve arról, hogy ez hosszú távon is működőképes lesz. Ma kaptunk backup VPN éles tesztelésre egy kis időt, és ma éppen minden működött úgy, ahogy kell, de nem volt igazán meggyőző az ERP szolgáltatónknál dolgozó networkös kolléga, aki a múltkori állás okaival kapcsolatban annyit mondott, hogy "bad luck". Statikus route lesz a vége, már látom előre.

PPPoE VLAN interfészen Vyatta alatt

2011-05-09T22:17:00.005+02:00

Délután hosszasan vesződtem azzal, hogy egy VDSL modem mellé bekonfiguráljak egy Vyatta 6.2-es rendszert. Nem voltak nagy igények, csak a szokásosnak mondható dolgok, SPI tűzfal, NAT, DHCP, ilyesmi. Az egyetlen szokatlan dolog, hogy a Vyatta rendszerben egyetlen NIC-en, VLAN-okkal szerettem volna megoldani a LAN és a WAN kapcsolatot. Az interfész konfiguráció tehát első blikkre kb. így nézett ki:

interfaces {
    ethernet eth0 {
        duplex auto
        hw-id aa:aa:aa:aa:aa:aa
        speed auto
        vif 2 {
            pppoe 0 {
                connect-on-demand
                default-route auto
                mtu 1492
                name-server auto
                password DSLpassword
                user-id DSLusername
            }
        }
        vif 3 {
            address 192.168.0.1/24
        }
    }
    loopback lo {
    }
}

Mondanom sem kell, nem ment. De hát mi a fene baja lehet? A modem elérhető volt a 2-es VLAN-on, a LAN oldalon is rendben volt a 3-as VLAN, a tesztkliens LAN oldalon megkapta DHCP-vel a szükséges adatokat a Vyattától, de valamiért a PPPoE nem jött össze. Persze rögtön kipróbáltam, hogy közvetlenül a modembe dugom a tesztklienst: csatlakozott. Jó, akkor lépjünk tovább, a tesztkliens VLAN2-ben, switchen keresztül vajon csatlakozik-e? Persze, így is működik. Hm... vajon a Vyatta-hoz használt trönk port jó? VLAN2 és VLAN3 is tagged, ahogy a Vyattán konfiguráltam? Ezzel sem volt gond. Akkor talán a Vyatta rendszerben használt NIC problémás? Neeem, simán kezeli a VLAN-okat, nincs vele gond.

Turkáltam a Vyatta doksikban, ez, ha lehetséges, még kevesebb eredménnyel zárult, hiába van a rendszerhez 1000+ oldal dokumentáció, arról, hogy Ethernet interfészen hogy lehet PPPoE-t beállítani, nem sokat mesélnek, a DSL-es példák is egytől egyig az előfizetéses SE verziójú Vyattában használható DSL modemkártyák beizzításáról szólnak, PPPoE over VLAN sehol.

Rendben, gondoltam, ha nincs más, akkor belenézünk tcpdumppal. Igen ám, de mibe? Kiderült, hogy a fizikai interfészen egy árva PPPoE-vel kapcsolatos bit sem megy át, se PADI, se PADO, semmi, hiába próbálgatom a connect interface pppoe0 parancsot. Itt azért már gyanús volt, hogy valami vyattás hülyeségbe szaladtam bele, talán nem is támogatott lehetőség a PPPoE over VLAN vagy hasonló.

Végül a Google kiköpte a választ, nem a PPPoE over VLAN a hiba forrása. Persze azóta elkevertem a linket, és már nem emlékszem, hogy mire kerestem pontosan, de mindegy is, a lényeg, hogy egy vyatta.org-os fórumbejegyzésben egy Vyatta alkalmazott leírta, hogy már egy ideje gond van ezzel a connect-on-demand dologgal, és ha azt kiszedjük a konfigból, minden jó lesz. És tényleg, a delete interfaces ethernet eth0 vif 1 pppoe 0 connect-on-demand parancs kiadása után minden a helyére került. Megjegyzem, ez azért bénaság egy olyan feltörekvő networkös cégtől, amelyik a vállalati piacra szeretne betörni. Kíváncsi lennék, hogy vajon csak az ingyenes Vyatta szoftververziókban van-e ilyen hiba vagy az előfizetéses változatokban is?

Reguláris kifejezések a különféle network OS-ekben (1.)

2011-05-08T18:30:00.002+02:00

Az előző posztban említett kézi hálózatfelderítés során többször is alkalmaztam IOS alatt reguláris kifejezéseket a különféle parancsok kimenetének szűrésére, nem kell bonyolult dolgokra gondolni, csak nagyjából ilyesféle szűrésekre:

DEVICE#sh mac-address-table | include Gi1/0/1
   1    0001.e674.baa6    DYNAMIC     Gi1/0/13
   1    0001.e674.bab8    DYNAMIC     Gi1/0/1
   1    0001.e6a2.02b6    DYNAMIC     Gi1/0/13
   1    0002.e33c.5203    DYNAMIC     Gi1/0/13
   1    0002.e33c.5316    DYNAMIC     Gi1/0/15
   1    0002.e34f.08fd    DYNAMIC     Gi1/0/13
   1    0002.e34f.0a42    DYNAMIC     Gi1/0/13
   1    0002.e352.8dbb    DYNAMIC     Gi1/0/13
   1    000f.fe02.3f48    DYNAMIC     Gi1/0/13
   1    000f.fe30.880e    DYNAMIC     Gi1/0/13
   1    000f.fe31.920d    DYNAMIC     Gi1/0/15

DEVICE#sh mac-address-table | include Gi1/0/1$
   1    0001.e674.bab8    DYNAMIC     Gi1/0/1

Nyilván egyértelmű a különbség azok számára is, akik nem ismerik a regexpeket. A $ kifejezés a keresendő minta végéhez illeszkedik, tehát az az megelőző szöveges mintának a sorvégeken kell szerepelnie, ezért nem jelenik meg egy olyan sor sem a második példában, amelynek a végén nem pontosan a "Gi1/0/1" karaktersor áll. Ez persze az egyik legegyszerűbb példa, számtalan egyéb dolgot bevethetünk még, a regexpek használatának lehetősége átszövi az IOS-t, legtöbbször persze a különféle show kimeneteket szűrjük meg velük, de vannak más alkalmazási lehetőségek is, többek közt ilyen a BGP AS-path szűrés. Vajon mi a helyzet az egyéb OS-ekben?

A márciusban kiadott legújabb FortiOS-ben (4.0MR3) a CLI referencia kézikönyv szerint az alábbi területeken nyílik lehetőségünk regexp használatra:

Data Leakage Prvention (DLP) szabályok definiálásakor
BGP AS-path szűrésre
Különféle e-mail szűrésekhez (e-mail cím alapú levélszűrésre, spamszűrőkben, MIME header szűrésre)
Weboldalak tartalom- illetve URL alapú szűrésére
CLI-ben a get, show és diagnose parancsok kimenetének szűrésére (a szokásosnak mondható include, exclude parancsok helyett itt egyszerűen csak grep a szűrő parancs)

A H3C/3Com örökséget tovább vivő HP Networking termékekben szintén megtalálható a regexp támogatás, hogy pontosan mire is használható, arról a "Reguláris kifejezések a különféle network OS-ekben" következő részében lesz szó.

Network discovery módszerek

2011-04-13T22:41:00.005+02:00

Mit tehetünk akkor, ha a feladatunk a világ másik végén lévő telephely LAN-jának minél alaposabb feltérképezése, és nincs semmiféle dokumentáció, amivel neki lehetne kezdeni a feladatnak? A helyi IT-s munkaerő nem ismeri igazán a hálózati eszközöket, ha kell, néhány alapvető dolgot -- hostname, IP, default gateway, admin jelszó -- be tud állítani webes felületen, de itt nagyjából kimerül a szakértelem.

Ilyenkor az lenne a legjobb, ha az ember csak ráeresztene valami okos szoftvert a megfelelő subnetre, az meg minden kis információmorzsát felcsipegetne, benézne ide is, oda is, HTTP-n, HTTPS-en, telneten, SSH-n, SNMP-n, amelyiken éppen lehet, végül kiadna egy részletes layer 2-es topológia ábrát hostnevekkel, IP-kkel, portszámokkal, az eszközök típusával, meg minden. A valóság ezzel szemben az, hogy nem véletlenül jut el a világnak erre a felére a probléma, az adott telephelyen a LAN eszközök nincsenek egységesen konfigurálva, különböző felhasználónevek és jelszavak vannak rajtuk beállítva (ha egyáltalán be van állítva valami), több különböző gyártótól valóak, vicces hurkokat kötöttek rájuk, némelyiknek még IP-je sincs.

A tipikusan ilyesmire használt gyártóspecifikus szoftverek, mint amilyen régi kedvencem, a 3Com Network Director (3ND) vagy újabban az azt felváltó HP Intelligent Management Center - IMC (bár szerintem ez kissé nehézkesre sikeredett) vagy a Nortel Enterprise Switch Manager vagy a Cisco Network Assistant nem igazán rúgnak labdába ilyen helyzetben, és soha nem lesz pontos az, amit kiköpnek magukból egy discovery után, de azért kiindulási alapként nem feltétlenül rossz az. Jelenleg épp a 3ND és a Cisco Network Assistant volt kéznél, gondoltam kipróbálom, mire mennek.

A menedzsment szoftverek alternatívájaként pedig ott a CLI-s buherálás, első körben nmap-pel kiszűrhetők az adott subnetben lévő gyanús hostok: a már említett protokollok portjai közül legalább egy nyitva van, szerencsésebb esetben több is (TCP-80, TCP-22, TCP-23, TCP-443, UDP-161), ezekről listát készít az ember, összeszedi a helyi IT-től előzetesen begyűjtött jelszavakat, majd jöhet a favágás: megpróbálni belépkedni mindenhova. A sikeres műveletekről táblázat készül, hogy egy adott IP adott portján mivel lehetett belépni. Ha a subnet elfogyott, akkor jó eséllyel a legtöbb távolról adminisztrálható eszközt sikerült azonosítani, így már csak a köztük lévő kapcsolatokat kell feltérképezni. A kapcsolatok feltérképezésében óriási segítség a CDP, NDP vagy egyéb hasonló protokoll által begyűjtött információ, ám nem mindig elegendő. A végső megoldás annak megállapítására, hogy mely portra van kötve egy-egy eszköz, a CAM tábla nézegetése. Ha sikerült bejutni már akár csak egyetlen eszköz parancssorába, onnantól a subnet összes hostjának MAC címét meg tudjuk keresni, egy ping után ott lesz az ARP táblánkban. Az ARP táblából kikeresett MAC címet utána már megleljük a CAM táblában is, és ha kell, switchről switchre, CAM tábláról CAM táblára végig lehet követni addig a portig, ahová az adott eszköz ténylegesen be van dugva. A CAM tábla további előnye, hogy megmutatja az összes csatolt switchet, hubot: ha azt látjuk a CAM táblában, hogy mondjuk az Fa0/8-as porton 13 MAC címet tanult be az eszközünk, akkor biztosak lehetünk benne, hogy a 8-as porton lóg még valamilyen hálózati eszköz, akár mutatja a CDP neighbor-ök közt a switchünk, akár nem (leszámítva az olyan extrém eseteket, mint például a virtual hostok, ahol virtuális a switch is). Végül a CLI-ben elérhető STP, LACP információk alapján pontosíthatjuk a topológiát, bejelölve a redundáns linkeket is. Hát, ez a kézi módszer, sziszifuszi meló, az biztos.

No, de hogy valami érdekes is jusson végére, az említett telephely feltérképezését megcsináltam 3ND-vel, Cisco Network Assistant-tal és kézzel is. Amint az utólag kiderült, a telephelyen az eszközök többsége Cisco volt, szóval a 3ND-nek eleve nem voltak nagy esélyei. Gondoltam érdemes az eredményeket számszerűsíteni is, ha a layer2-es topológia gráfjának minden megtalált éle és csúcsa egy-egy pontnak számít (az élek estén szükségesek a portok információi is a ponthoz, pl. egyik eszköz Gi1/0/2-ről megy a másik Gi0/1-re), akkor a következő eredmények születtek:

A kézi módszerrel 41 pontot sikerült elérni, 21 csúcs és 20 él került fel a topológia ábrájára (semmi redundancia), ez összesen 16 Cisco eszközt jelent, egy 3Com eszközt és négy közelebbről nem azonosítható, feltehetően unmanaged switchet. Természetesen messze ez a módszer igényli a legtöbb időt, a management szoftverek néhány vagy néhány tíz perces discovery idejéhez képest itt több óráról van szó.

A Cisco Network Assistant 20 pontot gyűjtött, a 16 Cisco eszközből 11-et megtalált, köztük egy olyat is, mely csak a CDP neighbor-ök közt volt megtalálható, egyébként nem volt IP cím beállítva rajta. A többi Cisco eszközre különféle okokból nem tudott bejelentkezni, az egyik például szolgáltatói eszköz volt az ötből, amelyhez nincs jelszavunk, a maradék négy Cisco eszközökhöz pedig csak Telnet hozzáférés volt, amit nem tudott használni, míg az egyéb (nem Cisco) eszközöket pedig hivatalból ignorálta. De legyünk méltányosak a programhoz, az általa megrajzolt topológia pontos volt, nem húzott be téves éleket a gráf csúcsai közé, minden teljesen egybevágott az eszközökből kinyerhető CDP információkkal, így sokat segített a kézi módszer felgyorsításában, ellenőrzésében.

A 3Com Network Director meglepetésre 21 pontot ért el, összesen 16 eszközt talált meg (ugye emlékszünk: a maradék 5 eszköznek nincs IP címe!), ám csak 5 kapcsolatot fedezett fel az eszközök közt helyesen, a többi eszköz fura felhőkön keresztül csatlakozott vagy csak úgy lógott a levegőben. Vitathatatlanul ez volt a legzajosabb módszer, számos nyomtató és egyéb SNMP-képes eszköz bukkant fel a topológiában, igaz ezeket nem volt nehéz kiszűrni.

A végső találati arányokat még sajnos nem tudom, ugyanis nemrég küldtem el a helyi IT-snek ellenőrzésre a kézi módszerrel összeállított topológiáról a Visio ábrát, amit ki fog egészíteni/javítani a tényleges állapotoknak megfelelően. Remélhetőleg a 41 pont nem lesz messze a valós értéktől...

A tűzfalazás magasiskolája

2011-03-30T13:26:00.001+02:00

A mostanában -- illetve már egy éve -- futó WAN átszervezős projektünk keretein belül belefutottam egy újabb szánalmas problémába. A projektben soron következő néhány telephelyhez igen sok tűzfalszabály kapcsolódik az egyik legfontosabb site-unk tűzfalában, ami azért gond, mert ezeket a szabályokat a WAN migrációval párhuzamosan kell megváltoztatni, más zónákba kell majd kerülniük ezeknek a szabályoknak, zónákból is elég sok van, az említett telephelyekhez kapcsolódó szabályokból még több, szóval gyanús, hogy nem lesz a dologból sikertörténet.

Még annyit érdemes tudni, hogy a tűzfal többek közt a fontos site-on is ki van szervezve, és nincs közös irányelvek alapján dolgozó belső csapatunk a tűzfalas kérdésekre, ráadásul az ezzel foglalkozó emberek is jönnek-mennek. Van persze egy alapvető biztonsági szűrés a tűzfalas kérésekre, de itt nagyjából meg is áll minden egységesítési törekvés. Ha ezt még megfűszerezzük azzal, hogy a tűzfal szolgáltatást nyújtó cég sem ugyanazokra az emberekre delegálja a kéréseinket (értelemszerűen), akkor azért nagyjából el lehet képzelni, hogy hogyan néz ki egy-egy ilyen kiszervezett tűzfal. A legkisebb bajom az, hogy nincs egységes megközelítés, hogy mikor használjunk pl. a szabályok SRC és DST mezőiben sima IP-t, IP-t netmaskkal, szimbolikus, külön definiált neveket vagy a belső DNS-eken feloldott domainneveket, szóval ez teljesen ötletszerű, és ember legyen a talpán, aki egy-egy szabályról ránézésre megállapítja, hogy honnan hová tilt vagy engedélyez bizonyos forgalmat.

Épp azon lamentáltam a tűzfalszabályokat böngészgetve, hogy hogyan lenne érdemes ezt megközelíteni, amikor megpillantottam a GUI-n a "Column settings" opciót... és igen, volt benne "Count" mező is, bekapcsoltam, majd jött a döbbenet. A már említett fontos telephely tűzfalszabályainak 76 százaléka szemét. Nem volt azokon a szabályokon semmilyen forgalom a tűzfal utolsó firmware frissítése óta, ami azért nem két napja történt (148). Jó, ebből a 76%-ból lejön valamennyi, például bizonyos VPN tunnelekhez kapcsolódó szabályok, amely tunnelek csak akkor kezdenek el érdemben forgalmazni, ha szakad a bérelt vonal itt vagy ott, de azért a 76 százalék az 76 százalék. Tiszta sor: nincs gazdája a rendszernek, a szabályok csak bekerülnek, olykor többször is, és valójában sem a cégünk, sem a tűzfalat szolgáltató cég nem törődik a rendszerrel.

Szóval megkérdeztem a főnököt, hogy mit szólna, ha azt a jó néhány száz szabályt, ahol 0 bájt volt a forgalom, töröltetnénk, utána már könnyebb lesz a WAN migráció. Meglátjuk, mit szól hozzá.

Firmware frissítés 3ComOS-t futtató XRN (IRF) switch stacken

2011-03-15T17:42:00.002+01:00

Korábban már érintőlegesen volt szó a 3ComOS-ről, ami tavaly ugye mindenestül a HP kezébe került, de gyakorlatilag ugyanez a szoftver fut a Huawei és a H3C eszközökön is. Ma ismét előszedhettem a 3ComOS ismereteimet, a nemzeti ünnep ugyanis kiváló alkalom a szoftverfrissítések terítésére. Aki ismeri valamennyire a korábbi 3Com, illetve a jelenlegi HP, H3C, Huawei vonalat, az tudja, hogy egészen élhető stack technológia van ezekben a vasakban, viszont a stack a szoftverfrissítés során nem nagy előny. Az XRN vagy újabban IRF stackek nem állnak ugyanis össze, csak akkor, ha pontosan azonos a szoftververzió a stack unitjain. Innentől viszont érdemes észnél lenni, hogy mikor, mit csinál az ember, és bizony a hivatalos dokumentumok sem viszik túlzásba a stack-es szoftverfrissítési folyamat ismertetését. Vannak persze ezekhez a dolgokhoz is management eszközök (3Com Network Director, HP Intelligent Management Center), amivel GUI-n összekattintgatja az ember a frissítést, viszont ha elég sok stackünk van, akkor ilyen vagy olyan okból mindig akad egy-kettő, ahol elhasal a GUI és jöhet a mindenható CLI-s bütykölgetés.

Az első lépés a hely felszabadítás a beépített flash modulokon, nem mindegyik típusnál fér ugyanis el két különböző szoftververzió egymás mellett, nyilván a nagyobb, drágább eszközökön ez nem gond, de ha access stackekről van szó, akkor a helyhiány mindennapos probléma lehet a frissítéskor. A dir /all /fabric paranccsal egyszerre ki tudjuk listázni az összes uniton a fájlokat unitonkénti bontásban:

<HOSTNAME>dir /all /fabric
Directory of unit1>flash:/

   1 (*)   -rw-     10199 Mar 10 2011 08:43:52   3comoscfg.cfg
   2       -rwh       293 Mar 02 2011 01:56:03   private-data.txt
   3       -rw-      9705 Feb 29 2008 12:00:00   3comoscfg.def
   4 (*) -rw-   4171170 Mar 15 2011 15:56:51   s3n03_03_02s168p06.app
   5 (*)   -rw-    981062 Mar 15 2011 16:00:08   s3p04_03.web

7239 KB total (2055 KB free)

Directory of unit2>flash:/
... a többi unit adatai...

A listából láthatjuk, hogy mennyi szabad hely van még unitonként, illetve azt, hogy mely fájlokat futtatja aktuálisan a rendszer. A fenti példában látható, hogy az s3n03_03_02s168p06.app a bootloadernek megadott rendszer image, a webGUI-hoz pedig az s3p04_03.web fájlból veszi az adatokat az OS, hely viszont még egyszer ugyanennyihez nincs (általában a többi uniton is ugyanez a helyzet). Ilyenkor le kell egyenként törölgetni a fájlokat minden unitról a delete paranccsal (delete unit1>flash:/s3n03_03_02s168p06.app), majd ugyanez a unit2-vel, unit3-mal... illetve a műveletet érdemes megismételni a web package-ekre (*.web) is. Valami ilyesmit fogunk kapni eredményül:

<HOSTNAME>dir /all /fabric
Directory of unit1>flash:/

   1 (*)   -rw-     10199 Mar 10 2011 08:43:52   3comoscfg.cfg
   2       -rwh       293 Apr 02 2008 01:56:03   private-data.txt
   3       -rw-      9705 Feb 29 2008 12:00:00   3comoscfg.def
   4       -rw-   4171170 Mar 15 2011 15:56:51   [s3n03_03_02s168p06.app]
   5       -rw-    981062 Mar 15 2011 16:00:08   [s3p04_03.web]

7239 KB total (2055 KB free)

Directory of unit2>flash:/
... a többi unit adatai...

<HOSTNAME>reset recycle-bin /fabric
Squeeze the recycle bins in fabric ? [Y/N]:y
Unit1 reset success!
Unit2 reset success!
Unit3 reset success!
Unit4 reset success!
Unit5 reset success!
Unit6 reset success!

A hely csak a recycle-bin ürítés után szabadul fel ténylegesen, amit egyetlen paranccsal meg tudunk tenni minden unitra a reset recicle-bin /fabric kapcsolójával. Ebben az állapotban nem jó, ha újraindulnak eszközök, mert nem fognak tudni bebootolni (természetesen konzolról vissza lehet küzdeni magunkat, de jobb az ilyesmit elkerülni, ha van rá mód), így mihamarabb másoljuk fel minden unitra a friss szoftvert:

tftp 10.10.10.10 get s3n03_03_02s168p11.app unit1>flash:/s3n03_03_02s168p11.app
tftp 10.10.10.10 get s3n03_03_02s168p11.app unit2>flash:/s3n03_03_02s168p11.app
stb.

tftp 10.10.10.10 get s3p04_04.web unit1>flash:/s3p04_04.web
tftp 10.10.10.10 get s3p04_04.web unit2>flash:/s3p04_04.web
stb.

A fájlokat egyébként elegendő egyszer letölteni a stackre, és onnantól lehet a unitok közt is másolgatni a copy paranccsal. Bizonyos frissítésekhez új bootloader (*.btm) is jár, ilyenkor ezt is le kell töltenünk minden unitra:

tftp 10.10.10.10 get s3o04_04.btm unit1>flash:/s3o04_04.btm
tftp 10.10.10.10 get s3o04_04.btm unit2>flash:/s3o04_04.btm
stb.

Ha felmásoltuk a szoftvereket, jöhet a használatba vétel, be kell állítanunk (még a régi) bootloaderhez az új szoftver image-t -- természetesen minden egyes uniton:

<HOSTNAME>boot boot-loader unit1>flash:/s3n03_03_02s168p11.app
The specified file will be booted next time on unit 1!
<HOSTNAME>boot boot-loader unit2>flash:/s3n03_03_02s168p11.app
The specified file will be booted next time on unit 2!
stb.

Ha van bootloader frissítés, akkor azt is minden uniton be kell állítani (a beállítás után egyébként a *.btm fájlok törölhetők, de ha ott maradnak, az sem számít):

<HOSTNAME>boot bootrom unit1>flash:/s3o04_04.btm
This will update Bootrom on unit 1. Continue? [Y/N] y
Upgrading Bootrom, please wait...
Upgrade Bootrom succeeded!
<HOSTNAME>boot bootrom unit2>flash:/s3o04_04.btm
This will update Bootrom on unit 2. Continue? [Y/N] y
Upgrading Bootrom, please wait...
Upgrade Bootrom succeeded!
stb.

Végül a friss web package beállítása következik, már ahol szükség van egyáltalán ilyesmire. Ezt nem kell unitonként állítani, egyszer kell kiadni a következő parancsot:

<HOSTNAME>boot web-package s3p04_04.web m

Ha mindennel elkészültünk, akkor jöhet a stack újraindítása a reboot paranccsal.

A Babel routing protokoll

2011-03-14T22:41:00.021+01:00

Épp az OpenWRT oldalán böngésztem a híreket (egyre türelmetlenebbül várom a tavalyi 10.3-as verzió frissítését), amikor olvasom, hogy holnapután Barcelona mellett lesz a "Wireless Battle Mesh v4". Hát az meg mi? No, nem mintha elmennék vagy ilyesmi, de sosem hallottam még csak hasonlóról sem, ezek meg már a negyediket rendezik...

Némi kutakodás után, bár sokkal okosabb nem lettem, arra jutottam, hogy ez valamiféle perverz geek találkozó, ahol tényleg foglalkoznak wifivel, de a hangsúly nem ezen van, hanem a routingon. Egy-egy ilyen esemény alkalmával összedobnak egy mesh hálózatot, amelyben minden egyes eszközön (a mesh gráf csúcsai) routeolás folyik és valamilyen irányító protokoll fut.

Itt jön a lényeg, hogy milyen protokollt érdemes választani? A rádiós hálózatok ugyanis a vezetékesekkel szemben számos meglepetést tartogathatnak. Változhat például a topológia az eszközök mozgatása, ki-be kapcsolása nélkül is, az épp aktuális rádiós viszonyok függvényében, és a vezetékes világban megszokott, gyakorlatilag kétállapotú összeköttetések (a mesh gráf élei) -- amelyek ugye vagy működnek vagy nem -- helyett előfordulhatnak olyan "működő" kapcsolatok, amelyek érdemi információtovábbításra nem alkalmasak, mert igen jelentős rajtuk a csomagvesztés.

A legizgalmasabb az egészben, hogy új irányító protokollokat tesztelnek és hasonlítanak össze egymással ezen a mesh hálózaton. Részt lehet venni bármilyen nyílt forrású implementációval, ami működőképes OpenWRT alatt. Az külön poén, hogy ilyenek tényleg vannak, a felhívás szerint ezen a negyedik mesh találkozón a Babel, a B.A.T.M.A.N., a BMX (B.A.T.M.A.N. Experimental) és az OLSR protokollok biztosan szerepelnek. Egy picit utánaolvastam mindnek, és találtam egy összehasonlító elemzést is, amely szerint a Babel a nyerő.

Ezek után a Babel doksit végig is nyálaztam, kiderült, hogy ez egy új távolságvektor-alapú protokoll, az említettek közül ez a legfiatalabb, kifejezetten mesh wifihez készült, de állítólag vezetékes környezetben is megállja a helyét. A teljesség igénye nélkül a protokoll néhány fontosabb jellemzője:

A Babel által használt metrika a prokollt futtató szomszédos eszközök közötti kommunikációra épül, az eszközök Hello üzeneteket küldenek szomszédaiknak, amelyekre azok az "I Heard You" (IHU) választ kapják. Az üzenetváltások sikeressége alapján a babeles eszköz költséget számol minden egyes szomszédjához, értelemszerűen a költség annál kisebb, minél kevesebb a sikertelen üzenetváltás.
A protokoll alapvetően a Bellman-Ford algoritmusra épít (periodikus frissítések minden szomszédtól és ezen frissítések alapján a legalacsonyabb költségű útvonal kiválasztása, illetve a végtelenig számlálás), bizonyos megszorításokkal.
Ilyen megszorítás, hogy egy adott router nem vesz tudomást egy másikhoz vezető frissítésekről, amíg azok kisebb költségűek, mint a rajta nyilvántartott eddigi legkisebb költség az adott célhoz (a nagyobb költségűeket pedig épp azért hagyja figyelmen kívül, mert ott nagyobb a költség, így nem éri meg átváltani rájuk).
Az előző pont, bár megakadályozza a hurkok kialakulását, a topológia módosulásakor route-ok használhatatlanná válásához vezet, ezért a Babel által küldött frissítésekben szekvenciaszámok is szerepelnek, és egy frissítés átmegy a szűrőn, ha a szekvenciaszám nagyobb, mint az eddig látott szekvenciaszám.
A szekvenciaszám növelését kérhetik is a routerek egymástól, minden routernek saját szekvenciaszáma van. A szekvenciaszám-növelési kérelmek jelentősen felgyorsítják a konvergenciát.
Ha azonos prefixet meghirdet több eszköz is, akkor azokat a prefixeket a Babel külön entitásként kezeli, vagyis mindenki a hozzá "közelebbi" forrást fogja használni.
Támogatja az IPv4-et és az IPv6-ot is.

Gyaníthatóan ez a kis összegzés több kérdést vet fel, mint amennyit megválaszol, a végső válaszok a protokoll dokumentációjában érhetők el.

DHCP relay agent NAT-olt hálózatban: esélytelen

2011-03-02T22:22:00.004+01:00

Adott egy telephelyünkön egy több subnetre osztott LAN, minden subnetben a LAN router a DHCP relay agent, ez így eddig tiszta sor, semmi meglepő nincs benne. Na most vannak persze olyan subnetek is ezen a telephelyen, amelyek nincsenek Layer 3 összeköttetésben a telephely egyéb részeivel, ezer oka lehet, a legtöbb persze nem szakmai, mindenesetre ilyesmi dolgot kell elképzelni:

A gondok természetesen akkor kezdődnek, amikor a 192.168.1.0/24-ben mégiscsak akadnak hostok amelyek a többi subnettel kommunikálnának. Persze ilyenkor a network admin kaján vigyorral közli, hogy látjátok-látjátok, nem kellett volna azt a subnetetet így oda tenni, megmondtuk mi annak idején, hogy olyan hálózatot válasszatok, ami illeszkedik a globális címzési rendszerünkbe és a telephelyen használt supernetben benne van.

Aztán a vigyor, meg a címzési tervek gyorsan eltűnnek, amikor kiderül, hogy itt most nem "légből kapott", "ködös" elvekhez kell ragaszkodni, hanem a felmerülő üzleti igényeket kell gyorsan, pontosan kiszolgálni, és nincs apelláta: a 192.168.1.0/24-nek tudnia kell kommunikálni, most, nincs sem idő, sem erőforrás, sem hajlandóság az utált subneten belüli 150+ statikus IP-s hoston címváltásra (vagyis nem lehet belőle semmilyen körülmények közt sem pl. 10.10.15.0), és igazából csak a VLAN99-ből kell elérni egy-két külső dolgot, "hát már ennyit sem lehet rátok bízni?" stb.

Száz szónak is egy a vége, meg kell patkolni, egy végzetes napon a VLAN99 NAT-olva rácsatlakozik a VLAN10-re. Aztán jönnek az újabb és újabb problémák, amelyek fel sem merülnének ugye, ha a VLAN99 rendes subnet lenne, olyanok például, hogy egyik-másik adatbázis szervert a VLAN99-ben mégiscsak el kellene érni kívülről, legyen port forward, ezt ide, azt oda, akkor persze jön a kérdés, hogy miért nem lehet a belső adatbázis-szervereket kívülről pingelni, aztán újabb és újabb port forwardok, persze az egész rögtön biztonsági kérdéseket is felvet, mert természetesen a VLAN99-ben nincs szabványos kliensvédelem, hiszen az úgyis "szeparált", szóval egy-két év alatt ebből egy teljesen dokumentálatlan össze-vissza rugdosott rendszert lehet felépíteni, amihez senki nem nyúl szívesen, akik meg használják, elégedetlenek.

Na, most ott tart a dolog, hogy a VLAN99-ben be kellene vezetni a központi DHCP szolgáltatást, és persze sikerült ráfutni a DHCP relay agent beüzemelése közben egy elég alapvető problémára: NAT-olt hálózat felé nem fog menni a relayezés, hiszen a relay agent még csak kiküldi a VLAN99-ből a DHCP üzeneteket a DHCP szerver felé, azonban a relay agent és a DHCP szerver közt már unicast forgalom zajlik, amely kommunikációban a relay agent a belső, a DHCP szervertől távolabbi lábának az IP-jével vesz részt (pl. 192.168.1.1), így a DHCP szerver hiába küldené vissza a választ a default gatewayen... Persze így vagy úgy folytatódni fog a hályogkovácsolás, át lehet azt a DHCP-t küldeni ezer más módon.

Az egészben a legbosszantóbb, hogy az üzleti oldal még mindig, sok év után sem látja, hogy itt az alapkoncepció hibás, ugyanakkor újabb és újabb dolgokat építene az ingatag alapokra. Erős IT-t szeretnék, ahol nem engedik ki az IT kezéből az IT-ra tartozó döntéseket.

Radia Perlman az STP-ről és sok minden másról

2011-02-15T22:38:00.006+01:00

Elképesztő, hogy micsoda könnyedséggel tud beszélni Radia Perlman mindenféle hálózati protokollokról, és hogy mennyire meg tudja ragadni a lényeget egy-egy szinte ovis szinten felvázolt ábrával. Bájos az is, hogy nem hagyja magát zavartatni csip-csup részletekkel (pl. a TRILL részleteinek tágyalásánál a per-ingress tree melleti érvelés a 36-37. percnél). Szóval szinte tátott szájjal néztem végig a TRILL protokollról (Transparent Interconnection of Lots of Links) szóló előadásáról készült videót, amelyben felvázolja az általa gyakorlatilag egyetlen este kitalált STP protokollhoz vezető lépéseket (hatalmas a sztori az első bridge-ről, amibe beletették az STP-t, kb. 15:30-tól), illetve részletesen beszél a felvétel készítése óta (2008) nem túl nagy karriert befutott TRILL-ről.

GRE tunnel IPSec-ben Cisco és Vyatta eszközök közt

2011-02-11T16:48:00.004+01:00

A nem azonos gyártótól származó eszközök közötti korábbi egyszerű IPSec tunneles posztok után gondoltam, kipróbálom az IPSec-be ágyazott GRE tunnelt Cisco és Vyatta eszközök közt. Bár a GRE alapvetően Cisco technológia, más gyártók is támogatják használatát, többek közt a Vyatta rendszerek is.

A GRE/IP tunnelek nagy előnye az egyszerű IPSec tunnelekhez képest, hogy külön virtuális tunnel interfészünk van, ami az unicast IP forgalmon kívül (amit az egyszerű IPSec tunnel is tud) ismeri a multicastot és a broadcastot is, így akár egy olyan irányító protokoll is működhet GRE-n keresztül, mint az OSPF. Ugyanakkor a GRE/IP semmilyen biztonságot nem nyújt, nem titkosított a payload benne, ezért is gondolták a Cisco-nál, hogy jó ötlet lesz az IPSec-kel házasítani, így született meg a GRE/IPSec, amit egy Cisco routeren körülbelül így kell konfigurálni (az IPSec beállítások megegyeznek a korábbi táblázatban leírtakkal):

crypto isakmp policy 10
encr aes 256
hash sha
authentication pre-share
group 5
exit

crypto isakmp key TITOK address <peer IP>

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 <tunnel IP-je> <netmask>
tunnel source <saját külső IP>
tunnel destination <peer IP>
tunnel protection ipsec profile TESZTPROFIL
exit

Látható, hogy nincs szükség GRE/IPSec esetén crypto map-re, tehát crypto ACL-re sem (amivel egyébként egy kis figyelmetlenséggel pillanatok alatt ki tudjuk zárni magunkat a távoli routeről), így nem kell megadnunk azt sem, hogy milyen subnetből milyen subnetbe megy az IPSec-kel védett forgalom, hiszen az a GRE tunnelben fog utazni, az IPSec fölött, így az IPSec-nek elég azt tudnia, hogy mi a két IP a GRE tunnel két végén (tunnel source, tunnel destination), e két IP közt pedig elég a GRE forgalmat titkosítani, minden más már a GRE-n belül fog utazni. Na, ez az, amit nem lehet összehozni Vyatta alatt, legalábbis most (VC-6.1) még nem, de talán már a következő kiadásban benne lesz.

Megjegyzés (2011-08-26): a Vyatta 6.3-as verziójától kezdve elérhető a kérdéses lehetőség, amit egy külön posztban meg is vizsgáltam.

Létezik azonban más megközelítés is: ha közbeiktatunk egy loopback interfészt, és mi magunk drótozgatunk össze egy GRE/IPSec-like megoldást. A lényeg változatlan marad, a GRE alatt IPSec lesz, viszont ezt a Vyatta is támogatja. Az ötlet alapvetően annyi, hogy a GRE tunnelt fizikai interfészek helyett loopback interfészek IP-i közt húzzuk ki, és ezeket a loopback IP-ket engedjük át az IPSec tunnelen, az IPSec pedig ugye már a rendes külső IP-nken fog átmenni a peerhez. A túloldalon ugyanúgy él a két router közti IP kapcsolat, ott is rátesszük az IPSec-et, abba is beletesszük a loopbackek közti GRE-t, amibe végül önthetjük mindazt, amit meg ezen az oldalon szeretnénk látni. Konfiguráció szempontjából persze kényelmetlenebb ez a fenti megoldásnál mind a Cisco mind a Vyatta oldalán, de a végén lehet egy olyan GRE tunnelünk IPSec felett, amelyben szépen dolgozgat az OSPF, és bármilyen egyéb hálózatot átrouteolhatunk rajta, függetlenül attól, hogy mi van beállítva a crypto ACL-ben. Simán megéri. A tesztkörnyezet topológiája a következő:

Konfiguráció az R1-Cisco eszközön:

hostname R1-Cisco

interface Loopback1
ip address 10.10.127.1 255.255.255.255
exit
interface Tunnel1
ip address 10.10.47.1 255.255.255.252
tunnel source 10.10.127.1
tunnel destination 10.10.127.2
exit
interface FastEthernet0/1
ip address 10.1.1.1 255.255.255.0
duplex auto
speed auto
exit

crypto isakmp policy 10
encr aes 256
hash sha
authentication pre-share
group 5
lifetime 28800
exit

crypto isakmp key TITOK address 192.168.12.2

crypto ipsec transform-set TESZTSET esp-aes esp-md5-hmac
exit

access-list 100 permit ip host 10.10.127.1 host 10.10.127.2

crypto map TESZTMAP 10 ipsec-isakmp
set peer 192.168.12.2
set transform-set TESZTSET
set pfs group5
match address 100

interface FastEthernet0/0
ip address 192.168.11.2 255.255.255.252
crypto map TESZTMAP
exit

router ospf 1
network 10.1.1.0 0.0.0.255 area 0
network 10.10.47.0 0.0.0.3 area 0
exit

ip route 0.0.0.0 0.0.0.0 192.168.11.1

Konfiguráció az R2-Vyatta eszközön:

set system host-name R2-Vyatta

set interfaces ethernet eth0 address 192.168.12.2/24
set interfaces ethernet eth1 address 10.2.2.1/24
set interfaces loopback lo address 10.10.127.2/32
set interfaces tunnel tun1 address 10.10.47.2/30
set interfaces tunnel tun1 encapsulation gre
set interfaces tunnel tun1 local-ip 10.10.127.2
set interfaces tunnel tun1 remote-ip 10.10.127.1

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 pfs enable
set vpn ipsec esp-group TESZT-ESP-GROUP lifetime 3600

set vpn ipsec site-to-site peer 192.168.11.2
set vpn ipsec site-to-site peer 192.168.11.2 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 192.168.11.2 authentication pre-shared-secret TITOK
set vpn ipsec site-to-site peer 192.168.11.2 ike-group TESZT-IKE-GROUP
set vpn ipsec site-to-site peer 192.168.11.2 local-ip 192.168.12.2
set vpn ipsec site-to-site peer 192.168.11.2 tunnel 1
set vpn ipsec site-to-site peer 192.168.11.2 tunnel 1 local-subnet 10.10.127.2/32
set vpn ipsec site-to-site peer 192.168.11.2 tunnel 1 remote-subnet 10.10.127.1/32
set vpn ipsec site-to-site peer 192.168.11.2 tunnel 1 esp-group TESZT-ESP-GROUP

set system gateway-address 192.168.12.1
set protocols ospf area 0 network 10.10.47.0/30
set protocols ospf area 0 network 10.2.2.0/24

IPSec site-to-site VPN Cisco és Fortigate eszközökkel

2011-02-05T16:45:00.016+01:00

A korábbi Cisco-Cisco majd Cisco-Vyatta felállás után jöjjön most ismét ugyanaz, ám Cisco-Fortinet variációban. A teszteszköz egy Fortigate 60-as, még a régebbi, 3-as FortiOS-szel, de ugyanezek a CLI parancsok használhatók a legfrissebb 4-es verziójú FortiOS-ekben is. A korábbi topológia változatlan:

Az IPSec beállításokat összegző táblázat szintén változatlan, a Cisco-Cisco posztban megtalálható. A vyattás felállással ellentétben a FortiOS parancsokat nem próbálom megfeleltetni az IOS-es parancsoknak, alapvető szemléletbeli különbségek vannak a Fortigate tűzfalak és a Cisco routerek közt, túl sok lenne a különbség, így az IOS-t futtató R1 eszköz beállításai itt nem is szerepelnek, pontról pontra ugyanazt a konfigurációt használtam, amit korábban is.

A korábbi versenyzőkkel ellentétben a Fortigate viszonylag terjedelmes gyári beállításokkal érkezik, NAT/route üzemmódban (ez az alapértelmezett) a következő IP-k vannak a fizikai interfészeken beállítva:

Internal: 192.168.1.99
WAN1: 192.168.100.99
WAN2: 192.168.101.99
DMZ: 10.10.10.1

Az alapértelmezett user/jelszó páros: admin/nincs jelszó, ha nem tudjuk a jelszót, állítsuk vissza az eszközt a gyári beállításokra. A bejelentkezés után kezdhetünk az interfészekkel, a WAN1 porton lesz a WAN kapcsolatunk (10.1.1.0/24), az internalon pedig a belső háló (10.3.3.0/24), a többit le lehet lőni:

config system interface
    edit "internal"
        set ip 10.3.3.1 255.255.255.0
    next
    edit "dmz"
        set status down
    next
    edit "wan1"
        set ip 10.1.1.2 255.255.255.0
    next
    edit "wan2"
      set status down
end

A következő lépés a Phase1 adatok megadása, minden további beállítás esetén az itt létrehozott néven (TESZT-PH1) tudunk erre a VPN kapcsolatra hivatkozni.

config vpn ipsec phase1-interface
    edit "TESZT-PH1"
        set interface "wan1"
        set proposal aes256-sha1
        set keylife 28800
        set remote-gw 10.1.1.1
        set psksecret TITOK
end

Szükségünk lesz természetesen Phase2 beállításokra is, amelyek a már létrehozott Phase1 beállításokra fognak épülni:

config vpn ipsec phase2-interface
    edit "TESZT-PH2"
        set pfs enable
        set phase1name "TESZT-PH1"
        set proposal aes128-md5
        set dst-subnet 10.2.2.0 255.255.255.0
        set keylifeseconds 3600
        set src-subnet 10.3.3.0 255.255.255.0
end

Ezzel maga az IPSec konfiguráció ugyan készen van, de ne feledjük, hogy a Fortigate-ek alapvetően UTM eszközök, magától szinte semmi sem működik, ha csak nem kreálunk hozzá tűzfalszabályokat. Mielőtt azonban ténylegesen a tűzfal policy-khez nyúlnánk, definiálnunk kell a subneteket, amelyekkel dolgozgatni szeretnénk a későbbiekben:

config firewall address
    edit "R2-belso-subnet"
        set associated-interface "internal"
        set subnet 10.3.3.0 255.255.255.0
    next
    edit "R1-belso-subnet"
        set associated-interface "TESZT-PH1"
        set subnet 10.2.2.0 255.255.255.0
end

Miután készen vannak a subnetek, jöhet a tűzfal policy. Ha az alapértelmezett beállításról indulunk, akkor észrevehetjük, hogy egy szabály már létezik a tűzfalon, ami az R2 belső subnet hostjai számára hozzáférést engedélyez a WAN1 interfészen keresztül elérhető dolgokhoz. Ezt a szabályt megtarthatjuk, vagy akár törölhetjük, letilthatjuk (set status disable), attól függően, mire van épp szükségünk, ezért nem eggyel kezdődik a tűzfalszabályok számozása:

config firewall policy
    edit 2
        set srcintf "internal"
        set dstintf "TESZT-PH1"
        set srcaddr "R2-belso-subnet"
        set dstaddr "R1-belso-subnet"
        set action accept
        set schedule "always"
        set service "ANY"
    next
    edit 3
        set srcintf "TESZT-PH1"
        set dstintf "internal"
        set srcaddr "R1-belso-subnet"
        set dstaddr "R2-belso-subnet"
        set action accept
        set schedule "always"
        set service "ANY"
end

A végére maradt a statikus route a távoli subnet felé:

config router static
    edit 1
        set device "TESZT-PH1"
        set dst 10.2.2.0 255.255.255.0
end

A FortiOS-ben külön nem szükséges menteni, amint kilépünk az end paranccsal valamilyen objektum konfigurációs módjából, a beállított értékeket a rendszer elmenti, illetve természetesen a futó konfigurációban érvényre juttatja.

A figyelmesebbeknek szemet szúrhat, hogy történt egy kis csalás ebben a Fortigate beállításban. A korábbiakban sehol sem használtam az IPSec-hez bármilyen módon köthető virtuális interfészt, VTI-t, loopback interfészt, a Cisco routeren és a Vyattán is egyszerű tunnel módban hoztam létre a kapcsolatot, nem hajtottuk át az adatokat semmilyen egyéb interfészen, csak azon, ahol kiléptek a routerből. A Fortigate esetén is elérhető ez a tunnel mód, policy-based VPN-nek hívják, config vpn ipsec phase1-interface helyett a config vpn ipsec phase1 paranccsal kell létrehozni. Phase2-ben szintén a megfelelő parancs interface nélküli változatát kell választanunk, majd egy tűzfalszabályt kell még hozzárendelnünk, ahol ACCEPT vagy DENY helyett az IPSEC műveletet kell a szabályban műveletként megadni (egy tunnelhez csak egy szabály tartozhat). Eddig egyébként még sosem sikerült értelmes módon beállítanom a policy-based VPN-t, például a távoli site-ról kezdeményezett forgalom során nem áll fel magától az IPSec kapcsolat, bármilyen tűzfal policy-vel is próbálkoztam, míg a Fortigate mögötti subnetből meginduló forgalom hatására mindig azonnal létrejött az IPSec összeköttetés.

A másik, a posztban részletesen is bemutatott módszerrel létrehozott, virtuális IPSec interfésszel operáló beállítást a Fortigate rendszerekben route-based VPN-nek nevezik. A virtuális interfész segítségével kezelhetőbbé válnak a IPSec-en keresztül kimenő vagy beérkező csomagok, átláthatóbbak a rájuk vonatkozó tűzfalszabályok, és mivel ekkor önálló interfészként jelenik meg az IPSec tunnel Fortigate-en lévő vége, bármennyi szabály vonatkozhat rá, kedvünk szerint finomhangolhatjuk.

IPSec site-to-site VPN Cisco és Vyatta VPN routerek közt

2011-02-01T12:48:00.006+01:00

A korábbi IPSec site-to-site VPN konfigurációban kicseréltem az R2 routert, és a Cisco eszköz helyett egy Vyatta VC6.1-es OS-szel ellátott x86-os gép került a helyére (lehetett volna akár virtuális gép is). A korábbi topológia változatlan:

A korábbi, IPSec beállításokat összegző táblázat szintén változatlan, nem is másolom be, megtalálható a hivatkozott posztban. Érdekesebb dolog viszont a Cisco IOS és a Vyatta parancsok összevetése, hogy pontosan melyik minek felel meg a másik OS-ben.

Az első lépés az interfészek felkonfigurálása, a Cisco routerben két FastEthernet port van, a Vyattát futtató rendszeren Fa0/0 helyett eth0 lesz az első ethernet interfész Fa0/1 helyett pedig eth1 a másik:

R1 - Cisco IOS

interface FastEthernet0/0
ip address 10.1.1.1 255.255.255.0
no shutdown
exit

interface FastEthernet0/1
ip address 10.2.2.1 255.255.255.0
no shutdown
exit

R2 - Vyatta

set interfaces ethernet eth0 address 10.1.1.2/24
set interfaces ethernet eth1 address 10.3.3.1/24

Mivel egyik oldalon sincs dinamikus routeolás, ezért be kell jegyeznünk a túloldalon lévő subnetet. Ez a lépés a Vyatta rendszeren egyébként elhagyható, ha ugyanis nincs a későbbi IPSec peer beállításoknak megfelelő bejegyzés a route táblában, akkor a tunnel felépülésekor ezt a rendszer automatikusan létrehozza. A teljesség kedvéért azonban itt szerepel az IOS-ben kiadott parancs vyattás megfelelője:

R1 - Cisco IOS

ip route 10.3.3.0 255.255.255.0 10.1.1.2

R2 - Vyatta

set protocols static route 10.2.2.0/24 next-hop 10.1.1.1

A következő lépés a 10-es prioritású IKE policy létrehozása IOS-en (természetesen más számot is válaszhatunk 10 helyett). Vyatta esetén ennek nagyjából az IKE group létrehozása felel meg, a példában ez a TESZT-IKE-GROUP nevet viseli:

R1 - Cisco IOS

crypto isakmp policy 10
encr aes 256
hash sha
authentication pre-share
group 5
lifetime 28800
exit

R2 - Vyatta

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

A Cisco IOS-ben az isakmp beállítások közt kell megadnunk minden IPSec peerhez a PSK-t, ez a Vyattában csak később, a peer egyéb beállításaival együtt szerepel. Ugyanez érvényes a crypto ACL szabályra, IOS-ben egy extended ACL-t kell létrehoznunk, és azt majd alkalmazni a megfelelő interfészen, ami a Vyattán ugyancsak a peer beállítások közt szerepel:

R1 - Cisco IOS

crypto isakmp key TITOK address 10.1.1.2
access-list 100 permit ip 10.2.2.0 0.0.0.255 10.3.3.0 0.0.0.255

R2 - Vyatta

A peer beállításai közt kell megadni.

A következő sorok a Phase 2-re vonatkoznak, nem feleltethetők meg egymásnak a parancsok egy az egyben, IOS esetén transform set és security assiciation lifetime néven futnak a beállítások, Vyatta esetén pedig ESP group néven, de alapvetően mindkét OS-ben ugyanazt a beállítást végzik el. Vegyük észre azonban, hogy a Vyatta esetén a Perfect Forward Secrecy szintén itt kerül beállításra:

R1 - Cisco IOS

crypto ipsec transform-set TESZTSET esp-aes 128 esp-md5-hmac
crypto ipsec security-association lifetime seconds 3600

R2 - Vyatta

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 pfs enable
set vpn ipsec esp-group TESZT-ESP-GROUP lifetime 3600

Következhet a crypto map az IOS-ben, ami nagyjából az ipsec site-to-site peer beállításoknak feleltethető meg Vyatta alatt. Ugye még emlékszünk arra, hogy a Vyattának két dolgot is pótolnia kell, a PSK és a crypto ACL megfelelőit itt fogjuk megadni, míg az IOS a PFS beállításokkal maradt eddig adós:

R1 - Cisco IOS

crypto map TESZTMAP 50 ipsec-isakmp
set peer 10.1.1.2
set pfs group5
set transform-set TESZTSET
match address 100
exit

R2 - Vyatta

set vpn ipsec site-to-site peer 10.1.1.1
set vpn ipsec site-to-site peer 10.1.1.1 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 10.1.1.1 authentication pre-shared-secret TITOK
set vpn ipsec site-to-site peer 10.1.1.1 ike-group TESZT-IKE-GROUP
set vpn ipsec site-to-site peer 10.1.1.1 local-ip 10.1.1.2
set vpn ipsec site-to-site peer 10.1.1.1 tunnel 0
set vpn ipsec site-to-site peer 10.1.1.1 tunnel 0 local-subnet 10.3.3.0/24
set vpn ipsec site-to-site peer 10.1.1.1 tunnel 0 remote-subnet 10.2.2.0/24
set vpn ipsec site-to-site peer 10.1.1.1 tunnel 0 esp-group TESZT-ESP-GROUP

Utolsó lépésként a mindkét eszköz külső interfészén engedélyeznünk kell az IPSec-et:

R1 - Cisco IOS

interface FastEthernet0/0
crypto map TESZTMAP
exit

R2 - Vyatta

set vpn ipsec ipsec-interfaces interface eth0

Jelentős különbség a két rendszer közt, hogy az IOS-ben a parancsok a kiadásuk után azonnal érvényre jutnak, míg a Vyattában addig, amíg ki nem lépünk konfigurációs módból, csak gyűjti a rendszer a változtatásokat, és át tudjuk nézni az összes változást mielőtt érvényesítenénk (commit) őket.

R1 - Cisco IOS

end
copy run start

R2 - Vyatta

commit
save
exit

IPSec hibakereséshez használhatók a következő parancsok:

R1 - Cisco IOS

show crypto isakmp sa
show crypto ipsec sa

R2 - Vyatta

show vpn ike sa
show vpn ipsec sa

IPSec site-to-site VPN Cisco routerekkel

2011-01-31T22:52:00.023+01:00

Sok forrásból meríthetünk, ha Cisco IOS alatti site-to-site VPN példákat szeretnénk látni, az itt bemutatandó természetesen nem különbözik gyökeresen ezen példáktól, szóval különösebb újdonság jellege nem lesz a dolognak. Valójában csak egy referencia konfigurációt szeretnék bemutatni ebben a posztban, amire később bármikor tudok hivatkozni, és amit később majd olyan posztok fognak követni, amelyekben megváltozik ez vagy az a részlet.

Tegyük fel tehát, hogy két telephelyünk van, a telephelyek LAN-jai igen egyszerűek, egyetlen subnetből áll mindkettő. A két telephely összekötésére csak publikus hálózaton keresztül van módunk, a telephelyek közti belső forgalmat természetesen nem tárhatjuk fel az világ számára. Egyszerű site-to-site IPSec VPN-re van tehát szükség Cisco routerek közt, amelyhez az IPSec-es IOS-en kívül egy-egy publikus, fix IPv4 címre van szükség mindkét oldalon. Topológia:

A IPSec VPN beállítások összefoglalása:

	R1	R2
Phase 1
Encryption	AES256	AES256
Authentication	SHA1	SHA1
Diffie–Hellman Group	5	5
Lifetime	28800 sec	28800 sec
Phase 2
Encryption	AES128	AES128
Authentication	MD5	MD5
Diffie–Hellman Group	5	5
Lifetime	3600 sec	3600 sec

Peer IP	10.1.1.2	10.1.1.1
Authentication method	PSK (“TITOK”)	PSK (“TITOK”)
Local interface	FA0/0	FA0/0
Local subnet	10.2.2.0/24	10.3.3.0/24
Remote subnet	10.3.3.0/24	10.2.2.0/24
NAT-T	nincs	nincs
DPD	nincs	nincs
PFS	van	van
Compression	nincs	nincs

A következő IOS parancsokkal húzhatjuk fel az IPSec tunnelt R1-en:

interface FastEthernet0/0
ip address 10.1.1.1 255.255.255.0
no shutdown
exit

interface FastEthernet0/1
ip address 10.2.2.1 255.255.255.0
no shutdown
exit

ip route 10.3.3.0 255.255.255.0 10.1.1.2

crypto isakmp policy 10
encr aes 256
hash sha
authentication pre-share
group 5
lifetime 28800
exit

crypto isakmp key TITOK address 10.1.1.2

access-list 100 permit ip 10.100.31.0 0.0.0.255 10.100.30.0 0.0.0.255

crypto ipsec transform-set TESZTSET esp-aes 128 esp-md5-hmac
crypto ipsec security-association lifetime seconds 3600

crypto map TESZTMAP 50 ipsec-isakmp
set peer 10.1.1.2
set pfs group5
set transform-set TESZTSET
match address 100
exit

interface FastEthernet0/0
crypto map TESZTMAP
exit

A kékkel jelzett parancsok egybeesnek az IOS alapértelmezett értékeivel, így a show running-config nem fogja őket mutatni, be sem kell pötyögni, csak a teljesség kedvéért szerepelnek a parancsok közt. Az R1 konfigurációja természetesen ugyanezekkel a parancsokkal történik, az IP címeket és a subneteket éretelemszerűen fel kell cserélni, 10.1.1.1 helyett 10.1.1.2, 10.2.2.0 helyett 10.3.3.0 szerepel az R1-es parancsokban.

NMS host multi-VLAN környezetben

2011-01-27T22:06:00.006+01:00

Sok VLAN-os környezetben, különösen ha nincs inter-VLAN routing, vagy ha nem minden VLAN között van layer3-ban kapcsolat, bármikor jól jöhet egy olyan, szigorúan diagnosztikára használt host, amelyik minden VLAN-ba be tud kukucskálni. A komolyabb, szerverekbe való hálózati kártyákon persze már hosszú évek óta ott a VLAN-ok támogatása a Windows Server OS-re, így elvileg Windowsból is készíthetünk ilyen network monitoring hostot, de Windows alatt elég nehézkes már 20 ilyen VLAN interfész kezelése is, különösen ha mondjuk csak 16-ot tud kezelni a windowsos driver. Aztán persze minden VLAN interfészhez külön gondoskodnunk kell a megfelelő route-okról, ügyelnünk kell arra, hogy egyik interfészen se vágja felül egy kósza DHCP-s beállítás a route-okat, és akkor még nem is említettük az átlátható tűzfalazást, szóval Linuxnak kell ennek lennie.

Mostanában Ubuntu/Debian vonalon mozgolódok leginkább, így a konfigurációs példa ilyen rendszerekhez lesz igazítva. Gondolom, azzal nagyjából mindannyian egyetértünk, hogy egy ilyen Linux rendszert kizárólag a legszükségesebb összetevőkkel, X és desktop környezet nélkül kell telepítenünk. Hardver szinten csak a hálókártyát emelném ki, egy megbízható, a VLAN taggelést is kezelni képes kártyára lesz szükségünk (pl. Intel szerver NIC-ek, de a PRO/Desktop sem rossz), a különféle USB-s meg Via, Realtek és hasonló rémségeket viszont felejtsük el, inkább bele se kezdjünk, igen alattomos hibákat tud okozni VLAN környezetben például ha 1500 bájtnál vágják az Ethernet keretet.

Ha sikerült felkonfigurálnunk egy trönk portot valamelyik switchen, akkor a konfiguráció már alapvetően csak az "/etc/network/interfaces" fájl módosítgatásából áll. Különösebb magyarázat helyett jöjjön egy példa, a célunk, hogy egy Linux segítségével az alábbi layer3-as topológia minden egyes VLAN-jába bejárásunk legyen:

A 2-es VLAN az első szervezeti egység publikus hálózata, a 3-as VLAN ugyanezen szervezeti egység belső hálózata, a 4-es VLAN a másik szervezeti egység publikus hálózata, az 5-ös ugyanezen egység belső hálózata, amelyre még közvetlenül becsatlakozik egy távoli telephely. A két szervezet belső hálózata közt nincs semmilyen összeköttetés (viszont ugyanazokon a fizikai switcheken osztoznak). Egy ilyen képzeletbeli topológiához az alábbi beállításokat használhatjuk az "/etc/network/interfaces" fájlban:

auto lo eth0.3
iface lo inet loopback
iface eth0 inet dhcp

# Szervezet1 public - VLAN2
iface eth0.2 inet static
hw-mac-address aa:aa:aa:aa:00:02
address 2.2.2.3
netmask 255.255.255.240
gateway 2.2.2.1

# Szervezet1 private - VLAN3
iface eth0.3 inet static
hw-mac-address aa:aa:aa:aa:00:03
address 10.3.3.2
netmask 255.255.255.0

# Szervezet2 public - VLAN4
iface eth0.4 inet static
hw-mac-address aa:aa:aa:aa:00:04
address 4.4.4.3
netmask 255.255.255.240
gateway 4.4.4.1

# Szervezet2 private - VLAN5
iface eth0.5 inet static
hw-mac-address aa:aa:aa:aa:00:05
address 10.5.5.3
netmask 255.255.255.0
up route add -net 10.10.10.0 netmask 255.255.255.0 gw 10.5.5.2
down route del -net 10.10.10.0 netmask 255.255.255.0 gw 10.5.5.2

Mindenképp kiemelt figyelemmel kezeljük, hogy a Linuxon ne legyen engedélyezve az IP forwarding, azaz ne routeoljuk össze a különböző VLAN-okat (/etc/sysctl.conf). A példa első sorában látható, hogy az eth0 fizikai interfészen bootolás után csak az eth0.3 lesz fent, a natív/default VLAN (eth0) be van ugyan állítva DHCP-re, de inaktív, ahogy a többi tagged VLAN interfész is az. Tehát a belső hálózatok közül a VLAN3-ban tudunk feljelentkezni a multi-VLAN hostunkra. Az eth0.2 vagy az eth0.4 felhúzásakor (pl.: ifup eth0.2) beállítódik egy default route az internet felé, így hozzáférünk bármilyen internetes hosthoz a Linuxról direkben, NAT nélkül. Értelemszerűen egyszerre nem érdemes mindkét internetes interfészt up-ban tartani. Amint lekapcsoljuk ezen interfészeket (ifdown eth0.2) újra csak a VLAN3-ból hoazzáférhető a Linux hostunk. A VLAN5 interfész szintén változtat a route-okon, amikor felhúzzuk , ám itt specifikusan csak egyetlen subnetet adunnk a route táblához, csak annyit, amennyi a VLAN5-ön keresztül csatlakozó távoli telephely eléréséhez szükséges. A VLAN interfészek egyedi, a VLAN ID-t is magában foglaló MAC címe természetesen nem kötelező, ha nem állítjuk át, akkor a fizikai interfész MAC-címét fogja használni minden virtuális interfészen.

Mire jó mindez? Diagnosztikai célokra például nem rossz. Bármelyik VLAN-on el tudjuk éri a hostokat konzolból, sőt szükség esetén SSH-val áthozhatunk magunknak ezt-azt más VLAN-okból anélkül, hogy a normál route-olást felborítanánk. Bármikor egyetlen helyről fel tudjuk mérni az egyébként közvetlenül nem összekapcsolt VLAN-okban a hostok számát nmap-pel, tshark-kal belenézhetünk akármelyik VLAN broadcast forgalmába. Meg tudjuk mondani az 5-ös VLAN-ban dolgozó kollegának, hogy vajon azért nem éri el a bérelt vonal túloldalán lévő szervert, mert megszakadt a bérelt vonal vagy csak azért, mert nem dugta be a gépébe a patchkábelt, és még sorolhatnám.

Azt viszont minden körülmények közt érdemes szem előtt tartani, hogy nem megfelelő biztonsági beállításokkal hatalmas réseket lehet nyitni hálózatunk védelmén egy ilyen konfigurációval.

Cisco, HP, 3Com, H3C, Huawei CLI referencia

2011-01-25T23:06:00.002+01:00

Gyanítom, az senkinek nem új hír, hogy a HP 2010-ben bekebelezte a 3Com-ot, azt viszont még a networkös szakmán belül sem szokás tudni, hogy a 3Com termékeken futó operációs rendszer, a 3Com OS gyakorlatilag megegyezik a Huawei eszközökön használt "Huawei Versatile Routing Platform Software" (VRP) rendszerrel, illetve a 3Com és a Huawei által még 2003-ban közösen gründolt H3C eszközein futó "H3C Comware Platform Software" (Comware) rendszerrel. Vagyis a 3Com OS, a Huawei VRP és a H3C Comware ugyanannak a network OS-nek változatai, nem különböznek jobban egymástól, mint a Cisco IOS különféle verziói: vannak bennük itt-ott apróbb eltérések, de ha valaki kiismeri magát a mondjuk a Comware-ben, az otthonosan fog mozogni a 3Com OS vagy a VRP alatt is. Sőt, a rokonság még ennél is szorosabb a volt 3Com, a jelenlegi Huawei, illetve a H3C termékek közt, az egyes termékeknek (persze nem mindnek) megvan (vagy volt) a maga testvére a másik két márka termékpalettáján, és ezek a testvérek bizony közös alkatrészeken is osztoznak. A kompatibilitás olyannyira létezik, hogy például e három márka SFP moduljai is csereszabatosak, használhatunk egy 3Com optikai modult Huawei vagy H3C eszközben és persze a dolog fordítva is igaz.

A HP megjelenésével tovább bővült ezt a nagyjából azonos hardver- és szoftverplatformot felhasználó márkák száma, a HP Networking termékek ezt a közös, illetve most már a HP tulajdonában lévő platformot használják. Csupa öröm egy ilyen platformot megtanulni, hiszen egycsapásra lehet bővíteni az önéletrajzunkat 3Com, Huawei, H3C és HP termékek ismeretével :). Ráadásul ebben a HP hatékony segítséget ad, most találtam rá a "HP Networking and Cisco CLI Reference Guide"-ra, amiben funkcióról funkcióra haladva összevetik a régi HP ProCurve termékeken futó ProVision, a 3Com-Huawei-H3C-HPN-féle Comware és a Cisco IOS parancsokat. A doksi kellően alapos, semmi sallang, nem próbálja megmagyarázni a különféle protokollokat, szabványokat, parancsok és példák gyűjteménye kevesebb mint háromszáz oldalon, kötelező minden networkös számára. Jó néhány évig még biztosan hasznát lehet venni, amíg el nem távolodik nagyon egymástól a régi 3Com-féle legacy rendszerek és a legújabb H3C/HPN rendszerek tudása.

Multi-VLAN bridge site-to-site VPN tunneleken Vyattával és OpenVPN-nel

2011-01-24T00:02:00.021+01:00

Többféle megközelítése lehetséges a VLAN-ok telephelyek közötti átvitelének, ebben a posztban egy, a Vyattában nem túl régóta meglévő opcióval, az OpenVPN-nel esek neki a problémának. Alapvetően tesztről van szó, és mivel nem akartam túlságosan elbonyolítani, ezért a tesztkörnyezetben a teljes layer 2 egyetlen switchen lakik, ezen az egy switchen van az egyik telephely két VLAN-ja, a másik telephely két VLAN-ja, és persze a WAN kapcsolatot helyettesítő VLAN is. Layer 3-as funkciók (a tesztklienseket leszámítva) csak a Vyatta hostokon találhatók, ezekben csupán egyetlen NIC van, így minden interfész vagy VLAN interfész lesz vagy valamilyen egyéb virtuális interfész. A cél, hogy a két telephely között a kliensek számára transzparens layer2-es bridge épüljön fel az alábbi topológiával:

A bemutatandó módszer lehetővé teszi a VLAN ID átírást, és mivel a tesztkörnyezet layer 2-ben csupán egyetlen switch, szükség is lesz erre, de éles környezetben természetesen lehet ugyanazokat a VLAN ID-ket használni a kapcsolat mindkét oldalán. V1 és V2 lesz a két Vyatta teszt host, mindkettő egyetlen fizikai interfészen keresztül kapja meg a tagged VLAN-okat. V1 esetében ez a VLAN1, VLAN2, VLAN3, az ezeknek megfelelő interfészek értelemszerűen: eth0.1, eth0.2, eth0.3. A beállítások hasonlóak V2 esetén is, ám itt a VLAN2 átalakul VLAN20-ra a VLAN3 pedig VLAN30-ra.

Mielőtt ténylegesen belekezdenénk a VPN konfigurációba, állítsuk be a legalapvetőbb dolgokat! Szükség lesz egy VLAN1 interfészre, azon IP-re, SSH-ra, és a hostnév beállítása sem árt (a prompt csak egy kijelentkezés-bejelentkezés után vált V1-re az alapértelmezett "vyatta"-ról):

vyatta@vyatta:~$ configure
[edit] 
vyatta@vyatta# set interfaces ethernet eth0 vif 1 address 10.1.1.1/24
[edit]
vyatta@vyatta# set system host-name V1
[edit]
vyatta@vyatta# set service ssh        
[edit]
vyatta@vyatta# commit 
Restarting OpenBSD Secure Shell server: sshd.
[edit]
vyatta@vyatta# save
Saving configuration to '/opt/vyatta/etc/config/config.boot'...
Done

A továbblépés előtt hasonló alapbeállítást igényel a V2-es Vyatta is. Ha megvagyunk, akkor jöhet a VPN: a site-to-site tunnelek felhúzásához az új OpenVPN-es Vyatta parancsokat fogjuk használni, és az egyszerűség kedvéért PSK-ra építünk. Ha jobban meggondolom, annyira azért nem új az OpenVPN a Vyattában, valamikor tavaly év elején került bele. Akárhogy is, a topológia megvalósításához két külön OpenVPN tunnelre lesz szükségünk, ezért a V1 alapbeállításai után az első feladat két kulcs létrehozása a V1-en, majd e két kulcs eljuttatása V2-re is. A kulcsok generálása a "vpn openvpn-key generate <fájlnév>" paranccsal történik:

vyatta@V1:~$ vpn openvpn-key generate /root/vtun0.key
vyatta@V1:~$ cat /root/vtun0.key
cat: /root/vtun0.key: Permission denied
vyatta@V1:~$ sudo cat /root/vtun0.key
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
0cbcd00265518db1fd8b4ded2e721396
2ee1ef306d1163b82df0b478462ae35b
5764e128b8c6f15931c2ad0d94f1a477
c7aab38ca570cc20b0aeb8da8056dd27
d70d4bdf9b705af8cfe2380f57a7c840
ae24f6a9a1f13d5da1ebc18025b8d575
dc4634625c051bfbf976b72a8f35bca5
238bd80f371df2bac0f48ccd26968917
9b86c7067bf6a927c217f81d6f6b6840
7e133cc4fc677175a5702f841b11be4e
8c56c0cfc08497d1e599162757ec848b
26f670842245af40f45670b3ef257adc
784aa1f6b1c27c83e969aab0edca8b6b
dead67a4bad7630f18838cb0871b1449
a686356a001e4d3c34ecc8743f7c6067
95027528e178fb73994241e6348c3977
-----END OpenVPN Static key V1-----
vyatta@V1:~$

Az első paranccsal legeneráltuk az OpenVPN PSK-t és azt a "/root/vtun0.key" fájlba mentettük. Tulajdonképpen mindegy is, hogy hová mentjük, a fájl "root:root","600" jogokkal jön létre, tehát kizárólag a root felhasználó tudja írni-olvasni, másoknak semmilyen jogosultsága nincs a fájlra, és ez jól is van így. A példában ezért nem működik elsőre a fájl tartalmának kiírása, másodszorra viszont rootként megyünk, sudo-val, ezért nincs ilyen probléma. A "vtun0.key"-hez hasonlóan generáltassunk egy "vtun1.key"-t is, ez lesz a másik tunnelhez a PSK. Ha megvannak a kulcsok, akkor SCP-vel átmásolhatjuk őket a V2-re (figyelem: a kulcsok csak a root számára olvashatók, viszont az SSH PermitRootLogin no-val fut, "sudo -i"-vel tudunk bash shellt nyitni rootként a megoldáshoz). Persze SCP helyett másolhatjuk vágólapon keresztül is a kulcsokat vagy USB-n, a lényeg, hogy ugyanazok a kulcsok legyenek fent mindkét Vyattán.

Ezek után létrehozhatjuk a V1-en az első site-to-site bridge kapcsolatot. Készítünk egy "br0" nevű bridge interfészt, amelynek a tagjai az "eth0.2" és a "vtun0" lesznek, majd beállítjuk az OpenVPN paramétereket. OpenVPN esetén szeretem kihasználni az IPSec-től eltérő adottságokat, ilyen például a Blowfish kódolás (bf128), ami - ha pusztán a szoftveres implementációkat vizsgáljuk, márpedig a Vyatta esetén csak ilyenünk van - minden létező teszt szerint gyorsabb az AES-nél, az öregecskedő 3DES-t pedig nem is érdemes egy lapon említeni vele. A "br0" és a "vtun0" beállítását a következő parancsokkal végezhetjük el a V1-en:

set interfaces bridge br0
set interfaces ethernet eth0 vif 2
set interfaces ethernet eth0 vif 2 bridge-group bridge br0
set interfaces openvpn vtun0 bridge-group bridge br0
set interfaces openvpn vtun0 encryption bf128
set interfaces openvpn vtun0 hash sha1
set interfaces openvpn vtun0 mode site-to-site
set interfaces openvpn vtun0 remote-host 10.1.1.2
set interfaces openvpn vtun0 shared-secret-key-file /root/vtun0.key

Alapvetően rendkívül hasonló lesz a "br1" és a "vtun1" is, azt az apróságot leszámítva, hogy itt az OpenVPN által alapértelmezetten használt egyetlen portot UDP 1194-ről eggyel feljebb, az UDP 1195-re tesszük mindkét oldalon (így külön datagram socketre épül a vtun1 és a vtun0), és persze az interfész nevek mások lesznek:

set interfaces bridge br1
set interfaces ethernet eth0 vif 3
set interfaces ethernet eth0 vif 3 bridge-group bridge br1
set interfaces openvpn vtun1 bridge-group bridge br1
set interfaces openvpn vtun1 encryption bf128
set interfaces openvpn vtun1 hash sha1
set interfaces openvpn vtun1 local-port 1195
set interfaces openvpn vtun1 mode site-to-site
set interfaces openvpn vtun1 remote-host 10.1.1.2
set interfaces openvpn vtun1 remote-port 1195
set interfaces openvpn vtun1 shared-secret-key-file /root/vtun1.key

A sok pötyögés után jöhet a "commit" majd a "save", és a V1-en készen is vagyunk. A V2 konfigurációja alig tér el a V1-től, "vtun0" esetén "vif2" helyett "vif20", "10.1.1.2" helyett pedig "10.1.1.1" szükséges. A V2 "vtun1" pedig "vif3" helyett "vif30"-at használ, illetve itt is 1-re végződik a VPN peer IP-je. Említettem az elején: nem feltétlenül kell átírni a V2-es Vyattán a VLAN ID-ket, a tesztkörnyezet azonban nálam csak egyetlen switchet tartalmazott layer2-ben. Ha készen vagyunk a beállításokkal, a VPN kapcsolatok állapotát a "show interfaces openvpn", illetve a "show interfaces openvpn detail" paranccsal ellenőrizhetjük, A bridge-ek állapotát a "show bridge br0" vagy "show bridge br1" paranccsal kérhetjük le.

Vyatta alapok

2011-01-21T16:59:00.004+01:00

Régebben, amikor még úgy gondoltam, hogy ismét felcsapok egy magyar IT portálon munkatársnak, már szemezgettem ezzel a network OS-szel, és többé kevésbé azóta is követem töretlen fejlődését, jómagam viszont mégsem csaptam fel semmilyen IT portálon semmiféle munkatársnak. A Vyattáról akkor leírtak ettől függetlenül természetesen továbbra is érvényben vannak, és a rendszer fejlesztőinek azóta sikerült rengeteg hasznos lehetőséget átemelni a Linux platformról a Vyatta által is támogatott elemek közé.

Nagyon sokat fejlődtek a 4-es verziók óta a VPN képességek, megjelent a WAN load balancing, jelentős átalakítás történt a tűzfal funkciókban, itt is átvették a más termékekben már jól bevált zóna koncepciót, és persze egyre több Vyatta funkció érhető el IPv6-on is. Az éppen aktuális 6.1-es Vyattában rettenetesen tetszik, hogy image-ként is lehet telepíteni, így csak a bootoláshoz szükséges fájlok és egy Squashfs image kerül fel a gépre, nem lesz rajta a hagyományos értelemben telepített Linux. Ezzel ismét egy lépéssel közelebb került a rendszer a hálózati eszközök világában megszokott konvenciókhoz. Több feltelepített image esetén boot menüben választhatunk a rendelkezésre álló "firmware"-ek közül. A rendszerhez egyetlen konfigurációs fájl tartozik, ebben a fájlban van a teljes konfiguráció, beleértve a szolgáltatásokat és azok paramétereit, a VLAN-okat, a userneveket, jelszavakat, tűzfalszabályokat, routeolási, NAT-olási beállításokat stb.

Gyorstalpaló az induláshoz:

Ha csak próbálgatni, tesztelni szeretnénk, nem kell telepítés, live CD-n terjesztik.
Bejelentkezés: user: vyatta, password: vyatta.
Ez nem hagyományos értelemben vett Linux, mindent el tudunk végezni a Vyatta shell saját parancsaival, ne küzdjünk a megszokott bash shellért. Ha ilyesmire vágyunk, egyszerűbb egy rendes Linuxot elővenni. Egyébként a legtöbb alapvető UNIX parancs elérhető a Vyatta shellből, csak nincs meg hozzá a tab-os autocomplete, így olyan, minta nem is létezne (a "help" paranccsal kérhető rövid összefoglaló a támogatott UNIX parancsokról).
Telepítéskor inkább az image alapú telepítést ("install-image" parancs) válasszuk, a régebbi módszernek ("install-system" parancs) csak akkor van előnye, ha módosítani szeretnénk a rendszer felépítésén, extra csomagokat akarunk használni, de ennyi erővel már telepíthetünk bármilyen Linuxot is, ehhez sem kell Vyatta.
CLI üzemmódok: operational mode ($ prompt), configuration mode (parancs: "configure", # prompt)
A konfiguráció hierarchikusan szervezett, node-okból és attribútumokból épül fel, a node-okat mindig kapcsos zárójellel {} határolt szövegrész követi, benne a node részleteivel, ami állhat újabb node-okból vagy attribútumokból. Pl:

service {
     ssh {
         port 22
     }
}

Konfiguráció lekérése operational módban: "show configuration", konfig módban: "show".
A beállítások tekergetése, módosítása (konfigurációs módban) mindig a "set" paranccsal kezdődik, utána felsoroljuk a node-okat amelyek mentén végül eljutunk a módosítani kívánt attribútumhoz (bizonyos esetekben elég csak a node-ot megadni: pl. "set service ssh"). Egy alap konfighoz, ami már lehetővé teszi a távoli adminisztrációt is SSH-n keresztül, a következő parancsokat kell kiadnunk:

set service ssh
set system host-name TESZT
set interfaces ethernet eth0 address 10.10.10.10/24
set system gateway-address 10.10.10.1

Konfiguráció törlése: ugyanúgy történik mint a a beállítás, ám "set" helyett "delete" a parancs eleje. Nemcsak attribútumokat, hanem teljes node-okat is törölhetünk egyben.
Az ilyen környezetben megszokott segítség (nyilak, tab, kérdőjel) itt is rendelkezésre áll, sőt a tab az általunk előzetesen már megadott értékekre, nevek, IP-címek, stb. is tudja az automatikus kiegészítést (sajnos nem minden node-on).
A módosított beállítások nem jutnak azonnal a parancs kiadása után érvényre. Konfigurálás közben bármikor megnézhetjük a konfigurációs fájl aktuális állapotát a "show" paranccsal. Azon sorok előtt, amelyeket frissen adtunk a konfigurációhoz és még nem részei az éppen futó beállításoknak egy "+" jel áll. Ugyanígy a törölt sorok előtt egy "-" jel áll.
A "commit" parancs konfigurációs módban aktualizálja a konfigurációs változásokat, és ténylegesen is beállítja a rendszert.
A "save" parancs menti a konfigurációt (hogy egy újraindítás után is meglegyen).
Konfigurációs módból való kilépés: "exit".

A szórási tartományok méretéről

2011-01-19T08:53:00.003+01:00

Néhány éve, amikor elkezdtem a jelenlegi munkahelyemen dolgozni, egyszerűen sokkolt a gondolat, hogy azon a telephelyen, ahol én is ügyködni fogok, teljesen strukturálatlan a LAN layer3-ban. Az adott telephely legtöbb munkaállomása, a notebookok, a nyomtatók, a szerverek, a termelési gépek, az ilyen-olyan célhardverek, biszbaszok, beágyazott rendszerek, a hálózati eszközök management felülete, a szerverek iLO/RMC portjai, de még a céges wifi is egyetlen nagy /21-es hálózatban élt egymás mellett.

Komolyan azt gondoltam, hogy itt vége a világnak, hogy ez maga a fertő, a networkös pokol. Persze tudtam, hiszen korábban az interjúk során is elmondták, hogy az alkalmazásom egyik oka épp ez, hogy vannak úgymond anomáliák ezen a telephelyen, amiket meg kellene oldani, és hogy addig nem volt teljes állásban hálózatos ember. Mondanom sem kell ugye, minden létező szakkönyv szerint ellenjavallt az ilyen bazi nagyra felhízlalt broadcast domain, amiben még a legcsendesebb éjszakákon is működget nagyjából 1000 host, de volt olyan időszak, amikor a /21-es hálózat 2000-es gépszáma is elérhető távolságba került.

Most már lassan három éve élek együtt ezzel a dinoszaurusszal a munkahelyemen, és persze az évek során számos dolog letisztult, nagyon sok host, sok munkával, szervezéssel külön VLAN-okba került, innen is csippentettünk egy kicsit, onnan is, ezeknek a hostoknak ilyen VLAN, amazoknak amolyan került, de alapvetően a harminc-egynéhány VLAN mellett a /21-es nagy hálózat ma is létezik, rengeteg benne a gazdátlan, fix IP-s host, melyek adminisztrációjával senki nem akar törődni, egészen addig, míg nincs vele valami baj, szóval a telephely életébe, működésébe szó szerint ezer szállal bele van fűzve a /21-es monstrum.

Azt gondolná az ember, hogy az elképzelhetetlen mennyiségű broadcast forgalom miatt itt nincs egyetlen ép host sem, de a helyzet valójában nem annyira vészes. A broadcast forgalom legnagyobb része egyébként az SMB/CIFS balgaságaiból adódik, rettenetesen szószátyár ez a protkollcsalád, és persze nálunk is SMB/CIFS-et natívan beszélő Microsoft OS-ek vannak leginkább a hostokon. De még ennek ellenére is az átlagos broadcast terhelés nagyából megáll 50-70 kbit/s környékén. Multicastot nem használunk, az egyetlen dolog, ami még rondíthat ezen az 50-70 kbit/s-on, az az elárasztásos (flood) forgalom. Ilyen floodként jelentkezik a switchek által nem ismert MAC-címre történő forgalmazás, amit a broadcast domain minden hostja megkap, mert a switch nem tudja, hogy melyik portjára switchelje, így kiteszi mindegyikre - sajnos vannak olyan "megoldások", amelyek építenek is erre az egyébként nem kívánatos jelenségre.

Hogy mit tapasztalhat az ember 50-70 kbit/s állandó broadcast mellett? Semmit. Nevetségesen kicsi ez a forgalom az elérhető 100 vagy 1000Mbit/s-os sebességhez viszonyítva, nincs érezhető, mérhető hatása a hostok működésére. Sajnos emiatt a döntéshozók sem értik meg az IP szegmentáció mielőbbi szükségességét. Biztos vagyok benne, hogy még csak nem is feszegetjük a technológia határait, és hogy egy hostokkal megpakolt /20-as vagy akár egy /19-es is működőképes lenne.

Azt azért nem állítom, hogy soha nincs gond egy ilyen méretű hálózattal alapvetően magára a méretére visszavezethető okok miatt. Egyszer például néhány kolléga úgy látta jónak, ha Norton Ghosttal, anélkül, hogy bármilyen hálózati támogatás lett volna hozzá, multicast üzemmódban terítenek image-eket néhány gépen. A switchek persze azonnal broadcastba fordították a multicast forgalmat, és tolták minden portjukon, ami csak a csövön kifért. Na, ezt már mindenki megérezte, 80 Mbit/s egy ekkora hálózat minden portján azonnal látványos eredmény ad. De ez egy extrém példa, és nem áll neki bárki multicast Ghost terítésnek, viszont látható, hogy ha a napi rutinfeladatokon nem is vérzik el a nagy szórási tartomány, biztonsági szempontból semmiképp nem javasolt.

Meggyőződésem, hogy amennyiben valaha is megszűnik ezen a telephelyen a /21, az biztonsági problémák miatt lesz. Gondoljunk csak bele, hogy egy ekkora szórási tartomány micsoda lehetőségeket tartogat a különféle layer2-es támadásokra, ARP spoofingra, STP támadásokra, de még egy egyszerű passzív broadcast forgalom gyűjtögetés is rengeteg értékes információval szolgál.Őszintén szólva nem is szeretek rá csatlakozni, inkább megyek wifin, ami azóta külön subnetbe került vagy remote access VPN-en (szintén külön subnet). Csak a kollégáim meg ne tudják... (tudják) :)

Szeretem a Cisco AP-k carrier busy tesztjét

2011-01-18T00:02:00.006+01:00

Régóta keresgélek alternatívát az autonóm Cisco AP-k IOS-ében rendelkezésre álló carrier busy tesztre. Na jó, talán még a keresgélek használata is túlzás, mondjuk úgy, hogy időnként elszontyolodom, hogy nincs (vagy nem tudok) hasonló dologról például a notebookomra, vagy mondjuk Androidra. Valami egyszerű kis parancssoros util megtenné, amivel gyorsan, könnyen lehet felmérni a teljes wifi tartomány layer1-es kihasználtságát.

A félreértések elkerülése végett: nem wifi analyzert keresek, ami grafikonokat rajzolgat az elérhető SSID-kről, csatornákról, és azokat tudja ilyen vagy olyan szempontok szerint rendezgetni, nem. A carrier busy teszt az IOS-ben ennél sokkal alapvetőbb, a fizikai rétegre vonatkozó teszt, ami azt vizsgálja meg, hogy van-e bármilyen, az AP rádióvevője számára érzékelhető forgalom a szabad frekvenciatartományban. Ez aztán lehet persze a szomszéd wifije, de lehet mikrosütő, rádiós kamerarendszer, vezeték nélküli telefon, bármi, ami interferálhat a wifi jelekkel. Ezzel a carrier busy teszttel tehát megállapítható, hogy az adott pillanatban van-e az adott AP környékén zavaró jelforrás, ami tönkre vághatja a wifi kommunikációt. Annyira nem részletes mint egy komplett spektrum analízis, de jól használható és a CLI elég hozzá.

Aki esetleg nem ismerné ezt a tesztet: a "dot11 <interfész> carrier busy" paranccsal futtatható, és mindössze néhány másodpercig tart, míg végigszkenneli a frekvenciatartományt. A parancs kiadásakor az AP-n természetesen minden kiépített wifis kapcsolat megszakad, az adott AP-n lógó klienseknek újra kell majd authentikálniuk stb. A lefutás után látszólag nem történik semmi, de a teszt eredményét a "show dot11 carrier busy" paranccsal egyetlen egyszer meg tudjuk jeleníteni. A példában látható, hogy nem egy rádiószmogos környéken lakik a teszt AP, a 6-os channelen valami csordogál (2427-2447), de például az 1-es (2402-2422) vagy a 11-es (2452-2472) nagyjából kihasználatlannak tűnik:

AP#dot11 dot11Radio 0 carrier busy
AP#show dot11 carrier busy

Frequency Carrier Busy %
--------- --------------
   2412          0
   2417          1
   2422          1
   2427          3
   2432          6
   2437          4
   2442          2
   2447          2
   2452          0
   2457          0
   2462          1
   2467          0
   2472          0
AP#show dot11 carrier busy
AP#

A "show dot11 carrier busy" ismételt használata semmilyen eredményt nem ad egészen addig, amíg meg nem ismételjük a carrier busy tesztet, ekkor az új eredményt - szintén csak egyszer - listázza. Nem egy spektrum analízis, de legtöbbször ennyi is megteszi. No, valami ilyesmit keresek időnként Linuxra, Windowsra vagy Androidra, és eddig még nem találtam.

Cisco IOS Netflow ingress, egress, v5, v9

2011-01-16T22:33:00.007+01:00

Korábban íram már egy postot Netflow ügyben, az egyik MPLS-szolgáltatónk sok-sok vesződség után sem tudta felkonfigurálni a routerét úgy, hogy az a WAN interfészéről mind a bemenő mind a kijövő forgalomról tudjon információt adni. Mennyire bonyolult egy ilyen dolog? Hát, annyira azért nem... Teljes, jól működő beállításra példa:

router(config)#interface FastEthernet 0/0
router(config-if)#ip route-cache flow
router(config-if)#exit
router(config)#interface FastEthernet 0/1
router(config-if)#ip route-cache flow
router(config-if)#exit
router(config)#ip flow-export destination 10.10.10.10 9999
router(config)#ip flow-export source FastEthernet 0/0
router(config)#ip flow-export version 5
router(config)#ip flow-cache timeout active 1
router(config)#ip flow-cache timeout inactive 15
router(config)#snmp-server ifindex persist

Az interfészenkénti "ip route-cache flow" parancsot minden olyan interfészen ki kell adnunk, amelyen az általunk figyelni és elemezni kívánt forgalom át fog haladni. Mindegyiken. Ennek az az oka, hogy az alapértelmezett Netflow v5 csak a bejövő adatokról gyűjt és továbbít bizonyos időközönként összesített forgalmi információt (flow-t). Ha tehát a routeremben pl. csak az Fa0/0 és az Fa0/1 interfész forgalmaz, akkor az Fa0/1 bejövő adatairól alapból lesz információm, viszont az Fa0/1 kimenő adatokról csak akkor, ha engedélyezve van a Netflow az Fa0/0-n is, és az Fa0/0 bejövő adatait tudja majd a Netflow collector szoftverem az Fa0/1 kimenő forgalom adatainak előállításához felhasználni. Vagyis minden releváns, a forgalmunk által érintett interfészen engedélyeznünk kell a Netflow-t, különben nem azt fogjuk kapni, amire számítunk.

Az "ip flow-export destination" globális konfigurációs módbeli paranccsal állítható be a Netflow forgalom célja, itt kell megadni azt az IP-t vagy hostnevet és portszámot ahol a Netflow adatokat gyűjtő szoftverünk (collector) fülel. A collectornak küldött csomagokban a forrás IP cím annak az interfésznek az elsődleges IP-je lesz, amelyet az "ip flow-export source" után megadunk.

Az "ip flow-export version" egyértelmű, az általunk használni kívánt Netflow verziót adhatjuk meg vele, a két leggyakrabban használt verzió az 5-ös és a 9-es.

A következő két parancs a router által kezelt flow-cache ürítésére (a flow-k collectorhoz való elküldésére) vonatkozik. Az "ip flow-cache timeout active" egy aktív, azaz rendszeresen frissített flow-cache bejegyzés maximális élettartamát adja percekben. A cégünknél használt Netflow Analyzer nevű collector például a max. egy perces élettartamot preferálja, az IOS alapértelmezett érték egyébként 30. Az "ip flow-cache inactive timeout" az inaktív flow-kra vonatkozó időzítő, amely a nem frissített (befejeződött az adott típusú forgalom) flow-cache bejegyzések esetén megadja, hogy az inaktív státuszba lépés után még meddig maradhat az adott flow-cache bejegyzés a cache-ben.

Mivel a Netflow collectorok általában SNMP-s hozzáférést is igényelnek kiegészítő információk beszerzéséhez, pl. router adatok, hostnév, interfész adatok, ezért érdemes az SNMP-t úgy beállítanunk a routeren, hogy egy esetleges újraindulás után az interfészeink ugyanazokat az SNMP interfész indexeket kapják (snmp-server ifindex persist).

Persze még van egy-két kanyar. Itt van mindjárt az alinterfészek kérdése. A "ip route-cache flow" engedélyezi a flow-k gyűjtését egy adott fizikai interfészen és annak minden alinterfészén. Ha kizárólag egy alinterfész adataira vagyunk csak kíváncsiak, akkor azt az adott alinterfészen az "ip flow ingress" paranccsal aktiválhatjuk.

A Netflow v5 és v9 közötti egyik fontos különbség, hogy a v5 - ahogy arról már volt szó - csak ingress irányt támogat, míg a v9 használata esetén megnyílik a lehetőségünk az egress irányú flow-k gyűjtésére is, vagyis v9 esetén akár elfelejthetjük azt a v5-nél még obligát szabályt, hogy minden interfészen engedélyeznünk kell a Netflow-t. Az egress irányú flow gyűjtéséhez szükséges az "ip flow-export version 9", illetve az interfészen az "ip flow egress" parancs kiadása.

Nem árt továbbá, ha figyelünk az "ip flow-export source" interfész megadásánál. Ha fizikai interfészt adunk meg, számolnunk kell azzal az eshetőséggel, hogy az interfész (bármilyen okból) leesik. Ekkor a Netflow collectorunk hibaüzenetet küldhet, még akkor is, ha egyébként maga az eszköz elérhető marad alternatív útvonalon. Megoldás? Az ip flow-export source is elfogad loopback interfészt.

Végül pedig, visszatérve a szolgáltatónkra: körülbelül három hét levelezés és 5-6 telefonhívás után feladtam. Egy kivételével minden általuk adott routeren jól működik a Netflow, az az egy pedig, ami továbbra is csak az egyik forgalmi irányról ad flow-kat, úgyis csak egy backup router. Egyszerűen belefáradtam, csináltak ők mindent, volt router újraindítás, IOS frissítés, Netflow konfig törlés és újrakonfigurálás, másik mérnök újra ellenőrizte, majd egy harmadik, egyszer még egy fél órára jól is ment a Netflow még ezen az egy routeren is, de mire elért a szolgáltatóhoz a "most jó, ne keressétek tovább a hibát" üzenet, már továbbléptek. Az utolsó állapot az volt, hogy v9 használata mellett a router minden portjáról jön ingress és egress adat, kivéve azt a portot, amit tényleg figyelni szeretnék. Nem tudom, hogy mi lehet vele baj, nincs rálátásom a konfigurációjukra, lehet, hogy én sem tudnám megjavítani. Persze az emberben mindig ott motoszkál ilyenkor az a fura érzés, hogy esetleg nem is próbálták ezt annyira komolyan megoldani. Akárhogy is, nem számít már.

TCP/UDP session timeout értékek beállítása FortiOS-ben

2011-01-13T15:58:00.000+01:00

A közelmúltban egy különös problémára sikerült megtalálni a megoldást. Az egyik telephelyünkön az ERP rendszer felhasználói egyik napról a másikra elkezdtek panaszkodni, hogy mindig kidobja őket a rendszer, és hogy naponta hússzor bejelentkezni nem vicces. Persze nem is hozzám került első körben a probléma, megjárta az ERP rendszerünkért felelős outsourcing partnert, és csak utána került a hálózatos csapathoz.

Annyit érdemes tudni az ERP-nkről, hogy egy özönvíz előtti, kb. tizenöt éves Baan verziót (IV) használunk. Az összes Baan szerverünk és adatbázisunk a Global Data Centerünkben van, a szóban forgó telephelyen pedig csak kliensek vannak, így minden ERP-vel kapcsolatos forgalom át kell, hogy menjen a belső WAN-unkon. Ezen kívül pedig volt még két másik tényező is: a kérdéses telephelyen a bérelt vonalat új szolgáltatóhoz vittük, illetve két héttel később belső tűzfal is került a csomagok útjába.

Mivel az adott telephelyen én felügyeltem a bérelt vonal migrációját illetve a tűzfal telepítést, megnyertem a Baan kliensek problémáját is. Az új szolgáltatót, mint problémaforrást viszonylag hamar ki lehetett zárni, hiszen az új vonal üzembe helyezése és a tűzfal telepítése közt eltelt két hétben a Baan kliensek hasítottak, bejelentkeztek reggel, kijelentkeztek délután, nem panaszkodott senki eldobált sessionökre.

Ideiglenes megoldásként a szerveres csapattal összefogva azt a megoldást javasoltuk első körben az adott telephely Baan usereinek, hogy akiket valóban zavar, hogy nem él egész nap a sessionjük, azok használják a Global Data Centerünkben frissen telepített Windows Server 2008 alapú új terminál szerver szolgáltatást, amin fent van a Baan kliens is, kiváló, gyors (LAN) kapcsolatuk lesz az adatbázissal, stb. Közben Baan forgalomra készíttettem az MPLS szolgáltatónkkal QoS-t, hátha... persze ehhez túl sok reményt nem fűztem, de mindenesetre egyértelműen monitorozhatóvá vált, hogy van-e gond az ERP-vel kapcsolatos adatforgalommal az MPLS-ünkben, hát nem volt.

Mondanom sem kell, minden egyéb forgalom tökéletesen rendben volt, nem volt gond a WAN-on keresztül az RDP sessionökkel, CIFS-sel, HTTP-vel, semmivel, csak a Baan4 gyengélkedett. Az adott telephely LAN-jában sem történtek változások, a fizikai réteggel kapcsolatos problémákat (laza patch kábel, vacak optikai kapcsolat LAN gerincen stb.) szintén gyorsan ki lehetett szórni, mint lehetséges problémaforrásokat. Maga a Baan IV kliens program sem egy bonyolult jószág, nincsenek speciális TCP beállításai, amelyek változása esetleg okozhatna hasonló jelenséget. Volt egy zsákutca még a kliensek védelmét ellátó Symantec SEP csomaggal, hátha ott valamilyen félresikerült policy kavar be... de nem, SEP nélkül is hullottak a sessionök, ha magukra hagyták őket a userek.

Időközben a belső tűzfalas projekt futott tovább, és hogy, hogy nem egy másik telephelyen is felmerült ugyanez a gond a Baan kliensekkel nem sokkal az ottani Fortigate tűzfal cluster telepítése után. Innen már viszonylag egyszerű volt a végkövetkeztetést levonni: a Fortigate-eken akadnak fenn a Baan sessionök. Valamiért a Baan IV TCP keepalive kezelése (ha van egyáltalán ilyesmije) nem kerek, és a Fortigate tűzfalak némi inaktivitás után egyszerűen eldobják a sessiont, szegény kliens meg csak áll, és nem érti, hogy ki vette el tőle az ő kis kapcsolatát a szerverhez.

De mit lehet ezzel kezdeni? Van ugyan a FortiOS-ben egy "system session-ttl" parancs, amivel minden (!) TCP és UDP sessionön meg lehet növelni a keepalive értéket, de ezzel ugye viszonylag hamar le lehet térdeltetni a tűzfalat, hiszen annak sem végtelenek az erőforrásai. Kiderült, hogy a FortiOS 4.0-ban viszont már nem csak system szinten, hanem firewall rule-onként lehet TTL-t állítani ("set session-ttl <másodperc>" az adott rule-on belül). Szóval a megoldás mindenhol az lett, hogy a Fortigate-eket frissíteni kell legalább 4.0-ra, majd egy külön rule készült a Baan forgalomra, amelyben a session-ttl értéket be kell lőni 28800-ra (8 óra). A tanulság? A tűzfal még akkor is tud nagy gondot okozni, ha egyébként tisztességgel átengedné a kérdéses forgalmat.

A legjobb szolgáltató

2011-01-11T13:16:00.004+01:00

Alapvetően nem szeretném, ha a blog szolgáltatók vagy termékek fikázásáról szólna, de a mai esetet muszáj megírnom. A cégünknél az összes telephely esetén a külső tűzfalak, illetve a s2s VPN hálózat üzemeltetése ki van szervezve. Nos, ettől a cégtől kerestek ma telefonon, hogy nem érik el az egyik telephelyünkön az eszközüket, és hogy tudok-e erről valamit.

A kérdéses telephelyen kizárólag s2s VPN van, semmilyen egyéb bérelt vonali kapcsolat nem áll rendelkezésre. Kicsit furcsálltam azonban a dolgot, mert a telephelyen lévő monitorozott hostok mindegyike elérhető volt, semmilyen riasztást nem kaptunk kapcsolódó problémákról, szóval, semmi jelét nem láttam annak, hogy bármilyen probléma lenne az ottani tűzfallal vagy a VPN tunnellel.

Nem is volt, az egyetlen gond az volt, hogy a szolgáltatás kb. egy hónappal ezelőtti telepítése óta a külső cég nem készített az adott eszközön magának management VPN tunnelt, pedig ezt annak idején a kollégám nyomatékosan kérte tőlük, épp azért, hogy ne legyen probléma a tűzfal általuk történő adminisztrációjával. Ma viszont valamilyen különös okból kifolyólag észrevették ezt problémát.

Ezek után tehát felhívnak telefonon, hogy valószínűleg megállt az adott telephelyen a szolgáltatásuk, és hogy tapasztalunk-e bármilyen problémát? Mondom a servicedeskesüknek, hogy nem, sőt a VPN és a tűzfal szolgáltatás is üzemel a saját monitorozó rendszereink adatai alapján. "Hm... ez igazán jó hír" - jött a válasz - "Elnézést a zavarásért. Annyit még tudna segíteni, hogy mi a külső IP címe az adott telephelyen az eszközünknek?".

No, az hiszem, ennél a pontnál foszlott szét minden kiszervezett szolgáltatásba vetett hitem, ha volt ilyesmim egyáltalán, hiszen a szolgáltató a szolgáltatásával kapcsolatos alapvető adatokat, dokumentációkat nem ismeri (pl. külső IP cím), nem képes monitorozni azt a saját rendszerivel (management VPN tunnel hiánya), ráadásul a saját eszközével kapcsolatos probléma elhárításához tőlem, az ügyféltől kér segítséget... és persze a negyedév végén mindezért benyújtja a számlát is. Ez a tökéletes üzleti modell, valóságos aranybánya, ilyet szeretnék magamnak én is.

HyperTerminal? Minicom!

2010-12-21T14:29:00.001+01:00

Sosem szerettem igazán HyperTerminalt, a Vista óta nem is része a Windows-nak, meg aztán jómagam inkább a Linux felé húzok, így nem meglepő, hogy egy-egy friss Linux telepítésen az első extra csomagok közé be szokott kerülni a Minicom. Ennek a programnak nincs grafikus felülete, ám gyakorlatilag mindennel tud kommunikálni, ami soros átvitelt használ, szóval ideális, akár egy rescue CD-ről is beindítható szöveges üzemmódban. Az első futtatáskor érdemes root-ként bekonfigurálni a soros eszközünkhöz (nálam ez például egy ATEN UC232A USB-Serial konverter), illetve beállítani az adatbit-paritás-stopbit hármast a minicom -s paranccsal.

   +-----------------------------------------------------------------------+
    | A -    Serial Device      : /dev/ttyUSB0                              |
    | B - Lockfile Location     : /var/lock                                 |
    | C -   Callin Program      :                                           |
    | D -  Callout Program      :                                           |
    | E -    Bps/Par/Bits       : 9600 8N1                                  |
    | F - Hardware Flow Control : Yes                                       |
    | G - Software Flow Control : No                                        |
    |                                                                       |
    |    Change which setting?                                              |
    +-----------------------------------------------------------------------+
            | Screen and keyboard      |
            | Save setup as dfl        |
            | Save setup as..          |
            | Exit                     |
            | Exit from Minicom        |
            +--------------------------+

Ha készen vagyunk a beállítással, akkor azt a "Save setup as dfl" menüponttal el is tudjuk menteni, a minden felhasználóra érvényes rendszerszintű alapbeállítások az /etc/minicom/minirc.dfl fájlba kerülnek:

root@futoszalag:~# cat /etc/minicom/minirc.dfl 
# Machine-generated file - use "minicom -s" to change parameters.
pu port             /dev/ttyUSB0
pu baudrate         9600
pu bits             8
pu parity           N
pu stopbits         1

Ezek után egy tisztességes rendszeren már mezei felhasználóként is el tudjuk indítani a minicom programot mindenféle kapcsolók nélkül, és a szokásos módon dolgozgathatunk konzolban. Ha épp olyan eszköz akad a kezünkbe, amelyik másféle soros beállítást igényel, felülvághatjuk a default beállításainkat parancssori kapcsolókkal vagy készíthetünk alternatív konfig fájlt, esetleg userként beállíthatjuk menün keresztül a "minicom -s"-sel. Futás közben a rendelkezésre álló parancsok listáját a Ctrl-A egyidejű lenyomását követően a "z" gombbal hívhatjuk elő:

+-------------------------------------------------------------------+
|                     Minicom Command Summary                       |
|                                                                   |
|          Commands can be called by CTRL-A <key>                   |
|                                                                   |
|               Main Functions                  Other Functions     |
|                                                                   |
| Dialing directory..D  run script (Go)....G | Clear Screen.......C |
| Send files.........S  Receive files......R | cOnfigure Minicom..O |
| comm Parameters....P  Add linefeed.......A | Suspend minicom....J |
| Capture on/off.....L  Hangup.............H | eXit and reset.....X |
| send break.........F  initialize Modem...M | Quit with no reset.Q |
| Terminal settings..T  run Kermit.........K | Cursor key mode....I |
| lineWrap on/off....W  local Echo on/off..E | Help screen........Z |
| Paste file.........Y                       | scroll Back........B |
|                                                                   |
|      Select function or press Enter for none.                     |
|                                                                   |
|             Written by Miquel van Smoorenburg 1991-1995           |
|             Some additions by Jukka Lahtinen 1997-2000            |
|             i18n by Arnaldo Carvalho de Melo 1998                 |
+-------------------------------------------------------------------+

Kilépni a Ctrl-A x kombinációval tudunk.

Expect

2010-12-20T11:06:00.004+01:00

Előfordul, hogy nincs jobb megoldás a kézi vezérlésnél, mert a központi management eszközben nincs olyan opció, amire szükségünk lenne, vagy van ugyan valami hasonló, de nem pontosan azt csinálja. Ilyenkor aztán marad az SSH, Telnet, command line. Viszont ha sok eszközön kell ugyanazt bepötyögni, hát, az bizony lélekölő feladat, nem is szívesen kezdek ilyesmibe. Helyette jöhet az Expect. Ez egy remek kis linuxos program, amivel bármilyen parancssoros interaktív kommunikációt le lehet szkriptelni, készíthetünk elágazásokat, használhatunk változókat, meghívhatunk külső programokat, igazi svájci bicska.

További magyarázatok helyett álljon itt egy példa, amely bejelentkezik Linux alól egy Cisco eszközre SSH-n keresztül (spawn ssh -l $ap_user $ap_ip) és beállít ezt-azt. Ha még soha nem jelentkeztünk be erre az eszközre, akkor ugye meg kell erősítenünk, hogy tényleg elfogadjuk azt az RSA kulcsot, amit az SSH szerver küld a kliensünk számára, viszont ilyesmire csak az első bejelentkezésnél kér minket az SSH kliens, minden további bejelentkezésnél a szerver RSA kulcsát a saját kis "known_hosts" fájljában lévő kulccsal veti össze, és nem kérdez alapból semmit. A kilencedik sor ezt a helyzetet kezeli le, küld egy "yes"-t, ha még nem látott ilyen RSA kulcsot, ellenkező esetben pedig csendben timeoutol az ötödik másodperc után és folytatja a következő sorral. Maga a konfiguráció egyébként, amit a szkript elvégez, az egy új, "minta" nevű SNMPv3 user felvétele a "MINTAcsoport" nevű SNMPv3 group-ba, illetve a hozzá tartozó jelszó beállítása, majd a teljes konfiguráció mentése:

#!/usr/bin/expect

set ap_user [lindex $argv 0]
set ap_pass [lindex $argv 1]
set ap_ip [lindex $argv 2]
set timeout 5

spawn ssh -l $ap_user $ap_ip
expect "Are you sure" { send "yes\r"} timeout {}
expect "password:"
send "$ap_pass\r"
expect "#"
send "conf t\r"
expect "(config)#"
send "snmp-server user minta MINTAcsoport v3 auth md5 MINTAjelszo\r"
expect "(config)#"
send "exit\r"
expect "#"
send "copy run start\r"
expect "Destination"
send "\r"
expect "#"
send "exit\r"
expect "closed"

A kódból látható, hogy ezt a szkriptet változókkal kell meghívni, a szkript neve után meg kell adnunk az admin user nevét, jelszavát, majd azt az IP-t is, ahová be szeretnénk jelentkezni. Ez a megoldás jelentősen megkönnyíti az expect szkriptünk ciklusból való meghívását, így ugyanis könnyen fabrikálhatunk olyan shell szkriptet köré, amivel minden adminisztrálandó eszközünkön el tudjuk végezni a kérdéses feladatot.

RJ45-ös loopback dugók

2010-12-16T15:20:00.002+01:00

Eljön szinte minden hálózati eszköz életében az a pillanat, amikor kifaggatják arról, hogy vajon hardver szinten rendben van-e rajta ez vagy az az interfész. A hálózati interfészek fizikai tesztjét a legegyszerűbben hurkolással, avagy loopback teszttel lehet letudni, minden loopback teszt lényege, hogy közvetlen, passzív TX-RX összeköttetést hozunk létre az áramkörön, az eszköz így elhiszi nekünk, hogy ő most valamilyen fizikai réteghez kapcsolódik, pedig valójában nem is. Érdemes megjegyezni, hogy ennek a fizikai loopback tesztnek nem sok köze van a TCP/IP stackekben implementált virtuális loopback interfészhez (127.0.0.1), az layer3, mi pedig most layer1-ben mocorgunk.

RJ45-ös dugó esetén eddig kétféle loopback bekötéssel találkoztam, az egyik Ethernethez való, a másik E1-es interfészekhez. Ethernet esetén a bekötés a következőképp alakul: 1-es eret visszahurkoljuk a 3-asra, a 2-est pedig a 6-osra. E1 esetében az 1-es a 4-esre a 2-es pedig az 5-ösre van kötve. Részletes E1 hard loopback útmutatót találhatunk egyébként a Cisco technote-ok közt.