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.



23 de mayo de 2021

Productos de la familia Meraki

Meraki ofrece una importante variedad de productos que cubren buena parte de los requerimientos de las actuales redes corporativas; todos dentro del mismo concepto de arquitectura y basados en la misma tecnología.

Cada línea de productos tiene características propias ajustadas a los requerimientos habituales de las implementaciones corporativas, manteniendo la misma facilidad de uso, ya conocida, de los productos Meraki.

Dispositivos de seguridad y SD WAN Meraki MX 

Los dispositivos de seguridad Cisco Meraki MX son dispositivos multifuncionales que permiten el despliegue de implementaciones SD-WAN. Es una solución integral de seguridad y conectividad en el borde de la red corporativa.

Incluye la posibilidad de una conexión de respaldo alternativa LTE implementando adicionalmente un gateway Meraki MG.

El firewall que se incluye en la estructura de Meraki MX tiene componentes avanzados de última generación:

  • Firewall statefull.
  • Protección contra amenazas con la incorporación de AMP.
  • Sistema de prevención de intrusiones que utiliza el motor Snort.
  • Filtrado de contenido basado en categorías de BrightCloud.
  • Gestión en la nube de las prestaciones de seguridad.
  • Reglas de geolocalización.

La implementación de Auto VPN y SD-WAN tiene características específicas:

  • VPN automática para el provisionado de túneles IPsec gestionados desde la nube.
  • Selección de ruta inteligente.
  • Optimización del tráfico a través de túneles VPN.
  • Equilibrio de la carga de tráfico dinámico en función de las condiciones de los enlaces WAN.
  • Gestión de enlaces ISP redundantes.
  • El enlace redundante se puede utilizar para conmutación en caso de fallo o con una política de equilibrio de carga dinámico.
Switches Meraki MS

La línea de switches Meraki incluye prestaciones de enrutamiento dinámico y un alto nivel de seguridad; incluyen herramientas adicionales para la solución de fallos. Entre las funciones que incorporan se pueden destacar:

  • Herramienta de captura de paquetes en vivo.
  • Herramienta de prueba de integridad del cableado.
  • Herramientas de diagnóstico en tiempo real.
  • Características de seguridad de nivel corporativo.
  • Virtual stack para facilitar la configuración de cientos de puertos independientemente de la ubicación física de los switches.
  • Port-security.
  • Página de topología.
  • Visibilidad de capa 7 de las sesiones de los clientes.
  • Calidad de servicios (QoS) para voz y video

Algunas de las prestaciones, dado que requieren hardware especializado, son dependientes del hardware y no están soportadas en todos los modelos de switches:

  • Stack físico.
  • StackPower.
  • Servicios DHCP incorporado.
  • UPoE.
  • Enrutamiento dinámico con OSPF.
Hay también algunos dispositivos de alta performance para tareas de agregación y distribución.

Access points Meraki MR

Son el primer producto que se lanzó y quizás el más conocido de la familia Meraki. Hoy, los APs de la familia Meraki ofrecen prestaciones de última generación e implementan los últimos estándares definidos. Ofrecen soluciones para una amplia gama de necesidades, desde la cobertura básica hasta la operación en entornos de alta densidad y uso intensivo.

Entre sus principales características se puede destacar:

  • Dispositivos que responden al estándar 802.11ax (WiFi 6) y que incluyen seguridad WPA3.
  • Variedad de modelos para despliegues indoor y outdoor, con antenas integradas o conectorizadas.
  • Posibilidad de priorizar tráfico de aplicaciones críticas.
  • Implementación de autenticación con portal web cautivo para usuarios invitados.
  • Despliegue en malla de recuperación automática.
  • Motor de estado inalámbrico que identifica anomalías en la experiencia de los usuarios finales.
  • La mayoría de los modelos incluyen una tercera radio para despliegues de seguridad con Air Marshal, Auto RF y localización.

Cámaras de seguridad Meraki MV

Las cámaras de seguridad Cisco Meraki MV incluyen numerosas funciones que intentan hacer su implementación simple y efectiva, al mismo tiempo que permiten un nivel de personalización adecuado para los requerimientos de implementaciones corporativas. Permiten monitorear e investigar cualquier incidente de modo fácil y rápido.

Utilizan una arquitectura de borde que incluye almacenamiento del video registrado en una tarjeta SSD local, con lo que no se requiere almacenamiento centralizado. La imagen capturada por la cámara se puede visualizar localmente o a través de la nube. Con este propósito incluye el cifrado end-to-end de la transmisión de video.

Incluyen múltiples funciones que aportan valor:

  • Análisis de imágenes retroactivo.
  • Detección de objetos y mapas de calor de movimiento.
  • Diferentes formatos de hardware disponibles.
  • Modelos indoor y outdoor.
  • Dotación de LEDs infrarrojos para contar con imagen de sitios oscuros.
  • Lentes ópticas y lentes fijas.
  • Conectividad inalámbrica.
  • Funcionalidades PTZ disponibles.
  • Posibilidad de almacenamiento en la nube Cisco Meraki MV Cloud Archive con licencia adicional.

System Manager Endpoint

Solución diseñada para administrar y controlar dispositivos terminales.

En aquellos casos en los que se requiere aprovisionamiento dinámico e incorporación este sistema permite asegurar de modo rápido y simple que la red permanecerá segura mientras proporciona la cobertura necesaria para satisfacer el requerimiento de los usuarios finales.

  • Brinda soporte multiplataforma: MacOS, iOS, Apple TV, Windows, Android y Chrome OS.
  • No requiere implementación de dispositivos y/o software on-premise.
  • Brinda visibilidad del comportamiento de las terminales.
  • Permite aplicar perfiles específicos a diferentes tipos de terminales.

La implementación de perfiles permite deshabilitar funciones o aplicaciones en las terminales, pueden descargar una configuración inalámbrica específica y activar la asociación automática a un determinado SSID.

Como resultado de la implementación de perfilado se puede:

  • Desactivar funciones específicas del sistema operativo, ocultar aplicaciones y aplicar restricciones.
  • Forzar el cumplimiento de políticas de seguridad.
  • Establecer límites geográficos para la presencia de un dispositivo.
  • Aplicar herramientas para control en tiempo real.
  • Obtener, de modo remoto, capturas de pantalla de las terminales.
  • Descargar aplicaciones, perfiles y certificados digitales de modo remoto.
  • Apagar y reiniciar terminales.

Meraki Insight


Cisco Meraki Insight es un servicio que analiza el rendimiento y funcionamiento de las diferentes aplicaciones. Por este motivo es una herramienta poderosa y muy útil para contar con información sobre aplicaciones, servicios y su rendimiento; detecta anomalías de comportamiento y las registra de forma gráfica para información del administrador.

Es una herramienta que permite responder de forma rápida, eficiente y en tiempo real a la posibilidad del surgimiento de problemas graves.

  • Se ejecuta en la nube de Meraki.
  • Utiliza los dispositivos Meraki MX como sensores para obtener datos.
  • Permite obtener copias de seguridad de la información procesada.
  • Introduce la función VoIP Health que monitorea la performance de los enlaces ascendentes para el tráfico de VoIP a través de sondas ICMP desde el Meraki MX hasta el punto final de VoIP.
  • VoIP Health puede estimar la calidad de las llamadas y proporcionar información en función de MOS.


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.



12 de mayo de 2021

Meraki, control en la nube

Cisco Meraki introduce la tecnología necesaria para desplazar la gestión y control de los dispositivos a la nube. De esta manera ofrece una funcionalidad completa que se puede gestionar y monitorear fácilmente desde cualquier lugar con acceso a Internet y a través de ella, a la nube. Por otra parte, la integración de los dispositivos a esta nube es sumamente simple:

  • Se implementa el dispositivo en las instalaciones de la empresa. 
  • Como consecuencia de esto el dispositivo adquiere una dirección IP (vía DHCP) de gestión y acceso a Internet.
  • El dispositivo se conecta automáticamente en forma segura a la nube Cisco Meraki.
  • Desde el panel de control se registra el dispositivo en la red adecuada, se actualiza el firmware y se descarga la configuración de modo automático.
  • Se inician las tareas de gestión y monitoreo desde el panel de control que brinda herramientas para estas tareas.


Los dispositivos Meraki se entregan preconfigurados con el nombre de host y las direcciones IP necesarias para poder establecer una conexión segura con la nube de Meraki. Esta configuración inicial incluye un certificado digital que se utiliza en el proceso para establecer un túnel cifrado entre el dispositivo y la nube de Meraki para asegurar el tráfico de gestión y control que circula a través de ese circuito.

  • Todo el tráfico que se intercambia con la nube de Meraki circula en un túnel cifrado con un algoritmo basado en AES 256.

El tablero de control es una interfaz web a la que se puede acceder utilizando cualquier navegador web y desde dónde se administran y monitorean todos los dispositivos Meraki de la red corporativa. Cada dispositivo establece su propio túnel cifrado y a  través de esta conexión con la nube:

  • Cada dispositivo independientemente genera un tráfico de entre 1 y 2 Kbps para la gestión y control.
  • A través de ese túnel se descargan configuraciones y e envían datos de monitoreo que se procesan en la nube.
  • El tráfico de los usuarios se reenvía independientemente sin que pase por la nube de Meraki.

Nota: Las cámaras Meraki MV pueden generar picos de tráfico hacia la nube de hasta 200 Kbps cuando tienen activada la función de detección de movimiento. Esta función puede ser desactivada para reducir el consumo de ancho de banda.


Las objeciones más frecuentes están referidas a:

Seguridad
¿En algún momento el tráfico que circula por la red corporativa fluye a través de la nube de Meraki?

  • El tráfico de los usuarios nunca ingresa a la nube de Meraki.
    Esto permite afirmar que todas las implementaciones de Cisco Meraki cumplen con los requerimientos para certificar HIPAA y PCI.
Confiabilidad
¿Qué ocurre si en algún momento los dispositivos de la infraestructura corporativa no pueden acceder a la nube de Meraki?
  • La nube de Meraki tiene una disponibilidad garantizada del 99,99%.
    Este servicio está basado en centros de datos distribuidos en diferentes puntos del planeta.
    Los problemas de conectividad de dispositivos a la nube se deben en su inmensa mayoría a problemas de conectividad del dispositivo hacia la nube, no de disponibilidad de la nube: interrupciones de servicio del ISP, problemas de cableado, o reglas de bloqueo de tráfico.
  • Si se da una interrupción de la conexión con la nube de Meraki los dispositivos continúan reenviando el tráfico de la red corporativa sin interrupciones porque la última configuración conocida de los dispositivos reside localmente en los mismos.
    De ser necesario, cada dispositivo tiene una interfaz web local que se puede utilizar para realizar cambios de configuración básicos (por ejemplo los que puedan impactar en su acceso a Internet).
Previsibilidad
¿Cómo se realizan las actualizaciones de firmware? 
¿Están aseguradas?
¿Con qué frecuencia se publican actualizaciones?
  • Las actualizaciones de firmware se programan y envían a través del panel de control de Meraki. No requieren ninguna operación local.
  • Cisco Meraki tiene 3 categorías de actualizaciones de firmware: estable, candidato a estable y beta.
    El Administrador puede seleccionar la versión de firmware deseada a través del panel de control y programar el momento (día y hora) en que desea que se realice la actualización; o bien puede activar las actualizaciones manualmente.
Escalabilidad
¿Cómo puede crecer la red?
  • La red puede crecer o expandirse de modo muy simple, sencillamente agregando dispositivos y licencias en el tablero de control.


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 abril de 2021

Un protocolo de verificación para redes inalámbricas

Una solicitud que he recibido muchas veces es la referida a la necesidad de un protocolo, método o lista de verificación para probar la operación de una red inalámbrica después de su implementación o ante la presunción de alguna necesidad específica.

Mi respuesta habitualmente tiende a ser más o menos la siguiente: lo que están buscando es un protocolo de prueba que en realidad debiera haberse definido en el momento de diseñar esa red inalámbrica. La red inalámbrica no es un ente teórico sino un despliegue de tecnología que se supone que debe responder a una necesidad o requerimiento de la organización que la implementa. 
Es por esto que un buen diseño debiera incluir una prueba a ejecutar inmediatamente después de la implementación que verifique el cumplimiento de esos requerimientos.

Por lo tanto el inicio de toda verificación debiera ser una pregunta: "¿cuál es el requerimiento al que se está respondiendo?" La prueba debe diseñarse pensando en responder a ese requerimiento, no a parámetros puramente teóricos.
Es decir, no se trata de verificar parámetros puramente técnicos, sino el cumplimiento de objetivos específicos; muchas veces objetivos vinculados a la operación de la empresa, el desarrollo del negocio u otras áreas vinculadas.

Estas verificaciones debieran considerar al menos 4 elementos básicos.

1. ¿A qué dispositivos se desea dar conectividad?

No todos los dispositivos terminales inalámbricos operan exactamente igual.
La capacidad de de las terminales inalámbricas para conectarse a la red depende básicamente del hardware y el software con el que operan. Y hay diferencias muy significativas entre diferentes terminales, aún del mismo fabricante.
Las terminales pueden tener una sola radio (generalmente de 2,4 GHz) o dos radios (2,4 y 5 GHz); además, pueden estar dotadas de 1, 2 o 3 antenas; y su sensibilidad de recepción es diferentes (típicamente un smartphone tiene menor sensibilidad que una laptop).
Al mismo tiempo, pueden dar soporte a diferentes estándares, hoy, típicamente 802.11n, 802.11ac u 802.11ax, con diferentes anchos de canal, con diferente cantidad de cadenas de transmisión simultáneas.
Diferentes dispositivos, de diferentes fabricantes (o aún del mismo fabricante) pueden responder de modo diferente al conectarse a nuestra red. Esto es lo que explica porqué en muchas situaciones, dos dispositivos colocados uno junto al otro, conectados al mismo access point, presentan performances diferentes.

En este sentido es importante, entonces, que el diseño de la red inalámbrica esté ajustado para dar la mejor respuesta posible a los dispositivos terminales a los que debe ofrecer conectividad; y es eso lo que debemos verificar.

Esto es determinante también al momento de definir con qué dispositivos se van a hacer las pruebas. En este punto debieran elegirse dispositivos que reflejen la realidad operativa del día a día y no terminales de alto nivel que pueden brindar una percepción errónea de lo que luego será el día a día de esa red.

2. ¿Cuál es el throughput esperado?

El concepto es throughput, no data rate.
Lo que debemos considerar es la performance que han de experimentar los usuario, la capacidad real de transporte de datos que brinda la red inalámbrica.
Los usuarios no esperan simplemente conectarse a la red; esperan conectarse y poder operar en condiciones mínimas de performance que consideran adecuadas. ¿Cuáles son esas condiciones? ¿cuántos terminales deben conectarse en esas condiciones dentro de la misma celda? ¿Cuál es throughput total que se espera de la celda?
Porque el througput de una conexión no sólo es resultado del data rate que negocia la conexión sino también de la cantidad y tipo de terminales conectadas simultáneamente dentro de la misma celda.

Para ser claros, para este tipo de mediciones no es adecuada la información que brinda normalmente el software de las terminales, que expresa "data rate". Tampoco se trata de una medición puramente técnica de potencia de la señal o RSSI. Lo que se requiere es una medición de throughput.
La mejor forma de hacerlo es utilizar alguna aplicación diseñada con ese propósito, como puede ser Jperf.

Y lo que debemos evaluar es el throughput total de la celda. Por ejemplo, si se considera que lo adecuado es que una terminal pueda disponer de un throughput de unos 20 Mbps para operar, y se estima que en una celda puede haber aproximadamente 10 terminales conectadas simultaneamente, el objetivo a cubrir es un throughput promedio de 220 Mbps por celda (20 Mbps x 10 terminales y un adicional del 10% por la degradación que genera el incremento en el número de terminales).

3. ¿Cuál es el área de cobertura esperada?

Es sumamente importante tener claro el área o superficie dentro de la cual se espera lograr una conectividad aceptable.
Esto incluye espacios complejos para la propagación de la señal de los APs como son ángulos o rincones, cajas de escalera, sitios en los que la señal de radiofrecuencia pueda estar bloqueada por columnas o paredes gruesas, etc.
¿Dónde esperan lograr conectividad los usuarios?

Para esto es importante contar con un plano del lugar, marcar el área de cobertura acordada y seleccionar los puntos en los que se harán las mediciones de throughput. Es importante contar con la información del site survey previo a la implementación que nos mostrará áreas más difíciles o complejas para verificar cobertura y throughput en los puntos más difíciles.

4. ¿Hay un requerimiento de roaming?

Si en los requerimientos se incluye soportar movilidad para algunos servicios, es importante tenerlo presente y aclarar a qué tipo de servicios hay que dar soporte. Puede tratarse simplemente de movilidad para aplicaciones de datos, o en casos más complejos aplicaciones de voz y/o video.
Es igualmente importante aclarar qué aplicaciones deben operar con movilidad y verificar para esas aplicaciones cuáles son las condiciones soportadas de pérdida de paquetes, delay y jitter.
Otro elemento necesario es determinar las "rutas de roaming", es decir, los caminos más probables a recorrer por los usuarios mientras mantienen operativas sus aplicaciones. Estas rutas son relevantes porque han de estar cubiertas por celdas específicas que son las que deben cumplir con requerimiento de superposición y de sensibilidades mínimas al momento de hacer roaming.

Pero al hablar de movilidad también es preciso tener presente que, por defecto, la determinación del momento de cambio de celda es realizada por el dispositivo terminal, y consecuentemente la operación del roaming está supeditada también a la terminal con la que se está trabajando. Por este motivo, la respuesta al roaming puede variar entre diferentes terminales.

En este punto también es importante, al momento de evaluar si una implementación responde a los objetivos inicialmente propuestos, hacerlo utilizando terminales similares a las que luego se desplegarán en el día a día de la organización.


Mucho más se puede decir sobre el tema pero creo que esta es una primera síntesis que espero pueda ser útil.


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.