ECMP cara a un só VTEP: de onde vén a entropía de VXLAN

A afirmación de que o multipath de igual custo non serve para unha ruta de host repítese o suficiente como para soar certa. Un /32 selecciona un enderezo de destino, e nada nesa selección restrinxe o paquete a unha soa ligazón física. Cando o destino é un extremo remoto de túnel VXLAN, varios saltos seguintes poden transportar fluxos de superposición distintos, e se o fan depende do que o hash de reenvío teña permiso para ver. O resto é aritmética sobre a cabeceira exterior, non unha propiedade do prefixo.

A ruta decide a alcanzabilidade; o hash decide a distribución.

O mito: un /32 significa un só camiño

OSPF pode anunciar alcanzabilidade de igual custo cara a un loopback de VTEP mentres a táboa de reenvío instala un grupo de saltos seguintes para ese mesmo prefixo. O protocolo fornece os candidatos; a plataforma decide cales son utilizables e como se asigna un paquete. Ningún protocolo de encamiñamento calcula un hash novo para cada trama encapsulada. Esa separación explica por que dous routers con rutas idénticas poden repartir o tráfico de forma distinta.

Mire a entrada de reenvío instalada e non só a visualización da ruta, porque os límites de hardware ou de política poden descartar candidatos que o plano de control aínda anuncia.

De onde ten que vir a entropía

Entre dous VTEP os enderezos exterior de orixe e destino permanecen fixos, e o porto de destino UDP é 4789 nun despregamento convencional. Un hash que só le eses valores ve unha entrada constante e devolve un camiño constante. Algo da cabeceira exterior ten que variar, e o VTEP é o dispositivo que pode facelo variar.

RFC 7348 propón derivar o porto de orixe UDP a partir de campos dentro da trama encapsulada. Distintas conversas internas producen entón tuplas exteriores distintas, o que dá a un hash de transporte ordinario algo con que traballar.

Se o hardware de reenvío pode mirar máis dentro do paquete, comprobe que campos internos admite a súa implementación de hash. Ese fondo non debería tratarse como un requisito para cada dispositivo de underlay, xa que a variación do porto de orixe por si soa xa expón diferenzas útiles.

Comprobe o hash que realmente obtén

Mida en lugar de supor. Capture unha mostra de tráfico encapsulado e observe os portos de orixe exteriores, e despois compare o resultado coas entradas de reenvío e os contadores por ligazón.

show ip route 10.255.0.5/32
show ip cef 10.255.0.5 internal
ip route show 10.255.0.5
tcpdump -ni eth0 -c 200 'udp port 4789' -vv

Un só porto de orixe que aparece en moitas conversas internas distintas significa que o VTEP non varía o campo, e ningún axuste do underlay repartirá a carga. Moitos portos distintos cun só salto seguinte en uso apuntan máis ben ao grupo de reenvío.

Anote os contadores antes e despois da mostra, e teña en conta o tráfico non relacionado que comparte as ligazóns ascendentes, ou as cifras parecerán peores do que o hash merece.

Que non significa unha distribución uniforme

Un hash por fluxo está deseñado para manter unha conversa nun só camiño mentres as súas entradas e o conxunto de camiños dispoñible non cambien. Por iso unha única transferencia TCP grande non agrega todas as ligazóns ascendentes, e engadir ligazóns non acelerará ese fluxo. É un comportamento normal, non un fallo.

Varios fluxos tamén poden colisionar por casualidade no mesmo salto seguinte. Unha mostra curta pode parecer moi sesgada mentres o hash fai exactamente aquilo para o que se configurou, e un fallo de ligazón ou un cambio do conxunto de camiños pode mover fluxos establecidos no medio dunha transferencia.

Probe con pares de enderezos, transportes e taxas representativos baixo un plan aprobado, e manteña a selección de membros de agregación de ligazóns separada da selección de multipath encamiñado, porque dúas etapas de hash compoñen o seu propio patrón. Un grupo de saltos seguintes poboado máis entropía exterior visible explican o resultado; a lonxitude do prefixo non.