Juniper SRX - Sem tráfego após 17 minutos


7

Este é realmente um problema estranho .

Estou tentando instalar um Juniper SRX 220H como gateway para substituir meu antigo roteador Cisco no meu ambiente de rede de teste. A topologia simplificada está listada abaixo:

    ISP ----- ONT ----- SRX ----- Other devices (Routers, switches, client computers...)

O link do ISP para o SRX é um link de tronco 802.1Q contém duas VLANs (VLAN 35 para acesso à Internet, endereço IP atribuído pelo DHCP, concessão por 20 minutos. VLAN 34 para IPTV que não é usada aqui).

O SRX pode obter o endereço IP do ISP primeiro. Após 12 a 17 minutos (após a renovação da primeira concessão de DHCP e antes da segunda renovação), o SRX perdeu o acesso à Internet (não é possível executar ping no gateway). Não há nada de especial ou mesmo um aviso no log ou no status do sistema. "show interface" disse que tudo funciona bem. Mas nenhum tráfego em ge-0/0/0. Se eu desconectar o cabo ou reiniciar o SRX, ele funcionará por mais 12 a 17 minutos e todo o tráfego será interrompido novamente.

Antes de instalar este SRX, o roteador Cisco antigo com a mesma configuração funciona sem problemas.

Alguma pista?

A configuração parcial do SRX está listada abaixo:

interfaces {
    ge-0/0/0 {
        unit 0 {
            family ethernet-switching {
                port-mode trunk;
                vlan {
                    members vlan-internet;
                }
            }
        }
    }
    ge-0/0/1 {
        unit 0 {
            family ethernet-switching {
                vlan {
                    members vlan-trust;
                }
            }
        }
    vlan {
        mac xx:xx:xx:xx:xx:xx;
        unit 0 {
            family inet {
                address 192.168.99.254/24;
            }
        }
        unit 35 {
            family inet {
                dhcp;
            }
        }
    }
    }                                   

vlans {
    vlan-internet {
        vlan-id 35;
        l3-interface vlan.35;
    }
    vlan-trust {
        vlan-id 3;
        l3-interface vlan.0;
    }
}

Configuração Cisco correspondente:

interface GigabitEthernet0/0
 description WAN
 mac-address xxxx.xxxx.xxxx
 no ip address
 duplex auto
 speed auto
 media-type rj45
 no negotiation auto
!
interface GigabitEthernet0/0.35
 description FibreOP-Internet
 encapsulation dot1Q 35
 ip address dhcp
 ip nat outside
 ip virtual-reassembly in
!

EDITAR:

Troquei o cabo que conecta o ISP e o SRX ge-0/0/0. Nada bom.

EDIT2:

Eu configurei um switch Cisco sobressalente para simular meu ambiente de ISP. O tronco da VLAN e o mesmo termo de concessão do DHCP estão definidos. Então eu conecto ge-0/0/0 do SRX a esse switch. A configuração do SRX é mantida. Neste experimento, comportamento SRX normal. Isso me deixa realmente confuso.

EDIT3:

Saída solicitada por @ryanklein

root@Firewall> show dhcp client statistics                   
warning: dhcp-service subsystem not running - not needed by configuration.

root@Firewall> show dhcp client binding 
warning: dhcp-service subsystem not running - not needed by configuration.

EDIT4:

Saída solicitada por @ryanklein

root@Firewall> show system services dhcp statistics 
Packets dropped:
    Total                      0

Messages received:
    BOOTREQUEST                0
    DHCPDECLINE                0
    DHCPDISCOVER               0
    DHCPINFORM                 0
    DHCPRELEASE                0
    DHCPREQUEST                0

Messages sent:
    BOOTREPLY                  0
    DHCPOFFER                  0
    DHCPACK                    0
    DHCPNAK                    0

root@Firewall> show system services dhcp client 

 Logical Interface name         vlan.35
        Hardware address        xx:xx:xx:xx:xx:xx
        Client status           bound
        Address obtained        142.xxx.xxx.xxx
        Update server           disabled
        Lease obtained at       2015-01-18 03:35:47 NST
        Lease expires at        2015-01-18 03:55:47 NST

DHCP options:
    Code: 1, Type: ip-address, Value: 255.255.252.0
    Name: server-identifier, Value: 142.yyy.yyy.yyy
    Name: router, Value: [ 142.xxx.xxx.1 ]
    Name: name-server, Value: [ 47.55.55.55, 142.166.166.166 ]

root@Firewall> 

EDIT5:

Capturei os dados entre SRX e ISP e descobri que algo pode ser útil.

O diagrama de topologia é atualizado (adicionado dispositivo ONT ausente entre SRX e ISP).

  • Quando a Internet acaba, as comunicações da camada 2 entre ONT e SRX ainda estão ativas. Parece que o ONT continua enviando solicitações de consulta ARP para os endereços IP que meu ISP atribuiu ao SRX. Após a saída da Internet, ainda consigo ver as solicitações e respostas do ARP. Eu acho que esse comportamento indica que o ONT não é a raiz desse problema.

  • Quando a Internet acabar, os pacotes de solicitação de DHCP não receberão respostas, assim como outro tráfego. Tentei renovar meu endereço IP no SRX depois que a Internet desapareceu, mas falhou. Os dados capturados mostram que não há respostas do lado remoto.

  • A renovação do DHCP é bem-sucedida quando a Internet está normal. Quando emiti "solicitar serviço de sistema dhcp client renew vlan.35", posso ver a solicitação DHCP e o DHCP ACK correspondente.

  • (INCORRETO. Consulte o próximo item) Quando a Internet acabar, libere a concessão DHCP atual e solicite uma nova para restaurar a conectividade. Tentei liberar a concessão DHCP atual e renová-la, o SRX recebeu um novo endereço IP e a Internet voltou. Os dados capturados mostram que, embora um único pacote de solicitação DHCP não receba resposta (veja acima), um pacote de liberação DHCP resulta em uma resposta DHCP NAK . Depois disso, uma descoberta DHCP é emitida e obtém a oferta DHCP correta. Então a Internet está de volta. No entanto, quando tentei repetir esse resultado, nada de bom: nem a liberação do DHCP nem a descoberta do DHCP obtêm respostas. Emiti o comando de liberação e renovação logo após um comando de renovação. Não tenho certeza se o comportamento irrespondível é causado pelo envio rápido ou não desses pacotes.

  • Depois que a Internet acabar, emita uma solicitação de descoberta DHCP e processada, pois a primeira solicitação restaurará a conexão com a Internet. Os dados capturados mostram que, quando a Internet acaba, a emissão de um pacote de solicitação DHCP resulta em uma resposta DHCP NAK. Combine com o resultado do item anterior, a emissão de solicitação e liberação do DHCP resultará em DHCP NAK. No entanto, o processo como se fosse a primeira vez que solicita um endereço IP do servidor DHCP (envie a descoberta do DHCP e a solicitação do DHCP) obterá um resultado positivo e restaurará o acesso à Internet. ATUALIZADO: Parece que o NAK nem sempre é enviado ... às vezes a solicitação / liberação do DHCP é retornada com o DHCP NAK, às vezes apenas o silêncio ...


Você já tentou falsificar o MAC do seu roteador Cisco antigo? Talvez esse problema esteja no fim do ISP?
Panther Modern

@ Panther, eu já fiz isso. A configuração do SRX contém isso.
Lingfeng Xiong

Acredito que sua instrução Mac deve estar diretamente em ge-0/0/0, não na sua VLAN.
Panther Modern

11
@ Panther, adicionei a instrução Mac sob ge-0/0/0 também. O problema ainda está aí.
Lingfeng Xiong

11
@ryanklein Parece que o problema é causado pelo servidor DHCP remoto expirar minha concessão de DHCP antes de mim. Por favor, consulte a seção EDIT5. Obrigado. BTW: É perceptível que o SRX está enviando todos os tipos de solicitações DHCP com TTL = 1. Lembrei-me de que alguns artigos diziam que esse comportamento pode causar um trabalho de retransmissão DHCP anormal. Mas ainda é possível obter endereços IP ... então eu não sei se é o caso.
Lingfeng Xiong

Respostas:


6

Eu resolvi esse problema finalmente. Ao capturar e comparar os pacotes DHCP Discover enviados do JunOS e Cisco, descobri que a Cisco envia o Identificador de cliente da opção 64 e o nome do host da opção 12 por padrão. No entanto, o JunOS não os enviará sem instruções explícitas.

Eu acho que meu ISP configura um filtro ou algo do lado deles. As duas opções acima são obrigatórias. Quando eu configuro meu SRX para enviá-los, tudo passou.


0

Uma coisa que você pode querer confirmar é que o SRX está usando um DHCPREQUEST adequado para renovar o endereço em vez de outro DHCPDISCOVER.

Aqui está como habilitar a depuração.

http://kb.juniper.net/InfoCenter/index?page=content&id=KB26748#DHCP_Client

Eu tenho uma experiência limitada com o Juniper, mas vi pelo menos um sistema operacional importante fazer isso quando o relógio do sistema não estava correto.

No mínimo, você quer ver o que está acontecendo com a renovação.


Coloquei um switch Cisco entre SRX e ISP e o espelhamento de porta configurado. A captura de pacotes mostra que uma solicitação DHCP correta é enviada durante a renovação. Nenhuma mensagem de descoberta DHCP é enviada, exceto na primeira vez em que o endereço IP é obtido.
Lingfeng Xiong
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.