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.
