Servidor TFTP en CentOS/RHEL. Backup configuraciones Cisco

     En este artículo vamos a ver como montar/configurar un servidor TFTP para que recoja las configuraciones de nuestros equipos Cisco. El equipo Cisco vamos a configurarlo para que envíe las configuraciones periódicamente y así tener un backup de las mismas:

     Empezamos con los pasos para instalar/configurar servidor:

1-. Instalamos el servidor TFTP mediante el comando:

yum -y install tftp-server

VPN overlapping networks (Túnel IPsec)

     En este laboratorio vamos a conectar, mediante una VPN IPsec site-to-site, dos subredes cuyo direccionamiento IP se solapa.

     Para evitar el problema de solapamiento de las subredes nateamos cada una de ellas a una nueva subred diferente. En el laboratorio haremos dos configuraciones: una mediante NAT 'tradicional' y otra mediante NAT-NVI.

Cisco IPSEC VPN site-to-site con ISP redundantes o de backup (IP SLA)

     En este laboratorio vamos a implementar una solución  para conectar 2 sites mediante túneles VPN IPSEC site-to-site con accesos de ISPs redundantes. Tendremos un camino principal y cuando este no este disponible utilizaremos el de backup. Para establecer el backup utilizaremos la facilidad de tracking de rutas estáticas lo que nos permite utilizar conexiones redundantes a Internet. 

     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.

Cisco NAT. Como funciona..

     Como veo que hay algunas dudas sobre como funciona el NAT tradicional o por dominios diferenciados entre inside y outside, vamos a aclarar algunos conceptos básicos. Lo primero indicar que la parte del paquete IP que se traducirá (source address o destination address) dependerá tanto de la dirección en que viaje el paquete como de la configuración que hayamos aplicado.

Cisco NVI (NAT Virtual Interface)

     En este laboratorio vamos a ver la utilización del Interfaz Virtual de NAT (NVI). Esta facilidad elimina el requerimiento de configurar dominios de NAT, es decir, un interface como NAT interno y otro como NAT externo. Simplemente definimos los interfaces en los que queremos utilizar NAT.

     Cuando configurarmos el NAT tradicional necesitamos tener al menos un interface como 'NAT outside' y otro interface como 'NAT inside' y configurar una serie de reglas de traducción. Para configurar Nat Virtual Interface (NVI) necesitamos al menos un interface con NAT habilitado y la misma serie de reglas de traducción.

Pix Firewall. Conexiones TCP y su finalización

     Cuando el firewall PIX finaliza una conexión genera un mensaje en la log que proporciona la razón para la terminación de la misma. Por ejemplo:

2012-02-27 12:08:42 Local4.Info PIX_678 Feb 27 2012 12:08:42: %PIX-6-302014: Teardown TCP connection 999 for outside:195.212.29.164/5451 to Intf3:192.168.250.121/3389 duration 0:00:06 bytes 0 SYN Timeout

2012-02-27 12:08:42 Local4.Info PIX_678 Feb 27 2012 12:08:42: %PIX-6-302014: Teardown TCP connection 998 for outside:195.212.29.164/23107 to Intf3:192.168.250.121/3389 duration 0:00:07 bytes 0 TCP Reset-O

Frame Relay. Backup interface

El objetivo de esta maqueta es:

• Implementar una red Frame Relay con 2 routers funcionando como switches y utilizando entre ellos el protocolo estándar de señalización NNI (Network-to-Network Interface). 
• Probar la funcionalidad de respaldar la conectividad a través de la nube Frame Relay mediante la facilidad de respaldo de un interface por otro interface.  Con ello se intenta emular el servicio CVP+ de Telefónica, si bien no es del todo posible dada la imposibilidad de solapar destinos en la rutas Frame Relay.

     En esta maqueta, para no tener dependencia del esquema IP, trabajaremos sin direccionamiento IP definido en los interfaces WAN. Trabajaremos con la facilidad “IP unnumbered” para permitir tráfico IP en la WAN y con routing dinámico a través de EIGRP.

Frame Relay. Maqueta backup con dos CVPs permanentes

     El objetivo de esta maqueta es:

• Implementar una red Frame Relay con 2 routers funcionando como switches y utilizando entre ellos el protocolo estándar de señalización NNI (Network-to-Network Interface). 
• Probar la funcionalidad de respaldar la conectividad a través de la nube Frame Relay mediante la implementación de 2 caminos con CVPs permanentes.

     Para ello se configuran los routers ‘HUBIBM’ y ‘HUBSAB’ como FRAD (Frame Relay Access Device) proporcionando LMI ccitt y clock (2M) a los CPE (Customer Premise Equipment) ‘IBM’ y ‘SAB’.

     La elección del camino ‘preferente’ viene determinada por el peso de las rutas.

MPLS. Dual CE + HSRP

     En este laboratorio vamos a simular la conexión de un cliente a la red e-VPN a través de dos CE's instalados en su site. Dotaremos de alta disponibilidad o redundancia al tráfico saliente mediante el protocolo propietario de Cisco HSRP. Con este protocolo uno de los CE será el primario o activo y el otro estará como standby o pasivo. El secundario pasará a activo si se produce un fallo en el enlace con el CE o una caída del router primario. Los servidores tendrán configurado como gateway la dirección IP virtual de HSRP.

G703 y G704

     G.703 es un estándar ITU que describe las características físicas y eléctricas de las interfaces digitales jerárquicas para la transferencia de datos entre dos equipos a través de circuitos digitales. Presenta un método para codificar la señal que se transmite entre los dos extremos de la comunicación.

     G.703 describe la transmisión de voz sobre canales digitales como E1 (T1 está definido en ANSI T1.403). Es una recomendación asociada con el método de digitalización PCM (Pulse Code Modulation) definido en detalle por el estándar G.711 que requiere un ancho de banda de 64 Kbps (E0), unidad básica para el estándar G.703.

MPLS. Enrutamiento en base a etiquetas. Cont.

     El principio de una red MPLS es el enrutamiento en base a etiquetas (más adelante veremos que en concreto se  trata de la etiqueta exterior). Esta etiqueta es añadida entre la información de nivel 2 y nivel 3 en el interfaz de entrada a la red por el PE al que se encuentra conectado el cliente.

MPLS Básico. Práctica

     En este laboratorio vamos a explicar el funcionamiento de una red básica MPLS, tanto el enrutamiento en la backbone a través de etiquetas, como la “formación” de redes virtuales VPNs en los routers de acceso a la red para que la backbone IP pueda ser compartida por varios clientes sin que por ello la seguridad de la red se vea afectada. Los PE’s intercambiaran información de las VPNs conectadas a través de MP-BGP.

Práctica. Frame Relay, NAT, Tunneling

          Siguiendo con la base de Frame Relay vamos a meter NAT y tunnelizar el tráfico. El router Getafe debe ir a SP1 pero apuntando a una dirección diferente, esa dirección es la 25.25.25.25. Además, SP1 debe recibir peticiones únicamente de la dirección 11.11.11.52, es decir, el router debe transformar la dirección origen en esa nueva.

Práctica. Frame Relay y route-map

     Laboratorio en el que tomando como base el de Frame Relay switching pretendemos encaminar un tráfico específico a través de la conexión  RDSI. El objetivo es desde el router Getafe llegar a la lan del edificio. De manera que, si se hace a un host concreto (135.76.35.80) el tráfico se encaminará por rdsi, pero si se va al resto de la red,  se encaminará por frame relay.

Práctica. Frame Relay switching

   Laboratorio donde implementamos Frame Relay switching y backup de Frame Relay por RDSI. Sobre el esquema: Aranjuez y Alcorcon hacen de switch Frame-relay proporcionando LMI ansi y clock a Aluche y Leganes. Backup RDSI iniciando llamada Aluche.