NESTA PÁGINA
Não é possível gerenciar o nó secundário de um cluster de chassi usando a J-Web
Não é possível atualizar um cluster de chassi usando upgrade de software em serviço
Configuração do comando de roteador de backup no cluster do chassi
Não é possível atualizar um cluster de chassi usando upgrade de software em serviço
Resolução de problemas de problemas de gerenciamento de clusters de chassi
Não é possível gerenciar um cluster de chassi da Série SRX usando a porta de gerenciamento ou as portas de receita
Problema
Descrição
Não é possível gerenciar o cluster de chassi da Série SRX usando a porta de gerenciamento ou as portas de receita.
Ambiente
Cluster de chassi da Série SRX
Diagnóstico
Qual nó no cluster do chassi você está usando para gerenciar o cluster?
Nó primário — Prossiga para:
Gerencie o cluster de chassi usando a J-Web.
Nota:Você pode usar a J-Web para gerenciar apenas o nó principal.
Gerencie o cluster de chassis usando a porta de receita ou a porta de gerenciamento do fxp0.
Nota:Você pode usar a porta de receita ou a porta de gerenciamento Dep0 para gerenciar o nó primário.
Nó secundário — Prossiga para gerenciar o cluster de chassis usando a porta de gerenciamento Dap0
Nota:Você só pode gerenciar o nó secundário usando a porta de gerenciamento Dop0.
Resolução
- Gerencie o cluster de chassi usando j-web
- Gerencie o cluster de chassis usando a porta de receita ou a porta de gerenciamento Dop0
- Gerencie o cluster de chassis usando a porta de gerenciamento Dop0
- O que vem a seguir
- Gerencie o cluster de chassi usando j-web
- Gerencie o cluster de chassis usando a porta de receita ou a porta de gerenciamento Dop0
- Gerencie o cluster de chassis usando a porta de gerenciamento Dop0
- O que vem a seguir
Gerencie o cluster de chassi usando j-web
Você pode usar a J-Web para gerenciar apenas o nó principal.
-
Conecte um console ao nó principal.
-
Usando o CLI, execute o
show system services web-managementcomando. -
Verifique se a interface de loopback (lo0) está configurada na configuração HTTP/HTTPS do gerenciamento da Web. Consulte o gerenciamento da web (Serviços de sistema) .
-
Se a interface de loopback (lo0) estiver configurada sob a configuração HTTP/HTTPS do gerenciamento da Web, remova a interface de loopback executando o
delete system services web-management http interface lo.0comando. -
Comprometa a mudança e verifique se agora você pode gerenciar o cluster do chassi.
-
Se você ainda não conseguir gerenciar o cluster do chassi, siga para gerenciar o cluster de chassis usando a porta de receita ou a porta de gerenciamento Daxp0.
Gerencie o cluster de chassis usando a porta de receita ou a porta de gerenciamento Dop0
Você pode usar tanto a porta de receita quanto a porta de gerenciamento de switches para gerenciar o nó primário.
-
Conecte-se a um console usando a porta de receita do nó principal que você deseja usar como uma interface de gerenciamento.
-
Verifique a configuração da interface de gerenciamento:
-
Verifique se os serviços de sistema necessários (SSH, Telnet, HTTP) estão habilitados no nível de host-inbound-traffic hierarquia na zona relevante:
zones { security-zone trust { host-inbound-traffic { system-services { any-service; } protocols { all; } } interfaces { reth0.0 reth0.1; } } -
Verifique se os serviços de sistema necessários (SSH, Telnet, HTTP) estão habilitados no nível de system services hierarquia:
{primary:node1}[edit] root# show system services { http; ssh; telnet; }
-
-
O ping na interface de gerenciamento funciona?
-
Yes: Não é possível gerenciar um cluster de chassi da Série SRX usando o fxp0 quando o destino no roteador de backup for 0/0. Se essa solução não funcionar, prossiga para o What's Next para abrir um caso com o suporte técnico da Juniper Networks.
-
No: Prossiga para a etapa 4.
-
-
Usando o CLI, execute o
show interfaces tersecomando:Na saída, o status de
FXP0 interfaceup é e ele fornece um endereço IP?-
Yes: Prossiga para a etapa 5.
-
No: Verifique o seguinte:
-
Usando o CLI, verifique se a interface do fxp0 está configurada corretamente: show groups.
Saída de amostra:
root@srx# show groups node0 { system { host-name SRX3400-1; backup-router 192.168.1.254 destination 0.0.0.0/0; } interfaces { fxp0 { unit 0 { family inet { address 192.168.1.1/24; } } } } } node1 { system { host-name SRX3400-2; backup-router 192.168.1.254 destination 0.0.0.0/0; } interfaces { fxp0 { unit 0 { family inet { address 192.168.1.2/24; } } } } } } apply-groups "${NODE}"; system { services { ftp; ssh; telnet; } } -
Verifique a condição do cabo que está conectado à fxp0 interface. O cabo está em boas condições?
-
Yes: Prossiga para a próxima etapa.
-
No: Substitua o cabo e tente gerenciar o cluster do chassi. Se você ainda não conseguir gerenciar o cluster do chassi, siga para a próxima etapa.
-
-
Usando a CLI, verifique se há contadores de erros de incremento: show interfaces fxp0.0 extensive.
-
Yes: Se você encontrar algum erro na saída, siga para o What's Next para abrir um caso com o suporte técnico da Juniper Networks.
-
No: Se não houver erros na saída e se você ainda não conseguir gerenciar o cluster do chassi, prossiga para a etapa 5.
-
-
-
-
Verifique se o endereço IP da fxp0 interface e o endereço IP do dispositivo de gerenciamento estão na mesma sub-rede.
-
Yes: Prossiga para a etapa 6.
-
No:Usando a CLI, verifique se há uma rota para o endereço IP do dispositivo de gerenciamento: : show route <management device IP>
-
Se uma rota não existir para o endereço IP do dispositivo de gerenciamento, adicione uma rota para a sub-rede de gerenciamento na tabela com o inet.0 próximo salto como endereço IP do roteador de backup.
-
-
-
Usando a CLI, verifique se há uma entrada ARP para o dispositivo de gerenciamento no gateway de serviços: show arp no-resolve | match <ip>.
-
Yes: Verifique se o cluster do chassi tem várias rotas para o dispositivo de gerenciamento: show route <device-ip>.
-
Yes: Poderia haver rotas para o dispositivo de gerenciamento por meio da interface do fxp0 e outras interfaces que levam ao roteamento assimétrico. Prossiga para o que vem a seguir para abrir um caso com o suporte técnico da Juniper Networks.
-
No:Prossiga para gerenciar o cluster de chassis usando a porta de gerenciamento do fxp0.
-
-
No: Prossiga para o que vem a seguir para abrir um caso com o suporte técnico da Juniper Networks.
-
Gerencie o cluster de chassis usando a porta de gerenciamento Dop0
Você só pode usar a porta de gerenciamento Dop0 para gerenciar o nó secundário.
-
Verifique a configuração da interface de gerenciamento no nó secundário:
-
Verifique se os serviços de sistema necessários (SSH, Telnet, HTTP) estão habilitados no nível de host-inbound-traffic hierarquia:
zones { security-zone trust { host-inbound-traffic { system-services { any-service; } protocols { all; } } interfaces { reth0.0 reth0.1; } } -
Verifique se os serviços de sistema necessários (SSH, Telnet, HTTP) estão habilitados no nível de system services hierarquia:
{primary:node1}[edit] root# show system services { http; ssh; telnet; }
Veja como gerenciar um cluster de chassi da Série SRX usando o fxp0 quando o destino no roteador de backup é 0/0 e configurando o comando de roteador de backup no cluster de chassi para obter mais informações sobre as diretrizes de configuração.
Se a configuração estiver correta e você ainda não conseguir gerenciar o cluster do chassi, prossiga para a etapa 2.
-
-
Os endereços IP das interfaces do switchp0 do nó primário e do nó secundário estão na mesma sub-rede?
-
Yes: Prossiga para o que vem a seguir.
-
No: Configure as interfaces de fxp0 do nó primário e do nó secundário na mesma sub-rede. Vá para a etapa 1 e verifique a configuração.
-
O que vem a seguir
-
Se o problema persistir, consulte o artigo KB KB20795.
-
Se quiser depurar mais, consulte o artigo KB KB21164 para verificar os logs de depuração.
-
Para abrir um caso da JTAC com a equipe de suporte da Juniper Networks, consulte a coleta de dados para suporte ao cliente para os dados que você deve coletar para ajudar na solução de problemas antes de abrir um caso da JTAC.
Gerencie o cluster de chassi usando j-web
Você pode usar a J-Web para gerenciar apenas o nó principal.
Conecte um console ao nó principal.
Usando o CLI, execute o
show system services web-managementcomando.Verifique se a interface de loopback (lo0) está configurada na configuração HTTP/HTTPS do gerenciamento da Web. Consulte o gerenciamento da web (Serviços de sistema) .
Se a interface de loopback (lo0) estiver configurada sob a configuração HTTP/HTTPS do gerenciamento da Web, remova a interface de loopback executando o
delete system services web-management http interface lo.0comando.Comprometa a mudança e verifique se agora você pode gerenciar o cluster do chassi.
Se você ainda não conseguir gerenciar o cluster do chassi, siga para gerenciar o cluster de chassis usando a porta de receita ou a porta de gerenciamento Daxp0.
Gerencie o cluster de chassis usando a porta de receita ou a porta de gerenciamento Dop0
Você pode usar tanto a porta de receita quanto a porta de gerenciamento de switches para gerenciar o nó primário.
Conecte-se a um console usando a porta de receita do nó principal que você deseja usar como uma interface de gerenciamento.
Verifique a configuração da interface de gerenciamento:
Verifique se os serviços de sistema necessários (SSH, Telnet, HTTP) estão habilitados no nível de host-inbound-traffic hierarquia na zona relevante:
zones { security-zone trust { host-inbound-traffic { system-services { any-service; } protocols { all; } } interfaces { reth0.0 reth0.1; } }Verifique se os serviços de sistema necessários (SSH, Telnet, HTTP) estão habilitados no nível de system services hierarquia:
{primary:node1}[edit] root# show system services { http; ssh; telnet; }
O ping na interface de gerenciamento funciona?
Yes: Não é possível gerenciar um cluster de chassi da Série SRX usando o fxp0 quando o destino no roteador de backup for 0/0. Se essa solução não funcionar, prossiga para o What's Next para abrir um caso com o suporte técnico da Juniper Networks.
No: Prossiga para a etapa 4.
Usando o CLI, execute o
show interfaces tersecomando:Na saída, o status de
FXP0 interfaceup é e ele fornece um endereço IP?Yes: Prossiga para a etapa 5.
No: Verifique o seguinte:
Usando o CLI, verifique se a interface do fxp0 está configurada corretamente: show groups.
Saída de amostra:
root@srx# show groups node0 { system { host-name SRX3400-1; backup-router 192.168.1.254 destination 0.0.0.0/0; } interfaces { fxp0 { unit 0 { family inet { address 192.168.1.1/24; } } } } } node1 { system { host-name SRX3400-2; backup-router 192.168.1.254 destination 0.0.0.0/0; } interfaces { fxp0 { unit 0 { family inet { address 192.168.1.2/24; } } } } } } apply-groups "${NODE}"; system { services { ftp; ssh; telnet; } }Verifique a condição do cabo que está conectado à fxp0 interface. O cabo está em boas condições?
Yes: Prossiga para a próxima etapa.
No: Substitua o cabo e tente gerenciar o cluster do chassi. Se você ainda não conseguir gerenciar o cluster do chassi, siga para a próxima etapa.
Usando a CLI, verifique se há contadores de erros de incremento: show interfaces fxp0.0 extensive.
Yes: Se você encontrar algum erro na saída, siga para o What's Next para abrir um caso com o suporte técnico da Juniper Networks.
No: Se não houver erros na saída e se você ainda não conseguir gerenciar o cluster do chassi, prossiga para a etapa 5.
Verifique se o endereço IP da fxp0 interface e o endereço IP do dispositivo de gerenciamento estão na mesma sub-rede.
Yes: Prossiga para a etapa 6.
No:Usando a CLI, verifique se há uma rota para o endereço IP do dispositivo de gerenciamento: : show route <management device IP>
Se uma rota não existir para o endereço IP do dispositivo de gerenciamento, adicione uma rota para a sub-rede de gerenciamento na tabela com o inet.0 próximo salto como endereço IP do roteador de backup.
Usando a CLI, verifique se há uma entrada ARP para o dispositivo de gerenciamento no gateway de serviços: show arp no-resolve | match <ip>.
Yes: Verifique se o cluster do chassi tem várias rotas para o dispositivo de gerenciamento: show route <device-ip>.
Yes: Poderia haver rotas para o dispositivo de gerenciamento por meio da interface do fxp0 e outras interfaces que levam ao roteamento assimétrico. Prossiga para o que vem a seguir para abrir um caso com o suporte técnico da Juniper Networks.
No:Prossiga para gerenciar o cluster de chassis usando a porta de gerenciamento do fxp0.
No: Prossiga para o que vem a seguir para abrir um caso com o suporte técnico da Juniper Networks.
Gerencie o cluster de chassis usando a porta de gerenciamento Dop0
Você só pode usar a porta de gerenciamento Dop0 para gerenciar o nó secundário.
Verifique a configuração da interface de gerenciamento no nó secundário:
Verifique se os serviços de sistema necessários (SSH, Telnet, HTTP) estão habilitados no nível de host-inbound-traffic hierarquia:
zones { security-zone trust { host-inbound-traffic { system-services { any-service; } protocols { all; } } interfaces { reth0.0 reth0.1; } }Verifique se os serviços de sistema necessários (SSH, Telnet, HTTP) estão habilitados no nível de system services hierarquia:
{primary:node1}[edit] root# show system services { http; ssh; telnet; }
Veja como gerenciar um cluster de chassi da Série SRX usando o fxp0 quando o destino no roteador de backup é 0/0 e configurando o comando de roteador de backup no cluster de chassi para obter mais informações sobre as diretrizes de configuração.
Se a configuração estiver correta e você ainda não conseguir gerenciar o cluster do chassi, prossiga para a etapa 2.
Os endereços IP das interfaces do switchp0 do nó primário e do nó secundário estão na mesma sub-rede?
Yes: Prossiga para o que vem a seguir.
No: Configure as interfaces de fxp0 do nó primário e do nó secundário na mesma sub-rede. Vá para a etapa 1 e verifique a configuração.
O que vem a seguir
Se o problema persistir, consulte o artigo KB KB20795.
Se quiser depurar mais, consulte o artigo KB KB21164 para verificar os logs de depuração.
Para abrir um caso da JTAC com a equipe de suporte da Juniper Networks, consulte a coleta de dados para suporte ao cliente para os dados que você deve coletar para ajudar na solução de problemas antes de abrir um caso da JTAC.
Não é possível gerenciar o nó secundário de um cluster de chassi usando a J-Web
Problema
Descrição
Não é possível gerenciar o nó secundário de um cluster de chassi usando a interface J-Web.
Ambiente
Cluster de chassi da Série SRX
Sintomas
Quando no modo de cluster do chassi do Junos Services Redundância Protocol (JSRP), você não pode gerenciar a redundância do grupo 0 (RG0) no nó secundário usando a interface J-Web.
Causa
Você pode usar a interface J-Web para gerenciar o grupo de redundância 0 apenas no nó principal.
Os processos que as referências J-Web não estão executando no nó secundário.
Exemplo
O exemplo a seguir mostra a saída do syslog e do processo do sistema em nós0 e nó1 depois que o RG0 falhou de nós1 para nós0.
No nó1, o processo de gerenciamento da web (httpd-gk) foi encerrado (saiu).
No nó0, o processo de gerenciamento da web (httpd-gk) foi iniciado.
Dois processos relacionados a http (httpd-gk e httpd), são executados apenas em nós0, que é o novo nó primário do RG0.
{secondary:node1}
root@SRX210HE-B> show chassis cluster status
Cluster ID: 1
Node Priority Status Preempt Manual failover
Redundancy group: 0 , Failover count: 1
node0 255 primary no yes
node1 1 secondary no yes
Redundancy group: 1 , Failover count: 1
node0 100 primary yes no
node1 1 secondary yes no
{secondary:node1}
root@SRX210HE-B> show log log-any | grep web-management
Jul 5 11:31:52 SRX210HE-B init: web-management (PID 9660) started
Jul 5 12:00:37 SRX210HE-B init: web-management (PID 9660) SIGTERM sent
Jul 5 12:00:37 SRX210HE-B init: web-management (PID 9660) exited with status=0 Normal Exit
{primary:node0}
root@SRX210HE-A> show log log-any | grep web-management
Jul 5 12:00:37 SRX210HE-A init: web-management (PID 9498) started
{primary:node0}
root@SRX210HE-A> show system processes extensive node 0 | grep http
9498 root 1 76 0 12916K 4604K select 0 0:00 0.00% httpd-gk
9535 nobody 1 90 0 8860K 3264K select 0 0:00 0.00% httpd
{primary:node0}
root@SRX210HE-A> show system processes extensive node 1 | grep http
=> No httpd-gk and httpd processes running on node 1 (secondary node)
Isso limita as chamadas de procedimento remoto (RPCs) da lógica J-Web e, posteriormente, páginas que podem ser emitidas a partir do nó secundário.
Solução
Você pode gerenciar o nó secundário de um cluster de chassi usando o CLI (SSH, telnet e console). Veja gerenciar o cluster de chassis usando a porta de gerenciamento Daxp0
Não é possível gerenciar um cluster de chassi da Série SRX usando o fxp0 quando o destino no roteador de backup é de 0/0
RESUMO Esse tópico explica, com um exemplo, como gerenciar um cluster de chassi da Série SRX configurado usando a configuração do roteador de backup por meio da interface do fxp0.
Problema
Descrição
O dispositivo de gerenciamento não pode gerenciar o cluster do chassi por meio de uma interface do tipo fxp0, mas ele pode colocar as duas interfaces do tipo fxp0.
Topologia de amostra
A topologia, endereços IP e configuração são os seguintes:
Fxp0 primário: 192.168.1.1/24
Fxp0 secundário: 192.168.1.2/24
Gateway para o fxp0: 192.168.1.254
Dispositivo de gerenciamento: 172.16.1.1/24
groups {
node0 {
system {
host-name SRX5400-1;
backup-router 192.168.1.254 destination 0.0.0.0/0;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 192.168.1.1/24;
}
}
}
}
}
node1 {
system {
host-name SRX5400-2;
backup-router 192.168.1.254 destination 0.0.0.0/0;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 192.168.1.2/24;
}
}
}
}
}
}
apply-groups "${NODE}";
system {
services {
ftp;
ssh;
telnet;
}
}
Ambiente
Cluster de chassi da Série SRX
Causa
Existe uma rota para o 172.16.1.1 através das interfaces que não sejam a interface do fxp0 nos dispositivos de cluster. Não recomendamos usar o 0.0.0.0/0 como destino do roteador de backup. O ping funciona porque a resposta echo para uma solicitação de eco de entrada para a interface de fxp0 é enviada após a rota para 172.16.1.1 através de interfaces que não sejam o fxp0, mas a Telnet falha.
Solução
Remova a rota para 172.16.1.1 na tabela de roteamento e configure um destino de roteador de backup mais específico no nó0/nó1 do grupo.
Por exemplo:
groups {
node0 {
...
backup-router 192.168.1.254 destination 172.16.1.1/32;
...
}
node1 {
...
backup-router 192.168.1.254 destination 172.16.1.1/32;
...
}
Nenhuma alteração é exibida na tabela de roteamento após a configuração ser aplicada porque a configuração do roteador de backup destina-se a facilitar o acesso de gerenciamento apenas no nó de backup. O acesso ao nó primário é habilitado através do roteamento no nó primário.Assim, quando a configuração do roteador de backup estiver completa, você pode ver que uma rota é injetada na tabela de encaminhamento no nó secundário. Você não pode ver a tabela de roteamento no nó secundário porque o subsistema de roteamento não funciona no nó secundário.
Saída de amostra quando o roteador de backup está configurado com destino 0/0
Tabela de roteamento sobre nó primário:
{primary:node0}[edit] root@SRX5400-1# run show route inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.1.0/24 *[Direct/0] 00:00:54 > via fxp0.0 192.168.1.1/32 *[Local/0] 00:00:54 Local via fxp0.0Tabela de encaminhamento em nó secundário com destino 0/0:
root@SRX3400-2# run show route forwarding-table Routing table: default.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif default user 0 28:c0:da:a0:88:0 ucst 345 2 fxp0.0 default perm 0 rjct 36 1 0.0.0.0/32 perm 0 dscd 34 1 192.168.1.0/24 intf 0 rslv 344 1 fxp0.0 192.168.1.0/32 dest 0 192.168.1.0 recv 342 1 fxp0.0 192.168.1.2/32 intf 0 192.168.1.2 locl 343 2 192.168.1.2/32 dest 0 192.168.1.2 locl 343 2 192.168.1.254/32 dest 0 28:c0:da:a0:88:0 ucst 345 2 fxp0.0 192.168.1.255/32 dest 0 192.168.1.255 bcst 336 1 fxp0.0 224.0.0.0/4 perm 0 mdsc 35 1 224.0.0.1/32 perm 0 224.0.0.1 mcst 31 1 255.255.255.255/32 perm 0 bcst 32 1 Routing table: __master.anon__.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 rjct 526 1 0.0.0.0/32 perm 0 dscd 524 1 224.0.0.0/4 perm 0 mdsc 525 1 224.0.0.1/32 perm 0 224.0.0.1 mcst 521 1 255.255.255.255/32 perm 0 bcst 522 1
Saída de amostra quando o roteador de backup está configurado com Destino 172.16.1.1/32
Tabela de roteamento sobre nó primário:
{primary:node0}[edit] root@SRX5400-1# run show route inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.1.0/24 *[Direct/0] 00:17:51 > via fxp0.0 192.168.1.1/32 *[Local/0] 00:55:50 Local via fxp0.0Tabela de encaminhamento sobre nó primário:
Nota:No nó primário, a rota 172.16.1.1/32 do roteador de backup não é mostrada na saída de amostra.
{primary:node0}[edit] root@SRX5400-1# run show route forwarding-table Routing table: default.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 rjct 36 1 0.0.0.0/32 perm 0 dscd 34 1 192.168.1.0/24 intf 0 rslv 334 1 fxp0.0 192.168.1.0/32 dest 0 192.168.1.0 recv 331 1 fxp0.0 192.168.1.1/32 intf 0 192.168.1.1 locl 332 2 192.168.1.1/32 dest 0 192.168.1.1 locl 332 2 192.168.1.3/32 dest 0 5c:5e:ab:16:e3:81 ucst 339 1 fxp0.0 192.168.1.6/32 dest 0 0:26:88:4f:c8:8 ucst 340 1 fxp0.0 192.168.1.11/32 dest 0 0:30:48:bc:9f:45 ucst 342 1 fxp0.0 192.168.1.254/32 dest 0 28:c0:da:a0:88:0 ucst 343 1 fxp0.0 192.168.1.255/32 dest 0 192.168.1.255 bcst 329 1 fxp0.0 224.0.0.0/4 perm 0 mdsc 35 1 224.0.0.1/32 perm 0 224.0.0.1 mcst 31 1 255.255.255.255/32 perm 0 bcst 32 1 Routing table: __master.anon__.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 rjct 526 1 0.0.0.0/32 perm 0 dscd 524 1 224.0.0.0/4 perm 0 mdsc 525 1 224.0.0.1/32 perm 0 224.0.0.1 mcst 521 1 255.255.255.255/32 perm 0 bcst 522 1Tabela de encaminhamento sobre o nó secundário:
Nota:No nó secundário, a rota 172.16.1.1/32 do roteador de backup é mostrada na saída de amostra. Isso facilita o acesso ao nó secundário por meio da interface do fxp0.
{secondary:node1}[edit] root@SRX5400-2# run show route forwarding-table Routing table: default.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 rjct 36 1 0.0.0.0/32 perm 0 dscd 34 1 172.16.1.1/32 user 0 192.168.1.254 ucst 345 2 fxp0.0 192.168.1.0/24 intf 0 rslv 344 1 fxp0.0 192.168.1.0/32 dest 0 192.168.1.0 recv 342 1 fxp0.0 192.168.1.2/32 intf 0 192.168.1.2 locl 343 2 192.168.1.2/32 dest 0 192.168.1.2 locl 343 2 192.168.1.254/32 dest 0 28:c0:da:a0:88:0 ucst 345 2 fxp0.0 192.168.1.255/32 dest 0 192.168.1.255 bcst 336 1 fxp0.0 224.0.0.0/4 perm 0 mdsc 35 1 224.0.0.1/32 perm 0 224.0.0.1 mcst 31 1 255.255.255.255/32 perm 0 bcst 32 1 Routing table: __master.anon__.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 rjct 526 1 0.0.0.0/32 perm 0 dscd 524 1 224.0.0.0/4 perm 0 mdsc 525 1 224.0.0.1/32 perm 0 224.0.0.1 mcst 521 1 255.255.255.255/32 perm 0 bcst 522 1
Se uma sub-rede em particular tiver uma rota configurada pelo roteador de backup e uma rota estática sob opções de roteamento, pode haver problemas no acesso à interface do fxp0. No exemplo acima, ocorre o problema com o acesso à interface do tipo fxp0 do dispositivo de gerenciamento quando:
A mesma rota existe como uma rota estática e pelo roteador de backup.
Existe uma rota estática que é mais específica do que a rota pelo roteador de backup.
Nos exemplos, quando as rotas do nó principal são sincronizadas para a tabela de encaminhamento do nó secundário, a rota configurada sob rota estática tem precedência sobre a rota sob o roteador de backup. Se 0/0 estiver configurado sob o roteador de backup, as chances de uma rota de correspondência melhor em rota estática são maiores. Por isso, recomendamos evitar 0/0 em um roteador de backup.
Se você quiser configurar rotas para o mesmo destino usando o roteador de backup, bem como a rota estática, divida as rotas ao configurar sob o roteador de backup. Com isso, as rotas configuradas sob o roteador de backup são as rotas preferidas e garante que a interface do fxp0 esteja acessível.
[edit routing-options static route] 0.0.0.0/0 next-hop 100.200.200.254; [edit groups node0 ] backup-router 192.168.1.254 destination [0.0.0.0/1 128.0.0.0/1];
Não é possível atualizar um cluster de chassi usando upgrade de software em serviço
Problema
Descrição
Não é possível atualizar um cluster de chassi usando um método mínimo de atualização de tempo de inatividade.
Ambiente
SRX5400 cluster de chassi.
Sintomas
-
Cluster preso no nó0 RG1 com bandeira IF e não pode ficar em cima.
-
O erro de confirmação de configuração é mostrado na CLI.
Causa
A configuração tem o mesmo prefixo em destinos de roteador de backup (em RE/nó de backup) e endereço de interface de usuário.
regress@R1_re# show interfaces ge-0/0/0
unit 0 {
family inet {
address 192.1.1.1/24;
}
}
regress@R1_re# show groups re1 system backup-router
10.204.63.254 destination 192.1.1.1/18;
regress@R1_re# commit
re0: configuration check succeeds re1: error: Cannot have same prefix for backup-router destination and interface address. ge-0/0/0.0 inet 192.1.1 error: configuration check-out failed re0: error: remote commit-configuration failed on re1
Solução
No modo cluster do chassi, o endereço de destino do roteador de backup para roteadores IPv4 e IPv6 usando os comandos edit system backup-router address destination destination-address e edit system inet6-backup-router address destination destination-address não deve ser o mesmo que o endereço de interface configurado para IPv4 e IPv6 usando os comandos edit interfaces interface-name unit logical-unit-number family inet address ipv4-address e edit interfaces interface-name unit logical-unit-number family inet6 address ipv6-address.Configuração do comando de roteador de backup no cluster do chassi
RESUMO Como fazer o backup de um roteador em um cluster de chassi da Série SRX usando o comando de backup-router configuração.
Problema
Descrição
Problemas de conectividade intermitente ao NSM e outros hosts de gerenciamento a partir do nó secundário.
Ambiente
Cluster de chassi da Série SRX
Causa
A configuração de um destino do roteador de 0.0.0.0/0 backup (sem configuração) não é suportada.
Exemplo de uma configuração incorreta:
set groups node0 system backup-router 10.10.10.1 destination 0.0.0.0/0
Solução
Consulte a configuração de um roteador de backup para a maneira recomendada de configurar um roteador de backup usando um prefixo não zero.
Exemplo de uma configuração de roteador de backup de sub-rede não zero:
set groups node0 system backup-router 10.10.10.1 destination 10.100.0.0/16
Como alternativa ao destino do roteador de backup de 0/0, aqui está outro exemplo em que 0/0 é dividido em dois prefixos:
set groups node0 system backup-router 10.10.10.1 destination 0.0.0.0/1 set groups node0 system backup-router 10.10.10.1 destination 128.0.0.0/1
Se várias redes precisarem ser acessáveis através do roteador de backup, você pode adicionar várias entradas de destino à configuração. A configuração do roteador de backup é usada apenas pelo nó secundário RG0. O nó primário continua a usar a tabela de rotas inet.0.
Não é possível atualizar um cluster de chassi usando upgrade de software em serviço
Problema
Descrição
Não é possível atualizar um cluster de chassi usando um método mínimo de atualização de tempo de inatividade.
Ambiente
SRX5400 cluster de chassi.
Sintomas
-
Cluster preso no nó0 RG1 com bandeira IF e não pode ficar em cima.
-
O erro de confirmação de configuração é mostrado na CLI.
Causa
A configuração tem o mesmo prefixo em destinos de roteador de backup (em RE/nó de backup) e endereço de interface de usuário.
regress@R1_re# show interfaces ge-0/0/0
unit 0 {
family inet {
address 192.1.1.1/24;
}
}
regress@R1_re# show groups re1 system backup-router
10.204.63.254 destination 192.1.1.1/18;
regress@R1_re# commit
re0: configuration check succeeds re1: error: Cannot have same prefix for backup-router destination and interface address. ge-0/0/0.0 inet 192.1.1 error: configuration check-out failed re0: error: remote commit-configuration failed on re1