23 de julio de 2015

Implementación de SSH en Cisco IOS

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:

20 de julio de 2015

Caso, incidente, problema

Al momento de enfrentar un inconveniente en la operación de la red es necesario comenzar por identificar el nivel de complejidad del problema; no todas las situaciones tienen la misma complejidad, consecuencias y gravedad. Es por esto preciso diferenciar algunas categorías básicas:
  • Caso.
    Se da la denominación de caso a un incidente operativo que afecta la operación normal de la red, que ha sido detectado a partir del monitoreo regular de la operación y cuya resolución escapa a las tareas regulares de mantenimiento.
    El caso puede surgir de problemas en la operación de la red y se inicia independientemente de su alcance y posibilidad de afectación a la operación de los clientes.
    Por lo general los casos se documentan y se reportan a una instancia técnica de soporte interna o externa para su análisis y resolución.
    Denominamos caso, por ejemplo, al hecho de que en un sector específico de la red se detecte un problema de enrutamiento que hace que la red no se comporte del modo esperado. Verificada la situación y debidamente documentada, el caso se eleva a la instancia correspondiente para su análisis y respuesta.
  • Incidente.
    Un incidente es un problema puntual reportado por un usuario en particular. Los incidentes son ocasionales y generalmente reportados por los usuarios requiriendo soporte de parte del proveedor de servicio.
    Téngase en cuenta que si bien el incidente se define a partir de un usuario en particular, si el mismo es causado por alguna falla de la red en su operación el mismo puede ser reportado por múltiples usuarios de modo concurrente. En este caso se trata de un incidente de tipo masivo y el análisis de esta concurrencia es parte del proceso de análisis.
    Son ejemplos de incidentes, por ejemplo, la dificultad de un usuario particular para levantar una VPN, o el reporte de falta de conectividad a Internet.
  • Problema.
    Con el término problema se identifica a un acontecimiento en la infraestructura de la red que afecta al desempeño de la misma. El problema puede corresponderse o estar relacionado o no con incidentes reportados de los usuarios, pueden afectar la performance (no la conectividad) y en algunos casos puede ser superado sin que el usuario lo perciba claramente.
    Ejemplos de problemas de la red puede ser la inestabilidad de un enlace de transporte o la salida de servicio de un dispositivo colocado de manera redundante.
Otros post relacionados:
Bibliografía asociada:

9 de julio de 2015

Direcciones IPv6 link local

IPv6 es un protocolo completamente diferente de su predecesor, IPv4. Diferente no sólo en la longitud de las direcciones que utiliza (128 bits en total) sino en múltiples aspectos. Uno de ellos: en una misma interfaz pueden encontrarse múltiples direcciones IP simultáneamente.
Uno de los motivos de esta multiplicidad de direcciones es que en IPv6 hay diferentes direcciones de unicast: direcciones unicast globales, direcciones unicast unique local y direcciones unicast link local (sobre estos diferentes tipos sugiero revisar el post "Tipos de direcciones IPv6").

Las direcciones IPv6 link local
Una de las tantas innovaciones que introduce IPv6 son estas direcciones: toda interfaz que implementa IPv6 tiene al menos una dirección asignada, la dirección de link local.
Las direcciones de link local pertenecen a un rango específico definido por el prefijo FE80::/10 (1111 1110 10xx xxxx/10).
La porción de nodo o identificador de interfaz de estas direcciones puede obtenerse por configuración manual o automáticamente. Para la asignación automática aplican 2 procedimientos:
  • EUI-64, utilizado principalmente para la asignación en interfaces de dispositivos de infraestructura.
    Es el implementado por IOS.
  • RFC 3014, utilizado preferentemente en interfaces de dispositivos terminales.
    Es el implementado en sistemas de escritorio como Microsoft o Mac OS X.
Son direcciones utilizadas para el establecimiento de comunicaciones entre interfaces alojadas en el mismo segmento de red (dominio de broadcast) identifican a la interfaz únicamente dentro del enlace al que se encuentra conectada.
Aseguran la operación de múltiples protocolos aún antes de que la interfaz tenga asignada una dirección IPv6 global unicast o unique local. Por este motivo se utilizan en procesos de configuración automática, descubrimiento de vecinos, etc. Son utilizadas para identificar los neighbor de los protocolos de enrutamiento y el próximo salto en la tabla de enrutamiento.
No son ruteables. Los paquetes que tienen una dirección de link local como origen o destino no deben ser reenviados por los dispositivos de capa 3.

Sintetizando
  • Estas direcciones se configuran automáticamente siempre que el protocolo IPv6 esté habilitado en la interfaz, sin necesidad del operador.
  • Pueden ser definidas estáticamente.
    Router(config-if)#ipv6 address FE80::1 link-local
  • Son accesibles solamente dentro del mismo segmento de red.
  • Solamente responden ping desde interfaces en el mismo segmento de red.
  • Se pueden verificar utilizando los comandos show habituales.
    Router#show ipv6 interface
    Router#show ipv6 interface brief
  • Se utilizan para la operación de múltiples procesos como stateless configuration, enrutamiento dinámico y NDP (Neighbor Discovery Protocol).
Enlaces de referencia
Bibliografía sugerida

Siglas, siglas y más siglas

Los que trabajamos en el ámbito de las tecnologías Cisco estamos acostumbrados a lidiar con siglas: EIGRP, CDP, OSPF, NDP, IP, TCP, etc., etc. Algunas propias, otras no, las siglas son parte de nuestra realidad diaria.
Se dice que Cisco Systems es una de las organizaciones que más siglas utiliza en el mundo, y esto hace suponer que debiéramos estar habituados a las mismas. Pero en los últimos tiempos estamos recibiendo una nueva lluvia de conjuntos de letras ya no referidas directamente a protocolos o tecnologías, sino al entorno de aplicación de las mismas, y que debemos comenzar a dominar pues posiblemente convivamos con ellas por muchos años, y por eso me pareció conveniente revisar algunas de ellas:
  • MtoM
    Machine to Machine.
    Alude a comunicaciones digitales establecidas directamente entre dos dispositivos o máquinas.
  • HtoH
    Human to Human.
    Refiere a las comunicaciones clásicas en sentido amplio, establecidas entre dos personas.
  • MtoH
    Machine to Human.
    Referencia a comunicaciones digitales establecidas entre un dispositivo o máquina y una persona.
  • IoT
    Internet of Things.
    Concepto enunciado por Kevin Ashton del MIT que refiere al momento en el que se conecten a Internet más objetos que personas.
    Alude básicamente a una red basada en comunicaciones MtoM.
  • IoE
    Internet of Everything.
    Concepto impulsado por Cisco Systems que busca una visión más amplia que el de IoT y que apunta a una Internet en la que objetos, procesos y personas se comunican entre sí de modos diversos para el intercambio de información en formato digital: MtoM, HtoH, MtoH.
  • IdT
    Internet de Todo.
    Versión en castellano de IoE (no confundir con IoT).
  • IdC
    Internet de las Cosas.
    Versión en castellano de IoT.
  • IT
    Information Technology.
    Conjunto de tecnologías implicadas en el intercambio de información en formato digital.
  • OT
    Operation Technology.
    Conjunto de technologías digitales aplicadas a procesos de producción y gestión.
  • TIC
    Tecnologías de la Información y las Comunicaciones.
    Corresponde a la sigla en inglés ITC (Information Technology and Communications).
  • TEC
    Tecnologías de Enseñanza y Comunicación.
  • TAC
    Tecnologías de Aprendizaje y Comunicación.

28 de junio de 2015

Configuración de SVIs en switches Catalyst



¿Qué es una SVI?

Cuando ingresamos en el mundo de los switches capa 3 uno de los primeros conceptos que se incorporan es el de SVI (Switch Virtual Interface).

¿Qué es una SVI?
Se trata de una interfaz virtual, no vinculada a ningún puerto físico del dispositivo, que opera como una interfaz completa (incluyendo capa 3) de salida de una VLAN.
Típicamente una SVI es el default gateway de las terminales que forman parte del dominio de broadcast definido por una VLAN. Proporciona posibilidades de procesamiento en capa 3 a los paquetes que tienen origen o destino en puertos que son parte de la VLAN, en consecuencia es posible configurar la mayoría de los features vinculados a capa 3 de los puertos de los routers (dirección IP, ACLs, etc.) en estas interfaces.

¿Para qué utilizaría una SVI?
Estas interfaces virtuales tienen múltiples aplicaciones, entre las principales podemos mencionar:
  • Proporcionar en los switches capa 3 un interfaz que pueda operar como gateway de la VLAN, permitiendo de este modo enrutar tráfico hacia y desde las VLANs sin necesidad de un router.
  • Permitir el bridging de VLANs en el caso de protocolos no ruteables.
  • Posibilitar la conectividad de capa 3 en los switches (como en los switches LAN, donde se utiliza una SVI para definir la IP de gestión).
  • Soportar la configuración de protocolos de enrutamiento.

SVIs en Cisco IOS
  • Los switches Catalyst (tanto capa 2 como capa 3) presentan una interfaz SVI creada por defecto que es la interfaz VLAN1. Dado que la VLAN 1 es por defecto la VLAN de gestión en switches Catalyst, esta es la interfaz en la que se ingresa la configuración IP necesaria para el acceso por Telnet, SSH, HTTP y HTTPS.
  • El comando interface vlan [ID] permite crear una SVI asociada a la VLAN cuyo ID se aplica, e ingresar al modo de configuración de esa interfaz.
  • Se realiza un mapeo uno a uno entre VLANs y SVIs ,por lo tanto cada SVI puede estar asociada a una única VLAN, y cada VLAN puede asociarse a una única SVI.
Para que una SVI (la interfaz) se muestre como up/up es necesario que:
  • La VLAN exista y esté activa en la base de datos de VLANs del switch.
  • Que la interfaz VLAN no se encuentre administratively down (por defecto en IOS están en este estado).
  • Exista al menos un puerto (de acceso o troncal) activo y en estado de STP forwarding sobre esa VLAN
Configuración de una SVI
  • Identifique a qué VLAN desea dotar de un gateway.
  • Si no existe la VLAN en el dispositivo, créela (puede utilizar el comando show vlan brief para verificar esto).
  • Cree la SVI con el comando interface vlan [ID].
  • Habilite administrativamente la interfaz.
  • Asigne la configuración IP necesaria a la interfaz.
  • Asegúrese que el enrutamiento IP se encuentre habilitado en el dispositivo.
  • Si es necesario, configure el protocolo de enrutamiento deseado.
Una vez creadas las SVIs pueden monitorearse con los comandos de monitoreo de interfaces regulares, como por ejemplo show ip interfaces brief.

Switch#configure terminal
Switch(config)#vlan 10
Switch(config-vlan)#exit
Switch(config)#interface vlan 10
Switch(config-if)#no shutdown
Switch(config-if)#ip address 172.16.1.1 255.255.255.0
Switch(config-if)#exit
Switch(config)#ip routing

Enlace de referencia:


5 de junio de 2015

Enrutamiento IP en entornos con VRFs

Cuando implementamos VRFs podemos diferencias, en principio, 2 redes que están operando e interactuando entre sí:
  • La red de servicios que es la que opera brindando conectividad entre extremos distantes. Este es el rol esencial de la red del Proveedor de Servicios clásico.
  • La red cliente que es la red dispersa que necesita interconectar puntos remotos a través de la red de servicios. Si bien en la gráfica de más abajo representé una única red cliente para mayor claridad, sobre una red de servicio pueden conectarse múltiples redes cliente diferentes sin que ocurran superposiciones de ningún tipo.
Cada una de estas redes tienen su propio dominio de enrutamiento, completamente independiente. Para que todo esto funcione hay que considerar 3 dominios de enrutamiento diferentes:
  • El dominio de enrutamiento de la red cliente que utiliza un protocolo de enrutamiento para gestionar las rutas de la red cliente. Típicamente es un IGP (RIPv2, EIGRP, OSPF), pero también es posible que utilice BGP.
  • El dominio de enrutamiento de la red de servicios que utiliza un protocolo de enrutamiento interior para gestionar las rutas de la red de servicios. Típicamente encontramos en este caso OSPF, EIGRP o IS-IS.
  • El dominio de enrutamiento BGP de la red de servicios que utiliza un address-family vpnv4  para transportar las rutas de la red cliente a través de la red de servicios.
Para que BGP pueda transportar las rutas de la red cliente es necesario que se redistribuyan las rutas de la red cliente dentro de un address-family asociado a la VRF de la red cliente, del mismo modo que las rutas del address-family luego deben ser redistribuidas dentro de la VRF.
De esta forma, el transporte de rutas de la red cliente sobre la red de servicios puede ser representado de la siguiente manera:
Consecuencias de esto:
  • Las rutas de la red cliente solamente se encuentran en la tabla de enrutamiento de las VRFs y los CEs. Nunca se incorporan a la tabla de enrutamiento de la red de servicios (PEs y Ps).
  • Las rutas de la red de servicios nunca se mezclan con las rutas de las VRFs.
  • Cuando hay múltiples VRFs en un mismo PE, las rutas de cada VRF se mantienen independientemente unas de otras.
  • En el router P nunca se encuentran rutas de las redes cliente.