O que tem de estar alinhado antes de um MX terminar IPsec
Um commit que aceita a configuração prova o analisador, não o caminho. Cinco partes do tuplo da plataforma decidem se o serviço corre de facto.
A configuração é submetida sem erros, as interfaces sobem e o túnel continua a recusar-se a estabelecer. Nada no registo diz que a plataforma não é capaz de o fazer; simplesmente não o faz. No Junos, o IPsec é um serviço que só uma combinação concreta de chassis, hardware de serviços ou caminho de software, e versão consegue prestar, e uma página de funcionalidades descreve a capacidade do software, não a sua caixa. O tuplo tem de ser verificado parte a parte, porque o resultado de um commit prova apenas o analisador.
Para onde vai realmente o pacote
O tráfego selecionado para IPsec tem de chegar ao componente que o cifra. Nas plataformas com módulo de serviços, o fluxo selecionado é encaminhado para esse módulo e depois regressa ao caminho de encaminhamento. Se o módulo faltar, tiver dimensão insuficiente ou não estiver associado à interface, a configuração existe e nenhum pacote chega a ser processado. Nada na saída do commit distingue esse caso de um estado saudável.
As implementações alojadas em software mantêm o trabalho no motor de encaminhamento ou em hardware inline, com limites de recursos muito diferentes. Um túnel visível na configuração não lhe diz qual desses caminhos o está realmente a transportar.
As cinco partes do tuplo
Escreva a combinação antes de ler qualquer recomendação, porque uma parte pode invalidar as restantes. Um número de peça que suportava um serviço há três anos não diz nada sobre a placa e a versão neste chassis. Leia as linhas seguintes como lista de verificação e depois preencha os valores que a configuração não lhe consegue mostrar.
| Part | What to record | Where it fails quietly |
|---|---|---|
| Chassis and service hardware | Model plus the installed PIC, MPC or MIC | Card absent or not bound to the interface |
| Implementation | Services card, inline or software path | Configuration accepted, no processing |
| Release | Exact Junos version | The feature arrives in a later build |
| Address families and mode | Outer and inner family, tunnel mode, peer authentication | Half the traffic silently unprotected |
| Entitlement and capacity | Licence state and the workload profile | Ceiling reached only under load |
As famílias de endereços e a carga de trabalho são as duas linhas que as pessoas saltam, e ambas são baratas de verificar e caras de descobrir mais tarde. Leia o tuplo a partir do equipamento e não de uma folha de cálculo, porque uma configuração reporta o que pediu, não o que está instalado. Dois comandos transportam a maior parte: show chassis hardware indica a placa realmente instalada e show version dá a versão exata. Nenhum dos dois depende de a configuração estar correta, e é precisamente esse o ponto.
show chassis hardware
show versionOs limiares de versão são limiares reais
O detalhe da versão não é uma formalidade. A visão geral do IPsec da Juniper data o suporte de AES-GCM para placas multiserviços em Junos 17.3R1, com o modo FIPS a começar em 17.4R1. A mesma funcionalidade tem, portanto, dois limiares conforme a forma como a plataforma é operada, e o modo em que corre decide qual se aplica. Verifique o modo antes de verificar a lista de funcionalidades.
Leia as notas de versão da versão exata instalada, não da mais recente documentada. Uma capacidade que chegou numa compilação posterior não pode ser presumida numa anterior, e uma afirmação escrita para uma placa não se transfere para outra. Copie a linha das notas de versão para o registo de conceção, para que a afirmação leve a sua própria fonte, porque uma declaração de suporte escrita para uma família de plataformas não é uma declaração sobre o modo que corre nem sobre a placa que tem.
A capacidade é uma carga de trabalho, não um título
Uma cifra de débito de título sem as suas condições de medição é um número de marketing. Os pacotes pequenos custam muito mais por bit do que os grandes, as associações simultâneas consomem memória, e qualquer outro serviço que partilhe a placa reduz o que resta.
Estime a partir do tráfego que espera: tamanhos de pacote típicos e no pior caso, número de pares e se essa placa também termina NAT ou outro serviço. Depois deixe margem para o dia em que um caminho levar mais carga do que a conceção assumiu. Um plano de capacidade que assume hardware inativo é um desejo, não um plano. Se a cifra importa para o caso de negócio, meça-a uma vez no equipamento sob uma carga representativa e guarde essa medição com a conceção.
Escreva o registo antes da conceção
Para cada capacidade de que a conceção precisa, mantenha a referência da plataforma, a documentação alinhada com a versão e qualquer restrição por resolver num só lugar. Quando uma linha do tuplo falhar, compare outro gateway já aprovado em vez de reconstruir a conceção em torno de uma lista de compras obsoleta. O registo deve dizer qual sistema exato executa a tarefa e sob que limites.
Só depois verifique o par, porque a compatibilidade de protocolo com a extremidade remota é a pergunta seguinte e nunca substitui o suporte local. Um par que concorda com as propostas continua a não conseguir ajudar um chassis que nunca cifra um pacote.