Estudio de caso de alta disponibilidad
en servidores sin NLB
Fecha: 3 de diciembre del 2017 Clase: Programa de administración de datacenters (4/11)
Escenario
En este escenario, se propone la creación de un esquema redundante para servidores en un datacenter
principal (CPD) y un datacenter alternativo (CDA), sin la utilización del protocolo NLB (Network Load Balancing)
para clusters de servidores, utilizando sólo las herramientas aprendidas en la carrera CCNA.
La idea es que tanto los servers en CPD (192.168.10.10) y en CDA (192.168.10.11), se vean como uno solo
mediante una única IP virtual (192.168.1.10).
Consideramos que los servers replican sus datos por otro canal diferente (fuera de banda) no lo estudiaremos
en este escenario ya que sólo nos centraremos en la conectividad (capas 2, 3 y 4).
1.- Verificación inicial
Se verifica el acceso al server ubicado en el CPD, ahora hay que planificar una contingencia transparente para
el usuario, ni que haya que cambiar ninguna IP o gateway.
2.- Solución: ARP + NAT + HSRP + OSPF = transparente para el usuario.
Se utilizan estos protocolos en este orden:
1.- El usuario ingresa la URL http://192.168.1.10
2.- El host verifica que esta IP destino está dentro de la misma subred.
3.- El host genera un ARP solicitando la dirección MAC de la IP ingresada.
4.- El router CPD (principal)negoció previamente HSRP (Hot Standby Redundancy Protocol) contra CDA para
hacerse cargo del servicio de gateway de la red 192.168.1.0/24 (usuarios) y 192.168.10.0/24 (servidores).
GW-CPD>
%HSRP-6-STATECHANGE: Vlan1 Grp 0 state Speak
-> Standby
%HSRP-6-STATECHANGE: Vlan1 Grp 0 state Standby
-> Active
%HSRP-6-STATECHANGE: Vlan2 Grp 0 state Speak
-> Standby
%HSRP-6-STATECHANGE: Vlan2 Grp 0 state Standby
-> Active
GW-CPD>
GW-CDA>
%HSRP-6-STATECHANGE: Vlan2 Grp 0 state Speak
-> Standby
%HSRP-6-STATECHANGE: Vlan1 Grp 0 state Speak
-> Standby
GW-CDA>
5.- El router CPD (principal), responde con su propia MAC ya que tiene un static NAT configurado
entre la IP 192.168.1.10 y 192.168.10.10 y debe responder por dicha IP.
6.- El host envía el HTTP GET hacia el server mediante la IP virtual (obviamos el saludo de 3 vías TCP para simplificar).
7.- El router CPD recibe la petición HTTP del usuario a 192.168.1.10, la traduce como 192.168.10.10 (server CPD) y la
reenvía mediante una petición ARP solicitando la MAC de la IP 192.168.10.10.
GW-CPD#sh
ip nat translations
Pro
Inside global Inside
local Outside local Outside global
--- 192.168.1.10 192.168.10.10 --- ---
tcp 192.168.1.10:80 192.168.10.10:80 192.168.1.100:1025 192.168.1.100:1025 (server de CPD)
GW-CPD#
8.- El server del CPD recibe la solicitud y la responde, utilizando como gateway el router del CPD debido al HSRP.
9.- El router del CPD recibe la respuesta del server, traduce la IP de origen del server en 192.168.1.10 y la reenvía a
la red de usuarios, al host que solicitó en el punto 7.
10.- El host del usuario recibe la respuesta y la muestra en el browser.
3.- Pruebas de contingencia (I):
En caso de que el router del CPD falle, HSRP configurará como activo el router del CDA, reenviando las peticiones de
los puntos 5, 7 y 9 (estos pasos son algo mas complejos como el handshacking TCP, etc, pero no es el caso de estudio
de este laboratorio, aquí estudiamos sólo la redundancia y su comportamiento).
GW-CDA#
%HSRP-6-STATECHANGE: Vlan2 Grp 0 state Standby
-> Active
%HSRP-6-STATECHANGE: Vlan1 Grp 0 state Standby
-> Active
GW-CDA#
Verificamos en el usuario y la solicitud inicial falla debido a la persistencia de la MAC del router CPD
asociada a la IP 192.168.1.10 en la tabla ARP del usuario.
PC>arp
–a (verificamos gateway)
Internet Address Physical
Address Type
192.168.1.10 0050.0f9c.5110 dynamic
PC>arp –d (purgamos tabla de ARP)
PC>
Esto hace que nuestra prueba no sea transparente al usuario, aunque en Packet Tracer no lo podemos
reproducir, podemos generar un gratuitos ARP en el router para reconfigurar las tablas, recordemos que
este lab es una “solución casera” a la falta de NLB en los servidores.
En la vida real, la falta de conexiones durante un tiempo puede hacer expirar la entrada ARP en la PC,
también podemos aplicar otros métodos como ARP gratuito o algún script.
PC>arp
-a
Internet Address Physical
Address Type
192.168.1.10 00e0.f766.a475 dynamic (ahora es diferente a 0050.0f9c.5110)
PC>
Verificamos traducción NAT hacia el server del CDA:
GW-CDA#sh
ip nat translations
Pro
Inside global Inside
local Outside local Outside global
--- 192.168.1.10 192.168.10.11 --- ---
tcp 192.168.1.10:80 192.168.10.11:80 192.168.1.101:1028 192.168.1.101:1028 (server del CDA)
GW-CDA#
4.- Pruebas de contingencia (II):
Ahora analizaremos si falla sólo una de las interfaces de los switchs de capa 3 (gateway entre redes).
En este caso actúa OSPF para encontrar el camino a los paquetes entre las diferentes redes.
Este caso puntual, si no disponemos de tracking HSRP entre interfaces, el proceso es el siguiente:
1.- El usuario ingresa la URL http://192.168.1.10
2.- El host verifica que esta IP destino está dentro de la misma subred.
3.- El host genera un ARP solicitando la dirección MAC de la IP ingresada.
4.- El router CPD (principal)negoció previamente HSRP (Hot Standby Redundancy Protocol) contra CDA para
hacerse cargo del servicio de gateway de la red 192.168.1.0/24 (usuarios) y 192.168.10.0/24 (servidores), pero CDA
se hace cargo del gateway de la red de servidores.
GW-CDA>
%HSRP-6-STATECHANGE: Vlan2 Grp 0 state Standby
-> Active (en red de servidores)
00:30:31: %OSPF-5-ADJCHG: Process 1, Nbr
192.168.10.3 on Vlan2 from FULL to DOWN, Neighbor Down: Dead timer expired
00:30:31: %OSPF-5-ADJCHG: Process 1, Nbr
192.168.10.3 on Vlan2 from FULL to DOWN, Neighbor Down: Interface down or
detached
GW-CDA>
5.- El router CPD (principal), responde con su propia MAC ya que tiene un static NAT configurado
entre la IP 192.168.1.10 y 192.168.10.10 y debe responder por dicha IP.
6.- El host envía el HTTP GET hacia el server mediante la IP virtual del mismo.
7.- El router CPD recibe la petición HTTP del usuario a 192.168.1.10, la traduce como 192.168.10.10 (server CPD) y la
intenta reenvíar, pero al tener la interface 192.168.10.0/24 DOWN, busca en su tabla de enrutamiento, encontrando
la red de destino por OSPF a través de la IP 192.168.1.2 (router CDA), reenvía la solicitud HTTP hacia el destino,
paradojicamente ya traducida (“nateada”), aunque el paquete no se haya transmitido por la interface inside sino por
un reenvío por la outside.
GW-CPD#sh
ip route
Codes: C - connected, S - static, I - IGRP, R -
RIP, M - mobile, B - BGP
D
- EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1
- OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
*
- candidate default, U - per-user static route, o - ODR
P
- periodic downloaded static route
Gateway of last resort is not set
C
192.168.1.0/24 is directly connected, Vlan1
O 192.168.10.0/24 [110/2] via 192.168.1.2, 00:07:29, Vlan1
GW-CPD#
GW-CPD#sh
ip nat translations
Pro
Inside global Inside
local Outside local Outside global
---
192.168.1.10
192.168.10.10 --- ---
tcp 192.168.1.10:80 192.168.10.10:80 192.168.1.100:1025 192.168.1.100:1025
tcp 192.168.1.10:80 192.168.10.10:80 192.168.1.100:1026 192.168.1.100:1026
tcp 192.168.1.10:80 192.168.10.10:80 192.168.1.100:1027 192.168.1.100:1027
GW-CPD#
8.- El router del CDA recibe el paquete con destino 192.168.10.10 (ya “nateado”) y lo reenvía hacia la red de servers
sin traducir ya que ahora el paquete no tiene como destino 192.168.1.10 sino 192.168.10.10 y por lo tanto no aplica
a la regla del static NAT.
GW-CDA#sh
ip nat translations
Pro
Inside global Inside
local Outside local Outside global
--- 192.168.1.10 192.168.10.11 --- ---
GW-CDA#
9.- El server del CPD recibe la solicitud y la responde, utilizando
como gateway el router del CDA debido al HSRP.
10.- El router del CDA recibe la respuesta del server, no traduce la IP de origen del server en 192.168.1.10 ya que la regla
de NAT configurada sólo traduce el origen 192.168.10.11, reenvía el paquete al host de origen (192.168.1.100).
11.- El host del usuario recibe la respuesta y la descarta ya que viene desde la IP 192.168.10.10 (sin natear).
Como dato curioso, si verificamos con ping este responde:
PC>ping
192.168.1.10
Pinging 192.168.1.10 with 32 bytes of data:
Reply from 192.168.10.10: bytes=32 time=14ms
TTL=127
Reply from 192.168.10.10: bytes=32 time=12ms
TTL=127
Reply from 192.168.10.10: bytes=32 time=0ms
TTL=127
Reply from 192.168.10.10: bytes=32 time=0ms
TTL=127
Esto se debe a que la respuesta de eco es un paquete nuevo originado en 192.168.10.10 y hacia 192.168.1.100, con
TCP todo es parte del mismo flujo y no se alcanza a completar el saludo inicial, entonces el paquete se descarta.
Para esto se debe configurar el tracking de HSRP que hace que si en el router CPD una de las interfaces cambia a DOWN
la otra interface pasa a standby y el router CDA queda como activo:
GW-CPD(config)#int vlan 1
GW-CPD(config-if)#standby 0 track fastEthernet 0/23
GW-CPD(config-if)#end
GW-CPD#
Cae la interface en VLAN de servidores:
%LINK-5-CHANGED: Interface FastEthernet0/23,
changed state to down
%LINEPROTO-5-UPDOWN: Line protocol on Interface
FastEthernet0/23, changed state to down
%LINEPROTO-5-UPDOWN: Line protocol on Interface
Vlan2, changed state to down
00:03:18: %OSPF-5-ADJCHG: Process 1, Nbr
192.168.10.2 on Vlan2 from FULL to DOWN, Neighbor Down: Interface down or
detached
Verificación en CPD:
GW-CPD#sh standby
Vlan1 - Group 0 (version 2)
State is Standby
8
state changes, last state change 00:02:40
Virtual
IP address is 192.168.1.10
Active
virtual MAC address is 0000.0C9F.F000
Local
virtual MAC address is 0000.0C9F.F000 (v2 default)
Hello
time 3 sec, hold time 10 sec
Next
hello sent in 0.036 secs
Preemption enabled
Active router is 192.168.1.2
Standby router is local
Priority 90 (default 100)
Track
interface FastEthernet0/23 state Down
decrement 10
Group
name is hsrp-Vl1-0 (default)
Vlan2 - Group 0 (version 2)
State
is Init (interface down)
Virtual
IP address is 192.168.10.1
Active
virtual MAC address is unknown
Local
virtual MAC address is 0000.0C9F.F000 (v2 default)
Hello
time 3 sec, hold time 10 sec
Next hello
sent in 1.180 secs
Preemption enabled
Active router is unknown
Standby router is unknown
Priority 100 (default 100)
Group
name is hsrp-Vl2-0 (default)
GW-CPD#
Verificación en CDA:
%HSRP-6-STATECHANGE: Vlan2 Grp 0 state Standby
-> Active
00:03:52: %OSPF-5-ADJCHG: Process 1, Nbr
192.168.10.3 on Vlan2 from FULL to DOWN, Neighbor Down: Dead timer expired
00:03:52: %OSPF-5-ADJCHG: Process 1, Nbr
192.168.10.3 on Vlan2 from FULL to DOWN, Neighbor Down: Interface down or
detached
GW-CDA#sh
standby
Vlan1 - Group 0 (version 2)
State is Active
7
state changes, last state change 00:02:20
Virtual
IP address is 192.168.1.10
Active
virtual MAC address is 0000.0C9F.F000
Local
virtual MAC address is 0000.0C9F.F000 (v2 default)
Hello
time 3 sec, hold time 10 sec
Next
hello sent in 2.25 secs
Preemption disabled
Active router is local
Standby router is 192.168.1.3
Priority 100 (default 100)
Group
name is hsrp-Vl1-0 (default)
Vlan2 - Group 0 (version 2)
State is Active
9 state
changes, last state change 00:03:25
Virtual
IP address is 192.168.10.1
Active
virtual MAC address is 0000.0C9F.F000
Local
virtual MAC address is 0000.0C9F.F000 (v2 default)
Hello
time 3 sec, hold time 10 sec
Next
hello sent in 0.404 secs
Preemption disabled
Active router is local
Standby router is unknown
Priority 100 (default 100)
Group
name is hsrp-Vl2-0 (default)
GW-CDA#
En este caso al solicitar la página en el servidor la secuencia será la siguiente:
1.- El usuario ingresa la URL http://192.168.1.10
2.- El host verifica que esta IP destino está dentro de la misma subred.
3.- El host genera un ARP solicitando la dirección MAC de la IP ingresada.
4.- El router CDA (contingencia) negoció mediante HSRP (Hot Standby Redundancy Protocol) contra CPD y al tener
prioridad mas alta (100 contra 100-10=90) se transformó en activo y escucha en la IP 192.168.1.10 y debe
hacerse cargo del servicio de gateway de la red 192.168.1.0/24 (usuarios) y 192.168.10.0/24 (servidores).
5.- El router CDA (contingencia), responde con su propia MAC ya que tiene un static NAT configurado
entre la IP 192.168.1.10 y 192.168.10.11 y debe responder por dicha IP.
6.- El host envía el HTTP GET hacia el server mediante la IP virtual (obviamos el saludo de 3 vías TCP para simplificar).
7.- El router CDA recibe la petición HTTP del usuario a 192.168.1.10, la traduce como 192.168.10.11 (server CDA) y la
reenvía mediante una petición ARP solicitando la MAC de la IP 192.168.10.11.
8.- El server del CDA recibe la solicitud y la responde, utilizando como gateway el router del CDA debido al HSRP.
9.- El router del CDA recibe la respuesta del server, traduce la IP de origen del server en 192.168.1.10 y la reenvía a
la red de usuarios, al host que solicitó en el punto 6.
10.- El host del usuario recibe la respuesta y la muestra en el browser.
5.- Reflexión:
Como se mencionó al principio, la solucuion definitiva es NLB u otro protocolo similar, la idea era resoverlo con lo que
tenemos a mano como networkers.
Si bien es fácil buscar en internet e implementar soluciones, tanto de HSRP, NLB o del protocolo que sea, es fundamental
entender los procesos involucrados para que todo esto funcione, es lo que nos diferencia como buenos profesionales
a la hora de resolver problemas.
A estudiar !
(2017) Summer, girls & networking
Rosario, Argentina