A hálózat design áttekintése

A hálózat vázlatát mutatja az 1. ábra.

1. ábra: A hálózati design

A tervezett Campus hálózat architekturálisan teljes volt, vagyis tartalmazta a Core, a Distribution és az Access réteget. (A továbbiakban rendre C-, D- és A- rétegként hivatkozunk rájuk, az őket  reprezentáló switcheket pedig C-switch, D-switch és A-switch elnevezéssel illetjük. Azon switchek halmazát, amelyek egy összefüggő Layer 2 domaint alkotnak, egy disztribúciónak fogjuk nevezni; ez lényegében a két összetartozó D-switch és a rájuk csatlakozó A-switchek együttese.) A C-rétegben –amelyet két redundáns Catalyst 6500-as típusú switch alkotott- kizárólag Layer3 kapcsolatokat definiáltunk, nem is használtunk VLAN-okat, vagy Spanning Tree Protocol-t. A C-rétegben használt routing protocol gyors konvergenciájú OSPF volt.

A D-réteg switchei szintén Layer3 képességűek voltak. Két-két D-switch szolgálta ki az egy épület szintjein elhelyezett Access switcheket. A D-switchek egy-egy Layer3 kapcsolaton csatlakoztak a C-switchekhez; itt költségkímélési okból engedtünk a redundanciából, amennyiben egy-egy D-switch csak egy C-switch-hez csatlakozott (nem pedig mind a kettőhöz). A D-switchek a Layer 3 kapcsolatokon kívül kizárólag 802.1Q Trunk kapcsolatokkal rendelkeztek mind az A-switchek, mind egymás felé.

Az A-switchek két 802.1Q Trunk kapcsolaton csatlakoztak a D-switchekhez. Megjegyezzük, hogy ezzel a design módszerrel az A-switchek konfigurációja nem csak egy disztribúción belül, hanem a teljes hálózatban uniformizálható, hiszen a VLAN-számok és –nevek minden disztribúcióban újrahasználhatók. Az egyetlen beállítás, amiben disztribúciónként célszerűen. bár nem kötelezően különböznek, az a VTP domain név.

A logikai design szerint a hálózat Layer 3 határfelülete a D-switcheken végződött, és a két-két összetartozó D-switch már Layer 2 (VLAN Trunk) kapcsolaton csatlakozott egymáshoz. A disztribúciókban az A-switchekre csatlakozó host gépek számára minden egyes VLAN-ban a D-switchek Layer 3 (VLAN) interfészei biztosítottak a redundáns kijáratot VLAN-onként egy-egy HSRP (Hot Standby Router Protocol) default gateway IP-cím formájában. A D-switcheken –és így a rendelkezésre álló A-D és D-C kapcsolatokon- terhelésmegosztást alakítottunk ki. A terhelésmegosztás technikájára nem valamiféle dinamikus (packet vagy flow alapú), hanem statikus megoldást választottunk. Ennek lényege volt, hogy az A-rétegben szolgáltatott VLAN-okat a forgalmi szokások alapján két, közel egyenlő összsávszélességű csoportba osztottuk, és a D-switchek megfelelő beállításaival elértük azt, hogy rendes üzemi körülmények között az egyik VLAN csoport forgalma az egyik D-switchen (nevezzük ezt D1-switchnek), a másik VLAN csoport forgalma a másik D-switchen keresztül folyt. Ezt a működést a HSRP és a hálózatban működő Rapid Per VLAN Spanning Tree Protocol (Rapid-PVSTP) összehangolt tuningjával értük el. A lényeg az volt, hogy az adott VLAN-ban az STP root bridge és a HSRP aktív router ugyanaz a switch legyen, viszont az egyik VLAN csoport számára a D1-switch, míg a másik csoport számára a D2-switch lássa el ezt a szerepet. Ha valamely A-switch egyik uplink kapcsolata megszakadt, akkor a Rapid-PVSTP és a HSRP természetesen automatikusan a másik D-switch irányába terelte a forgalmat. A beállítások forgalomra gyakorolt eredményét mutatja a 2. ábra. Látszik, hogy a disztribúció piros VLAN-jának forgalma mindkét irányban a D1-switchben, míg a fekete VLAN forgalma a D2-switch-ben aggregálódik.

2. ábra: A HSRP és STP tuning hatása a terheléselosztásra

A hiba észlelése

A hálózatban Cisco IP-telefonrendszert is üzembe helyeztünk, a számítógépek a telefonok mögött csatlakoztak a hálózatra. Egy telefonos probléma miatt csomagvizsgálatot végeztünk az egyik telefon számítógép-portján, és meglepve tapasztaltuk, hogy oda nem illő unicast keretek érkeznek a porton, vagyis az A-switch áraszt, szaknyelven Flooding-ot végez. A Flooding kialakulásának jól definiált okai a következők lehetnek:

• A switch tábla (TCAM vagy CAM) betelik
• Tartósan magas CPU terhelés
• Unknown Unicast Destination Address („címzett ismeretlen”)

Az első két lehetőséget igen hamar kizártuk a switch berendezések lekérdezése után, így a harmadik okra koncentráltunk. Kiderült, hogy már a Layer 3 kapcsolást végző D-switch nem ismeri switch-táblájában azokat a mac-címeket, amelyekre szóló kereteket a végpontokon észleltünk, vagyis a Flooding már a D-switchben fellépett.

A jelenség magyarázata

A jelenség abban az esetben léphet fel, amikor a két kommunikáló berendezés egy disztribúción belül, de különböző VLAN-csoportba tartozó host. Másképpen fogalmazva az egyik host (nevezzük H1-nek) VLAN-jában a Default Gateway és STP root a D1-switch, a másik host (H2) VLAN-jában a Default Gateway és STP root a D2-switch. Vizsgáljuk meg a csomagok illetve keretek útját mindkét irányban! A megértést ábrák segítik; az ábrákon a két, egy disztribúcióban levő VLAN-t piros és fekete színek reprezentálják.

A H1-től H2 felé haladó csomag útját szemlélteti a 3. ábra.

3. ábra: A csomag útja H1-től H2 felé

A csomag Layer2 forráscíme a H1 host mac-címe, célcíme a D1-switch mac-címe, (hiszen a default gateway-en keresztül a fekete VLAN-ba tart a csomag). A D1-switch a bejövő keret alapján kitölti H1 mac-címével CAM-tábláját, vagyis tudja, hogy H1 melyik portján  látszik. A D1-switch eztuán a Layer2 keretezést leveszi a csomagról, és Layer3 forwarding döntést végez az IP csomagon (ezt a sárga szaggatott nyíl szimbolizálja), és megállapítja, hogy a fekete VLAN-ban kell kiküldenie a csomagot. A D1-switch ezután ahhoz, hogy Layer2 keretbe foglalja a csomagot egy ARP-kérést küld ki a fekete VLAN-ba H2 mac-címét tudakolva, amelyre a H2-től kapott válasz alapján megtudja H2 mac-címét, amelyet ARP és CAM-táblájába is bejegyez. Fontos tudnunk, hogy a Cisco IOS-ben az ARP-cache a bejegyzéseket alapértelmezetten 4 óráig, a CAM-tábla sorokat pedig 5 percig őrzi, továbbá az ARP bejegyzés kiöregedésekor az IOS először újabb ARP kéréssel megpróbálja megújítani a bejegyzést, és akkor törli, ha nem kap rá választ. A csomagot ezutám Layer2 kerettel látja el, és a a CAM-táblája alapján a Layer2 kapcsolással továbbítja esetünkben a D2-switch felé néző Trunk porton immár a fekete VLAN-ban. A D2-switch ezután a CAM-táblája alapján, egyszerű Layer2 kapcsolással továbbítja a keretet a megfelelő A-switch felé, amely hasonlóan kiküldi azt H2 portján.

A H2-től H1 felé haladó csomagok (4. ábra) hasonlóan követhetők, a legfőbb kölönbség a Layer3 kapcsolás helyében van.

4. ábra: A csomag útja H2-től H1 felé

Mivel a H2-nek a fekete VLAN-ban D2-switch a default gateway-e, ezért a visszafelé irányuló IP-forgalom Layer3 kapcsolása a D2-switchben történik. A D2-switch a H1 host mac-címéről az előbbiekhez hasonlóan a legelső neki szóló csomag előtt bonyolított ARP-kommunikáció alapján szerez tudomást, és bejegyzi azt az ARP és a CAM-táblájába.

A csomagok tehát fizikailag ugyanazon az útvonalon haladnak oda és vissza, ám a csomagfolyam mégis aszimmetrikus a két irányban a Layer3 kapcsolás, a routing helye miatt. Az aszimmetrikus routing következménye az, hogy a D1-switch az első ARP-válasz után nem kap olyan kereteket, amelyek H2-től származnak, vagyis amelyekben H2 mac-címe szerepel forráscímként. Mivel a switchek a bejövő keretek forráscímeiől „tanulnak”, így a CAM-táblájából 5 perc után törli a H2-re vonatkozó bejegyzést. Az ARP-cache bejegyzése viszont négy óráig érvényes, így leghamarabb akkor számíthatunk az ARP kommunikációból eredő CAM-bejegyzés frissítésre. Ezzel előállt az a helyzet, hogy a H2 mac-címe a D1-switch számára 3 óra 55 percig ismeretlen unicast cím, és a H2-nek szóló kereteket így minden, fekete VLAN-ba csatlakozó portján kiküld, vagyis D1-switch Flooding-ot végez H2 mac-címére. Szimmetrikus gondolatmenettel könnyű belátni, hogy hasonló helyzet áll elő D2 switchben H1 mac-címére.

Ha megfigyeljük D1-switchet, akkor azt látjuk, hogy a fekete VLAN-ban (amelybe a problémás H2 host tartozik) kizárólag az a VLAN Trunk portja van forwarding állapotban, amelyen ténylegesen ki kellene küldenie a keretet H2 felé akkor is, ha a CAM-táblájában szerepelne H2 mac-címe. A többi, fekete VLAN-ba tartozó A-switchek felé néző Trunk portján a Spanning Tree Protocol blokkolása miatt nincs kerettovábbítás. Hasonló a helyzet D2-switch és H1 host viszonylatában. Mondhatjuk, hogy az ismeretlen unicast címre való továbbítás miatt az ismeretlen Unicast Flooding állapot fennáll, de sajátos módon rendes üzemi állapotban éppen arra az egy trunk portra terjed ki, amely a megfelelő irány. Így ahhoz, hogy a jelenséget észleljük, kellett az a körülmény is, hogy a telepítéskor az A-switchek és a D-switchek közötti optikai kapcsolatokhoz a Gigabites SFP transceiver modulok jó része később érkezett meg, és így az A-switchek egy része így egyetlen Trunk kapcsolaton csatlakozott a D-switchhez. Ezt a helyzetet mutatja az 5. ábra.

5. ábra:Unicast Frame Flooding

Hasonló állapot életszerűbb módon kialakulhat akkor is, ha egy egyébként redundáns módon bekötött A-switch egyik uplink kapcsolata valamilyen műszaki hibaokból megszakad.

A fentieket összegezve megállapíthatjuk, hogy a jelenség nem hibás eszközműködés, hanem a design következménye, és bár rendes üzemi körülmények között is kialakul mégis rejtve marad, és mindenképpen ki kell küszöbölnünk a jelenlétét.

A jelenség kiküszöbölése

A leírt jelenség oka az aszimmetrikus routing miatt kialakuló ARP-cache és CAM-tábla inkonzisztencia. Az aszimmetrikus routing az egyik eredeti célból: a terhelésmegosztásból ered, vagyis a design szerves része, így ezt nem tudtuk és nem is akartuk megszüntetni. Megkerestük tehát, milyen módszerekkel lehet az ARP-cache és a CAM-tábla konzisztenciáját biztosítani. Mivel az ARP-válasz egyúttal az adott host CAM-tábla bejegyzését is frissíti, ezért kézenfekvő, hogy azt kell elérni, hogy az ARP kommunikáció a CAM-bejegyzés kiöregedése előtt megtörténjen. Az általunk választott megoldás a VLAN interfészeken az ARP-cache lejárati idejének valamivel 5 perc alá (298 másodpercre) állítása volt, de megfelelő lehet a CAM-aging növelése valamivel az ARP timeout fölé. Az ARP-lejárat csökkentése némiképp növeli az ARP (és így a broadcast) forgalmat, míg a CAM-aging megnövelése hálózatbiztonsági aggályokat vethet fel.