Cisco ha anunciado la actualización de las certificaciones CCNA Security y CCNP Security.
El anuncio está referido tanto a la actualización de exámenes de certificación, como de los entrenamientos que mapean directamente a ambas certificaciones. De acuerdo al anuncio, esta actualización incorpora destrezas y conocimientos referidos a nuevos productos e implementaciones:
- Se ha incluido Cisco ASA con firmware versión 8.3 y 8.4.
- Se ha focalizado la atención en Cisco AnyConnect 3.0 y otros clientes IPsec tradicionales.
- Se ha incluido información a la implementación de NAT en Cisco ASA 8.3.
- Se ha ampliado la información referida a la configuración global de ACLs.
- Lo mismo se ha hecho respecto de EtherChannel.
- Se ha incorporado la utilización de CCP para el management de ISRs.
- Se ha incluido Cisco IOS 15.x en el caso de ISRs.
¿Cómo quedan ahora las certificaciones?
CCNA Security
El examen de certificación actual es IINS 640-553. Podrá ser rendido aún hasta el 30 de septiembre de 2012 para obtener la certificación. Esto quiere decir que quienes están estudiando hoy para obtener su certificación pueden seguir haciéndolo con los mismos manuales y rendir el mismo examen para lograr su objetivo.
El nuevo examen de certificación es el IINS v2.0 640-554 ya está disponible y será el único a partir del 1 de octubre de 2012.
CCNP Security
La certificación de nivel profesional está compuesta de 4 exámenes, de los cuales 2 han sido actualizados.
Fue actualizado el examen de FIREWALL (Deploying Cisco ASA Firewall Solutions). El examen actual (642-617) podrá ser rendido hasta el 28 de mayo de 2012. El nuevo examen de certificación FIREWALL v2.0 642-618 ya está disponible.
También fue actualizado el examen VPN (Deploying Cisco ASA VPN Solutions). El examen actual 642-647 podrá ser rendido también hasta el 28 de mayo de 2012. El nuevo examen de certificación VPN v2.0 642-648 también ya está disponible.
Por el momento no hay anunciados cambios para los exámenes SECURE v1.0 (642-637) e IPS v7.0 (642-627).
De esta manera, a partir del 28 de mayo de 2012, la certificación CCNP Security queda conformada por estos 4 exámenes:
- SECURE v1.0 642-637
- FIREWALL v2.0 642-618
- VPN v2.0 642-648
- IPS v7.0 642-627
Hasta esa fecha, es posible obtener la certificación con los exámenes aún vigentes.
También hay que tener presente que los exámenes ya aprobados (por ejemplo un FIREWALL v1.0) tienen una validez de 3 años, por lo que quienes ya tienen aprobado alguno de los exámenes que se han actualizado no necesitan rendir nuevamente las versiones nuevas sino completar el path.
Enlaces de referencia:
La resolución de fallos es el proceso que lleva al diagnóstico, y si es posible la resolución, de un problema, incidente o evento.
Este proceso reconoce 3 etapas o momentos principales:
- El reporte del problema, incidente o evento.En el proceso de resolución de fallos el problema no existe hasta que es notificado.Esto significa, ante todo, que el evento que causó el problema reportado no necesariamente ocurrió en el momento en que fue reportado.
Es posible que el evento que causó el fallo haya ocurrido tiempo antes y nadie lo haya advertido, o si lo hizo no lo reportó.También es importante tener presente que el usuario reporta un incidente desde su propia perspectiva y con su lenguaje. Esto hace imprescindible que al momento de analizar el reporte de un incidente el técnico asuma la posición de usuario para poder comprender claramente el hecho reportado y el grado de urgencia que reporta para la tarea del usuario.Es preciso diferenciar y distinguir claramente el problema de los síntomas, y a estos de las verdaderas causas del problema.El usuario nos reporta el problema y muchas veces los síntomas. Muy difícilmente nos indica las causas.
- A partir del reporte de un problema se inicia el proceso de diagnóstico.Este es un proceso complejo cuyo objetivo es detectar la verdadera causa del problema para, si es posible, solucionarla.Como resultado de este proceso se debe proponer una posible solución. En algunos casos la solución no será posible implementarla de modo inmediato, por lo que será necesario definir una tarea preliminar que permita remediar provisionalmente los síntomas del problema hasta tanto se pueda implementar una solución definitiva.
- Se considera que se ha llegado a una verdadera solución cuando es posible resolver la causa profunda del problema, no simplemente cuando se resuelve el síntoma al que apunta el reporte inicial del problema que hizo el usuario.
El proceso de resolución de fallos es un proceso complejo que conlleva la elección de estrategias de abordaje, a la vez que un conjunto de herramientas o técnicas específicas. Respecto de estas estrategias y herramientas me ocuparé en futuros posts.
Bibliografía asociada:
Cuadernillo: Elementos de diagnóstico y resolución de fallos - Oscar Gerometta
Hace ya tiempo dediqué un post a comentar el significado del comando bandwidth. En él explicaba que este comando no establece en "ancho de banda" de un enlace sino que tiene un valor declarativo para establecer un parámetro que luego utilizarán en sus algoritmos de cálculo los protocolos de capa superior, como los protocolos de enrutamiento.
Ahora bien, el ancho de banda declarado (bandwidth) también tiene impacto en las políticas de QoS.
La políticas de QoS por defecto
Un punto que frecuentemente ignoramos u olvidamos, es que Cisco IOS aplica en las interfaces una política por defecto: se reserva solamente un 75% del ancho de banda para el tráfico de datos. Esta reserva recibe el nombre de "available bandwidth".
¿Qué quiere decir esto?
Esto tiene 2 consecuencias:
- Cisco IOS asegura que siempre hay una reserva de hasta el 25% del bandwith para el tráfico del plano de control.
Esta política tiene como propósito asegurar que los protocolos (p.e. protocolos de enrutamiento) que mantienen la infraestructura de la red tengan espacio suficiente para operar.
- Cuando se aplican políticas de calidad de servicio, no se puede asignar más del 75% del ancho de banda declarado.
Si una política define un volumen de tráfico garantizado mayor del 75% disponible, al aplicar la política a la interfaz se recibirá un mensaje de error indicando que se está excediendo la disponibilidad actual.
Esta política por defecto es importante en enlaces de baja capacidad ya que asegura el mantenimiento del plano de control. Sin embargo puede representar una mala política de asignación de recursos cuando se trata de enlaces de alta capacidad (por ejemplo enlaces de 10 Mbps o superiores).
De cualquier modo téngase en cuenta que esto no significa que ese 25 % no podrá ser utilizado para datos si está disponibles. Pongamos un ejemplo:
- Tomemos como base un enlace de 10 Mbps: bandwidth 10000
- Por defecto: reserva 2,5 Mbps para tráfico de control y permite reservar hasta 7,5 Mbps para datos.
- ¿Qué ocurre si no tenemos más que 0,5 Mbps de plano de control?
1. El tráfico de control tiene reservada capacidad de transporte más que suficiente.
2. El tráfico de datos tiene reservados hasta 7,5 Mbps
3. Siempre es posible que haya más de 7,5 Mbps de datos porque el tráfico de control no utiliza toda su reserva, pero no es posible garantizar cuánto más podrá usar.
¿Se puede modificar esta política por defecto?
Si, la política por defecto se puede modificar.
Una manera de modificarla es simplemente "mentir" el bandwidth ya que es puramente declarativo. Esta NO es una práctica recomendable ya que el parámetro no se utiliza solamente para el cálculo de las asignación de QoS, sino también como métrica para los protocolos de enrutamiento.
El modo de modificar la política es utilizando el comando max-reserved-bandwidth que permite modificar ese porcentaje por defecto del 75% para aplicar la política que más se ajuste a nuesta necesidad.
Este comando está disponible en todas las versiones actuales de IOS, a partir de 12.0, si bien en IOS 15.0 está como comando oculto ya que está anunciado por Cisco que el comando es reemplazado por otra metodología de configuración de QoS.
Enlaces relacionados
Bibliografía sugerida:
Introducción a Quality or Services - Oscar Gerometta
Un problema desafortunadamente habitual pero poco analizado en nuestras redes Ethernet, es el cableado. En muchos casos al hacer el cableado inicial se certificó la instalación, se compraron patchs certificados, pero luego se opera regularmente sin volver sobre el tema cableado. Fue un punto de atención en el momento de la implementación, pero no recibe mayor atención hasta que se produce un fallo.
Y en la resolución de fallos, cuando se trata de una red que estaba en operaciones, no siempre es un punto que se verifica inicialmente. Muchas veces se llega a analizar el estado del cable cuando ya se han descartado todas las otras causas posibles. Y esto es porque no siempre tenemos a mano un tester de cables, o estamos físicamente lejos de la instalación y eso nos hace difícil la verificación.
Pues bien, en el caso de los switches Catalyst, Cisco IOS incluye un feature que nos permite hacer una verificación de TDR (Time Domain Reflector) del cable Ethernet que está conectado en una boca específica del switch.
show cable-diagnostics tdr
Se trata de un comando de modo privilegiado introducido a partir de IOS 12.2(25)FX.
La estructura del comando es la siguiente:
Switch#show cable-diagnostics tdr interface FastEthernet 0/1
TDR test last run on: February 10 20:15:40
Interface Speed Local pair Pair length Remote pair Pair status
--------- ----- ---------- --------------- ----------- ------------
Fa0/1 auto Pair A 0 +/- 2 meters N/A Open
Pair B 0 +/- 2 meters N/A Open
Pair C 0 +/- 2 meters N/A Open
Pair D 0 +/- 2 meters N/A Open
Como se puede apreciar, el comando en la columna "Pair length" nos permite precisar a qué distancia respecto de la boca del switch en la que se ejecutó el comando se encuentra potencialmente el problema. Reporta solamente en 3 situaciones concretas:
- El cable está conectado y la interface está up.
- El cable está "abierto".
- El cable está en corto.
La columna "Remote Pair" identifica con qué par remoto está conectado cada par del cable. Pero esta información sólo se brinda cuando el cable está adecuadamente conectado a otro switch y el enlace está operativo.
Este comando está soportado esclusivamente en puertos de cobre 10/100 y 10/100/1000.
Sin dudas un comando muy útil en la resolución de fallos, tanto cuando estamos operando de modo remoto como cuando estamos en el lugar pero no disponemos de un probador de cables o queremos evitar interrumpir la conexión. La información detallada del comando, como siempre, la pueden encontrar en el sitio de Cisco:
Bibliografía asociada:
Cuadernillo: Elementos de diagnóstico y resolución de fallos - Oscar Gerometta
Amigos.
Uno de los temas que generan incógnitas al momento de preparar el examen de certificación CCNA son las preguntas de simulación que están incluidas en el examen.
Cada examen suele incluir entre 1 y 3 preguntas de simulación, de las que hay de 2 tipos diferentes: ejercicios de configuración y ejercicios de resolución de fallos.
Este tema está incluido en la Guía de Preparación para el examen de certificación CCNA. Pero siempre surgen nuevas consultas y solicitudes.
Es por ello que preparé un cuadernillo que contiene exclusivamente ejercicios de configuración y resolución de fallos, con el objeto de ayudar a quienes están preparando su examen. En los ejercicios e incluido las configuraciones iniciales y la resolución de cada uno.
Para reproducir estos escenarios se pueden utilizar tanto dispositivos reales, como virtualizados en GNS3 o simulados en Packet Tracer.
Este cuadernillo he decidido ponerlo de acceso libre. Sólo pido que quienes reutilicen este material citen claramente la fuente e incluyan un enlace al documento original.
Simulaciones CCNA v4.1
Si les resulta de utilidad, los comentarios y sugerencias siempre son bienvenidos.
Un requerimiento habitual en las tareas de administración de la red es el de medición de la performance de los enlaces.
En este punto, permítanme ante todo una aclaración: la medición de performance está referida inicialmente a la medición de un enlace específico. También podemos medir la performance de una conexión a través de una ruta completa, por ejemplo entre mi terminal y el servidor de Blogger. Pero en este caso el resultado será igual a la performance del enlace de menor capacidad por el cual atraviesa mi ruta hacia Blogger.
Pero entrando específicamente en tema, si vamos a medir performance primero tenemos que aclarar un par de conceptos.
Data Rate y Throughput
Lo primero es tener claro la diferencia entre la tasa de transferencia del enlace (habitualmente denominada "data rate") y la tasa de transferencia efectiva (denominada "throughtput).
El data rate refiere a la capacidad absoluta de un enlace y es función directa de la manera en que modula y codifica la portadora sobre ese enlace. Habitualmente suele medirse en bits/segundo (Mbps, Gbps, etc.).
El data rate establece un límite absoluto para nuestra transmisión: no podemos transmitir mayor cantidad de datos que la definida en el data rate.
El througput en cambio, es la capacidad efectiva de transferencia de datos sobre el enlace. Esta capacidad siempre es menor al data rate ya que en los enlaces, junto con los datos, hay tráfico de negociación, mantenimiento y control del enlace. Esto en sistemas TCP/IP además depende del protocolo de capa de transporte que utiliza la aplicación, que puede ser TCP o UDP. Típicamente una sesión UDP tiene un 20% más de performance que una seción TCP sobre el mismo enlace. En muchos casos (Microsoft, por ejemplo) vamos a encontrar el throughput en Bytes/segundo (KBps, MBps).
Un ejemplo:
En redes inalámbricas (WiFi) solemos encontrar conexiones que están declaradas como de 54 Mbps, sin embargo nunca llegamos a esa cifra cuando realizamos transferencias de archivos.
Esto se debe esencialmente a que el protocolo IEEE 802.11g que implementan las redes WiFi tiene una alta carga de tráfico de management y control, al mismo tiempo que impone tiempos de espera muy altos. A esto súmenle que la mayoría del tráfico que pasa sobre esas redes es TCP.
Si lo vemos en cifras:
- Data rate: 54 Mbps.
- Throughput máximo: Aproximadamente 28 Mbps.
- Throughput de una sesión FTP (TCP): 22,4 Mbps o 2,8 MBps.
Consecuencias prácticas: el data rate se verifica monitoreando la velocidad a la que negocian los puertos que componen un enlace; el throughput debe ser medido generando tráfico sobre ese enlace.
¿Cómo medimos el throughput?
A los fines operativos lo que se nos suele requerir es la medición de throughput y para esto lo que necesitamos es generar tráfico sobre el enlace para medir efectivamente cuál es su capacidad.
Existen generadores de tráfico, e incluso podemos configurar un dispositivo (como un router) para que genere tráfico. Pero estas soluciones son costosas y requieren conocimientos avanzados para poder implementarlas.
Hay una solución simple y de muy bajo costo: Iperf.
Se trata de una herramienta open source, muy sencilla de utilizar y que provee la información que habitualmente necesitamos para resolver situaciones en las que la performance es un parámetro que requiere estudio.
Iperf trabaja con una lógica cliente-servidor, por lo que debe ser instalado en terminales que estén en ambos extremos del enlace que se desea medir. Puede generar y medir tanto tráfico TCP como UDP y nos permite definir tamaño de los paquetes, puerto de destino, duración de la medición, etc.
La información que nos brinda es, para la sesión que se está analizando, delay, jitter (variación del delay) y throughput.
Iperf es una herramienta multiplataforma que se ejecuta por línea de comando y nos entrega los resultados en modo texto.
Personalmente prefiero utilizar Jperf. Jperf no es más que un frontend gráfico en Java para facilitar la operación y monitoreo de Iperf. Mi preferencia se debe a que la salida gráfica de los resultados es un elemento útil al momento de tener que presentar informes de performance de los enlaces.
En síntesis: Iperf o Jperf (según los gustos personales, son lo mismo) es una herramienta simple pero poderosa para verificar el throughput, la pérdida de paquetes y el jitter.
Pero una salvedad: La capacidad de generación de tráfico dependerá esencialmente de la CPU y memoria RAM de los equipos que estén corriendo la aplicación. Por eso, es muy eficiente para realizar mediciones sobre enlaces de baja capacidad o inalámbricos. Cuando se trata de medir redes LAN, es posible que la capacidad de las terminales que estemos usando no sea suficiente y debamos buscar equipos con mayor procesamiento.
Recursos
Bibliografía sugerida:
Introducción a Quality of Services - Oscar Gerometta
