Juniper SRX: sin tráfico después de 17 minutos

Este es realmente un problema extraño .

Estoy tratando de instalar un Juniper SRX 220H como puerta de enlace para reemplazar mi antiguo enrutador Cisco en mi entorno de prueba de red. La topología simplificada se enumera a continuación:

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

El enlace de ISP a SRX es un enlace troncal 802.1Q que contiene dos VLAN (VLAN 35 para acceso a Internet, dirección IP asignada por DHCP, arrendamiento por 20 minutos. VLAN 34 para IPTV que no se usa aquí).

SRX puede obtener la dirección IP del ISP al principio. Después de 12 a 17 minutos (después de la primera renovación de arrendamiento de DHCP y antes de la segunda renovación), SRX perdió el acceso a Internet (no puede hacer ping a la puerta de enlace). No hay nada especial o incluso un aviso en el registro del sistema o el estado del sistema. "show interface" dijo que todo funciona bien. Pero no hay tráfico en absoluto en ge-0/0/0. Si desconecto el cable o reinicio SRX, funciona durante otros 12 a 17 minutos y luego todo el tráfico se detiene nuevamente.

Antes de instalar este SRX, el antiguo enrutador Cisco con la misma configuración funciona sin ningún problema.

¿Alguna pista?

La configuración parcial de SRX se enumera a continuación:

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;
    }
}

Configuración de Cisco correspondiente:

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:

Reemplacé el cable que conecta ISP y SRX ge-0/0/0. Nada bueno.

EDIT2:

Configuré un switch Cisco de repuesto para simular mi entorno de ISP. Se establece la troncal de VLAN y el mismo plazo de arrendamiento de DHCP. Luego conecto ge-0/0/0 de SRX a ese interruptor. La configuración de SRX se mantiene. En este experimento, el comportamiento SRX es normal. Esto me confunde mucho.

EDITAR3:

Salida 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.

EDITAR4:

Salida 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> 

EDITAR5:

Capturé los datos entre SRX e ISP y descubrí que algo puede ser útil.

El diagrama de topología se actualiza (se agregó el dispositivo ONT faltante entre SRX e ISP).

• Cuando Internet desaparece, las comunicaciones de capa 2 entre ONT y SRX siguen activas. Parece que la ONT sigue enviando solicitudes de consulta ARP a las direcciones IP que mi ISP asignó a SRX. Después de la desaparición de Internet, todavía puedo ver esas solicitudes y respuestas ARP. Creo que este comportamiento indica que la ONT no es la raíz de este problema.

• Cuando Internet se haya ido, los paquetes de solicitud de DHCP no recibirán respuestas al igual que otro tráfico. Intenté renovar mi dirección IP en SRX después de que Internet desapareció pero fallé. Los datos capturados muestran que no hay respuestas desde el lado remoto.

• La renovación de DHCP se realiza correctamente cuando Internet es normal. Cuando publiqué "Solicitar servicio del sistema dhcp cliente renueve vlan.35", puedo ver la solicitud de DHCP y el ACK de DHCP correspondiente.

• (INCORRECTO. Vea el siguiente elemento) Cuando Internet se haya ido, libere el contrato de arrendamiento DHCP actual y solicite uno nuevo para restablecer la conectividad. Traté de liberar el contrato de arrendamiento de DHCP actual y renovarlo, luego SRX obtuvo una nueva dirección IP e Internet volvió. Los datos capturados muestran que aunque un solo paquete de solicitud de DHCP no obtiene respuesta (ver arriba), un paquete de liberación de DHCP produce una respuesta NAK de DHCP . Después de eso, se emite un descubrimiento de DHCP y se obtiene la oferta correcta de DHCP. Entonces vuelve Internet. Sin embargo, cuando intenté repetir este resultado, nada bueno: ni la versión de DHCP ni el descubrimiento de DHCP obtienen respuestas. Emití el comando de liberación y renovación justo después de un comando de renovación. No estoy seguro de que el comportamiento que no responde sea causado por el envío de esos paquetes demasiado rápido o no.

• Después de que Internet se haya ido, emita una solicitud de detección de DHCP y procese como la primera solicitud restablecerá la conexión a Internet. Los datos capturados muestran que cuando Internet desaparece, la emisión de un paquete de solicitud DHCP generará una respuesta NAK DHCP. Combine con el resultado del artículo anterior, emitir tanto la solicitud DHCP como la liberación de DHCP dará como resultado DHCP NAK. Sin embargo, procesar como si fuera la primera vez que solicita una dirección IP del servidor DHCP (envíe el descubrimiento DHCP y luego la solicitud DHCP) obtendrá un resultado positivo y restablecerá el acceso a Internet. ACTUALIZADO: Parece que el NAK no siempre se envía ... a veces, la solicitud / liberación de DHCP se devuelve con DHCP NAK, a veces solo silencio ...

Finalmente resolví este problema. Al capturar y comparar los paquetes DHCP Discover enviados desde JunOS y Cisco, descubrí que Cisco envía el Identificador de cliente de la Opción 64 y el Nombre del host de la Opción 12 de forma predeterminada. Sin embargo, JunOS no los enviará sin instrucciones explícitas.

Creo que mi ISP configura un filtro o algo de su lado. Las dos opciones anteriores son obligatorias. Cuando configuré mi SRX para enviarlos, todo sucedió.

Una cosa que quizás desee confirmar es que el SRX está utilizando un DHCPREQUEST adecuado para renovar la dirección en lugar de otro DHCPDISCOVER.

Aquí se explica cómo habilitar la depuración.

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

Tengo experiencia limitada con Juniper, pero he visto que al menos un sistema operativo principal hace esto cuando el reloj del sistema no era correcto.

Como mínimo, desea ver qué sucede con la renovación.