SMB Multichannel: cuándo ayuda (y cuándo perjudica)

Qué hace realmente SMB Multichannel (y qué no hace)

SMB Multichannel es una característica de SMB 3.x en la que una única sesión SMB puede usar múltiples conexiones TCP en paralelo. Esas conexiones pueden usar diferentes NICs, diferentes IPs y, en algunos casos, diferentes rutas físicas. El objetivo es simple: agregar ancho de banda y mejorar la resiliencia sin necesitar agregación de enlaces en el switch.

La gran promesa: ancho de banda y redundancia sin el drama de LACP

En un diseño bueno, Multichannel hace dos cosas muy prácticas:

• Escalado de rendimiento: múltiples conexiones SMB pueden leer/escribir simultáneamente, moviendo más datos de los que una sola conexión TCP podría lograr.
• Conmutación por error transparente: si una NIC/ruta cae, SMB puede continuar por las conexiones restantes (dependiendo del tipo de fallo y del momento).

No es magia. No arregla discos lentos. No elimina la pérdida de paquetes. No mejora la latencia en un switch congestionado. Sí, en cambio, complica los patrones de tráfico—que es una forma educada de decir: tus suposiciones quedan examinadas por la realidad.

Lo que Multichannel no es

• No es teaming de NIC: el teaming vincula enlaces en L2/L3; SMB Multichannel es un comportamiento a nivel de aplicación. Pueden coexistir, pero así surgen outages interesantes.
• No garantiza «balanceo perfecto»: los flujos pueden no distribuirse de manera uniforme. Un camino aún puede llevar la mayor parte de la carga.
• No sustituye a QoS: si compartes el mismo uplink congestionado, solo estás añadiendo más flujos al mismo atasco de tráfico.

Cómo decide qué usar

Multichannel descubre múltiples «interfaces cliente-servidor» basadas en direcciones IP, propiedades de la NIC y (en Windows) la capacidad RSS (Receive Side Scaling) y la capacidad RDMA. Luego crea una o más conexiones por interfaz, influenciado por factores como el número de colas RSS y si RDMA está disponible.

Conclusión operativa: Multichannel es una característica de red + controlador + SO. Los ingenieros de almacenamiento tienden a verla como una característica de almacenamiento. Los ingenieros de red la ven como una aplicación. Es ambas cosas. Por eso puede sentirse como un fantasma en la máquina.

Una idea parafraseada atribuida a John Allspaw (operaciones/fiabilidad): La falla rara vez es un único error; es una propiedad emergente de sistemas complejos. SMB Multichannel es una buena manera de añadir complejidad—a veces del tipo bueno.

Cuándo Multichannel ayuda: la ruta ideal

1) Tienes paralelismo real para explotar

Multichannel brilla cuando la carga puede realmente consumir más ancho de banda: lecturas/escrituras secuenciales grandes, copias multihilo, almacenamiento de VM sobre SMB (Hyper-V), flujos de backup, flujos de trabajo multimedia, granjas de compilación. Si tu carga es una aplicación de un solo hilo que lee archivos pequeños, puede que no veas mejora y sí muchas variables nuevas.

2) Tienes rutas reales múltiples, no solo direcciones IP extras

Dos NICs conectadas al mismo switch top-of-rack con un único uplink 10Gb no son «dos rutas». Son dos entradas a la misma autopista. Multichannel aún ayuda con cuellos de botella a nivel de host (limitaciones de un solo flujo), pero no solucionará la congestión aguas arriba.

Las mejores ganancias provienen de:

• NICs duales en cliente y servidor
• Switches separados (o al menos caminos ASIC separados en el switch)
• VLANs/subredes separadas para prevenir asimetrías de enrutamiento accidentales
• Ethernet limpia y con baja pérdida (especialmente si RDMA está en juego)

3) RSS está habilitado y realmente funciona

Para SMB sin RDMA, quieres RSS para que múltiples núcleos CPU puedan procesar la ruta de recepción. Si RSS está desactivado, un único núcleo puede convertirse en el cuello de botella, y Multichannel puede crear más trabajo sin elevar el techo.

4) RDMA (SMB Direct) está presente y estable

Con NICs compatibles RDMA (RoCE o iWARP), SMB puede usar SMB Direct, evitando partes de la pila TCP/IP para reducir carga de CPU y mejorar la latencia. Multichannel se convierte entonces en una forma de usar múltiples interfaces RDMA y ganar tanto rendimiento como resiliencia.

Si RDMA es estable, Multichannel suele ser una gran ventaja. Si RDMA es inestable, Multichannel puede crear una casa encantada: pausas intermitentes, comportamientos de retroceso y tickets estilo «solo pasa los martes».

5) Te importa más el comportamiento de conmutación por error que el pico de rendimiento

Incluso si no necesitas ancho de banda agregado, Multichannel puede ser una característica de resiliencia. Una sola caída de enlace no debería tumbar un recurso compartido ocupado. No es un sustituto de alta disponibilidad adecuada, pero es una capa útil en la pila.

Cuándo Multichannel perjudica: modos de fallo reproducibles

1) Enrutamiento asimétrico o equipos de red «útiles»

Multichannel abre múltiples conexiones. Si tu enrutamiento o políticas de firewall tratan los caminos de forma distinta, obtendrás latencias inconsistentes, retransmisiones o pérdidas directas. Dispositivos con estado también pueden confundirse si los flujos atraviesan middleboxes diferentes inesperadamente.

Síntomas: pausas aleatorias, rendimiento desigual, latencias cola larga en operaciones de archivos. La red parece «bien» hasta que desglozas por flujo.

2) Habilitaste teaming de NIC y Multichannel sin un plan

Esto no siempre está mal, pero con frecuencia es inútil o contraproducente. El teaming ya ofrece una interfaz única a SMB; Multichannel entonces ve menos interfaces distintas. Peor aún, algunos modos de teaming interactúan mal con RSS, offloads o hashing del switch.

Si haces esto porque «más es más», para. Diseña primero.

3) Pérdida de paquetes, microbursts o mala sintonía DCB/PFC (especialmente RDMA)

RDMA quiere un carril limpio. En RoCE, a menudo se usa DCB/PFC para evitar drops. Si configuras mal PFC puedes crear bloqueo head-of-line donde una clase de prioridad congestionada detiene a las demás. Multichannel puede amplificar el radio de impacto al empujar más tráfico en paralelo.

Chiste #1: RDMA es como un coche de carreras—rápido, caro y te castigará por conducirlo como si fuera de alquiler.

4) Sobrecarga de CPU y tormentas de interrupciones por «demasiadas buenas intenciones»

Más canales significa más conexiones, más interrupciones, más estado por conexión, más contención de locks en el kernel. Si el driver o firmware de tu NIC no está contento, Multichannel puede convertir un servidor cómodo en una máquina limitada por CPU que aún se siente «lenta».

Esto es común con:

• Drivers/firmware antiguos
• VMs con vCPU limitadas y vecinos ruidosos
• Conteos de colas RSS mal ajustados

5) La latencia de almacenamiento se vuelve visible (Multichannel no la causó—los usuarios solo la descubrieron)

Cuando eliminas un cuello de botella de red, expones el siguiente. Quizá sea el pool de discos, quizá sean IOPS de metadatos, quizá sea el antivirus en el servidor de archivos. Multichannel recibe la culpa porque fue el último cambio. A veces es culpable. A menudo es solo el mensajero.

6) «Funcionó en el laboratorio» (porque el laboratorio no tenía entropía)

Multichannel en producción es sensible al desorden del mundo real: flaps de enlace, presión de buffers en switches, peculiaridades de firmware, clientes no uniformes y ese dispositivo legacy que hace algo ilegal con timestamps TCP.

Chiste #2: El laboratorio es donde los diseños van a sentirse bien consigo mismos.

Datos interesantes y contexto histórico

• SMB 3.0 debutó con Windows Server 2012, trayendo Multichannel y SMB Direct al uso general en servidores de archivos Windows.
• Multichannel fue diseñado en parte para virtualización: Hyper-V sobre SMB necesitaba tanto alto rendimiento como resiliencia sin exigir a todas las organizaciones convertirse en expertas en agregación de enlaces.
• SMB Direct (RDMA) es una capacidad separada que Multichannel puede usar; Multichannel es la lógica de «múltiples rutas», RDMA es el transporte «vía rápida».
• La capacidad RSS influye cuántas conexiones se crean en Windows; Multichannel puede abrir múltiples conexiones por interfaz para paralelizar el procesamiento de recepción.
• Multichannel no requiere configuración de switch de la misma manera que LACP, por eso es atractivo en entornos con control de cambios de red muy restrictivo.
• El cifrado SMB puede reducir el rendimiento y aumentar el uso de CPU; Multichannel puede ayudar a recuperar rendimiento, pero también puedes encontrarte limitado por CPU antes.
• SMB sobre QUIC existe (Windows más reciente), pero es otra historia de transporte; el comportamiento clásico de Multichannel está ligado a SMB sobre TCP.
• Linux Samba añadió soporte Multichannel SMB3 más tarde que Windows; durante años fue una ventaja de Windows en entornos mixtos.

Guía rápida de diagnóstico (primero/segundo/tercero)

Primero: decide si tienes un problema de red, host o almacenamiento

1. Verifica si SMB realmente está usando Multichannel (no lo asumas). Si no lo está, deja de buscar «bugs de Multichannel».
2. Comprueba pérdida de paquetes/retransmisiones. Si hay pérdida, optimizar rendimiento es teatro.
3. Comprueba saturación de CPU y presión de interrupciones en cliente y servidor. Si un núcleo está al máximo, tu «10GbE» es decorativo.
4. Comprueba latencia de almacenamiento en el servidor de archivos. Si tus discos son lentos, el paralelismo de red solo encolará más rápido.

Segundo: aísla una variable a la vez

1. Prueba NIC única vs Multichannel (deshabilitar/habilitar) para confirmar causalidad.
2. Prueba desde un cliente único vs varios clientes. Algunos problemas son solo con concurrencia.
3. Prueba secuencial grande vs aleatorio pequeño. El cuello de botella cambia.

Tercero: valida la simetría de ruta y la selección de interfaz

1. Confirma qué IPs se usan para las conexiones SMB.
2. Confirma que el diseño de VLAN/subred evita enrutamiento inesperado.
3. Confirma que teaming, bridging o switches virtuales no están ocultando interfaces a SMB.

Tareas prácticas: comandos, salida y decisiones (12+)

Estas tareas asumen que estás solucionando SMB Multichannel entre un cliente Windows y un servidor de archivos Windows, con algunas herramientas Linux donde son útiles. Los comandos se muestran desde un host Linux de salto y PowerShell de Windows. Sí, el prompt es una mentira; es un envoltorio consistente para que los bloques de código coincidan con el formato requerido. Ejecuta los comandos de PowerShell en PowerShell.

Task 1: Verify Multichannel is enabled on Windows

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbClientConfiguration | Select EnableMultiChannel"
EnableMultiChannel
------------------
True

Qué significa: El cliente tiene permitido usar Multichannel.

Decisión: Si False, habilítalo para pruebas (Set-SmbClientConfiguration -EnableMultiChannel $true) o mantenlo apagado intencionalmente y deja de esperar comportamiento multicanal.

Task 2: Verify Multichannel is enabled on the server

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbServerConfiguration | Select EnableMultiChannel"
EnableMultiChannel
------------------
True

Qué significa: El servidor negociará Multichannel.

Decisión: Si False, habilitarlo suele ser seguro en servidores modernos—a menos que estés en un entorno con controladores conocidos como problemáticos. Si estás solucionando inestabilidad, deshabilítalo temporalmente para confirmar causalidad.

Task 3: See what SMB thinks the interfaces are (client-side)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbClientNetworkInterface | Sort-Object InterfaceIndex | Format-Table InterfaceIndex,IPAddress,RssCapable,RdmaCapable,LinkSpeed"
InterfaceIndex IPAddress      RssCapable RdmaCapable LinkSpeed
-------------- ---------      ---------- ----------  ---------
12             10.10.10.21    True       False       10 Gbps
13             10.10.20.21    True       False       10 Gbps

Qué significa: SMB ve dos interfaces cliente, ambas con RSS. Buena línea base.

Decisión: Si una muestra RssCapable False o LinkSpeed incorrecto, puede que no consigas paralelismo. Arregla el driver de la NIC/configuración RSS antes de culpar a SMB.

Task 4: Confirm the server’s SMB network interfaces

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbServerNetworkInterface | Sort-Object InterfaceIndex | Format-Table InterfaceIndex,IPAddress,RssCapable,RdmaCapable,LinkSpeed"
InterfaceIndex IPAddress      RssCapable RdmaCapable LinkSpeed
-------------- ---------      ---------- ----------  ---------
9              10.10.10.10    True       False       10 Gbps
10             10.10.20.10    True       False       10 Gbps

Qué significa: El servidor está igualmente multi-homed para SMB.

Decisión: Si el servidor solo lista una interfaz, revisa si la otra NIC está en un team, está caída, en un perfil distinto o filtrada por métricas de interfaz SMB.

Task 5: Confirm an SMB session is using multiple channels

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbMultichannelConnection | Format-Table ServerName,ClientIPAddress,ServerIPAddress,ClientRSSCapable,State"
ServerName ClientIPAddress ServerIPAddress ClientRSSCapable State
---------- -------------- -------------- --------------- -----
FS01       10.10.10.21    10.10.10.10    True            Active
FS01       10.10.20.21    10.10.20.10    True            Active

Qué significa: Existen dos canales activos. Multichannel es real, no teórico.

Decisión: Si solo ves una conexión, no estás multicanalizando. Investiga descubrimiento de interfaces, DNS, enrutamiento, restricciones SMB o que la carga de trabajo no esté disparando canales extra.

Task 6: Check whether SMB is falling back from RDMA to TCP (if RDMA is expected)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbMultichannelConnection | Select ServerName,ClientIPAddress,ServerIPAddress,RdmaCapable | Format-Table"
ServerName ClientIPAddress ServerIPAddress RdmaCapable
---------- -------------- -------------- ----------
FS01       10.10.30.21    10.10.30.10    True
FS01       10.10.40.21    10.10.40.10    True

Qué significa: Las interfaces son RDMA-capables. Eso es necesario, no suficiente.

Decisión: Si RdmaCapable es False inesperadamente, confirma modelo/driver de NIC y que RDMA esté habilitado en SO y en el switch (y que las políticas VLAN/MTU/DCB coincidan).

Task 7: Observe TCP retransmits from a Linux host near the path

cr0x@server:~$ ss -ti dst 10.10.10.10 | head -n 12
ESTAB 0 0 10.10.10.21:49822 10.10.10.10:445
	 cubic wscale:7,7 rto:204 rtt:1.22/0.41 ato:40 mss:1448 pmtu:1500 rcvmss:1448 advmss:1448 cwnd:10 bytes_acked:1294832 segs_out:985 segs_in:902 send 95.0Mbps lastsnd:12 lastrcv:12 lastack:12 pacing_rate 190Mbps retrans:0/0

Qué significa: Contadores retrans en 0 sugiere que no hay pérdida visible en ese flujo.

Decisión: Si las retransmisiones suben durante los bloqueos, arregla la red primero: óptica mala, buffers congestionados, MTU mismatched o policing.

Task 8: Confirm MTU consistency (Linux example)

cr0x@server:~$ ip link show dev eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:aa:bb:cc brd ff:ff:ff:ff:ff:ff

Qué significa: MTU 9000 en una interfaz. Si otras son 1500, tienes una discordancia.

Decisión: Mantén MTU consistente extremo a extremo por VLAN. Marcos jumbo desplegados parcialmente son una fuente clásica de «funciona hasta que no funciona».

Task 9: Spot RSS state on Windows NICs

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapterRss | Format-Table Name,Enabled,NumberOfReceiveQueues,MaxNumberOfReceiveQueues"
Name      Enabled NumberOfReceiveQueues MaxNumberOfReceiveQueues
----      ------- --------------------- ------------------------
Ethernet1 True    8                     16
Ethernet2 True    8                     16

Qué significa: RSS está habilitado, 8 colas activas.

Decisión: Si RSS está deshabilitado, habilítalo. Si las colas son pocas para tus CPU/NIC, puedes estar limitado en recepción. Si son demasiadas, puedes desperdiciar CPU e incrementar contención. Ajusta deliberadamente.

Task 10: Measure per-NIC throughput to see whether traffic is actually split

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\Network Interface(*)\Bytes Total/sec' -SampleInterval 1 -MaxSamples 3 | Select -ExpandProperty CounterSamples | Sort-Object InstanceName | Select InstanceName,CookedValue"
InstanceName                         CookedValue
------------                         -----------
Intel[R] Ethernet 10G 2              485000000
Intel[R] Ethernet 10G 1              512000000

Qué significa: Ambas NICs llevan tráfico significativo. Multichannel está proporcionando ancho de banda agregado.

Decisión: Si una NIC está cercana a cero, puede que tengas problemas de métricas de interfaz, asimetría de ruta o un camino degradado (SMB puede evitarlo).

Task 11: Check SMB client-side connection details (including dialect)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbConnection | Format-Table ServerName,ShareName,Dialect,NumOpens,ContinuouslyAvailable"
ServerName ShareName Dialect NumOpens ContinuouslyAvailable
---------- --------- ------- -------- ---------------------
FS01       data      3.1.1   42       False

Qué significa: Dialect 3.1.1 indica SMB moderno. Bien. La disponibilidad continua depende de la configuración de share/cluster.

Decisión: Si ves SMB 2.x, te faltan funciones y puedes estar atascado en comportamiento legacy por políticas, servidor antiguo o ajustes de compatibilidad.

Task 12: Check server CPU pressure quickly (Linux or Windows Server Core via typeperf is fine; here’s Linux top as proxy)

cr0x@server:~$ mpstat -P ALL 1 1
Linux 6.5.0 (fs01) 	02/05/2026 	_x86_64_	(32 CPU)

02:14:29 PM  CPU   %usr %nice %sys %iowait %irq %soft %steal %idle
02:14:30 PM  all   18.2  0.0   9.4  1.1     0.6  3.0   0.0    67.7

Qué significa: Mucho CPU ocioso. Si esto estuviera saturado, SMB podría estar limitado por CPU.

Decisión: Si CPU está alta en %soft/%irq, sospecha presión de interrupciones, problemas de offload o configuración RSS. Si está alta en %iowait, sospecha latencia de almacenamiento.

Task 13: Check disk latency on a Windows file server (Perf counter snapshot)

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\PhysicalDisk(_Total)\Avg. Disk sec/Read','\PhysicalDisk(_Total)\Avg. Disk sec/Write' -SampleInterval 1 -MaxSamples 3 | Select -ExpandProperty CounterSamples | Format-Table Path,CookedValue"
Path                                              CookedValue
----                                              -----------
\\FS01\physicaldisk(_total)\avg. disk sec/read     0.0042
\\FS01\physicaldisk(_total)\avg. disk sec/write    0.0210

Qué significa: Las lecturas están en ~4 ms, escrituras ~21 ms. Las escrituras podrían ser el limitante si los usuarios se quejan en periodos intensos de escritura.

Decisión: Si la latencia es alta, no esperes que Multichannel la arregle. Investiga caché, disposición RAID, profundidad de cola, tiering o saturación del backend.

Task 14: Confirm DNS resolves to the intended IPs (avoid “wrong interface” surprises)

cr0x@server:~$ nslookup fs01
Server:		10.10.0.53
Address:	10.10.0.53#53

Name:	fs01.corp.example
Address: 10.10.10.10
Name:	fs01.corp.example
Address: 10.10.20.10

Qué significa: Dos registros A, probablemente corresponden a ambas interfaces SMB.

Decisión: Si DNS solo devuelve una IP, Multichannel aún puede funcionar vía descubrimiento de interfaces, pero la resolución de nombres influye cuál IP del servidor es «primaria» y puede afectar políticas de enrutamiento/firewall. Corrige el registro DNS y prioridades de interfaz si es necesario.

Task 15: Validate SMB port reachability across both subnets

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection 10.10.10.10 -Port 445 | Select ComputerName,RemotePort,TcpTestSucceeded"
ComputerName RemotePort TcpTestSucceeded
------------ ---------- ----------------
10.10.10.10   445       True

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection 10.10.20.10 -Port 445 | Select ComputerName,RemotePort,TcpTestSucceeded"
ComputerName RemotePort TcpTestSucceeded
------------ ---------- ----------------
10.10.20.10   445       True

Qué significa: Ambas interfaces son accesibles por TCP/445.

Decisión: Si una falla, Multichannel no puede usarla. Arregla reglas de firewall, enrutamiento o ACLs. No habilites Multichannel a medias y esperes que encuentre un camino.

Tres microhistorias del mundo corporativo (realistas, anonimadas)

Mini-historia 1: El incidente causado por una suposición incorrecta

Tenían un nuevo par de servidores de archivos para los directorios de ingeniería. Dual 10GbE, switches decentes, VLANs ordenadas. El plan de despliegue fue conservador: habilitar SMB Multichannel (por defecto), verificar que los dos enlaces se activaran y dar por finalizado.

En una semana, usuarios de CAD comenzaron a reportar «congelamientos» al abrir ensamblajes. No era carga lenta—eran congelamientos. El tipo donde la app deja de responder y Windows reflexiona durante 10–20 segundos. Operaciones miró el servidor de archivos y vio que el throughput medio estaba bien. La CPU estaba bien. La latencia de disco estaba bien. Los gráficos de red eran aburridos. Los tickets seguían llegando.

La suposición incorrecta fue sutil: asumieron que ambas rutas SMB eran equivalentes porque ambas eran 10GbE. Un camino, sin embargo, atravesaba un clúster de firewall debido a una VLAN mal etiquetada en un puerto del switch. Aún pasaba tráfico. Solo añadía jitter y pérdidas ocasionales bajo carga porque el firewall hacía inspección stateful y logging en una ruta que nadie había planeado para tráfico este-oeste.

Multichannel lo empeoró al usar ambas rutas. Algunas lecturas pasaban por la ruta limpia, otras por la ruta «accidentalmente por el firewall». La aplicación experimentó latencias inconsistentes e interpretó eso como bloqueos de I/O.

La solución no fue heroica: corregir el tagging de VLAN, eliminar el firewall del camino de datos y volver a probar. También añadieron una validación estándar: traceroute y verificación de ACL para cada subred SMB, no solo «ping funciona». La lección quedó porque el incidente fue embarazoso de una manera muy específica: la red estaba «arriba», y la app estaba «abajo».

Mini-historia 2: La optimización que se volvió en contra

Otra compañía tenía un clúster Hyper-V usando SMB para almacenamiento de VM. El rendimiento era bueno pero no excelente. Alguien propuso un «gancho fácil»: aumentar las colas RSS y habilitar todas las funciones de offload en las propiedades avanzadas de la NIC. Más colas, más offloads, más velocidad. Así funcionan las computadoras, ¿no?

Durante unas 48 horas, los gráficos se veían mejor. Luego comenzaron pausas intermitentes: las migraciones en vivo a veces colgaban por unos segundos, y el tráfico SMB tipo CSV del clúster mostró picos periódicos de latencia. Nada lo suficientemente consistente como para gritar «roto», solo lo suficiente para que la plataforma pareciera poco confiable.

El contragolpe fue un caso límite de driver/firmware. Con los nuevos ajustes, la NIC ocasionalmente redistribuía flujos entre colas de una forma que agravó la contención de locks en la pila de red del host. SMB Multichannel multiplicó el número de flujos activos, lo que multiplicó la probabilidad de golpear ese rincón.

Revirtieron a una línea base conocida buena: conteo moderado de colas RSS, offloads por defecto salvo los recomendados para su modelo específico de NIC, y actualizaron firmware en una ventana controlada. El rendimiento quedó algo por debajo del pico efímero, pero la plataforma dejó de hacer la rutina de «mirar a la nada» a mitad de migración.

La recomendación del postmortem fue refrescantemente aburrida: trata el tuning de NIC como el tuning de almacenamiento. Un cambio a la vez, medir y tener un plan de rollback. Multichannel no rompió el sistema. Expuso una «optimización» inestable.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Una productora de medios ejecutaba un clúster de archivos Windows con Multichannel y (en algunos segmentos) RDMA. Sus redes eran rápidas y sus deadlines más rápidas. Ya habían sufrido antes, así que adoptaron una práctica de la que nadie se jactaba: cada trimestre ejecutaban un «chequeo de salud de rutas» scriptado durante baja carga.

El script verificaba: ambas subredes SMB alcanzables, MTU consistente, sin enrutamiento inesperado, conexiones SMB Multichannel activas y retransmisiones por debajo de umbral durante una copia controlada. También registraba versiones de drivers y firmware. Si algo derivaba, creaba un ticket. No un pánico. Un ticket.

Un trimestre, el script señaló un ligero pero consistente aumento de retransmisiones en una VLAN SMB. Aún no había quejas de usuarios. Trazaron la causa hasta un puerto de switch que empezaba a registrar errores corregibles—una óptica fallando lentamente. La reemplazaron en una ventana de mantenimiento.

Dos semanas después, otro equipo tuvo un gran empuje y saturó el sistema de archivos todo el día. Sin incidentes. Ese era el punto: el trabajo «aburrido» previno el outage emocionante. Multichannel siguió haciendo su trabajo—distribuir carga y absorber problemas menores—porque las rutas subyacentes se mantenían limpias.

Errores comunes: síntomas → causa raíz → solución

1) Síntoma: Solo una NIC transporta tráfico a pesar de que Multichannel está «habilitado»

• Causa raíz: SMB solo ve una interfaz adecuada (la otra está en un team, carece de RSS, está filtrada o DNS/enrutamiento la hace inaccesible para el puerto 445).
• Solución: Usa Get-SmbClientNetworkInterface/Get-SmbServerNetworkInterface y Test-NetConnection -Port 445 para validar ambos caminos. Arregla la conectividad, elimina teaming accidental, habilita RSS.

2) Síntoma: Bloqueos aleatorios, «congelamientos», latencias cola largas

• Causa raíz: Enrutamiento asimétrico, middleboxes stateful en una ruta o pérdida intermitente de paquetes en un enlace.
• Solución: Confirma que cada subred SMB sea puro L2/L3 sin firewalls en el camino de datos. Revisa retransmisiones. Arregla errores físicos, congestión de buffers o políticas de enrutamiento.

3) Síntoma: El throughput mejoró, pero la CPU subió y el servidor se siente más lento

• Causa raíz: Presión de interrupciones/softirq, RSS mal ajustado o problemas de offload/driver. Multichannel aumentó la carga de recepción paralela y la sobrecarga.
• Solución: Valida que RSS esté habilitado y dimensionado apropiadamente. Actualiza drivers/firmware de la NIC. Considera reducir canales corrigiendo colas RSS en lugar de deshabilitar Multichannel globalmente.

4) Síntoma: Entorno RDMA muestra pausas periódicas bajo carga

• Causa raíz: RoCE DCB/PFC mal configurado causando bloqueo head-of-line; o MTU mismatched; o un problema de microburst en buffers del switch.
• Solución: Valida MTU extremo a extremo, asegúrate de que las configuraciones DCB sean consistentes entre NICs y switches, y prueba con RDMA deshabilitado temporalmente para confirmar. Arregla la tela, no solo la máscara.

5) Síntoma: Tras habilitar Multichannel, la latencia de almacenamiento «de repente empeoró»

• Causa raíz: Se removió el cuello de botella de red; el almacenamiento ahora está saturado. Suben las profundidades de cola y la latencia aumenta, y los usuarios culpan al último cambio.
• Solución: Mide latencia de disco y utilización del backend. Mejora almacenamiento, ajusta caché o reduce concurrencia. Multichannel no es una función de QoS de almacenamiento.

6) Síntoma: Funciona desde algunos clientes, no desde otros

• Causa raíz: Versiones de SO mixtas, diferencias de políticas, drivers de NIC distintos o subredes cliente no simétricas.
• Solución: Compara Get-SmbClientConfiguration, capacidades RSS/RDMA de NIC y resolución de nombres por cliente. Estandariza drivers y políticas para los clientes de alto rendimiento.

Listas de comprobación / plan paso a paso

Habilitar Multichannel de forma segura (greenfield o cambio planificado)

1. Inventario de interfaces: lista NICs, IPs, VLANs, velocidades de enlace y puertos de switch para cliente y servidor.
2. Confirmar independencia de caminos: idealmente switches separados o al menos uplinks/paths ASIC separados.
3. Confirmar alcance: TCP/445 debe ser alcanzable en cada interfaz que esperas que SMB use.
4. Normalizar MTU: 1500 en todas partes o jumbo en todas partes en esa VLAN, extremo a extremo.
5. Asegurar RSS habilitado y que el conteo de colas sea razonable para el número de núcleos CPU.
6. Higiene de drivers/firmware: actualiza a un conjunto conocido estable, no «lo último un viernes».
7. Métricas base: throughput por NIC, retransmisiones, CPU, latencia de disco.
8. Prueba de carga: ejecuta una copia multihilo controlada o un benchmark específico de la carga.
9. Despliegue: habilita para un grupo piloto primero; vigila latencia cola y contadores de error.

Cuándo deshabilitar Multichannel (intencionalmente, no por superstición)

• Tienes enrutamiento asimétrico conocido que no puedes arreglar rápido y necesitas estabilidad más que rendimiento.
• Estás en un entorno con middleboxes stateful que tratan los caminos de forma diferente y la realidad política impide rediseñar.
• Tienes bugs de driver/firmware y necesitas una mitigación mientras planificas actualizaciones.
• Tu carga es sensible a latencia y de bajo throughput, y Multichannel añade sobrecarga sin beneficio medible.

Plan de solución paso a paso (repetible)

1. Confirma dialecto SMB negociado y que Multichannel esté habilitado en ambos extremos.
2. Confirma que SMB realmente está usando múltiples conexiones.
3. Verifica alcance y reglas de firewall/ACL para cada IP interfaz SMB.
4. Revisa pérdida de paquetes y retransmisiones durante la ventana del problema.
5. Revisa la distribución de throughput por NIC durante la ventana del problema.
6. Revisa CPU (especialmente IRQ/softirq) en cliente y servidor.
7. Revisa latencia de disco y utilización del backend de almacenamiento.
8. Si RDMA: valida MTU/DCB/PFC y prueba RDMA apagado/encendido.
9. Cambia una cosa a la vez; valida; documenta la nueva línea base.

Preguntas frecuentes

1) ¿SMB Multichannel reemplaza el teaming de NIC?

No. Resuelve un problema similar de «usar más de un enlace» a un nivel distinto. Usa teaming cuando necesites semántica L2/L3 (una sola IP/MAC) para otras aplicaciones. Usa Multichannel cuando el objetivo sea rendimiento/resiliencia SMB y puedas mantener los caminos limpios.

2) ¿Debo habilitar Multichannel en un servidor de archivos por defecto?

En servidores Windows modernos con redes sensatas, sí. Pero «por defecto» incluye «con validación». Si no puedes validar simetría de rutas, MTU y pérdida de paquetes, estás apostando con la complejidad.

3) ¿Por qué Multichannel a veces no usa todas las NICs?

Porque SMB solo usa interfaces que considera adecuadas y alcanzables, y pondera según capacidades (RSS/RDMA) y métricas. Además, algunas cargas no generan I/O paralelo suficiente para justificar múltiples conexiones.

4) ¿Es útil Multichannel en 1GbE?

A veces. Puede mejorar throughput agregado para cargas multi-stream, pero el coste operativo puede no valer la pena. En redes de 1GbE, la pérdida de paquetes y problemas de buffer suelen ser un limitador mayor que la «falta de canales».

5) Multichannel está activado, pero el rendimiento no mejoró. ¿Ahora qué?

Asume que el cuello de botella se movió. Revisa CPU (RSS/interrupciones), luego latencia de almacenamiento. También verifica que la carga sea lo bastante paralela—copias de un solo hilo no necesariamente escalan.

6) ¿Puede Multichannel empeorar el rendimiento?

Sí. Especialmente con pérdida de paquetes, enrutamiento asimétrico, drivers inestables o mala configuración RDMA. Puede incrementar la sobrecarga y amplificar jitter porque ahora tienes múltiples caminos cuyo comportamiento debe coincidir.

7) ¿Necesito subredes/VLAN separadas para Multichannel?

Se recomienda encarecidamente para claridad y para evitar sorpresas de enrutamiento. Subredes separadas facilitan razonar sobre caminos, aplicar políticas y verificar que «interfaz A» realmente mapea a «camino de switch A».

8) ¿Cómo interactúa el cifrado SMB con Multichannel?

El cifrado añade coste de CPU y puede reducir throughput. Multichannel puede ayudar a recuperar throughput paralelizando, pero puedes quedarte limitado por CPU antes. Mide CPU y considera CPUs con AES-NI y cifrados modernos.

9) Si uso RDMA, ¿sigo queriendo Multichannel?

A menudo sí—múltiples NICs RDMA pueden aportar tanto ancho de banda como resiliencia. Pero RDMA exige requisitos más estrictos para la tela. Si tu configuración lossless es frágil, empieza con un camino RDMA, estabilízalo y luego escala.

Conclusión: próximos pasos prácticos

Si recuerdas solo tres cosas, que sean estas:

1. Verifica que Multichannel esté realmente en uso antes de diagnosticar cualquier otra cosa. No depures fantasmas.
2. Elimina pérdida de paquetes y asimetría de rutas antes de perseguir rendimiento. Multichannel odia redes «casi fiables».
3. Mide el nuevo cuello de botella después de mejorar throughput. La capa de almacenamiento aceptará tu nueva concurrencia y devolverá latencia.

Próximos pasos que puedes hacer esta semana:

• Ejecuta los comandos de interfaz y conexión en un cliente y servidor representativos; captura pantallazos de las salidas para tu runbook.
• Elige un share crítico y realiza una prueba de carga controlada mientras rastreas throughput por NIC, retransmisiones, CPU y latencia de disco.
• Decide tu política: Multichannel activado por defecto con una lista de validación, o desactivado por defecto con un proceso de excepción justificado. Cualquiera es aceptable. «Lo que sea que pase» no lo es.

SMB Multichannel es una herramienta potente. Usada correctamente, es más rápida y segura que los trucos antiguos. Usada de manera casual, es una excelente forma de descubrir qué partes de tu red están sostenidas por optimismo.