Resumo e análise dos resultados

Desempenho/escala

Embora o máximo desempenho possível e a capacidade de escala do sistema estejam fora do escopo do JVD, a validação demonstrou a propriedade de expansão do complexo e a capacidade de demonstrar desempenho linear e crescimento de escala adicionando novos elementos de serviço ao complexo. O teste inicial é feito com um único par de firewalls da Série SRX para uma combinação típica de tráfego (100 Gbps) como linha de base, um segundo par de firewalls da Série SRX é adicionado ao primeiro para validar a adição da mesma capacidade que o primeiro par está lidando (veja a tabela mais adiante mostrando a escala/desempenho testados por par de firewalls da Série SRX).

Nesse caso, a linearidade de desempenho e escala é óbvia ao adicionar mais pares de firewalls da Série SRX, já que o roteador da Série MX é independente do número de sessões. A quantidade de tráfego permanece dentro dos limites de taxa de transferência MX-PFE, cada novo par MNHA adiciona uma quantidade semelhante de desempenho ao complexo de expansão.

Para entender como atingir um desempenho/capacidade máximo, calcule-o com um exemplo. Adicione qualquer número de firewalls da Série SRX até que a capacidade do roteador seja atingida (por exemplo, 3,2 Tbps de capacidade de encaminhamento com REs redundantes ou 4,8 Tbps sem REs, que é alta) ou sua capacidade máxima de porta (por exemplo, 16 links de 100GE por placa de linha, até duas placas com REs redundantes ou placas de três linhas sem REs).

No lado do firewall da Série SRX, a escalabilidade também depende do tipo de tráfego e de sua capacidade de analisar o conteúdo. Mais conteúdo, mais trabalho de que precisa. Tomando 200 Gbps testados chegaria ao MX304 com placas de duas linhas a 3,2 Tbps / 200 Gbps = 16 SRX, ou placas de três linhas a 4,8 Tbps / 200 Gbps = 24 SRX. O segundo roteador da Série MX e outro firewall da Série SRX, os segundos membros de cada par como backup para poder lidar com uma carga total em caso de grande falha.

Contar o número de portas disponíveis (sem uma camada de distribuição como QFX) forneceria ao MX304 placas de duas linhas (e 2 RE) * 16 portas = 32 portas ou placas de três linhas (e 1 RE) * 16 portas = 48 portas. Isso está dentro dos limites teóricos, pois não considera o uso de interface agregada (2 portas) por firewalls da Série SRX, que divide esse número por 2.

Balanceamento de carga

O hash consistente de ECMP mostrou tempos de restauração estáveis em milissegundos.

O uso do TLB em plataformas de roteador da Série MX mostra que ele também funciona com o roteador da Série MX não testado aqui, onde o TLB usa uma função de controle no RE (como MX304) ou em uma placa de serviço (por exemplo, MS-MPC para MX240). O TLB está no Junos desde o Junos OS Release 18.1R1, quando o BGP adquiriu a função multipath. Essa conexão com o BGP faz com que os provedores de serviços o usem com frequência interna e externamente.

O cenário TLB está trabalhando com temporizadores de restauração e mostra flexibilidade nas opções de implantação (como o roteador da Série MX simples ou duplo é usado), bem como um melhor manuseio dos firewalls da Série SRX no cluster MNHA.

Serviços de Segurança

Os recursos de firewalls da Série SRX utilizados neste JVD se concentram em firewall stateful e CGNAT e não entraram em recursos de segurança de camada superior. O fato de que a arquitetura de escalabilidade horizontal pode lidar com clusters autônomos e SRX, usando uma distribuição uniforme entre vários firewalls da Série SRX, sem perturbar o tráfego, mostra que o serviço de segurança da camada 7 SRX pode ser facilmente adicionado a esse uso.

Observe que, com o ECMP, todos os firewalls da Série SRX precisam ser do mesmo modelo, ao passo que, com o TLB, isso pode aproveitar a noção de grupos TLB para ter grupos de uso (por exemplo, alguns firewalls da Série SRX em grupos SFW e outros firewalls da Série SRX em um grupo CGNAT). O número de grupos é de cerca de 2.000 por roteador da Série MX e o número de membros de firewalls da Série SRX é de cerca de 256. Esses números oferecem um grande potencial para uso futuro.

NAT de grau de operadora

Sobre o CGNAT, a capacidade de registro não é especificamente mencionada, mas pode ser um fator chave. E deve-se notar que um ambiente syslog escalável pode ser definido em ambos os lados do roteador da Série MX e dos firewalls da Série SRX, usando sua capacidade de gerar logs no nível PFE, registrando em ritmo acelerado. Algumas leis locais em vários países precisam registrar muitos eventos de segurança e, mais simplesmente, quais endereços IP participaram de eventos específicos. Então, o endereço IP e a atribuição de NAT são importantes nesses logs. Dependendo do CGNAT usado e da quantidade de políticas de segurança em log ativo, a solução pode gerar um bom número de logs.

O CGNAT pode usar o NAT determinístico para limitar a necessidade de registro relacionado ao NAT e à atribuição de porta (determinada por algoritmo conhecido). Ou outra opção é usar o PBA (Port Block Allocation) em que as portas são alocadas durante períodos e, em seguida, esse evento de atribuição é registrado (begin, update e release).

Cada política de segurança em um firewall da Série SRX pode ter a ação "log session-init", "log session-update" e "log session-close". Cada ação gera um log com o IP/porta de origem/destino real e o IP/porta de origem/destino com NATs. Esse é o recurso que pode gerar a maior quantidade de log. Além disso, para CGNAT, "categoria nat" precisa ser registrado em "fluxo de log de segurança" para registrar mensagens PBA "ALLOC" e "RELEASE".

Escalabilidade horizontal vs. chassi

Esta solução de expansão horizontal é considerada uma alternativa à abordagem de expansão vertical monolítica com os firewalls da Série SRX baseados em chassi ou serviços de segurança em MX960/480 com placas de serviço MX-SPC3. No entanto, nada impede que tais arquiteturas sejam usadas para se beneficiar tanto para aproveitar a possibilidade de adicionar novos serviços quanto o poder dessas plataformas existentes. As próximas pequenas plataformas como MX304 e SRX4700 ajudam a criar uma arquitetura de menor pegada.

Gerenciamento e Automação

Na frente de gerenciamento, a automação de configuração não é coberta. No entanto, ele é usado para ajudar a construir e testar a solução com vários casos de uso e testes. Basicamente, o script é usado com o acesso ao Junos usando o Netconf. Já existem muitos scripts no campo (ou locais de automação da Juniper como o GitHub) usando Ansible, Terraform, Python, PyEZ (Python Easy for Junos) e assim por diante. Alguns usuários avançados já criaram scripts para o Junos, principalmente no espaço do provedor de serviços, onde as APIs são importantes para integração com sua própria estrutura de gerenciamento. As ferramentas podem ser criadas para ajudar no gerenciamento e na automação, sendo executadas on-box (no próprio roteador, pois é compatível com Python) ou off-box em um servidor Linux.

O Security Director (no local ou Security Director Cloud) tem um lugar importante para fornecer configurações comuns à camada de serviço de segurança (como políticas de segurança, objetos de endereço e pools NAT) e para fornecer visibilidade sobre os eventos e logs de segurança gerados por cada firewall da Série SRX.

Roteamento

A integração do Junos com o peering BGP entre o roteador da Série MX e o firewall da Série SRX, inclui os temporizadores BFD certos, permite que você crie um ambiente perfeitamente compatível com todas as soluções da Juniper trabalhando perfeitamente juntas. A redundância de cada roteador e solução de segurança permite que você mantenha o tráfego estável enquanto prevê a adição de novas capacidades de uma maneira simples. Declarações de configuração semelhantes para roteadores da série MX e firewalls da série SRX permitem um gerenciamento simples e contínuo desta solução.