diff --git a/deploy-lab.sh b/deploy-lab.sh
index 227da3e..2c7d335 100644
--- a/deploy-lab.sh
+++ b/deploy-lab.sh
@@ -432,6 +432,7 @@ create_cluster() {
   log "Creando clúster ${CLUSTER_NAME} con IPAM estático"
   docker pull "$K3S_IMAGE"
   k3d cluster create --config "$CONFIG_FILE"
+  fix_flannel_mtu
 }
 
 start_cluster() {
@@ -440,6 +441,36 @@ start_cluster() {
     "$CLUSTER_NAME" \
     --wait \
     --timeout "${AUTOSTART_K3D_START_TIMEOUT}s"
+  fix_flannel_mtu
+}
+
+# Workaround para el blackhole de red cross-node por MTU/PMTUD (ver
+# docs/known-issues.md en apps-registry). k3s embebe flannel sin exponer un
+# flag --flannel-mtu (confirmado con `k3s server --help`, no existe en esta
+# version), asi que el unico punto de ajuste es la interfaz flannel.1 en
+# vivo dentro de cada contenedor de nodo -- no persiste en ningun archivo de
+# config, hay que reaplicarlo cada vez que el cluster arranca (creacion
+# nueva o start de uno existente). Confirmado empiricamente 2026-08-16: el
+# blackhole real esta entre payload interno 1420 (OK) y 1450 (100% perdida,
+# sin ICMP), asi que 1400 queda con margen seguro.
+fix_flannel_mtu() {
+  local node mtu_target=1400 tries iface_ready
+  log "Ajustando MTU de flannel.1 a ${mtu_target} en los nodos de ${CLUSTER_NAME} (fix blackhole MTU/PMTUD)"
+  for node in $(docker ps --filter "label=k3d.cluster=${CLUSTER_NAME}" --format '{{.Names}}'); do
+    iface_ready=false
+    for tries in 1 2 3 4 5 6 7 8 9 10; do
+      if docker exec "$node" ip link show flannel.1 >/dev/null 2>&1; then
+        iface_ready=true
+        break
+      fi
+      sleep 2
+    done
+    if [[ "$iface_ready" != true ]]; then
+      log "ADVERTENCIA: ${node} no tiene interfaz flannel.1 tras esperar, se omite (¿nodo sin CNI listo?)"
+      continue
+    fi
+    docker exec "$node" ip link set flannel.1 mtu "$mtu_target"
+  done
 }
 
 cluster_api_ready() {