Documentos de Académico
Documentos de Profesional
Documentos de Cultura
I Características
Hace poco me dí cuenta de que el tema del packet tracer (PT) está muy poco explorado y
a veces se subestima el poder del PT para desarrollar las actividades de los cursos de
CCNA y sobre todo el valor didáctico que tiene: en él se pueden experimentar todas las
alternativas que se le ocurran a un estudiante para terminar de entender lo que se le ha
explicado y lo que ha leído. Así que a partir de esta entrada comenzaré una serie de
entradas sobre el uso del PT, que servirá tanto a estudiantes como a instructores. Hoy
comentaré las características que hacen del PT una gran herramienta, no sólo por la
potencia de simulación sino por la facilidad de uso. Disfrútenlo.
El PT está vinculado con las academias de networking de Cisco, es una aplicación que
permite diseñar topologías de red con los mismos iconos que se usan en el currículum
oficial. Más allá de poder diseñar las topologías, el PT permite configurar los equipos con
casi todas las tecnologías que se mencionan en los currículos y observar cómo funcionan
como si fueran equipos reales. PT al día de hoy va en la versión 5.3.1, recientemente
liberada.
Si tuviéramos que definir PT en una frase corta sería simulador de redes de datos. El
objetivo inicial de PT es ser una herramienta didáctica, pero después de la versión 5.0, la
capacidad de simulación es tal que prácticamente puede servir para preconfigurar una red
real o ver si alguna opción de implementación experimental puede ser viable. De todos
modos hay que recordar que ese no es el objetivo de PT y por lo tanto no se puede
asegurar que lo que funcione en el PT se pueda tomar seriamente como prueba de
alguna implementación real, para eso es mejor diseñar topologías prototipo y probar con
los equipos reales, con topologías controladas o usar emuladores, también con mucho
cuidado.
PT permite, como ya lo dije, diseñar topologías con los mismos iconos del currículo, lo que
facilita el entendimiento del currículo mismo. Los equipos tienen referencias reales y su
interfaz es tan realista que si se va a cambiar la configuración física de un enrutador o switch
es necesario apagarlo. Otras características de realismo del PT es que incluye varias
formas de visualizar la topología, entre ellas, la vista física cuyo uso muestra un mapa de
alguna ciudad (no me extrañaría que fuera San Francisco) y en ella la oficina y en la oficina
el armario de cableado. Si llegamos en la vista física a dar clic en el armario de cableado nos
muestra un bastidor con los equipos que tenemos en la topología como se verían
realmente… ¡y hasta podríamos apagarlos desde ahí! (aunque sólo podríamos hacer eso).
Aparentemente el espacio físico está inacabado pero permite llegar hasta los extremos de
realismo que acabo de describir, adicionalmente se puede dividir el espacio físico en
diferentes closets, ciudades o edificios, me imagino que eso tiende a la posibilidad futura de
distribuir la topología por espacios físicos geográficamente separados como una topología
real.
Siendo un poco más pragmáticos (no tan didácticos), el PT permite acceder a cada
dispositivo de la topología y configurarlo, bien sea por una interfaz gráfica muy
intuitiva o por interfaz de línea de consola (CLI) como lo haríamos con equipos reales.
El PT es suficientemente flexible, como para que los PC simulados en una topología
tengan un escritorio, en el que se puede acceder a aplicaciones que usamos todos los días
en la red: un navegador y una consola de comandos, adicionalmente las herramientas que
usaremos ordinariamente: telnet, emulador de consola (como hyperterminal o minicom)
y configuración de acceso telefónico, red inalámbrica y red alambrada. Existe también
la posibilidad de agregar PC servidores que ejecutan servicios como HTTP, DNS y TFTP
que podríamos conectar a la red para simular transacciones, digamos, desde los
navegadores de los PCs clientes o para guardar configuraciones de equipos de red.
Dentro del currículo oficial de CCNA se explota intensivamente la posibilidad de visualizar el
flujo de paquetes que generan los dispositivos en la red, como es de esperar, con filtros para
no ver todos los protocolos que se generan -que sería abrumadores. La idea es que existe un
modo de simulación que nos permite ver y controlar la forma en que se crean y
destruyen paquetes en una topología después de disparar algún evento como hacer un
ping o intentar ver una página almacenada en uno de los servidores de la topología
desde el navegador de uno de los PC de la misma. En éste modo visualizamos el trayecto
de los paquetes por la red y si el resultado es exitoso o fallido y podemos mirar qué procesos
se le aplicaron a cada paquete en cada uno de los dispositivos por los que pasó y, en caso
de fallo, podemos llegar hasta el último proceso que no se pudo realizar. La descripcion de
cada proceso se hace con base en la terminología del modelo OSI y es tan detallada que
no queda duda de por qué falla algo una vez que llegamos a la descripción del último
proceso sufrido por un paquete en uno de los nodos de la red.
Pues a mí me parece bastante avanzado todo lo que he descrito, pero para más detalles, en
el mismo currículo de CCNA Exploration he visto laboratorios con más de 20
dispositivos: 10 enrutadores, 10 switches y como 10 PCs incluyendo PCs que usan tarjetas
inalámbricas, es decir, la potencia de simulación del PT es suficientemente grande para el
alcance de CCNA, de hecho, en algunos comentarios dicen que PT puede ser usado en
cursos de CCNP. Una característica que va de la mano con laboratorios tan grandes es la
agrupación lógica de dispositivos o clustering. Por medio de la agrupación se arreglan
varios dispositivos de red en una nube y se trata ésta como un sólo dispositivo (un sólo
icono en la topología).
Una de las características más usadas en el
currículo son las actividades, que consisten en
laboratorios con instrucciones incluidas que
llevan un registro de qué porcentaje de las tareas
que se espera que el estudiante realice se han
hecho bien, mostrando permanentemente el
porcentaje completado de la práctica.
Adicionalmente a las instrucciones y al control del
porcentaje completado, las actividades pueden
restringir algunas opciones que puedan tener
los estudiantes ordinariamente, por ejemplo,
impedir el uso de la interfaz gráfica en un servidor
o evitar la configuración de un enrutador por
interfaz gráfica, obligando así a un estudiante a usar la CLI (Command Line Interface).
Las actividades no son exclusivas del currículo, el PT tiene asistentes para crear
actividades diseñadas por cualquier persona, obviamente se espera que sean instructores.
Otra característica poderosa desde el PT 5.0 es la extensión multiusuario, que permite
desarrollar laboratorios desde diferentes computadoras, es decir, se puede dividir una
actividad para ser desarrollada en dos o más PCs que se conectan por red para
configurar la topología diseñada para la actividad. Existe incluso material adicional disponible
para los instructores en el Academy Connection que distribuye un laboratorio bastante
grande en 6 diferentes laboratorios colaborativos con supervisión del instructor. En un
contexto mucho más simple, yo lo he usado para ponerles a mis estudiantes los laboratorios
más complejos que hay en el currículo e instarlos a que los desarrollen en equipos usando la
extensión multiusuario, de otra manera sería muy difícil que lo puedan entregar a tiempo.
Una característica de PT 5.1, nueva en el producto, es la posibilidad de agregar extensiones
de terceros o external appplications, es decir, PT5.1 publica un API para interactuar con él,
de tal manera que si alguien quiere desarrollar una aplicación que use capacidades de PT
puede hacerlo e instalarla como una extensión habilitable, dando nuevas funcionalidades al
PT.
Como de costumbre con Cisco, éste es un asunto delicado. Packet Tracer, como ya lo he
dicho, está estrechamente vinculado con las academias de networking y aunque ese es su
único fin, tiene una licencia de uso que dice que sólo se puede usar para eso y por
estudiantes alguna vez matriculados en alguna academia reconocida. El PT se puede
descargar gratuitamente del mismo Academy Connection, es decir, si usted es instructor,
estudiante o alumno (fue estudiante y creó un perfil como alumni, es decir, graduado de
algún curso) en una academia de networking, al lado izquierdo de su página de bienvenida
después de ingresar su nombre de usuario y contraseña, estará un ícono para descargar la
última versión. Si existen dos alternativas para descarga, una es con tutorial y la otra sin el
tutorial. El tutorial es grande pero muy útil, son pequeños videos donde se muestra cómo
usar cada utilidad del programa. He visto por ahí otras alternativas para descarga pero no
son recomendables, uno nunca sabe con qué se va a topar por ahí.
¿Cómo usar Packet Tracer?
II Fundamentos
Siguiendo con la serie de entradas sobre Packet Tracer, en esta entrada describiré lo más
básico que se puede hacer con PT: Crear una topología, conocer los espacios de trabajo (en
poco detalle) y usar la interfaz gráfica de configuración. Disfrútenla.
Modos de operación
El PT opera en modo de tiempo real y simulación, siendo tiempo real el que
se muestra inicialmente. Tiempo real significa que los eventos se simulan
exactamente como los ejecutarían los dispositivos reales, es decir, si se
envía un paquete de un dispositivo a otro eso sucede en milisegundos y lo
único que nosotros observamos en el espacio lógico es el piloto (punto
verde) del enlace titilar. En éste modo de operación las cosas suceden casi inmediatamente y
podemos hacer pruebas en tiempo real como lo haríamos con equipos reales.
Una de las pruebas de conectividad básicas consiste en agregar una PDU simple, que en la
interfaz se ve como un sobre con un signo de más ( + ) a un costado. Esta PDU es
equivalente a un paquete único de Ping que toma como direcciones origen las del primer
dispositivo al que se le da clic y direcciones destino las del segundo dispositivo al que se da
clic. Una vez que señalamos el destino de la PDU el paquete se dispara inmediatamente en
tiempo real y en el panel de Escenarios aparece una línea indicando lo que le pasa a esa
PDU y ofreciéndonos algunas opciones para manipularla. Por ejemplo, cuando soltamos la
PDU, si hay redes ethernet/fastethernet involucradas el paquete suele fallar (Failed), para
repetirlo sólo hay que dar doble clic en el “botón” rojo al inicio de la línea. En esta misma
línea, al final y usualmente fuera de la pantalla (hay que mover la barra de desplazamiento
horizontal del panel) se puede dar doble clic a Edit y cambiar parámetros del paquete, por
ejemplo decirle que se repita cada X segundos y cambiar los parámetros de origen, lo cual
cuando se trabaja con enrutadores -que tienen múltiples interfaces, redes y direcciones
diferentes en cada una- puede resultar muy útil. También podemos cambiar a qué aplicación
pertenece el paquete, pero eso puede ser complicado si no conocemos los detalles de la
aplicación, eso lo exploraremos en los tópicos avanzados. Finalmente el último elemento de
la línea que identifica una PDU es Borrar (delete), con lo que se elimina la PDU del listado y
del espacio de trabajo.
Si alguien se pregunta para qué sirve entonces el botón Delete y a qué se refiere el botón
New, pues es a los escenarios, en pocas palabras conjuntos de paquetes que se envían por
la topología. De éste tema hablaremos en futuras entregas pero los invito a que exploren
esta función con lo que ya saben.
El modo de simulación es un modo especial en el que se pude observar cómo viajan los
paquetes entre los dispositivos. Éste modo permite ver a un alto nivel de detalle lo que pasa
en la red y controlar el nivel de detalle que se desea ver, por ejemplo, en una red ordinaria
hay muchos protocolos que usan automáticamente los dispositivos para comunicarse
información de control, y cada uno genera flujos de paquetes, por lo que con frecuencia es
muy importante permitir que sólo los protocolos de interés se vean en una simulación.
Obviamente también es importante controlar la velocidad a la que suceden los eventos de la
red. El modo de simulación lo exploraremos en detalle en una próxima entrada.
Modo de simulación
En la anterior publicación vimos cómo seleccionar el modo (tiempo real y simulación) y cómo
construir una topología básica. En el modo de tiempo real podemos ver los eventos a la
velocidad a la que usualmente ocurren en el mundo real, por ejemplo, si enviamos un ping
exitosamente, vemos el resultado inmediatamente incluso perdemos el primero como pasa
en la vida real (eso no es fortuito, existe una razón). En el modo de simulación, la intención
es ver al mayor detalle posible cómo se desarrolla una transferencia de datos. Se ven
los paquetes pasar por cada nodo de la red, se listan esos eventos y en cada uno de ellos se
puede ver qué transformaciones sufre el paquete y qué desiciones toman los dispositivos en
cada capa del modelo OSI, incluso es posible ver de manera simbólica los encabezados de
los protocolos en uso.
Cuando pasamos al modo de simulación, aparece una ventana adicional llamada lista de
eventos (event list), en ella podemos ver cada paso de todo el proceso de comunicación de
nodo a nodo. Cada línea de la lista de eventos es un paso de un paquete por un nodo de la
red. Cuando se dispara algún tráfico en la topología, digamos un ping, el paquete aparece en
la topología como un sobre y en la lista de eventos aparece una línea que termina en un
cuadrado del mismo color que el sobre. Cada vez que oprimimos capture/forward
(capturar/enviar) el paquete se mueve de un punto a otro según lo que le suceda en el nodo
en el que está cuando oprimimos el botón. El modo de simulación por defecto muestra
todos los protocolos que él puede simular, para evitar que empiecen a salir paquetes sin
que los hayamos puesto nosotros, debemos filtrar el tráfico de interés y dejar sólo el
necesario, por ejemplo ICMP que es el protocolo que transporta los pings.
La simulación puede correr paso a paso o automáticamente, cuando usamos
capture/forward nosotros controlamos la simulación, cuando oprimimos auto capture/play
la simulación se ejecuta automáticamente y nosotros la podemos detener volviendo a oprimir
auto capture/play. La velocidad con la que suceden los eventos en el modo de simulación se
controla con el indicador que hay justo debajo de los botones de control (back, auto
capture/play, capture/forward). Si quiere cambiar la topología, debe hacerlo en modo de
tiempo real.
La gran utilidad de este modo no sólo es ver cómo se mueven los paquetes por la topología,
el cuadrado de colores y el sobre que se mueve por la topología son las dos formas de
acceder a los detalles de recepción y envío de paquetes en un nodo en particular. Si
observan las columnas de la lista de eventos, verán que cada línea indica un nodo y una
dirección de tránsito del paquete (at device, last device). Cuando oprimimos clic en el
cuadrado de color o en el sobre, podemos ver los procesos y decisiones que se hicieron
sobre el paquete al entrar y al salir del nodo en particular. Para cada capa del modelo
OSI hay una descripción de esos procesos, por ejemplo, si el dispositivo es un enrutador,
éste desencapsula el paquete en capa 2 y lo compara con su tabla de direcciones de capa 2,
si el paquete coincide con su dirección de capa 2 lo desencapsula y lo pasa a la siguiente
capa, en capa 3 lo compara con su tabla de enrutamiento y si encuentra una salida lo pasa al
proceso de capa 3 de salida y así sucesivamente. Todo lo que acabo de describir, incluso con
más detalle, se describe al dar clic en cada capa. Cuando un paquete falla por alguna razón,
ésta se puede buscar en la descripción detallada en el nodo en que falló y en la última capa
que tenga descripción.
Adicional al detalle de los procesos de un paquete en un nodo de la red, hay una o dos
pestañas adicionales que permiten ver encabezados de los protocolos en uso en el paquete.
Práctica
Para ilustrar lo escrito vamos a observar lo que le pasa a una PDU simple (paquete ICMP de
echo -ping) en tránsito de ida y vuelta en los nodos de una red muy simple. Tenemos un PC y
un servidor conectados a través de dos enrutadores y un switch. Pondremos una PDU simple
del PC al servidor y veremos lo que se puede hacer en el modo de simulación.
Lo que observamos en el video es una topología completa, ya configurada para que haya
conectividad completa. Exploramos la interfaz en tiempo real, pasamos a simulación,
ponemos en marcha la simulación automáticamente y aceleramos su velocidad, la dejamos
correr. Cuando el paquete llega al enrutador, lo pausamos, vemos los detalles en cada capa
del modelo OSI, luego los vemos en el switch y dejamos continuar la simulación. Al final se
ve cómo la simulación empieza a generar una serie de paquetes adicionales que nosotros no
disparamos y ahí termina el video.
¿Cómo usar Packet Tracer?
IV Trucos básicos
Dentro de la serie de entradas sobre Packet Tracer, ésta es como una especie de descanso.
Basándome en lo que he escrito en las entradas anteriores, voy a comentar algunos trucos
para hacer el uso del área de trabajo en modo de tiempo real y de simulación un poco más
útil. Disfrútenlo.
Antes de cualquier cosa y porque es un truco muy básico que no requiere mayor explicación,
en el modo de tiempo real podemos crear copias de un dispositivo ya ubicado en la
topología: dando clic en él con la tecla Control oprimida. La copia es exacta y si antes
modificamos el hardware del dispositivo original nos evitamos tanto dar clic en el panel de
dispositivos como modificar el hardware en el nuevo dispositivo.
En nuestra segunda entrada de la serie, exploramos la interfaz básica en modo de tiempo
real, en ella veíamos cómo crear topologías, configurarlas sin tener que conocer de
comandos y probarlas poniendo a correr unidades de datos de protocolo o PDU por sus
siglas en inglés (Packet Data Unit).
Las PDU simples que uno pone en una topología en tiempo real son por defecto un
paquete de un protocolo llamado ICMP que complementa las capacidades de IP. Como IP
no envía notificaciones cuando suceden errores (y por ciertas necesidades de diseño no lo
debe hacer) es necesario tener éste segundo protocolo de capa 3, ICMP, que envía un
conjunto de notificaciones y mensajes de control. ICMP es una sigla que significa Protocolo
de Mensajería de Control de Internet (Internet Control Messaging Protocol).
Para poner a correr una PDU por la topología, usamos el sobre con un signo más encima,
eso cambia el puntero por un sobre gris que desaparece cuando damos clic en dos
dispositivos de la topología: el origen y el destino de la PDU. En ese momento, PT obtiene
una dirección IP origen y destino y dispara en el origen los procesos necesarios para
encapsular un dato de ese tipo. Por defecto, en el panel de escenarios aparece una línea
(una por cada PDU que haya en ese momento en la topología), la primer columna indica si la
PDU llegó o no (succesful/fail), si este panel y esta línea no aparecen hay dos posibles
razones: el panel está oculto (botón Toggle PDU list window) o la PDU no se sembró
correctamente (no se dió clic a los dispositivos origen y destino), un indicador del último error
es que el puntero del ratón siga siendo un sobre.
El primer truco sobre las PDU simples consiste en reenviar la PDU sin necesidad de volver
a usar el sobre, eso significa evitar 3 clics distribuidos por toda la pantalla. En el panel de
escenarios hay una lista de PDUs definidas con todos sus parámetros (protocolo, ip origen e
ip destino, entre otros) y para reenviarlas sólo debemos dar clic en el botón rojo al inicio de
cada línea. Usualmente hay una parte del panel que no se ve porque está fuera de la
pantalla, hay que usar la barra de desplazamiento para ver las últimas dos columnas:
edit y delete, entre paréntesis ambas. Editar permite modificar directamente la PDU, así que
podemos experimentar para ver qué sucede si un PC cambiara ciertas partes de un paquete
arbitrariamente, cómo reaccionarían los PCs o los nodos en el camino. La única desventaja
es que tenemos que conocer un poco sobre todos los protocolos que se pueden usar y sus
respectivos parámetros (c/u tiene parámetros diferentes), pero eso no nos previene de
experimentar: igual no dañaríamos nada haciéndolo. Un buen truco consiste en establecer
que la PDU sea períodica y decirle cuántas veces se puede repetir la PDU, eso en ping es
equivalente a la opción -n del ping de línea de comandos o /repeat en la CLI de un enrutador
o switch. Cuando damos doble clic a la columna edit, en la casilla de protocolo vemos PING,
con lo que verificamos lo que les he venido diciendo. Los parámetros modificables en ésta
pantalla son como para una entrada completa sobre el funcionamiento detallado de IP y
algunos protocolos que se encapsulan o transportan sobre IP. Finalmente, la última columna
nos permite eliminar una PDU en particular sin borrarlas todas como lo hace el botón
delete.
Escenarios
Ya hemos hablado mucho del panel de escenarios, pero ¿por qué se llama escenarios?. La
razón es muy simple, en la medida que ponemos PDUs en la topología se van acumulando
en el panel y cada conjunto de PDUs pueden tener un significado, eso es un escenario.
Por ejemplo, antes de que el enrutamiento entre redes diferentes funcione, debe existir
conectividad de punto a punto, es decir, todos los nodos deben poder hacer ping
exitosamente a sus puertas de enlace (gateways) y en cada enlace los enrutadores se deben
poder hacer ping entre sí. Aunque se cumpla la condición anterior, la conectividad de capa 3
entre redes separadas por enrutadores puede no ser posible -o no debería-, porque los
enrutadores no tienen rutas en su tabla de enrutamiento. Por lo tanto, hablando de PDUs
para hacer pruebas, una prueba puede consistir en comprobar la conectividad punto a punto,
antes de configurar el enrutamiento, si en ésta prueba alguna PDU falla no se puede
continuar a la configuración del enrutamiento; una segunda prueba con PDUs consistiría en
probar la conectividad de extremo a extremo contando con enrutamiento completamente
funcional. Las dos pruebas que acabo de describir son dos escenarios: un conjunto de
paquetes para probar la conectividad de punto a punto y otro conjunto de paquetes para
probar la conectividad de extremo a extremo, si creamos éstos dos escenarios y en cada uno
ponemos las PDUs para comprobar las condiciones descritas, al seleccionar el escenario
se dispararán todas las PDUs del mismo. Este es sólo un ejemplo, pero un escenario es
más útil para demostrar el funcionamiento de las ACLs, por ejemplo.
Para terminar, miremos un poco más a fondo el modo de simulación. Cuando ponemos una
PDU simple en la topología y pasamos a modo de simulación, aparece automáticamente la
ventana de lista de eventos con un primer paquete en ella. Podemos cerrar la lista de
eventos sin salir del modo de simulación usando la x en la esquina superior derecha como
con cualquier otra ventana, pero ¿cómo volverla a mostrar?, existe un señalizador justo
debajo de la lista de eventos e inmediatamente al lado de la etiqueta Simulation llamado
Event list. Ese “botón” es el que oculta o muestra la ventana de simulación. En esta misma
barra vemos los mismos controles que en la lista de eventos (back, autocapture/play y
capture/forward), que nos permiten correr la simulación sin la lista de eventos. Ésto puede
ser útil si la topología es grande y la lista no la deja ver completamente, además el acceso a
los procesos de entrada/salida de cada paquete y los encabezados siguen siendo accesibles
através de los sobres que vemos pasar de nodo a nodo por la topología. El último indicador
en ésta barra es Power Cycle Devices, muy útil y también está disponible en el modo de
tiempo real: reiniciar los equipos. Cuando usamos el botón de reiniciar los dispositivos hay
que tener en cuenta que si las configuraciones no se han guardado a la flash en los
enrutadores/switches esas configuraciones desaparecerán cuando los dispositivos
arranquen.
Si corremos la simulación, vemos el paquete pasar de nodo a nodo por la topología y para
cada nodo una línea en la lista de eventos. Ya habíamos dicho que éstas líneas nos dan
acceso a la descripción de los procesos de entrada y de salida en un nodo particular
señalando el cuadrado de colores para un paquete en particular y que esa misma
información la obtenemos dando clic en el sobre que aparece en la topología. Un problema
que sucede con frecuencia a los principiantes, es que de un momento a otro la topología se
llena de paquetes que el usuario no generó, eso refleja la naturaleza caótica de la red y
simula de manera realista su funcionamiento: en una red de datos están ejecutándose
muchos procesos que requieren comunicación y que generan paquetes según sea necesario,
por períodos o disparados por eventos. Para evitar confusiones, la lista de eventos tiene un
botón Edit filters, que le dice a PT qué tipos de paquetes mostrar, eso no significa que los
paquetes dejen de enviarse (son necesarios para que la red funcione) sino que no harán
parte de la lista de eventos ni generarán sobres en la topología. Para editar los filtros, es
necesario conocer la forma en que interactúan los protocolos y tener en cuenta qué es lo que
queremos ver de la simulación.
¿Cómo usar Packet Tracer?
V Extensión multiusuario
La extensión multiusuario de Packet Tracer es una utilidad que permite conectarse desde
varios computadores en red a un mismo laboratorio/topología. Se pueden hacer muchas
cosas con ésta extensión y en los párrafos que siguen, espero ilustrar un poco los
aspectos más importantes, dar algún ejemplo de uso y dejar un video. Disfrútenlo.
Como es evidente a partir del título de esta entrada, ésta es la 5a en la serie de ¿cómo usar
Packet Tracer?. En esta ocasión vamos a explorar la extensión multiusuario, una de las
características avanzadas y emocionantes que encontramos en las últimas versiones de esta
excelente herramienta. Con ésta extensión se pueden abordar laboratorios de gran
complejidad y distribuir el trabajo en varios usuarios.
Primero definamos qué es una extensión. Desde la versión 5.1 de PT, se pueden hacer
extensiones del programa para adicionarle comportamientos personalizados al mismo. Una
de ellas es la extensión multiusuario. Éstas extensiones son como los plug-ins.
Infortunadamente y a pesar de la potencia de ésta idea, no hay mucha documentación
pública sobre ésto.
Ya hablando de la extensión multiusuario, ésta define una forma de conectar laboratorios de
PT que se ejecutan en PCs diferentes conectados por la red, es decir, si dos (o más)
estudiantes deben hacer un laboratorio demasiado complejo para que uno solo lo termine,
pueden conectar dos PCs y abrir simultáneamente el mismo laboratorio (aunque no
exactamente) y trabajar juntos en ello.
Con ésta extensión y las capacidades avanzadas de PT, se amplía muchísimo lo que
podemos hacer con este programa, de hecho, casi podríamos decir que un curso de CCNA
se podría abordar exclusivamente con el PT, ya que sólo hay unos pocos comandos que no
soporta, pero lo básico y casi toda la práctica que se necesita saber para pasar el examen de
certificación se puede hacer usando intensivamente el PT. Los instructores tenemos a
disposición algunos laboratorios avanzados especialmente diseñados para trabajo con PT y
en especial para la extensión multiusuario.
Esta utilidad abre un puerto TCP y usa un protocolo especial que encapsula el tráfico
virtual generado por los dispositivos de un PT en uno de los PCs involucrados y lo
envía por la red al PT del otro u otros Pcs.
Como se deduce de lo que he escrito, es necesario que los PCs en los que se va a
trabajar PT multisusuario tengan conectividad hasta la capa 4, es decir, los PCs se
deben poder hacer ping mutuamente y no estar detrás de algún firewall (que puede ser el
del propio Windows) que bloquee estos puertos nuevos en alguno de los PCs donde se
ejecuta la extensión. Esta utilidad funciona sólo desde la versión 5.1 en adelante, entonces,
si usted tiene una versión anterior es mejor que descargue la última.
Por lo pronto vamos a suponer que los PCs en los que se va a trabajar están en una red
LAN, es decir, que no pasan por Internet. La razón es que a veces los proveedores de
servicio dan a nuestros PCs direcciones IP privadas y de esa manera no es posible mandar
la conexión de un PC a otro. Sólo digamos que es un poco más difícil. Si quiere intentar usar
ésta función a través de Internet, verifique que su dirección IP no pertenece a ninguno de
estos rangos: 10.X.X.X, 172.16.X.X a 172.31.X.X o 192.168.0.X a 192.168.255.X. Consulte
esta entrada anterior para saber más de las direcciones privadas.
Ahora prepárese para usar la extensión multiusuario: tome nota de las direcciones IP de
los PCs involucrados y haga ping entre ellos. El ping debe resultar exitoso.
¿Cómo usarla?
Ésta ya es una tarea un poco más avanzada, existen muchas razones por las que puede
fallar la conexión por Internet. Lo primero es un posible bloqueo de puertos en el ISP y lo
segundo es que los puertos hacia internet no sean los mismos puertos si tenemos IP
privadas. Si las direcciones de nuestros PCs son direcciones públicas, podemos intentar lo
mismo que hicimos para conectar los PCs directamente: en un PC creamos la topología
normalmente y en otro creamos la topología, instalamos una nube multiusuario y la
configuramos con la dir. IP del PC remoto. Una vez que hacemos ésto y la contraseña sea la
misma a ambos lados, en el PC remoto saldrá la ventana de autorización y la conexión se
establecerá.
Para saber si las direcciones de nuestros PCs son públicas o privadas, consultamos la
dirección de nuestro controlador de red, use una de las siguientes formas de averiguarlo:
• Ejecutar (run) –> cmd –> ipconfig
• Doble clic en el ícono de la red, clic a la pestaña soporte
Las direcciones privadas son las que comienzan con 10, o con 172.16, 172.17 hasta la
<!--
goog
le_a
d_cli
ent =
"pub
172.31 y las que comienzan con 192.168.0 hasta 192.168.255 (sin importar los últimos
-
2017
2756
7334
7428
";
pública con la que salimos a internet por algún sitio web como whatismyIP.com o
do
20/0
9/08
*/
goog
le_a
funcionó y tocó intentar con una VPN usando una aplicación muy conocida llamada
goog
le_a
d_wi
dth
=
300;
podría hacer una entrada en el futuro sobre su uso. Por lo pronto, intentenlo sin ayuda y si
//
-->g
oogl
e_pr
otect
And
Yo creo haber visto alguna vez un video en el que los dispositivos se tomaban directamente
del panel de dispositivos en la parte de dispositivos personalizados y ahora sé por qué. Los
enrutadores y switches que encontramos normalmente en el panel, tienen sólo las interfaces
con que vienen originalmente, es decir, si un enrutador de la serie 1800 se agrega al espacio
de trabajo pero hay que usarlo con una interfaz serial hay que agregarla manualmente. A
estas alturas sabemos que, sin leer mis entradas o sin alguien que nos indique qué hacer, no
comprendemos fácilmente que el dispositivo hay que apagarlo antes de agregarle hardware y
más difícil la tendremos para saber de dónde lo apagamos. Todo este proceso es muy bueno
para evidenciar lo realista que puede ser el PT, pero después de hacer muchas prácticas se
nos va volviendo aburridor tener que agregar siempre las interfaces que necesitamos.
Los dispositivos personalizados son aquellos que tienen las interfaces necesarias para
alguna prueba particular y podemos guardarlos para que queden disponibles cuando
lo necesitemos en el futuro si lo vamos a seguir usando con frecuencia. Por ejemplo,
cuando sacamos un enrutador 2800 del panel de enrutadores, sólo tiene 2 interfaces
fastethernet, la consola y la línea auxiliar. Si sacamos un 2800 del panel de dispositivos
personalizados, éste tiene un módulo lleno (16) de interfaces fastethernet que funcionan y se
configuran como un switch, además tiene cuatro interfaces seriales en dos módulos
separados (¡además tiene tapitas en las bahías -slots- vacías! ).
VII: Nubes
Bueno hace rato que estoy en deuda con terminar la serie sobre Packet Tracer y muchos
lectores me han preguntado sobre las nubes. Pues en la última entrada sobre PT, dije que
dentro de los tópicos avanzados estaban las nubes y es que las nubes permiten simular
cosas como una red Frame Relay y mucho más. Así que acá les va una entrada sobre nubes
en Packet Tracer 5.1 con video incluido. Disfrútenlo.
Introducción
Antes de comenzar, recuerde que ésta es una entrada de la serie ¿cómo usar packet tracer?,
donde hemos explorado desde lo que se puede hacer con el programa hasta cómo trabajar
desde dos PCs en la misma simulación usando la red. Si es la primera vez que viene a este
blog, le recomiendo que hecho un vistazo a las entradas anteriores para que se contextualice
y a ver si de pronto encuentra algo interesante. Varias de las entradas anteriores tienen un
video que ilustra lo escrito o un ejemplo descrito en la entrada.
Ahora sí, un concepto muy importante en el trabajo con redes es la abstracción y el
simbolismo, en otras palabras, tratar con un ícono un conjunto de propiedades o
tecnologías que pueden tener una gran complejidad. Así como no sabemos exactamente
la arquitectura de un Switch o un Enrutator, pero aún así capturamos en su ícono lo mínimo
que necesitamos saber para configurarlo y ententer cómo se conecta con otros dispositivos,
así mismo usaremos las nubes. Las nubes simbolizan toda una red que no está
necesariamente bajo nuestro control, por ejemplo la red del proveedor de servicio (ISP),
sin embargo, tendrá lo mínimo que necesitamos para conectarnos a ella.
Las nubes en PT son una abstracción general, es decir, significa cualquier tecnología
adicional que no sea ethernet o serial y que esté compuesta por otras tecnologías. Como una
nube representa una tecnología particular que permite transferir información de una conexión
a otra, necesita por lo menos la información de cómo conmutar la información de una interfaz
a la otra, en el caso real, los ingenieros establecen los circuitos virtuales permanentes que se
aseguran de que el tráfico que entra en una interfaz de la empresa, recorra correctamente la
red y salga por otra interfaz con que se atiende al mismo cliente en otra ciudad o en otro
lugar de la misma ciudad. Para nosotros en Packet Tracer significa establecer un mapeado
único de interfaz de entrada contra interfaz de salida simplemente, que es lo que tendremos
que saber como ingenieros en una empresa.
Tecnologías
Las nubes como ya dije, pueden representar varias tecnologías, la que más se usa en CCNA
es Frame Relay, entre otras cosas porque sigue vigente y, comercialmente, sigue siendo muy
usada. Frame Relay se ve en el módulo de Conexión con la Wan (4º semestre de CCNA)
entre otras tecnologías. Otra tecnología puede ser una red de banda ancha, tipo xDSL o
CableModem o incluso un acceso telefónico, todos son casos de conexión con la Wan y se
ven en ese semestre. El primer requisito para conectarnos con cualquiera de las
tecnologías es tener interfaces apropiadas, es decir, que un enrutador tenga una interfaz
telefónica para poder acceder a un acceso conmutado telefónico (modem), usualmente es el
PC el que debe tener un modem. Otro ejemplo, más real, es que el enrutador tenga
interfaces coaxiales para DOCSIS (CableModem) o interfaces telefónicas para xDSL, los
enrutadores de la serie 800 y 1800 pueden venir con éste tipo de interfaces. Otro caso,
incluso más común, es un dispositivo adicional que se conecte con el enrutador por interfaz
ethernet/fastethernet, por ejemplo un cablemodem que se conecte a la red DOCSIS por
coaxial y al enrutador por fastethernet como lo hacemos con nuestros PCs.
Aunque cada tecnología tiene sus características técnicas detalladas, como lo que hay que
configurar cuando se usa PPPoE en una interfaz tipo DSL o CableModem (se configuran
cosas distintas), en PT y en especial en CCNA no hay que lidiar con eso. Las interfaces FR
pueden conectar directamente enrutador con enrutador, pero las interfaces DSL o
Cablemodem sólo se pueden corresponder con interfaces ethernet, de hecho, la
configuración de las interfaces ethernet en una nube es a qué red atiende: DSL o
Cablemodem.
Ejemplo
Ya teniendo una idea de lo que estamos haciendo, vamos a ver un ejemplo práctico.
Tenemos dos enrutadores en lugares distintos, digamos en los extremos de su ciudad, el
proveedor de servicio nos brinda la oportunidad de conectarlos por su red privada Frame
Relay. Para simular el caso ubicaremos dos enrutadores y una nube genérica (Cloud-PT),
ésta por defecto tiene todo tipo de interfaces. Lo más común (y lo que se aprende en CCNA)
es FR que en realidad es muy simple. En FR un DLCI es un indentificador de capa dos que
se corresponde con un camino hacia otro enrutador por la red FR, en otras palabras, un DLCI
es un identificador de PVC (Permanent Virtual Circuit o Circuito virtual permanente). Los
DLCI son los equivalentes FR a la MAC de ethernet, tienen el mismo uso y significado, es
decir, finalmente cada DLCI termina correspodiendose con una dir. IP, así como las MAC se
corresponden con dir. IP a través de ARP en ethernet. Entonces lo que necesito de una red
FR es que diga a qué DLCI de salida debe llegar el tráfico que entra por otro DLCI en alguna
interfaz. Es así de simple. A continuación un video que ilustra el uso de la nube genérica
configurando Frame Relay, luego de eso una explicación de los pasos que se siguen.
FR es una tecnología muy simple, diseñada como tal para ser simple como se ha visto en el
video, sin embargo, no se confíen, FR tiene muchos conceptos importantes de operación y
términos específicos como el CIR, CB, conexión punto a punto o punto a multipunto, tipo de
encapsulación, tipo de LMI y muchas otras cosas que tienen un impacto directo en la
posibilidad de uso de ésta tecnología como alternativa de conexión a la WAN. Por ejemplo,
en el video con sólo configurar la encapsulación y levantar la interfaz, la conectividad de capa
3 se hace efectiva, pero para que eso suceda existen varias precondiciones, el uso del
mismo tipo de encapsulación, el mismo tipo de LMI y que el enrutador y la red de proveedor
soporte iARP o inverse ARP que es finalmente el que consigue la IP que se corresponde con
el DLCI, si éste último paso no se da, tenemos que ejecutar el comando frame-relay map ip
10.0.0.2 100.
Lo que sucede es que la operación de FR es simple, pero hay que comprender el resto del
contexto para poder efectuar un diagnóstico y solución de problemas efectivo y rápido. Lo
que hice en el video fue configurar dos enrutadores con interfaces en una nube FR, la
conexión entre ellos constituye una red aparte (10.0.0.0/8), cada uno con una dir. IP única en
ella, la encapsulación se establece como Frame Relay. En la nube se publican los DLCIs
correspondientes a cada lado de la conexión, en la interfaz serial 0/0 de la nube se publica el
DLCI 100 con nombre A y en la interfaz serial 0/1 se publica el DLCI 200 de nombre B, éstos
dos números son las direcciones de Capa 2 de los enrutadores del otro lado, es decir, para
enviar paquetes al enrutador de la derecha desde el de la izquierda se usa el DLCI 100 en la
capa 2 y la IP 10.0.0.2 en la capa 3. En la nube FR se debe crear el circuito, es decir, que lo
que entre por el DLCI 100 de serial 0/0 salga por el DLCI 200 de serial 0/1 y viceversa, eso
es lo que se hace en configuración de Frame Relay.
¿Cómo usar Packet Tracer?
VIII Actividades
No es que tenga mucho tiempo libre, pero no puedo abandonar a éste hijito que es el blog.
Por fin vuelvo a escribir una entrada más sobre PT y ahora espero responder la pregunta
¿cómo se hacen laboratorios autocalificables en PT?, en otras palabras ¿cómo crear
actividades? Disfrútenlo.
Introducción
A estas alturas, casi que sobra decir que ésta es una entrada de la serie ¿cómo usar Packet
Tracer?, en la que hemos visto desde las características generales hasta la creación de
escenarios, clusters y el uso básico de las nubes. Ahora vamos a explorar, de manera básica,
la utilidad que viene con éste interesante programa para crear laboratorios guiados
autocalificables, que en PT se llaman Actividades. Es importante resaltar que digo básico
porque la herramienta en cuestión es sofisticada, por ejemplo permite calificar el uso de
textos específicos en alguna parte de una configuración, uso de grupos de direcciones IP e
incluso uso de números arbitrarios. En esta entrada sólo veremos cómo crear un
laboratorio básico con instrucciones y calificación automática de las configuraciones.
Para aprovechar mejor esta publicación, es recomendable entender un poco la interfaz de
PT y un conocimiento básico de redes, es decir, esta entrada está escrita como para
estudiantes de segundo semestre de CCNA en adelante o un nivel equivalente de
conocimiento en redes de datos y será especialmente útil para los instructores de Cisco.
Por favor dosifiquen esta entrada, porque cada vez me resulta más difícil escribir con éste
nivel de detalle (se requiere mucho tiempo), además que la publicación me salió un poco
más larga que de costumbre (me desahogué de lo que no había escrito todos estos días).
Vale la pena también resaltar, que la versión 5.2 (actualmente en Beta) soportará comandos
que incluso se practican en el currículo de CCNP, por lo que a PT todavía le falta mucho
potencial por explotar y a quienes nos gusta este tema debemos estar pendientes de los
desarrollos con él.
Laboratorios prediseñados
El currículo de CCNA en su versión 4, tiene como novedad un uso intensivo de PT, de hecho,
cada vez que se termina de exponer un tema en un módulo particular, lo sigue un laboratorio
guiado con instrucciones paso a paso. Lo anterior implica que existe una herramienta que
permite visualizar y practicar la teoría recién vista, pero con ayuda completa por parte del
programa a través de sus instrucciones, al final de un módulo se deberían haber hecho por lo
menos 3 laboratorios de éstos. Todos los módulos tienen también uno o varios desafíos o
pruebas finales en las que se hace un laboratorio muy completo que revisa el tema de todo
un módulo pero sin la guía específica de los laboratorios entre temas, es decir, sólo indica los
objetivos pero no cómo configurar lo que se necesita.
La gracia de todos éstos laboratorios, es que en la medida que se van desarrollando, las
instrucciones indican un porcentaje después de ejecutar ciertas tareas, por ejemplo
configurar un PC. Cada tarea bien hecha aumenta el porcentaje hasta que al final el
estudiante tiene certeza (sin asistencia de nadie) que terminó correctamente el laboratorio,
es decir que hizo el 100% de lo esperado. Sin embargo, valga la aclaración que éstas
actividades guiadas a veces tienen errores en sus intrucciones, por ejemplo, con
frecuencia el nombre de algo en la configuración está en inglés y el laboratorio lo indica en
español o a veces hay equivocaciones en direcciones o interfaces que a los estudiantes les
resulta un poco difícil de encontrar.
Elementos de un laboratorio
Vamos entonces al ejemplo. He creado una topología inicial con dos enrutadores conectados
por cables seriales y dos PC conectados por cables cruzados a cada uno de sus enrutadores
que harán de puerta de enlace. En los enrutadores he configurado RIP y he guardado esta
topología con el nombre inicial. Noten que yo pude haber terminado la configuración y
tomarla como configuración final, pero ésto significaría que las instrucciones deben prever la
creación de la red completamente porque no habría topología inicial. En el ejemplo que doy,
guardo una topología completa con una parte preconfigurada (el enrutamiento) para que los
estudiantes no tengan que crearla desde cero. A continuación configuro los PCs, los enlaces
entre todos los dispositivos (esos serían los puntos a evaluar, la configuración de los enlaces:
diferencia entre topología inicial y final) y guardo el archivo como final (sólo por
precaución), luego abro el asistente y digo sí a la pregunta de si quiero usar la topología
actual como red de respuesta.
El Activity Wizard tiene los siguientes pasos:
1. Bienvenida
2. Administrador de Variables
3. Instrucciones
4. Red de respuesta
5. Red inicial
6. Contraseña
7. Probar la actividad
8. Validar la actividad
9. Guardar
10.Salir
Instrucciones
Las bienvenida es una pequeña descripción de la herramienta, recuerde que no voy a
explicar el uso de variables, por lo que vamos a pasar de una vez a las instrucciones. En
ellas vamos a crear un conjunto de páginas web que el estudiante va a leer como
instrucciones de su actividad, en éstas se pueden incluir variables, pero por lo pronto
serán sólo textos que indiquen qué hay que hacer y, si queremos, dividimos estas
instrucciones en varias páginas a manera de pasos. Cuando el estudiante abra el laboratorio,
lo que quedará frente a él serán éstas instrucciones. Como nota al margen: cuando termine
las instrucciones vuelva a la primera página, de lo contrario la actividad va a iniciar
mostrando la última página de las instrucciones.
Red de respuesta
En la red de respuesta configuramos la evaluación a partir de lo que contiene la red de
respuesta, es decir, el área de trabajo contiene un árbol que lista jerárquicamente los
dispositivos y sus partes, por ejemplo la raíz, llamada Network, lista PC0, PC1, Router0 y
Router1, si abrimos PC0 encontramos los elementos calificables de éste, por ejemplo la
puerta de enlace y sus puertos, si abrimos sus puertos encontramos fastethernet y si lo
abrimos encontramos todos los parámetros del puerto fasethernet de PC0, por ejemplo la
dirección IP o el enlace con el enrutador (dónde se conecta en el enrutador). En fin, mucho
detalle, todo dependerá de qué tan exacta queramos que quede la respuesta del estudiante
respecto a la nuestra. Cada línea de ésta tabla jerárquica, tiene una caja de chequeo, que
indica si se tendrá en cuenta en la calificación si la activamos o no, en seguida del nombre
del elemento hay una columna de 1, éste es el peso relativo del elemento respecto a la
calificación general, es decir, si activamos 10 elementos cada uno valdrá 10%, pero si
activamos 6 elementos de los cuales el primero vale 5, éste valdrá 50%. Por ejemplo, si nos
parece que es más importante que quede bien configurada la puerta de enlace que la
máscara podríamos poner 5 a la configuración de la primera y dejar en 1 (por defecto) la
segunda. Estos pesos son calculados automáticamente, de tal manera que la suma de todos
los puntos es el 100% y los puntos de cada elemento sobre el total dará el % de éste. Luego
del peso está el indicador (cómo aparece listado el elemento en la evaluación) y enseguida
un texto de ayuda en caso de equivocación. Para cambiar cualquiera de éstos elementos es
indispensable dar enter al finalizar cada cambio.
Podemos iniciar el asistente sin necesidad de haber abierto la topología final siempre y
cuando la hayamos guardado previamente el archivo final (como lo hice en el ejemplo). Ya
sabemos entonces para qué los botones import arriba en la pantalla de red de respuesta. Las
pestañas adicionales permiten modificar otros parámetros de operación como las pruebas de
conectividad, el mensaje de terminación del laboratorio y la forma de contar el tiempo (sólo
contarlo o que sirva de tiempo límite).
Red inicial
En este pantallazo vemos lo que se puede bloquear en la operación de la red desde el inicio
en un esquema similar al de la red de respuesta: una jerarquía de elementos. Una cosa
importante es recordar que si no importamos una red inicial el laboratorio comenzará
con un área de trabajo vacía y las instrucciones deberían empezar por describir qué
topología se debe componer. Yo prefiero dejar los elementos en la topología inicial e indicar
qué quiero que configuren.
Cuando se ha importado una topología inicial, se puede indicar que cosas de la interfaz se
va a impedir usar, por ejemplo, a mí me gusta que los estudiantes usen la CLI, por lo que yo
siempre abro el elemento de topología y en él global y allí habilito Use Config Tab, una vez
hecho eso la pestaña de configuración de cualquier dispositivo de la topología estará
bloqueado y la única opción para un estudiante será usar la CLI en todos los dispositivos.
Ésto tiene una desventaja: para poder encender las interfaces de los PCs y configurar los
servidores es indispensable la pestaña de configuración, en otras palabras, si se bloquea
esta pestaña se debe asegurar de que los servidores que haya en la topología estén
perfectamente configurados y que los PCs tengan sus interfaces activadas en la red
importada como red de respuesta. Valga la aclaración que ésto es lo único con lo que yo he
tenido problemas, pero pueden haber otras cosas que todavía no haya explorado que
también sea imposible hacer como consecuencia de bloquear algo en la interfaz. Eso hay
que preverlo cuando se hagan laboratorios o actividades evaluables.
Video
Con base en lo anterior, preparé éste video que ilustra brevemente todo lo que describí, pero
es indispensable haberlo leído. Para que el video no quedara muy largo, pausé varias veces
la captura, así que uds. sabrán perdonar las pausas y saltos del ratón, incluso así salió largo.
http://cesarcabrera.info/blog/?p=721