A regra dos trinta bytes adicionais para a MTU falla nos pseudocables MPLS

Pregunte a un enxeñeiro canto hai que sumar para MPLS e oirá un número, normalmente trinta, dito con confianza. O número non é tanto erróneo como desancorado: depende por completo do que conta a cifra inicial e do que transmite realmente a beira do provedor. Nun pseudocable Ethernet as suposicións son visibles, e en canto as escribe, a aritmética substitúe o folclore.

Mídense tres cousas distintas baixo un mesmo nome. Están o paquete IP do cliente, a trama Ethernet transportada polo pseudocable e o propio encadramento externo da ligazón do provedor. Un orzamento que os mestura produce un valor que ningún campo de dispositivo espera.

Un orzamento calculado con cada suposición declarada

Tome un paquete IP de cliente de 1500 bytes, unha cabeceira Ethernet corrente transportada polo pseudocable sen o FCS do cliente, ningunha etiqueta VLAN conservada, unha pila de etiquetas de dúas entradas e unha palabra de control de catro bytes. A cabeceira Ethernet transportada suma 14, as etiquetas conservadas non suman nada, as dúas entradas de etiqueta suman 8 porque cada entrada ocupa 4 bytes, e a palabra de control suma 4. Iso dá 1526 bytes de paquete encapsulado en MPLS.

Lea o resultado con coidado. Exclúe a cabeceira Ethernet exterior da ligazón do provedor e o seu FCS, e é un exemplo, non unha constante que escribir en calquera campo chamado MTU. Dúas etiquetas tamén é unha suposición: a pila real pode levar unha etiqueta de transporte, unha etiqueta de servizo e ás veces máis, e cada entrada custa os mesmos 4 bytes.

Que atravesa realmente o pseudocable

A RFC 4448 define como viaxan as tramas Ethernet dentro de MPLS, e no seu modelo ordinario o preámbulo e o FCS do cliente elimínanse na entrada e rexenéranse na saída. Por iso o FCS non aparece no orzamento anterior. O tratamento de VLAN depende do modo de servizo: un modo que conserva as etiquetas do cliente volve sumar os seus bytes, e un modo que as mapea non o fai. A conservación adicional ou a encapsulación extra deben contarse por riba.

A palabra de control forma parte da aritmética sempre que se usa. A RFC 8469 recoméndaa para pseudocables Ethernet, así que un texto máis antigo que a describe como opcional non é proba de que a súa ruta a omita. Confirme o modo de servizo real co provedor en lugar de inferilo dun diagrama.

Compare a cifra co campo correcto

Agora poña o tamaño encapsulado requirido xunto a cada ligazón relevante e xunto á definición do fabricante do límite que configura. Algúns campos describen un paquete IP, outros describen unha trama ou outra fronteira de encapsulación. Dous números poden parecer idénticos e describir capacidades distintas, e así é como unha configuración que parece encaixar produce descartes en produción.

Tamén por iso é arriscado copiar un valor entre plataformas non relacionadas. O nome do campo é a especificación, non o número decimal que recorda da consola doutro fabricante.

As cargas de ping non son valores de MTU

A carga dun ping IPv4 non é unha MTU IP. A cabeceira IP e a cabeceira ICMP tamén consomen bytes, así que un tamaño de carga que ten éxito corresponde a un paquete maior no cable. Unha sonda que pasa cun tamaño tampouco di nada sobre un servizo con outro modo VLAN ou unha pila de etiquetas máis profunda. A proba mide unha ruta, un tamaño e unha forma de carga, e o servizo pode variar as tres.

Peor aínda, un ping pode funcionar mentres as tramas grandes fallan, porque a sonda exercitou unha ruta e un tamaño que o tráfico real nunca usa. Tráteo como un só punto de datos sobre alcanzabilidade, non como unha especificación de servizo de capa 2.

Cando a trama non cabe

Se as tramas demasiado grandes non se poden transportar e non hai ningún mecanismo de fragmentación ou reensamblaxe soportado, descártanse, normalmente sen un erro limpo en ningún dos dous extremos. As aplicacións mostran entón tempos de espera en transferencias masivas mentres as sesións interactivas seguen sans, o que envía a xente a mirar cortalumes e rutas en lugar de contar bytes.

Resolva o orzamento real co provedor: modo de servizo, tratamento de etiquetas, profundidade de etiquetas, palabra de control e o límite exacto que aplica o seu dispositivo. Escriba as suposicións xunto ao número, porque doutro xeito o seguinte enxeñeiro herdará a regra dos trinta bytes e un misterio.