Algo se marca, configúrase unha cola e despois alguén pregunta que calidade garante realmente o deseño. A resposta honesta é que describiu dúas metades dun contrato que se atopan nunha fronteira. Ata que poida nomear a clase que acepta o provedor e o tratamento que aplica, a configuración local é unha intención, non unha promesa. Ambas as metades importan e ningunha pode inferirse da outra.

local match → queue and marking → provider classifier
  → provider treatment → destination

Onde un marcado correcto pode morrer en silencio

Comece anotando, por carga de traballo, a condición de coincidencia local, calquera marcado que ocorra dentro dun túnel, o valor que acepta o provedor e a clase de servizo que ese valor selecciona. Catro columnas, e os fallos adoitan vivir entre a segunda e a terceira.

O comportamento de marcado de interior a exterior é o problema clásico. Un paquete dentro dunha ruta cifrada ou tunelizada leva unha cabeceira interior que o seu clasificador pode ver e unha cabeceira exterior que o equipo do provedor pode ver, e copiar unha na outra é unha decisión de configuración, non unha propiedade automática. Marque só a cabeceira interior e o provedor clasificará a exterior, normalmente como predeterminada, por iso un fluxo marcado correctamente pode chegar á clase equivocada sen unha soa liña mal configurada no seu lado.

Unha clase nomeada localmente tamén pode quedar baleira porque a súa condición de coincidencia nunca se activa con paquetes reais. Os portos móvense, as aplicacións usan varios fluxos, e unha coincidencia nun porto coñecido que o fabricante deixou de usar dúas versións atrás produce unha cola con contadores a cero e unha política que na configuración en execución parece perfecta.

Decida explicitamente onde se confía nos marcados. Promover todo o que comparte un túnel promove as transferencias masivas xunto coas chamadas, e un provedor que acepta o seu marcado sen validación ofrécelle unha forma de facerse dano. Se o contrato permite que a pasarela volva marcar na entrega, dígao por escrito, porque é xusto o punto onde as suposicións de dous equipos adoitan diverxir.

Que divide realmente o planificador

A política local ten a súa propia semántica, e a que causa máis malentendidos é a palabra “remaining”. Nas plataformas que describe a guía de planificación de IOS XE, bandwidth remaining percent establece un peso excedente, non un paso dunha secuencia na que cada clase toma unha porción do que deixou a clase anterior. As porcentaxes non asignadas repártense entre as colas elixibles non configuradas en lugar de reservarse para a última clase do ficheiro.

Esa distinción importa porque o modelo mental secuencial produce predicións que nunca coinciden cos contadores. Os enxeñeiros reordenan clases para cambiar un resultado, non ven diferenza e conclúen que a plataforma está rota, cando a configuración nunca quixo dicir o que supuñan.

O modelador pai é a outra sorpresa habitual. Modelar unha cola controlada ata a taxa de servizo utilizábel adoita ser deliberado, porque traslada o punto de conxestión a un dispositivo que vostede administra en lugar dunha cola ascendente que non administra. Quitar o modelador porque a modelaxe engade retardo pode trasladar a perda en vez de eliminala, e a contabilidade de sobrecarga ou un policer do provedor poden facer que a taxa efectiva sexa inferior á que suxire a interface.

Os contadores din que metade fallou

Compare catro números na dirección afectada: que se ofreceu, que coincidiu a clase, que se puxo en cola ou se descartou e que entregou realmente o servizo. Manteña a descrición da carga de traballo e a versión da política xunto á observación, porque unha captura de pantalla dos contadores sen elas non se pode reproducir.

As ramas son problemas distintos con propietarios distintos. Unha clase local que non coincide con nada é un erro de clasificación no seu lado. Unha clase que coincide, se encola e descarta mentres o provedor informa dunha entrega limpa apunta ao seu propio planificador ou modelador. Unha clase que parece correcta localmente mentres a perda aparece máis aló da entrega apunta ao mapeo do operador e á fronteira medida no contrato. Ningunha das tres se arranxa editando as outras, por iso os números deben recollerse xuntos.

RFC 2475 enmarca a clasificación e o condicionamento como traballo realizado dentro de dominios administrativos, e precisamente por iso un marcado non pode reservar colas de extremo a extremo. A guía de planificación de IOS XE é a referencia do comportamento de peso excedente descrito arriba, e paga a pena ler as súas comparacións de plataformas antes de trasladar unha taxa calculada entre modelos.

Escriba o contrato nun só lugar

Pon a coincidencia local, a fronteira de confianza, a clase do provedor e o nivel de servizo medido nun único documento que asinen ambas as partes. Entón un cambio de porcentaxe ten contexto, e unha queixa de calidade ten propietario.

Cambiar unha porcentaxe local non pode reparar a garantía doutra cola, e ningún esquema de marcado sobrevive a un mapeo que o provedor non respecta. Compare as metades, nomee a fronteira e só entón cite unha cifra.

Artigos relacionados