Tus usuarios dicen “el servidor de archivos está lento”. Te conectas por RDP, inicias una copia y la ves avanzar a paso de tortuga a 80–120 MB/s en una red 10GbE que debería mover 900+ MB/s sin inmutarse. Alguien sugiere “quizá sea DNS”. Otro sugiere “reinicia el switch”. Consideras cambiar de carrera y hacer cerámica.
La mayoría de las veces, SMB va lento por una razón poco glamurosa: estás usando una red moderna con un cuello de botella de aspecto legado. La única función que la gente olvida habilitar —o verificar— es SMB Multichannel. Es la diferencia entre una sola transmisión TCP y muchas; entre un núcleo de CPU saturado y una máquina que realmente aprovecha el hardware por el que pagaste.
La función que olvidaste: SMB Multichannel (y por qué importa)
SMB (Server Message Block) es el protocolo detrás del uso compartido de archivos en Windows. En Windows moderno, “SMB” básicamente significa SMB 3.x, que trae funciones empresariales reales: cifrado, firmado, conmutación por error transparente y (crucial aquí) Multichannel.
SMB Multichannel permite que una sola sesión SMB use varias conexiones de red en paralelo. Eso puede significar múltiples NICs, varias IP en la misma NIC, o múltiples colas/rutas en una única NIC rápida cuando las funciones hardware adecuadas (RSS) están presentes. Mejora el rendimiento, la resiliencia y a menudo la latencia bajo carga porque no fuerzas todo por una sola pajita de copia de archivos.
Sin Multichannel, muchas transferencias se comportan como una sola transmisión TCP. Y una única transmisión TCP tiene limitaciones previsibles:
- Una ventana de congestión para crecer y reducirse.
- Un conjunto de procesamiento de paquetes que puede recaer fuertemente en un solo núcleo de CPU.
- Un solo camino que puede verse interrumpido por un solo tropiezo.
Cuando habilitas Multichannel y realmente se activa, normalmente ves:
- Mayor rendimiento en 10/25/40/100GbE
- Mejor uso de la CPU a través de núcleos
- Mejor rendimiento para múltiples clientes simultáneos
- Algo de tolerancia a fallos cuando un enlace falla (dependiendo de la configuración)
Ahora la verdad incómoda: Multichannel puede estar “habilitado” y aun así no hacer nada. Es una función con prerrequisitos. Si RSS está apagado, si la NIC está mal configurada, si forzas SMB a una sola interfaz por accidente, o si tus reglas de firewall son “creativas”, Multichannel se queda ahí educadamente sin actuar.
Qué hacer: Trata Multichannel como una dependencia en producción: verifica que esté habilitado, verifica que se negocie y verifica que realmente se usen múltiples conexiones bajo carga.
Guión de diagnóstico rápido (primero/segundo/tercero)
Esta es la vía rápida: tienes un ticket, una queja, una copia que se arrastra. Quieres encontrar el cuello de botella sin pasarte la tarde discutiendo con un switch.
Primero: prueba si SMB Multichannel está activo
- Comprueba si la función está habilitada en cliente y servidor.
- Comprueba si la sesión SMB tiene múltiples conexiones.
- Si es de una sola conexión, asume que estás en tierra de un único flujo hasta que se demuestre lo contrario.
Segundo: revisa RSS / distribución de CPU y la realidad de los enlaces NIC
- Verifica velocidad de enlace y dúplex (sí, todavía).
- Verifica que RSS esté habilitado y tenga múltiples colas.
- Observa la CPU: si un núcleo se dispara durante la transferencia, probablemente no se está paralelizando el procesamiento de paquetes.
Tercero: aisla red vs almacenamiento vs sobrecarga de funciones SMB
- Ejecuta una prueba de rendimiento de red cruda para eliminar el almacenamiento de la ecuación.
- Revisa el estado de encriptación/firmado SMB; el cifrado puede ser la opción correcta, pero no es gratuito.
- Observa la latencia del disco y la profundidad de cola en el servidor mientras copias.
Una cita que debería colgar en la pared de todos los equipos de operaciones, porque salva carreras:
«La esperanza no es una estrategia.» — General Gordon R. Sullivan
Datos interesantes y breve historia (para que el comportamiento extraño tenga sentido)
Los problemas de rendimiento de SMB parecen aleatorios hasta que recuerdas por qué SMB ha pasado: décadas de compatibilidad, golpes de seguridad y cambios de hardware. Unos hechos concretos ayudan a anclar el proceso de resolución.
- SMB nació en los años 80 y fue acumulando funciones con el tiempo, por eso el comportamiento puede diferir drásticamente entre SMB1, SMB2 y SMB3.
- SMB2 (era Vista/Server 2008) fue un rediseño mayor: menos viajes de ida y vuelta, lecturas/escrituras más grandes, mejor pipelining. Si comparaste SMB1 con SMB2, viste el salto.
- SMB3 (Windows 8/Server 2012) introdujo Multichannel y SMB Direct (RDMA), moviendo SMB de “compartir archivos de oficina” a “transporte de almacenamiento en datacenter”.
- Tras la era WannaCry, SMB1 quedó deshabilitado ampliamente en las empresas. Buena decisión de seguridad; también forzó el uso de funciones SMB modernas.
- El escalado de ventana TCP y los controles de congestión modernos importan más en enlaces de alta latencia. Un solo flujo en una red de alta capacidad puede subutilizar el ancho de banda si RTT y ajustes no son amistosos.
- El firmado y el cifrado SMB no son lo mismo: el firmado valida integridad; el cifrado proporciona confidencialidad. Ambos añaden sobrecarga de CPU; el cifrado especialmente puede volverse limitante en CPUs antiguas o bajo carga intensa.
- Multichannel no es “teaming”. El NIC teaming es agregación/failover a nivel NIC/driver; SMB Multichannel es a nivel protocolo/sesión y puede funcionar sin teaming.
- Receive Side Scaling (RSS) es el héroe silencioso en servidores de archivos con mucho tráfico: permite repartir el procesamiento de paquetes entre núcleos de CPU. Sin él, un solo núcleo puede estrangular un enlace de 25GbE como si fuera 2009.
- Los jumbo frames no son un interruptor mágico de velocidad. Pueden ayudar a reducir la sobrecarga de CPU, pero los desajustes crean pérdidas y retransmisiones misteriosas que hacen que SMB parezca “lento y inestable”.
Broma #1: SMB es como una reunión corporativa: una persona hablando a la vez es cortés, pero no es la forma de terminar nada para el viernes.
Cómo SMB se vuelve lento en producción real
“SMB va lento” no es un único problema. Es un síntoma. Las causas principales que veo en producción caen en varios grupos.
1) Sesiones SMB de conexión única en enlaces rápidos
Un enlace 10GbE puede transportar ~1.1 GB/s de carga útil en condiciones ideales. Pero un único flujo TCP puede estar limitado por:
- procesamiento de paquetes en un núcleo (especialmente si RSS está apagado o mal configurado)
- pérdidas/retransmisiones (óptica mala, presión en buffers, mismatched dúplex, mismatch de MTU)
- latencia (un RTT más alto significa crecimiento más lento de la ventana)
- comportamiento de créditos SMB bajo ciertas cargas
Multichannel ayuda porque reparte el trabajo entre múltiples conexiones y puede usar múltiples rutas/colas NIC.
2) Cifrado/firmado atascando la CPU
Las funciones de seguridad valen la pena. Pero si habilitas cifrado SMB en todos lados sin comprobar la capacidad de CPU, puedes “mejorar” tu sistema hasta un techo de rendimiento. En CPUs modernas con AES-NI esto suele ir bien. En máquinas antiguas, o en enlaces muy rápidos, no.
3) El almacenamiento es el cuello de botella, no el cable
SMB es un transporte. Si el almacenamiento del servidor no puede hacer los IOPS o el rendimiento, la velocidad de copia igualará a los discos, no a la NIC. Esto se complica cuando el almacenamiento es “rápido a veces” (aciertos de caché) y “lento a veces” (fallos de caché, escrituras RAID con penalización, snapshots, escaneo antivirus).
4) Antivirus, filtrado de archivos y drivers filtro
La protección en tiempo real en servidores de archivos puede convertir escrituras secuenciales en un desfile de paradas y arranques. Si tus copias tienen paradas periódicas y los picos de latencia de disco coinciden, revisa el escaneo en tiempo real y los drivers filtro.
5) “Optimizaciones” de red que no lo son
Deshabilitar offloads porque “alguien leyó un post”, activar jumbo frames en la mitad del camino, habilitar LACP cuando necesitabas SMB Multichannel, o forzar una sola interfaz SMB para “controlar”—así es como las buenas intenciones se convierten en incidentes.
Tareas prácticas: 12+ comandos, salidas y decisiones
A continuación hay tareas reales que ejecuto cuando SMB va lento. Cada una incluye un comando, un ejemplo de salida realista, lo que significa y qué decisión tomar.
Nota: Estos comandos se ejecutan en Windows (PowerShell / CMD). El formato de bloque de código abajo está fijo según tu petición; trata el prompt como una etiqueta de marcador.
Task 1: Confirmar que SMB Multichannel está habilitado en el cliente
cr0x@server:~$ powershell -NoProfile -Command "Get-SmbClientConfiguration | Select EnableMultichannel,EnableSecuritySignature,RequireSecuritySignature"
EnableMultichannel EnableSecuritySignature RequireSecuritySignature
----------------- ----------------------- ------------------------
True False False
Qué significa: El cliente intentará Multichannel. El firmado no es obligatorio aquí.
Decisión: Si EnableMultichannel es False, habilítalo (Task 3). Si es True, no te felicites todavía: verifica la negociación (Task 5).
Task 2: Confirmar que SMB Multichannel está habilitado en el servidor
cr0x@server:~$ powershell -NoProfile -Command "Get-SmbServerConfiguration | Select EnableMultichannel,EncryptData,RejectUnencryptedAccess"
EnableMultichannel EncryptData RejectUnencryptedAccess
----------------- ----------- ------------------------
True False False
Qué significa: El servidor permite Multichannel y no fuerza cifrado.
Decisión: Si Multichannel del servidor está apagado, enciéndelo (Task 4). Si el cifrado está forzado, planea verificar impacto en CPU y rendimiento (Task 10).
Task 3: Habilitar SMB Multichannel en el cliente (si está deshabilitado)
cr0x@server:~$ powershell -NoProfile -Command "Set-SmbClientConfiguration -EnableMultichannel $true -Force; Get-SmbClientConfiguration | Select EnableMultichannel"
EnableMultichannel
-----------------
True
Qué significa: Lado cliente configurado.
Decisión: Repite en servidores/imagenes VDI vía GPO/estado deseado. Luego verifica conexiones activas (Task 5).
Task 4: Habilitar SMB Multichannel en el servidor (si está deshabilitado)
cr0x@server:~$ powershell -NoProfile -Command "Set-SmbServerConfiguration -EnableMultichannel $true -Force; Get-SmbServerConfiguration | Select EnableMultichannel"
EnableMultichannel
-----------------
True
Qué significa: El servidor de archivos negociará Multichannel cuando los clientes lo soporten.
Decisión: Si el rendimiento era malo, vuelve a probar las transferencias y verifica conexiones SMB activas (Task 5/6).
Task 5: Verificar que la sesión SMB realmente use múltiples conexiones
cr0x@server:~$ powershell -NoProfile -Command "Get-SmbMultichannelConnection | Select ServerName,ClientInterfaceIndex,ServerInterfaceIndex,ClientIPAddress,ServerIPAddress,RSSCapable | Format-Table -AutoSize"
ServerName ClientInterfaceIndex ServerInterfaceIndex ClientIPAddress ServerIPAddress RSSCapable
---------- -------------------- -------------------- ------------- ------------- ----------
FS01 12 9 10.10.20.51 10.10.20.10 True
FS01 13 10 10.10.21.51 10.10.21.10 True
Qué significa: Dos conexiones están activas y con capacidad RSS. Esa es la forma que quieres ver.
Decisión: Si ves solo una línea, efectivamente estás en single-channel. Pasa a chequear RSS/NIC (Task 7–9).
Task 6: Revisar conexiones SMB y dialecto (¿estamos en SMB3?)
cr0x@server:~$ powershell -NoProfile -Command "Get-SmbConnection | Select ServerName,ShareName,Dialect,NumOpens,Encrypted | Format-Table -AutoSize"
ServerName ShareName Dialect NumOpens Encrypted
---------- --------- ------- -------- ---------
FS01 data 3.1.1 42 False
Qué significa: El cliente usa SMB 3.1.1 (bien). El cifrado está apagado para este share/sesión.
Decisión: Si el dialecto es inesperadamente bajo, puedes estar alcanzando limitaciones por política/compatibilidad. Si Encrypted=True y el rendimiento es pobre, valida CPU (Task 10).
Task 7: Verificar velocidad y estado del enlace NIC en cliente/servidor
cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Select Name,Status,LinkSpeed | Format-Table -AutoSize"
Name Status LinkSpeed
---- ------ ---------
Ethernet0 Up 10 Gbps
Ethernet1 Up 10 Gbps
Qué significa: Los enlaces están arriba a la velocidad esperada.
Decisión: Si ves 1 Gbps en un enlace que debería ser 10GbE, detente. Arregla cableado/óptica/configuración del puerto del switch antes de culpar a SMB.
Task 8: Comprobar que RSS está habilitado y tiene colas (cliente y servidor)
cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapterRss | Select Name,Enabled,NumberOfReceiveQueues,MaxNumberOfReceiveQueues | Format-Table -AutoSize"
Name Enabled NumberOfReceiveQueues MaxNumberOfReceiveQueues
---- ------- --------------------- ------------------------
Ethernet0 True 8 16
Ethernet1 True 8 16
Qué significa: RSS está habilitado con múltiples colas. Esto es fundamental para alto rendimiento SMB en una NIC rápida y útil para Multichannel.
Decisión: Si RSS está deshabilitado o las colas son 1, habilita RSS (Task 9). Luego vuelve a probar y observa la distribución de CPU.
Task 9: Habilitar RSS (con cuidado) en un adaptador
cr0x@server:~$ powershell -NoProfile -Command "Enable-NetAdapterRss -Name Ethernet0; Get-NetAdapterRss -Name Ethernet0 | Select Name,Enabled,NumberOfReceiveQueues"
Name Enabled NumberOfReceiveQueues
---- ------- ---------------------
Ethernet0 True 8
Qué significa: RSS ahora está habilitado en esa NIC.
Decisión: Si habilitar RSS causa inestabilidad (raro, específico del driver), actualiza drivers/firmware de la NIC. No “resuelvas” apagando RSS permanentemente a menos que te guste lidiar incidencias a las 2 a.m.
Task 10: Comprobar si el cifrado SMB es obligatorio y estimar riesgo para la CPU
cr0x@server:~$ powershell -NoProfile -Command "Get-SmbShare | Select Name,EncryptData | Format-Table -AutoSize"
Name EncryptData
---- -----------
data False
secure True
Qué significa: Solo el share secure fuerza cifrado.
Decisión: Si “todo está lento” y el cifrado está activado en todas partes, mide CPU durante las copias. Si la CPU es el límite, considera cifrado selectivo (según clasificación de datos) o actualizar CPUs/funciones offload de NIC—no desactives el cifrado solo por conveniencia.
Task 11: Vigilar puntos calientes de CPU durante una copia (lado servidor)
cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\Processor(*)\% Processor Time' -SampleInterval 1 -MaxSamples 5 | Select -ExpandProperty CounterSamples | Sort CookedValue -Descending | Select -First 5 Path,CookedValue"
Path CookedValue
---- -----------
\\FS01\processor(3)\% processor time 96.8125
\\FS01\processor(7)\% processor time 22.125
\\FS01\processor(5)\% processor time 18.4375
\\FS01\processor(_total)\% processor time 31.020
\\FS01\processor(1)\% processor time 14.625
Qué significa: Un núcleo está saturado mientras la CPU total no lo está. Territorio clásico de “cola única / flujo único / mala distribución”.
Decisión: Revisa RSS, colas y conexiones Multichannel. Si el cifrado está activado, podrías estar alcanzando sobrecarga cripto monohilo en partes de la pila según la carga y el sistema.
Task 12: Comprobar la selección de interfaz de red cliente para SMB y sus capacidades
cr0x@server:~$ powershell -NoProfile -Command "Get-SmbClientNetworkInterface | Select InterfaceIndex,IPAddress,RSSCapable,LinkSpeed | Format-Table -AutoSize"
InterfaceIndex IPAddress RSSCapable LinkSpeed
-------------- --------- ---------- ---------
12 10.10.20.51 True 10 Gbps
13 10.10.21.51 True 10 Gbps
Qué significa: El cliente ve dos interfaces compatibles con SMB, ambas con RSS y rápidas.
Decisión: Si las interfaces esperadas no aparecen aquí, SMB no las usará para Multichannel. Arregla enrutamiento, binding de NIC o reglas de firewall para que las interfaces sean elegibles.
Task 13: Medir rendimiento bruto de red (elimina discos de la historia)
cr0x@server:~$ iperf3 -c fs01 -P 4 -t 10
Connecting to host fs01, port 5201
[ 5] local 10.10.20.51 port 53122 connected to 10.10.20.10 port 5201
[ 7] local 10.10.20.51 port 53124 connected to 10.10.20.10 port 5201
[ 9] local 10.10.20.51 port 53126 connected to 10.10.20.10 port 5201
[ 11] local 10.10.20.51 port 53128 connected to 10.10.20.10 port 5201
[SUM] 0.00-10.00 sec 10.6 GBytes 9.10 Gbits/sec 0 sender
[SUM] 0.00-10.00 sec 10.6 GBytes 9.09 Gbits/sec receiver
Qué significa: La red puede hacer ~9.1 Gbps. El cable no es tu problema hoy.
Decisión: Si iperf también es lento, arregla la ruta de red/MTU/pérdida. Si iperf es rápido pero SMB es lento, céntrate en configuración SMB, CPU, cifrado y almacenamiento.
Task 14: Comprobar retransmisiones y errores (captura rápida sin Wireshark)
cr0x@server:~$ powershell -NoProfile -Command "netstat -s -p tcp | Select-String -Pattern 'Retransmitted|Segments Retransmitted|Errors'"
Segments Retransmitted = 1842
Qué significa: Existen retransmisiones. Algunas son normales, pero muchas durante una sola copia es sospechoso.
Decisión: Si las retransmisiones aumentan rápidamente durante las transferencias, revisa mismatches de MTU, dúplex, óptica, drops en buffers del switch y problemas de driver NIC. SMB parecerá “lento” porque TCP hace control de daños.
Task 15: Validar MTU/jumbo frames consistencia (lado Windows)
cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface | Where-Object {$_.InterfaceAlias -like 'Ethernet*' -and $_.AddressFamily -eq 'IPv4'} | Select InterfaceAlias,NlMtu | Format-Table -AutoSize"
InterfaceAlias NlMtu
-------------- -----
Ethernet0 9000
Ethernet1 1500
Qué significa: Tienes un desajuste de MTU entre interfaces. Si SMB Multichannel reparte tráfico entre ambas, puedes obtener comportamiento impredecible.
Decisión: Estandariza MTU de extremo a extremo según el diseño de red. Si no puedes, restringe qué interfaces puede usar SMB (con cuidado), o arregla la segunda interfaz.
Task 16: Revisar latencia de disco en el servidor durante la copia
cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\PhysicalDisk(_Total)\Avg. Disk sec/Read','\PhysicalDisk(_Total)\Avg. Disk sec/Write' -SampleInterval 1 -MaxSamples 5 | Select -ExpandProperty CounterSamples | Format-Table -AutoSize Path,CookedValue"
Path CookedValue
---- -----------
\\FS01\physicaldisk(_total)\avg. disk sec/read 0.0021
\\FS01\physicaldisk(_total)\avg. disk sec/write 0.0385
Qué significa: Escrituras promediando ~38 ms no son “almacenamiento rápido”. Eso limitará el rendimiento de escritura SMB sin importar las funciones de red.
Decisión: Si los picos de latencia de disco se correlacionan con SMB lento, estás frente a contención de almacenamiento, penalización RAID, overhead de snapshots, escaneo antivirus o un backend limitado.
Tres mini-historias corporativas (qué sucede realmente)
Mini-historia 1: El incidente causado por una suposición equivocada
El ticket era simple: “Los shares de Ingeniería están lentos; los builds se agotan.” Era lunes, claro, y el on-call ya había recibido pings de Slack durante una hora. El servidor de archivos tenía dos puertos 10GbE. Los puertos del switch parecían limpios. El panel del array de almacenamiento estaba en verde. Todos asumieron que la red estaba bien y que el almacenamiento estaba bien, así que debía ser “SMB siendo SMB”.
La suposición equivocada: “Dos NICs significa que la copia usará automáticamente ambas.” Alguien había configurado teaming de NIC años antes, luego lo quitó durante una actualización de drivers y nunca revisó el perfil de rendimiento. SMB Multichannel estaba deshabilitado en el servidor de archivos porque un antiguo baseline de hardening lo había desactivado y nadie lo notó.
Los síntomas eran clásicos: un flujo TCP clavaba un único núcleo de CPU, el rendimiento rondaba lo que un núcleo ocupado podía procesar y múltiples clientes quedaban en cola uno detrás de otro. El servidor tenía CPU total de sobra, pero el trabajo no se distribuía.
La solución fue dolorosamente aburrida: habilitar SMB Multichannel, verificar que RSS estuviera activado y validar que múltiples conexiones SMB aparecieran para clientes activos. El rendimiento se duplicó para muchos clientes inmediatamente y el coro de “la red está lenta” se silenció hasta el siguiente incidente, como es tradición.
La lección no fue “Multichannel es magia”. Fue: no asumas que estás usando las funciones hardware que compraste. Verifica el comportamiento negociado, no la casilla marcada.
Mini-historia 2: La optimización que salió mal
En otro lugar, otro tipo de dolor. Una iniciativa de seguridad decidió que todos los shares de archivos deberían requerir cifrado SMB. Objetivo razonable. El despliegue fue rápido, amplio y aprobado por varios comités, lo que indica que nadie lo benchmarkeó.
En días, los usuarios se quejaron de que las copias grandes eran “intermitentes”. La CPU del servidor de archivos no estaba al máximo en general, pero el sistema se sentía extrañamente limitado en horas pico. El equipo de almacenamiento señalaba al equipo de red. El equipo de red señalaba al de almacenamiento. Mientras tanto, los desarrolladores empezaron a copiar datos localmente, lo cual nunca es la victoria de cumplimiento que alguien quería.
La causa raíz fue predecible: el cifrado añadió sobrecarga de CPU que movió el cuello de botella de la NIC a la CPU, y bajo ciertas cargas el costo cripto se concentró de manera que no escalaba perfectamente con los núcleos. Multichannel ayudó algo, RSS ayudó algo, pero el techo fundamental se movió.
El equipo reculó la política global y la reemplazó por cifrado a nivel de share para datasets sensibles, además de un plan de renovación de hardware para los servidores que realmente necesitaban cifrado siempre activo a alto rendimiento. Seguridad ganó mejoras reales. Operaciones recuperó rendimiento. Nadie pudo fingir que la física era opcional.
Broma #2: Activar el cifrado en todas partes sin probar es como poner una calcomanía de turbo en tu coche y esperar que el motor se sienta motivado.
Mini-historia 3: La práctica aburrida pero correcta que salvó el día
Otra organización, otra plataforma de archivos. Ejecutaban trimestralmente “chequeos aburridos” en sus servidores de archivos Windows: exportar configuraciones SMB, capturar versiones de driver de NIC, validar estado de RSS y ejecutar una prueba de rendimiento estandarizada desde un host de salto. Nada heroico. Ninguna sorpresa a medianoche. Solo un ritual.
Durante un trimestre, la prueba mostró una caída de rendimiento en un nodo del cluster. Nada estaba “caído”. Los usuarios aún no se habían quejado. Pero la tendencia era obvia: el nodo era más lento que sus hermanos por un amplio margen.
Porque tenían líneas base, compararon configuraciones y encontraron que tras una actualización de firmware la NIC había quedado con RSS deshabilitado solo en ese nodo. Era un único toggle. La actualización del proveedor no había “roto SMB”; había cambiado un comportamiento de NIC crítico para el rendimiento.
Rehabilitaron RSS, volvieron a ejecutar la prueba y el nodo volvió a alinearse. Sin incidente. Sin correos ejecutivos. Los mejores outages son los que no ocurren.
Errores comunes: síntoma → causa raíz → solución
Esta sección es directa porque tu tiempo es valioso.
1) Rendimiento estancado alrededor de 80–200 MB/s en 10GbE
Síntoma: Una copia secuencial grande nunca llega a la tasa de línea; la CPU muestra un núcleo caliente.
Causa raíz: Conexión SMB única y/o RSS deshabilitado (procesamiento por núcleo único).
Solución: Habilita SMB Multichannel en ambos extremos; verifica múltiples conexiones multichannel; habilita RSS y asegúrate de múltiples colas de recepción; actualiza drivers/firmware de NIC si RSS se comporta mal.
2) Multichannel “habilitado” pero solo aparece una conexión
Síntoma: EnableMultichannel=True, pero Get-SmbMultichannelConnection muestra una sola fila.
Causa raíz: Solo una interfaz/IP elegible; la lista de interfaces cliente SMB no incluye la segunda NIC; firewall/enrutamiento impide la ruta paralela; interfaces no compatibles con RSS.
Solución: Revisa Get-SmbClientNetworkInterface y Get-SmbServerNetworkInterface; asegura que ambos extremos tengan IPs alcanzables en cada interfaz; confirma compatibilidad RSS; corrige reglas de firewall para SMB (TCP 445) en cada interfaz.
3) Las copias son rápidas para lecturas, terribles para escrituras
Síntoma: Descargar del share está bien; subir se arrastra; picos de latencia de escritura en disco.
Causa raíz: Penalización/latencia del backend de almacenamiento (RAID, snapshots, aprovisionamiento thin, contención) o escaneo antivirus en escrituras.
Solución: Mide latencia de escritura durante la copia; verifica exclusiones/ajustes de antivirus; valida salud del pool y comportamiento de la caché de escritura; evita diagnosticar esto como “red”.
4) Rendimiento es intermitente: rápido y luego se detiene
Síntoma: La velocidad de copia oscila; los usuarios describen “cuelgues”.
Causa raíz: Retransmisiones por mismatch de MTU, microbursts, drops en buffers del switch o offloads problemáticos; a veces drivers filtro.
Solución: Revisa retransmisiones; estandariza MTU extremo a extremo; valida contadores de puertos del switch; considera deshabilitar solo la offload problemática tras evidencia (no por corazonadas).
5) SMB es lento solo en una subred/VLAN
Síntoma: Mismo servidor, diferente cliente en red, rendimiento muy distinto.
Causa raíz: Diferente MTU de ruta, ACLs, políticas QoS o asimetría de enrutamiento; a veces un “optimizador WAN” “útil”.
Solución: Compara resultados de iperf por subred; revisa MTU y retransmisiones; verifica simetría de enrutamiento; audita políticas QoS.
6) Todo se volvió más lento después del “hardening”
Síntoma: Tras aplicar el baseline, throughput SMB cae y la CPU aumenta.
Causa raíz: Firmado obligatorio en todas partes; cifrado forzado en todas partes; Multichannel deshabilitado; ajustes de compatibilidad legacy.
Solución: Inspecciona deltas de configuración SMB cliente/servidor; aplica cifrado de forma selectiva; mantiene firmado donde se necesita; re-habilita Multichannel con validación.
Listas de verificación / plan paso a paso
Checklist A: Recuperar throughput esperado en LAN 10/25GbE
- Confirma velocidad de enlace en NICs cliente y servidor (
Get-NetAdapter). - Confirma dialecto SMB es 3.x (
Get-SmbConnection). - Habilita y verifica SMB Multichannel en ambos extremos (
Get-Smb*Configuration,Get-SmbMultichannelConnection). - Verifica RSS está habilitado con múltiples colas (
Get-NetAdapterRss). - Ejecuta iperf para validar que el rendimiento bruto de red cumple expectativas.
- Observa distribución de CPU durante una transferencia sostenida (contadores Perf).
- Revisa latencia de disco durante la misma transferencia (contadores Perf).
- Sólo entonces empieza a tocar offloads, jumbo frames y toggles “avanzados”.
Checklist B: Verificar que Multichannel está haciendo trabajo real (no solo habilitado)
- En el cliente, lista interfaces cliente SMB (
Get-SmbClientNetworkInterface). Quieres múltiples interfaces elegibles. - En el servidor, lista interfaces servidor SMB (usa
Get-SmbServerNetworkInterfacedonde esté disponible) y confirma IPs correspondientes. - Inicia una transferencia sostenida (archivo grande, no un directorio de archivos pequeños).
- Revisa
Get-SmbMultichannelConnectionmientras la transferencia corre. - Si aún ves una conexión, investiga firewall/enrutamiento/MTU/elegibilidad RSS.
Checklist C: Decidir si el cifrado es tu cuello de botella
- Confirma si el cifrado está activo por share/sesión (
Get-SmbShare,Get-SmbConnection). - Ejecuta la misma copia con cifrado desactivado en un share de prueba (si la política lo permite) para comparar.
- Durante la copia cifrada, observa CPU y puntos calientes por núcleo.
- Si la CPU limita, elige una de las opciones: más CPU, cifrado selectivo o RDMA (SMB Direct) donde sea apropiado.
Preguntas frecuentes
1) ¿SMB Multichannel es lo mismo que NIC teaming?
No. El teaming es una construcción a nivel NIC/driver; Multichannel es SMB usando múltiples conexiones a nivel de protocolo/sesión. Puedes usar Multichannel sin teaming, y a menudo deberías.
2) Si tengo una única NIC 25GbE, ¿Multichannel puede ayudar?
A veces. Multichannel puede crear múltiples conexiones sobre una sola interfaz, pero la mayor ganancia en una NIC rápida única suele venir de RSS y de tener suficientes colas de recepción y CPU para procesar paquetes.
3) ¿Por qué una única copia SMB no alcanza la velocidad de línea?
Porque un único flujo TCP puede estar limitado por procesamiento de paquetes en un núcleo, control de congestión, pérdidas y latencia. Multichannel y RSS reducen esos cuellos al paralelizar el trabajo.
4) ¿SMB Multichannel se activa automáticamente cuando está habilitado?
Se negocia automáticamente, pero solo si ambos lados lo soportan y detectan múltiples rutas/interfases elegibles. “Habilitado” no es lo mismo que “activo”. Verifica siempre con Get-SmbMultichannelConnection.
5) ¿Debería habilitar jumbo frames para arreglar SMB lento?
No como primer movimiento. Los jumbo frames pueden ayudar la eficiencia de CPU, pero la implementación parcial causa pérdidas/retransmisiones que empeoran SMB. Arregla Multichannel/RSS y confirma ausencia de pérdida primero.
6) ¿El cifrado SMB matará el rendimiento?
Depende de la capacidad de CPU, la carga y la velocidad de línea. En CPUs modernas puede estar bien; en servidores antiguos o enlaces muy rápidos puede volverse limitado por CPU. Mide antes y después, y considera cifrado selectivo.
7) ¿Por qué copiar muchos archivos pequeños es más lento que uno grande?
Operaciones de metadatos, enumeración de directorios y costes por abrir/cerrar archivo dominan. Multichannel ayuda el throughput, pero no elimina la chatarrería inherente y el overhead de metadatos del almacenamiento con “millones de archivos pequeños”.
8) ¿Puede el antivirus en el servidor de archivos enlentecer SMB?
Sí, especialmente en escrituras. El escaneo en tiempo real puede añadir latencia por operación y convertir throughput estable en ráfagas. Coordina exclusiones y modos de escaneo con los equipos de seguridad y valida con contadores de latencia de disco.
9) ¿Cuál es la diferencia entre SMB Multichannel y SMB Direct?
Multichannel usa múltiples conexiones TCP. SMB Direct usa RDMA (NICs y configuración especial) para evitar partes de la pila TCP/IP y reducir latencia y uso de CPU. Genial cuando se puede ejecutar; Multichannel es la ganancia más común.
10) ¿Cuál es la manera más rápida de demostrar que no es la red?
Ejecuta iperf entre los mismos hosts en las mismas interfaces y compara. Si iperf alcanza el rendimiento esperado pero SMB no, el cuello de botella probablemente esté en la configuración SMB, la CPU, el cifrado o el almacenamiento.
Conclusión: próximos pasos que puedes hacer hoy
Si SMB va lento, deja de tratarlo como un problema místico de Windows. Es un sistema: NICs, colas de CPU, comportamiento TCP, sobrecarga de seguridad y latencia de almacenamiento se muestran en el número final.
Tus próximos pasos prácticos:
- Verifica que SMB Multichannel esté habilitado en cliente y servidor, y luego verifica que esté activo con
Get-SmbMultichannelConnection. - Valida RSS y la cantidad de colas en las NICs que llevan tráfico SMB.
- Mide rendimiento de red bruto con iperf para separar red de SMB/almacenamiento.
- Mide CPU y latencia de disco durante la misma transferencia; decide qué subsistema te está limitando realmente.
- Sé deliberado con el cifrado: aplícalo donde sea obligatorio y presupuestado para la CPU.
Haz eso y “SMB va lento” normalmente se convierte en un cuello de botella concreto y solucionable. Que es el mejor tipo de problema: el que tiene fin.