Para monitorizar la disponibilidad de los accesos utilizaremos IP SLA (Service Level Agreement) mediante ICMP (Internet Control Message Protocol).
Esta configuración no es para balancear carga entre los routers Cisco, ya que aunque los dos túneles IPSEC están establecidos, sólo utilizaremos uno de ellos. El tráfico se encaminará por el túnel de backup sólo cuando el acceso principal esté caído.
El problema que presentan las rutas estáticas es que no disponen de un mecanismo para determinar si la ruta está disponible o caída. La ruta permanecerá en nuestra tabla de enrutamiento a pesar de que nuestro gateway no esté disponible. Este problema lo podemos resolver monitorizando la disponibilidad de la ruta utilizando la facilidad de tracking. Si la ruta falla, la eliminamos de la tabla de enrutamiento y utilizamos la ruta de backup.
Para articular la redundancia, el router verificará la validez de la ruta estática monitorizando la dirección IP WAN del router remoto. Esto lo implementamos mediante IP SLA, que monitorizará periódicamente mediante icmp la disponibilidad del router remoto. En caso de no recibir respuesta de eco el router se considerará como caído y la ruta asociada será eliminada de la tabla de routing, pasando a encaminarse el tráfico por la ruta de backup. La operación de monitorización SLA continuará ejecutándose e intentando alcanzar el router. Cuando está disponible, se injectará nuevamente la ruta principal y se eliminará la ruta de backup de la tabla de routing.
Os adjunto un esquema del escenario:
A continuación la configuración de ambos routers Cisco:
(Nota: En las configuraciones veréis que configuro 802.1Q y subinterfaces. Esto no tiene nada que ver con el laboratorio, sino por falta de interfaces.)
version 15.0
!
hostname pruebas1
!
........
!
----
Definimos el objeto que hace el seguimiento de la prueba SLA IP ----
track 10 ip sla 1
reachability
!
----
Definimos la política ISAKMP (Internet Security Association and Key Management
Protocol) y los parámetros IKE (Internet Key Exchange) ----
crypto isakmp policy
10
encr 3des
hash md5
authentication pre-share
group 2
!
----
Indicamos las claves a utilizar en la autentificación con los peer Ike ----
crypto isakmp key
pruebavpn address 195.57.x.90
crypto isakmp key
pruebavpn address 85.62.x.204
!
----
Especificamos los algoritmos de encriptación y autentificación que vamos a
utilizar (Los parámetros IPSEC) ----
crypto ipsec
transform-set vpnset esp-3des esp-md5-hmac
!
----
Definimos el crypto map que apunta a nuestro primer peer ----
crypto map vpnl1 10
ipsec-isakmp
set peer 85.62.x.204
set transform-set vpnset
match address 100
!
----
Definimos el crypto map que apunta al segundo peer ----
crypto map vpnl2 10
ipsec-isakmp
set peer 195.57.x.90
set transform-set vpnset
match address 100
!
interface
FastEthernet0/0
no ip address
duplex auto
speed auto
!
interface
FastEthernet0/0.1
encapsulation dot1Q 22
ip address 10.10.10.20 255.255.255.0
crypto map vpnl1
!
interface
FastEthernet0/0.2
encapsulation dot1Q 17
ip address 192.168.150.27 255.255.255.248
!
interface
FastEthernet0/0.3
encapsulation dot1Q 12
ip address 192.168.1.1 255.255.255.0
!
interface
FastEthernet0/1
ip address 195.53.x.84 255.255.255.248
duplex auto
speed auto
crypto map vpnl2
!
-----
A la ruta estática que tenemos para alcanzar el destino por nuestro
"camino principal" le añadimos la clave track. El valor después de track es el objeto a monitorizar. La
ruta estará instalada en la tabla de routing mientras el objeto monitorizado
esté disponible -----
ip route 192.168.2.0
255.255.255.0 195.53.x.81 track 10
ip route
85.62.x.200 255.255.255.248 10.10.10.1
-----
La ruta estática de backup, con peor métrica, (le configuramos peor distancia
administrativa) que se utilizará cuando el objeto monitorizado no esté
disponible. Mientras el objeto que monitorizamos está 'vivo' se utilizará el
gateway primario. Cuando deje de estar disponible y se borre la ruta estática
por él, esta ruta se instalará en la tabla de routing. -----
ip route 192.168.2.0
255.255.255.0 10.10.10.1 254
ip route 195.57.x.88
255.255.255.248 195.53.x.81
!
---- Definimos con IP SLA el objeto u host del que
queremos hacer seguimiento y la forma de monitorizarlo ----
ip sla 1
----
Configuramos la operación de SLA IP como ICMP Echo. Indicamos la dirección IP
de destino y la IP de origen (opcional) -----
icmp-echo 195.57.x.90 source-ip 195.53.x.84
----
Indicamos la frecuencia (en segundos) con que queremos que se repita la
operación (por defecto son 60 seg) -----
frequency 10
----
Ahora configuramos la planificación o programación de la operación de SLA IP.
En este caso le indicamos que corra indefinidamente y que empiece
inmediatamente. ----
ip sla schedule 1
life forever start-time now
access-list 100
permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
!
.........
!
end
_____________________________________________________________
version 15.0
!
hostname Pruebas2
!
.........
!
track 10 ip sla 1
reachability
!
crypto isakmp policy
10
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key
pruebavpn address 195.53.x.84
crypto isakmp key
pruebavpn address 80.59.x.112
!
crypto ipsec
transform-set vpnset esp-3des esp-md5-hmac
!
crypto map vpnl1 10
ipsec-isakmp
set peer 80.59.x.112
set transform-set vpnset
match address 100
!
crypto map vpnl2 10
ipsec-isakmp
set peer 195.53.x.84
set transform-set vpnset
match address 100
!
interface
FastEthernet0/0
no ip address
duplex auto
speed auto
!
interface
FastEthernet0/0.1
encapsulation dot1Q 127
ip address 85.62.x.204 255.255.255.248
crypto map vpnl1
!
interface
FastEthernet0/0.2
encapsulation dot1Q 17
ip address 192.168.150.26 255.255.255.0
!
interface
FastEthernet0/0.3
encapsulation dot1Q 19
ip address 192.168.2.1 255.255.255.0
!
interface
FastEthernet0/1
ip address 195.57.x.90 255.255.255.248
duplex auto
speed auto
crypto map vpnl2
!
ip route 192.168.1.0
255.255.255.0 195.57.x.89 track 10
ip route
80.59.x.112 255.255.255.255 85.62.x.201
ip route 192.168.1.0
255.255.255.0 85.62.x.201 254
ip route
195.53.x.80 255.255.255.248 195.57.x.89
!
ip sla 1
icmp-echo 195.53.x.84 source-ip 195.57.x.90
frequency 10
ip sla schedule 1
life forever start-time now
access-list 100
permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
!
.......................
!
end
Comprobamos que tenemos los dos túneles IPSEC VPN establecidos:
pruebas1#sh crypto
session
Crypto session
current status
Interface:
FastEthernet0/0.1
Session status:
UP-ACTIVE
Peer: 85.62.x.204
port 4500
IKE SA: local 10.10.10.20/4500 remote
85.62.x.204/4500 Active
IPSEC FLOW: permit ip
192.168.1.0/255.255.255.0 192.168.2.0/255.255.255.0
Active SAs: 2, origin: crypto map
Interface:
FastEthernet0/1
Session status:
UP-ACTIVE
Peer: 195.57.x.90
port 500
IKE SA: local 195.53.x.84/500 remote
195.57.2.90/500 Active
IPSEC FLOW: permit ip
192.168.1.0/255.255.255.0 192.168.2.0/255.255.255.0
Active SAs: 2, origin: crypto map
A continuación vamos a verificar la configuración y el funcionamiento de la solución de backup:
1-. Verificamos la configuración de IP SLA:
__________
pruebas1#sh ip sla
configuration
IP SLAs
Infrastructure Engine-II
Entry number: 1
Owner:
Tag:
Type of operation to
perform: icmp-echo
Target
address/Source address: 195.57.x.90/195.53.x.84
Operation timeout
(milliseconds): 5000
Type Of Service
parameters: 0x0
Vrf Name:
Request size (ARR
data portion): 28
Verify data: No
Schedule:
Operation frequency (seconds): 10 (not considered if randomly scheduled)
Next Scheduled Start Time: Start Time
already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold
(milliseconds): 5000 (not considered if react RTT is configured)
Distribution
Statistics:
Number of statistic hours kept: 2
Number of statistic distribution buckets
kept: 1
Statistic distribution interval
(milliseconds): 20
History Statistics:
Number of history Lives kept: 0
Number of history Buckets kept: 15
History Filter Type: None
Enhanced History:
_________
pruebas1#sh track ip
brief
Track Object Parameter Value Last Change
10 ip sla 1 reachability Up
00:55:41
__________
2-. Comprobamos el estado del objeto monitorizado:
pruebas1#sh ip route
track-table
ip route 192.168.2.0 255.255.255.0
195.53.156.81 track 10 state is [up]
3-. Aquí podemos ver que esta funcionando el proceso IP SLA:
*Feb 11
15:44:13.194: IP SLAs(1) echo operation: Sending ID: 40
*Feb 11
15:44:13.214: IP SLAs(1) echo operation: RTT=19
*Feb 11
15:44:13.214: IP SLAs(1) Scheduler: Updating result
*Feb 11
15:44:13.214: IP SLAs(1) Scheduler: start wakeup timer, delay = 9980
*Feb 11
15:44:23.194: IP SLAs(1) Scheduler: saaSchedulerEventWakeup
*Feb 11
15:44:23.194: IP SLAs(1) Scheduler: Starting an operation
*Feb 11
15:44:23.194: IP SLAs(1) echo operation: Sending an echo operation -destAddr=195.57.x.90, sAddr=195.53.x.84
*Feb 11
15:44:23.194: IP SLAs(1) echo operation: Sending ID: 40
*Feb 11
15:44:23.214: IP SLAs(1) echo operation: RTT=20
*Feb 11
15:44:23.214: IP SLAs(1) Scheduler: Updating result
*Feb 11
15:44:23.214: IP SLAs(1) Scheduler: start wakeup timer, delay = 9980
*Feb 11
15:44:33.194: IP SLAs(1) Scheduler: saaSchedulerEventWakeup
*Feb 11
15:44:33.194: IP SLAs(1) Scheduler: Starting an operation
*Feb 11
15:44:33.194: IP SLAs(1) echo operation: Sending an echo operation -destAddr=195.57.x.90, sAddr=195.53.x.84
4-. Aquí vemos que ocurre cuando el objeto monitorizado (IP WAN del Cisco remoto) no contesta a los icmps. Como podéis ver se produce el intercambio de rutas que comentábamos:
*Feb 11
15:44:43.194: IP SLAs(1) echo operation: Sending ID: 40
*Feb 11
15:44:48.194: IP SLAs(1) echo operation: Timeout - destAddr=195.57.x.90,
sAddr=195.53.x.84
*Feb 11
15:44:48.194: IP SLAs(1) Scheduler: Updating result
*Feb 11
15:44:48.194: IP SLAs(1) Scheduler: start wakeup timer, delay = 5000
*Feb 11
15:44:50.014: Track: 10 Change #6 ip sla 1, reachability Up->Down
*Feb 11
15:44:50.014: %TRACKING-5-STATE: 10 ip sla 1 reachability Up->Down
*Feb 11
15:44:50.014: RT: del 192.168.2.0 via 195.53.x.81, static metric [1/0]
*Feb 11
15:44:50.014: RT: delete network route to 192.168.2.0/24
*Feb 11
15:44:50.014: RT: updating static 192.168.2.0/24 (0x0) via 10.10.10.1
*Feb 11
15:44:50.014: RT: add 192.168.2.0/24 via 10.10.10.1, static metric [254/0]
*Feb 11
15:44:50.014: RT: updating static 192.168.2.0/24 (0x0) via 10.10.10.1
5-. Volvemos a conectar la entrada por el ISP principal y vemos como se recupera:
*Feb 11
15:46:33.194: IP SLAs(1) echo operation: Sending ID: 40
*Feb 11
15:46:33.214: IP SLAs(1) echo operation: RTT=20
*Feb 11
15:46:33.214: IP SLAs(1) Scheduler: Updating result
*Feb 11
15:46:33.214: IP SLAs(1) Scheduler: start wakeup timer, delay = 9980
*Feb 11
15:46:35.014: Track: 10 Change #7 ip sla 1, reachability Down->Up
*Feb 11
15:46:35.014: %TRACKING-5-STATE: 10 ip sla 1 reachability Down->Up
*Feb 11
15:46:35.014: RT: updating static 192.168.2.0/24 (0x0) via 195.53.156.81
*Feb 11
15:46:35.014: RT: closer admin distance for 192.168.2.0, flushing 1 routes
*Feb 11
15:46:35.014: RT: add 192.168.2.0/24 via 195.53.156.81, static metric [1/0]
*Feb 11
15:46:35.014: RT: updating static 192.168.2.0/24 (0x0) via 10.10.10.1
*Feb 11
15:46:35.014: RT: rib update return code: 17
*Feb 11
15:46:35.014: RT: updating static 192.168.2.0/24 (0x0) via 10.10.10.1
*Feb 11
15:46:35.014: RT: rib update return code: 17
*Feb 11
15:46:43.194: IP SLAs(1) Scheduler: saaSchedulerEventWakeup
No hay comentarios:
Publicar un comentario
Nota: solo los miembros de este blog pueden publicar comentarios.