Resolução de problemas de dispositivos de segurança
Resolução de problemas de resolução de nomes de DNS em políticas lógicas de segurança do sistema (apenas administradores primários)
Problema
Descrição
O endereço de um nome de host em uma entrada de livro de endereços usada em uma política de segurança pode não ser resolvido corretamente.
Causa
Normalmente, as entradas de agenda de endereços que contêm nomes de host dinâmicos são atualizadas automaticamente para firewalls da Série SRX. O campo TTL associado a uma entrada de DNS indica o tempo após o qual a entrada deve ser atualizada no cache de políticas. Assim que o valor da TTL expirar, o firewall da Série SRX atualiza automaticamente a entrada de DNS para uma entrada na lista de endereços.
No entanto, se o firewall da Série SRX não conseguir obter uma resposta do servidor DNS (por exemplo, a solicitação de DNS ou o pacote de resposta são perdidos na rede ou o servidor DNS não puder enviar uma resposta), o endereço de um nome de host em uma entrada de livro de endereços pode não ser resolvido corretamente. Isso pode fazer com que o tráfego caia, pois nenhuma política de segurança ou correspondência de sessão é encontrada.
Solução
O administrador principal pode usar o show security dns-cache comando para exibir informações de cache DNS no firewall da Série SRX. Se as informações de cache DNS precisarem ser atualizadas, o administrador primário pode usar o clear security dns-cache comando.
Esses comandos só estão disponíveis para o administrador principal em dispositivos configurados para sistemas lógicos. Esse comando não está disponível em sistemas lógicos do usuário ou em dispositivos que não estão configurados para sistemas lógicos.
Consulte também
Resolução de problemas da interface de serviços de enlace
Para resolver problemas de configuração em uma interface de serviços de enlace:
- Determinar quais componentes cos são aplicados aos links constituintes
- Determinar o que causa jitter e latência no pacote multilink
- Determine se o balanceamento de carga e LFI está funcionando corretamente
- Determine por que os pacotes são descartados em um PVC entre um dispositivo da Juniper Networks e um dispositivo de terceiros
Determinar quais componentes cos são aplicados aos links constituintes
Problema
Descrição
Você está configurando um pacote multilink, mas também tem tráfego sem encapsulamento MLPPP passando por links constituintes do pacote multilink. Você aplica todos os componentes de CoS nos links constituintes ou está aplicando-os ao pacote multilink o suficiente?
Solução
Você pode aplicar um mapa de agendador ao pacote multilink e seus links constituintes. Embora você possa aplicar vários componentes de CoS com o mapa do agendador, configure apenas os que são necessários. Recomendamos que você mantenha a configuração nos links constituintes simples para evitar atrasos desnecessários na transmissão.
Tabela 1 mostra os componentes cos a serem aplicados em um pacote multilink e seus links constituintes.
Componente Cos |
Pacote multilink |
Links constituintes |
Explicação |
|---|---|---|---|
Classificador |
Sim |
Não |
A classificação cos ocorre no lado de entrada da interface, não no lado transmissor, portanto, não são necessários classificadores em links constituintes. |
Aula de encaminhamento |
Sim |
Não |
A aula de encaminhamento está associada a uma fila, e a fila é aplicada na interface por um mapa do agendador. A atribuição da fila é predeterminada nos links constituintes. Todos os pacotes do 2º trimestre do pacote multilink são atribuídos ao 2º trimestre do link constituinte, e os pacotes de todas as outras filas estão enfileirados no Q0 do link constituinte. |
Mapa do agendador |
Sim |
Sim |
Aplique mapas de agendador no pacote multilink e no link constituinte da seguinte forma:
|
Taxa de modelagem para um agendador por unidade ou um agendador de nível de interface |
Não |
Sim |
Como o agendamento por unidade é aplicado apenas no ponto final, aplique essa taxa de modelagem apenas nos links constituintes. Qualquer configuração aplicada anteriormente é sobreescrita pela configuração do link constituinte. |
Modelagem exata ou de nível de fila de taxa de transmissão |
Sim |
Não |
A modelagem de nível de interface aplicada nos links constituintes substitui qualquer modelagem na fila. Assim, aplique a modelagem exata da taxa de transmissão apenas no pacote multilink. |
Regras de reescrita |
Sim |
Não |
Os bits de reescrita são copiados do pacote para os fragmentos automaticamente durante a fragmentação. Assim, o que você configura no pacote multilink é transportado nos fragmentos para os links constituintes. |
Grupo de canais virtuais |
Sim |
Não |
Grupos de canais virtuais são identificados por meio de regras de filtro de firewall que são aplicadas em pacotes apenas antes do pacote multilink. Assim, você não precisa aplicar a configuração do grupo de canais virtuais aos links constituintes. |
Consulte também
Determinar o que causa jitter e latência no pacote multilink
Problema
Descrição
Para testar o jitter e a latência, você envia três fluxos de pacotes IP. Todos os pacotes têm as mesmas configurações de precedência de IP. Após a configuração de LFI e CRTP, a latência aumentou mesmo em um enlace não mais limitado. Como você pode reduzir o jitter e a latência?
Solução
Para reduzir o jitter e a latência, faça o seguinte:
Certifique-se de ter configurado uma taxa de modelagem em cada link constituinte.
Certifique-se de não ter configurado uma taxa de modelagem na interface de serviços de link.
Certifique-se de que o valor da taxa de modelagem configurada seja igual à largura de banda da interface física.
Se as taxas de modelagem estiverem configuradas corretamente e o jitter ainda persistir, entre em contato com o Centro de Assistência Técnica (JTAC) da Juniper Networks.
Determine se o balanceamento de carga e LFI está funcionando corretamente
Problema
Descrição
Neste caso, você tem uma única rede que oferece suporte a vários serviços. A rede transmite dados e tráfego de voz sensível ao atraso. Após a configuração do MLPPP e do LFI, certifique-se de que os pacotes de voz sejam transmitidos por toda a rede com muito pouco atraso e jitter. Como você pode descobrir se os pacotes de voz estão sendo tratados como pacotes LFI e balanceamento de carga é executado corretamente?
Solução
Quando o LFI é habilitado, os pacotes de dados (não LFI) são encapsulados com um cabeçalho MLPPP e fragmentados em pacotes de um tamanho especificado. Os pacotes de voz (LFI) sensíveis ao atraso são encapsulados por PPP e intercalados entre fragmentos de pacote de dados. A fila e o balanceamento de carga são executados de forma diferente para pacotes LFI e não LFI.
Para verificar se o LFI é executado corretamente, determine que os pacotes estão fragmentados e encapsulados conforme configurados. Depois de saber se um pacote é tratado como um pacote LFI ou um pacote não LFI, você pode confirmar se o balanceamento de carga é executado corretamente.
Solution Scenario— Suponha que dois dispositivos da Juniper Networks, R0 e R1, estejam conectados por um pacote lsq-0/0/0.0 multilink que agrega dois links se-1/0/0 serial e se-1/0/1. No R0 e R1, MLPPP e LFI estão habilitados na interface de serviços de link e o limite de fragmentação é definido para 128 bytes.
Neste exemplo, usamos um gerador de pacotes para gerar fluxos de voz e dados. Você pode usar o recurso de captura de pacotes para capturar e analisar os pacotes na interface de entrada.
Os dois fluxos de dados a seguir foram enviados no pacote multilink:
100 pacotes de dados de 200 bytes (maior que o limiar de fragmentação)
500 pacotes de dados de 60 bytes (menor que o limiar de fragmentação)
Os dois fluxos de voz a seguir foram enviados no pacote multilink:
100 pacotes de voz de 200 bytes da porta de origem 100
300 pacotes de voz de 200 bytes da porta de origem 200
Para confirmar que o LFI e o balanceamento de carga são executados corretamente:
Apenas as partes significativas da saída de comando são exibidas e descritas neste exemplo.
Verifique a fragmentação de pacotes. Desde o modo operacional, entre no
show interfaces lsq-0/0/0comando para verificar se pacotes grandes são fragmentados corretamente.user@R0#> show interfaces lsq-0/0/0 Physical interface: lsq-0/0/0, Enabled, Physical link is Up Interface index: 136, SNMP ifIndex: 29 Link-level type: LinkService, MTU: 1504 Device flags : Present Running Interface flags: Point-To-Point SNMP-Traps Last flapped : 2006-08-01 10:45:13 PDT (2w0d 06:06 ago) Input rate : 0 bps (0 pps) Output rate : 0 bps (0 pps) Logical interface lsq-0/0/0.0 (Index 69) (SNMP ifIndex 42) Flags: Point-To-Point SNMP-Traps 0x4000 Encapsulation: Multilink-PPP Bandwidth: 16mbps Statistics Frames fps Bytes bps Bundle: Fragments: Input : 0 0 0 0 Output: 1100 0 118800 0 Packets: Input : 0 0 0 0 Output: 1000 0 112000 0 ... Protocol inet, MTU: 1500 Flags: None Addresses, Flags: Is-Preferred Is-Primary Destination: 9.9.9/24, Local: 9.9.9.10Meaning— A saída mostra um resumo dos pacotes que transitam pelo dispositivo no pacote multilink. Verifique as seguintes informações sobre o pacote multilink:O número total de pacotes de trânsito = 1000
O número total de fragmentos de trânsito=1100
O número de pacotes de dados fragmentados =100
O número total de pacotes enviados (600 + 400) no pacote multilink corresponde ao número de pacotes de trânsito (1000), indicando que nenhum pacote foi descartado.
O número de fragmentos de trânsito excede o número de pacotes de trânsito em 100, indicando que 100 grandes pacotes de dados foram corretamente fragmentados.
Corrective Action— Se os pacotes não forem fragmentados corretamente, verifique a configuração do limiar de fragmentação. Pacotes menores que o limiar de fragmentação especificado não são fragmentados.Verifique o encapsulamento de pacotes. Para descobrir se um pacote é tratado como um pacote LFI ou não LFI, determine seu tipo de encapsulamento. Os pacotes LFI são encapsulados por PPP, e os pacotes não LFI são encapsulados com PPP e MLPPP. Os encapsulamentos de PPP e MLPPP têm custos fixos diferentes, resultando em pacotes de diferentes tamanhos. Você pode comparar tamanhos de pacotes para determinar o tipo de encapsulamento.
Um pequeno pacote de dados nãofragmentado contém um cabeçalho PPP e um único cabeçalho MLPPP. Em um grande pacote de dados fragmentado, o primeiro fragmento contém um cabeçalho PPP e um cabeçalho MLPPP, mas os fragmentos consecutivos contêm apenas um cabeçalho MLPPP.
Os encapsulamentos de PPP e MLPPP adicionam o seguinte número de bytes a um pacote:
O encapsulamento de PPP adiciona 7 bytes:
4 bytes de cabeçalho+2 bytes de sequência de verificação de quadro (FCS)+1 byte que está ocioso ou contém uma bandeira
O encapsulamento do MLPPP adiciona entre 6 e 8 bytes:
4 bytes de cabeçalho PPP+2 a 4 bytes de cabeçalho multilink
Figura 1 mostra a sobrecarga adicionada aos cabeçalhos PPP e MLPPP.
Figura 1: Cabeçalhos PPP e MLPPP
Para pacotes CRTP, a sobrecarga de encapsulamento e o tamanho dos pacotes são ainda menores do que para um pacote LFI. Para obter mais informações, veja Exemplo: Configuração do protocolo de transporte em tempo real comprimido.
Tabela 2 mostra a sobrecarga de encapsulamento para um pacote de dados e um pacote de voz de 70 bytes cada. Após o encapsulamento, o tamanho do pacote de dados é maior do que o tamanho do pacote de voz.
Tabela 2: Sobrecarga de encapsulamento de PPP e MLPPP Tipo de pacote
Encapsulação
Tamanho inicial do pacote
Sobrecarga de encapsulamento
Tamanho do pacote após o encapsulamento
Pacote de voz (LFI)
PPP
70 bytes
4 + 2 + 1 = 7 bytes
77 bytes
Fragmento de dados (não LFI) com sequência curta
MLPPP
70 bytes
4 + 2 + 1 + 4 + 2 = 13 bytes
83 bytes
Fragmento de dados (não LFI) com longa sequência
MLPPP
70 bytes
4 + 2 + 1 + 4 + 4 = 15 bytes
85 bytes
Desde o modo operacional, insira o
show interfaces queuecomando para exibir o tamanho do pacote transmitido em cada fila. Divida o número de bytes transmitidos pelo número de pacotes para obter o tamanho dos pacotes e determinar o tipo de encapsulamento.Verifique o balanceamento de carga. A partir do modo operacional, insira o
show interfaces queuecomando no pacote multilink e seus links constituintes para confirmar se o balanceamento de carga é executado de acordo com os pacotes.user@R0> show interfaces queue lsq-0/0/0 Physical interface: lsq-0/0/0, Enabled, Physical link is Up Interface index: 136, SNMP ifIndex: 29 Forwarding classes: 8 supported, 8 in use Egress queues: 8 supported, 8 in use Queue: 0, Forwarding classes: DATA Queued: Packets : 600 0 pps Bytes : 44800 0 bps Transmitted: Packets : 600 0 pps Bytes : 44800 0 bps Tail-dropped packets : 0 0 pps RED-dropped packets : 0 0 pps … Queue: 1, Forwarding classes: expedited-forwarding Queued: Packets : 0 0 pps Bytes : 0 0 bps … Queue: 2, Forwarding classes: VOICE Queued: Packets : 400 0 pps Bytes : 61344 0 bps Transmitted: Packets : 400 0 pps Bytes : 61344 0 bps … Queue: 3, Forwarding classes: NC Queued: Packets : 0 0 pps Bytes : 0 0 bps …user@R0> show interfaces queue se-1/0/0 Physical interface: se-1/0/0, Enabled, Physical link is Up Interface index: 141, SNMP ifIndex: 35 Forwarding classes: 8 supported, 8 in use Egress queues: 8 supported, 8 in use Queue: 0, Forwarding classes: DATA Queued: Packets : 350 0 pps Bytes : 24350 0 bps Transmitted: Packets : 350 0 pps Bytes : 24350 0 bps ... Queue: 1, Forwarding classes: expedited-forwarding Queued: Packets : 0 0 pps Bytes : 0 0 bps … Queue: 2, Forwarding classes: VOICE Queued: Packets : 100 0 pps Bytes : 15272 0 bps Transmitted: Packets : 100 0 pps Bytes : 15272 0 bps … Queue: 3, Forwarding classes: NC Queued: Packets : 19 0 pps Bytes : 247 0 bps Transmitted: Packets : 19 0 pps Bytes : 247 0 bps …user@R0> show interfaces queue se-1/0/1 Physical interface: se-1/0/1, Enabled, Physical link is Up Interface index: 142, SNMP ifIndex: 38 Forwarding classes: 8 supported, 8 in use Egress queues: 8 supported, 8 in use Queue: 0, Forwarding classes: DATA Queued: Packets : 350 0 pps Bytes : 24350 0 bps Transmitted: Packets : 350 0 pps Bytes : 24350 0 bps … Queue: 1, Forwarding classes: expedited-forwarding Queued: Packets : 0 0 pps Bytes : 0 0 bps … Queue: 2, Forwarding classes: VOICE Queued: Packets : 300 0 pps Bytes : 45672 0 bps Transmitted: Packets : 300 0 pps Bytes : 45672 0 bps … Queue: 3, Forwarding classes: NC Queued: Packets : 18 0 pps Bytes : 234 0 bps Transmitted: Packets : 18 0 pps Bytes : 234 0 bpsMeaning— A saída desses comandos mostra os pacotes transmitidos e enfileirados em cada fila da interface de serviços de link e seus links constituintes. Tabela 3 mostra um resumo desses valores. (Como o número de pacotes transmitidos igualou o número de pacotes enfileirados em todos os links, esta tabela mostra apenas os pacotes enfileirados.)Tabela 3: Número de pacotes transmitidos em uma fila Pacotes enfileirados
Pacote lsq-0/0/0,0
Enlace constituinte se-1/0/0
Enlace constituinte se-1/0/1
Explicação
Pacotes no Q0
600
350
350
O número total de pacotes que transitam pelos links constituintes (350+350 = 700) excedeu o número de pacotes enfileirados (600) no pacote multilink.
Pacotes no 2º trimestre
400
100
300
O número total de pacotes que transitam pelos links constituintes igualou o número de pacotes no pacote.
Pacotes no terceiro trimestre
0
19
18
Os pacotes que transitam no terceiro trimestre dos links constituintes são para mensagens keepalive trocadas entre links constituintes. Assim, nenhum pacote foi contado no terceiro trimestre do pacote.
No pacote multilink, verifique o seguinte:
O número de pacotes enfileirados corresponde ao número transmitido. Se os números corresponderem, nenhum pacote foi descartado. Se mais pacotes fossem enfileirados do que os transmitidos, os pacotes eram descartados porque o buffer era muito pequeno. O tamanho do buffer nos links constituintes controla o congestionamento na fase de saída. Para corrigir esse problema, aumente o tamanho do buffer nos links constituintes.
O número de pacotes que transitam Q0 (600) corresponde ao número de pacotes de dados grandes e pequenos recebidos (100+500) no pacote multilink. Se os números corresponderem, todos os pacotes de dados transitaram corretamente no Q0.
O número de pacotes que transitam pelo Q2 no pacote multilink (400) corresponde ao número de pacotes de voz recebidos no pacote multilink. Se os números corresponderem, todos os pacotes LFI de voz transitaram corretamente no 2º trimestre.
Nos links constituintes, verifique o seguinte:
O número total de pacotes em trânsito Q0 (350+350) corresponde ao número de pacotes de dados e fragmentos de dados (500+200). Se os números corresponderem, todos os pacotes de dados após a fragmentação transitaram corretamente pelo Q0 dos links constituintes.
Os pacotes transitaram em ambos os links constituintes, indicando que o balanceamento de carga foi executado corretamente em pacotes não LFI.
O número total de pacotes que transitam pelo Q2 (300+100) em links constituintes corresponde ao número de pacotes de voz recebidos (400) no pacote multilink. Se os números corresponderem, todos os pacotes LFI de voz transitaram corretamente no 2º trimestre.
Pacotes LFI da porta
100de origem transitadosse-1/0/0e pacotes LFI da porta200de origem transitadosse-1/0/1. Assim, todos os pacotes LFI (Q2) foram hashed com base na porta de origem e transitaram corretamente em ambos os links constituintes.
Corrective Action— Se os pacotes transitaram apenas um link, tome as seguintes medidas para resolver o problema:Determine se o link físico está
up(operacional) oudown(indisponível). Um link indisponível indica um problema com o PIM, a porta da interface ou a conexão física (erros da camada de enlace). Se o link estiver operacional, passe para a próxima etapa.Verifique se os classificadores estão definidos corretamente para pacotes não LFI. Certifique-se de que os pacotes não LFI não estejam configurados para serem enfileirados no 2º trimestre. Todos os pacotes enfileirados no 2º trimestre são tratados como pacotes LFI.
Verifique se pelo menos um dos seguintes valores é diferente nos pacotes LFI: endereço fonte, endereço de destino, protocolo IP, porta de origem ou porta de destino. Se os mesmos valores estiverem configurados para todos os pacotes LFI, todos os pacotes serão hashed para o mesmo fluxo e transitam pelo mesmo link.
Use os resultados para verificar o balanceamento de carga.
Determine por que os pacotes são descartados em um PVC entre um dispositivo da Juniper Networks e um dispositivo de terceiros
Problema
Descrição
Você está configurando um circuito virtual permanente (PVC) entre interfaces T1, E1, T3 ou E3 em um dispositivo da Juniper Networks e um dispositivo de terceiros, e os pacotes estão sendo descartados e o ping falha.
Solução
Se o dispositivo de terceiros não tiver o mesmo suporte FRF.12 que o dispositivo Juniper Networks ou suportar o FRF.12 de uma maneira diferente, a interface de dispositivo da Juniper Networks no PVC pode descartar um pacote fragmentado contendo cabeçalhos FRF.12 e contá-lo como um "Descarte policiado".
Como uma solução alternativa, configure pacotes multilink em ambos os pares e configure limites de fragmentação nos pacotes multilink.
Resolução de problemas de políticas de segurança
- Sincronização de políticas entre mecanismo de roteamento e mecanismo de encaminhamento de pacotes
- Verificando uma falha no compromisso da política de segurança
- Confirmar o compromisso de uma política de segurança
- Busca de políticas de depuração
Sincronização de políticas entre mecanismo de roteamento e mecanismo de encaminhamento de pacotes
Problema
Descrição
As políticas de segurança são armazenadas no mecanismo de roteamento e no mecanismo de encaminhamento de pacotes. As políticas de segurança são empurradas do mecanismo de roteamento para o mecanismo de encaminhamento de pacotes quando você confirma configurações. Se as políticas de segurança no mecanismo de roteamento estiverem fora de sincronia com o Mecanismo de encaminhamento de pacotes, o comprometimento de uma configuração falha. Os arquivos de despejo de núcleo podem ser gerados se o commit for tentado repetidamente. A desincronizá-lo pode ser devido a:
Uma mensagem de política do mecanismo de roteamento para o mecanismo de encaminhamento de pacotes é perdida em trânsito.
Um erro com o mecanismo de roteamento, como um UID de política reutilizado.
Ambiente
As políticas no mecanismo de roteamento e mecanismo de encaminhamento de pacotes devem estar em sincronia para que a configuração seja comprometida. No entanto, em determinadas circunstâncias, as políticas no mecanismo de roteamento e no mecanismo de encaminhamento de pacotes podem estar fora de sincronia, o que faz com que o compromisso fracasse.
Sintomas
Quando as configurações de políticas são modificadas e as políticas estão fora de sincronia, a mensagem de erro a seguir é exibida - error: Warning: policy might be out of sync between RE and PFE <SPU-name(s)> Please request security policies check/resync.
Solução
Use o show security policies checksum comando para exibir o valor do checkum da política de segurança e use o request security policies resync comando para sincronizar a configuração das políticas de segurança no Mecanismo de Roteamento e mecanismo de encaminhamento de pacotes, se as políticas de segurança estiverem fora de sincronia.
Consulte também
Verificando uma falha no compromisso da política de segurança
Problema
Descrição
A maioria das falhas de configuração de políticas ocorrem durante um compromisso ou tempo de execução.
As falhas de confirmação são relatadas diretamente na CLI quando você executa o comando commit-check CLI no modo de configuração. Esses erros são erros de configuração e você não pode confirmar a configuração sem corrigir esses erros.
Solução
Para corrigir esses erros, faça o seguinte:
Analise seus dados de configuração.
Abra o arquivo /var/log/nsd_chk_only. Este arquivo é sobreescrito cada vez que você realiza uma verificação de confirmação e contém informações detalhadas de falha.
Confirmar o compromisso de uma política de segurança
Problema
Descrição
Ao realizar um compromisso de configuração de política, se você notar que o comportamento do sistema está incorreto, use as seguintes etapas para solucionar este problema:
Solução
Comandos operacionais show — Execute os comandos operacionais para políticas de segurança e verifique se as informações mostradas na saída são consistentes com o que você esperava. Se não, a configuração precisa ser alterada adequadamente.
Traceoptions — Defina o
traceoptionscomando em sua configuração de política. As bandeiras sob essa hierarquia podem ser selecionadas de acordo com a análise do usuário dashowsaída de comando. Se você não puder determinar qual bandeira usar, a opçãoallde bandeira pode ser usada para capturar todos os logs de rastreamento.user@host#
set security policies traceoptions <flag all>
Você também pode configurar um nome de arquivo opcional para capturar os logs.
user@host# set security policies traceoptions <filename>
Se você especificou um nome de arquivo nas opções de rastreamento, você pode procurar no /var/log/<filename> para o arquivo de log verificar se algum erro foi relatado no arquivo. (Se você não especificou um nome de arquivo, o nome de arquivo padrão é eventd.) As mensagens de erro indicam o local da falha e o motivo apropriado.
Após a configuração das opções de rastreamento, você deve reacomodar a mudança de configuração que causou o comportamento incorreto do sistema.
Busca de políticas de depuração
Problema
Descrição
Quando você tem a configuração correta, mas algum tráfego foi incorreto ou permitido, você pode ativar a lookup bandeira nas traceoptions de políticas de segurança. A lookup bandeira registra os vestígios relacionados à busca no arquivo de rastreamento.
Solução
user@host# set security policies traceoptions <flag lookup>