Creación de un switch de red administrado por Linux
(blog.brixit.nl)- Para recrear una estructura en la que Linux controla directamente el chip del switch, como dentro de un router de consumo, se diseñó una PCB de switch gigabit basada en RTL8367S y se conectó a DSA/switchdev
- El RTL8367S elegido es un chip de switch gigabit de 7 puertos con PHY integrado en 5 puertos; en lugar de usar un puerto CPU dedicado, el puerto 0 se conecta por cable de red al Ethernet de una placa Linux
- En el proceso de fabricación del hardware, se simplificaron los rieles de alimentación a 3.3V y 1.1V y se probaron rutas de configuración como pines de arranque, EEPROM, flash SPI y puerto serial
- Para la conexión con Linux se necesitaron una placa PINE64 A64-lts, opciones de kernel personalizadas y modificaciones al Device Tree; después del arranque,
lan1~lan4aparecen bajoeth0como si fueran interfaces de red locales - Este enfoque encaja bien con herramientas existentes como Linux bridge y
ethtool, pero en PCs, servidores o interfaces de red USB comunes es difícil de usar directamente por las limitaciones de Device Tree y GPIO
Estructura de los switches administrados y Linux DSA
- Un switch administrado típico permite cambiar la configuración y ver el estado de los puertos mediante una interfaz web, y los equipos más caros también ofrecen interfaces adicionales como telnet o consola serial
- El switch dentro de un router de consumo también puede verse como una categoría aparte de switch administrado
- El router es un pequeño dispositivo Linux y en su interior tiene un chip de switch
- Uno o más puertos están conectados internamente a la CPU, y el resto se exponen al exterior como puertos físicos
- Si se usan los subsistemas DSA y switchdev de Linux, los puertos conectados al switch funcionan como si fueran puertos de red “locales” reales
- Entre el SoC del router y el switch se necesitan conexiones como SGMII o RGMII, y un bus de administración como SMI o MDIO
- En los switches comerciales normales, las conexiones de chip necesarias no están expuestas hacia afuera, por lo que es difícil controlarlos de esta manera
Fabricación de una placa de switch basada en RTL8367S
- El switch gigabit hecho a mano usa el chip Realtek RTL8367S
- Es un chip de switch gigabit de 5 puertos ampliamente utilizado
- En realidad tiene una estructura de 7 puertos: 5 puertos con PHY integrado y 2 puertos para conexión con CPU
- Como el datasheet solo ofrece información mínima, también se consultaron esquemas de dispositivos con chips Realtek similares y documentos de diseño Ethernet
- Al principio parecía que se necesitaban unas 7 redes de alimentación, pero como los rangos de voltaje se superponían, fue posible agruparlas y usar solo reguladores de 3.3V y 1.1V
- Como Linux switchdev no exige que la conexión a la CPU use obligatoriamente un puerto CPU dedicado, en este diseño el puerto 0 se conecta por cable a la placa Linux
- Desde la perspectiva del driver switchdev, parece como si no hubiera un PHY Ethernet intermedio
Configuración del chip del switch y tropiezos en la PCB
- El RTL8367S tiene varias rutas de configuración, pero solo con el datasheet era difícil identificar la configuración mínima necesaria para que funcionara como un dumb switch común
- Los 8 pines leídos al inicio comparten función con los pines de LED de los puertos
- El bus i2c puede usarse para conectar un chip EEPROM, pero comparte pines con el bus SMI necesario
- El bus SPI permite conectar una flash NOR para guardar registros de configuración o firmware del núcleo 8051 integrado
- Se consideró que el puerto serial no funcionaría sin firmware para el 8051
- La primera placa se abordó pidiéndola directamente y cambiando conexiones de soldadura para descubrir las condiciones de funcionamiento
- Se incluyó la huella para un chip flash, pero al final no fue necesaria
- Se pusieron jumpers de soldadura en los pines de configuración
- Los LED se omitieron porque era difícil hacerlos configurables
- Los documentos de diseño para Ethernet gigabit enfatizan el control de impedancia y la coincidencia precisa de longitudes, pero los diseños de switches baratos reales no parecían ser tan estrictos
- La parte considerada más importante fue la coincidencia de skew entre los pares de red
- Se concluyó que no era útil igualar entre sí la longitud total de los 4 pares de red
- Incluso dentro del cable de red, la tasa de trenzado de los 4 pares ya difiere bastante y sus longitudes son muy distintas
- En la revisión inicial de la placa, Ethernet no funcionaba por un error en el tratamiento del capacitor que referenciaba a tierra el center tap del transformador del lado del switch
- En las pruebas se cortó una pista pequeña para eliminar el corto a tierra
- En la configuración de prueba, funcionaba incluso con el center tap flotante
- En el diseño final se añadió el capacitor correspondiente
El switch terminado y su conexión con Linux
- La placa terminada es un switch gigabit de forma algo peculiar
- 4 puertos miran hacia un lado
- 1 puerto mira hacia el lado opuesto y se usa para conectar la placa Linux
- La alimentación se suministra por un pin header de 2.54 mm
- También se añadió la huella de un conector USB Type-C para poder alimentar sin cables DuPont
- Como placa Linux de prueba se eligió la PINE64 A64-lts
- La posición de sus conectores coincidía más o menos con la disposición deseada
- Como se requerían cambios en el Device Tree, era importante usar una plataforma que no fuera x86
- El kernel se recompiló porque normalmente los módulos relacionados con switches no están habilitados
CONFIG_NET_DSA: Distributed Switch ArchitectureCONFIG_NET_DSA_TAG_RTL8_4: etiquetado de puertos para chips switch RealtekCONFIG_NET_SWITCHDEV: sistema de drivers de switch de redCONFIG_NET_DSA_REALTEK,CONFIG_NET_DSA_REALTEK_SMI,CONFIG_NET_DSA_REALTEK_RTL8365MB: drivers del chip de switch real
- En vez de cargar un Device Tree overlay con U-Boot, se parchó directamente el Device Tree de la placa A64-lts
- Se cargó el driver con la cadena de compatibilidad
realtek,rtl8365rb - Ese driver soporta varios chips switch Realtek, incluido el RTL8367S usado aquí
- Se eliminó la definición del puerto CPU del ejemplo de la documentación y se definieron 5 puertos de switch normales
- Se cargó el driver con la cadena de compatibilidad
port@0es el puerto orientado hacia atrás y está conectado al&emacdel A64-lts- Los demás puertos están conectados a cada PHY dentro del chip del switch
- En la parte superior del Device Tree se definen 3 GPIO conectados a SDA/SCL y Reset
Herramientas de red de Linux y limitaciones
- Después del arranque, en Linux aparecen las interfaces de puertos del switch definidas en el Device Tree junto con el dispositivo
eth0normallan1@eth0lan2@eth0lan3@eth0lan4@eth0
- Para hacerlo funcionar de verdad, hay que ejecutar
ip link set eth0 upy levantar cada interfazlan - La integración con las herramientas estándar de red de Linux es natural
- Si se agregan varios puertos
lana un Linux bridge, switchdev hace que el bridging de esos puertos se procese dentro del chip del switch - Linux no necesita reenviar directamente ese tráfico
- Con
ethtool lan3se puede ver la información del enlace ethtool -S lan3devuelve información de estado estándar, incluidos paquetes procesados completamente por el switch
- Si se agregan varios puertos
- Aun así, tiene muchas limitaciones para usarse en un entorno común
- Hay que construir un switch de red propio o abrir uno existente para encontrar las conexiones necesarias
- Las PCs y servidores comunes no usan configuración basada en Device Tree, y normalmente tampoco tienen pines GPIO utilizables por el kernel
- Las interfaces de red USB son difíciles de usar con este enfoque porque no tienen un handle de nodo de Device Tree para asignarlas como puerto conduit
- Algunas limitaciones quizá puedan esquivarse, pero hace falta más documentación sobre cómo cargar switchdev en entornos que no sean dispositivos ARM o dispositivos USB especiales que expongan GPIO
1 comentarios
Opiniones de Hacker News
Por ejemplo, un par de switches Dell OS9 antiguos son equipos apilables de la vieja escuela con 48 puertos de 10 Gb/s y 4 puertos ópticos QSFP+ de 40 Gb/s, y cada switch puede procesar hasta 1.28 Tb/s
Hoy en día se consiguen por unas £1800 con IVA incluido y pueden durar prácticamente para siempre
Este tipo de intento está bueno, pero también hay que tener en cuenta que empresas como Netgear venden switches de 8 puertos de 1 Gb con PoE en todos los puertos por unas £125
Si uno evalúa la economía del proyecto calculando el tiempo a £20~50 por hora, quizá convenga comprar algo ya hecho; pero si el objetivo es el proyecto en sí, no hace falta preocuparse por el precio
(1) https://i.dell.com/sites/doccontent/shared-content/data-shee...
(2) https://www.etb-tech.com/dell-force10-s4820t-10gbe-switch-os...
El precio del ASIC era más o menos lo esperable; no sé la cifra exacta, pero probablemente rondaba unos cientos de dólares
La documentación de la interfaz de software era muy deficiente, y como era una biblioteca que soportaba todos los ASIC de switch de Broadcom, traía un archivo
.ade cientos de MB lleno de funciones que solo devolvían errores de “no soportado en este dispositivo”, algo que no podías saber hasta llamarlas directamentePara usos más simples, se pueden conseguir routers compatibles con OpenWRT que en su mayoría usan chips de switch administrables, y OpenWRT ofrece una buena interfaz para configurar VLAN y muchas otras opciones
Eso sí, el soporte de funciones como PoE o puertos 10 Gb/SFP+ puede ser limitado, y no tengo claro cuál es el estado actual
Pero este proyecto no es tanto “ponerle un cerebro externo a un switch no administrable”, sino más bien el primer switch administrable hecho desde cero que veo
Supongo que el rendimiento del lado de hardware será mejor, pero no sé si hubo pruebas que muestren la diferencia real
Si usas adaptadores USB, el USB es un bus compartido en varios sentidos, así que se llega rápido al ancho de banda máximo, más aún porque los datos tienen que entrar hasta la CPU y luego volver a salir
Al hacer switching por software, se suma el tiempo de procesar cada paquete y reenviarlo al lugar correcto, además de la latencia propia de las interfaces
Cada adaptador tiene su propio PHY de red y hardware, lo que aumenta el consumo, y si sumas el procesamiento adicional, el uso de energía crece todavía más
También se aprovechan menos el offloading por hardware y otras mejoras de rendimiento, por lo que el sistema completo participa más en mover paquetes
En cuanto a funciones, depende del hardware elegido; algunos adaptadores USB gigabit baratos ni siquiera manejaban bien cosas como VLAN
En cambio, si usas varias tarjetas PCIe, las funciones pueden mejorar mucho, pero a partir de ese punto se parece más a ruteo que a switching
Aunque el SO host se caiga, el switching puede seguir funcionando, y si se combina con watchdog y recuperación, se puede crear un sistema con mejor disponibilidad que un bridge por software, aunque algunas funciones dejen de operar por un rato
Eso sí, hace falta asumir que el chip de switch en sí no se muere ni se queda colgado
Depende del objetivo, pero si quieres inspeccionar todo el tráfico que pasa por el switch, 4 interfaces claramente son mejores
Si el switch basado en host también se comunica mucho, 4 interfaces dan 4 Gbps hacia el host, lo cual es mejor que un solo 1 Gbps
En eBay se pueden comprar tarjetas empresariales usadas quad 1G por menos de $15, y yo prefiero la Silicom quad bypass 1g
PEG4BPI-SDLa función de bypass es interesante y poco común, por eso son más baratas, pero en general, una vez configuradas como una “NIC estándar”, se pueden conectar en otro equipo y usar sin mayores problemas
Los productos iniciales son más difíciles de usar porque el proveedor y subproveedor del PCI ID aparecen como Silicom, mientras que las tarjetas
-SDtienen ID de proveedor Intel y subproveedor Silicom, por lo que se les asocia el controlador normalCon puertos 4x10G hay más cosas que administrar, y según el sistema host, el throughput de bridging por software podría no ser suficiente
Las tarjetas de cuatro puertos 10G son difíciles de conseguir, pero si esperas, las 2x10G pueden encontrarse a precios razonables
Un switch no conmuta paquetes en la CPU sino en el ASIC, así que dependerá del rendimiento de la CPU y normalmente no es una forma eficiente de usar los recursos de cómputo disponibles
Aun así, si ignoras el esfuerzo de diseño y fabricación, el costo total del hardware podría quedar por debajo de $100, y posiblemente salga más barato que una computadora con varias interfaces
Eso sí, una red de 1 Gb/s ya está bastante anticuada
Se puede fabricar un switch de red administrable más grande y rápido usando solo componentes comerciales por un costo de poco más de USD 200
Por ejemplo, con un Odroid H4+ con 2 puertos y una tarjeta de expansión M.2 que agrega 4 puertos Ethernet, se puede armar un switch de 6 puertos a 2.5 Gb/s
Otra opción es usar una computadora pequeña con CPU N100 y 4 puertos de 2.5 Gb/s, que se consigue en ese rango de precio de varios fabricantes chinos
Una computadora pequeña similar con 6 puertos de 2.5 Gb/s cuesta un poco más y puede superar ligeramente los USD 300
Parecería encajar perfecto en dispositivos como estos, pero perdí el interés porque montar un entorno de laboratorio era casi imposible
Creo que esos chips son necesarios porque hacer switching con la CPU genera mucha carga
88E6393Xfunciona en modo “simple/administración externa” sin firmwareSe puede usar con switchdev de Linux, como el dispositivo de este artículo
Se usó un diagrama de bloques de RouterBoard como modelo para mostrar cómo se conecta el switch de hardware con el resto del sistema, pero luego parece argumentarse que esos dispositivos son imposibles o difíciles de manejar
Me pregunto si aquí realmente se ha conseguido un RouterBoard
Probablemente se pueda compilar OpenWRT para la mayoría de los RouterBoard, y el 2011 debe ser un equipo bastante común incluso en el mercado de segunda mano
La mejor pregunta es si el objetivo era construirlo desde cero desde el principio, o si se descartó por alguna razón concreta el concepto de usar hardware de otra persona
Tomé el diagrama del RB2011 porque me pareció simple y bien explicado
Técnicamente, el RB1100AHx4, que usa el mismo chip de switch, sería un mejor ejemplo, pero resulta más confuso porque usa juntos los dos puertos de CPU y afirma que son un enlace de 2.5 Gbps a partir de 2 enlaces de 1.25 Gbps, ignorando el overhead de codificación
La razón para construirlo desde cero es que el costo es razonable y este dispositivo debe ir dentro de una caja de grabación de video de FOSDEM
Hay que resolver algunos problemas específicos de ese diseño: exponer 4 puertos de red en el panel frontal del gabinete y, al mismo tiempo, conectarlos al SBC interno
Dentro del gabinete no hay mucho espacio para hacer un passthrough hasta el switch sin un cable de loop externo para el SBC, y con un switch simple tampoco se podría monitorear el sistema
Como fabricamos bastantes de estas cajas, se vuelve una solución razonable; si se ignora el tiempo de diseño, es viable porque es trabajo voluntario
El problema parece estar relacionado en cierta medida con la NAND y, si no recuerdo mal, difiere en algo de otros RouterBoard soportados
Alguien propuso una nueva solución para este problema, pero aún no fue incorporada: https://forum.openwrt.org/t/wiki-cleanup-for-mikrotik-rb2011... y otros hilos