Az útválasztás testreszabása L2TPv3 Tunnel használata esetén –
avagy hogyan kerüljük el, hogy szükségtelen forgalmat küldjünk a csatornára

A konfiguráció egyszerű, számtalan minta található az interneten, de szükséges hozzá az Application Experience (AppX) licenc.  Ebben a cikkben azt vizsgáljuk, hogy miként lehet megakadályozni, hogy a tunnelen felesleges forgalom haladjon keresztül – azaz hogyan állítsuk be ilyen környezetben az útválasztást. 

A teszthálózatunk az alábbi ábrán látható.

A két szerver mindkét telephelyen a tízes VLAN hálózathoz csatlakozik és a két tízes VLAN között építettük ki az L2TPv3 összeköttetést.  A tesztkörnyezetben a kiszolgálóknak Cisco routereket használunk, ezért az adatbázis fürtöt egy HSRP relációval szimuláltuk, ami egyben az L2TPv3 csatorna tesztje, mert ha a két szerver megtalálja egymást akkor működik a L2 összeköttetés.  A HSRP protokollt úgy konfiguráltuk, hogy minden esetben az SVR111 az Active tag és SVR222 a Standby. SVR222 csak SVR111 leállása, vagy a L2-csatorna megszakadása esetén vált Active állapotba.

A célunk az, hogy a fürt IP címét (10.12.10.100) a teljes hálózatról a SW11 felé keressék mindaddig, amíg a SVR222 nem vált Active állapotba.  A routerek felesleges terhelését akkor tudjuk teljesen elkerülni, ha még az SW22 eszközön definiált többi VLAN hálózatból is SW11 legyen az irány a 10.12.10.0/24 hálózat felé.  Ez utóbbi elég fogas kérdés, mivel a VLAN10 hálózata SW22 eszközön connected ami mindent visz a route táblában, ezért alapesetben mindkét switch a saját VLAN10 interfészén keresztül éri el a 10.12.10.0/24 hálózatot. Az alábbi példákban a SW11 konfigurációja alapján részletezzük a megoldást:

A konfiguráció első lépése, hogy SW11 és SW22 switchek VLAN10 interfészén nem a 10.12.10.0/24 hálózatot konfiguráljuk, hanem egy szűkebb 10.12.10.0/27-et, ezért a switcheken található connected útvonallal nem érhető el a fürt IP, csak a kiszolgálók címei.  Ezt a /27 IP tartományt nem hirdetjük a tesztben használt EIGRP protokollal a többieknek, csak arra használjuk, hogy vizsgáljuk a kiszolgálók elérhetőségét.  Ezután definiálunk egy VRRP viszonyt a switchek VLAN10 interfészén, ami követi a szerverek működését: amíg SVR111 elérhető addig SW11 a VRRP Master és SW22 a Backup.  Ezt úgy érjük el, hogy SW11 eszköznek magasabb a prioritása és csak akkor csökken SW22 prioritása alá, ha nem érhető el SVR111: 10.12.10.1 IP cím.  Az elérhetőséget 5 másodpercenként ellenőrizzük a 10-es IP SLA révén egy ICMP Echo üzenettel – azaz pingeléssel.

Mindkét switchen konfiguráltunk egy-egy Loopback interfészt, amit a tesztben használt EIGRP szintén nem hirdet a routereknek, így kizárólag az a switch ismeri, ahol létrehoztuk. 

Ezen felül definiálunk még egy IP SLA objektumot, ami az imént létrehozott VRRP Group address elérhetőségét teszteli úgy, hogy az ICMP Echo csomagok forrás IP címe ez a Loopback cím legyen.

A fenti track csak akkor lesz UP, ha lokális SW a VRRP Master, mert ugyan az ICMP csomagok eljutnak mindkét eszközről a 10.12.10.10 címhez, de ha a címzett nem egyezik meg a feladóval akkor a válaszcsomagokat nem lehet visszaküldeni, mert ismeretlen a forrás IP címe.

A végső lépés egy olyan statikus útvonal konfigurálása, ami csak akkor aktív, ha a fenti track UP állapotban van:

A statikus útvonal a 10.12.10.0/24 hálózatot a VLAN10 interfészre irányítja, így az a switch ahol az Aktív szerver van tudja, hogy merre keresse a teljes /24-et.  Ezt követően ezt a statikus útvonalat redisztribúcióval importáljuk az EIGRP adatbázisába, hogy a hálózat többi része is informálva legyen:

A teljes konfigurációt az alábbiakban részletezzük:

És akkor lássuk a medvét!  Hogyan működik a megoldásunk?  Alap esetben SVR111 az aktív, ezért SW22 eszközről a 10.12.10.100 címet kerülő úton, R1 és R2 eszközökön keresztül kell elérni:

SW11-ről pedig közvetlenül:

Mi történik SVR111 leállítása esetén?

A SW22-n pedig:

A traceroute is mutatja, hogy megváltozott a hálózatok elérhetősége:

Mi a helyzet akkor, ha az L2TPv3 tunnel lesz elérhetetlen?  Ebben az esetben mindkét Szerver aktív, mindkét switch hirdeti EIGRP-vel a 10.12.10.0/24 hálózatot, de egy valós fürt esetén a Quorum erőforrás elérhetősége miatt továbbra is SVR111 kiszolgálón van az elsődleges adatbázis, ezért szeretnénk, hogy a hálózat SW11 hirdetését tekintse elsődlegesnek.  Ezt a célt úgy tudjuk elérni, hogy a 10.12.10.0/24 statikus útvonalak redisztribúciója során SW11 esetében alacsonyabb metrikát adunk az útvonalnak, mint SW22-n:

A helyben importált útvonal egy nagyságrenddel rosszabb, mint az R2-től kapott verzió és a csomagok továbbra is SW11-en lépnek be a 10.12.10.0/24 hálózatba.

Szeretnél többet tudni?

Vedd fel velünk a kapcsolatot az alábbi elérhetőségen:

• Gőgös Barnabás 
  Senior Systems Engineer 
  +36 30 162 0841 
  barnabas.gogos@alef.com