Antes de adicionar OTV, escreva o contrato Ethernet de que precisa

Uma carga de trabalho muda para um segundo centro de dados e começa a exceder o tempo num serviço que respondia bem a partir do primeiro. Alguém propõe OTV, porque o Layer 2 VPN existente «não faz broadcast». Essa conclusão é habitualmente prematura. A categoria de serviço e o contrato concreto que comprou são duas perguntas diferentes, e o tempo excedido ainda não foi atribuído a nenhuma delas.

O sintoma que inicia a comparação

Escreva o que a aplicação realmente necessita antes de comparar produtos. O número de sites, o âmbito VLAN, a aprendizagem de endereços, a tolerância a flooding e o comportamento em caso de falha descrevem o requisito. «Layer 2» e «OTV» descrevem arquiteturas, e nenhum deles é um requisito por si só. Cinco propriedades numa página sobreviverão a qualquer comparação de fornecedores.

Depois verifique se o serviço atual já satisfaz essas cinco propriedades. Um Layer 2 VPN gerido pelo fornecedor pode incluir encaminhamento multipoint e aprendizagem no plano de controlo que uma vista rápida da fatura não mencionava.

Se o serviço atual as satisfaz, o tempo excedido está noutro lugar: um problema de MTU, uma assimetria de encaminhamento, uma regra de firewall que difere entre sites. Mudar o overlay deixaria essa causa no lugar e acrescentaria uma migração.

O que o rótulo não lhe diz

Um Layer 2 VPN é uma categoria, não um produto. VPWS ponto a ponto e VPLS multipoint encaminham de forma diferente, e a categoria inclui serviços com aprendizagem no plano de controlo e gestão de ciclos, bem como outros mais simples. Assumir que cada Layer 2 VPN liga exatamente dois sites e inunda tudo é como se faz a comparação errada. O nome no contrato não diz nada sobre a tabela de encaminhamento por trás.

Pergunte que modelo de encaminhamento implementa o serviço existente, e qual a aplicação necessita. Um requisito hub-and-spoke e um requisito full-mesh produzem desenhos diferentes mesmo quando ambos são descritos como Layer 2.

Onde o OTV traça a sua fronteira

O OTV funciona sobre um transporte IP com alcance MAC no plano de controlo e papéis de edge definidos. A informação local de spanning-tree permanece local em vez de ser estendida como um único domínio não controlado através do transporte. Essa é uma diferença real face a uma extensão pontada simples, e é a razão pela qual as pessoas recorrem a ele.

A fronteira importa tanto como o benefício. O tratamento de unicast, broadcast e multicast desconhecidos depende da plataforma e da sua configuração, e um par de edge tem de cooperar através do mecanismo de multihoming suportado. Dois dispositivos independentes que encaminham o mesmo VLAN não são o mesmo desenho, e produzem um modo de falha diferente.

O flooding é reduzido, não removido

Suprimir parte do flooding desnecessário não é o mesmo que garantir que nenhuma trama broadcast ou multicast alguma vez atravessa a extensão. Uma tempestade que começa num site ainda pode consumir o transporte, e uma funcionalidade da plataforma que filtra uma classe de tráfego não filtra as outras. É dessa distinção que vem a maior parte da desilusão com qualquer overlay.

Portanto a pergunta não é se o OTV trava as tempestades de broadcast. É que classes de tráfego atravessam, em que condições, e o que limita o ritmo quando o fazem.

Confirme o underlay enquanto está lá: entrega suportada, tamanho do pacote, encaminhamento e a adjacência exigida pela versão escolhida. Nada disso vem de graça com o overlay, e um túnel que acomoda uma trama de 1500 bytes não é automaticamente um túnel que acomoda as suas tramas etiquetadas.

O contrato a pedir, por escrito

Para qualquer serviço que escolher, peça as mesmas seis respostas: âmbito ponto a ponto ou multipoint, tratamento da trama e da etiqueta do cliente, modelo de aprendizagem MAC, limites de flooding, comportamento de recuperação e o tamanho máximo de trama de ponta a ponta. Dois serviços com o mesmo nome podem diferir em cada uma delas. Obtenha as respostas por escrito, porque o engenheiro que configurou o serviço pode não ser o que responde à pergunta.

Escolha uma mudança apenas para um requisito que o serviço atual demonstra não conseguir satisfazer. Estender um VLAN mais além estende também as dependências da aplicação e do Ethernet com ele; um novo nome de overlay não as remove.

O quadro RFC 4664 apresenta as categorias de serviço e os seus modelos de encaminhamento, que é o vocabulário de que precisa para fazer a pergunta certa. Leve as seis respostas e o teste falhado à mesma reunião, e a decisão deixa de ser sobre rótulos.