Comandos: show ip interface brief

Un comando de diagnóstico que no siempre apreciamos lo suficiente es show ip interface brief. 
Es por esto que me parece importante dedicar un post específicamente a este comando ya que brinda una información clave, de modo sintético y esencial al momento de diagnosticas problemas de conectividad.

El comando ha sido introducido en IOS 9.3.0 y desde entonces no ha sufrido modificaciones. La keyword "brief" es un opcional que genera una tabla sintética con la información más relevante de la operación de cada interfaz del dispositivo, orientada primariamente a la usabilidad de cada interfaz.

Está disponible en modo EXEC privilegiado.

Propongo como siempre en primer lugar un ejemplo del resultado de este comando para luego revisarlo con mayor detalle.

Router#show ip interface brief

Interface             IP-Address      OK?   Method Status   Protocol
GigabitEthernet0/1    unassigned      YES   unset  up       up
GigabitEthernet0/2    192.168.190.235 YES   DCHP   up       up
GigabitEthernet0/3    unassigned      YES   unset  up       up
GigabitEthernet0/4    192.168.191.2   YES   NVRAM  up       up
TenGigabitEthernet2/1 unassigned      YES   unset  up       up
TenGigabitEthernet2/2 unassigned      YES   unset  up       up
TenGigabitEthernet2/3 unassigned      YES   unset  up       up
TenGigabitEthernet2/4 unassigned      YES   unset  down     down

Lectura del comando

Router#show ip interface brief

Interface             IP-Address      OK?   Method Status   Protocol
GigabitEthernet0/1    unassigned      YES   unset  up       up

• Interface: tipo de interfaz siguiendo la nomenclatura estándar de IOS para las interfaces de los dispositivos.
• IP-Address: Dirección IP asignada a la interfaz (no incluye longitud del prefijo IP).
  Solo muestra direccionamiento IPv4.
  Si no hay IPv4 asignada a la interfaz aparece como "unassigned".
• OK?: Verifica que el direccionamiento IPv4 asignada es actualmente válido. "YES" indica la validez de la asignación. "NO" indica un direccionamiento IPv4 no válido.
• Method: Indica el procedimiento utilizado para la asignación del direccionamiento referido antes.
  
  Tiene múltiples valores posibles. Los más usuales son:
  TFTP - La configuración se ha obtenido de un servidor TFTP.
  manual - Se ha configurado manualmente a través de la CLI.
  NVRAM - Configuración leída de un archivo en la NVRAM.
  DHCP - Configuración obtenido a través de DHCP.
  unassigned - No tiene dirección IPv4 asignada.
  unset - No configurado.
  
• Status: Indica el estado de la interfaz.
  
  up - Interfaz habilitada administrativamente.
  down - interfad habilitada administrativamente pero no operativa a nivel físico.
  administratively down - Interfaz no habilitada adminsitrativamente.
  
• Protocol: Indica si se encuentra operacional el protocolo en la interfaz.

GigabitEthernet0/2    192.168.190.235 YES   unset  up       up
GigabitEthernet0/3    unassigned      YES   unset  up       up
GigabitEthernet0/4    192.168.191.2   YES   unset  up       up
TenGigabitEthernet2/1 unassigned      YES   unset  up       up
TenGigabitEthernet2/2 unassigned      YES   unset  up       up
TenGigabitEthernet2/3 unassigned      YES   unset  up       up
TenGigabitEthernet2/4 unassigned      YES   unset  down     down

Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en

 el Glosario de Siglas y Términos de Networking

que está disponible en la Librería en Línea de EduBooks.

Comandos: show cdp traffic

Entre los comandos asociados al monitoreo y diagnóstico de CDP hay algunos de mucha importancia para diagnosticas la operación pero a los cuales no les solemos dar mayo relevancia.

Es el caso de show cdp y show cdp traffic. Por eso vamos a detenernos a dar una mirada a estos comandos.

show cdp
Este comando permite verificar la información global de CDP incluyendo temporizadores.
Fue introducido en IOS 10.3 y se ha mantenido desde entonces sin variantes significativas. Este comando no incluye argumentos más específicos por lo que es de ejecución muy sencilla.

Consideremos en primer lugar un ejemplo para luego revisarlo con mayor detalle.

Router#show cdp
Global CDP information:
 Sending CDP packets every 60 seconds
 Sending a holdtime value of 180 seconds

 Sending CDPv2 advertisements is enabled

Lectura del comando

Router#show cdp
Global CDP information:
 Sending CDP packets every 60 seconds

• Intervalo en segundos entre emisión de publicaciones CDP.
  Refleja lo definido utilizando el comando cdp timer.

 Sending a holdtime value of 180 seconds

• Espacio de tiempo expresado en segundo que el dispositivo mantendrá un publicación CDP de un vecino antes de descartarla.
  Se puede modificar utilizando el comando cdp holdtime.

 Sending CDPv2 advertisements is enabled

• Versión del protocolo utilizada para publicar información CDP por el dispositivo. Tiene 2 estados posible: "enabled" o "disabled".
  Esta información responde al comando cdp advertise v2.

show cdp traffic
Comando que permite verificar información referida al tráfico de paquetes CDP entre dispositivos. Es un comando introducido en IOS 10.3 que no ha tenido modificación a partir de ese momento y que no tiene argumentos.

Un ejemplo:

Router# show cdp traffic

 Total packets output: 543, Input: 333
 Hdr syntax: 0, Chksum error: 0, Encaps failed: 0
 No memory: 0, Invalid: 0, Fragmented: 0
 CDP version 1 advertisements output: 191, Input: 187

 CDP version 2 advertisements output: 352, Input: 146

Lectura del comando

Router# show cdp traffic

 Total packets output: 543, Input: 333

• Packets output: Cantidad de publicaciones CDP enviadas por el disposirito.
  Es la suma de las publicaciones CDP versión 1 y versión 2 que se han enviado.
• Input: Cantidad de publicaciones CDP recibidas por este dispositivo de los dispostiivos vecinos.
  Es la suma de las publicaciones CDP versión 1 y versión 2 recibidas.

 Hdr syntax: 0, Chksum error: 0, Encaps failed: 0

• Hdr syntax: Cantidad de publicaciones CDP con errores de encabezado recibidas.
• Chksum error: Cantidad de publicaciones recibidas que fallaron la verificación del checksum de la trama.
• Encaps failed: Cantidad de veces que el dispositivo local no pudo enviar una actualización CDP a causa de un error en el puerto local.

 No memory: 0, Invalid: 0, Fragmented: 0

• No memory: Cantidad de veces que el dispositivo local no dispuso de la memoria suficiente para almacenar las publicaciones de CDP cuando intentó procesar las actualizaciones  recibidas.
• Invalid: Número de publicaciones CDP inválidas recibidas y enviadas por el dispositivo local.
• Fragmented: Número de veces que fragmentos o porciones de una publicación CDP fueron recibidas por el dispositivo en lugar de publicaciones completas.

 CDP version 1 advertisements output: 191, Input: 187

• Advertisements output: número de publicaciones de CDP versión 1 enviadas por este dispositivo.
• Input:  número de publicaciones CDP versión 1 recibidas por este dispositivo.

 CDP version 2 advertisements output: 352, Input: 146

• Advertisements output: número de publicaciones de CDP versión 2 enviadas por este dispositivo.
• Input: número de publicaciones CDP versión 2 recibidas por este dispositivo.

Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en

 el Glosario de Siglas y Términos de Networking

que está disponible en la Librería en Línea de EduBooks.

Comandos: show cdp neighbors

Cuando nos iniciamos en la utilización de la CLI de IOS, uno de los primeros protocolos que encontramos es CDP. Un protocolo propietario de Cisco empleado para descubrir dispositivos vecinos y brindar soporte a implementaciones de calidad de servicio, PoE, etc.

Asociados a la operación del protocolo (del que hoy contamos con un estándar que es LLDP) IOS brinda una serie de comandos de verificación entre los cuales uno de los más utilizados es show cdp neighbors. 
El comando fue introducido en IOS 10.3 y no tiene mayores variaciones al día de hoy.
Como venimos haciendo ya en casos anteriores, consideremos un ejemplo para luego revisar la información que nos presenta el comando.

Router#show cdp neighbors
 Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                   S - Switch, H - Host, I - IGMP, r - Repeater

 Device ID        Local Intrfce     Holdtme    Capability  Platform   Port ID
 lab-7206         Eth 0              157          R        7206VXR    Fas 0/0/0
 lab-as5300-1     Eth 0              163          R        AS5300     Fas 0
 lab-as5300-2     Eth 0              159          R        AS5300     Eth 0
 lab-as5300-3     Eth 0              122          R        AS5300     Eth 0
 lab-as5300-4     Eth 0              132          R        AS5300     Fas 0/0
 lab-3621         Eth 0              140         R S       3631-telco Fas 0/0
 008024 2758E0    Eth 0              132          T        CAT3000    1/2

Lectura del comando

Router#show cdp neighbors
 Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                   S - Switch, H - Host, I - IGMP, r - Repeater

• Presenta los códigos de interpretación de la información contenido más abajo en la columna "capability" de la tabla de información que presenta.

 Device ID        Local Intrfce     Holdtme    Capability  Platform   Port ID
 lab-7206         Eth 0              157          R        7206VXR    Fas 0/0/0

• Device ID: Hostname del dispositivo vecino. Si no hay un hostname disponible se indica la dirección MAC o el número de serie del dispositivo.
• Local Intrfce: Interface del dispositivo en el cual se ejecuta el comando, a través de la cual se recibe la información CDP del dispositivo vecino.
• Holdtime: Tiempo remanente en segundos por el cual este dispositivo aguardará una nueva actualización del dispositivo vecino, antes de descartar la entrada.
• Capability: Tipo de dispositivo que ha generado la información CDP que se ha recibido. Puede ser un router (R), bridge transparente (B), switch (S), host (H), dispositivo IGMP (I) o repetidor (r)
• Platform: ID de producto o  modelo de dispositivo vecino del cual se ha recibido la información.
• Port ID: ID de puerto del dispositivo vecino que generó el paquete de información que se ha recibido.

 lab-as5300-1     Eth 0              163          R        AS5300     Fas 0
 lab-as5300-2     Eth 0              159          R        AS5300     Eth 0
 lab-as5300-3     Eth 0              122          R        AS5300     Eth 0
 lab-as5300-4     Eth 0              132          R        AS5300     Fas 0/0
 lab-3621         Eth 0              140         R S       3631-telco Fas 0/0
 008024 2758E0    Eth 0              132          T        CAT3000    1/2

Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en

 el Glosario de Siglas y Términos de Networking

que está disponible en la Librería en Línea de EduBooks.

¿Un laboratorio para CCNA en Packet Tracer?

Hace ya un tiempo propuse una maqueta que permite ejercitar todas las tecnologías incluidas en el examen de certificación CCNA 200-125. Esta es también la maqueta que utilizo para proponer los laboratorios incluidos en los manuales que he publicado para la certificación CCNA.
Como indico en los manuales, a los fines de preparar el examen de certificación esta maqueta puede armarse tanto con dispositivos físicos como virtualizados (GNS3 o Eve-NG), como en el simulador más extendido que a mi entender es Packet Tracer.

Dado que no todos tienen la misma experiencia en el uso de estas herramientas es que escribo este post para dar algunos tips básicos para el armado de la maqueta en Packet Tracer.

¿Qué routers utilizar?
En Packet Tracer la maqueta puede desarrollarse utilizando routers Cisco 2911.

Para poder cubrir los requerimientos de estos 4 routers los routers Cisco 2911 en Packet Tracer cuentan con 3 interfaces GigabitEthernet (0/0, 0/1 y 0/2) y la posibilidad de incorporar en el chasis un módulo HWIC-2T para incorporar 2 interfaces seriales.

De esta forma, utilizando routers Cisco 2911 con un módulo HWIC-2T se pueden cubrir todos los requerimientos de la maqueta ya que desde la perspectiva del software Packet Tracer simula un IOS 15.1 (4)M4 que está alineado con el requerimiento del examen de certificación.

¿Cómo montamos el servidor de autenticación?
Para montar el servidor de autenticación utilizamos el servidor genérico incluido en las opciones de equipos terminales de Packet Tracer,

Una vez instalado el servidor, para contar con un servicio RADIUS o TACACS+ es necesario abrir la configuración del dispositivo, y seleccionar la solapa "Services".
En esta solapa el menú de la izquierda nos permite seleccionar los servicios que se desea activar. Es posible utilizar este servidor para montar servicios TFTP, FTP, NTP, SYSLOG en la red. En este caso lo que nos interesa es el servicio AAA.
Una vez seleccionado el menú de AAA es necesario "encender" el servicio seleccionando la opción "On", y luego el protocolo a utilizar: RADIUS o TACACS+.

El resto de la configuración ya es tema del desarrollo del laboratorio.

Espero que estas notas sean de utilidad para quienes se inician en el uso de Packet Tracer y desean aprovecharlo para su preparación para el examen.

• Post: Un laboratorio para CCNA 200-125

Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en

 el Glosario de Siglas y Términos de Networking

que está disponible en la Librería en Línea de EduBooks.

Comandos: show ip route

Un comando de diagnóstico ampliamente utilizado para tareas de diagnóstico de enrutamiento es show ip route.

El comando tiene múltiples variantes, una de las cuáles es la que nos permite verificar la ruta que el dispositivo utilizará para enrutar un paquete con una IP de destino específica:
show ip route x.x.x.x

Este comando nos pemite verificar configuración específica y detallada respecto de la ruta que se utilizará para reenviar un paquete específico.
El comando fue introducido en IOS 9.2 y ha tenido una evolución muy importante sobre todo en lo que hace a las opciones e información que se brinda.

Como suelo hacer en estos casos, consideremos un ejemplo para revisar el resultado del comando:

Router#show ip route 192.168.5.130
Routing entry for 192.168.5.128/28
  Known via "eigrp 1", distance 90, metric 2172416, type internal
  Redistributing via eigrp 1
  Last update from 192.168.5.162 on Serial0/0/0.2, 00:20:16 ago
  Routing Descriptor Blocks:
  * 192.168.5.128, from 192.168.5.162, 00:20:16 ago, via Serial0/0/0.2
      Route metric is 2172416, traffic share count is 1
      Total delay is 20100 microseconds, minimum bandwidth is 1544 Kbit/sec
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

Lectura del comando

Router#show ip route 192.168.5.130
Routing entry for 192.168.5.128/28

• Prefijo IP (red/máscara) de la ruta que se utilizará para efectivamente reenviar el paquete con la dirección IP de destino que se especifica.

  Known via "eigrp 1", distance 90, metric 2172416, type internal

• "Know via": indica la fuente de información a partir de la cuál se incorpora esta ruta en la tabla de enrutamiento. Refleja la información que se plasma en la columna izquierda de la tabla de enrutamiento con algunas letras.
• "distance" indica la distancia administrativa asignada a la ruta.
• "metric" muestra la métrica que se ha calculado para esta ruta.
• "tag" muestra la etiqueta asignada a esta ruta. En el ejemplo que elegí la ruta no tiene asignada etiqueta (las rutas no tienen por defecto asignada una etiqueta).
• "type" especifica el tipo de ruta de que se trata, el resultado depende del protocolo utilizado. En el caso de EIGRP se diferencian rutas internas de rutas externas.

  Redistributing via eigrp 1

• Indica cómo se redistribuirá esta información de enrutamiento. En este caso se utilizará el proceso de EIGRP sistema autónomo 1.

  Last update from 192.168.5.162 on Serial0/0/0.2, 00:20:16 ago

• "from" Indica la dirección IP de origen de los paquetes del protocolo de enrutamiento en los que llegó la información que dió origen a esta ruta.
  Es la dirección IP del puerto a través del cuál el dispositivo vecino envió el paquete EIGRP en este caso.
  En los protocolos de enrutamiento interior (IGP) esta es la dirección IP del próximo salto que se mostrará en la tabla de enrutamiento. En BGP la definición de la dirección del próximo salto es diferente.
• "on" muestra la interfaz local a través de la cual se recibió el paquete.
• Finalmente indica el tiempo transcurrido desde que se recibió la última actualización.

  Routing Descriptor Blocks:

• Muestra la información detallada de la ruta recibida.

  * 192.168.5.128, from 192.168.5.162, 00:20:16 ago, via Serial0/0/0.2

• Se repite la dirección de red destino.
• Se indica la dirección IP del próximo salto.
• El tiempo transcurrido desde la última actualización recibida.
• Interfaz local a través de la cual se recibió la actualización.

      Route metric is 2172416, traffic share count is 1

• Métrica asignada a la ruta.
• Cantidad de rutas que utilizan la misma métrica.

      Total delay is 20100 microseconds, minimum bandwidth is 1544 Kbit/sec

• Delay total de la ruta hasta la red destino expresado en microsegundos.
• Ancho de banda del enlace con menor ancho de banda de la ruta hasta el destino.

      Reliability 255/255, minimum MTU 1500 bytes

• Confiabilidad de la ruta considerado a partir de la cantidad de paquetes perdidos y expresada como un valor en función de 8 bits, con lo que 255 = 100%
• Menor tamaño máximo de la trama (MTU) soportado por esta ruta.

      Loading 1/255, Hops 1

• Carga de la ruta expresada utilizado 8 bits, por lo que 255 = 100%
• Cantidad de saltos de capa 3 que se deben atravesar para llegar a la red destino.

Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en

 el Glosario de Siglas y Términos de Networking

que está disponible en la Librería en Línea de EduBooks.

¿Gestión centralizada o control centralizado?

Las redes de datos están en permanente evolución y nos encontramos en este momento en el punto particular en el que avanzamos hacia arquitecturas definidas por software (SDN), lo que marca una modificación radical no sólo en el modo en que se gestionan las redes, sino sobre todo en el modo en que operan.
Por eso me ha parecido importante retomar y revisar algunos de los conceptos que ya hemos discutido en post anteriores a fin de comenzar a visualizar claramente en qué consiste SDN.

Los planos de operación
Un punto sobre el que ya trabajamos hace un tiempo, es la división en planos de la operación de los dispositivos.

En los esquemas tradicionales estos 3 planos de operación operan de modo independiente en cada uno de los dispositivos de la red.

Sistemas de gestión centralizada
Hace ya tiempo que, en la medida en que las redes crecían en cantidad de dispositivos y complejidad, comenzó a ser necesario simplificar los procesos de configuración de los dispositivos que integran esa infraestructura. 
El primer paso fue pasar de una gestión de dispositivos individuales a una gestión centralizada en un único sistema. Esto permitió a continuación no sólo tener un único punto de gestión, sino sumarle el uso de plantillas de configuración, la automatización del proceso de descubrimiento de los dispositivos, automatizar procesos de actualización de software, la generación de reportes integrales, la automatización de estos reportes.
El corazón de estos sistemas es SNMP, el protocolo del stack TCP/IP diseñado con este propósito específico.

A SNMP, dependiendo del sistema en uso, se pueden sumar otros protocolos tales como CDP, LLDP, SSH, HTTPS, etc.
Esto es lo que se logra con la implementación de sistemas de gestión como Cisco Prime, PRTG o Nagios. Prácticamente todos los fabricantes de dispositivos para redes corporativas tienen su herramienta de gestión basada en SNMP.

Sin embargo los sistemas de gestión centralizada son solamente herramientas de gestión de la red tradicional. Facilitan y potencian la configuración, monitoreo y reporting de los sistemas, pero cada dispositivo sigue siendo una unidad autónoma que opera de forma completamente independiente de los demás.

Sistemas de control centralizado
La introducción de las arquitecturas SDN, en cambio, introducen un concepto completamente diferente. Los dispositivos que componen la infraestructura no son ya independientes entre sí sino que se encuentran vinculados a un dispositivo central denominado controlador que es el responsable de mantener el plano de control y el de gestión.

El diálogo entre el controlador y los dispositivos de infrestructura se hace a través de interfaces API que se denominan SouthBound que aplican diferentes protocolos: OpenFlow (el estándar abierto), OpFlex (la versión propietaria de Cisco de OpenFlow), NetConf, etc.
La implementación de esta arquitectura requiere de dispositivos que soporten estas interfaces API para hacer efectiva su asociación con el controlador y el intercambio de información.

Consecuentemente, las redes de control centralizado van mucho más allá que los sistemas de gestión centralizada ya que operan la totalidad de la red como una unidad basando la toma de decisiones respecto del flujo del tráfico en una visión holística integrada de la totalidad de la red, y no ya desde la perspectiva de dispositivos individuales (el antiguo salto por salto).
Por todo esto, confundir los sistemas de gestión centralizada con arquitecturas SDN es un error ya que se trata de arquitecturas completamente diferentes, con posibilidades a futuro absolutamente distintas.

Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en

 el Glosario de Siglas y Términos de Networking

que está disponible en la Librería en Línea de EduBooks.

Estado de IPv6

Periódicamente vuelvo a encontrarme con diferentes publicaciones en las que se pone en dudas o se cuestiona la implementación de IPv6. Incluso algunas que siguen considerándola como una propuesta a futuro que podría o no darse.
Ya muchas veces he abordado el tema en este blog, incluso he publicado un manual con los conceptos básicos de IPv6. Pero evidentemente es necesario cada tanto volver sobre el tema.

La implementación de IPv6 no es una posibilidad, es una realidad que no podemos desconocer. Hay mucha información disponible sobre el tema.

La implementación al día de hoy
Como dije, IPv6 no es un proyecto a futuro sino una tecnología ya implementada cuya penetración es creciente cada día.
Así lo muestra la información disponible.

Un ejemplo.
Google publica en línea el porcentaje de tráfico de sus data centers que utiliza IPv6. Este es el reporte al día de hoy que, como podemos ver, muestra que el 21,09% del tráfico de los data centers de Google es tráfico IPv6 nativo:

Esta información está disponible en línea para quien quiera consultarla en este enlace.

Si lo que queremos es conocer la disponibilidad de conectividad IPv6 a nivel global, este mapa puede servir de primera aproximación:

Una mirada rápida nos permite verificar que el despliegue actual está centrado en América del Norte, Brasil, Europa, India, Japón, Australia y otros países asiáticos. El país con mayor nivel de adopción en este momento es Bélgica con el 62,59% de sus usuarios conectados utilizando IPv6.

Se puede acceder a la información detallada, país por país, desde este enlace.

¿Qué pasa en América Latina?
Como muestra el mapa global, si bien América Latina no se encuentra a la cabeza de la implementación global, tampoco está a la cola de la misma. En los últimos años varios países han disparado sus procesos de adopción

La vista regional del estado de adopción está volcada en este mapa en el que la intensidad del color verde indica un porcentaje creciente de usuarios conectados a IPv6.

Si consideramos el porcentaje de usuarios conectados con IPv6 un índice adecuado de evaluación del proceso, el líder en la región es entonces Uruguay con un 28,4% de sus usuarios conectados a la red IPv6.

Claro que por sus dimensiones, población y peso en la región no podemos ignorar a Brasil que se presenta con un 23,5% de sus usuarios conectados a IPv6.

Lo que es posible verificar de la observación de la información histórica de implementación en la región es que la misma se ha comenzado a desarrollar con mayor intensidad a partir del año 2015.

Esto es para empresas, ¿no para conexiones domiciliarias?

Este es otro prejuicio falso respecto a la implementación de IPv6.
No hay un Internet corporativo y otro hogareño. Claro que todo depende de nuestro proveedor de acceso.
Pero como un ejemplo, yo estoy en este momento utilizando una conexión hogareño de cable módem, y estoy conectado utilizando IPv6:

Y no se trata solamente de recibir direccionamiento IPv6 global unicast, sino que también opero utilizando IPv6 como primer opción:

Si querés saber si estás verdaderamente operando en la red IPv6 hay varios sitios que permiten verificar esto.
Uno de ellos es el sitio de verificación en línea dispuesto por Google:

También es posible utilizar servicios en línea con un análisis más detallados como el de IPv6 Test:

¿Qué debemos esperar a futuro?

A futuro debemos esperar un despliegue creciente de IPv6. Tanto en el ámbito corporativo como en el hogareño.

• Hace ya tiempo que se han agotado las direcciones IPv4 para seguir creciendo.
• El despliegue de IoE es una realidad que ya está instalada y sigue creciendo.
• El requerimiento de direccionamiento IP global es consecuentemente creciente.
• La respuesta para los requerimientos actuales de entonces IPv6.

Podemos discultir la velocidad con la que se realiza el despliegue, pero ya no es posible poner en dudas que se ha de hacer y que debemos ponernos en esta línea de trabajo.
Para quienes mayores precisiones sobre el crecimiento, hay un sitio que hace proyecciones para el despliegue de IPv6 a nivel global y por países. De acuerdo a vyncke.org el despliegue previsible para los próximos 2 años, a nivel global, es el siguiente:

Poner en dudas la implementación de IPv6 parece, entonces, un acto de ignorancia. La pregunta, creo, no es ya si IPv6 se implementará o no sino cuándo la implementaremos y si estamos listos para hacerlo.

Enlaces útiles:

• Estadísticas Google IPv6
• 6lab de Cisco
• Proyecciones de Vyncke.org
• Test IPv6 de Google
• IPv6 Test
• Bibliografía sugerida: Protocolo de Internet versión 6, v3.1
• Presentación: ¿Estás preparado para IPv6?

Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en

 el Glosario de Siglas y Términos de Networking

que está disponible en la Librería en Línea de EduBooks.

Conversión de configuraciones IOS a IOS XR (8)

Vamos a concluir por el momento esta serie de publicaciones referidas a IOS XR.
En este post voy a revisar algunos temas breves, que no por breves dejan de ser relevantes.


Conversión de listas de acceso

• En IOS XR no se diferencian listas de acceso numeradas y nombradas.
• No hay diferentes categorías (estándar y extendidas).
• Se soportan todas las keywords de IOS.

First Hop Redundancy Protocol

• IOS XR soporta la operación tanto de HSRP como VRRP.
• En IOS XR no se configura en la interfaz sino que se activa el protocolo en configuración global.

Configuración de las líneas de acceso
Los mecanismos por defecto son diferentes en IOS y IOS XR

• En IOS inicialmente se configura una clave de acceso simple en cada una de las líneas de acceso, sin necesidad de configurar usuario.
• En IOS XR se aplica AAA new model por defecto y por lo tanto no hay una clave en las líneas sino que se define usuario y clave y se asocia a un grupo de tareas (permisos).

Otros post sobre este tema:

• Conversión de configuraciones IOS a IOS XR (1): Prompt y modos del SO
• Conversión de configuraciones IOS a IOS XR (2): Interfaces y CEF
• Conversión de configuraciones IOS a IOS XR (3): Enrutamiento IP y OSPF
• Conversión de configuraciones IOS a IOS XR (4): Configuración de BGP 
• Conversión de configuraciones IOS a IOS XR (5): Traducción de route-maps
• Conversión de configuraciones IOS a IOS XR (6): Comandos no presentes en IOS XR
• Conversión de configuraciones IOS a IOS XR (7): Comandos similares
• Cisco IOS, IOS XE, IOS XR
• Cisco IOS, IOS XE, IOS XR
• Arquitectura de Cisco IOS XR

Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en

 el Glosario de Siglas y Términos de Networking

que está disponible en la Librería en Línea de EduBooks.