In articolul acesta voi documenta un caz pe care l-am intalnit in practica.
Discutam despre o solutie VPN ridicata cu ajutorul unor tunele GRE intre HQ si branch-uri, peste doua retele MPLS (doi provideri diferiti). In HQ avem doua rutere pentru redundanta, iar intre ele este configurat HSRP. In total avem ridicate patru tunele GRE pe CPE-ul din branch. Doua tunele terminate pe routerul active din HQ, unul dintre ele printr-o retea MPLS, iar celalalt prin cea de-a doua, iar doua tunele sunt terminate pe standby in HQ si urmeaza aceeasi cale la nivel de MPLS, precum tunelele spre routerul active.
Distanta EIGRP este influentata prin definirea unui delay mai mare pentru tunelele terminate pe routerul standby din HQ.
Rutarea intre HQ si branch-uri se realizeaza dinamic cu ajutorul EIGRP. Dispre branch-uri se anunta spre HQ clasa configurata pe LAN, iar dinspre HQ este anuntata o ruta default.
In conditii normale de functionare, cand toate buclele locale sunt up, traficul dinspre HQ spre branch-uri iese prin routerul active si este balansat prin cei doi provideri de MPLS. La intoarcere urmeaza aceeasi cale, fiind simetric din acest punct de vedere.
In poza de mai jos am descris setup-ul normal de functionare a solutiei.
Am identificat urmatoarea problema in configurarea HSRP.
Pe routerul active avem doua probe SLA care monitorizeaza WAN-urile spre cei doi provideri MPLS. Aceste doua probe au fost folosite pentru a comuta HSRP-ul in cazul in care una dintre ele nu mai primeste raspuns. Am atasat mai jos un extras din configuratia HSRP.
Probe SLA
ip sla 1
icmp-echo 10.1.0.1 source-ip 10.1.0.2
tag MPLS_1
frequency 5
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 10.1.1.1 source-ip 10.1.1.2
tag MPLS_2
frequency 5
ip sla schedule 2 life forever start-time now
Obiecte definite
track 1 ip sla 1
track 2 ip sla 2
Configuratia HSRP
interface FastEthernet1/1
description LAN
ip address 172.16.0.1 255.255.255.0
standby 1 ip 172.16.0.3
standby 1 preempt
standby 1 track 1 decrement 20
standby 1 track 2 decrement 20
Routerul standby are configurata prioritatea 90.
Problema cu aceasta configuratie este ca atunci cand oricare dintre cele doua WAN-uri cade, HSRP-ul decrementeaza prioritatea routerului active cu 20 si promoveaza routerul standby ca router active.
Astfel vom sfarsi prin a avea trafic asimetric, plecand balansat dinspre HQ spre branch-uri prin routerul de backup, iar la intoarcere va pleca prin tunelul ridicat cu routerul main din HQ, deoarece EIGRP vede distanta mai buna pe acolo.
Solutia pe care am gasit-o a fost de a configura HSRP sa faca tracking avansat pe un obiect in care am inclus o lista de obiecte intre care am ales sa fac o operatie logica de tip ‘sau’. Am inclus in obiectele din lista probele SLA prin care monitorizez cele doua WAN-uri.
Astfel, daca cel putin unul dintre obiecte este ok, obiectul parinte pe care fac tracking nu va declansa actiunea de decrementare a prioritatii HSRP pentru routerul active. Este nevoie ca toate obiectele sa fie down pentru a se intampla acest lucru.
Practic, cand cade unul dintre WAN-uri pe routerul active din HQ, nu mai avem trafic balansat, dar el va ramane simetric.
Am pus mai jos configuratia ajustata.
HQ-M#show run | sec ip sla|track
track 10 list boolean or
object 11
object 12
track 11 ip sla 1
track 12 ip sla 2
standby 1 track 10 decrement 20
ip sla 1
icmp-echo 10.1.0.1 source-ip 10.1.0.2
tag MPLS_1
frequency 5
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 10.1.1.1 source-ip 10.1.1.2
tag MPLS_2
frequency 5
ip sla schedule 2 life forever start-time now
!
interface FastEthernet1/1
description LAN
ip address 172.16.0.1 255.255.255.0
standby 1 ip 172.16.0.3
standby 1 preempt
standby 1 track 10 decrement 20
Niciun comentariu :
Trimiteți un comentariu