Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Interfaces de malha de cluster de chassi

Os dispositivos da Série SRX em um cluster de chassi usam a interface de malha (fab) para sincronização de sessão e encaminhamento de tráfego entre os dois chassis. O link de malha é uma conexão física entre duas interfaces Ethernet na mesma LAN. Ambas as interfaces devem ser do mesmo tipo de mídia. Para obter mais informações, veja os seguintes tópicos:

Entender as interfaces de malha de cluster de chassi

A malha é uma conexão física entre dois nós de um cluster e é formada pela conexão de um par de interfaces Ethernet de volta para trás (um de cada nó).

Ao contrário do link de controle, cujas interfaces são determinadas pelo sistema, você especifica as interfaces físicas a serem usadas para o link de dados da malha na configuração.

A malha é a ligação de dados entre os nós e é usada para encaminhar tráfego entre o chassi. O tráfego que chega em um nó que precisa ser processado do outro é encaminhado pelo link de dados da malha. Da mesma forma, o tráfego processado em um nó que precisa sair por meio de uma interface no outro nó é encaminhado sobre a malha.

O link de dados é referido como a interface de malha. Ele é usado pelos mecanismos de encaminhamento de pacotes do cluster para transmitir tráfego de trânsito e sincronizar o estado dinâmico de tempo de execução do software de plano de dados. A malha oferece a sincronização de objetos de estado de sessão criados por operações como autenticação, tradução de endereços de rede (NAT), gateways de camada de aplicativos (ALGs) e sessões de segurança IP (IPsec).

Quando o sistema cria a interface de malha, o software atribui a ele um endereço IP derivado internamente para ser usado para transmissão de pacotes.

CUIDADO:

Depois que as interfaces de malha tiverem sido configuradas em um cluster de chassi, a remoção da configuração da malha em ambos os nós fará com que o nó secundário do grupo 0 (RG0) de redundância se mova para um estado desativado. (Redefinir um dispositivo na configuração padrão de fábrica remove a configuração da malha e, com isso, faz com que o nó secundário RG0 se mova para um estado desativado.) Após o compromisso da configuração da malha, não redefinir nenhum dos dispositivos para a configuração padrão da fábrica.

Tipos de interface de malha suportados para firewalls da Série SRX (série SRX300, SRX1500, SRX1600, SRX4100/SRX4200, SRX4600 e linha de SRX5000)

Para clusters de chassi da Série SRX, o link de malha pode ser qualquer par de interfaces Ethernet que abrangem o cluster; o link de malha pode ser qualquer par de interface Gigabit Ethernet. Exemplos:

  • Para dispositivos SRX300, SRX320, SRX340 e SRX345, o link de malha pode ser qualquer par de interfaces Gigabit Ethernet. Para dispositivos SRX380, o link de malha pode ser qualquer par de interfaces Gigabit Ethernet ou qualquer par de interface Ethernet de 10 Gigabits.

  • Para SRX1500 e SRX1600, o link de malha pode ser qualquer par de interfaces Ethernet que abrangem o cluster; o link de malha pode ser qualquer par de interface Gigabit Ethernet ou qualquer par de interface Ethernet de 10 Gigabits. Para SRX1600, o link de malha também pode ser qualquer par de interface Ethernet de 25 Gigabits.

  • Os tipos de interface de malha suportados para dispositivos de SRX4100 e SRX4200 são ethernet de 10 Gigabits (xe) (slots SFP+ de interface Ethernet de 10 Gigabits).

  • Os tipos de interface de malha suportados para dispositivos SRX4600 são ethernet de 40 Gigabit (et) (slots QSFP de interface Ethernet de 40 Gigabit) e Ethernet de 10 Gigabits (xe).

  • Os tipos de interface de malha suportados para dispositivos de linha SRX5000 são:

    • Ethernet rápida

    • Gigabit Ethernet

    • Ethernet de 10 Gigabits

    • Ethernet de 40 Gigabits

    • Ethernet de 100 Gigabits

      A partir do Junos OS Release 12.1X46-D10 e Junos OS Release 17.3R1, a interface Ethernet de 100 Gigabits é suportada em dispositivos de linha SRX5000.

      A partir do Junos OS Release 19.3R1, o SRX5K-IOC4-10G e o SRX5K-IOC4-MRAT contam com o suporte do SRX5K-SPC3 nos dispositivos de linha SRX5000. O SRX5K-IOC4-10G MPIC oferece suporte ao MACsec.

Para obter mais informações sobre o uso de portas e interfaces para links de gerenciamento, controle e malha, veja Entendendo a numeração de slots de cluster de chassi da Série SRX e a nomeação de portas físicas e interface lógica.

Suporte para estruturas jumbo

O link de dados da malha não oferece suporte à fragmentação. Para acomodar este estado, o suporte a quadros jumbo é habilitado por padrão no link com uma unidade de transmissão máxima (MTU) do tamanho de 9014 bytes (9000 bytes de carga + 14 bytes para o cabeçalho Ethernet) em firewalls da Série SRX. Para garantir que o tráfego que transita pelo link de dados não exceda esse tamanho, recomendamos que nenhuma outra interface exceda o tamanho mtu do link de dados da malha.

Entendendo as interfaces de malha em dispositivos de linha de SRX5000 para IOC2 e IOC3

A partir do Junos OS Release 15.1X49-D10, são introduzidos o SRX5K-MPC3-100G10G (IOC3) e o SRX5K-MPC3-40G10G (IOC3).

O SRX5K-MPC (IOC2) é um concentrador modular de portas (MPC) que é suportado nas SRX5400, SRX5600 e SRX5800. Essa placa de interface aceita placas de interface modulares (MICs), que adicionam portas Ethernet ao seu gateway de serviços para fornecer conexões físicas a vários tipos de mídia de rede. Os MPCs e MICs oferecem suporte a links de malha para clusters de chassi. O SRX5K-MPC oferece Ethernet de 10 Gigabits (com 10x10GE MIC), Ethernet de 40 Gigabit, Ethernet de 100 Gigabit e portas Ethernet 20x1GE como portas de malha. Em SRX5400 dispositivos, apenas o SRX5K-MPCs (IOC2) é compatível.

O SRX5K-MPC3-100G10G (IOC3) e o SRX5K-MPC3-40G10G (IOC3) são concentradores modulares de portas (MPCs) que são suportados no SRX5400, SRX5600 e SRX5800. Essas placas de interface aceitam placas de interface modulares (MICs), que adicionam portas Ethernet ao seu gateway de serviços para fornecer conexões físicas a vários tipos de mídia de rede. Os MPCs e MICs oferecem suporte a links de malha para clusters de chassi.

Os dois tipos de Concentradores modulares de portas (MPCs) do IOC3, que têm MICs integrados diferentes, são o 24x10GE + 6x40GE MPC e o 2x100GE + 4x10GE MPC.

Devido a restrições de energia e térmicas, todos os quatro PICs no 24x10GE + 6x40GE não podem ser ligados. No máximo dois PICs podem ser ligados ao mesmo tempo.

Use o set chassis fpc <slot> pic <pic> power off comando para escolher os PICs que você deseja alimentar.

Em SRX5400, SRX5600 e dispositivos SRX5800 em um cluster de chassi, quando os PICs que contêm links de malha no SRX5K-MPC3-40G10G (IOC3) são alimentados para ativar PICs alternativos, certifique-se sempre de que:

  • Os novos links de malha estão configurados nos novos PICs que são ativados. Pelo menos um link de malha deve estar presente e on-line para garantir uma perda mínima de RTO.

  • O cluster do chassi está no modo ativo passivo para garantir uma perda mínima de RTO, uma vez que os links alternativos são colocados on-line.

  • Se nenhum enlace de malha alternativo estiver configurado nos PICs ativados, a comunicação síncrona de RTO entre os dois nós para e o estado de sessão de cluster do chassi não será novamente ativada, porque o link da malha está faltando. Você pode visualizar a saída CLI para este cenário indicando um estado de cluster de chassi ruim usando o show chassis cluster interfaces comando.

Entendendo os RTOs de sessão

O software de plano de dados, que opera no modo ativo/ativo, gerencia o processamento de fluxo e a redundância do estado de sessão e processa o tráfego de trânsito. Todos os pacotes pertencentes a uma sessão específica são processados no mesmo nó para garantir que o mesmo tratamento de segurança seja aplicado a eles. O sistema identifica o nó em que uma sessão está ativa e encaminha seus pacotes para esse nó para processamento. (Depois que um pacote é processado, o Mecanismo de encaminhamento de pacotes transmite o pacote para o nó no qual sua interface de saída existe se esse nó não for o local.)

Para fornecer redundância de sessão (ou fluxo), o software do plano de dados sincroniza seu estado enviando pacotes especiais de carga chamados objetos de tempo de execução (RTOs) de um nó para o outro através do link de dados da malha. Ao transmitir informações sobre uma sessão entre os nós, os RTOs garantem a consistência e a estabilidade das sessões se um failover ocorrer e, assim, permitem que o sistema continue processando o tráfego pertencente às sessões existentes. Para garantir que as informações da sessão sejam sempre sincronizadas entre os dois nós, o software do plano de dados dá aos RTOs prioridade de transmissão sobre o tráfego de trânsito.

O software de plano de dados cria RTOs para sessões de UDP e TCP e rastreia mudanças de estado. Ele também sincroniza o tráfego para protocolos de passagem IPv4, como o Generic Routing Encapsulation (GRE) e o IPsec.

Os RTOs para sincronização de uma sessão incluem:

  • RTOs de criação de sessão no primeiro pacote

  • Exclusão de sessão e RTOs com envelhecimento

  • RTOs relacionados a mudanças, incluindo:

    • Mudanças de estado do TCP

    • Solicitação de sincronização de tempo limite e mensagens de resposta

    • RTOs para criar e excluir aberturas temporárias no firewall (pinholes) e pinholes de sessão infantil

Entendendo o encaminhamento de dados

Para o Junos OS, o processamento de fluxo ocorre em um único nó no qual a sessão para esse fluxo foi estabelecida e está ativa. Essa abordagem garante que as mesmas medidas de segurança sejam aplicadas a todos os pacotes pertencentes a uma sessão.

Um cluster de chassi pode receber tráfego em uma interface em um nó e enviar para uma interface no outro nó. (No modo ativo/ativo, a interface de entrada para tráfego pode existir em um nó e sua interface de saída do outro.)

Essa travessia é necessária nas seguintes situações:

  • Quando os pacotes são processados em um nó, mas precisam ser encaminhados para fora uma interface de saída no outro nó

  • Quando os pacotes chegam em uma interface em um nó, mas devem ser processados no outro nó

    Se as interfaces de entrada e saída para um pacote estiverem em um nó, mas o pacote deve ser processado no outro nó porque sua sessão foi estabelecida lá, ele deve atravessar o link de dados duas vezes. Esse pode ser o caso de algumas sessões de mídia complexas, como sessões de voz sobre IP (VoIP).

Entendendo a falha e a recuperação do enlace de dados da malha

Os serviços de detecção e prevenção de invasões (IDP) não suportam failover. Por esse motivo, os serviços de IDP não são aplicados às sessões que estavam presentes antes do failover. Os serviços de IDP são aplicados para novas sessões criadas no novo nó primário.

O link de dados da malha é vital para o cluster do chassi. Se o link estiver indisponível, o encaminhamento de tráfego e a sincronização de RTO serão afetados, o que pode resultar em perda de tráfego e comportamento imprevisível do sistema.

Para eliminar essa possibilidade, o Junos OS usa o monitoramento de malha para verificar se o enlace da malha, ou os dois links de malha no caso de uma configuração de enlace de malha dupla, estão vivos transmitindo sondas periodicamente pelos links da malha. Se o Junos OS detectar falhas na malha, o status RG1+ do nó secundário muda para inelegibilidade. Ele determina que ocorreu uma falha na malha se uma sonda de malha não for recebida, mas a interface de malha estiver ativa. Para se recuperar desse estado, ambos os links de malha precisam voltar ao estado on-line e devem começar a trocar sondas. Assim que isso acontecer, todos os FPCs no nó anteriormente iniligível serão reiniciados. Em seguida, eles chegam ao estado on-line e reencontram o cluster.

Se você fizer alguma alteração na configuração enquanto o nó secundário estiver desativado, execute o commit comando para sincronizar a configuração após reiniciar o nó. Se você não fez alterações na configuração, o arquivo de configuração permanece sincronizado com o do nó principal.

Começando pelo Junos OS Release 12.1X47-D10 e Junos OS Release 17.3R1, o recurso de monitoramento da malha é habilitado por padrão em dispositivos de SRX5800, SRX5600 e SRX5400.

Começando pelo Junos OS Release 12.1X47-D10 e Junos OS Release 17.3R1, a recuperação do enlace e sincronização da malha ocorre automaticamente.

Quando os nós primários e secundários são saudáveis (ou seja, não há falhas) e o enlace da malha cai, o(s) grupo(s) de redundância(s) RG1+ no nó secundário fica iniligível. Quando um dos nós não é saudável (ou seja, há uma falha), o(s) grupo(s) de redundância RG1+ neste nó (seja o nó primário ou secundário) torna-se inelegibilidade. Quando ambos os nós não são saudáveis e o enlace da malha cai, o(s) grupo(s) de redundância(s) RG1+ no nó secundário torna-se iniligível. Quando o link da malha surge, o nó no qual o RG1+ se tornou iniligível realiza uma sincronização fria em todas as Unidades de processamento de serviços e faz a transição para o standby ativo.

  • Se o RG0 for primário em um nó não saudável, então o RG0 falhará de um nó não saudável para um nó saudável. Por exemplo, se o nó 0 for primário para RG0+ e o nó 0 se tornar insalubridade, então o RG1+ no nó 0 fará a transição para inelegibilidade após 66 segundos de uma falha no enlace da malha e o RG0+ falha no nó 1, que é o nó saudável.

  • Apenas o RG1+ passa para um estado iniligível. O RG0 continua a ser em um estado primário ou secundário.

Use o show chassis cluster interfaces comando CLI para verificar o status do link da malha.

Exemplo: Configuração das interfaces de malha de cluster do chassi

Este exemplo mostra como configurar a malha de cluster do chassi. A malha é a conexão de dados de volta para trás entre os nós em um cluster. O tráfego em um nó que precisa ser processado no outro nó ou para sair por uma interface no outro nó passa por cima da malha. As informações de estado da sessão também passam pela malha.

Requisitos

Antes de começar, configure a ID do cluster do chassi e o ID do nó de cluster do chassi. Veja exemplo: definir o ID do nó e o ID de cluster para dispositivos de segurança em um cluster de chassi .

Visão geral

Na maioria dos firewalls da Série SRX em um cluster de chassi, você pode configurar qualquer par de interfaces Ethernet Gigabit ou qualquer par de interfaces de 10 Gigabit para servir como a malha entre nós.

Você não pode configurar filtros, políticas ou serviços na interface da malha. A fragmentação não é suportada no enlace da malha. O tamanho máximo de MTU para interfaces de malha é de 9014 bytes e o tamanho máximo de MTU para outras interfaces é de 8900 bytes. O suporte de estrutura jumbo nos links de membros é habilitado por padrão.

Este exemplo ilustra como configurar o link da malha.

Apenas o mesmo tipo de interfaces pode ser configurada como crianças de malha, e você deve configurar um número igual de links infantis para fab0 e fab1.

Se você estiver conectando cada um dos links de malha através de um switch, você deve habilitar o recurso de quadro jumbo nas portas de switch correspondentes. Se ambos os links de malha estiverem conectados pelo mesmo switch, o par RTO-and-probes deve estar em uma LAN virtual (VLAN) e o par de dados deve estar em outra VLAN. Aqui também, o recurso de estrutura jumbo deve ser habilitado nas portas de switch correspondentes.

Configuração

Procedimento

Configuração rápida da CLI

Para configurar rapidamente este exemplo, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere todos os detalhes necessários para combinar com a configuração da sua rede, copiar e colar os comandos na CLI no nível de [edit] hierarquia e, em seguida, entrar no commit modo de configuração.

Procedimento passo a passo

Para configurar a malha de cluster do chassi:

  • Especifique as interfaces de malha.

Resultados

A partir do modo de configuração, confirme sua configuração entrando no show interfaces comando. Se a saída não exibir a configuração pretendida, repita as instruções de configuração neste exemplo para corrigi-la.

Para a brevidade, essa show saída de comando inclui apenas a configuração que é relevante para este exemplo. Qualquer outra configuração no sistema foi substituída por elipses (...).

Se você terminar de configurar o dispositivo, entre no commit modo de configuração.

Verificação

Verificando a malha de cluster do chassi

Propósito

Verifique a malha de cluster do chassi.

Ação

A partir do modo operacional, entre no show interfaces terse | match fab comando.

Verificação de interfaces de plano de dados de cluster de chassi

Propósito

Exibir o status da interface do plano de dados do cluster de chassis.

Ação

A partir da CLI, entre no show chassis cluster data-plane interfaces comando:

Estatísticas do plano de dados do cluster de chassi

Propósito

Exibir estatísticas do plano de dados do cluster de chassi.

Ação

A partir da CLI, entre no show chassis cluster data-plane statistics comando:

Estatísticas do plano de dados do cluster de chassis

Para limpar as estatísticas do plano de dados de cluster de chassi exibido, insira o clear chassis cluster data-plane statistics comando da CLI:

Tabela de histórico de lançamentos
Lançamento
Descrição
19.3R1
A partir do Junos OS Release 19.3R1, o SRX5K-IOC4-10G e o SRX5K-IOC4-MRAT contam com o suporte do SRX5K-SPC3 nos dispositivos de linha SRX5000. O SRX5K-IOC4-10G MPIC oferece suporte ao MACsec.
15,1X49-D10
A partir do Junos OS Release 15.1X49-D10, são introduzidos o SRX5K-MPC3-100G10G (IOC3) e o SRX5K-MPC3-40G10G (IOC3).
12.1X47
Começando pelo Junos OS Release 12.1X47-D10 e Junos OS Release 17.3R1, o recurso de monitoramento da malha é habilitado por padrão em dispositivos de SRX5800, SRX5600 e SRX5400.
12.1X47
Começando pelo Junos OS Release 12.1X47-D10 e Junos OS Release 17.3R1, a recuperação do enlace e sincronização da malha ocorre automaticamente.
12.1X46
A partir do Junos OS Release 12.1X46-D10 e Junos OS Release 17.3R1, a interface Ethernet de 100 Gigabits é suportada em dispositivos de linha SRX5000.