4 de diciembre de 2021

WiFi6 y más allá

 El jueves 2 de diciembre desarrollé una ponencia titulada "WiFi6 y más allá" en la 1° Jornada de tecnologías de comunicación, Oruro, diciembre 2021.

En esta ponencia hago una síntesis de las novedades técnicas introducidas por el estándas IEEE 802.11ax y algunas de sus consecuencias a futuro que considero interesantes. Por esto pongo a disposición de todos la presencación que utilicé en el desarrollo de la ponencia.


Estás invitado a participar de nuestro grupo en Facebook
https://www.facebook.com/groups/librosnetworking/

O si preferís redes sociales con mayor control de tu privacidad,
podés participar de nuestro grupo en VKontakte
https://vk.com/libros.networking

o seguir las principales novedades en el grupo de Telegram:
https://t.me/LibrosNetworking



Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.


16 de noviembre de 2021

Network Associate (CCNA 200-301)

    • Gracias al acuerdo alcanzado entre Educática y Ediciones EduBooks, finalmente está disponible mi curso íntegramente grabado en video: Network Associate. Un curso no oficial que abarca el temario completo del examen de certificación CCNA 200-301.

      El curso toma como base el Apunte Rápido CCNA 200-301 versión 7.1 que publiqué el mes de febrero pasado, está completamente desarrollado en castellano, consta de más de 45 horas de video on demand que abarcan el temario e incluyen demostraciones de cada uno de los laboratorios que propongo en la Guía de Laboratorios CCNA 200-301 versión 7.1.

      La información detallada es la siguiente:

      Prerrequisitos:

      • Este entrenamiento no tiene pre-requisitos para los participantes.

      Metodología:

      • Desarrollo asincrónico.
        El alumno estudia en sus propios tiempos accediendo a las clases según vaya avanzando.
        Cada uno puede diseñar su propio plan de estudio.
      • Temario teórico presentado en clases grabadas en video disponibles en línea, siguiendo el desarrollo del Apunte Rápido CCNA 200-301.
      • Temario práctico presentado en videos en modo demostración, en línea, siguiendo el desarrollo de la Guía de Laboratorios CCNA 200-301.
      • Laboratorios desarrollados sobre Packet Tracer.
        El planteo permite utilizar, según disponibilidad personal, de maquetas implementadas sobre dispositivos físicos, emulados con sistemas como GNS3 o Eve-ng o simuladores. Las demostraciones en video están desarrolladas sobre Packet Tracer.
      • Consultas por correo electrónico a requerimiento del alumno.

      Calendario:

      • Cada alumno hace su propio calendario de clases y revisa las clases grabadas a su propio ritmo.

      Materiales de estudio:

      Cada inscripto recibe:

      Materiales accesibles en línea:

      • Temario y detalles del curso (pdf).
      • Índice de videos disponibles (Excel).
      • Videos de desarrollo teórico.
      • Videos demo de laboratorios.
      • Archivos Packet Tracer con topologías de la Guía de Laboratorios.
      • Materiales complementarios en diferentes formatos.
      • Cuestionarios de repaso al final de cada capítulo.
      Si deseás revisar una demo de los videos que componen el curso, podés ver este video en el canal de YouTube: https://youtu.be/D89rBbiTw2I

      Temario:

      1. Principios y operación de redes TCP/IP
      2. Direccionamiento IP (IPv4/IPv6)
      3. Operación de dispositivos Cisco IOS
      4. Conmutación LAN
      5. Fundamentos de redes inalámbricas
      6. Enrutamiento IP
      7. Servicios IP
      8. Tecnologías WAN
      9. Introducción a la seguridad
      Podés revisar el video de presentación aquí.

      Modelos de suscripción

      • Suscripción individual
        Acceso irrestricto a la plataforma para una persona por el término de 180 días corridos.
        USD 100
      • Paquete corporativo 5
        Acceso irrestricto a la plataforma para hasta 5 personas por el término de 180 días corridos.
        USD 400 
      • Paquete corporativo 10
        Acceso irrestricto a la plataforma para hasta 10 personas por el término de 180 días corridos.
        USD 800 
      • Paquete corporativo 20
        Acceso irrestricto a la plataforma para hasta 20 personas por el término de 180 días corridos.
        USD 1500 
      • Paquete corporativo +20
        Acceso irrestricto a la plataforma para más de 20 personas por el término de 180 días corridos.
        USD 1500 y USD 70 por cada persona adicional a las 20 iniciales.

      Información para la inscripción

      Para ampliar la información disponible o adquirir una suscripción, podés hacerlo de modo directo a través del catálogo de cursos de Educática: https://www.educatica.com.ar/nuestros-cursos.

      Por consultas sobre formas de pago, formas alternativas de inscripción y otros temas, podés contactar por correo electrónico con Ediciones Edubooks: libros.networking@gmail.com


      Estás invitado a participar de nuestro grupo en Facebook:
      https://www.facebook.com/groups/librosnetworking/

      O si preferís redes sociales con mayor control de tu privacidad,
      podés participar de nuestro grupo en VKontakte
      https://vk.com/libros.networking

      o seguir las principales novedades en el grupo de Telegram:
      https://t.me/LibrosNetworking



      Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
      que está disponible en la Librería en Línea de EduBooks.



      8 de noviembre de 2021

      Guía de Laboratorios CCNA 200-301 versión 7.1

       Ya está disponible la Guía de Laboratorios CCNA 200-301 versión 7.1. Se trata de una colección  de ejercicios prácticos diseñados pensando en quienes preparan el examen de certificación Cisco CCNA 200-301 y que en muchos casos están iniciándose en el universo del networking y los dispositivos Cisco. 

      Por otro lado, la Guía de Laboratorios está concebida como un complemento del Apunte Rápido CCNA 200-301 versión 7.1.
      El Apunte Rápido desarrolla el temario teórico del examen de certificación, la Guía de Laboratorios complementa esa exposición teórica con ejercicios prácticos que permiten una mejor comprensión de las tecnologías y la fijación de conocimientos.

      ¿Esto significa que ahora el examen de certificación incluye ejercicios de laboratorio? No.
      El examen de certificación sigue igual, en los formatos de preguntas que se incluyen no hay ejercicios simulados que requieran configurar o diagnosticar fallos. Pero eso no quita que quienes buscan aprender puedan recurrir a las técnicas del "hacer" para revisar lo aprendido y fijar conocimientos.
      Y por otra parte, si bien no hay ejercicios simulados en el examen muchas preguntas "teóricas" requieren conocimientos de configuración y capacidad de análisis de resultados de la línea de comandos.

      Dado que este manual es un complemento del Apunte Rápido CCNA 200-301, en su organización he mantenido la misma división de temas que en aquel manual. Claro que, como no todos los temas teóricos tienen un correlato práctico la Guía de Laboratorios presenta una singularidad en la numeración de los capítulos: no es correlativa sino que responde a la numeración de los capítulos del Apunte Rápido CCNA.

      Contenidos:

      Introducción
      2. Direccionamiento IPv4/IPv6
          Lab 2.1 - Verificación de dirección IP asignada a un host
          Ejercicios de cálculo de subredes
      3. Operación de dispositivos Cisco IOS
          Lab 3.1 - Introducción a la línea de comandos de IOS
          Lab 3.2 - Aseguramiento del acceso a la gestión
          Lab 3.3 - Configuración básica del router
          Lab 3.4 - Implementación y monitoreo de CDP
          Lab 3.5 - Implementación y monitoreo de LLDP
      4. Conmutación LAN
          Lab 4.1 - Configuración inicial de un switch Catalyst
          Lab 4.2 - Operación del switch
          Lab 4.3 - Configuracion de VLANs y troncales
          Lab 4.4 - Configuración de router on stick
          Lab 4.5 - Configuración de una topología activa STP
          Lab 4.6 - Configuración y verificación de EtherChannel
          Lab 4.7 - Configuración de HSRP
      5. Fundamentos de WLAN
          Lab 5.1 - Configuración de los puertos del switch
          Lab 5.2 - Acceso a la interfaz gráfica del WLC
          Lab 5.3 - Configuración de una WLAN con WPA2 PSK
      6. Enrutamiento IP
          Lab 6.1 - Configuración inicial de un router Cisco
          Lab 6.2 - Configuración de rutas estáticas
          Lab 6.3 -Configuración básica de IPv6
          Lab 6.4 - Configuración de enrutamiento IPv6 estático
          Lab 6.5 - Configuración y verificación de OSPF
      7. Servicios IP
          Lab 7.1 - Configuración de listas de control de acceso
          Lab 7.2 - Direccionamiento IP asignado por el proveedor
          Lab 7.3 - Configuración de NAT
          Lab 7.4 - Configuración de protocolos para el monitoreo y la gestión
      9. Introducción a la seguridad
          Lab 9.1 - Aseguramiento de dispositivos
          Lab 9.2 - Seguridad en dispositivos capa 2

      Páginas: 205
      Fecha de publicación: 5 de noviembre de 2021
      Autor: 
      Oscar A. Gerometta
      CCSI / CCNA / CCDA / CCNA wir / CCNA sec / CCNP sec / CCBF
      Docente y consultor con una trayectoria de más de 20 años en el área de networking. Autor de los primeros manuales en castellano para la preparación del examen de certificación CCNA que ha mantenido a lo largo de estos años.
      Texto:
      Colección de ejercicios prácticos que abarcan la totalidad del temario del examen de certificación CCNA 200-301.
      No incluye desarrollos teóricos (estos se encuentran en el Apunte Rápido CCNA 200-301).
      Cada capítulo propone la conformación de una maqueta para el desarrollo de los ejercicios que puede armarse con dispositivos físicos, emulados o con un simulador. El desarrollo tiene en cuenta como punto de partida Packet Tracer versión 8.0.

      Para la compra:
      La Guía de Laboratorios CCNA 200-301 versión 7.1 está disponible en formato e-book e impreso en papel, y se puede adquirir en línea ingresando al sitio de Ediciones Edubooks.

      Para revisar las características de los ebooks de EduBooks ingresar aquí.
      Para revisar las características de los impresos adquiridos en línea ingresar aquí.

      Para alternativas de pago u otras consultas diríjase directamente a Ediciones EduBooks por correo electrónico escribiendo  a libros.networking@gmail.com

      Para facilitar la compra de ebooks desdeBolivia
      contactar a: libros.networking.bolivia@gmail.com


      Como siempre, cualquier sugerencia que puedas hacer, será muy bien venida.

      Referencias:


      Estás invitado a participar de nuestro grupo en Facebook:https://www.facebook.com/groups/librosnetworking/

      O si preferís redes sociales con mayor control de tu privacidad,
      podés participar de nuestro grupo en VKontakte: https://vk.com/libros.networking

      o seguir las principales novedades en el grupo de Telegramhttps://t.me/LibrosNetworking



      Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
      que está disponible en la Librería en Línea de EduBooks.



      9 de agosto de 2021

      ¿Qué es Netflow?

       En los últimos años ha ganado relevancia, de modo creciente, una herramienta muy particular: NetFlow.
      Originalmente creada para monitorear comunicaciones individuales, hoy es una herramienta utilizada para el análisis tanto de prestaciones de calidad de servicio como de seguridad.
      Es por esto que consideré conveniente preguntarnos, ¿qué es NetFlow?

      NetFlow es una herramienta de monitoreo desarrollada por Cisco e introducida en las diferentes formulaciones de IOS a partir del año 1996 (Cisco IOS 11.x). Esta herramienta permite relevar información estadística referida al tráfico en la red cuando ingresa o sale a través de una interfaz.
      Si bien inicialmente estaba incorporada en la imagen de IOS solamente de algunos dispositivos, progresivamente se ha incorporado a nuevas plataformas de modo que en la actualidad, en redes que utilizan IOS XE, está disponible prácticamente en toda la infraestructura de la red corporativa.
      Responde a 2 premisas básicas:
      • Es completamente transparente a las aplicaciones y dispositivos que operan en la red.
      • No es necesario que sea soportada en todos los dispositivos de la infraestructura de la red.
      Su implementación tiene múltiples aplicaciones posibles, las más frecuentes son:
      • Registro estadístico de tráfico para realizar un análisis de línea base.
      • Facturación de servicios de red a usuarios.
      • Monitoreo y análisis del tráfico y aplicaciones que están corriendo en la red.
      • Diseño general de seguridad de la red.
      • Detección y prevención de ataques DoS o DDoS.
      • Monitoreo de tráfico malicioso en la red.
      Con este propósito NetFlow releva estadística de comunicaciones utilizando el concepto de flujo (flow).
      ¿Qué es un flujo? Un stream o cadena unidireccional de paquetes entre un sistema de origen y un sistema destino específicos que es identificada tomando como base de referencia 7 parámetros específicos:
      • Dirección IP origen.
      • Dirección ID destino.
      • Puerto TCP o UDP de origen.
      • Puerto TCP o UDP de destino.
      • Tipo de protocolo (campo del encabezado IP).
      • Tipo de servicio (campo del encabezado IP).
      • Interfaz lógica de ingreso.
      Esta misma definición de flujo se aplica a tráfico IPv4 e IPv6.
      A esta información básica se puede agregar información complementaria a partir de NetFlow versión 9. Los registros NetFlow solo contienen información estadística, no contenido de los paquetes.

      Estos datos se exportan como registros de NetFlow hacia un servidor que concentra esos datos y en donde se analizan.
      El registro de una comunicación se genera cuando una comunicación TCP llega a su fin, o por un contador de inactividad de la comunicación, o se puede definir por configuración que periódicamente se genere el registro aún cuando la comunicación no ha terminado. 
      Transporte de los registros
      Los registros de NetFlow se transportan utilizando segmentos UDP que suelen estar dirigidos al puerto 2055 del collector, pero que también puede utilizar otros puertos. 
      El dispositivo que genera los registros, en general, no retiene los datos correspondientes a los registros que se envían al collector. Esto no permite realizar un seguimiento del transporte de los registros con lo que, si se produjera la pérdida de algún segmento, no se puede recuperar la información.
      Por este motivo algunas implementaciones de NetFlow utilizan SCTP para asegurar el envío de los registros. Particularmente cuando se trata de NetFlow versión 8 o 9.
      El inconveniente de este tipo de implementaciones es que se requiere interacción entre cada exporter y cada collector definido; esto puede tener un impacto significativo en la performance de ambos componentes.

      Arquitectura de NetFlow
      La implementación de NetFlow supone una arquitectura específica:
      • Exporter
        Uno o varios dispositivos que tienen Netflow habilitado.
      • Collector
        Una consola que recolecta y concentra la información.
      • Aplicación de análisis
        Aplicación que procesa los datos generados por el exporter y concentrados en el collector para obtener información significativa.
        Cisco StealthWatch es un ejemplo de este tipo de aplicaciones.

      Versiones de NetFlow

      Desde su lanzamiento NetFlow ha tenido diferentes versiones.
      La versión implementada en los dispositivos Cisco actuales es NetFlow v9. Adicionalmente, la herramienta se abrió con múltiples RFCs de la IETF, lo que dio lugar a IPFIX: 
      • RFC 3954 - NetFlow versión 9.
      • RFC 5101 - Especificación del protocolo de IPFIX para el intercambio de información de flujo de tráfico.
      • RFC 5102 - Modelo de información para IPFIX.
      • RFC 5103 - Exportación bidireccional usando IPFIX.
      • RFC 5153 - Directrices para la aplicación de IPFIX.
      • RFC 5470 - Arquitectura de IPFIX.
      • RFC 5471 - Pautas para las pruebas de IPFIX.
      • RFC 5472 - Pertinencia de IPFIX.
      NetFlow es una marca registrada de Cisco.
      Pero muchos otros fabricantes han desarrollado herramientas semejantes que cumplen la misma tarea:
      • Argus 
      • Jflow o cflowd de Juniper Networks
      • NetStream de 3Com/HP
      • NetStream de Huawei Technologies
      • Cflowd de Nokia
      • Rflow de Ericsson
      • AppFlow de Citrix
      • sFlow implementado por varios fabricantes: Alcatel Lucent, Allied Telesis, Arista Networks, Brocade, Dell, D-Link, Enterasys, Extreme, F5, Fortinet, Hewlett-Packard, Hitachi, Huawei, IBM, Juniper, LG-Ericsson, ZTE, ZyXEL, etc.


      Estás invitado a participar de nuestro grupo en Facebook:

      https://www.facebook.com/groups/librosnetworking/

      O si preferís redes sociales con mayor control de tu privacidad,
      podés participar de nuestro grupo en VKontakte
      https://vk.com/libros.networking

      o seguir las principales novedades en el grupo de Telegram:
      https://t.me/LibrosNetworking


      Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
      que está disponible en la Librería en Línea de EduBooks.

      30 de julio de 2021

      Introducción a Cisco TrustSec

      En los últimos años las redes corporativas han comenzado a migrar hacia una arquitectura de red definida por software (SDN).
      Cisco ha formulado, en este sentido, sus propuestas SD Access y SD WAN.
      SD Access es una propuesta de arquitectura completa, definida por software, que integra un conjunto importante de tecnologías que permiten dinamizar y automatizar la operación de la red para dar lugar a una red que responda rápida y flexiblemente a los objetivos institucionales de las organizaciones.
      Entre los múltiples aspectos que consideran estas implementaciones tiene un lugar sumamente importante la seguridad. En este sentido, la propuesta SD Access de Cisco integra TrustSec.
      TrustSec es una solución de seguridad presentada por Cisco hace ya más de 15 años y que se ha ido desarrollando e integrando en los diferentes dispositivos de infraestructura que ofrece Cisco Systems.

      TrustSec es un mecanismo diseñado por Cisco que permite segmentar dinámicamente el tráfico de la red organizando los dispositivos terminales en diferentes grupos lógicos.
      La asignación de terminales a un grupo no se realiza tomando como base su direccionamiento IP o pertenencia a una VLAN en particular sino a partir de decisiones de gestión alineadas con los requerimientos del negocio y las políticas de seguridad definidas. Esto facilita la gestión de la seguridad y brinda una mayor flexibilidad independizando la implementación de políticas de la pertenencia o no a una determina sección de la infraestructura (subred o VLAN).
      Cuando un usuario o dispositivo se conecta a la red, es esta (la red) la que le asigna un grupo de seguridad específico. Este mecanismo se denomina clasificación.
      La idea básica ha sido balancear los requerimientos de seguridad y la agilidad en la gestión, al tiempo que se reduce drásticamente la cantidad de reglas necesarias para conseguir el mismo resultado.
      Para este propósito se asiga a cada trama que circula dentro de la red una etiqueta (SGT - Security Group Tag) que identifica su correspondencia con un determinado grupo. Esta etiqueta se utiliza luego para permitir o bloquear ese tráfico en diferentes puntos de la red (con la condición que los dispositivos soporten TrustSec).

      La etiqueta de grupo (SGT)
      Denominamos etiqueta a un ID que es un número unico que representa la pertenencia del dispositivo a un grupo específico. Cada etiqueta tiene un nombre asociado (SG Name) y un valor.
      Por ejemplo, un usuario que cumple el rol de empleado tiene asociada una etiqueta con un valor arbitrario (p.e. “100”) y un nombre (p.e. “empleado”). Cuando un dispositivo con soporte TrustSec recibe una trama con esa etiqueta (101), aplica las políticas de filtrado definidas para ella.
      Estas etiquetas se insertan en el encabezado de la trama Ethernet entre la dirección MAC de origen y en campo Ethertype. Si se trata de tráfico 802.1Q, la etiqueta TrustSec se inserta entre la etiqueta 802.1Q y el campo Ethertype. 
      Para esto se implementa un encabezado propietario denominado CMD (Cisco Meta Data). Este encabezado está compuesto por varios campos; un campo Ethertype con el valor 0x8909 y un campo valor SGT de 16 bits de longitud que representa el valor de la etiqueta.

      Estas etiquetas pueden ser administradas de modo centralizado por un servidor ISE en una implementación 802.1X. En esta implementación los dispositivos de la red consultan periódicamente a ISE para tener información de las asignaciones de etiquetas y políticas SGT.
      La etiqueta SGT es una representación de los privilegios que se asigna al tráfico generado por un determinado grupo de usuarios o dispositivos.

      Para implementar TrustSec es necesario ejecutar 3 acciones: Clasificar el tráfico, propagar las etiquetas y forzar o aplicar las políticas.

      Clasificación
      Cuando una trama ingresa a través de un dispositivo de acceso, a la red, se identifica como perteneciente a un grupo determinado. Esta asignación del tráfico como perteneciente a un grupo específico puede realizarse de 2 modos:
      • Dinámicamente
        La clasificación dinámica tiene lugar cuando se trata de un usuario o terminal que accede a la red auténticandose por IEEE 802.1X. Cisco ISE nos permite utilizar diferentes mecanismos de autenticación: 802.1X, MAB o web authentication.
        En este caso, cuando el dispositivo ingresa a la red, como consecuencia de la autenticación el servidor RADIUS lo identifica como perteneciente a un grupo específico y le asigna vía política de autorización la etiqueta SGT correspondiente que luego será aplicada al mismo switch o controlador inalámbrico de acceso.
        Esta etiqueta se descarga al dispositivo de acceso y queda asociada a la IP y MAC del usuario o dispositivo.
      • Estáticamente
        Se aplica en aquellos casos en los que no hay autenticación de usuario o dispositivo.
        En estos casos la etiqueta SGT se puede asignar a una VLAN, o a un puerto, o a una IP o perfil de puerto.
        En estos casos la etiqueta se aplica a cualquier dispositivo que esté conectado a ese puerto o asociado a esa VLAN.
        Esto permite asignar etiquetas a tráfico generado en dispositivos que no implementan 802.1X, como es el caso de servidores en un data center. 
      Propagación
      La red deben propagar las etiquetas que se asignan desde el punto en que se realizó la clasificación hasta los equipos que implementan las políticas (“enforcement“). Para esta propagación se utilizan 2 métodos:
      • Inline tagging
        El dispositivo mismo marca con la etiqueta al ingreso de la trama al puerto. En este caso SGT está integrado en el marco de Ethernet y requiere soporte de hardware.
        Los dispositivos que no están en capacidad de realizar etiquetado en línea utilizan SXP.
      • SXP (SGT eXchange Protocol)
        Los dispositivos intercambian entre sí la información de las etiquetas. Para esto se establecen relaciones Speaker-Listener entre pares para realizar el intercambio.
        La información que se intercambia es el mapeo IP-SGT; esto permite que la propagación de etiquetas se mantenga a lo largo de la ruta.
      Aplicación
      Cuando el tráfico marcado con etiqueta llega a un dispositivo de "enforcement" el tráfico de usuario puede ser permitido o bloqueado en función de la etiqueta que porta.
      Para esto se compara la etiqueta de origen con la etiqueta que corresponde a la IP destino para determinar si el tráfico se debe permitir o bloquear.
      Esta implementación de políticas se puede realizar en dispositivos (routers o switches) que soporten la implementación de SGACL (Security Group ACL) y firewalls que soporten la implementación de políticas de filtrado de tráfico (incluyendo inspección profunda) en base a SGT. 
      De esta manera el tráfico se permite o bloquea en función de su pertenencia a un determinado grupo de seguridad y no en base a su dirección IP o pertenencia a VLAN.




      Estás invitado a participar de nuestro grupo en Facebook:

      https://www.facebook.com/groups/librosnetworking/

      O si preferís redes sociales con mayor control de tu privacidad,
      podés participar de nuestro grupo en VKontakte
      https://vk.com/libros.networking

      o seguir las principales novedades en el grupo de Telegram:
      https://t.me/LibrosNetworking


      Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
      que está disponible en la Librería en Línea de EduBooks.

      6 de julio de 2021

      Configuración avanzada 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 autenticar y 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 que el sistema operativo del dispositivo al que deseamos acceder soporte el servicio SSH. Cisco IOS hoy soporta SSH en todas sus imágenes. 
      La otra condición, es 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. 

      Configuración básica del servicio SSH
      La configuración básica del servicio SSH para el acceso de gestión es un procedimiento ampliamente difundido y por lo tanto, se supone conocido.

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

      * Prerequisitos

      Router(config)#hostname LAB 
      Router(config)#ip domain-name ccnp.com 
      Router(config)#crypto key generate rsa modulus 2048 
      • Genera un par de llaves de cifrado RSA (en este caso de 2048 bits de longitud), que luego utilizará SSH.
        Para que se genere el par de llaves de cifrado es necesario antes contar con hostname y nombre de dominio ya que son elementos utilizados para su generación. 
      Router(config)#username admin privilege 15 secret Clave_4A 
      • Crea un usuario con privilegios de nivel 15 en la base de usuario locales, con su clave de acceso (Clave_4A), que será luego utilizado por SSH.
        Dado que la clave de usuario está definida como "secret", se guardará cifrada utilizando MD5 en el archivo de configuración, no en texto plano.
        Este usuario y clave puede tener diferentes usos en la operación del dispositivo; en este caso lo utilizaremos específicamente para autenticar el acceso a la gestión remota.
      Router(config)#ip ssh version 2
      • Elige utilizar SSH versión 2 solamente para las conexiones remotas que se establezcan. 
        Por defecto IOS lo ejecuta en modo compatibilidad, es decir, admite conexiones SSHv1 y SSHv2.
      * Activación de la autenticación en líneas virtuales con SSH

      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

      * 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.
      Soporte SSH en IOS XE 17
      • Cualquier imagen de IOS con soporte de cifrado estándar es compatible con servicios y clientes SSH estándar.
      • IOS incluye tanto un cliente como un servicio SSH.
      • Tanto el cliente como el servidor soportan SSH versión 2.
      • La generación de claves RSA es requisito del lado del servidor SSH.
      • La longitud del par de claves RSA debe ser, como mínimo, igual o superior a 768 bits. La práctica recomendada de seguridad hoy es que sea de 2048 bits.
      • No se soporta reenvío de puertos ni compresión.
      Algoritmos de SSH para la operación
      El servicio SSH incluido en IOS XE admite varios algoritmos de cifrado que, en principio, negocia dinámicamente con el cliente en el momento de establecer la sesión. Los algoritmos de cifrado soportados son:
      • ESS128-CTR
      • AES192-CTR
      • AES256-CTR
      • AES128-CBC
      • 3DES-CBC
      • AES192-CBC
      • AES256-CBC
      Para la autenticación el servicio de SSH de IOS admite:
      • HMAC-SHA1
      • HMAC-SHA1-96
      Respecto a los algoritmos de manejo de llaves de cifrado, los soportados son:
      • X509v3-SSH-RSA
      • SSH-RSA
      En la implementación por defecto los algoritmos se negocian dinámicamente entre cliente y servidor iniciando la negociación por los primeros que incluí en cada lista y luego avanzando en sentido descendente hasta alcanzar una coincidencia.

      Respecto del cliente SSH incluido en IOS, los algoritmos de cifrado soportados son los siguientes, en orden descendente de preferencia.
      • ESS128-CTR
      • AES192-CTR
      • AES256-CTR
      • AES128-CBC
      • 3DES-CBC
      • AES192-CBC
      • AES256-CBC
      Los algoritmos de autenticación soportados por el cliente SSH, en orden de preferencia decreciente, son:
      • HMAC-SHA1
      • HMAC-SHA1-96
      El cliente SSH de IOS soporta solamente un algorimo de llaves de cifrado que es SSH-RSA.

      Selección de algoritmos criptográficos por configuración
      Por defecto IOS negocia dinámicamente entre cliente y servidor los algoritmos criptográficos a utilizar.
      Sin embargo, este comportamiento puede ser modificado por configuración de manera tal de especificar un algoritmo de cifrado específico.

      Para fijar el algoritmo de cifrado soportado por el servicio SSH, la configuración es la siguiente:

      Router#configure terminal
      Router(config)#ip ssh server algorithm encryption aes128-ctr 3des-cbc
      • Establece un grupo específico de algoritmos de cifrado soportados para la conexión con el servidor SSH y un orden de preferencia. En este ejemplo se intenta en primer lugar utilizar AES128-CTR y, si el cliente no lo soporta, entonces 3DES-CBC.
        Si se incluye un único algoritmo, entonces no hay negociación y solo se puede utilizar ese algoritmo en el cliente.
        Se debe especificar al menos un algoritmo.
      Para definir los algoritmos de cifrado que se utilizarán en el cliente SSH de IOS, la configuración es la siguiente:

      Router#configure terminal
      Router(config)#ip ssh client algorithm encryption aes128-ctr 3des-cbc
      • Establece un grupo específico de algoritmos de cifrado soportados para conexión iniciadas con el cliente SSH de IOS y el orden de preferencia. En este ejemplo se intenta en primer lugar utilizar AES128-CTR y, si el cliente no lo soporta, entonces 3DES-CBC.
        Si se incluye un único algoritmo, entonces no hay negociación y solo se pueden establecer conexiones con servidores SSH que soporten ese algoritmo.
        Se debe especificar al menos un algoritmo.
      Para fijar el algoritmo utilizado para el intercambio de claves de autenticación, en el servidor, el comando es el siguiente:

      Router#configure terminal
      Router(config)#ip ssh server algorithm mac hmac-sha1
      • Establece en el servicio SSH HMAC-SHA1 como algoritmo para la negociación de claves. Si se especifica más de uno, el orden indica el orden de preferencia de los mismos.
        Se debe indicar al menos un algoritmo.
      Si se desea fijar el algoritmo utilizado en la autenticación por el cliente SSH de IOS, el comando es el siguiente:

      Router#configure terminal
      Router(config)#ip ssh client algorithm mac hmac-sha1
      • Establece HMAC-SHA1 como algoritmo para la negociación de claves en el cliente SSH de IOS. Si se especifica más de uno, el orden indica el orden de preferencia de los mismos.
        Se debe indicar al menos un algoritmo.
      Si lo que se desea es fijar el algoritmo de cifrado que se utiliza en la generación de llaves de cifrado en el servicio SSH (el cliente SSH de IOS solamente soporta llaves SSH-RSA, por lo que no hay posibilidad de modificar esa opción) el comando a utilizar es:

      Router#configure terminal
      Router(config)#ip ssh server algorithm hostkey x509v3-ssh-rsa
      • Establece en el servicio SSH X509v3-SSH-RSA como algoritmo para la generación de llaves de cifrado a utilizar en la sesión SSH. Si se especifica más de uno, el orden indica el orden de preferencia de los mismos.
        Se debe indicar al menos un algoritmo.


      Estás invitado a participar de nuestro grupo en Facebook:

      https://www.facebook.com/groups/librosnetworking/

      O si preferís redes sociales con mayor control de tu privacidad,
      podés participar de nuestro grupo en VKontakte
      https://vk.com/libros.networking

      o seguir las principales novedades en el grupo de Telegram:
      https://t.me/LibrosNetworking


      Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
      que está disponible en la Librería en Línea de EduBooks.

      2 de julio de 2021

      Alta disponibilidad en switches Cisco

      Los switches modulares implementan una variedad de módulos entre los que destacan 2 tipos principales: los módulos supervisores y los módulos de interfaces. Los módulos supervisores son el corazón del funcionamiento de los dispositivos ya que son los encargados de mantiener el procesamiento central de los mismos y sin ellos los dispositivos estarían fuera de línea.
      Es por esto, de suma importancia la implementación no solo de redundancia, sino también de alta disponibilidad a nivel de estos módulos. No solo es importante contar con un respaldo para poder mantener la operación, sino también asegurar que ese respaldo se encuentre en línea y cuente con toda la información necesaria para asumir la tarea inmediatamente de modo tal de evitar cortes de servicios.
      En este aspecto, los módulos supervisores redundantes pueden configurarse en diferentes modos para asegurar la alta disponibilidad. 
      El modo de redundancia adoptado afecta la forma en que las placas supervisoras se comunican y sincronizan entre sí.
      • Lo módulos supervisores se pueden configurar en varios modos diferentes.
      • El modo de redundancia define el estado de preparación del módulo de respaldo para asumir la operación.
      • SSO es el mecanismo para sostener el reenvío ininterrumpido de Cisco.

      • RPR
        El módulo supervisor de respaldo se inicia solo parcialmente.
        Cuando el módulo activo falla el módulo de respaldo debe recargar los demás módulos del switch y a continuación inicializar todas las funciones del supervisor.
      • RPR +
        El módulo supervisor de respaldo se inicializa con lo que también se inicializan el supervisor y el motor de enrutamiento. No se inician funciones de capa 2 y capa 3.
        Cuando el módulo activo falla se completa la inicialización sin recargar otros módulos. Los puertos del switch conservan su estado.
      • SSO
        El módulo de respaldo se inicia completamente.
        Tanto el contenido de la configuración inicial como la configuración activa se sincronizan entre los módulos supervisores. La información de capa 2 se mantiene en ambos supervisores para que la conmutación de hardware pueda continuar durante el reemplazo de módulo de supervisión.
        El estado de las interfaces del switch se mantiene para que los enlaces no flapeen durante la conmutación.
      Cisco Non Stop Forwarding
      En switches Cisco es posible implementa NSF junto con SSO.
      NSF es un método interactivo que reconstruye rápidamente la tabla de enrutamiento (RIB) en el momento de cambio de placa supervisora. La tabla de enrutamiento (RIB) es la base para generar la FIB (tabla de reenvío de CEF); esta última tabla se descarga a cada uno de los módulos que están operando con CEF. En consecuencia, es posible mantener la FIB operativa mientras se reconstruye la RIB de mdo tal que el dispositivo puede seguir reenviando tráfico sin interrupción.

      NSF con SSO en switches Catalyst 9400
      En estos dispositivos, al implementar NSF con SSO:
      • Es el modo de redundancia de supervisora por defecto.
      • La información de estado se sincroniza inmediatamente del supervisor activo al de respaldo.
      • El tiempo de conmutación activo/standby es menor a los 150 milisegundos.
        La interrupción de conmutación de tráfico está por debajo de los 200 milisegundos.
      • Los puertos de los demás módulos se mantienen activos, con sus LEDs encendidos.
      • Los puertos de uplink de las supervisoras se mantienen activos.
      • El reenvío de paquetes no se interrumpe.
      • La información de las sesiones de usuario se mantiene.
      • No hay pérdida de sesiones.
      Al margen de la reducción de los tiempos de conmutación activo/standby de las placas controladoras, hay que tener presente que el proceso de arranque en un switch Catalyst 9400 con supervisora simple o doble y tarjetas de puertos mixtas requiere aproximadamente 9 minutos.



      Estás invitado a participar de nuestro grupo en Facebook:

      https://www.facebook.com/groups/librosnetworking/

      O si preferís redes sociales con mayor control de tu privacidad,
      podés participar de nuestro grupo en VKontakte
      https://vk.com/libros.networking

      o seguir las principales novedades en el grupo de Telegram:
      https://t.me/LibrosNetworking


      Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
      que está disponible en la Librería en Línea de EduBooks.

      14 de junio de 2021

      Transmisiones de video: ancho de banda requerido

      Es una pregunta respecto del ancho de banda necesario para sostener comunicaciones de video de diferente tipo es recurrente en nuestra tarea. 
      Es que no sólo el streaming de video ha ido ganando cada vez más lugar en el tráfico de la red. También se multiplican las aplicaciones que permiten acceder a contenidos basados en video o establecer comunicaciones de video; y cada vez de mayor calidad. Cuando se implementa QoS o se diseñan redes inalámbricas es necesario considerar la cantidad de comunicaciones de video simultaneas que habrá de sostenerse, y al hacerlo es fundamental conocer la calidad de ese video para poder estimar el ancho de banda necesario para garantizar su fluidez.

      ¿Qué es un "streaming" de video?
      Con este término solemos referirnos a una transmisión de video unidireccional a través de una red de datos.
      Es un tipo de transmisión que requiere la transferencia contínua de bits a través de la red de datos (Internet, la red corporativa o la red hogareña) hasta el receptor en el que se reproducirá.
      Normalmente se trata de contenido enviado de modo comprimido, utilizando diferentes algoritmos de compresión, que el receptor final visualiza en tiempo real utilizando aplicaciones que no esperan a la descarga completa o a almacenarlo para poder reproducirlo.
      Este video puede tener diferente resolución o calidad.
      La resolución del video, junto al algoritmo de compresión utilizado, determinan el requerimiento de ancho de banda.

      Video HD
      Resolución de imagen: 720p, lo que implica una resolución de pantalla de 1280 x 720 píxeles.
      Esta calidad de video, utilizando códec H.264 requiere 3 Mbps de ancho de banda.
      Si se utiliza códec H.265 es necesario calcular un ancho de banda de 1,5 Mbps.

      Video FHD
      Resolución de imagen: 1080p, lo que implica una resolución de pantalla de 1920 x 1080 píxeles.
      Cuando se utiliza códec H.264 su transmisión requiere 6 Mbps de ancho de banda.
      Utilizando H.265 se recomienda estimar 3 Mbps para este streaming.

      Video UHD
      Resolución de imagen: 2160p, lo que implica una resolución de pantalla de 3840 x 2160 píxeles (el doble que FHD).
      Aproximadamente 4 veces la cantidad de píxeles del video FHD.

      Video 4K
      Esta calidad de video refiere a 2 resoluciones posibles.
      La resolución correspondiente a video UHD: 3840 x 2160 píxeles; o la resolución mayor disponible que es 4096 x 2160 píxeles. 
      Materiales en esta resolución ya están disponibles en servicios de streaming como Netflix o YouTube.
      Para una transmisión en resolución 4096 x 2160, con códec H.264 se recomienda reservar 32 Mbps. Si se utiliza códec H.265 hay que estimar 15 Mbps.

      Sintetizando

      HD     1280 x 720       H.264    3 Mbps
                                         H.265    1,5 Mbps
      FHD   1920 x 1080    H.264     6 Mbps
                                        H.265     3 Mbps
      UHD   3840 x 2160    H.264    25 Mbps
                                         H.265   12 Mbps
      4K      4096 x 2160   H.264     32 Mbps
                                        H.265   15 Mbps



      Estás invitado a participar de nuestro grupo en Facebook:

      https://www.facebook.com/groups/librosnetworking/

      O si preferís redes sociales con mayor control de tu privacidad,
      podés participar de nuestro grupo en VKontakte
      https://vk.com/libros.networking

      o seguir las principales novedades en el grupo de Telegram:
      https://t.me/LibrosNetworking


      Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
      que está disponible en la Librería en Línea de EduBooks.



      9 de junio de 2021

      Power over Ethernet

      En las redes actuales hay una variedad importante de terminales o "endpoints" (cámaras IP, access points, teléfonos IP, laptops, etc.) que por su naturaleza de dispositivos terminales están diseñados para conectarse a la infraestructura de la red a través de dispositivos de acceso, típicamente un switch. 

      Estas terminales utilizan un cable UTP para conectarse al puerto de acceso de un switch LAN. Pero para poder operar, además de la conexión de datos requieren de alimentación eléctrica.

      Desde hace varios años los switches de acceso de nivel enterprise dan la posibilidad de que el dispositivo terminal reciba energía a través del mismo cable UTP que se utiliza para la transmisión de datos. Es lo que recibe la denominación genérica de Power over Ethernet (PoE). De esta manera es posible simplificar los requerimientos de cableado eléctrico y aprovechar el tendido del cableado de red para un propósito doble: alimentación eléctrica y transporte de datos.

      Adicionalmente, al controlar el suministro eléctrico de estos dispositivos desde el switch es también posible tener un control centralizado del encendido y apagado de terminales como teléfonos y otros. Con esto hay un nuevo recurso para el control del consumo eléctrico.

      Para dar suministro eléctrico a través del puerto del switch es suficiente un cableado UTP categoría 5e realizado de acuerdo a las especificaciones del estándar.  

      En el caso de los switches Cisco, si bien PoE se inicio como una implementación propietaria (Power Inline y UPoE), en la medida en que se publicaron estándares los dispositivos se fueron adaptando a los mismos. En primer lugar la primera norma fue IEEE 802.3af (conocida como PoE), luego actualizada por IEEE 802.3at (llamada PoE+) y finalmente llevada a su expresión más potente en la actualidad, IEEE 802.3bt (UPoE).

      PoE IEEE 802.3af

      Generalmente recibe la denominación genérica de PoE la implementación del estándar 802.3af aprobado por la IEEE en el año 2003, y que tiene las siguientes características:

      • Puede utilizar 2 o 4 pares de cable UTP categoría 5e.
      • Entrega hasta 15,4 W en el puerto del switch, lo que brinda hasta 12,95 W en el dispositivo alimentado considerando la pérdida de 100 m. de cable.
        Esto es suficiente para alimentar APs IEEE 802.11a/b/g con radio dual, una cámara IP o un teléfono IP que requieren un máximo de 12,95 watts. 
      • Se puede implementar sobre enlaces Ethernet 10BaseT, 100BaseT o 1000BaseT.
      • Mantiene una longitud máxima de 100 m. para cada segmento de cableado UTP.

      PoE+ IEEE 802.3at

      Estándar IEEE aprobado en el año 2009, que cuenta con las siguientes características:

      • Proporciona hasta 30 watts en el puerto del switch lo que representa hasta 25,5 watts de potencia a los 100 metros de cable.
      • Soportado sobre cableado categoría 5e o superior.
      • Estos dispositivos también son denominados dispositivos “tipo 2”.
      • Mantiene una longitud máxima de 100 m. para el cableado UTP.
      • PoE+ es la solución para dar alimentación eléctrica a APs 802.11n de radio dual y los estándares posteriores, para sostener también cámaras IP color de alta resolución o teléfonos IP con pantalla color de alta resolución.

      UPoE+ IEEE 802.3bt

      La tecnología de provisión de energía sobre el cableado de datos ha seguido evolucionando para permitir dar alimentación eléctrica a una variedad más amplia de dispositivos terminales.

      Inicialmente fue un desarrollo propietario de Cisco para proporcionar alimentación eléctrica de hasta 60 watts en el puerto del switch denominado genéricamente UPoE.

      Ahora, estandarizado como IEEE 802.3bt es denominado UPoE+ y proporciona:

      • Proporciona hasta 90 watts en el puerto del switch que representan hasta 71 watts a los 100 metros de cable.
      • Soportado sobre cableado categoría 5e o superior.
      • Mantiene los 100 m. de longitud para el cableado UTP.
      • Requerido para alimentación eléctrica de clientes de infraestructura de escritorio virtual, switches compactos, laptops, sistemas de Telepresencia, etc.


      Soporte en dispositivos Cisco
      Entre la familia de dispositivos Cisco, soporten PoE+ o UPoE+ los siguientes:
      • Catalyst 9200 soporta PoE+.
      • Catalyst 9300 y 9400 soportan hasta UPoE+.
      • Meraki MS12X, 2XX y 350 soportan PoE+.
      • Meraki MS355 y 390 soportan UPoE.

      En el caso de los switches Catalyst, una letra incluida en el Product ID identifica el soporte PoE que ofrece la plataforma:

      • Una letra "P" identifica productos con soporte PoE+ como, por ejemplo: C9200L-48P-4G, o C9300-48P.
      • Una letra "U" identifica productos con soporte UPoE como, por ejemplo: C9300-24U, o C9400-LC-48UX.
      • Una letra "H" identifica productos con soporte UPoE+ como, por ejemplo: C9300-48H o C9400-LC-48H.
      En todos los casos es necesario tener presente que la simple declaración de que un dispositivo posee capacidad PoE no es suficiente. Es necesario complementar la información con lo detallado en el hoja técnica del dispositivo respecto de posibles restricciones y requisitos, el rango de puertos soportados, el posible requerimiento de fuentes de alimentación o actualizaciones de software.



      Estás invitado a participar de nuestro grupo en Facebook:

      https://www.facebook.com/groups/librosnetworking/

      O si preferís redes sociales con mayor control de tu privacidad,
      podés participar de nuestro grupo en VKontakte
      https://vk.com/libros.networking

      o seguir las principales novedades en el grupo de Telegram:
      https://t.me/LibrosNetworking


      Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
      que está disponible en la Librería en Línea de EduBooks.