Cisco acaba de publicar una actualización de su path de certificación de Service Provider.
Primera aclaración: No confundir, hay 2 path de certificación diferentes: Service Provider y Service Provider Operations; aquí me estoy refiriendo al primero de ellos.
Segunda aclaración: hay una modificación importante y significativa: se ha introducido un nuevo CCNA que es el CCNA Service Provider.
En conclusión, la noticia principal es que hay un nuevo CCNA.
CCNA Service Provider
Las características que destacan de este nuevo CCNA son las siguientes:
- Se trata de una certificación completamente nueva y diferente.
- NO es un CCNA Concentrations. CCNA Concentrations son CCNA Sec, CCNA Wir, CCNA Vo y CCNA SPO; en estos 4 casos es pre-requisito el CCNA R&S.
- Esta nueva certificación NO requiere como pre-requisito el CCNA R&S tradicional (640-802).
- Esta certificación se obtiene aprobando 2 exámenes: 640-875 SPNGN1 y 640-878 SPNGN2.
- En sus contenidos estos exámenes (y las capacitaciones correspondientes) se centran en las tecnologías y dispositivos de redes de transporte, y la implementación de IOS-XE y IOS-XR.
De esta manera, un esquema posible de la situación actual de los path de certificación de Cisco es el siguiente:
Versión actualizada del esquema, en este post.
Enlaces de referencia
IPv6 no sólo ofrece un nuevo esquema de direccionamiento con un espacio de direccionamiento mucho más amplio. También establece una nueva forma de utilizar el direccionamiento y nuevas prestaciones. Parte de esta novedad es una variedad amplia de diferentes tipos de direcciones IPv6.
Básicamente hay 3 tipos de direcciones: unicast, multicas y anycast. En IPv6 se ha suprimido completamente el broadcast de capa 3.
Pero más allá de esta simplificación de 3 tipos de direcciones, hay más aspectos a considerar.
Direcciones de unicast
Se utilizan para comunicaciones uno a uno.
Pueden ser sumarizadas, para esto las direcciones son acompañadas por un prefijo que especifica una cantidad determinada de bits significativos.
Hay varios tipos de direcciones de unicast:
- Direcciones globales.
Son utilizadas para tráfico global y tienen una estructura jerárquica de 3 niveles:
Un prefijo de enrutamiento global (red), típicamente de 48 bits.
Un identificador de enrutamiento local (subred), de 16 bits.
Un identificador de interfaz de 64 bits de longitud.
La longitud de cada porción es arbitraria, pero generalmente se respetan los 64 bits del ID de interfaz para mantener compatibilidad con múltiples implementaciones.
En la actualidad IANA y RIR están asignando direcciones del rango 2000::/3.
- Direcciones site-local (obsoletas).
- Direcciones unique local.
Son direcciones que tienen el alcance de un sitio específico sin garantías de que sean globalmente únicas. Estas direcciones tienen una estructura propia:
Un prefijo FC00::/7 de 8 bits.
Un ID global pseudo-aleatorio de 40 bits.
Un ID de subred de 16 bits.
Un identificador de interfaz de 64 bits.
Estas direcciones no son ruteables sobre Internet.
- Direcciones link-local.Todas las interfaces que operan con IPv6 tienen una dirección link-local.Su alcance está limitado al enlace y no son reenviadas.Son generadas dinámicamente con el prefijo FE80::/10 y un identificador de interfaz de 64 bits.Permiten la comunicación entre dispositivos que están en un mismo segmento de red sin necesidad de otro tipo de direcciones.Se utilizan en procesos de configuración automática, descubrimiento de vecinos y descubrimiento de routers.
- Direcciones para propósitos especiales:
Dirección sin especificar: ::
Se utiliza como dirección de origen con propósitos especiales, por ejemplo en solicitudes DHCP.
Nunca ocupa el campo de dirección de origen en un encabezado IPv6. Si así fuera el paquete no será reenviado.
Dirección de loopback: ::1
Como en el caso de la dirección 127.0.0.1, define una interfaz local para el stack IP.
Direcciones de multicast
Permiten establecer como destino todos las interfaces de un grupo.
Son direcciones definidas por el prefijo FF00::/8 donde el segundo octeto define el alcance de esta dirección multicast que puede ser la sola interfaz, el segmento de red, una subred, una red o Internet.
El ID del grupo de multicast está definido por los restantes 112 bits.
El rango FF00:: a FF0F:: está reservado y asignado a través del RFC 2375.
Direcciones de anycast
Permiten definir como destino un host cualquiera de un grupo.
Son direcciones asignadas a interfaces de uno o más nodos.
Cuando la dirección de destino de un paquete IPv6 es una dirección de anycast, se rutea hacia la interfaz más cercana que esté asociada a esa dirección.
Las direcciones de anycast se toman del rango de direcciones de unicast y requieren que la interfaz esté explícitamente configurada para identificar la dirección como dirección de anycast.
Recuerdo:
En IPv6 no existen las direcciones de broadcast.
Bibliografía asociada:
Cuadernillo: Protocolo IPv6 básico - Oscar Gerometta
Días atrás, al introducir los principios de resolución de fallos, mientras desarrollaba la primer etapa de la tarea introduje una distinción: el problema, los síntomas y las causas verdaderas del problema.
Varios de ustedes, lectores, me pidieron bajar a casos concretos este tema, que ciertamente puede tornarse un poco abstracto. Por eso permítanme un pequeño ejemplo de esta distinción.
La distinción entre síntomas, problemas y causas es aplicable a todo incidente. Para ver de dejarla clara la aplicaré a un incidente muy sencillo.
Incidente: El usuario X reporta que no puede acceder a Internet.
La primer tarea que debe realizar quien recibe el reporte es revisar y verificar el incidente denunciado para determinar y establecer claramente cuál es el problema y cuál es el alcance del mismo. Como fruto de esto debe obtener un enunciado claro y preciso del problema.
Problema: Cuando el usuario intenta acceder cualquier URL (p.e. www.google.com) desde su navegador de Internet recibe como respuesta que el servicio no está disponible. Igualmente, cuando se ejecuta un ping al mismo dominio (google.com) se recibe como respuesta que no se puede encontrar el host buscado.
La definición del problema es la descripción precisa del inconveniente que experimenta el usuario. Es una descripción no técnica, desde la perspectiva del usuario.
El paso siguiente es volcar esta descripción a un lenguaje técnico, tan preciso como resulte posible. En este mismo caso:
Síntoma: A partir de la ejecución del ping se puede verificar que el sistema no está traduciendo el nombre de dominio por una dirección IP válida.
Es decir, nuestro usuario tiene problemas de DNS, por eso no puede navegar Internet.
Hasta aquí solamente hemos descrito el problema del usuario y los síntomas que lo verifican. A partir de este momento comienza el proceso de diagnóstico al cual aludía días atrás. El objeto del proceso de diagnóstico es encontrar la verdadera causa del problema para resolverlo a partir de la corrección de la causa. ¿Qué es lo que está causando estos síntomas?
En nuestro caso, la causa del problema resultó ser un error de configuración.
Causa: Un error de configuración IP en el cliente del usuario impide a la terminal ejecutar exitosamente la traducción de los nombres de dominio.
Como se puede observar, sólo un correcto diagnóstico de la causa puede llevar a una verdadera resolución del incidente en su raíz.
En algunos casos la resolución rápida de los síntomas puede dar una respuesta transitoria al problema (p.e. el agregado de una ruta estática para solucionar un problema de enrutamiento), pero el incidente en sí mismo no estará resuelto hasta tanto diagnostiquemos claramente las causas y elaboremos una estrategia de resolución.
Bibliografía asociada:
Cuadernillo: Elementos de diagnóstico y resolución de fallos - Oscar Gerometta
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
