NESTA PÁGINA
Entender o processamento de tráfego em dispositivos de segurança
Entendendo o comportamento de processamento padrão para tráfego IPv4
Entendendo o processamento de tráfego em dispositivos SRX210 e SRX320
Entendendo o processamento de tráfego em dispositivos de linha e SRX1400 SRX3000
Entender o processamento de tráfego em dispositivos de SRX4600
Entender o processamento de tráfego em dispositivos de linha SRX5000
Entendendo o processamento de fluxo em dispositivos SRX5K-SPC3
Visão geral do processamento de tráfego nos firewalls da Série SRX
O Junos OS para dispositivos de segurança integra recursos de segurança e roteamento de rede da Juniper Networks. Os pacotes que entram e saem de um dispositivo passam por processamento baseado em pacotes e baseados em fluxo.
Entender o processamento de tráfego em dispositivos de segurança
O Junos OS para dispositivos de segurança integra os recursos de segurança e roteamento de rede de nível mundial da Juniper Networks. O Junos OS inclui uma ampla gama de filtragem baseada em pacotes, classificadores de classe de serviço (CoS) e recursos de formação de tráfego, bem como um conjunto rico e extenso de recursos de segurança baseados em fluxo, incluindo políticas, telas, tradução de endereços de rede (NAT) e outros serviços baseados em fluxo.
O tráfego que entra e sai de um dispositivo de segurança é processado de acordo com recursos que você configura, como filtros de pacotes, políticas de segurança e telas. Por exemplo, o software pode determinar:
Se o pacote é permitido entrar no dispositivo
Quais telas de firewall aplicar ao pacote
A rota que o pacote faz para chegar ao seu destino
Qual CoS aplicar ao pacote, se houver
Seja para aplicar NAT para traduzir o endereço IP do pacote
Se o pacote requer um gateway de camada de aplicativo (ALG)
Os pacotes que entram e saem de um dispositivo passam por processamento baseado em pacotes e baseados em fluxo:
O processamento de pacotes baseados em fluxo trata pacotes relacionados, ou um fluxo de pacotes, da mesma forma. O tratamento de pacotes depende das características estabelecidas para o primeiro pacote do fluxo de pacotes, que é referido como um fluxo.
Para a arquitetura de processamento distribuída do gateway de serviços, todo o processamento baseado em fluxo ocorre na SPU e a amostragem é consciente de vários tópicos. O sequenciamento de pacotes é mantido para os pacotes amostrados.
O processamento de pacotes baseado em pacotes ou sem estado trata os pacotes de forma discreta. Cada pacote é avaliado individualmente para tratamento.
Para a arquitetura de processamento distribuída do gateway de serviços, alguns processamentos baseados em pacotes, como a modelagem de tráfego, ocorre na NPU. Alguns processamentos baseados em pacotes, como a aplicação de classificadores a um pacote, ocorre na SPU.
Este tópico inclui as seguintes seções:
Entendendo o processamento baseado em fluxo
Um pacote passa por processamento baseado em fluxo após filtros baseados em pacotes e algumas telas terem sido aplicadas a ele. Todo o processamento baseado em fluxo para um único fluxo ocorre em uma única unidade de processamento de serviços (SPU). Uma SPU processa os pacotes de um fluxo de acordo com os recursos de segurança e outros serviços configurados para a sessão.
A Figura 1 mostra uma visão conceitual de como o processamento de tráfego baseado em fluxo ocorre no gateway de serviços.
baseado em fluxo
Um fluxo é um fluxo de pacotes relacionados que atendem aos mesmos critérios de correspondência e compartilham as mesmas características. O Junos OS trata pacotes pertencentes ao mesmo fluxo da mesma maneira.
As configurações que determinam o destino de um pacote — como a política de segurança que se aplica a ele, se requer um gateway de camada de aplicativo (ALG), se o NAT for aplicado para traduzir o endereço IP de origem e/ou destino do pacote — são avaliados para o primeiro pacote de um fluxo.
Para determinar se existe um fluxo para um pacote, a NPU tenta combinar as informações do pacote com as de uma sessão existente com base nos seguintes critérios de correspondência:
Endereço fonte
Endereço de destino
Porta de origem
Porta de destino
Protocolo
Número único de símbolo de sessão para uma determinada zona e roteador virtual
Zonas e políticas
A política de segurança a ser usada para o primeiro pacote de um fluxo é armazenada em cache em uma tabela de fluxo para uso com o mesmo fluxo e fluxos intimamente relacionados. As políticas de segurança estão associadas a zonas. Uma zona é uma coleção de interfaces que definem um limite de segurança. A zona de entrada de um pacote, conforme determinado pela interface pela qual ele chegou, e sua zona de saída, conforme determinado pela busca de encaminhamento, determinam juntos qual política é usada para pacotes do fluxo.
Fluxos e sessões
O processamento de pacotes baseados em fluxo, que é stateful, requer a criação de sessões. Uma sessão é criada para o primeiro pacote de um fluxo para as seguintes finalidades:
Armazenar a maioria das medidas de segurança a serem aplicadas aos pacotes do fluxo.
Para armazenar informações sobre o estado do fluxo.
Por exemplo, o registro e a contagem de informações para um fluxo são armazenados em cache em sua sessão. (Algumas telas de firewall stateful dependem de valores limiares relativos a sessões individuais ou em todas as sessões.)
Alocar recursos necessários para o fluxo para recursos como o NAT.
Para fornecer uma estrutura para recursos como ALGs e recursos de firewall.
A maioria do processamento de pacotes ocorre no contexto de um fluxo, incluindo:
Gerenciamento de políticas, NAT, zonas e a maioria das telas.
Gerenciamento de ALGs e autenticação.
Entendendo o processamento baseado em pacotes
Um pacote passa por processamento baseado em pacotes quando é removido da fila em sua interface de entrada e antes de ser adicionado à fila em sua interface de saída.
O processamento baseado em pacotes aplica filtros de firewall stateless, recursos cos e algumas telas para pacotes discretos.
Quando um pacote chega a uma interface, verificações de sanidade, filtros baseados em pacotes, alguns recursos CoS e algumas telas são aplicados a ele.
Antes que um pacote deixe o dispositivo, quaisquer filtros baseados em pacotes, alguns recursos de CoS e algumas telas associadas à interface são aplicados ao pacote.
Os filtros e os recursos de CoS são tipicamente associados a uma ou mais interfaces para influenciar quais pacotes podem transitar pelo sistema e aplicar ações especiais aos pacotes conforme necessário.
Os tópicos a seguir descrevem os tipos de recursos baseados em pacotes que você pode configurar e aplicar ao tráfego de trânsito.
Filtros de firewall stateless
Também chamados de listas de controle de acesso (ACLs), os filtros de firewall stateless controlam o acesso e limitam as taxas de tráfego. Eles avaliam estaticamente o conteúdo dos pacotes que transitam pelo dispositivo de uma fonte para um destino, ou pacotes originários ou destinados ao Mecanismo de Roteamento. Um filtro de firewall sem estado avalia cada pacote, incluindo pacotes fragmentados.
Você pode aplicar um filtro de firewall sem estado em uma interface de entrada ou saída, ou a ambos. Um filtro contém um ou mais termos, e cada termo consiste em dois componentes — condições e ações compatíveis. Por padrão, um pacote que não corresponda a um filtro de firewall é descartado.
Você pode planejar e projetar filtros de firewall sem estado para serem usados para várias finalidades — por exemplo, para limitar o tráfego a determinados protocolos, endereços de origem ou destino ip ou taxas de dados. Os filtros de firewall stateless são executados na NPU.
Recursos de classe de serviço
Os recursos cos permitem que você classifique e modele o tráfego. Os recursos de CoS são executados na NPU.
Classificadores de agregação de comportamento (BA) — esses classificadores operam em pacotes conforme entram no dispositivo. Usando classificadores agregados de comportamento, o dispositivo agrega diferentes tipos de tráfego em uma única classe de encaminhamento para receber o mesmo tratamento de encaminhamento. Os classificadores BA permitem que você defina a prioridade de classe de encaminhamento e perda de um pacote com base no valor do Serviço Diferenciado (DiffServ).
Modelagem de tráfego — Você pode moldar o tráfego atribuindo níveis de serviço com diferentes características de atraso, jitter e perda de pacotes a aplicativos específicos atendidos por fluxos de tráfego específicos. A modelagem de tráfego é especialmente útil para aplicativos em tempo real, como transmissão de voz e vídeo.
Telas
Algumas telas, como as telas de negação de serviço (DoS), são aplicadas a um pacote fora do processo de fluxo. Eles são executados na unidade de processamento de rede (NPU).
Entendendo o comportamento de processamento padrão para tráfego IPv4
O modo de processamento baseado em fluxo é necessário para que recursos de segurança, como zonas, telas e políticas de firewall funcionem. Por padrão, o firewall da Série SRX é habilitado para encaminhamento baseado em fluxo para tráfego IPv4 em todos os dispositivos, além da Série SRX300 e dispositivos SRX550M que estão definidos para o modo de queda. Começando com o Junos OS Release 15.1X49-D70 e o Junos OS Release 17.3R1 para a série SRX1500, SRX4100, SRX4200, SRX5400, SRX5600, SRX5800 e dispositivos de firewall virtual vSRX, você não precisa reiniciar o dispositivo quando estiver comutando os modos entre o modo de fluxo, o modo de pacote e o modo de queda. Para dispositivos da Série SRX300 e SRX550M, você deve reiniciar o dispositivo ao alternar entre o modo de fluxo, o modo de pacote e o modo de queda.
SRX300 Series and SRX550M
Para a Série SRX300 e os dispositivos SRX550M, o modo de processamento padrão está definido para soltar o modo devido a restrições de memória. Nesse caso, você deve reiniciar o dispositivo depois de mudar o modo de processamento do padrão do modo de queda para o modo de processamento baseado em fluxo ou modo de processamento baseado em pacotes — ou seja, entre os modos nesses dispositivos.
Para processamento de modo de queda, o tráfego é desativado diretamente, não é encaminhado. Ela difere do processamento do modo de pacote para o qual o tráfego é tratado, mas nenhum processo de segurança é aplicado.
Configuring an SRX Series Device as a Border Router
Quando um firewall da Série SRX de qualquer tipo é habilitado para processamento baseado em fluxo ou modo de queda, para configurar o dispositivo como um roteador de borda, você deve alterar o modo para processamento baseado em pacotes para MPLS. Neste caso, para configurar o firewall da Série SRX ao modo de pacote para MPLS, use a set security forwarding-options family mpls mode packet-based declaração.
Como mencionado anteriormente, para a Série SRX300 e os dispositivos SRX550M, sempre que você mudar os modos de processamento, você deve reiniciar o dispositivo.
Entendendo o processamento de tráfego em dispositivos SRX210 e SRX320
Este tópico descreve o processo que os gateways de serviços SRX210 e SRX320 realizam ao estabelecer uma sessão para pacotes pertencentes a um fluxo que transita pelo dispositivo. Os serviços de fluxo dos dispositivos SRX210 e SRX320 são únicos e não distribuídos. Embora diferem dos outros firewalls da Série SRX a esse respeito, o mesmo modelo de fluxo é seguido e a mesma interface de linha de comando (CLI) é implementada.
Para ilustrar o estabelecimento de sessão e o pacote "andar", incluindo os pontos em que os serviços são aplicados aos pacotes de um fluxo, o exemplo descrito nas seções a seguir usa o caso simples de uma sessão unicast:
- Entender o processamento de fluxo e o gerenciamento de sessão
- Entendendo o processamento de primeiro pacote
- Entendendo a criação de sessões
- Entendendo o processamento rápido de caminhos
Entender o processamento de fluxo e o gerenciamento de sessão
Este tópico explica como uma sessão é configurada para processar os pacotes que compõem um fluxo. No tópico a seguir, a SPU refere-se à linha de plano de dados do firewall SRX210 ou SRX320.
No início, a rosca do plano de dados busca o pacote e realiza verificações básicas de sanidade nele. Em seguida, processa o pacote para filtros stateless e classificadores CoS e aplica algumas telas.
Entendendo o processamento de primeiro pacote
Para determinar se um pacote pertence a um fluxo existente, o dispositivo tenta combinar as informações do pacote com as de uma sessão existente com base nos seguintes seis critérios de correspondência:
Endereço fonte
Endereço de destino
Porta de origem
Porta de destino
Protocolo
Símbolo exclusivo de uma determinada zona e roteador virtual
A SPU verifica sua tabela de sessão para uma sessão existente para o pacote. Se nenhuma sessão existente for encontrada, a SPU configura uma sessão para o fluxo. Se uma correspondência de sessão for encontrada, a sessão já foi criada, para que a SPU realize processamento rápido no pacote.
Entendendo a criação de sessões
Ao configurar a sessão, a SPU executa os seguintes serviços para o pacote:
Telas
Busca por rotas
Busca de políticas
Busca de serviços
NAT, se necessário
Após a configuração de uma sessão, ela é usada para todos os pacotes pertencentes ao fluxo. Os pacotes de um fluxo são processados de acordo com os parâmetros de sua sessão. Para o restante das etapas implicadas no processamento de pacotes, prossiga para a Etapa 1 em "Processamento rápido". Todos os pacotes passam por processamento rápido.
Entendendo o processamento rápido de caminhos
Se um pacote corresponde a uma sessão, o Junos OS realiza processamento rápido como descrito nas seguintes etapas. Depois que uma sessão foi configurada para o primeiro pacote em um fluxo, também passa por processamento rápido. Todos os pacotes passam por processamento rápido.
A SPU aplica recursos de segurança baseados em fluxo ao pacote.
As telas configuradas são aplicadas.
Verificações de TCP são realizadas.
Serviços de fluxo, como NAT, ALG e IPsec são aplicados, se necessário.
A SPU prepara o pacote para o encaminhamento e o transmite.
Os filtros de pacotes de roteamento são aplicados.
A modelagem do tráfego é aplicada.
A priorização do tráfego é aplicada.
O agendamento de tráfego é aplicado.
O pacote é transmitido.
Entendendo o processamento de tráfego em dispositivos de linha e SRX1400 SRX3000
O Junos OS para gateways de serviços de SRX1400, SRX3400 e SRX3600 integra os recursos de segurança e roteamento de rede de nível mundial das redes Juniper. O Junos OS para esses gateways de serviço inclui a ampla gama de serviços de segurança, incluindo políticas, telas, tradução de endereços de rede, classificadores de classe de serviço e o amplo e amplo conjunto de serviços baseados em fluxo que também são suportados nos outros dispositivos nos gateways de serviços.
A arquitetura de processamento paralelo distribuída dos dispositivos de SRX1400, SRX3400 e SRX3600 inclui vários processadores para gerenciar sessões e executar a segurança e outros serviços de processamento. Essa arquitetura oferece maior flexibilidade e permite alta taxa de transferência e desempenho rápido.
As seções a seguir descrevem a arquitetura de processamento usando dispositivos de SRX3400 e SRX3600 como exemplo:
Este tópico inclui as seguintes informações:
- Componentes envolvidos na configuração de uma sessão
- Entendendo o caminho de dados para sessões unicast
- Critérios de observação de sessão e correspondência de pacotes
- Entendendo a criação de sessão: primeiro processamento de pacotes
- Entendendo o processamento rápido de caminhos
Componentes envolvidos na configuração de uma sessão
Apresentamos aqui uma visão geral dos principais componentes envolvidos na configuração de uma sessão para um pacote e processamento dos pacotes à medida que transitam pelos dispositivos SRX3400 e SRX3600:
Unidades de processamento de serviços (SPUs) — Os principais processadores dos dispositivos de SRX3400 e SRX3600 residem nas placas de processamento de serviços (SPCs). Eles estabelecem e gerenciam fluxos de tráfego e executam a maior parte do processamento de pacotes em um pacote enquanto ele transita pelo dispositivo. Cada SPU mantém uma tabela de hash para uma rápida busca por sessão. A SPU realiza todo o processamento baseado em fluxo para um pacote, incluindo a aplicação de serviços de segurança, classificadores e shapers de tráfego. Todos os pacotes que pertencem ao mesmo fluxo são processados pela mesma SPU.
A SPU mantém uma tabela de sessões com entradas para todas as sessões que estabeleceu e cujos pacotes processam. Quando um SPU recebe um pacote de um NPU, ele verifica sua tabela de sessão para garantir que o pacote pertence a ele.
Para dispositivos de SRX3400 e SRX3600, uma SPU atua em conjunto realizando suas funções regulares de gerenciamento de sessão e processamento de fluxo e atuando como um ponto central no qual arbitra sessões e aloca recursos. Quando um SPU funciona dessa maneira, diz-se que está no modo combo.
Ponto central — o ponto central é usado para alocar o gerenciamento de sessão para SPUs com base em critérios de balanceamento de carga. Ele distribui sessões de forma inteligente para evitar ocorrências nas quais várias SPUs podem lidar mal com o mesmo fluxo. O ponto central segue critérios de balanceamento de carga na alocação de sessões para SPUs. Se a sessão existir, o ponto central encaminha pacotes para esse fluxo para a SPU que a hospeda. Ele também redireciona os pacotes para a SPU correta caso a NPU não o faça.
Para os dispositivos SRX3400 e SRX3600, uma SPU sempre funciona no modo combo no qual implementa tanto a funcionalidade do ponto central quanto a funcionalidade de gerenciamento de fluxo e sessão. No modo combo, a SPU e o ponto central compartilham a mesma infraestrutura de thread de balanceamento de carga (LBT) e thread de pedido de pacotes (POT). .
Mecanismo de roteamento (RE) — O mecanismo de roteamento executa o plano de controle e gerencia o processador de plano de controle (CPP).
Entendendo o caminho de dados para sessões unicast
O Junos OS para gateways de serviços de SRX3400 e SRX3600 é um sistema distribuído de processamento paralelo de alta taxa de transferência e alto desempenho. Este tópico descreve o processo de estabelecer uma sessão para pacotes pertencentes a um fluxo que transita pelo dispositivo.
Para ilustrar o estabelecimento de sessão e o pacote "walk" incluindo os pontos em que os serviços são aplicados aos pacotes de um fluxo, o exemplo a seguir usa o caso simples de uma sessão unicast. Este pacote "walk" reúne o processamento baseado em pacotes e o processamento baseado em fluxo que o Junos OS executa no pacote.
Critérios de observação de sessão e correspondência de pacotes
Para determinar se um pacote pertence a um fluxo existente, o dispositivo tenta combinar as informações do pacote com as de uma sessão existente com base nos seguintes seis critérios de correspondência:
Endereço fonte
Endereço de destino
Porta de origem
Porta de destino
Protocolo
Símbolo exclusivo de uma determinada zona e roteador virtual
Entendendo a criação de sessão: primeiro processamento de pacotes
Este tópico explica como uma sessão é configurada para processar os pacotes que compõem um fluxo. Para ilustrar o processo, este tópico usa um exemplo com uma fonte "a" e um destino "b". A direção da fonte ao destino para os pacotes do fluxo é referida como (a -> b). A direção do destino à fonte é referida como (b -> a).
Um pacote chega a uma interface no dispositivo e o IOC o processa.
O IOC desqueia o pacote e o envia para a NPU com a qual se comunica.
O NPU recebe o pacote do IOC e o processa.
O NPU realiza verificações básicas de sanidade no pacote e aplica algumas telas configuradas para a interface do pacote.
Se uma correspondência de sessão for encontrada, a sessão já foi criada em uma SPU que foi atribuída a ela, para que a NPU encaminhe o pacote para a SPU para processamento junto com o ID da sessão.
Exemplo: Packet (a->b) chega ao NPU1 do IOC1. O NPU1 realiza verificações de sanidade e aplica telas DoS ao pacote. O NPU1 verifica sua tabela de sessão para uma correspondência de tuple e nenhuma sessão existente é encontrada. O NPU1 encaminha o pacote para o ponto central do SPU1 para atribuição a uma SPU.
O ponto central cria uma sessão com um estado "pendente".
O ponto central mantém uma tabela de sessões global que inclui entradas para todas as sessões que existem em todas as SPUs do dispositivo. Ele participa da criação de sessões e delegados e arbitra a alocação de recursos de sessão.
Esse processo implica as seguintes partes:
O ponto central verifica sua tabela de sessão e a tabela de portão para determinar se existe uma sessão ou um portão para o pacote que recebe da NPU. (Um NPU encaminhou um pacote para o ponto central porque sua tabela indica que não há sessão para ele. O ponto central verifica essas informações antes de alocar uma SPU para a sessão.)
Se não houver nenhuma entrada que corresponda ao pacote em qualquer tabela, o ponto central cria uma ala pendente para a sessão e seleciona uma SPU a ser usada para a sessão, com base em seu algoritmo de balanceamento de carga.
O ponto central encaminha o primeiro pacote do fluxo para a SPU selecionada em uma mensagem dizendo-lhe para configurar uma sessão localmente a ser usada para o fluxo de pacotes.
Exemplo: o ponto central cria ala pendente (a->b) para a sessão. Ele seleciona o SPU1 para ser usado para a sessão. Ele envia o pacote SPU1 (a->b) junto com uma mensagem para criar uma sessão para ele. (Acontece que o SPU1 é o SPU que funciona no modo combo. Portanto, seus serviços de gerenciamento de sessão e processamento de fluxo são usados para a sessão.
A SPU configura a sessão.
Cada SPU também tem uma tabela de sessões, que contém informações sobre suas sessões. Quando a SPU recebe uma mensagem do ponto central para configurar uma sessão, ela verifica sua tabela de sessão para garantir que uma sessão ainda não exista para o pacote.
Se não houver uma sessão existente para o pacote, a SPU configura a sessão localmente.
A SPU envia uma mensagem ao ponto central, dizendo-lhe para instalar a sessão.
Durante o processamento de primeiro pacote, se o NAT estiver habilitado, a SPU aloca recursos de endereço IP para NAT. Neste caso, o processamento do primeiro pacote para a sessão é suspenso até que o processo de alocação de NAT seja concluído.
A SPU adiciona à fila quaisquer pacotes adicionais para o fluxo que ele possa receber até que a sessão seja instalada.
Exemplo: o SPU1 cria a sessão para (uma ->b) e envia uma mensagem de volta ao ponto central (implementado na mesma SPU) dizendo-lhe para instalar a sessão pendente.
O ponto central instala a sessão.
Ele define o estado para que a ala pendente da sessão esteja ativa.
Ele instala a ala inversa para a sessão como uma ala ativa.
Ele envia uma mensagem de ACK (reconhecimento) à SPU, indicando que a sessão está instalada.
Exemplo: o ponto central recebe uma mensagem do SPU1 para instalar a sessão (a->b). Ele define o estado de sessão para (a->b) ala ativa. Ele instala a asa reversa (b->a) para a sessão e a torna ativa; isso permite a entrega de pacotes na direção inversa do fluxo: destino (b) a ser entregue na fonte (a).
A SPU configura a sessão sobre as NPUs de entrada e saída.
As NPUs mantêm informações sobre uma sessão para encaminhamento e entrega de pacotes. As informações da sessão são configuradas na saída e entrada de NPUs (que às vezes são as mesmas) para que os pacotes possam ser enviados diretamente para a SPU que gerencia seus fluxos e não para o ponto central para redirecionamento.
O processamento rápido ocorre.
Para o restante das etapas implicadas no processamento de pacotes, siga para a Etapa 1 em "Entendendo o processamento rápido".
Entendendo o processamento rápido de caminhos
Todos os pacotes passam por processamento rápido. No entanto, se existe uma sessão para um pacote, o pacote passa por processamento rápido e ignora o processo de primeiro pacote. Quando já existe uma sessão para o fluxo do pacote, o pacote não transita pelo ponto central.
Veja como o processamento de caminho rápido funciona: as NPUs nas interfaces de saída e entrada contêm tabelas de sessão que incluem a identificação da SPU que gerencia o fluxo de um pacote. Como as NPUs têm essas informações de sessão, todo o tráfego para o fluxo, incluindo tráfego reverso, é enviado diretamente à SPU para processamento.
Em dispositivos de SRX1400, SRX3400 e SRX3600, a funcionalidade iflset não é suportada para interfaces agregadas como a reth.
Entender o processamento de tráfego em dispositivos de SRX4600
O Firewall SRX4600 da Juniper Networks integra serviços de segurança e roteamento baseados em fluxo, incluindo segurança avançada e mitigação de ameaças e segurança de firewall stateful tradicional. A infraestrutura baseada em fluxo junos OS oferece a base e a estrutura para serviços baseados em aplicativos de Camada 4 a Camada 7. O firewall SRX4600 foi projetado para ser implantado como um firewall integrado na borda de data center e núcleo de data center de grandes empresas, além da borda do campus. Ele também pode ser implantado como um gateway de segurança LTE e um firewall Gi/SGi.
Este tópico inclui o seguinte conteúdo:
- Entendendo os cenários de implantação do firewall SRX4600 e seus recursos
- Processamento baseado em fluxo e fundamentos de sessão
- Componentes subjacentes de fluxo e sessão implementados em firewalls da Série SRX
Entendendo os cenários de implantação do firewall SRX4600 e seus recursos
O firewall SRX4600 pode ser implantado em muitas áreas para proteger o seu ambiente e seus recursos. É frequentemente usado para proteger a borda e o núcleo do data center das seguintes maneiras:
Implantação do firewall SRX4600 como um firewall de borda de data center
Você pode implantar o firewall SRX4600 na borda do seu data center para fornecer os aplicativos e serviços que hospeda com a proteção ideal. Todo data center tem um ponto de entrada para permitir que os clientes acessem os serviços do data center, mas os agressores mal-intencionados podem aproveitar isso para lançar ataques contra esses serviços. Uma grande quantidade de tráfego que entra no data center é o tráfego de internet de entrada. Por esse motivo, é essencial implantar uma segurança robusta e multicamadas na borda do data center. O firewall SRX4600 bloqueia ataques de forma eficaz e dependente, e permite que você configure o sistema para impedir tipos específicos de ataques. O firewall SRX4600 oferece suporte à estrutura de rede segura definida por software (SDSN) da Juniper, incluindo o Juniper Advanced Threat Prevention Cloud (ATP Cloud), que é construído em torno de inteligência automatizada e acionável que pode ser compartilhada rapidamente para reconhecer e mitigar ameaças. A Figura 2 mostra o firewall SRX4600 implantado na borda do data center em conjunto com um roteador MX480 e switches da Série EX.
Figura 2: Implantação do firewall SRX4600 na borda
do data center
Implantação do firewall SRX4600 no núcleo do data center
Você pode implantar o firewall SRX4600 no núcleo do data center para fornecer segurança aprimorada e garantir que os requisitos de conformidade sejam atendidos. O processamento de data center tornou-se cada vez mais dinâmico, exigindo uma definição clara da rede e a aplicação dos requisitos de conformidade. Para garantir a conformidade, você pode usar o firewall SRX4600 para segmentar sua rede geral em redes de servidor individuais e proteger o tráfego dentro deles. O firewall SRX4600 oferece alta disponibilidade e automação, e seus serviços de Camada 3 e Camada 4 de alto desempenho atendem aos requisitos de segurança do núcleo do data center. A Figura 3 mostra o firewall SRX4600 implantado como um firewall de várias camadas no núcleo do data center.
Figura 3: Implantação do firewall SRX4600 no núcleo do data center
Além de seus avançados recursos anti-malware, o firewall SRX4600 oferece suporte aos seguintes recursos:
Firewall stateful
Pacote de segurança de aplicativos
Segurança de conteúdo (Sophos AV, filtragem de Web, antispam)
IDP
Alta disponibilidade (cluster de chassi)
Portas de controle de HA duplas (10G)
Suporte MACsec para portas HA
Interfaces de ethernet através dos modos QSFP28 (modos 100G/40G/4x10G), QSFP+ (modos 40G/4x10G) e SFP+ (modo 10G)
VPN IPsec, incluindo AutoVPN e VPNv2 do grupo
QoS e serviços de rede
J-Web
Políticas de roteamento com multicast
Processamento baseado em fluxo e fundamentos de sessão
Para entender o processamento de fluxo no firewall SRX4600, é importante entender os fundamentos do fluxo.
Um fluxo é um fluxo de pacotes relacionados que atendem aos mesmos critérios de correspondência e compartilham as mesmas características. O Junos OS trata pacotes que pertencem ao mesmo fluxo da mesma maneira. A arquitetura de um gateway de serviços da Série SRX e como ele lida com os fluxos de pacotes são estreitamente acoplados. Consequentemente, em parte, o fluxo é implementado de forma diferente em toda a família de firewalls da Série SRX devido às suas diferenças arquitetônicas.
O processamento de pacotes baseados em fluxo, que é stateful, requer a criação de sessões. As sessões são criadas com base no roteamento e outras informações de classificação de tráfego para armazenar informações e alocar recursos para um fluxo. As sessões armazenam informações sobre o estado do fluxo e armazenam a maioria das medidas de segurança a serem aplicadas aos pacotes do fluxo. Devido às diferenças arquitetônicas entre dispositivos, as sessões também são gerenciadas de forma diferente por diferentes dispositivos.
Independentemente dessas diferenças, conceitualmente o processo de fluxo é o mesmo em todos os gateways de serviços, e as sessões atendem aos mesmos propósitos e têm os mesmos recursos.
Componentes subjacentes de fluxo e sessão implementados em firewalls da Série SRX
Os firewalls da Série SRX usam os mesmos componentes de infraestrutura para oferecer suporte ao fluxo e gerenciar sessões, mas nem todos os dispositivos implementam todos eles.
Para entender o fluxo, é essencial entender os seguintes componentes e como eles são usados:
A unidade de processamento de serviços (SPU)
Uma SPU gerencia a sessão para um fluxo de pacotes. Ele aplica recursos de segurança e outros serviços ao pacote. Ele também aplica filtros de firewall stateless baseados em pacotes, classificadores e shapers de tráfego ao pacote.
O ponto central (CP)
O ponto central é uma SPU que o sistema usa para alocar recursos e distribuir o gerenciamento de sessão entre as SPUs. Quando o primeiro pacote de um fluxo é processado, o ponto central determina qual SPU usar para a sessão desse pacote. O firewall SRX4600 não implementa um ponto central.
A unidade de processamento de rede (NPU) e a sessão de processamento de rede
Um NPU é um processador que é executado em uma placa de E/S (IOC) e processa pacotes de forma discreta. Quando um fluxo é criado, os pacotes subsequentes do fluxo são combinados com a sessão na NPU. A NPU lida com processamento adicional, como verificação de sequência de TCP, processamento de tempo de vida (TTL) e tradução de cabeçalho de Camada 2. Um NPU melhora o desempenho nesse encaminhamento extra de pacotes entre uma SPU de sessão e um hash-SPU é evitado. O firewall SRX4600 implementa uma NPU.
A arquitetura de fluxo de firewall SRX4600 foi melhorada para otimizar o uso dos avançados processadores Xeon™ multi-core do dispositivo SRX4600. O firewall SRX4600 implementa o uso de um thread de sessão dedicado para contornar problemas como o gerenciamento de pacotes fora de ordem em um fluxo. Ele utiliza a sessão de processamento de rede para garantir que os pacotes sejam encaminhados para o thread certo e dedicado. Os pacotes são distribuídos para diferentes threads de acordo com o modelo de distribuição de sessão baseado em hash.
Entender o processamento de tráfego em dispositivos de linha SRX5000
O Junos OS em dispositivos SRX5000 é um sistema distribuído, de processamento paralelo, de alta taxa de transferência e de alto desempenho. A arquitetura de processamento paralelo distribuída da linha SRX5000 de gateways de serviços inclui vários processadores para gerenciar sessões e executar a segurança e outros processamentos de serviços. Essa arquitetura oferece maior flexibilidade e permite alta taxa de transferência e desempenho rápido.
Em SRX1400, SRX3400, SRX3600, SRX5400, SRX5600 e dispositivos SRX5800, as negociações de IKE envolvendo a travessia de NAT não funcionam se o peer IKE estiver por trás de um dispositivo NAT que alterará o endereço IP de origem dos pacotes IKE durante a negociação. Por exemplo, se o dispositivo NAT estiver configurado com DIP, ele muda o IP de origem porque o protocolo IKE muda a porta UDP de 500 para 4500.
As placas de E/S (IOCs) e as placas de processamento de serviços (SPCs) em dispositivos de linha SRX5000 contêm unidades de processamento que processam um pacote enquanto ele atravessa o dispositivo. Um IOC tem uma ou mais unidades de processamento de rede (NPUs), e um SPC tem uma ou mais unidades de processamento de serviços (SPUs).
Essas unidades de processamento têm responsabilidades diferentes. Todos os serviços baseados em fluxo para um pacote são executados em uma única SPU. As responsabilidades dessas NPUs não estão claramente delineadas em relação aos outros tipos de serviços que as executam. .)
Por exemplo:
Um NPU processa pacotes de forma discreta. Ele realiza verificações de sanidade e aplica algumas telas que estão configuradas para a interface, como as telas de negação de serviço (DoS) ao pacote.
Um SPU gerencia a sessão para o fluxo de pacotes e aplica recursos de segurança e outros serviços ao pacote. Ele também aplica filtros de firewall stateless baseados em pacotes, classificadores e shapers de tráfego ao pacote.
Um NPU encaminha um pacote para a SPU usando o algoritmo de hash. No entanto, para alguns aplicativos, como ALG, o sistema precisará consultar o ponto central do aplicativo para determinar qual SPU o pacote deve ser processado.
Essas partes discretas e cooperativas do sistema, incluindo o ponto central, armazenam as informações identificando se existe uma sessão para um fluxo de pacotes e as informações contra as quais um pacote é combinado para determinar se ele pertence a uma sessão existente.
Essa arquitetura permite que o dispositivo distribua o processamento de todas as sessões em várias SPUs. Ele também permite que um NPU determine se existe uma sessão para um pacote, verificar o pacote e aplicar telas ao pacote. A forma como um pacote é tratado depende se é o primeiro pacote em um fluxo.
As seções a seguir descrevem a arquitetura de processamento usando dispositivos de SRX5400, SRX5600 e SRX5800 como exemplo:
- Entendendo o processamento de primeiro pacote
- Entendendo o processamento rápido de caminhos
- Entendendo o caminho de dados para sessões unicast
- Entendendo as unidades de processamento de serviços
- Entender as características do agendador
- Entendendo o processador de rede Bundling
Entendendo o processamento de primeiro pacote
A Figura 4 ilustra o caminho que o primeiro pacote em um fluxo toma quando ele entra no dispositivo — a NPU determina que nenhuma sessão existe para o pacote, e a NPU envia o pacote para o ponto central distribuído para configurar uma sessão de ponto central distribuída. Em seguida, o ponto central distribuído envia uma mensagem ao ponto central do aplicativo para selecionar a SPU para configurar uma sessão para o pacote e processar o pacote. O ponto central distribuído então envia o pacote para essa SPU. O SPU processa o pacote e o envia para a NPU para transmissão do dispositivo. (Esta descrição de alto nível não aborda a aplicação de recursos a um pacote.)
de primeiro pacote
Depois que o primeiro pacote em um fluxo passou pelo sistema e uma sessão foi estabelecida para ele, ele passa por processamento rápido.
Os pacotes subsequentes no fluxo também passam por processamento rápido; neste caso, após cada pacote entrar na sessão e a NPU encontrar uma correspondência para ele em sua tabela de sessão, a NPU encaminha o pacote para a SPU que gerencia sua sessão.
A Figura 5 ilustra o processamento rápido do caminho. Este é o caminho que um pacote toma quando um fluxo já foi estabelecido para seus pacotes relacionados. (É também o caminho que o primeiro pacote em um fluxo toma após a sessão para o fluxo que o pacote iniciado foi configurado.) Após a entrada do pacote no dispositivo, a NPU encontra uma correspondência para o pacote em sua tabela de sessão e encaminha o pacote para a SPU que gerencia a sessão do pacote. Observe que o pacote ignora a interação com o ponto central.
Entendendo o processamento rápido de caminhos
A seção a seguir explica como uma sessão é criada e o processo pelo qual um pacote passa enquanto transita pelo dispositivo.
rápido
Apresentamos aqui uma visão geral dos principais componentes envolvidos na configuração de uma sessão para um pacote e processamento de pacotes, tanto de forma discreta quanto como parte de um fluxo enquanto transitam pelos dispositivos SRX5400, SRX5600 e SRX5800.
Unidades de processamento de rede (NPUs) — as NPUs residem em IOCs. Eles lidam com a verificação de sanidade de pacotes e a aplicação de algumas telas. As NPUs mantêm tabelas de sessão que usam para determinar se existe uma sessão para um pacote de entrada ou para tráfego reverso.
A tabela de sessão da NPU contém uma entrada para uma sessão se a sessão for estabelecida em uma SPU para um pacote que já havia entrado no dispositivo por meio da interface e que foi processado por esta NPU. A SPU instala a sessão na tabela de NPU quando cria a sessão.
Um NPU determina se existe uma sessão para um pacote verificando as informações do pacote em relação à tabela de sessão. Se o pacote corresponde a uma sessão existente, a NPU envia o pacote e os metadados para ele para a SPU. Se não houver sessão, o NPUs envia o pacote para uma SPU que é calculada usando o algoritmo de hash.
Unidades de processamento de serviços (SPUs) — Os principais processadores dos dispositivos de SRX5400, SRX5600 e SRX5800 residem em SPCs. As SPUs estabelecem e gerenciam fluxos de tráfego e executam a maior parte do processamento de pacotes em um pacote enquanto ele transita pelo dispositivo. Cada SPU mantém uma tabela de hash para uma rápida busca por sessão. A SPU aplica filtros de firewall stateless, classificadores e shapers de tráfego ao tráfego. Uma SPU realiza todo o processamento baseado em fluxo para um pacote e a maioria dos processamentos baseados em pacotes. Cada SPU multicore processa pacotes de forma independente, com interação mínima entre SPUs no mesmo SPC ou diferente. Todos os pacotes que pertencem ao mesmo fluxo são processados pela mesma SPU.
A SPU mantém uma tabela de sessões com entradas para todas as sessões que estabeleceu e cujos pacotes processam. Quando um SPU recebe um pacote de um NPU, ele verifica sua tabela de sessão para garantir que o pacote pertence a ele. Ele também verifica sua tabela de sessão quando recebe um pacote do ponto central distribuído e envia uma mensagem para estabelecer uma sessão para esse pacote para verificar se não há uma sessão existente para o pacote.
Ponto central — A arquitetura do ponto central é dividida em dois módulos, o ponto central do aplicativo e o ponto central distribuído. O ponto central do aplicativo é responsável pelo gerenciamento global de recursos e balanceamento de carregamento, enquanto o ponto central distribuído é responsável pela identificação de tráfego (correspondência global da sessão). A funcionalidade do ponto central do aplicativo é executado na SPU de ponto central dedicada, enquanto a funcionalidade de ponto central distribuída é distribuída para o resto das SPUs. Agora, as sessões de ponto central não estão mais na SPU de ponto central dedicada, mas com o ponto central distribuído em outras SPUs de fluxo.
Mecanismo de roteamento — o mecanismo de roteamento executa o plano de controle.
Entendendo o caminho de dados para sessões unicast
Esta seção descreve o processo de estabelecer uma sessão para pacotes pertencentes a um fluxo que transita pelo dispositivo.
Para ilustrar o estabelecimento de sessão e o pacote "walk" incluindo os pontos em que os serviços são aplicados aos pacotes em um fluxo, este exemplo usa o caso simples de uma sessão unicast.
Este pacote "walk" reúne o processamento baseado em pacotes e o processamento baseado em fluxo que o Junos OS executa no pacote.
- Critérios de pesquisa de sessão e correspondência de pacotes
- Entendendo a criação de sessão: processamento de primeiro pacote
- Entendendo o processamento rápido de caminhos
Critérios de pesquisa de sessão e correspondência de pacotes
Para determinar se um pacote pertence a um fluxo existente, o dispositivo tenta combinar as informações do pacote com as de uma sessão existente com base nos seguintes seis critérios de correspondência:
Endereço fonte
Endereço de destino
Porta de origem
Porta de destino
Protocolo
Símbolo exclusivo de uma determinada zona e roteador virtual
Entendendo a criação de sessão: processamento de primeiro pacote
Esta seção explica como uma sessão é configurada para processar os pacotes que compõem um fluxo. Para ilustrar o processo, esta seção usa um exemplo com uma fonte "a" e um destino "b". A direção da fonte ao destino para os pacotes do fluxo é referida como (a ->b). A direção do destino à fonte é referida como (b->a).
Passo 1. Um pacote chega a uma interface no dispositivo e o NPU o processa.
Esta seção descreve como um pacote é tratado quando ele chega a um IOC de entrada da Série SRX.
O pacote chega ao IOC do dispositivo e é processado pela NPU no IOC.
O NPU realiza verificações básicas de sanidade no pacote e aplica algumas telas configuradas para a interface do pacote.
A NPU verifica sua tabela de sessão para uma sessão existente para o pacote. (Ele verifica a sintonia do pacote com os dos pacotes para sessões existentes em sua tabela de sessão.)
Se nenhuma sessão existente for encontrada, a NPU encaminha o pacote para a SPU de hash.
Se uma correspondência de sessão for encontrada, a sessão já foi criada em uma SPU que foi atribuída a ela, para que a NPU encaminhe o pacote para a SPU para processamento junto com o ID da sessão.
Example: Packet (a ->b) chega ao NPU1. O NPU1 realiza verificações de sanidade e aplica telas DoS ao pacote. A NPU1 verifica sua tabela de sessão para uma correspondência de tuple, e nenhuma sessão existente é encontrada. O NPU1 encaminha o pacote para uma SPU.
Passo 2. O ponto central distribuído cria uma sessão com um estado "pendente".
Quando um NPU recebe um pacote, o NPU o envia para o ponto central distribuído, com base no algoritmo de hash. O ponto central distribuído então olha para a tabela de sessão de ponto central distribuída e cria uma entrada, se necessário.
Esse processo implica as seguintes partes:
O ponto central distribuído verifica sua tabela de sessão para determinar se existe uma sessão para o pacote recebido da NPU. (Um NPU encaminha um pacote para o ponto central distribuído porque não consegue encontrar uma sessão existente para o pacote)
Se não houver nenhuma entrada que corresponda ao pacote na tabela de sessão distribuída do ponto central, o ponto central distribuído cria uma ala pendente para a sessão. Em seguida, o ponto central distribuído envia uma mensagem de consulta ao ponto central do aplicativo para selecionar uma SPU a ser usada para a sessão.
Ao receber a mensagem de consulta, o ponto central do aplicativo verifica a tabela de portão para determinar se existe um portão para o pacote. Se um portão for combinado ou algum outro algoritmo de distribuição de sessão for acionado, o ponto central do aplicativo seleciona outra SPU para processar o pacote; caso contrário, a SPU (ou seja, a SPU de ponto central distribuída) é selecionada. Por fim, o ponto central do aplicativo envia uma resposta de consulta ao ponto central distribuído.
Ao receber a resposta de consulta, o ponto central distribuído encaminha o primeiro pacote em fluxo para a SPU selecionada em uma mensagem direcionando a SPU para configurar uma sessão localmente a ser usada para o fluxo de pacotes. Por exemplo, o ponto central distribuído cria uma ala pendente (uma ->b) para a sessão. O ponto central do aplicativo seleciona o SPU1 para ser usado para ele. O ponto central distribuído envia ao SPU1 o pacote (a->b) juntamente com uma mensagem para criar uma sessão para o ponto central distribuído.
Example: O ponto central distribuído cria uma ala pendente (uma ->b) para a sessão. Ele seleciona o SPU1 para ser usado para ele. Ele envia o pacote SPU1 (a->b) junto com uma mensagem para criar uma sessão para ele.
Passo 3. A SPU configura a sessão.
Cada SPU também tem uma tabela de sessões, que contém informações sobre suas sessões. Quando a SPU recebe uma mensagem do ponto central distribuído para configurar uma sessão, ela verifica sua tabela de sessão para garantir que uma sessão ainda não exista para o pacote.
Se não houver uma sessão existente para o pacote, a SPU configura a sessão localmente.
A SPU envia uma mensagem ao ponto central distribuído direcionando-a para a instalação da sessão.
Nota:Durante o processamento de primeiro pacote, se o NAT estiver habilitado, a SPU aloca recursos de endereço IP para NAT. Neste caso, o processamento do primeiro pacote para a sessão é suspenso até que o processo de alocação de NAT seja concluído.
A SPU adiciona à fila quaisquer pacotes adicionais para o fluxo que ele possa receber até que a sessão seja instalada.
Example: A SPU1 cria a sessão para (uma ->b) e envia uma mensagem de volta ao ponto central distribuído direcionando-a para instalar a sessão pendente.
Passo 4. O ponto central distribuído instala a sessão.
O ponto central distribuído recebe a mensagem de instalação da SPU.
O ponto central distribuído define o estado para que a ala pendente da sessão esteja ativa.
O ponto central distribuído instala a ala reversa para a sessão como uma ala ativa.
Nota:Para alguns casos, como o NAT, a ala inversa pode ser instalada em um ponto central distribuído diferente do ponto central distribuído da ala de init.
Ele envia uma mensagem de reconhecimento (ACK) à SPU, indicando que a sessão está instalada.
Example: O ponto central distribuído recebe uma mensagem do SPU1 para instalar a sessão para a ala (a->b). Ele define o estado de sessão para a ala (a->b) ativa. Ele instala a asa reversa (b->a) para a sessão e a torna ativa; isso permite a entrega de pacotes na direção inversa do fluxo: destino (b) a ser entregue na fonte (a).
Passo 5. A SPU configura a sessão sobre as NPUs de entrada e saída.
As NPUs mantêm informações sobre uma sessão para encaminhamento e entrega de pacotes. As informações da sessão são configuradas sobre as NPUs de saída e entrada (que às vezes são as mesmas) para que os pacotes possam ser enviados diretamente para a SPU que gerencia seus fluxos e não para o ponto central distribuído para redirecionamento.
Passo 6. O processamento rápido ocorre.
Para o restante das etapas implicadas no processamento de pacotes, siga para a Etapa 1 na compreensão do processamento rápido do caminho.
A Figura 6 ilustra a primeira parte do processo pela qual o primeiro pacote em um fluxo passa após chegar ao dispositivo. Neste ponto, uma sessão é configurada para processar o pacote e o resto dos pacotes pertencentes ao seu fluxo. Posteriormente, ele e o restante dos pacotes no fluxo passam por processamento rápido.
de primeiro pacote
Entendendo o processamento rápido de caminhos
Todos os pacotes passam por processamento rápido. No entanto, se existe uma sessão para um pacote, o pacote passa por processamento rápido e ignora o processo de primeiro pacote. Quando já existe uma sessão para o fluxo do pacote, o pacote não transita pelo ponto central.
Veja como o processamento de caminho rápido funciona: as NPUs nas interfaces de saída e entrada contêm tabelas de sessão que incluem a identificação da SPU que gerencia o fluxo de um pacote. Como as NPUs têm essas informações de sessão, todo o tráfego para o fluxo, incluindo tráfego reverso, é enviado diretamente à SPU para processamento.
Para ilustrar o processo de caminho rápido, esta seção usa um exemplo com uma fonte "a" e um destino "b". A direção da fonte ao destino para os pacotes do fluxo é referida como (a->b). A direção do destino à fonte é referida como (b->a).
Passo 1. Um pacote chega ao dispositivo e o NPU o processa.
Esta seção descreve como um pacote é tratado quando ele chega ao IOC de um gateway de serviços.
O pacote chega ao IOC do dispositivo e é processado pela NPU no cartão.
A NPU realiza verificações de sanidade e aplica algumas telas, como telas de negação de serviço (DoS) ao pacote.
A NPU identifica uma entrada para uma sessão existente em sua tabela de sessão que o pacote corresponde.
A NPU encaminha o pacote juntamente com metadados de sua tabela de sessão, incluindo as informações de ID de sessão e tuple de pacotes, para a SPU que gerencia a sessão para o fluxo, aplica filtros de firewall sem estado e recursos CoS em seus pacotes, e lida com o processamento de fluxo e a aplicação de segurança do pacote e outros recursos.
Example: Packet (a ->b) chega ao NPU1. O NPU1 realiza verificações de sanidade no pacote, aplica telas DoS a ele e verifica sua tabela de sessão para uma correspondência de tuple. Ele encontra uma correspondência e que existe uma sessão para o pacote no SPU1. O NPU1 encaminha o pacote ao SPU1 para processamento.
Passo 2. A SPU para a sessão processa o pacote.
A maior parte do processamento de um pacote ocorre na SPU à qual sua sessão é atribuída. O pacote é processado para recursos baseados em pacotes, como filtros de firewall stateless, shapers de tráfego e classificadores, se aplicável. A segurança baseada em fluxo configurada e serviços relacionados, como recursos de firewall, NAT, ALGs e assim por diante, são aplicados ao pacote. (Para obter informações sobre como os serviços de segurança são determinados para uma sessão.
Antes de processar o pacote, a SPU verifica sua tabela de sessão para verificar se o pacote pertence a uma de suas sessões.
A SPU processa o pacote para recursos e serviços aplicáveis.
Example: O SPU1 recebe pacotes (a->b) da NPU1. A SPU1 verifica sua tabela de sessão para verificar se o pacote pertence a uma de suas sessões. Em seguida, processa pacotes (a->b) de acordo com filtros de entrada e recursos CoS que se aplicam à sua interface de entrada. A SPU aplica os recursos e serviços de segurança que estão configurados para o fluxo do pacote para ele, com base em sua zona e políticas. Se algum estiver configurado, ele aplica filtros de saída, shapers de tráfego e telas adicionais ao pacote.
Passo 3. A SPU encaminha o pacote para a NPU.
A SPU encaminha o pacote para a NPU.
O NPU aplica quaisquer telas aplicáveis associadas à interface ao pacote.
Example: O SPU1 encaminha pacotes (a ->b) para NPU2, e o NPU2 aplica telas DoS.
Passo 4. A interface transmite o pacote do dispositivo.
Example: A interface transmite pacotes (a->b) do dispositivo.
Passo 5. Um pacote de tráfego reverso chega à interface de saída e o NPU o processa.
Essa etapa espelha a Etapa 1 exatamente ao contrário. Veja a etapa 1 nesta seção para obter mais detalhes.
Example: O pacote (b->a) chega ao NPU2. O NPU2 verifica a tabela de sessão para uma combinação de tuple. Ele encontra uma correspondência e que existe uma sessão para o pacote no SPU1. O NPU2 encaminha o pacote ao SPU1 para processamento.
Passo 6. A SPU para a sessão processa o pacote de tráfego reverso.
Essa etapa é a mesma da Etapa 2, exceto que se aplica ao tráfego reverso. Veja a etapa 2 nesta seção para obter mais detalhes.
Example: O SPU1 recebe pacotes (b->a) do NPU2. Ele verifica sua tabela de sessão para verificar se o pacote pertence à sessão identificada pelo NPU2. Em seguida, aplica recursos baseados em pacotes configurados para a interface do NPU1 ao pacote. Ele processa pacotes (b->a) de acordo com os recursos de segurança e outros serviços que estão configurados para seu fluxo, com base em sua zona e políticas.
Passo 7. A SPU encaminha o pacote de tráfego reverso para a NPU.
Essa etapa é a mesma da Etapa 3, exceto que se aplica ao tráfego reverso. Veja a etapa 3 nesta seção para obter mais detalhes.
Example: SPU1 encaminha pacote (b->a) para NPU1. O NPU1 processa quaisquer telas configuradas para a interface.
8. A interface transmite o pacote do dispositivo.
Essa etapa é a mesma da Etapa 4, exceto que se aplica ao tráfego reverso. Veja a etapa 4 nesta seção para obter mais detalhes.
Exemplo: a interface transmite pacote (b->a) do dispositivo.
A Figura 7 ilustra o processo que um pacote passa quando chega ao dispositivo e existe uma sessão para o fluxo do qual o pacote pertence.
Entendendo as unidades de processamento de serviços
Para uma determinada interface física, a SPU recebe pacotes de entrada de todos os processadores de rede no pacote de processador de rede associados à interface física. A SPU extrai informações do pacote de processador de rede da interface física e usa o mesmo algoritmo de hash de 5 tuple para mapear um fluxo para um índice de processador de rede. Para determinar o processador de rede, a SPU faz uma busca no índice de processador de rede no pacote de processador de rede. A SPU envia pacotes de saída para o módulo de interface física local (PIM) para o tráfego externo.
O processador de rede e a SPU usam o mesmo algoritmo de hash de 5 tuple para obter os valores de hash para os pacotes.
Entender as características do agendador
Para dispositivos de SRX5400, SRX5600 e SRX5800, o IOC oferece suporte às seguintes características hierárquicas do agendador:
IFL – A configuração do pacote de processador de rede é armazenada na estrutura de dados da interface física. Por exemplo, dispositivos de SRX5400, SRX5600 e SRX5800 têm no máximo 48 PIMs. A interface física pode usar uma máscara de bit de 48 bits para indicar o PIM, ou o tráfego do processador de rede dessa interface física é distribuído, além do processador de rede principal da interface física.
Em dispositivos de linha SRX5000, a funcionalidade iflset não é suportada para interfaces agregadas como a reth.
IFD — A interface lógica associada à interface física de um pacote de processador de rede é passada para todos os IOCs que têm um PIM no pacote de processador de rede.
Entendendo o processador de rede Bundling
O recurso de agrupamento de processador de rede está disponível em dispositivos de linha SRX5000. Esse recurso permite a distribuição do tráfego de dados de uma interface a vários processadores de rede para processamento de pacotes. Um processador de rede primário é designado para uma interface que recebe o tráfego de entrada e distribui os pacotes para vários outros processadores de rede secundários. Um único processador de rede pode atuar como um processador de rede principal ou como um processador de rede secundário para várias interfaces. Um único processador de rede pode juntar-se a apenas um pacote de processador de rede.
Limitações do agrupamento do processador de rede
A funcionalidade de agrupamento de processador de rede tem as seguintes limitações:
O agrupamento de processador de rede permite um total de 16 PIMs por pacote e 8 sistemas diferentes de pacotes de processador de rede.
Você precisa reiniciar o dispositivo para aplicar as mudanças de configuração no pacote.
O agrupamento de processadores de rede está abaixo da interface de reth na arquitetura geral. Você pode escolher uma ou ambas as interfaces do pacote de processador de rede para formar a interface de reth.
Se o IOC for removido de um pacote de processador de rede, os pacotes encaminhados ao PIM nesse IOC serão perdidos.
Quando o pacote de processador de rede é habilitado, os limiares de inundação de sincronização de ICMP, UDP e TCP não se aplicam mais a uma interface. Os pacotes são distribuídos a vários processadores de rede para processamento. Esses limites se aplicam a cada processador de rede no pacote de processador de rede.
O agrupamento de processador de rede não é suportado no modo Camada 2.
Devido às restrições de memória no processador de rede, o número de portas empacotadas de processador de rede que são suportadas por PIM é limitado. Dentro do pacote de processador de rede, cada porta precisa ter um índice de porta global. O índice global de portas é calculado usando a seguinte fórmula:
Global_port_index = (global_pic * 16) + port_offset
Grupos de agregação de enlaces (LAGs) e LAGs redundantes de interface Ethernet em implementações de cluster de chassi podem coexistir com o agrupamento de processadores de rede. No entanto, nem LAGs nem LAGs redundantes de interface Ethernet podem se sobrepor ou compartilhar links físicos com um pacote de processador de rede.
Entendendo o Cache de sessão
- Visão geral
- Instalação seletiva de cache de sessão
- Aprimoramento da afinidade de sessão de VPN IPsec usando cache de sessão
- Pedido de pacote de fragmentação usando cache de sessão NP
Visão geral
O SRX5K-MPC (IOC2), SRX5K-MPC3-100G10G (IOC3) e SRX5K-MPC3-40G10G (IOC3) em SRX5400, SRX5600 e dispositivos SRX5800 suportam cache de sessão e instalação seletiva do cache de sessão.
O cache de sessão é usado para cache de uma conversa entre o processador de rede (NP) e a SPU em um IOC. Uma conversa pode ser uma sessão, tráfego de túnel GTP-U, tráfego de túneis IPsec VPN e assim por diante. Uma conversa tem duas entradas de cache de sessão, uma para tráfego de entrada e outra para tráfego reverso. Dependendo de onde estão as portas de entrada e saída de tráfego, duas entradas podem residir no mesmo processador de rede ou em diferentes processadores de rede. Os IOCs oferecem suporte ao cache de sessão para sessões IPv6.
Uma entrada de cache de sessão também é chamada de ala de sessão.
O cache de sessão no IOC aproveita a funcionalidade Express Path (anteriormente conhecida como descarregamento de serviços) e ajuda a evitar problemas como alta latência e queda no desempenho do IPsec.
Registros de entrada de cache de sessão:
Para qual SPU o tráfego da conversão deve ser encaminhado
Para a qual a saída porta o tráfego da conversão deve ser encaminhado no modo Express Path
O que o processamento a fazer para tráfego de saída, por exemplo, tradução de NAT no modo Express Path
Começando com o Junos OS Release 15.1X49-D10 e o Junos OS Release 17.3R1, o cache de sessão das sessões no IOC ajuda a resolver certos problemas de desempenho. A SPU agora pode instruir o cache de sessão do IOC a encaminhar o tráfego subsequente a uma SPU âncora específica.
A partir do Junos OS Release 15.1X49-D10, o SRX5K-MPC (IOC2) e o IOC3 oferecem suporte à afinidade de sessão de VPN por meio de um módulo de fluxo melhorado e cache de sessão. A partir do Junos OS Release 12.3X48-D30, no IOC2, a afinidade de sessão de VPN através do cache de sessão é suportada.
Outro tráfego foi hashed para SPUs com base em suas informações chave de 5 tuple. O tráfego de VPN empregava o conceito da SPU ancorada, que não necessariamente coincidia com as funções da SPU de fluxo. O processador de rede só poderia encaminhar os pacotes para a SPU de fluxo com base no hash de 5 tuples. A SPU de fluxo então encaminhou o pacote para a SPU ancorada. Isso criou um salto extra para o tráfego VPN, que desperdiçou a largura de banda da malha do switch e reduziu a taxa de transferência de VPN aproximadamente pela metade. Essa redução de desempenho ocorreu porque o tráfego ainda precisava voltar para a SPU de fluxo após o processamento na SPU ancorada.
A tabela de cache da sessão agora é estendida no IOC para oferecer suporte às sessões de NP. O tráfego express path e o tráfego NP compartilham a mesma tabela de cache de sessão em IOCs. O tráfego express path é encaminhado pelo próprio IOC localmente ou para outro IOC, porque o tráfego não requer nenhum serviço da SPU. O tráfego de NP é encaminhado para a SPU especificada no cache de sessão para processamento adicional. Todas as entradas de cache de sessão são compartilhadas pelo tráfego de sessão Express Path e pelo tráfego NP.
Para habilitar o cache de sessão nos IOCs, você precisa executar o set chassis fpc <fpc-slot> np-cache comando.
O IOC2 e o IOC3 utilizam o mecanismo de exclusão das sessões de atraso. As mesmas sessões (sessões com os mesmos cinco tuples) que são excluídas e depois reinstaladas imediatamente não são armazenadas em cache nos IOCs.
Instalação seletiva de cache de sessão
Para evitar alta latência, melhorar o desempenho do IPSec e utilizar melhor os recursos valiosos, certos mecanismos de prioridade são aplicados tanto ao módulo de fluxo quanto ao IOC.
Os IOCs mantêm e monitoram os níveis de limite de uso do cache de sessão. Os IOCs também comunicam o uso de cache de sessão à SPU, de modo que, quando um determinado limite de uso de cache de sessão é alcançado, a SPU apenas envia solicitações de instalação de cache de sessão para sessões de tráfego seletivas de alta prioridade.
Aplicativos como IDP, ALG precisam processar pacotes em ordem. Uma SPU tem vários threads de fluxo para lidar com pacotes que pertencem a uma sessão, rosca de balanceamento de carga (LBT) e ordem de pacotes de thread (POT) pode garantir que o tráfego passe pelo firewall em ordem, não pode garantir que o aplicativo processe pacotes que pertencem à mesma sessão em ordem. A serialização de fluxo fornece o método de que apenas um pacote de processamento de thread de fluxo de SPU pertence à mesma sessão de uma só vez, para que os aplicativos possam receber, processar e enviar pacotes em ordem. Outros tópicos de fluxo podem fazer processamento de serialização de fluxo para outras sessões ao mesmo tempo.
Os quatro níveis de prioridade a seguir são usados para determinar qual tipo de tráfego pode instalar cache de sessão nos IOCs:
Priority 1 (P1)— Tráfego qualificado de IPSec e Express Path
Priority 2 (P2)— Pedido de fragmentação
Priority 3 (P3)— tráfego de tráfego NAT/SZ (serialização de sessão)
Priority 4(P3)— Todos os outros tipos de tráfego
Os IOCs mantêm e monitoram os níveis limiares para o uso do cache de sessão e atualizam o uso atual de cache de sessão em tempo real para a SPU. A SPU solicita ao IOC que instale o cache de sessão para determinadas sessões de tráfego de alta prioridade. O uso de cache de sessão para sessões de tráfego de alta prioridade é definido na tabela:
Tipo de tráfego |
0% < utilização < 25% |
25% < utilização < 50% |
Utilização de 50% < < 75% |
Utilização de 75% < < 100% |
|---|---|---|---|---|
Tráfego IPsec e Express Path |
Sim |
Sim |
Sim |
Sim |
Fragmentação Ordenando tráfego |
Sim |
Sim |
Sim |
Não |
Tráfego NAT/SZ |
Sim |
Sim |
Não |
Não |
Outro tráfego |
Sim |
Não |
Não |
Não |
Para conservar as entradas de sessão no IOC, o módulo de fluxo instala sessões seletivamente no IOC. Para facilitar a seleção da instalação de sessão, o IOC mantém os limites correspondentes para fornecer uma indicação ao módulo de fluxo (sobre o quão completa é a tabela de cache da sessão nos IOCs). Dois bits no meta header são adicionados para indicar o status atual de utilização da tabela de cache. Todos os pacotes que vão para a SPU transportarão esses dois bits de status para informar o módulo de fluxo da utilização da tabela de cache no IOC.
Aprimoramento da afinidade de sessão de VPN IPsec usando cache de sessão
Os firewalls da Série SRX são sistemas totalmente distribuídos, e um túnel IPsec é alocado e ancorado em uma SPU específica. Todo o tráfego que pertence a um túnel IPsec é criptografado e descriptografado em sua SPU ancorada em túnel. Para obter um melhor desempenho IPsec, o IOC melhora o módulo de fluxo para criar sessões para o tráfego baseado em túnel IPsec (antes da criptografia e após a descriptografia) em sua SPU ancorada em túnel, e instala cache de sessão para as sessões para que o IOC possa redirecionar os pacotes diretamente para a mesma SPU para minimizar a sobrecarga de encaminhamento de pacotes. O tráfego express path e o tráfego NP compartilham a mesma tabela de cache de sessão em IOCs.
Você precisa habilitar o cache de sessão nos IOCs e definir a política de segurança para determinar se uma sessão é para o modo Express Path (anteriormente conhecido como descarregamento de serviços) no concentrador PIC flexível selecionado (FPC).
Para permitir o uso de afinidade vpn IPsec, o set security flow load-distribution session-affinity ipsec comando.
Para permitir a afinidade de VPN IPsec, você também deve habilitar o cache de sessão em IOCs usando o set chassis fpc <fpc-slot> np-cache comando.
Pedido de pacote de fragmentação usando cache de sessão NP
Uma sessão pode consistir em pacotes normais e fragmentados. Com distribuição baseada em hash, a chave de 5 tuple e 3 tuple pode ser usada para distribuir pacotes normais e fragmentados em diferentes SPUs, respectivamente. Nos firewalls da Série SRX, todos os pacotes da sessão são encaminhados para uma SPU de processamento. Devido à latência de encaminhamento e processamento, a SPU de processamento pode não garantir a ordenação de pacotes da sessão.
O cache de sessão nos IOCs garante o pedido de pacotes de uma sessão com pacotes fragmentados. Uma entrada de cache de sessão é alocada para pacotes normais da sessão e uma chave de 3 tuples é usada para encontrar os pacotes fragmentados. Ao receber o primeiro pacote fragmentado da sessão, o módulo de fluxo permite que o IOC atualize a entrada de cache de sessão para lembrar os pacotes fragmentados para a SPU. Posteriormente, o IOC encaminha todos os pacotes subsequentes da sessão para a SPU para garantir a ordenação de pacotes de uma sessão com pacotes fragmentados.
Configuração do mapeamento de IOC para NPC
Um mapeamento de placa de entrada/saída (IOC) para placa de processamento de rede (NPC) exige que você mapeie um IOC para um NPC. No entanto, você pode mapear vários IOCs para um único NPC. Para equilibrar o poder de processamento no NPC no SRX3400 e SRX3600 gateways de serviços, o processo de chassi (daemon) executa um algoritmo que realiza o mapeamento. Ele mapeia um IOC para um NPC que tem a menor quantidade de IOCs mapeados para ele. Você também pode usar a interface de linha de comando (CLI) para atribuir um IOC específico a um NPC específico. Quando você configura o mapeamento, o processo do chassi primeiro usará sua configuração e depois aplicará o algoritmo de NPC em menor número para o resto dos IOCs.
O suporte da plataforma depende da versão do Junos OS em sua instalação.
Para configurar o mapeamento ioc para NPC:
[edit]
set chassis ioc-npc-connectivity {
ioc slot-number npc (none | slot-number);
}
Consulte a Tabela 2 para obter uma descrição das set chassis ioc-npc-connectivity opções.
Opção |
Descrição |
|---|---|
coi slot-number |
Especifique o número de slot do IOC. O intervalo é de 0 a 7 para dispositivos SRX3400 e de 0 a 12 para dispositivos SRX3600. |
Npc slot-number |
Especifique o número de slot do NPC. O intervalo é de 0 a 7 para dispositivos SRX3400 e de 0 a 12 para dispositivos SRX3600 e SRX 4600. |
nenhum |
O processo do chassi mapeia a conexão para o IOC em particular. |
Você deve reiniciar o controle do chassi depois de confirmar o set chassis ioc-npc-connectivity comando.
Entendendo o processamento de fluxo em dispositivos SRX5K-SPC3
A placa de processamento de serviços SRX5K-SPC3 é introduzida para melhorar o desempenho dos serviços de segurança no gateway de serviços de segurança SRX5000. A placa SPC3 oferece suporte a uma taxa de transferência mais alta, mantém sua confiabilidade, preservando a funcionalidade de cluster do chassi e a escalabilidade para processamento de serviços.
A placa SPC3 oferece suporte para os seguintes recursos de segurança:
Gateway de camada de aplicativo (ALG). [Veja a visão geral da ALG]
Anti-malware avançado (Juniper ATP Cloud). [Veja o Juniper Sky Advanced Threat Prevention Administration]
Pacote de segurança de aplicativos. [Veja o guia do usuário de segurança de aplicativos para dispositivos de segurança]
Implementação de processamento de pacotes baseada em fluxo
Protocolo de tunelamento GPRS (GTP) e protocolo de transmissão de controle de fluxo (SCTP). [Veja o guia geral do usuário do serviço de rádio de pacotes para dispositivos de segurança]
Alta disponibilidade (cluster de chassi). [Veja o guia do usuário do cluster de chassis para dispositivos da Série SRX]
Detecção e prevenção de invasões (IDP). [Veja a visão geral da detecção e prevenção de invasões]
Tradução de endereços de rede (NAT). [Veja o guia de usuário de tradução de endereços de rede para dispositivos de segurança]
Firewall stateful
Proxy SSL. [Veja proxy SSL]
Autenticação do usuário do firewall. [Veja o guia de usuários de autenticação e firewalls de usuário integrados para dispositivos de segurança]
Segurança de conteúdo (antivírus, filtragem de web, filtragem de conteúdo e antispam). [Veja o guia do usuário da UTM para dispositivos de segurança]
O fluxo de segurança é aprimorado para oferecer suporte à placa SPC3 com todos os recursos de segurança existentes que são suportados na placa SPC2.
As seguintes limitações se aplicam à placa SPC3 no Junos OS Release 18.2R1-S1:
A interoperabilidade da placa SPC3 e da placa SPC2 não é suportada.
A funcionalidade VPN IPsec não é suportada com a placa SPC3.
A partir do Junos OS Release 18.2R1-S1, uma nova placa de processamento de serviços (SPC3) é introduzida para os dispositivos de linha SRX5000. A introdução da nova placa melhora a escalabilidade e o desempenho do dispositivo e mantém sua confiabilidade à medida que preserva a funcionalidade do cluster do chassi. A placa SPC3 oferece suporte a uma taxa de transferência e escalabilidade mais altas para o processamento de serviços.
Em SRX5000 dispositivos de linha, a placa SPC3 interopera com placas de E/S (IOC2, IOC3), Switch Control Board (SCB2, SCB3), Mecanismos de roteamento e placas SPC2.
A partir do Junos OS Release 18.4R1, uma mistura de placas SPC3 e SPC2 é suportada em dispositivos de linha SRX5000.
Se você estiver adicionando as placas SPC3 em SRX5000 linha de dispositivos, a nova placa SPC3 deve ser instalada no slot de menor número de qualquer SPC. A placa SPC3 está instalada no slot original com a menor numeração oferece a funcionalidade do ponto central (CP) no modo misto. Por exemplo, se o gateway de serviços contém um mix de placas SPC2 e SPC3, um SPC3 deve ocupar o slot com a menor numeração de qualquer SPC no chassi. Essa configuração garante que a funcionalidade do ponto central (CP) no modo misto seja executada pela placa SPC3.
Em SRX5000 dispositivos de linha que operam no modo misto, o processamento de fluxo é compartilhado entre as placas SPC3 e SPC2. O processamento de ponto central ocorre no slot SPC de número mais baixo para o qual uma placa SPC3 é instalada.
Quando os firewalls da Série SRX estão operando em um modo de cluster de chassi, as placas SPC3 e SPC2 devem ser instaladas nos mesmos locais de slot em cada chassi.
- Entendendo a arquitetura de software do SPC3
- Entendendo a distribuição de carga
- Entendendo o NP Session and Service Offload (SOF)
- Entendendo o suporte do J-Flow no SPC3
- Entendendo o suporte para SPU de debug de datapath (E2E)
- Entendendo o tratamento de fragmentação, o ISSU e o suporte ao ISHU
Entendendo a arquitetura de software do SPC3
A arquitetura de fluxo SPC3 é a mesma da arquitetura CP-Lite. O SPC3 possui fisicamente duas unidades de processamento de serviços (SPU) e cada SPU tem duas CPUs.
Ao instalar um ou dois SPC3s, o processamento de tráfego utiliza 75% do primeiro SPC. Quando você instala três ou mais SPC3s, o processamento de tráfego utiliza 50% do primeiro SPC.
A forma como o IOC temhes os pacotes para processar o fluxo é alterada. A figura mostra o fluxo de pacotes do firewall da Série SRX com o SPC3.
No SPC3, os pacotes são distribuídos diretamente do IOC para cada núcleo. Como o IOC temhes pacotes diretamente na rosca RT fluída, a rosca LBT original é removida. Os pacotes agora são entregues na rosca fluída em vez de SPU. Se o fluxo de segurança instalar sessões de NP, em vez de ID de SPU, o ID de thread de sessão é usado pelo IOC para encaminhar pacotes para corrigir thread associate com a sessão.
fluído
Entendendo a distribuição de carga
Todos os pacotes que passarem por uma porta de receita serão distribuídos para diferentes SPUs com base no algoritmo de hash, que é o mesmo que o hash existente dos dispositivos SRX5000 Line baseado na arquitetura CP-Lite. O método de hash varia para diferentes tipos de tráfego. A tabela abaixo lista métodos de hash.
Protocolo |
Portas |
Método hash |
|
|---|---|---|---|
TCP
|
Porta de src L4 e porta dst |
Hashed por 5-tuple |
|
UDP |
Normal |
Porta de src L4 e porta dst |
Hashed por 5-tuple |
GTP |
Porta de src L4 e porta dst |
Hashed por 5-tuple |
|
IKE |
Porta de src L4 e porta dst
|
Hashed by IP pair |
|
ICMP |
|
As informações do ICMP são hashed por 5-tuple; Erro de ICMP é a hashed por 3-tuple (sem informações de portas) |
|
SCTP |
Porta de src L4 e porta dst |
Hashed por 5-tuple |
|
ESP |
SPI |
Hashed by IP pair |
|
AH |
SPI |
Hashed by IP pair |
|
GRE |
Se o alg PPTP estiver habilitado, sport = id de chamada; dport = 0 Por padrão, a porta é 0x00010001 |
Hashed por 3-tuple |
|
PIM |
Por padrão, as portas PIM 0x00010001 |
Hashed por 3-tuple |
|
FRAGMENTO |
Primeiro fragmento, tem as portas normais Nenhum primeiro fragmento, nenhuma porta |
Hashed por 3-tuple |
|
Outro pacote IP |
Portas 0x00010001 |
Hashed por 3-tuple |
|
NENHUM IP |
Não aplicável |
Hashed by Mac address and Ethernet Type (Vlan ID) |
|
Entendendo o NP Session and Service Offload (SOF)
A sessão de processador de rede (NP) é uma sessão baseada em IOC que permite e estabelece as sessões de SPU. Os pacotes que passam na sessão de NP tem as seguintes vantagens:
Evita a busca por sessão na SPU para obter um melhor desempenho.
Evita o encaminhamento extra de pacotes entre a SPU de sessão e a SPU de hash.
O descarregamento de serviços é um tipo especial de sessão de NP para fornecer um recurso de baixa latência para sessão que precisa de serviços básicos de firewall. Pacotes que atingem a sessão SOF em um IOC ignoram o processamento de pacotes na SPU e são encaminhados diretamente pelo IOC. Os seguintes tipos de tráfego suportam o descarregamento de serviços:
Firewall básico (sem plug-in e fragmentos), IPv4 e IPv6 TCP, tráfego UDP
IPv4 NAT
1Fan-in e 1Fan-out Multicast
ALGs como sessão de dados ftp
Entendendo o suporte do J-Flow no SPC3
J-Flow é a versão juniper do mecanismo padrão de monitoramento de tráfego do setor. Ele fornece um recurso para exportar instantâneo das estatísticas de tráfego de rede para o servidor remoto para monitoramento da rede e processamento adicional de dados. O J-Flow oferece suporte ao formato v5, v8 e v9. Todas essas três versões são suportadas no SPC3.
Entendendo o suporte para SPU de debug de datapath (E2E)
A depuração de datapath oferece recurso de depuração de pacotes baseado em filtro de ponta a ponta (E2E) em dispositivos SRX5000 Line. Ele rastreia o caminho dos pacotes e despejo de conteúdo de pacotes.
No SPC3, o JEXEC é o único tipo de evento E2E que é suportado e os seguintes tipos de ação E2E são suportados:
Contar
Despejar
Traço
Trace-summary
Entendendo o tratamento de fragmentação, o ISSU e o suporte ao ISHU
No SPC3, os pacotes fragmentados são encaminhados para "núcleo de fragmento" em um PFE específico com base em seus valores de tuple de cabeçalho. Após receber um pacote fragmentado, o fluxo realiza a desfragmentação e encaminha o pacote para seu núcleo de sessão. A lógica de fluxo não muda e permanece a mesma.
Ao realizar o ISSU, as SPUs virtuais são sincronizadas com IDs de SPU virtuais relacionados. O suporte ao ISHU é baseado na arquitetura CP-Lite. Basicamente, duas operações de ISHU são apoiadas:
Insira um novo SPC ao nó secundário.
Substitua um SPC em nó secundário, e o número de SPCs deve ser o mesmo do nó primário.
Tabela de histórico de mudanças
O suporte de recursos é determinado pela plataforma e versão que você está usando. Use o Feature Explorer para determinar se um recurso é suportado em sua plataforma.