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:
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.
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.
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.
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
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:
