Így építettem hálózatot otthon – 2. rész

Így építettem hálózatot otthon – 2. rész

Az előző részben felvázoltam, milyen evolúciós fejlődésen ment keresztül a hálózatom. Most a technikai kivitelezését fogom bemutatni.

Első körben én szeretem a MikroTiket teljesen alaphelyzetbe állítani. Ezt azért csinálom így, mert ilyenkor biztos lehetek benne, hogy nem marad a konfigurációban semmilyen olyan részlet, ami később a rendszer működését befolyásolhatná, vagy nem a várt működést eredményezné.

Már jártam úgy, hogy egy korábban létrehozott tűzfalszabály felülbírálta az új szabályaimat, ezért a rendszer nem úgy működött, ahogy vártam. Ugyanez igaz a DHCP-, IP- vagy interface-beállításokra is. Ha ezekből bent marad egy régi konfigurációs elem, később nehezen felderíthető hibákat okozhat.

Miért nem használom a MikroTik gyári konfigurációját?

Egyrészt azért, mert szeretem pontosan tudni, mi került fel a routerre. Másrészt a teljesen saját konfiguráció hosszú távon sokkal könnyebben dokumentálható, hibakereshető és bővíthető.

Jómagam Winboxot használok, és azon belül a terminálba írva futtatom a parancsokat.

Szóval reseteljük le a routerünket:

Ekkor kidob minket a routerből, majd újraindul. Mivel ilyenkor a routernek még nincs IP-címe, a Winbox segítségével a MAC-címe alapján tudunk ismét csatlakozni hozzá.

Nyissuk meg a Neighbors fület, ahol látnunk kell a felfedezett eszközt.

A listában látszani fog a router MAC-címe, mellette pedig az, hogy nincs IP-címe.

Ebben az esetben kattintsunk a MAC-címre. Ekkor a felső Connect To mezőben automatikusan megjelenik a router MAC-címe.

Ezután adjuk meg a felhasználónevet.

Itt már van eltérés a régebbi és az újabb MikroTik eszközök között. A korábbi modelleknél elegendő volt az admin felhasználónév és az üres jelszómező, míg az újabb készülékek alján megtalálható a gyárilag beállított felhasználónév és jelszó. Ebben az esetben ezekkel az adatokkal tudunk bejelentkezni.

Sikeres bejelentkezés után első lépésként ki kell alakítanunk a switch portjainak szerepét.

A MikroTik nagyon rugalmasan kezeli a portok funkcióit. Egy port lehet önálló interfész, lehet egy bridge tagja, vagy akár trunk és access portként is működhet. Éppen ezért szeretjük ezt a rendszert, hiszen nagyon sokféle hálózati topológia kialakítható vele.

Jómagam mindig úgy kezdem a konfigurációt, hogy először eldöntöm, melyik fizikai portnak mi lesz a feladata.

Jelen esetben egy klasszikus router felépítésre lesz szükségünk, amely egy WAN portból és több LAN portból áll.

Hogy melyik portot mire érdemes használni, azt célszerű még a konfiguráció megkezdése előtt eldönteni. Ehhez érdemes megnézni az adott RouterBOARD blokkdiagramját, mert abból sok fontos információ kiderül, például az egyes portok közötti kapcsolat vagy azok maximális átviteli sebessége.

Esetünkben a RB4011 blokkdiagramja a következő:

A blokkdiagram alapján látható, hogy a routerben két külön switch chip található, amelyek egyenként öt-öt Ethernet portot szolgálnak ki. A két switch chip nem közvetlenül kapcsolódik egymáshoz, hanem a CPU-n keresztül kommunikálnak, amely mindkét switch chiphez egy 2,5 Gbit/s-os kapcsolaton csatlakozik.

Ezért érdemes úgy megválasztani a routerre csatlakozó eszközöket, hogy amennyiben lehetséges, a nagy forgalmat generáló eszközök – például a NAS és a kliensgépek – ugyanarra a switch chipre kerüljenek.

Amennyiben a kommunikáció ugyanazon a switch chipen belül történik, a forgalmat maga a switch ASIC kapcsolja, így a CPU-nak nem kell a csomagokat feldolgoznia. Ez a MikroTik által használt hardware offload működése.

Ez természetesen nem azt jelenti, hogy a CPU teljesen kimarad a működésből. A routing, a tűzfal, a DHCP és minden egyéb szolgáltatás továbbra is a processzor feladata. Egyszerűen a switch chipen belüli Layer2 forgalmat nem neki kell feldolgoznia.

Nálam például kezdetben az asztali gépem és a szerver ugyanabba a portcsoportba volt csatlakoztatva.. Így amikor NFS-en keresztül másoltam adatokat a szerverre, a forgalom a switch chipen belül maradt, és nem terhelte a router processzorát. a kisebb hálozati forgalommal bíró wifi ap-k meg a másik portcsoportba voltak csatlakoztatva, ott a sávszélesség miatt nem igazán volt fontos, plusz általában okostelefon és egyéb olyan eszköz volt csatlakoztatva ami esetében nem volt szükség a hálózati meghajtóra.

Egy RB4011 esetében ez ugyan már kevésbé kritikus, hiszen a benne található négymagos processzor bőséges teljesítménytartalékkal rendelkezik, de szerintem érdemes már a hálózat tervezésekor figyelembe venni ezeket a szempontokat, főleg ha régebbi vassal dolgozunk mint pl az RB2011, ahol ráadásul a 1-5 portcsoport 1Gb/s a 6-10 portcsoport meg 100Mb/s sebességű, és a blokkdiagramm teljesen más blokkséma alapján épül fel.

Egy kis történelmi kitérő
Ha már a MikroTik switch chipjeinek működéséről beszélünk, érdemes röviden kitérni arra is, hogy a portok hardveres kapcsolásának konfigurációja korábban másképpen történt.

A RouterOS 6.41 előtti verziókban az egy switch chiphez tartozó Ethernet-portok közül kijelöltünk egy úgynevezett master portot, a többi portot pedig ehhez rendeltük hozzá. Az így összekapcsolt portok közötti Layer2 forgalmat a switch chip továbbította, tehát nem a CPU végezte a csomagok szoftveres kapcsolását.

Egy korabeli konfiguráció például ehhez hasonlóan nézett ki:

Ebben a példában az ether2 volt a master port, az ether3–ether5 portok pedig ugyanahhoz a hardveresen kapcsolt portcsoporthoz tartoztak.

A RouterOS 6.41-es verziójában a MikroTik megszüntette a master-port tulajdonságot, és bevezette az új, hardveres offloadot támogató bridge-megvalósítást. Frissítéskor a korábbi master-port konfigurációkat a rendszer bridge-konfigurációvá alakította át. Ettől kezdve a fizikai portokat egy bridge-hez adjuk hozzá, és megfelelő hardvertámogatás, valamint megfelelő konfiguráció esetén a switch chip továbbra is hardveresen végzi a Layer2 kapcsolást.

Fontos, hogy a Switch menü nem tűnt el ezzel együtt. Bizonyos switch-chip-specifikus funkciók továbbra is ott konfigurálhatók, az eszköz típusától és a benne található switch chiptől függően. A változás elsősorban az volt, hogy a hagyományos portkapcsolás konfigurációja a master-port modell helyett bridge-alapúvá vált.

A bridge portjai mellett megjelenő H jelzés mutatja, hogy az adott porton engedélyezett a hardware offload. Ez azonban önmagában még nem jelenti azt, hogy az eszköz minden bridge- vagy VLAN-funkciót képes hardveresen kezelni; ez mindig az adott switch chip képességeitől és a használt konfigurációtól függ.

Nálam a konfiguráció úgy néz ki, hogy az ether1 látja el a WAN szerepét, míg az ether2–ether10 portok egy közös bridge tagjai, amelyek a belső LAN hálózatot alkotják.
Bridge létrehozása:

A következő lépésben építsük fel ezt a bridge-et, majd erre építjük fel a teljes VLAN struktúrát.

A VLAN filteringet mindig akkor kapcsoljuk be, amikor már minden szükséges VLAN- és portbeállítás elkészült, legalábbis én így szoktam.

Nevezzük el az ethernet 1 et wan nak.

és hamár itt vagyunk akkor állitsuk is be dhcp kliensre:

Mit jelentenek ezek?

• interface=WAN – ezen az interfészen kér IP-címet.
• add-default-route=yes – a szolgáltatótól kapott alapértelmezett útvonalat automatikusan felveszi.
• use-peer-dns=no – nem veszi át a szolgáltató DNS szervereit. Később úgyis saját DNS-t (pl. AdGuard Home) fogunk használni.
• use-peer-ntp=yes – átveszi a szolgáltató NTP szerverét. Ez általában hasznos.
• disabled=no – engedélyezett állapotban jön létre.

Annyi informáciot még hozzátennék, hogy az én esetemben telekomos hálozaton a szolgáltato ONT eszközének lan portján ülök, dmz és fix ip beállitással. Bár megtehetném hogy kérem a bridge módot az ONT eszközre, de jártam már úgy hogy valami oknál fogva beállt alaphelyzetbe a szolgáltató eszköze. Viszont így dupla nat van ami nem elegáns, de legalább működik.


Haladjunk tovább hozzuk létre a vlan-okat a lan bridge-re.


ha minden jol csináltunk akkor látni lehet a winboxban az interface menűben a létrehozott inerface-ket amiknek a szülője a LAN interface.

A következő lépésben hozzuk létre az ip-cimeket:

A bridge-re is adok egy IP-címet. Ez szolgál a router menedzsmentjére, így szükség esetén akkor is el tudom érni az eszközt, ha a VLAN-konfiguráció még nincs teljesen elkészítve. A későbbiekben természetesen a menedzsmentet át lehet helyezni egy külön VLAN-ba is, de jelen konfigurációban ez a hálózat látja el ezt a feladatot. Továbbá a címzést úgy alakítottam ki, hogy az IP-hálózatok kövessék a VLAN azonosítóit. Így például a 8-as VLAN a 192.168.8.0/24, a 14-es VLAN a 192.168.14.0/24 hálózatot használja. Ez nem műszaki követelmény, egyszerűen egy olyan rendszer, ami évekkel később is átlátható marad.

A Bridge VLAN tábla – Tagged és Untagged portok

Miután beállítottuk a portok PVID értékét, következhet a Bridge VLAN tábla. Ez az a rész, ahol megmondjuk a switchnek, hogy egy adott VLAN mely portokon jelenhet meg, és milyen formában.

A Bridge VLAN tábla minden VLAN-hoz kétféle portot különböztet meg:

• Tagged
• Untagged

Tagged port

A tagged portokon a VLAN-címke megmarad. Ezeket a portokat olyan eszközök felé használjuk, amelyek képesek VLAN címkéket kezelni.

Tipikus példák:

• switch–switch kapcsolat (trunk)
• switch–router kapcsolat
• switch–hypervisor kapcsolat (VMware, Proxmox, KVM)
• switch–Wi-Fi Access Point kapcsolat, ahol több VLAN is közlekedik

Egy trunk porton egyszerre több VLAN is áthaladhat. A fogadó eszköz a VLAN-címke alapján tudja eldönteni, hogy az adott csomag melyik hálózathoz tartozik.

Untagged port

Az untagged portokon a switch eltávolítja a VLAN-címkét, mielőtt elküldi a csomagot.

Erre azért van szükség, mert a legtöbb végberendezés – például egy számítógép, nyomtató vagy IP kamera – nem ismeri a VLAN-okat. Ezek egyszerű Ethernet kereteket várnak.

Amikor egy kliens csatlakozik egy access portra, számára teljesen láthatatlan, hogy a háttérben VLAN-ok működnek. A switch végzi el helyette a címkézést és a címke eltávolítását.

Hogyan működik?

Egy access port esetén a folyamat a következő:

Bejövő irány (Ingress)

A kliens egy címke nélküli Ethernet keretet küld. A switch a port PVID értéke alapján eldönti, melyik VLAN-hoz tartozik a keret, és belsőleg hozzárendeli azt a megfelelő VLAN-hoz.

Kimenő irány (Egress)

Amikor ugyanennek a VLAN-nak a forgalma visszatér erre a portra, a Bridge VLAN tábla alapján a switch eltávolítja róla a VLAN-címkét, majd így küldi el a kliensnek.

A végberendezés ebből semmit sem vesz észre.

Konfiguráció

Az alábbi példában az ether5 egy access port lesz a 20-as VLAN-ban, míg az ether1 trunk portként működik.

Első lépésként állítsuk be a PVID értékét:

Ez a beállítás azt mondja a switchnek:

Ha az ether5 portra egy címke nélküli Ethernet keret érkezik, akkor azt tekintsd a 20-as VLAN részének.

Ezután vegyük fel a Bridge VLAN táblába:

• a bridge1 (CPU port) tagged tagja a 20-as VLAN-nak, így maga a RouterOS is képes kommunikálni ezen a VLAN-on (DHCP, IP-cím, routing stb.),
• az ether1 trunk portként továbbítja a 20-as VLAN forgalmát VLAN-címkével,
• az ether5 access portként működik, ezért a kliens felé a VLAN-címke eltávolításra kerül.

A klasszikus csapda

Van egy tipikus hiba, amibe szinte mindenki belefut az első VLAN-konfiguráció során.

Beállítod, hogy az ether5 untagged tagja legyen a 20-as VLAN-nak, de elfelejted átállítani a port PVID értékét. A PVID marad az alapértelmezett 1.

Ennek eredményeként a kliens által küldött címke nélküli csomagok továbbra is az 1-es VLAN-ba kerülnek. Hiába szerepel a port a VLAN táblában untaggedként, a forgalom már a beérkezés pillanatában rossz VLAN-ba kerül.

Tanulság

Egy access port csak akkor működik helyesen, ha a PVID és a Bridge VLAN tábla untagged beállítása ugyanarra a VLAN-ra mutat.

Ha például:

• PVID = 20
• VLAN 20 → Untagged = ether5

akkor a kliens számára teljesen átlátszó módon fog működni a 20-as VLAN. A bejövő forgalom automatikusan a megfelelő VLAN-ba kerül, a kimenő forgalomról pedig a switch eltávolítja a VLAN-címkét, mielőtt elküldi a végberendezés felé.

DHCP-szerverek létrehozása

A következő lépésben létrehozzuk magukat a DHCP-szervereket, és hozzárendeljük őket a megfelelő interfészekhez és IP-poolokhoz.

A parancs fontosabb paraméterei:

• az address-pool határozza meg, hogy a DHCP-szerver melyik címtartományból oszthat címeket;
• az interface adja meg azt az interfészt vagy VLAN-interfészt, amelyen a szerver a DHCP-kéréseket fogadja;
• a name a DHCP-szerver RouterOS-on belüli neve;
• a lease-time azt határozza meg, hogy a kliens mennyi ideig használhatja a kiosztott címet újabb DHCP-egyeztetés nélkül.

A dhcp szervereknél, ahol külön nem adtunk meg lease-time értéket, a RouterOS alapértelmezett, 10 perces lease ideje marad érvényben. Igazábol

Az Admin VLAN DHCP-szerverénél 15 perces lease időt használok. Ennek oka, hogy a Home Assistant a MikroTik integráción keresztül a DHCP lease-ek alapján is figyeli az eszközök jelenlétét. Így ha a telefonom elhagyja az otthoni hálózatot, a rendszer legfeljebb körülbelül 15 percen belül érzékeli ezt, és elindítja a távozáshoz tartozó automatizmusokat.

Az IoT-9 hálózatnál ezzel szemben közel egy napos, 23h59m lease időt állítottam be:

Az IoT-eszközök jellemzően hosszú ideig ugyanahhoz a hálózathoz kapcsolódnak, ezért nincs szükségük gyakori címmegújításra.

Az always-broadcast=yes beállítás azt eredményezi, hogy a DHCP-szerver a válaszokat broadcastként küldi ki. Ez bizonyos egyszerűbb vagy nem teljesen szabványosan működő IoT-eszközöknél javíthatja a DHCP-kommunikáció megbízhatóságát.

A natív, VLAN-tag nélküli LAN hálózat DHCP-szervere külön parancsban jön létre:

Ez a DHCP-szerver a 192.168.10.0/24 hálózatot szolgálja ki, és már a létrehozásakor megkapja a később részletesen bemutatott set2 DHCP Option Setet.

DHCP network bejegyzések létrehozása

A DHCP-szerverek és a címtartományok létrehozása után meg kell adnunk azokat a hálózati paramétereket is, amelyeket a kliensek a DHCP-válaszban megkapnak.

A /ip dhcp-server network bejegyzések nem újabb DHCP-szervereket hoznak létre. Ezek azt határozzák meg, hogy az adott IP-hálózat kliensei milyen paramétereket kapjanak a már működő DHCP-szervertől.

Az address paraméter azt az alhálózatot jelöli, amelyre a bejegyzés vonatkozik.

A gateway paraméter azt az alapértelmezett átjárót adja át a klienseknek, amelyen keresztül a saját hálózatukon kívüli címeket elérhetik. Ez minden hálózatban az adott interfészre korábban beállított .1 végű routercím.

A dns-server paraméterben adhatjuk meg azokat a DNS-szervereket, amelyeket a kliensek használni fognak.

A legtöbb belső hálózat nálam a következő DNS-szervereket kapja:

192.168.8.3
192.168.208.3

A 192.168.8.3 a helyi DNS-szerver, a 192.168.208.3 pedig egy másik telephelyen található tartalék DNS-szerver.

Nem minden VLAN ugyanazt a DNS-konfigurációt használja. A Pubserv hálózat például közvetlenül a 8.8.8.8 DNS-szervert kapja:

add address=192.168.6.0/24 dns-server=8.8.8.8 domain=nemes gateway=192.168.6.1

A Solar hálózat két OpenDNS-szervert használ:

208.67.222.222
208.67.220.220

Ezzel az egyes hálózatok DNS-feloldása szükség szerint egymástól eltérően is kialakítható.

A domain=nemes paraméter a klienseknek átadott helyi domainnevet határozza meg. Ennek használatával a megfelelően konfigurált eszközök és DNS-szerverek esetén a belső gépek rövid névvel is elérhetők lehetnek, például:

szerver.nemes

Az IOT-4, IOT-9 és ubnt-16 hálózatokhoz jelenleg nincs külön domain érték megadva, ezért ezek kliensei ezt az információt nem kapják meg.

A DHCP-konfiguráció ellenőrzése

A létrehozott DHCP-szervereket a következő paranccsal ellenőrizhetjük:

A DHCP-poolok ellenőrzéséhez:

A klienseknek kiosztandó hálózati paramétereket pedig itt láthatjuk:

Az aktív és statikus DHCP-lease-ek megtekintéséhez:

Ezzel a DHCP-szolgáltatás alapkonfigurációja elkészült. Az egyes hálózatok kliensei már automatikusan megkaphatják az IP-címüket, az alapértelmezett átjárót, a DNS-szervereket és – ahol beállítottuk – a helyi domainnevet.
Komolyabb vállalati környezetben érdemes megfontolni, hogy a hálózati infrastruktúra eszközeit funkció vagy akár gyártó szerint külön menedzsment VLAN-okba szervezzük. Ilyenek lehetnek például a vezeték nélküli access pointok.

Erre jó példa a DHCP Option 43 használata. Ha egy UniFi access point vezérlője másik hálózatban vagy akár másik telephelyen található, az Option 43 segítségével átadható az AP számára a UniFi Network Controller IP-címe, amelyhez az eszköznek csatlakoznia kell. Ez a UniFi által támogatott Layer3 adoption egyik lehetősége.

A Cisco lightweight access pointok szintén használják a DHCP Option 43-at a Wireless LAN Controller felderítésére, azonban fontos tudni, hogy bár az opció száma megegyezik, a benne található adattartalom gyártóspecifikus. A Cisco és a UniFi eszközök tehát nem ugyanazt az információt várják az Option 43-ban. Cisco környezetben a DHCP-szerver jellemzően a kliens által küldött Option 60 (Vendor Class Identifier) alapján dönti el, hogy milyen Option 43 tartalmat küldjön vissza.

A TP-Link Omada rendszerek eredetileg a DHCP Option 138 segítségével kapták meg a Controller IP-címét, bár az újabb Omada rendszerek már támogatják a 43-as opció használatát is. Ettől függetlenül itt is gyártóspecifikus adattartalomról beszélünk.

Ezért ha több gyártó access pointjai kerülnek ugyanabba a menedzsment VLAN-ba, egyetlen, minden kliensnek kiosztott DHCP Option 43 nem feltétlenül lesz megfelelő minden eszköz számára. Ilyenkor vagy gyártónként külön menedzsment VLAN-t alakítunk ki, vagy a DHCP-szerveren a kliens Vendor Class Identifier értéke alapján eltérő DHCP-opciókat rendelünk az egyes eszköztípusokhoz. A MikroTik RouterOS DHCP Matcher funkciója ezt a megoldást is támogatja.

DHCP Option 43 létrehozása és hozzárendelése mikrotik-ben

A UniFi access pointok DHCP Option 43 segítségével is megkaphatják a vezérlő IP-címét. Nálam a UniFi Network Controller a 192.168.8.4 címen érhető el, ezért először létrehozom az ehhez tartozó DHCP-opciót:

A parancsban a name=ubnt az opció RouterOS-on belüli, tetszőlegesen megadható neve. A code=43 azt jelzi, hogy a DHCP Vendor Specific Information opcióját hozzuk létre. A value mező tartalmazza a UniFi vezérlő címét a UniFi által elvárt formátumban.

A MikroTikben a 0x előtag jelzi, hogy az utána következő értéket hexadecimális adatként kell értelmezni.

A teljes érték tehát a következőképpen bontható fel:

0x 01 04 c0 a8 08 04
   |  |  └───────────┘
   |  |       érték
   |  └── hossz
   └───── típus

A 0x nem része a továbbított adattartalomnak, kizárólag a RouterOS számára jelzi, hogy hexadecimális bájtsorozat következik.

Az Option 43-on belüli adat TLV, vagyis Type–Length–Value felépítésű:

01 | 04 | c0 a8 08 04
 T    L          V

A 01 a Type, vagyis a vendor-specifikus alopció azonosítója. Ez azt mondja meg az UniFi eszköznek, hogy milyen jellegű adat következik. A 01 jelentése nem egy általános DHCP-szabványban rögzített „vezérlőcím”, hanem a Ubiquiti által meghatározott vendor-specifikus formátum része. Ebben a struktúrában az 01 az inform URL, illetve a vezérlő IP-címének átadására használt alopciót jelöli.

A 04 a Length, vagyis a következő érték hosszát adja meg bájtokban. Mivel egy IPv4-cím 32 bites, azaz négy darab 8 bites bájtból áll, a hossz értéke 04.

A fennmaradó négy bájt maga a Value:

c0 a8 08 04

Az egyes bájtokat hexadecimálisból decimálisra átalakítva:

c0 = 192
a8 = 168
08 = 8
04 = 4

Így kapjuk meg a vezérlő IP-címét:

192.168.8.4

A létrehozott DHCP-opciót ezután egy Option Setbe rendezzük:

A set1 egy tetszőlegesen elnevezhető opciókészlet, amely jelen esetben csak az előzőleg létrehozott ubnt opciót tartalmazza. Az Option Set használatának előnye, hogy szükség esetén több DHCP-opciót is egyetlen készletbe szervezhetünk, majd a teljes készletet hozzárendelhetjük egy vagy több DHCP-hálózathoz.

Nálam a UniFi access pointok a 192.168.10.0/24 LAN menedzsmenthálózaton találhatók, ezért a létrehozott Option Setet ehhez a DHCP network bejegyzéshez rendelem:

A find where address=192.168.10.0/24 megkeresi a megfelelő DHCP network bejegyzést, a set parancs pedig hozzárendeli a set1 opciókészletet. Ettől kezdve az ezen a hálózaton DHCP-címet kérő eszközök megkapják az Option 43 tartalmát is.

A már működő access pointok nem feltétlenül kérnek azonnal új DHCP-konfigurációt. Az új beállítást a következő DHCP-megújításkor, illetve az AP újraindítása vagy a DHCP-lease megújítása után kapják meg.



Végére is értünk a második bejegyzésnek ahol létrehoztuk a hálozatunk strukturáját, ip-cimeket, és dhcp szervereket a létrehozott interface-kre, továbbá beállitotuk a portokra hogy mely vlan legyen tagged untagged. A következő részben a mikrtotik tüzfal szabályait mutatom be, illetve a nat részt.

Bár az írás elején kitértem a switch chipek optimális konfigurálására, és elmondtam, hogy lehetőség szerint kerülni kell a CPU csomagtovábbítási terhelését, a hálózat logikai felépítése ezt időnként felülírja. Mivel a VLAN-ok közötti adatcsere L3 szintű csomagtovábbítást igényel, ráadásul a biztonság érdekében a VLAN-ok között tűzfalszabályokat alkalmazunk (az access szabályok után egy záró implicit deny alapbeállítással), a csomagok vizsgálatát és szűrését a CPU-nak kell elvégeznie. Emiatt a hardveres switch-alapú gyorsítás ezeknél a forgalmaknál háttérbe szorul, és a CPU veszi át a routing feladatát – ami tudatos kompromisszum a szigorú hálózati szegmentáció és biztonság oltárán.