Mostrando entradas con la etiqueta IOS. Mostrar todas las entradas
Mostrando entradas con la etiqueta IOS. Mostrar todas las entradas

diciembre 29, 2016

Instalación de licencias en Cisco IOS 15.x


En Cisco IOS se distingue 2 tipos de licencias:

  • Licencias permanentes.
    Una vez instaladas son definitivas y no tienen vencimiento.
  • Licencias temporales.
    Pueden ser licencias demo o licencias compradas. En este caso su vigencia tiene un plazo de vencimiento.
Instalación de licencias permanentes

Router#license install fash:uck9-2900-SPE150_K9-FHH11253557.xml
  • Instala el archivo de licencias permanentes que ha sido descargado previamente a la memoria flash.
  • En este caso se instala una licencia permanente de comunicaciones unificadas en un router Cisco 2900.
Router#reload
  • Reinicia el dispositivo para hacer efectiva la instalación de la licencia permanente. Si la licencia de evaluación ya se encontraba activa antes, no es necesario el reinicio del dispositivo.
  • Las licencias permanentes son perpetuas y por lo tanto no les aplica el concepto de un período de validez.
  • Luego de reiniciado el dispositivo se sugiere verificar la instalación.
Router#show versión

License UDI:
------------------------------------
Device#  PID           SN           
------------------------------------
*0       CISCO2901/K9  FCG3467G5DX  
Technology Package License Information for Module:’c2900’
-------------------------------------------------------------
Technology   Technology-package      Technology-package
             Current     Type        Next reboot
-------------------------------------------------------------
ipbase       ipbasek9    Permanent   ipbasek9
security     None        None        None
uc           uck9        Permanent   uck9
data         None        None        None


Instalación de licencias de evaluación

Con la introducción de IOS 15.0(1)M las licencias de evaluación han sido reemplazadas con licencias RTU de evaluación. Para activar estas licencias se debe utilizar el siguiente procedimiento:

Router#license boot module c2900 technology-package uck9
  • Activa la licencia de comunicaciones unificadas de evaluación en el router Cisco 2900. Al ejecutar el comando se mostrará el contrato de acuerdo de uso que debe ser aceptado para que la licencia temporal se active.
  • Una vez instalada la licencia de evaluación o temporal, es necesario reiniciar el dispositivo.
  • Las licencias de evaluación tienen un período de duración de 60 días.
Router#show license
Index 1 Feature: ipbasek9
        Period left: Life time
        License Type: Permanent
        License State: Active, In Use
        License Count: Non-Counted
        License Priority: Medium
Index 2 Feature: securityk9
        Period left: Not Activated
        License Used: 0 minute 0 second
        License Type: EvalRightToUse
        License State: Not in Use, EULA not accepted
        License Count: Non-Counted
        License Priority: None
Index 1 Feature: uck9
        Period left: 8 weeks 3 days
        Period Used: 9 minutes 30 seconds
        License Type: EvalRightToUse
        License State: Active, In Use
        License Count: Non-Counted
        License Priority: Low


Tomado de: http://librosnetworking.blogspot.com/2016/11/instalacion-de-licencias-en-ios-15x.html

diciembre 06, 2016

Cómo Configurar VPN IPSec Site-to-Site en Cisco Router



En el artículo de hoy vamos a explicar cómo configurar una VPN (Virtual Private Network) Site To Site en Cisco IOS.

Primeramente, ¿qué es un VPN? 


Una VPN es una conexión virtual entre dos dispositivos que permite el envío de información de manera segura a través de un medio inseguro como lo es Internet. 

Con una VPN podemos desarrollar toda una infraestructura de red WAN (Wide Area Network) de forma más rápida y económica en comparación con la contratación del servicio de línea de fijas Frame Relay, ATM u otro tipo de tecnologías.

Nuestra configuración de VPN Site to Site es realizada utilizando el protocolo IPSec (Internet Protocol Security).  


IPSec es un protocolo de capa 3 del modelo OSI que permite desarrollar VPNs brindando las siguientes ventajas:
  • Confidentiality
  • Data integrity
  • Authentication
 
Confidentiality (confidencialidad) significa que la información enviada a través del VPN no podrá ser leída por un usuario o dispositivo tercero que no participe en la comunicación. En otras palabras, la información enviada por la VPN no podrá se accedida por ninguna entidad no autorizada. La confidencialidad se logra en la práctica a través de la implementación de técnicas de cifrado de datos. Para los no entendidos en la materia, el cifrado de información logra convertir un texto original en un formato no entendible (texto cifrado) para todo aquel que no conozca: (1) el algoritmo de cifrado y (2) la llave secreta. En IPSec podemos implementar cifrado de datos utilizando algoritmos simétricos tales como 3DES y AES.

Data integrity (Integridad de la información) significa que la información enviada entre dos dispositivos en una VPN debe de llegar tal cual fue enviada por el dispositivo emisor. En otras palabras, IPSec garantiza que la información, mientras esté en tránsito, no será modificada nivalterada. La integridad de la información en la práctica se logra a través de la implementación de técnicas de Hashing. Un Hash es una función matemática que no tiene inversa, por lo tanto, va partir del resultado no es posible —matemáticamente hablando — conseguir la información original. En IPSec podemos implementar Hashing utilizando algoritmos tales como MD5, SHA-1 y SHA-2.

Authentication (Autenticación) consiste en establecer mecanismos de seguridad para validar la identidad de los dispositivos envueltos en la transmisión de información a través de una VPN. En IPSec tenemos la opción utilizar diferentes mecanismos de autenticación como son: (1) Pre-share Key y (2) Digital Signature.

En la práctica, la implementación de IPSec como protocolo de VPN no es muy user-friendly. Requiere a priori un entendimiento muy detallado por parte del ingeniero de la intríngulis técnica de este protocolo que, de por sí, es complejo.

Una VPN IPSec requiere del establecimiento de dos túneles. El primero llamado IKE Phase 1 (Internet Key Exchange Fase 1) que es utilizado para que los routers se comuniquen directamente entre ellos. Este túnel no es utilizado para el envío de paquetes IP de los usuarios, sino más bien, para el intercambio información de control. Para que el túnel IKE Phase 1 pueda establecerse con éxito, ambos routers deben de estar de acuerdo en las siguientes variables:
  • Hash algorithm
  • Encryption algorithm
  • Diffie-Hellman DH group
  • Authentication method
  • Lifetime
 Después que ambos routers agotan con éxito la primera fase del IPSec — IKE Phase 1 —, sí y solo sí se establece la segunda fase — IKE Phase 2 — donde se establece el túnel por donde viaja la información de los usuarios de manera encriptada.



Entonces teniendo como trasfondo la información anterior, vamos a explicar cómo podemos configurar una VPN Site to Site entre dos routers Cisco utilizando IPSec. 

 Para hacer el proceso de configuración un poco más fácil de entender, vamos a dividir el proceso de configuración en dos etapas: (1) ISAKMP 1; (2) ISAKMP 2 tanto para R1 como para R2. A los túneles IKE también se les llama ISAKMP.



Vamos a comenzar con la configuración de R1.

IKE ISAKMP Phase 1


Paso 1: configuración de ISAKMP Policy.


R1(config)#crypto isakmp policy 1
R1(config-isakmp)#encr 3des
R1(config-isakmp)#hash md5
R1(config-isakmp)#authentication pre-share
R1(config-isakmp)#group 2
R1(config-isakmp)#lifetime 86400

Paso 2: definir la contraseña a utilizar entre los R1 y R2 como pre-share key.


R1(config)#crypto isakmp key cisco address 1.1.1.2

Paso 3: configuración de ACL


R1(config)# ip Access-list extended VPN-TRAFFIC
R1(config-ext-nacl)# permit ip 10.10.10.0 0.0.0.255 20.20.20.0 0.0.0.255

IKE ISAKMP Phase 2

Paso 4: configurando IPSec Transform


R1(config)# crypto ipsec transform-set TS esp-3des esp-md5-hmac

Paso 5: configuración de CRYPTO MAP


R1(config)# crypto map CMAP 10 ipsec-isakmp
R1(config-crypto-map)#set peer 1.1.1.2
R1(config-crypto-map)#set transform-set TS
R1(config-crypto-map)#match address VPN-TRAFFIC

Paso 6: aplicando Crypto MAP a una interface pública


R1(config)# interface Fastethernet 0/1
R1(config-if)#crypto map CMAP

El mismo procedimiento de configuración que aplicamos a R1 lo hacemos en R2 con ciertas modificaciones en cuanto a las direcciones IP.

Vamos a comenzar con la configuración de R2.

IKE ISAKMP Phase 1


Paso 1: configuración de ISAKMP Policy.


R2(config)#crypto isakmp policy 1
R2(config-isakmp)#encr 3des
R2(config-isakmp)#hash md5
R2(config-isakmp)#authentication pre-share
R2(config-isakmp)#group 2
R2(config-isakmp)#lifetime 86400

Paso 2: definir la contraseña a utilizer entre los R1 y R2 como pre-share key.


R2(config)#crypto isakmp key cisco address 1.1.1.1

Paso 3: configuración de ACL


R2(config)# ip Access-list extended VPN-TRAFFIC
R2(config-ext-nacl)# permit ip 20.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255

IKE ISAKMP Phase 2


Paso 4: configurando IPSec Transform

R2(config)# crypto ipsec transform-set TS esp-3des esp-md5-hmac

Paso 5: configuración de CRYPTO MAP

R2(config)# crypto map CMAP 10 ipsec-isakmp
R2(config-crypto-map)#set peer 1.1.1.1
R2(config-crypto-map)#set transform-set TS
R2(config-crypto-map)#match address VPN-TRAFFIC

Paso 6: aplicando Crypto MAP a una interface pública


R2(config)# interface Fastethernet 0/1
R2(config-if)#crypto map CMAP

Al aplicar esta configuración en R1 y R2 una VPN IPSec debe de funcionar perfectamente. Para comprobar que los paquetes IP provenientes de ambas redes LAN se envían a través del VPN debemos de ejecutar los siguientes comandos.

R1#ping 20.20.20.1 source FastEthernet 0/0
R1#show crypto session

Ahora en R2:

R2#ping 10.10.10.1 source FastEthernet 0/0
R2#show crypto session



Tomado de: http://blog.capacityacademy.com/2014/09/12/ccna-security-como-configurar-vpn-ipsec-site-to-site-en-cisco-router/

septiembre 06, 2016

Cisco IOS: ¿Que significado tiene el nombre?


Por Oscar Gerometta

Temario CCNA R&S 200-125

El nombre de las imágenes de IOS


Cisco utiliza una convención específica de nombres para la denominación de las imágenes de IOS en sus dispositivo. 

Esta convención nos permite, a partir del nombre por defecto (porque siempre es posible renombrar las imágenes), conocer algunas de sus características.

Un ejemplo:

C2900-universalk9-mz.SPA-152-4.M1.bin

Donde:
  • C2900
    Plataforma de hardware.
    Ej: Router Cisco 2900.
  • universalk9
    Conjunto de prestaciones.
    Ej: imagen única y universal
  • mz
    Formato del archivo.
    m = Se corre desde la RAM.
    z = Comprimido.
  • SPA
    Imagen de software firmada digitalmente.
  • 152-4.M1
    Versión.
    Ej: 15.2 (4)M1
  • bin
    Extensión del archivo.
    Ej: Archivo binario, ejecutable.
Recursos adicionales:
Tomado de: http://librosnetworking.blogspot.com/2016/08/el-nombre-de-las-imagenes-de-ios_72.html

agosto 16, 2016

Solucionado: Denegación de servicio en Cisco IOS XR


Cisco ha confirmado una vulnerabilidad en routers Cisco ASR 9001 Aggregation Services con Cisco IOS XR que podría permitir a un atacante remoto sin autenticar provocar condiciones de denegación de servicio.

El problema, con CVE-2016-6355, reside en el tratamiento inadecuado de paquetes fragmentados específicamente creados dirigidos al dispositivo afectado. 
Un ataque exitoso podría provocar una fuga de memoria en el procesador de rutas del dispositivo que provocaría la caída de los paneles de control de protocolo y la consiguiente condición de denegación de servicio.

El problema afecta a Cisco IOS XR versions 5.1.x, 5.2.x y 5.3.x, en routers Cisco ASR 9001 Aggregation Services.

Se ha solucionado en la versión de Cisco IOS XR 5.3.3, con las siguientes Software Maintenance Updates (SMUs):
  • asr9k-px-5.3.2.CSCux26791.pie para versiones 5.3.x
  • asr9k-px-5.2.4.CSCux26791.pie para versiones 5.2.x
  • asr9k-px-5.1.3.CSCux26791.pie para versiones 5.1.x

Más información:

Cisco IOS XR Software for Cisco ASR 9001 Aggregation Services Routers Fragmented Packet Denial of Service Vulnerability
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160810-iosxr


Antonio Ropero -  antonior@hispasec.com - Twitter: @aropero

agosto 24, 2015

Como configurar SSH en Cisco IOS

Implementación de SSH en Cisco IOS

Por Oscar Gerometta

La gestión remota de dispositivos de red es una práctica extendida y necesaria en el ámbito de la administración de la infraestructura de red.

La gestión remota implica un riesgo de seguridad: la información de configuración y monitoreo de los dispositivos circula en sesiones TCP atravesando diferentes secciones de red, muchas de las cuales no están bajo nuestro control y que por lo tanto han de ser consideradas inseguras. Sin embargo son muchos los que aún utilizan para esta tarea sesiones Telnet.

Telnet es un protocolo adecuado para la gestión remota de dispositivos pero inseguro. Las sesiones Telnet viajan por la red sin cifrar, y por lo tanto quien capture el tráfico de esas sesiones accederá no solo a la información de configuración sino también a las claves que ingresemos que estarán viajando por la red en texto plano.

Es por esto necesario implementar para estas tareas SSH.

Para poder implementar SSH se requieren dos condiciones básicas:

  • Que el sistema del dispositivo al que deseamos acceder soporte el servicio SSH.
    Cisco IOS hoy soporta SSH en todas sus imágenes, aún las conocidas como IP Base.
  • Contar con un cliente SSH.
    Esto también es posible ya que no sólo clientes licenciados, sino también otros de acceso libre (p.e. Putty y Tera Term) soportan SSH.

Habilitación de SSH en routers Cisco IOS

Los dispositivos Cisco IOS por defecto tienen habilitado el servicio de Telnet, no el de SSH. Por lo tanto, la utilización de SSH requiere de varios pasos de configuración:

1. Habilitar el servicio SSH.
Router(config)#hostname LAB
Router(config)#ip domain-name ccnp.com
Router(config)#crypto key generate rsa modulus 2048
    Genera una llave de cifrado RSA (en este caso de 2048 bits), que luego utilizará SSH.Para que se genere la llave de cifrado es necesario antes contar con hostname y nombre de dominio ya que son elementos utilizados para generar la llave.
Router(config)#username admin privilege 15 secret Clave_4A
    Crea un usuario de nivel 15, con su clave de acceso, que será luego utilizado por SSH.Dado que la clave está definida como secret, se guardará cifrada en el archivo de configuración.
Router(config)#ip ssh version 2
    Elige utilizar SSH versión 2 solamente para las conexiones remotas que se establezcan.
2. Dado que SSH requiere autenticación utilizando username y clave, hay que habilitar la autenticación local.

Router(config)#line vty 0 5
Router(config-line)#transport input ssh

    Define que el único protocolo para el acceso remoto utilizando terminal virtual es SSH.
Router(config-line)#login local
    Habilita la autenticación local utilizando las credenciales de usuario y clave que se definieron antes.
Router(config-line)#exit

3. Restringir el acceso exclusivamente desde un conjunto de direcciones IP específicas.

Router(config)#ip access-list standard SSH
Router(config-std-nacl)#permit 192.168.100.0 0.0.0.255
Router(config-std-nacl)#deny any log
Router(config-std-nacl)#exit
    Crea una lista de acceso estándar que sólo permite el paso de tráfico generado en la subred 192.168.100.0/24.
El resto del tráfico está denegado, y se guardará registro de los intentos rechazados.

Router(config)#line vty 0 5
Router(config)#access-class SSH in

    Aplica la ACL llamada SSH que se creó antes a los accesos por terminal virtual, limitando de esta manera a las direcciones IP de la red 192.168.100.0/24 el acceso por SSH al dispositivo.

Enlaces útiles:

Tomado de: http://librosnetworking.blogspot.com/

agosto 18, 2015

Mensajes de estado y eventos en Cisco IOS


Por Oscar Gerometta

Cuando trabajamos en la CLI de Cisco IOS interactuamos con una cantidad más o menos importante de mensajes del sistema operativo a los que genéricamente llamamos "mensajes de la consola".
 
En realidad la denominación de "mensajes de la consola" incluye indistintamente diferentes tipos de mensajes cuyo origen, propósito y significado son muy diferentes.

En principio hay que considerar 2 tipos de mensajes: 

  • Los mensajes de error que están referidos a situaciones generadas por el ingreso de comandos en el prompt de  IOS.
  • Los mensajes de estado y eventos, generados por cambios o actualizaciones en la operación de protocolos, interfaces, etc.
    En estos mensajes he de focalizarme en este post.

Los mensajes de estados y eventos

Los mensajes de eventos son generados por un sistema de notificaciones que permite que múltiples dispositivos en la red originen mensajes de estado con una estructura común y los almacenen (o no) en un dispositivo (servidor) centralizado para su posterior revisión por el Administrador.

En los dispositivos Cisco el sistema de mensajes de estado y eventos puede enviar estos mensajes a distintas posiciones:
  • A la pantalla de la consola (console).
  • A una sesión telnet o SSH (monitor).
  • A un servidor Syslog alojado en la red.
  • A un buffer de memoria local (buffered).
Los mensajes tienen un formato estándar:

*Dec 18 17:10:15.079: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
  • Un registro de tiempo (fecha y hora).
    Dec 18 17:10:15.079
  • La porción del dispositivo que genera el mensaje.%LINEPROTO
  • Nivel de severidad del mensaje:5
  • Clave nemotécnica.UPDOWN
  • Descripción del mensaje.Line protocol on Interface FastEthernet0/0...
Estos mensajes tienen 8 niveles de severidad diferentes:
  • 0 Emergency
  • 1 Alert
  • 2 Critical
  • 3 Error
  • 4 Warning
  • 5 Notification
  • 6 Informational
  • 7 Debugging
Los niveles 0 a 4 representan eventos que pueden tener serio impacto en la operación del dispositivo. 

El Administrador tiene la posibilidad de definir hasta qué nivel de severidad desea recibir mensajes en cada una de las diferentes posiciones (servidor, consola, etc.). Por ejemplo, almacenar hasta nivel 5 en el servidor de Syslog y recibir hasta nivel 7 en la terminal de consola.
 
Por defecto se envían todos los mensajes hasta nivel 7 al puerto de consola.

Configuración de los registros

Router(config)#service timestamps
Habilita la inclusión de fecha y hora en el encabezado de los mensajes.

Router(config)#service sequence-numbers
Habilita la inclusión de un número de secuencia en el encabezado de los mensajes.

Router(config)#logging on
Activa el proceso de logging.

Router(config)#logging buffered 200000
Determina el tamaño del buffer de memoria. Los mensajes almacenados en este buffer se pueden revisar con el comando show logging. El tamaño del buffer se establece en bytes. Por defecto, el tamaño es 4096 bytes y el nivel de severidad es debugging.

Router(config)#logging 172.16.1.2
Indica un servidor de syslog como destino para almacenar los mensajes.

Router(config)#logging trap warnings
Limita los mensajes enviados al servidor de syslog en base al nivel de severidad.
El nivel de severidad también puede expresarse en forma numérica, en este caso: 4.

Router(config)# terminal monitor
Envía los mensajes que por defecto sólo van a la consola, a las terminales virtuales.

Router(config)#logging monitor notifications
Limita los mensajes que se enviará a las terminales virtuales, en base al nivel de severidad.

Tomado de: http://librosnetworking.blogspot.com/

junio 28, 2015

Los 3 Principios de enrutamiento

En algunas secciones de este curso haremos referencia a tres principios relacionados con las tablas de enrutamiento que lo ayudarán a comprender, configurar y solucionar problemas de enrutamiento.

Estos principios se extraen del libro de Alex Zinin, Cisco IP Routing.

1. Cada router toma su decisión en forma independiente, según la información de su propia tabla de enrutamiento.

2. El hecho de que un router tenga cierta información en su tabla de enrutamiento no significa que los otros routers tengan la misma información.

3. La información de enrutamiento sobre una ruta desde una red a otra no suministra información de enrutamiento sobre la ruta inversa o de regreso.

¿Cuál es el efecto de estos principios? Observemos el ejemplo en la figura.
 
 
1. Después de tomar su decisión de enrutamiento, el router R1 envía al router R2 el paquete destinado a la PC2. R1 sólo conoce la información de su propia tabla de enrutamiento, que indica que el router R2 es el router del siguiente salto. R1 no sabe si R2 efectivamente tiene o no una ruta hacia la red de destino.

2. Es responsabilidad del administrador de red asegurarse de que todos los routers bajo su control tengan información de enrutamiento completa y precisa de manera tal que los paquetes puedan enviarse entre cualquiera de las dos redes. Esto puede lograrse mediante el uso de rutas estáticas, un protocolo de enrutamiento dinámico o una combinación de ambas opciones.

3. El router R2 logró enviar el paquete hacia la red de destino de la PC2. Sin embargo, R2 descartó el paquete desde la PC2 a la PC1. Aunque R2 tiene información en su tabla de enrutamiento sobre la red de destino de la PC2, no sabemos si tiene la información para la ruta de regreso hacia la red de la PC1.

Enrutamiento asimétrico

Dado que los routers no necesariamente tienen la misma información en sus tablas de enrutamiento, los paquetes pueden recorrer la red en un sentido, utilizando una ruta, y regresar por otra ruta. Esto se denomina enrutamiento asimétrico. El enrutamiento asimétrico es más común en Internet, que usa el protocolo de enrutamiento BGP, que en la mayoría de las redes internas.

Este ejemplo implica que cuando se diseña una red y se resuelven problemas en ella, el administrador de red debe verificar la siguiente información de enrutamiento:

¿Existe una ruta de origen a destino que esté disponible en ambos sentidos?

¿Es la ruta que se tomó en ambos sentidos la misma ruta?  (El enrutamiento asimétrico no es inusual, pero a veces puede causar otros problemas.)

Tomado de: https://cerebrote.wordpress.com/ con algunos aportes del editor del blog.

junio 01, 2015

Virtual Routing and Forwarding: Elementos básicos de VRF


Por Oscar Gerometta

Una tecnología sobre la que no se habla habitualmente es la implementación de VRFs (Virtual Routing and Forwarding). 

Se la suele vincular a la implementación de VPNs MPLS, donde es un recurso necesario, pero también es un recurso útil cuando debemos intercambiar rutas de múltiples redes diferentes sobre una misma infraestructura de enrutamiento, manteniendo las rutas de cada red totalmente independientes.

Por ese motivo me pareció adecuado dedicar un post al menos a los rudimentos de las VRFs.

Como se desprende de lo que dije antes, podemos utilizar VRFs para mantener múltiples instancias de enrutamiento de modo simultáneo en un único router. 

En este caso, cada instancia de enrutamiento es totalmente independiente, con su propia tabla de enrutamiento, sin interacción con el enrutamiento de otra instancias, lo que permite incluso que haya superposición de redes IP en una misma infraestructura sin que haya conflictos de direccionamiento.

Una VRF está definida por un conjunto de elementos específicos:

  • Un Nombre que la identifica localmente en el dispositivo y permite ingresar al modo de configuración de esa VRF específica.
  • Un Route Distinguisher que identifica dentro de una red las VRFs que componen la misma red virtual y que intercambian información de enrutamiento entre sí.
  • Un Exported Route Target que identifica a qué otra VRF dentro de la misma red se envía información de enrutamiento de esa VRF.
  • Un Imported Route Target que idendifica de qué otra VRF dentro de la misma red se aprende información de enrutamiento para esa VRF.
  • Un conjunto de interfaces asociadas a la VRF.

Elementos de configuración básica

Router(config)#ip vrf Prueba1
Router(config-vrf)#rd 1:10
Router(config-vrf)#route-target export 1:10
Router(config-vrf)#route-target import 1:10
Router(config-vrf)#exit
Router(config)#interface GigabitEthernet2
Router(config-if)#ip vrf forwarding Prueba1

Hay que tener presente que al incorporar o retirar una interfaz de una VRF se remueve automáticamente la configuración IP existente en la interfaz y se deberá configurar nuevamente según corresponda.

La tabla de enrutamiento

Al crear VRFs se habilitan diferentes instancias de enrutamiento en un mismo dispositivo, separadas lógicamente. Cada instancia de enrutamiento es completamente independiente y se mantiene una tabla de enrutamiento para cada instancia.

De esta manera, en un router que implementa VRFs se encuentran varias tablas de enrutamiento:

  • La tabla de enrutamiento global o de la infraestructura, en la que se mantienen las rutas propias de la infraestructura física.
    Se consulta utilizando el comando:
    Router#show ip route
  • Una tabla de enrutamiento independiente por cada VRF, en la que se encuentran exclusivamente las rutas de la red virtual a la que pertenece esa VRF.
    Su estructura es resultado del intercambio de información de enrutamiento con otras VRFs de la misma red virtual definido utilizando los comandos route-target.
    Se consulta utilizando el comando:
    Router#show ip route vrf Prueba1
El enrutamiento de cada VRF es completamente independiente, del mismo modo que el direccionamiento IP asociado a las interfaces y al enrutamiento. 

Por lo tanto cada VRF puede tener sus propias rutas estáticas o instancia de un protocolo de enrutamiento. La metodología de configuración del protocolo de enrutamiento en cada VRF cambia ligeramente según el protocolo del que se trate.

Adicionalmente, a nivel de la infraestructura se utiliza una instancia de MP-BGP para transportar la información de enrutamiento entre VRFs de diferentes routers que deben intercambiar información de enrutamiento.

Vea la forma de configurar en este video: https://www.youtube.com/watch?t=318&v=iw4BneMFG4U



Recursos:

Fuente: http://librosnetworking.blogspot.com/

mayo 26, 2015

Diagnóstico de interfaces en Cisco IOS


Por Oscar Gerometa

Hace ya algún tiempo que me solicitaron un esquema de diagnóstico del estado de las interfaces en dispositivos Cisco IOS.

Si bien el proceso de diagnóstico de una situación o dispositivo no es fruto exclusivamente de un procedimiento pre-definido sino que depende en mucho de la experiencia y conocimientos de quien lo realiza, creo que es posible revisar el conjunto de herramientas que ofrece Cisco IOS para el diagnóstico de interfaces de routers de un modo relativamente ordenado.

Lo que elaboro a continuación es un esquema personal, que pretende ordenar un proceso de diagnóstico genérico del estado de interfaces de un router Cisco que utiliza Cisco IOS 15.4 y al que se está accediendo remotamente. En cada comando he agregado el enlace para revisar el comando en la command guide para que quienes quieran profundizar en él puedan hacerlo en la fuente misma.

show ip interface brief

A mi modo de ver, el primer comando de diagnóstico a ejecutar cuando se está accediendo remotamente a un equipo es show ip interface brief.

Este comando nos permite requerir al sistema operativo una tabla sintética que nos permite visualizar de modo rápido y sencilo el estado de cada una de las interfaces que tiene configuración IP:


En un dispositivo operativo:

  • La columna IP-Address nos muestra la dirección IP configurada en cada interfaz.
  • La columna OK? debe indicarnos YES. La leyenda NO indica que se ha asignado a la interfaz una dirección IP inválida.
  • La columna Method indica el método a través del cual se ha obtenido la configuración IP de la interfaz: NVRAM refiere al archivo de configuración almacenado en la NVRAM, manual indica que ha sido cambiada la dirección IP utilizando configuración por CLI, DHCP refiere que la interfaz está configurada como cliente DHCP y ha obtenido dirección por ese método.
  • La columna Status muestra el estado de las interfaces (up | down | administratively down). Para estar operativa la interfaz debiera aparecer como up.
  • La columna Protocol indica que la interfaz se encuentra operativa a todo nivel.
En condiciones de operación, el comando debiera mostrarnos up/up todas las interfaces en uso, y como administratively down las interfaces que no se encuentran en uso.

Enlace de referencia: aquí.

Si una interfaz aparece como down/down, es posible que tenga inconvenientes a nivel de capa física. Es por esto que para diagnosticar adecuadamente necesitamos revisar capa física.

show controllers

Este comando nos permite revisar la información referente a hardware y software de la interfaz, y consecuentemente el estado físico de la misma.

La información que brinda este comando es variable de acuerdo al tipo de interfaz de la que se trate (Ethernet, FastEthernet, GigabitEthernet, Serial, etc.)

Es un comando con abundante información que generalmente es requerido en solicitudes de soporte a Cisco TAC. Sin embargo, nos brinda información útil también a nosotros, p.e., en interfaces seriales permite verificar si hay cable conectado y si el mismo es DCE o DTE, el clockrate que utiliza, el estado de la interfaz, etc.

Enlace de referencia: aquí.

show interfaces

En interfaces que se encuentran operativas permite visualizar el estado y estadísticas de operación de las interfaces.

Este comando permite verificar: estado de la interfaz, tipo de hardware que utiliza, dirección MAC, dirección IP y máscara de subred, parámetros de operación (MTU, BW, etc.), protocolo de encapsulación, y estadísticas de tráfico tanto entrante como saliente. El resultado específico y los parámetros que se muestran dependen de la configuración y tipo de interfaz.



Este comando lo utilizamos específicamente para, además de verificar el estado de la interfaz, verificar la actividad de la misma utilizando los contadores de paquetes y bytes que nos permiten corroborar la actividad que hay sobre la misma y la tasa y tipo de errores.

Enlace de referencia: aquí.

show interfaces accounting

Este no es más que un subcomando del comando anterior.
 

Si lo que necesitamos es verificar actividad de tráfico entrante y saliente a través de las interfaces, este es un comando que muestra de modo sintético la actividad de tráfico entrante y saliente a través de cada interfaz del dispositivo.



Las interfaces que no se encuentran operativas muestran la leyenda is disabled.

show ip interfaces

Este comando nos permite verificar, además del estado y dirección IP de la interfaz, la configuración y operación de la misma: proxy ARP, ICMP, presencia o no de ACLs asociadas, implementación de políticas, o de CEF, etc. 


Enlace de referencia: aquí.

Sintetizando:


  • Revisar el estado de las interfaces utilizando show ip interface brief.
  • Si alguna interfaz está down / down, verificar la operación a nivel de capa física utilizando show controllers.
  • Si una interfaz está up / down, verificar la operación la operación a nivel de capa de enlace y capa de red utilizando show interfaces.
  • Si las interfaces se encuentran up / up, verificar el flujo de tráfico y la tasa de errores utilizando show interfaces o show interfaces accounting.
  • Ante dificultades en la operación de la interfaz, verificar el modo de operación y la configuración utilizando show ip interface.
En términos generales, verifique el estado de las interfaces utilizando show ip interface brief según lo que indiquen las columnas status y protocol:
  • administratively down / down - la interfaz no ha sido habilitada administrativamente. Requiere no shutdown para ser operativa.
  • down / down - posible problema a nivel de la capa física. Inicie verificando la interfaz utilizando show controllers.
  • up / down - Posible problema a nivel de capa de enlace de datos o de red puede comenzar utilizando show interfaces.
  • up / up - La interfaz se encuentra operativa, verifique la existencia de tráfico a través de la interfaz utilizando show interfaces o show interfaces accounting.
  • Si la interfaz está operativa y persisten los problemas de comunicación, verifique la operación de la interfaz utilizando show ip interface.
Vea el video de este post en el canal de YouTube de LibrosNetworking


 

Fuente: http://librosnetworking.blogspot.com/

mayo 11, 2015

La tabla de enrutamiento en Cisco IOS


http://librosnetworking.blogspot.com.ar/2015/05/la-tabla-de-enrutamiento-en-cisco-ios.html

Por Oscar Gerometta

En Cisco IOS la información de enrutamiento se incorpora en la tabla de enrutamiento (básicamente una base de datos de información de enrutamiento) utilizando varios procedimientos diferentes:
  • Redes Locales (L)
    * Identifican las direcciones IP asignadas a las interfaces del propio dispositivo.
    * Las rutas locales IPv4 poseen máscara de subred /32, las rutas locales IPv6 tienen prefijos /128.
    * Las rutas locales tienen una distancia administrativa de cero.
    * Se utilizan para procesar los paquetes que tienen como destino interfaces del mismo dispositivo. Estas rutas no son redistribuidas.
    * Si la interfaz deja de estar operativa, esta ruta es removida automáticamente de la tabla.
  • Redes directamente conectadas. (C)* Identifican el segmento de red directamente conectado a cada interfaz del dispositivo.
    * El origen de la información es el segmento de red directamente conectado a las interfaces del dispositivo.
    * Si la interfaz deja de ser operativa la red asociada es removida automáticamente de la tabla de enrutamiento. Su distancia administrativa es 0 y son preferidas a cualquier otra ruta.
  • Rutas estáticas. (S)* Son ingresadas manualmente por el Administrador de la red.
    * Su distancia administrativa por defecto es 1.
  • Rutas dinámicas.* Son rutas aprendidas automáticamente a través de del intercambio de información con dispositivos vecinos generado por los protocolos de enrutamiento.
    * Estas rutas se modifican automáticamente en respuesta a cambios en la red.
Cisco IOS construye la tabla de enrutamiento utilizando un algoritmo para seleccionar la mejor ruta a cada destino conocido, a partir de los siguientes 2 parámetros: la distancia administrativa y la métrica.


Cuando se encuentras múltiples rutas de igual origen (igual distancia administrativa) e igual métrica , por defecto Cisco IOS incorpora hasta 4 rutas en la tabla de enrutamiento.