Compatibilidad del cliente SRX DHCP con HP Procurve DHCP Relay

Estoy tratando de arrancar la configuración en algunos Juniper SRX100 y tengo algunos problemas de DHCP.

Específicamente, estoy conectando el puerto 0/0 (fe-0/0/0 en el software) a mi red existente, donde DHCP ha funcionado de manera bastante confiable para casi todos los demás dispositivos que he usado. Los SRX100 no obtienen direcciones DHCP. El SRX100 es una configuración predeterminada lista para usar cuando intento esto.

Traje uno de los dispositivos a mi casa y lo conecté a mi red doméstica y obtuve una dirección IP en mi red doméstica a través de DHCP sin problemas.

La red de mi oficina tiene un conmutador Procurve 1400 (solo capa 2) en mi escritorio, conectado a un teléfono IP Polycom IP670 (actúa como un simple conmutador de capa 2), conectado a un conmutador Procurve 3500yl que actúa como un enrutador para la red con "ip helper-address 1.1.1.1 "en la interfaz vlan que apunta al servidor DHCP para la retransmisión DHCP.

¿Alguien tiene alguna experiencia para obtener un cliente SRX DHCP que obtenga una dirección IP a través de un Procurve (ejecutando el software K.15.09.0012 ... aunque el problema ha existido en varias versiones de firmware en el Procurve). Los SRX100 parecen tener 11.2 cuando salen de la caja, aunque creo que el problema sigue existiendo cuando se actualiza a 12.1X44-D10.4.

¿Alguien tiene alguna sugerencia para solucionar este problema? El Procurve 3500yl no parece admitir haber visto la solicitud del cliente DHCP proveniente del SRX100, pero la información de resolución de problemas de los Procurves en esta área parece limitada. El servidor DHCP definitivamente no ve que lleguen paquetes DHCPDISCOVER relacionados con el SRX100.

Mi solución ha sido configurar estáticamente una dirección IP en los SRX100 para conectarlos a la red y hacer el resto de mi configuración, pero el proyecto en el que estoy trabajando implica enviar los SRX100 a ubicaciones remotas que no están bajo mi control y, por lo tanto, depende de que obtengan de manera confiable direcciones DHCP para la conectividad, por lo que realmente me gustaría solucionar este problema y analizar una causa específica para saber qué buscar potencialmente si esto sucede en sitios remotos.

Actualización: Tengo (para verificar) el valor predeterminado de fábrica del SRX100, y lo conecté directamente a un puerto en un Procurve 3500yl y todavía veo el problema, por lo que elimina el 1400 y el teléfono IP670 de la discusión. Incluí la salida tcpdump del SRX100 a continuación ... como puede ver, se está enviando sobre el paquete DHCP más simple posible, cuando tiende a sugerir que el problema es con la función dhcp-relay en el 3500yl. No puedo encontrar ninguna manera de obtener ninguna salida de depuración del 3500yl que muestre paquetes que lleguen a la función dhcp-relay (con éxito o no). Se agradecerán mucho las sugerencias sobre cómo depurar esta función en el 3500yl.

tcpdump -n -s 0 -c 1 -vvv -r juniper.dhcp.pcap 
reading from file juniper.dhcp.pcap, link-type JUNIPER_ETHER (Juniper Ethernet)
17:49:11.538670 
Juniper PCAP Flags [Ext], PCAP Extension(s) total length 16
  Device Media Type Extension TLV #3, length 1, value Ethernet (1)
  Logical Interface Encapsulation Extension TLV #6, length 1, value Ethernet (14)
  Device Interface Index Extension TLV #1, length 2, value 34304
  Logical Interface Index Extension TLV #4, length 4, value 70
-----original packet-----
IP (tos 0x0, ttl 1, id 13874, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from a8:d0:e5:1c:68:80, length 300, xid 0x643c9869, Flags [Broadcast] (0x8000)
  Client-Ethernet-Address a8:d0:e5:1c:68:80
  Vendor-rfc1048 Extensions
    Magic Cookie 0x63825363
    DHCP-Message Option 53, length 1: Discover
    END Option 255, length 0
    PAD Option 0, length 0, occurs 56

Abrí un caso con HP con respecto a este problema. Después de escalar más allá de la tecnología inútil de Nivel 1, la tecnología de Nivel 2 detectó muy alerta algo que yo no tenía.

El SRX está enviando su paquete DHCPDISCOVER con un TTL de 1. El Procurve aparentemente disminuirá el TTL y usará el TTL resultante en el paquete retransmitido al servidor DHCP. En este caso, la disminución deja el TTL en 0, lo que significa que el paquete se cae al suelo.

En realidad, esto está en las especificaciones para el relé DHCP / BOOTP, aunque claramente causa una interoperabilidad reducida. Le he pedido a HPNetworking que trate esto como un error / RFE y cambie el comportamiento. No hay respuesta inmediata a esa solicitud en el caso.

El SRX que envía el DHCPDISCOVER con un TTL de 1 también está probablemente dentro de las especificaciones, pero, una vez más, una opción de interoperabilidad reducida, por lo que planeo abrir un caso con JTAC sobre la misma base.

Agregaré más información sobre la respuesta de Juniper y HP a medida que esté disponible.

Por cierto, he probado el comportamiento del relé de un Cisco 4506 (la versión de firmware no está disponible de inmediato) y un Brocade / Foundry FastIron Edge X (creo que el firmware 7.2 o 7.3 no tiene acceso inmediato para confirmar) y ambos manejan retransmitir la solicitud con TTL 1 sin problema.

ACTUALIZACIÓN Hay una manera de cambiar el valor TTL que utiliza el SRX en sus solicitudes DHCP, pero no desde el cli de JunOS ... se realiza desde el sistema operativo Unix subyacente.

root@% sysctl -w net.inet.ip.mcast_ttl=64

Abrí un RFE con HP para hacer que su función de retransmisión sea más resistente, pero aún no hay respuesta de ellos sobre si / cuándo se trabajará.

Puede ser difícil solucionar problemas cuando no sabe dónde está el problema y tiene tres dispositivos de tres proveedores antes de que parezca tener alguna visibilidad (el SRX100, el 1400 y el IP670). No puedo hablar con los dispositivos específicos, pero nunca puedes equivocarte al rastrear los paquetes. Como el ProCurve 1400 es un dispositivo no administrado, necesitaría usar un tap de red.

Desea capturar el tráfico en las siguientes ubicaciones (según su declaración de que el 3500yl no recibe el paquete de descubrimiento):

• Entre el SRX100 y el 1400.
• Entre el 1400 y el IP670
• Entre el IP670 y el 3500yl

Puede hacer todo esto desde su escritorio, y aunque un toque es perjudicial mientras lo conecta / desconecta, solo debería afectarlo a usted y a sus dispositivos.

Comenzaría en la parte superior de esta lista, ya que debería permitirle capturar el paquete de descubrimiento de DHCP al menos una vez y luego cualquier captura posterior del paquete de descubrimiento de DHCP se puede comparar con esta para ver si hay alguna modificación.

También es posible que desee capturar paquetes de descubrimiento DHCP de dispositivos que también funcionan para ver si hay alguna diferencia con respecto al paquete de descubrimiento que envía el SRX100.

Una vez que sepa dónde sale mal el paquete, puede buscar específicamente la solución de problemas por qué sale mal en ese punto.

Aunque ha probado el SRX en otro lugar:

1. ¿El SRX obtiene una dirección con exactamente la misma configuración en casa?
   • Esto debería significar que los siguientes no son problemas:
   • set security zones security-zone host-inbound-traffic system-services dhcp se ha hecho
   • Configuración de interfaz básica realizada (ya sea interfaz sin procesar, etiquetas de vlan, interfaz en vlan correcto, ese vlan en
2. ¿La interfaz realmente aparece limpiamente en el lado de Juniper?
   • show interfaces fe-0/0/0 extensive es tu amigo
   • (Sé que no es apropiado para esto, pero aún así ...) Para las interfaces ópticas también verifique los niveles de potencia: show interfaces diagnostics optics ge-0/0/0
3. Agregue un seguimiento al cliente DHCP:

configurar
establecer los servicios del sistema dhcp traceoptions archivo dhcp_client.log legible por el mundo
establecer los servicios del sistema dhcp traceoptions flag client
establecer los servicios de sistema dhcp traceoptions nivel todos
comprometerse y dejar de fumar

Luego, controle el registro a medida que abre la interfaz con monitor start dhcp_client.log. (Recuerde eliminar la opción de rastreo una vez que haya terminado)