viernes, 25 de diciembre de 2015

Licencias en Cisco IOS

Hay una pregunta muy frecuente que es hecha por usuarios tanto principiantes como expertos, ¿por qué mi router/switch no acepta el comando?

El IOS de Cisco comenzó en las versiones 8, saltó a la 12 y siguió su evolución hasta las presentes 15 y comienzan a salir algunas versiones 16. En esas primeras etapas, el almacenamiento y la memoria de ejecución eran limitadas por un tema principalmente económico, al abaratarse el almacenamiento y la memoria RAM, fue posible incluir mas características en una versión.

Con las versiones 12 se tenían licencias de diferentes niveles, cada una contenía un conjunto de diferentes tecnologías que el usuario podía utilizar, y que por tanto permitía que el dispositivo aceptara o no ciertos comandos que podían no estar incluídos en la versión.
Los diferentes niveles eran algo así:
  • IP Base
    • IP Voice
      • Advanced Security
      • SP Services
      • Enterprise Base
        • Advanced IP Services
        • Advanced Enterprise
          • Advanced Enterprise Services

Con las versiones 15, Cisco migró a un IOS versión Universal, lo que significa que el IOS contiene todos los comandos y tecnologías disponibles para esa plataforma en particular, pero que son activados o desactivados de acuerdo a la licencia instalada en el equipo.

Un ejemplo muy frecuente son los Switches Catalyst 4500 que utilizan software IOS XE, (lo que les permite ser equipos multiprocesador y ejecutar las funciones del equipo en procesos separados, lo cual les da una mayor estabilidad ante posibles fallas o errores). El IOS XE usualmente viene con licencias IP BASE, y por tanto al ejecutar EIGRP sólo se érmite el modo stub, lo que limita la funcionalidad del ruteo al comunicar sólo rutas locales, conectadas o sumarizadas en el router, y muy frecuentemente los usuarios creen que es un problema del equipo porque no reenvía información que recibió de otros vecinos.

Este pequeño inconveniente se resuelve adquiriendo e instalando la licencia de IP Services, o se puede hacer una solución parcial al utilizar un leak-map de EIGRP para permitir ciertas rutas.

Hay mucha información en Cisco sobre las licencias, como instalarlas, como utilizar versiones de prueba y como adquirirlas.

Pero a veces también es necesario saber, este router o switch ¿hacen lo que yo necesito? por ejemplo, ¿pueden correr FlexVPN?, ¿soportan túneles de GRE?. Para esto se puede utilizar el Feature Navigator, seleccionamos la plataforma, versión y licenciamiento que tenemos y nos dirá que tecnologías incluye; o al revés, seleccionamos la tecnología y nos dirá en que dispositivos se soporta, con que versiones y en que licenciamiento.

Un ejemplo de esto es el soporte de GRE, casi todos los usuarios dan por sentado que un dispositivo que tiene un comando tunnel es porque soporta túneles de GRE, pero en los switches 3750 no es una tecnología soportada, viene en el software, pero activarla podría causar problemas en el dispositivo.

Así que, utilicen también esta información para referencia cuando planeen una red, o cuando un problema de capacidad en los equipos se presente, no siempre es un tema de error en el hardware o software, también podría ser un tema de licencias o capacidades en los routers o switches.

martes, 17 de marzo de 2015

Servicios IP (network services)

De la lista de temas a evaluar en el examen de CCIE, tenemos los servicios IP (5.3 Network services), en este artículo veremos algunos, son temas muy extensos que sólo menciono brevemente porque es importante conocerlos, pero que no son tan importantes como para explorarlos a fondo; pero son configuraciones que se deben dominar, ya que son temas comunes en cualquier red, comenzaermos con una configuración básica de DHCP en el router Green2, configurando el ip helper address en el Green1 para poder asignarle una IP al router dhcp_client. Usaré la topología anterior, simulando un ISP que nos provee de conexión mediante MPLS entre el PE1 y el PE2, estando esta parte de la red "oculta" a nuestros routers de la VRF Green.
Los servicios son: DHCP, NTP, SNMP, Syslog, WCCP, Netflow, Cisco IOS Embedded Event Manager, Remote Monitoring, FTP, TFTP y SCP en un router, acceso http, https, telnet y ssh, y por último IP SLA.

DHCP

Primero en dhcp_client desactivamos el ruteo (para simular un host), habilitamos un puerto con la configuración de cliente de dhcp, configuramos el router con el ip helper, es decir, le indicamos la dirección IP que tiene el servicio de DHCP, en este caso es la loopback 100 del router Green2, y en este último configuramos el servicio de DHCP, indicando la red,  el default gateway que se debe asignar a los clientes, así como el dominio y el servidor de DNS; es importante también configurar las direcciones IP que no queremos que sean asignadas con este servicio:
documento en cisco.com

DHCP_client#

no  ip routing
!
interface Ethernet0/1
 ip address dhcp
 no ip route-cache

martes, 10 de marzo de 2015

Configuración de MPLS parte 4, ruteo entre ISP (PE) y cliente (CE)

Ya que hicimos las VRF para cada cliente y sus correspondientes etiquetas, así como la comunicación entre los diferentes PE, haremos la comunicación de las rutas entre el cliente y el ISP, y la correspondiente redistribución hacia mBGP a fin de propagar las rutas entre los sitios del cliente.

Ambos clientes tienen las mismas redes a fin de demostrar que las VRF hacen posible el escenario entre clientes; por lo que utilizaremos loopback interfaces diferentes en cada router y las asignaremos  a diferentes protocolos de ruteo, probando así que existe la separación.


Desde del lado del cliente no hay nada especial:

blue1#sh runn | beg router
router eigrp 10
 network 10.11.0.0 0.0.0.7
 network 11.0.0.1 0.0.0.0
!
router ospf 10
 network 10.11.0.0 0.0.0.7 area 0
 network 11.0.0.2 0.0.0.0 area 1
!
router rip
 version 2
 passive-interface default
 no passive-interface Ethernet0/0
 no passive-interface Loopback103
 network 10.0.0.0
 network 11.0.0.0
 no auto-summary

lunes, 9 de marzo de 2015

Configuración de MPLS parte 3, las VRF

Comenzaremos con una breve explicación de qué es una VRF, y como las identificamos.
Una VRF (virtual routing and forwarding) es una instancia virtual y separada de la instancia global de ruteo en el dispositivo; es decir, es casi como tener un segundo router corriendo sus propios procesos de ruteo, independientes de cualquier otro presente en el dispositivo.

El uso más común y que simularemos en el ejemplo, es el que los proveedores de servicio utilizan para conectar a sus clientes con MPLS, configurando redes privadas virtuales que separan el tráfico de los clientes en instancias separadas de los demás clientes por medio de las etiquetas de ruteo. los routers que tenemos dentro del ISP les llamaremos P (provider), a los del borde de la red del ISP les llamaremos PE (provider edge) a los del cliente CE (customer edge)

Esta separación se logra con la configuración de la VRF primero, declarando su nombre, y después utilizando etiquetas para poder separar esa información de los demás procesos. Dichas etiquetas son muy parecidas a las que utilizamos en LDP para MPLS, pero en este ejemplo utilizaremos el formato "extendido". Dichas etiquetas son utilizadas en el encabezado de las rutas, por lo que cualquier vecino de mBGP que reciba dichas rutas etiquetadas podrá instalarlas en sus propias VRF conforme a lo que se le indica en la configuración.

Entre otros beneficios, tener una VRF nos permite la duplicación de direcciones IP entre diferentes clientes, es decir, podríamos tener a dos clientes diferentes utilizando las redes 10.0.0.0/16 sin problemas, ya que las rutas se procesas basadas en las etiquetas.

Basados en estas etiquetas indicaremos cuál es la que identifica localmente a nuestra VRF y compartiremos dicha información con nuestro vecino de mBGP , comunicando así que por ejemplo, la VRF X está dentificada por el Route Distinguisher Y:Z, y que necesitamos que exporte esa información hacia mBGP y que desde ahí importe las etiquetas que necesitamos para comunicar dos sitios de un mismo cliente. También agregaremos una familia de direcciones a BGP que comunique el ruteo entre ambos PE para la VRF de cada cliente.

Cuando activamos una nueva instancia o VRF, el router puede ejecutar sus propios procesos de BGP, OSPF, RIP, ISIS, etc. y los utilizaremos para intercambiar rutas entre el cliente y el ISP, logrando que el cliente nos entregue la información de sus redes y nosotros la llevemos a los demás sitios del mismo cliente, estableciendo así una red privada con comunicación basada en MPLS. También indicaremos en cada interface a que VRF queremos que pertenezca.

IMPORTANTE: cuando asignas una interface a una VRF, se borra la configuración de la interface y deberemos volver a indicar la IP y demás características deseadas en dicho puerto.



Los routers P (2, 3 y 4) no requieren configuración adicional.

Ejemplo de los routers PE con dos clientes, las compañías blue y green que tienen un sitio cada una conectados ambos al PE 1, y dos sitios conectados al PE2:

viernes, 6 de marzo de 2015

Configuración de MPLS parte 2, mBGP

Después de que hemos configurado el intercambio de etiquetas de MPLS, sigue activar mBGP a fin de poder intercambiar información de ruteo entre diferentes sistemas autónomos, dándonos la funcionalidad de poder comunicar dichos sistemas con cierta privacidad y aislando el tráfico en diferentes instancias, comenzando así con el servicio de una red privada virtual o VPN.

Lo primero es activar BGP en los routers 1 y 5, establecer su vecindad y configurar el tipo de instancia que queremos utilizar, en este caso VPNv4:

R1
router bgp 99
 bgp log-neighbor-changes
 neighbor 5.5.5.5 remote-as 99
 neighbor 5.5.5.5 update-source Loopback1
 !
 address-family vpnv4
  neighbor 5.5.5.5 activate
  neighbor 5.5.5.5 send-community extended
 exit-address-family

R5
router bgp 99
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 99
 neighbor 1.1.1.1 update-source Loopback1
 !
 address-family vpnv4
  neighbor 1.1.1.1 activate
  neighbor 1.1.1.1 send-community extended
 exit-address-family

Configuración de MPLS parte 1, las etiquetas

Los routers Cisco tienen varias tablas que intervienen en la manera de reenviar un paquete, básicamente los procesos de ruteo se encargan de establecer opciones, seleccionar las mejores rutas e instalarlas en la tabla de ruteo global (RIB routing information base) y así tener opciones para ir a distintas redes.
Cuando las métricas son iguales (o similares si así nos interesa) se puede balancear el tráfico entre distintas rutas posibles.
Un inconveniente de la tabla de ruteo es que revisar la dirección de destino de un paquete contra la tabla es un proceso secuencial que ocupa mucha memoria, por lo que a través de CEF se construye una tabla de reenvío (FIB forwarding information base); este proceso es más rápido porque construye una tabla en la que se registran las direcciones de destino y las interfaces que nos llevan ahí, haciendo un proceso de conmutación o IP switching que es más eficiente para reenviar un paquete.
Lo siguiente es MPLS, que construye una tabla de etiquetas relacionando las redes que conocemos por distintos medios con números asignados localmente y remotamente, construyendo una tabla LIB (label information base) que reenvía el tráfico de manera más eficiente; ésto es porque el router recibe un paquete con un encabezado adicional que incluye las etiquetas de MPLS y que le indican por medio de la etiqueta el destino al que se dirige el paquete, se lee la etiqueta, se consulta la LIB, se quita la etiqueta de entrada, se coloca una etiqueta de salida (o se quitan todas si ha llegado a su destino) y se reenvía el paquete, todo sin consultar la tabla de ruteo o RIB.
El proceso de ruteo se encarga de mantener la LIB actualizada en cuanto a las distintas rutas disponibles, haciendo más eficiente el proceso de intercambiar rutas, y así mismo, el de transmitir tráfico.
Haremos un pequeño ejercicio de como configurar una MPLS con 5 routers contiguos, todos corriendo el proceso de OSPF 1 y todos con una loopback interface con máscara de 32 bits:


Descarga aquí las configuraciones completas de este laboratorio.