Etiqueta por VRF ou por prefixo? A fatura real da capacidade

Dois desenhos anunciam o mesmo prefixo de cliente no mesmo núcleo do fornecedor. Um atribui uma etiqueta por prefixo, o outro atribui uma única etiqueta para todo o VRF, e o segundo parece mais barato em todos os slides. O número de etiquetas é real, mas não é o orçamento que costuma esgotar-se primeiro. Escolher entre os dois significa contar quatro recursos, não um, e as etiquetas são o menor deles.

A escolha também depende do que o router de saída tem de fazer com o pacote depois de retirar a etiqueta. É essa diferença funcional, e não a aritmética das etiquetas, que deve orientar a decisão.

O que cada atribuição realmente poupa

Uma atribuição por prefixo transporta a informação de encaminhamento na etiqueta. O router de saída pode enviar o pacote diretamente para a adjacência correta sem uma pesquisa de destino, e é por isso que escala bem para grandes conjuntos de rotas VRF e que consome uma etiqueta por cada prefixo anunciado em cada VRF. Uma atribuição por VRF, como Junos vrf-table-label, anuncia uma etiqueta por instância de routing e usa essa etiqueta para selecionar a tabela VRF; o router faz depois uma pesquisa IP dentro da tabela.

É uma diferença arquitetural real e não um botão de afinação. A etiquetagem por VRF dá um espaço de etiquetas mais pequeno e um anúncio de etiquetas mais simples, ao custo de uma pesquisa e de uma etiqueta que nada diz sobre o destino. A etiquetagem por prefixo dá à placa de linha de saída mais informação à partida e custa etiquetas em proporção das rotas transportadas.

O livro das etiquetas é o pequeno

As etiquetas MPLS são finitas, mas o espaço de etiquetas é suficientemente grande para que os fornecedores de serviço comuns não o esgotem com alguns milhares de prefixos. Onde a etiquetagem por VRF ajuda mesmo é em plataformas com tabelas de etiquetas de hardware pequenas, ou em desenhos em que um único VRF transporta um feed completo da Internet e as etiquetas por prefixo multiplicariam a procura de etiquetas pelo número de rotas. Estas são restrições reais, e são a razão pela qual a funcionalidade existe. Nenhuma delas diz respeito ao número de prefixos na tabela.

Conte as etiquetas tanto do serviço como do transporte antes de escolher. Um desenho por VRF continua a precisar de etiquetas de transporte para os loopbacks e para cada salto no caminho, e continua a precisar de estado de adjacência. Se o briefing de desenho só conta as etiquetas de serviço, a poupança está a ser medida no livro errado.

Os feeds de rotas custam memória antes das etiquetas

Cada caminho recebido consome memória do plano de controlo, processamento de atualizações e tempo de convergência, quer o VRF use uma etiqueta ou dez mil. Um feed completo da Internet dentro de um VRF é caro por causa dos caminhos BGP, da RIB, das entradas FIB e da agitação por trás deles, não por causa da etiqueta que está à frente da tabela. O mesmo feed também aumenta o raio de impacto de uma fuga de rotas ou de um erro de política dentro desse inquilino.

Pergunte, por isso, o que o cliente realmente exige. Se o contrato for de sites privados mais uma saída predefinida, uma tabela completa acrescenta custo sem acrescentar requisito. É uma questão comercial, e merece uma resposta escrita em vez de um pressuposto herdado do desenho anterior. Se o serviço precisar mesmo do feed para política ou para seleção de saída local, faça disso uma rubrica explícita com a sua própria reserva de capacidade e o seu próprio comportamento em caso de falha.

Quando a etiquetagem por VRF é o padrão correto

É um bom padrão quando a plataforma a documenta como suportada, quando o número de rotas do VRF é grande e quando o custo da pesquisa na saída é aceitável para o perfil de tráfego. É também a escolha natural quando a simplicidade operacional conta mais do que espremer o último microssegundo do encaminhamento, porque uma etiqueta por inquilino é mais fácil de explicar e auditar do que uma etiqueta por prefixo.

É o padrão errado quando a documentação da plataforma liga a funcionalidade a restrições específicas de hardware ou de versão, ou quando o desenho depende de decisões de encaminhamento por prefixo na saída. Leia a própria referência de statement da plataforma antes de assumir o comportamento; o comando Junos está documentado, mas são os limites de hardware e de versão à sua volta que decidem realmente a implementação.

Um orçamento que consegue defender

Construa o caso de capacidade como cinco números separados: caminhos recebidos, rotas selecionadas, entradas de encaminhamento instaladas, etiquetas de serviço e etiquetas de transporte. Acrescente o estado de next-hop e de adjacência, o número de inquilinos e o modelo de redundância. A fotografia do caminho feliz de um único VRF não é um número de escala, e um tamanho nominal do espaço de etiquetas não é uma tabela de hardware disponível.

Depois acorde também o modo de falha, e não apenas o regime permanente. O que acontece quando o feed cresce para o dobro e meio, quando um inquilino acrescenta um segundo VRF ou quando a plataforma precisa de um reinício para redimensionar uma tabela? Um orçamento que resiste a estas perguntas vale mais do que uma contagem de etiquetas que só funciona no papel.

Escolha a atribuição a partir da ação na saída e dos limites da plataforma, e depois faça do feed de rotas uma decisão de serviço explícita. A etiqueta é a parte visível do desenho; as rotas são a parte que tem de ser paga todos os dias.