Resumo

  • O context label precisa ser único entre os LSRs do mesmo LAN. O método automático baseado na parte host IPv4 depende de baixos 20 bits únicos; colisão local provavelmente causa encaminhamento incorreto.
  • A mesma cifra em LANs diferentes não é ambígua porque a interface de entrada faz parte do lookup. Valor sem escopo não permite classificar colisão.

Um algoritmo determinístico não prova entrada exclusiva

RFC 5331 permite provisionar um context label de 20 bits ou gerá-lo da parte host do IPv4 sob condições. O mask deve deixar espaço adequado, valores reservados são evitados e certos limites excluem entradas.

Nada disso verifica por si só os demais participantes do LAN. Dois endereços podem ser globalmente distintos e compartilhar os mesmos bits relevantes. Se ambos gerarem o mesmo context label no mesmo meio, o receptor perde a identidade do vizinho e pode usar o espaço errado.

O recibo de geração precisa guardar endereço, mask, host part, offset, LAN, conjunto observado de LSRs e resultado da verificação de unicidade. Guardar só o número transforma a hipótese sobre os dados de entrada em garantia.

Interfaces exclusivamente IPv6 não entram no método automático. Usar um hash ou truncamento alternativo seria outra política, não execução silenciosa do RFC.

Reuso entre LANs não é colisão

O receptor consulta o context label no contexto da interface LAN de entrada. Portanto, o mesmo valor em interfaces diferentes pode apontar para espaços diferentes sem ambiguidade.

Uma ferramenta global que remove a interface denuncia falsos conflitos. Uma ferramenta local que não vê todos os LSRs do LAN deixa passar o conflito real. O domínio de unicidade deve reproduzir a chave usada no forwarding.

Essa distinção também impede que uma limpeza central force números globais únicos, desperdice espaço e ainda não prove ausência de colisão durante uma transição.

EtherType não basta para escolher o espaço

O EtherType de RFC 5332 pode indicar upstream assignment em meio multiacesso. Ele não identifica qual vizinho atribuiu o label. RFC 5331 usa um túnel MPLS de um salto: context label no topo, upstream label logo abaixo.

Context label e interface selecionam o Upstream Neighbor Label Space. Só então o segundo número é associado à FEC. Capture os dois labels, a ordem, EtherType, interface e table ID.

PHP pode apagar o selector antes do lookup

Em túnel MPLS, os labels acima do upstream-assigned label identificam a raiz. Se PHP remover a camada exterior, o egress recebe número válido sem saber qual tabela usar. O documento exige desativar PHP quando o contexto depende do túnel.

O benefício de uma pilha menor não compensa escolher a FEC de outra tabela. Fallback não reconstrói a intenção; produz nova decisão.

Endereço de raiz e de assigner devem ser o mesmo

O downstream mantém espaço separado por head-end IP. Mesmo roteador com endereços diferentes pode exigir tabelas diferentes. Label distribution deve nomear o assigner com o mesmo endereço usado pelo tunnel setup para a raiz.

GRE sem sinalização toma o source IP como root. CMDB pode conhecer aliases, mas não deve fundi-los antes do recibo de correspondência.

Suporte é opcional e precisa ser conhecido

Upstream assignment não pode ser usado apenas porque o código existe. É preciso saber que o downstream suporta, e o mecanismo dessa prova fica fora do RFC. Registre peer, aplicação, túnel, origem e validade do conhecimento.

Fontes e limite de evidência

As fontes estabelecem regras, história e registros, não implementação, túnel, PHP, raiz, tabela, colisão, desvio, multicast, forwarding ou entrega atuais.