A mai világban mindenki mindent azonnal akar. Ennek az élet minden területén meg kell felelni, nincs ez másképp az informatika, hálózatok világában sem.
Emlékeztek még mennyi a Spanning-Tree (a 802.1D, tehát az 1998-as verzió) Max-Age értéke, Listening és Learning ideje? Egy (indirekt) link hiba esetén a STP konvergencia akár 50 másodpercig is eltarthat. Majdnem 1 percig.
Mennyi a RIP (1980-as évek eleje) konvergenciája? Csak az “Invalid” timer 180 másodperc, azaz három perc. Csak mire biztos abban a protokoll hogy változás történt a hálózatban.
A route is considered perfectly usable if an update about it has been received within the last
180 seconds, which is the default upper limit for the Invalid after timer. If, however, the
Invalid after timer has reached the upper limit and an update about this network has not
been received, the network is considered invalid.(CCIE Routing & Switching Official Cert Guide Volume I.)
És ne feledkezzünk meg a “Flushed after” értékről sem ami 240 másodperc (Cisco implementációban igazából 60 mert ebből lejön 180 a Holddown timer), amikor végre kilökjük a RIB-ből a route-t (ha nincs hirdetve máshonnan). Szóval RIP esetében 3-4 perc is lehet a konvergencia.
Állítsuk ezeket szembe a mai világ elvárásaival. Mikor már az is feszültséget generál az emberekben ha pár percig nincs internet (mindenkinek teljesen természetes hogy megnyitja a böngészőt és szörfözik a neten; ha nincs hálózat a legtöbb ember nagyon feszült lesz – vallom, hogy ez a 21. század egyik drogja).
Ha megnézzük pl. az OSPF-et a “broadcast” interface alapértelmezett timerekkel (Hello 10, Dead 40) azért az sem száguldó gyorsvonat (azért itt meg kell említeni hogy mivel broadcast a hálózat típusa így függőség van pl. a LAN konvergenciától – lásd STP rész felül), de persze megvan a lehetőség arra hogy ezeket az értékeket lejjebb állítsuk – de a mai világban sokszor a minimum 1 mp-es HELLO érték is soknak számíthat, a DEAD-ről (mondjuk 3-4 mp) nem is beszélve.
Cirkuszt, kenyeret, internetet és gyors routing protokoll konvergenciát akar a nép.
Ugorjunk egy nagyot az időben és nézzük meg mi van a legtöbbeknél a kosárban: OSPF, EIGRP, BGP 🙂 . Persze jöttek be újabb lehetőségek protokollon belül (OSPF-nél pl. a FastHello, amivel megmondhatjuk hogy egy másodpercen belül hány HELLO menjen ki, a DEAD intervallumot pedig egy másodpercre állítjuk). Azaz maximum egy másodperc és felszakad a neighborship a routerek között. Ez nem rossz, a hátránya hogy CPU-ból megy nem ASIC-ből.
De használhatunk BFD-t is amit már hardverből támogat a legtöbb eszköz és ehhez kapcsolhatjuk a routing protokollt, azaz ha kommunikációs probléma történik a linken akkor a BFD “szól” a routing protokollnak hogy ideje szétesni.
A legtöbb hálózatban viszont történt egy nagyon fontos változás a régi időkhöz képest: redundáns supervisorok vannak az eszközökben, esetleg van VSS, VPC, cluster vagy más megoldás. Ezeknél tudjuk hogy a hardverhiba esetén a másik SUP vagy cluster member szinte azonnal átveszi az aktív szerepet és nagyon gyors konvergencia történik. Ez igaz lehet a routing konvergenciára de ehhez speciális feltételeknek kell megfelelni.
Nézzük meg a problémát az OSPF szemüvegén keresztül. Az aktív tagon van a routing adatbázis és a csomagok továbbításához szükséges információk (network, next hop, interface) valamint az adjacency információk (pl. ethernet keret létrehozásához szükséges információk a szomszédról), de nem minden van szinkronizálva a tagok között: a forwarding tábla igen de a routing kapcsolati nem.
Itt jön képbe a NSF (Non-Stop Forwarding) amelyből létezik Cisco szabadalom és IETF szabvány is. A Cisco-s változat volt előbb. A lényege mindkettőnek ugyanaz, csak (packet szinten) más módon érik el a célt.
Nézzünk egy példa topológiát. Van egy VSS eszközünk amely képes SSO (Stateful Switch Over) funkcióra, és három routerünk, amelyek nem redundáns RP-vel üzemelnek, azaz nem képesek SSO-ra. A célunk az lenne hogy ha a VSS-ben failover történik akkor gyakorlatilag ne legyen kiesés, amelyhez szükséges hogy az OSPF neighborshipek ne szakadjanak fel.
NSF-nél egy eszköz két kategóriába eshet (persze tudhatja egyszerre mindkettőt):
- NSF capable: ezek az eszközök hardveresen redundánsak és nagyon gyors konvergenciát várunk tőlük. Vagy a Cisco vagy az IETF mód aktív, a két verzió egyszerre nem használható.
- NSF aware: ezek az eszközök hardveresen nem redundánsak de ismerik az NSF funkciót és képesek más eszközöket segíteni a konvergenciában. Lehet egyszerre Cisco és IETF módban is az eszköz.
Routereknél pl. Cisco és IETF módokra is alapértelmezetten engedélyezve van az aware funkció (NSF helper), a capable funkciót viszont manuálisan konfigurálni kell.
Fontos hogy a helper funkciót interfészenként kell engedélyezni, azaz simán lehet hogy egy eszköz az egyik szegmensben tud NSF-et a másikban viszont nem (mert mondjuk abban a szegmensben van olyan eszköz ami nem helper).
Tegyük fel hogy a VSS-ben supervisor váltás történik. Ekkor az OSPF kapcsolatok felszakadnak, konvergencia történik. A felhasználók hálózati kiesést tapasztalnak. Ezeket szeretnénk elkerülni.
OSPFv2 esetén “Graceful restart” vagy “NSF” funkciónak nevezzük amikor ez nem történik meg. A Cisco megoldása a 4811-es és 4812-es, az IETF verzió pedig a 3623-as RFC-ben van leírva.
Az elv a következő: az NSF képes (capable) eszköz jelez a szomszédoknak a kapcsolat felépítésekor hogy tudja ezt a funkciót (link-local opaque LSA-val [IETF] vagy LLS-sel [Cisco], attól függ melyik verziót használjuk), és megadja mennyi idő kell neki az átálláshoz failover esetén. A szomszédok (helperek) ezt az információt tárolják és tudják hogy ha ilyen speciális LSA-t kapnak failover esetén akkor X másodperc van arra hogy megtörténjen az átállás a másik oldalon különben fel kell szakítani a kapcsolatot mert valami probléma történt.
Nézzük hogyan működik a funkció először a helperek oldaláról.
1.) Az NSF capable routernél átállás történik (supervisor, cluster, akármi), ezért kiküld megából egy LLS-t/grace-LSA-t az interface-n. A szomszédok ezt megkapják és a következőket teszik:
- Nem szakítják fel az OSPF kapcsolatot az LSA-ban megadott ideig (restart time)
- Hirdetik tovább a szomszéd Type1 és Type2 (ha van) LSA-it area-n belül, mintha meglenne az adjacency, tehát “hazudják” hogy nem történt semmi, de csak akkor ha nem történik a failover során egyéb változás (Type 1-5, Type7 LSA-k), nem járt le a timer, illetve ha a helper eszköz maga nem megy át failover-en éppen). Ezt a grace-LSA-ban megadott ideig teszi meg (restart time)
2.) Ha a szomszéd (capable) router végzett a failoverrel újra küld graceful LSA-t
3.) Ekkor történik egy LSDB szinkronizáció
4.) És befejeződött a folyamat
A failover így zajlik a capable router szemszögéből:
1.) A forwarding tábla (CEF) naprakész és nem változik az átállás folyamán – ez garantálja a szakadás nélküli csomagtovábbítást, azaz a data plane független lesz a control plane-től
2.) Átállás kezdetekor grace-LSA küldése, innen tudják a helperek hogy failover történik
3.) Az OSPF process újraindítása, LSA szinkronizáció a szomszédokkal, ezért az OSPF FULL-ból EXSTART állapotba megy, de mivel a forwarding tábla naprakész ez a csomagok továbbítását nem érinti
4.) Sikeres szinkronizáció után a forwarding tábla esetleges frissítése
5.) Grace-LSA kivonása
Ezzel a funkcióval biztosítható a gyors konvergencia, de persze fontos figyelembe venni sok eszköz nem tudja a “capable” funkciót. Ekkor marad a timerek alacsonyra állítása, BFD vagy valami hasonló megoldás.