Introducción a Cisco TrustSec

T

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

 el Glosario de Siglas y Términos de Networking

que está disponible en la Librería en Línea de EduBooks.

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

 el Glosario de Siglas y Términos de Networking

que está disponible en la Librería en Línea de EduBooks.

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

 el Glosario de Siglas y Términos de Networking

que está disponible en la Librería en Línea de EduBooks.

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

 el Glosario de Siglas y Términos de Networking

que está disponible en la Librería en Línea de EduBooks.

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

 el Glosario de Siglas y Términos de Networking

que está disponible en la Librería en Línea de EduBooks.