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