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