Router Cisco como Servidor TFTP

Muchas veces necesitamos transferir algunos archivos entre routers, ya se una config o bien algún archivo binario.

Los libros nos enseñaron que necesitamos un servidor TFTP externo, copiar los archivos a ese servidor y luego bajarlos desde el cliente.

En casos de urgencia debemos perder bastante tiempo buscando algún software, instalándolo y otorgando permisos, y esta pequeña receta nos puede ser de utilidad en esos casos de apuro.

IOS puede configurarse como servidor básico de TFTP para la copia eventual de algunos archivos. Veamos como:

! Permitir el acceso al archivo config.txt guardado en el dispositivo disk0.

tftp-server disk0:config.txt

! Permitir el acceso a la config de IOS, pero usando un

! nombre más corto (config.txt) como alias.

tftp-server disk0:c7200-tftpserver-config-201012101000 alias config.txt

! Permitir la descarga del archivo de sistema operativo con un nombre

! corto llamado ios.bin pero que sea accesible solo desde los hosts

! permitidos en el access-list estándar número 69.

tftp-server disk0:c7200-adventerprisek9-mz.124-24.T.bin alias ios.bin 69

Probemos...

Client#copy tftp://192.168.0.1/config.txt flash

Destination filename [config.txt]?

Accessing tftp://192.168.0.1/config.txt...

Erase flash: before copying? [confirm]n

Loading config.txt from 192.168.0.1 (via FastEthernet0): !  

[OK - 1282 bytes]                      

Introducción al Multicast (Parte III)

Según vimos en laprimer y la seguda parte de esta mini introducción al multicast, es posible transmitir información a un determinado grupo de equipos.

También analizamos que el origen de los datos necesita enviar una única copia y luego los dispositivos intermedios (routers, switches) se encargarán de crear una copia en cada puerto donde se encuentre conectado un cliente que desea recibir el tráfico de multicast. Pero antes de llegar a esto debemos razonar lo siguiente:

• Sabemos que los switches ethernet no guardan direcciones MAC de multicast en su tabla CAM, dado que nunca se origina una trama con una dirección de multicast como dirección de origen. 
• También sabemos que si una trama con dirección de destino de capa dos no se encuentra aprendida (no existe en la tabla CAM), el switch hace flooding (copia la trama en todos los puertos de la VLAN salvo en el que la originó).

Esto nos lleva a que según este modelo el tráfico de multicast pasa a ser muy parecido al tráfico de broadcast, la CAM tiene información y por ende los paquetes van hacia todos los hosts. Algo nos está faltando...

IGMP

El Internet Group Management Protocol definido en varias RFC se utiliza entre los routers y los dispositivos directamente conectados a ellos para preguntar o informar si se desea recibir (o dejar de recibir) el tráfico de un grupo determinado (grupo = dirección multicast).

Actualmente la versión 2 de IGMP es la más utilizada, a pesar de que ya existe una RFC para la versión 3.

La idea básica de esto es que la PC envía mensajes IGMP al router para avisarle que se quiere unir a un grupo determinado. El router está todo el tiempo escuchando esas peticiones llamadas IGMP joins/leaves, y a la vez los routers realizan preguntas llamadas IGMP queries a intervalos regulares para confirmar que las PC desean seguir recibiendo el tráfico destinado al grupo.

De acuerdo a los IGMP que el router reciba, podrá determinar si debe hacer forward de los paquetes de multicast en cada interfase. De la misma manera, los switches deben aprender cuáles de todos sus puertos tienen conectados los equipos interesados en recibir los datos destinados a cierto grupo.

Dado que el protocolo IGMP no tiene como origen y destino los dispositivos de capa dos, los switches utilizan un feature llamado IGMP Snooping, que viene a ser como un sniffer de paquetes de IGMP.

Hablando mal y pronto, el switch está espiando todo el tiempo el tráfico en busca de diálogos del protocolo IGMP, cuando ve los paquetes de IGMP join va aprendiendo la topología de multicast y sabe en que puerto esta el router y los hosts que desean recibir los datos destinados a un grupo en particular.

De igual manera, cuando encuentra un paquete de IGMP leave borra los datos aprendidos y deja de reenviar la información al puerto donde está el host que desea irse del grupo.

En un entorno de equipos Cisco hay otra opción propietaria de esta marca que se llama CGMP (Cisco Group Management Protocol) que hace que los routers se comuniquen con los switches e informen los grupos y los equipos interesados en ellos para que estos switches modifiquen su tabla CAM.

Esto es un panorama a vuelo de pájaro para que se pueda entender -al menos- un poco mejor el tema de multicast y su funcionamiento. Obviamente hay muchísimas cosas que decir de CGMP, IGMP y sus múltiples versiones pero la idea es no complicar tanto el post.

Introducción al Multicast (Parte II)

Como vimos en el capítulo anterior, unicast no escala cuando se debe enviar la misma información a muchos destinos dado que el ancho de banda requerido se multiplica por la cantidad de receptores de la información.

Por otro lado si usamos broadcast, los receptores no pueden estar atrás de un router dado que estos no los transmiten. Además estamos generando una carga intensiva en los dispositivos de red y desperdiciando ancho de banda.

Ahora bien, necesariamente tengo que aclarar un par de conceptos que son naturalmente elementales y en una magnitud tal que la mayoría de la gente nunca se detiene a pensar. Estoy hablando de la relación entre el direccionamiento de capa 2 y capa 3.

Conocemos perfectamente que a nivel de capa 3 una dirección IPv4 tiene una longitud de 32 bits y una dirección de capa 2 (MAC) del archifamoso protocolo Ethernet tiene 48 bits.

Es evidente que debemos contar con algo que relacione unívocamente cada una de estas direcciones dado que son de distinto tamaño y no es un requerimiento necesario que sean iguales.

En el caso de IPv4 existe un protocolo llamado ARP que se encarga de armar una "tabla de equivalencias" en cada host, que contiene direcciones IP y sus correspondientes MAC asociadas.

¿Por qué me detengo en este detalle?

Los equipos cuando quieren mandar información a otro host conocen la dirección IP de destino (generalmente obtenida por consultas DNS) y al momento de poner la información  en los cables, deben armar los encabezados de la capa de enlace de datos y por ende, deben conocer la dirección MAC de destino.

En multicast IPv4, existe una relación entre las direcciones MAC y las direcciones de grupo (IP's de clase D).

Supongamos el ejemplo de un servidor que envía un streaming a una LAN:

Cuando el servidor quiere usar Unicast y enviar datos a la PC D, arma los paquetes de la siguiente manera:

Capa 3:

IP Origen: 192.168.1.10

IP Destino: 192.168.1.14

Capa 2:

MAC Origen: aaaa.aaaa.aaaa

MAC Destino: 0000.0000.649a

Ahora imaginemos, que si seguimos el mismo ejemplo con Multicast a la dirección de grupo 239.1.1.10 tendríamos:

Capa 3:

IP Origen: 192.168.1.10

IP Destino: 239.1.1.10

Capa 2:

MAC Origen: aaaa.aaaa.aaaa

MAC Destino: ¿?

¿A qué dirección MAC debe enviar las tramas?

Es evidente que no puede ser ninguna MAC de alguno de los equipos, porque sino la información se transformaría en Unicast, dado que el switch replicaría la trama en un único puerto. Esto me lleva a citar una frase que siempre enfatizo con mis alumnos:

Antes de que exista Unicast, Multicast o Broadcast en capa 3, debe existir en capa 2.

Todos los hosts deben acordar una dirección MAC común que puedan utilizar para recibir las tramas dirigidas al grupo de multicast 239.1.1.10. Y no solo eso, sino que tambien el switch debe comprender que esa dirección MAC no se va a guardar como perteneciente a un solo puerto, sino a varios.

Verán ahora que la MAC en cuestión no se negocia, sino que se calcula según lo que veremos a continuación.

La IEEE registró un OUI que es el prefijo de todas las direcciones MAC relacionadas con direcciones IPv4. Dicho prefijo es: 01:00:5e

Verán el bit marcado en rojo, este es el bit menos significativo del byte más significativo de la dirección MAC (el último bit del primer byte en criollo) y determina que la MAC es de multicast. Cuando los switches ven este bit en 1 en cualquier dirección MAC entienden que no deben almacenar esa dirección en la tabla CAM dado que debe ser reenviada a varios puertos.

Ahora bien, sabemos que se calcula una dirección MAC de multicast en base a un OUI fijo y a la dirección de grupo, pero la problemática a la que nos enfrentamos es que una dirección IP tiene 32 bits y solo nos restan 24 de la dirección MAC, por lo que no podremos directamente pegar los bits de la dirección de grupo en la MAC dado que no nos alcanza el espacio. En cambio, podemos realizar el siguiente análisis:

Las direcciones de clase D se utilizan para multicast comprenden el rango desde la 224.0.0.0 a la 239.255.255.255, por lo que podemos ver que cualquier dirección que está dentro de ese rango tiene la forma:

Dado que los bits 1110 pasados a decimal son 128 + 64 + 32 + 0 = 224 y si el cuerto bit estuviese en 0 se sumarían 16 más y el 240 no está incluído en las clases D.
Si entendemos esto, podemos comprender que como estos bits siempre tienen el mismo valor para direcciones multicast de IPv4, podemos desestimarlos y no incluírlos en nuestra futura dirección  MAC de multicast:

Ahora tenemos 28 bits para almacenar y 24 bits disponibles. Ya nos estamos acercando a nuestra meta.

Lo que la gente de la IEEE pensó es en desestimar los bits 4 a 8 del primer byte y el primer bit del segundo byte y transformarlos en un único bit con valor cero.

En criollo:

1. Tomar los 5 bits que quedan en el primer byte incluyendo el primero del byte 2.
2. Reemplazarlos por un solo bit en cero.

Ahora si... transladamos los 24 bits a la dirección MAC de multicast.

En un ejemplo práctico:

Dirección IPv4: 224.0.0.5 (OSPF)

Binariamente es: 11100000.00000000.00000000.00000101

Quito la parte en rojo, que es siempre igual para todas las direcciones

____0000.00000000.00000000.00000101

Ahora transformo los próximos 5 bits en un solo cero:

00000000.00000000.00000101

Paso esto a hexadecimal:

00000000.00000000.00000101 = 00.00.05

Luego agrego el OUI de multicast (01:00:5E) como prefijo:

01:00:5E:00:00:05

Esa será la MAC address de multicast que todos los equipos se pondrán para recibir los datos del grupo.

Vamos a otro ejemplo:

Dirección IPv4: 239.140.125.94
En binario: 11101111.10001100.01111101.01011110
Quito los primeros 4 bits y comprimo los próximos 5: 00001100.01111101.01011110
Paso a hexadecimal:  0C:7D:5E
Agrego el OUI: 01:00:5E:0C:7D:5E

¿Fácil, no?

Ahora probemos con la IP: 231.12.125.194
En binario: 11100111.00001100.01111101.01011110
Quito los primeros 4 bits y comprimo los próximos 5: 00001100.01111101.01011110
Paso a hexadecimal:  0C:7D:5E
Agrego el OUI: 01:00:5E:0C:7D:5E <-- ¡¡¡ES LA MISMA QUE CALCULAMOS ANTES!!!

¿Qué pasó?

Cuando nosotros comprimimos los 5 bits en un solo valor en cero, estamos pisando 2^5 bits, por lo que 32 valores de direcciones IP van a corresponder a una única MAC.

Mini-HOWTO como configurar ssh en un router

Router(config)#hostname joanmanuel
Configuramos el hostname, de lo contrario el IOS no nos permite configurar SSH.
joanmanuel(config)#ip domain-name  joanmanuel.com
Configuramos el nombre de dominio.
joanmanuel(config)#crypto key generate rsa 1024
Con este comando generamos una llave pública de 1024 bits. El protocolo SSH cifra todos los datos enviados y recibidos a través del puerto 22. Para esto fines, se utiliza el algoritmo de cifrado asimétrico RSA. 

joanmanuel(config)#ip ssh time-out 30
Configuración de tiempo de espera. Si a los 30 segundos de inicializar la conexión el usuario no introduce su usuario y contraseña, automáticamente se cae la conexión.
joanmanuel(config)#ip ssh authentication-retries 3
Con este comando establecemos un máximo de tres intentos para que un usuario se valide en el sistema. De lo contrario el usuario deberá restablecer una nueva sesión.
joanmanuel(config)#ip ssh version 2
Este comando establece que utilizaremos la versión 2 del protocolo SSH. La versión 1 tiene un fallo de seguridad terrible. No se recomienda su uso bajo ninguna circunstancia.
joanmanuel(config)#username admin privilege 15 password  cisco
Creamos un usuario y password para podernos conectar al equipo a través de SSH.
joanmanuel(config)#line vty 0 4
Habilitamos 5 puertos virtuales para las conexiones SSH.
joanmanuel(config-line)#transport input ssh
Establecemos que el protocolo a utilizar para conexiones remotas será SSH.
joanmanuel(config-line)#login local
Configuramos que la validación de los usuarios que ingresen al equipo a través de SSH se realizará de manera local, es decir, verificando el usuario y password estén debidamente creados en el Cisco IOS.

Como configurar DHCP en Router

Como saber configurar el servicio de Dynamic Host Configuration Protocol (DHCP) dentro en un Router Cisco
La siguiente configuración muestra cómo podemos configurar un Router Cisco para que sirva de servidor de DHCP en una red LAN. Esta configuración es sencilla, sólo intentamos configurar los nodos de la red, 
A continuación tenemos el procedimiento:

Paso #1
R1>enable
Entra al modo de configuración Privilegiado.
R1#configure terminal
Entra al modo de configuración Global.
R1(config)#ip  dhcp pool LAB_joan
Crea el Pool de direcciones IP.
Paso #2
R1(dhcp-config)#domain-name joanmanuel.com
Especifica el nombre de dominio.
Paso #3
R1(dhcp-config)#network 10.0.0.0 255.255.255.0
Especifica la dirección IP que, es lo mismo decir, especifica el rango de las direcciones IP a asignar. Como la máscara es /24, entonces el rango de direcciones IP a asignar serán desde la 10.0.0.1 hasta la 10.0.0.254.
Paso #4
R1(dhcp-config)#lease 1
Especifica el tiempo máximo que puede asignarse una dirección IP a un nodo de la red. En este caso, el tiempo especificado es 1 días. Después de las 24 horas, el nodo hará un “Refresh” y se le asignará una nueva dirección IP.
Paso #5
R1(dhcp-config)#dns-server 8.8.8.8 196.3.81.5
Especifica los servidores de nombres de dominio.
Paso #6
R1(dhcp-config)#default-router 10.0.0.1
Especifica la dirección de la puerta de enlace en la red LAN.


otra funcion importante de configurar DHCP en los  router es para  “darle vida” a los teléfonos IP.
A través del servicio DHCP le pasamos a los teléfonos IP los siguientes parámetros:

• IP Address
• Netmask
• Default Gateway
• IP Telephony Service
• TFTP Server