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
Ha L3 hálózaton szeretnénk egy L2 tunnelt kialakítani – azaz Ethernet csomagokat továbbítani az IP hálózatunkon – akkor kézenfekvő megoldás az L2TPv3 protokoll használata, amit Cisco routereken úgynevezett xconnect konfigurációval tudunk beállítani. Ezek az összeköttetések nagyon hasznosak, ha két telephelyen a redundánsan üzemelő kiszolgálóink adatbázisait szeretnénk szinkronizálni.
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.
Interface Grp Pri P State Active Standby Virtual IP
Gi0/0 10 110 P Active local 10.12.10.222 10.12.10.100
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:
!
interface Vlan10
ip address 10.12.10.11 255.255.255.224
vrrp 10 ip 10.12.10.10
vrrp 10 priority 110
vrrp 10 track 10 decrement 30
end
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.
ip sla 10
icmp-echo 10.12.10.1
frequency 5
track 10 ip sla 10
SW11#show vrrp brief
Interface Grp Pri Time Own Pre State Master addr Group addr
Vl10 10 110 3570 Y Master 10.12.10.11 10.12.10.10
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.
!
interface Loopback0
ip address 11.11.11.11 255.255.255.255
end
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.
ip sla 100
icmp-echo 10.12.10.10 source-interface Loopback0
frequency 5
track 100 ip sla 100
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:
ip route 10.12.10.0 255.255.255.0 Vlan10 track 100
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:
router eigrp 1
network 10.1.11.0 0.0.0.255
network 10.1.20.0 0.0.0.255
redistribute static metric 10000 100 255 1 1500
passive-interface default
no passive-interface GigabitEthernet0/1
A teljes konfigurációt az alábbiakban részletezzük:
track 10 ip sla 10
track 100 ip sla 100
interface Vlan10
ip address 10.12.10.11 255.255.255.224
vrrp 10 ip 10.12.10.10
vrrp 10 priority 110
vrrp 10 track 10 decrement 30
router eigrp 1
network 10.1.11.0 0.0.0.255
network 10.1.20.0 0.0.0.255
redistribute static metric 10000 100 255 1 1500
passive-interface default
no passive-interface GigabitEthernet0/1
ip route 10.12.10.0 255.255.255.0 Vlan10 track 100
ip sla 10
icmp-echo 10.12.10.1
frequency 5
ip sla schedule 10 life forever start-time now
ip sla 100
icmp-echo 10.12.10.10 source-interface Loopback0
frequency 5
ip sla schedule 100 life forever start-time now
É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:
D EX 10.12.10.0/24
!
SW22#traceroute 10.12.10.100
Type escape sequence to abort.
Tracing the route to 10.12.10.100
VRF info: (vrf in name/id, vrf out name/id)
1 10.2.22.2 9 msec 4 msec 5 msec
2 10.1.2.1 8 msec 6 msec 3 msec
3 10.1.11.11 10 msec 10 msec 7 msec
4 10.12.10.1 15 msec * 7 msec
SW11-ről pedig közvetlenül:
S 10.12.10.0/24 is directly connected, Vlan10
!
SW11#traceroute 10.12.10.100
Type escape sequence to abort.
Tracing the route to 10.12.10.100
VRF info: (vrf in name/id, vrf out name/id)
1 10.12.10.1 4 msec * 3 msec
Mi történik SVR111 leállítása esetén?
*Aug 23 12:07:45.055: %TRACK-6-STATE: 10 ip sla 10 state Up -> Down
SW11#
*Aug 23 12:07:48.134: %VRRP-6-STATECHANGE: Vl10 Grp 10 state Master -> Backup
SW11#
*Aug 23 12:08:00.059: %TRACK-6-STATE: 100 ip sla 100 state Up -> Down
!
SW11#show ip route | i 10.12.10.0/24
D EX 10.12.10.0/24
A SW22-n pedig:
*Aug 23 11:56:09.982: %TRACK-6-STATE: 10 ip sla 10 state Down -> Up
SW22#
*Aug 23 12:06:42.495: %VRRP-6-STATECHANGE: Vl10 Grp 10 state Backup -> Master
SW22#
*Aug 23 12:06:50.083: %TRACK-6-STATE: 100 ip sla 100 state Down -> Up
!
SW22#sh ip route | i 10.12.10.0/24
S 10.12.10.0/24 is directly connected, Vlan10
A traceroute is mutatja, hogy megváltozott a hálózatok elérhetősége:
Type escape sequence to abort.
Tracing the route to 10.12.10.100
VRF info: (vrf in name/id, vrf out name/id)
1 10.1.11.1 11 msec 3 msec 2 msec
2 10.1.2.2 5 msec 8 msec 4 msec
3 10.2.22.22 7 msec 7 msec 6 msec
4 10.12.10.2 10 msec * 9 msec
SW22#traceroute 10.12.10.100
Type escape sequence to abort.
Tracing the route to 10.12.10.100
VRF info: (vrf in name/id, vrf out name/id)
1 10.12.10.2 4 msec * 4 msec
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:
EIGRP-IPv4 Topology Table for AS(1)/ID(22.22.22.22)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 10.12.10.0/24, 1 successors, FD is 2816000
via Rstatic (2816000/0)
via 10.2.22.2 (282368/282112), GigabitEthernet0/1
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