Compatibilité du client DHCP SRX avec le relais DHCP HP Procurve

J'essaie d'amorcer la configuration sur certains Juniper SRX100 et j'ai des problèmes DHCP.

Plus précisément, je connecte le port 0/0 (fe-0/0/0 dans le logiciel) à mon réseau existant, où DHCP a fonctionné de manière assez fiable pour à peu près tous les autres appareils que j'ai utilisés. Les SRX100 n'obtiennent pas d'adresses DHCP. Le SRX100 est une configuration par défaut prête à l'emploi lorsque j'essaye.

J'ai amené l'un des appareils chez moi et je l'ai branché sur mon réseau domestique et il a obtenu une adresse IP sur mon réseau domestique via DHCP sans aucun problème.

Mon réseau de bureau dispose d'un commutateur Procurve 1400 (couche 2 uniquement) sur mon bureau, relié à un téléphone IP Polycom IP670 (agit comme un simple commutateur de couche 2), relié à un commutateur Procurve 3500yl faisant office de routeur pour le réseau avec "ip helper-address 1.1.1.1 "sur l'interface vlan pointant vers le serveur DHCP pour le relais DHCP.

Quelqu'un a-t-il une expérience avec l'obtention d'un client DHCP SRX obtenant une adresse IP via un Procurve (exécutant le logiciel K.15.09.0012 ... bien que le problème existe sur plusieurs versions de firmware sur le Procurve). Les SRX100 semblent avoir 11,2 sur eux lorsqu'ils sortent de la boîte, bien que je pense que le problème continue d'exister lors de la mise à niveau vers 12.1X44-D10.4.

Quelqu'un at-il des suggestions pour résoudre ce problème? Le Procurve 3500yl ne semble pas admettre avoir vu la demande du client DHCP provenant du SRX100, mais les informations de dépannage sur les Procurves dans ce domaine semblent limitées. Le serveur DHCP ne voit définitivement aucun paquet DHCPDISCOVER arriver concernant le SRX100.

Ma solution de contournement a été de configurer statiquement une adresse IP sur les SRX100 pour les obtenir sur le réseau et de faire le reste de ma configuration, mais le projet sur lequel je travaille consiste à envoyer les SRX100 vers des emplacements distants qui ne sont pas sous mon contrôle et, par conséquent, cela dépend d'eux pour obtenir de manière fiable des adresses DHCP pour la connectivité, donc je voudrais vraiment résoudre ce problème et exécuter une cause spécifique afin que je sache quoi chercher potentiellement si cela se produit sur des sites distants.

Mise à jour: j'ai (pour vérifier) ​​le SRX100 par défaut et l'ai branché directement sur un port sur un Procurve 3500yl et je vois toujours le problème, ce qui supprime le 1400 et le téléphone IP670 de la discussion. J'ai inclus la sortie tcpdump du SRX100 ci-dessous ... comme vous pouvez le voir, son envoi sur le paquet DHCP le plus simple possible, quand a tendance à suggérer que le problème est avec la fonction relais DHCP sur le 3500yl. Je ne trouve aucun moyen d'obtenir une sortie de débogage du 3500yl montrant des paquets atteignant la fonction dhcp-relay (avec succès ou autrement). Des suggestions sur la façon de déboguer cette fonction sur le 3500yl seraient grandement appréciées.

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

J'ai ouvert un dossier avec HP concernant ce problème. Après avoir escaladé la technologie inutile de niveau 1, la technologie de niveau 2 a repéré très vivement quelque chose que je n'avais pas.

Le SRX envoie son paquet DHCPDISCOVER avec un TTL de 1. Apparemment, le Procurve décrémente le TTL et utilise le TTL résultant dans le paquet relayé au serveur DHCP. Dans ce cas, la décrémentation laisse le TTL à 0, ce qui signifie que le paquet est déposé sur le sol.

Il s'agit en fait de spécifications pour le relais DHCP / BOOTP, bien que cela entraîne clairement une interopérabilité réduite. J'ai demandé à HPNetworking de traiter cela comme un bogue / RFE et de changer le comportement. Aucune réponse immédiate à cette demande dans l'affaire.

Le SRX envoyant le DHCPDISCOVER avec un TTL de 1 est également probablement conforme aux spécifications, mais, encore une fois, un choix d'interopérabilité réduite, donc je prévois d'ouvrir un boîtier avec JTAC sur la même base.

J'ajouterai plus d'informations sur la réponse de Juniper et HP dès qu'elle sera disponible.

Soit dit en passant, j'ai testé le comportement de relais d'un Cisco 4506 (la version du micrologiciel n'est pas immédiatement disponible), et un Brocade / Foundry FastIron Edge X (le micrologiciel 7.2 ou 7.3, je crois, n'ont pas un accès immédiat pour confirmer) et ils gèrent tous les deux relayer la demande avec TTL 1 sans problème.

MISE À JOUR Il existe un moyen de modifier la valeur TTL que le SRX utilise sur ses requêtes DHCP, mais ce n'est pas à partir du cli JunOS ... c'est fait à partir du système d'exploitation Unix sous-jacent.

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

J'ai ouvert un RFE avec HP pour rendre leur fonction de relais plus résistante, mais pas encore de réponse d'eux si / quand cela sera travaillé.

Il peut être difficile de dépanner lorsque vous ne savez pas où réside le problème et que vous disposez de trois appareils de trois fournisseurs avant de sembler avoir une visibilité (le SRX100, le 1400 et l'IP670). Je ne peux pas parler des appareils spécifiques, mais vous ne pouvez jamais vous tromper en traçant les paquets. Étant donné que le ProCurve 1400 est un appareil non géré, vous devez utiliser une prise réseau.

Vous souhaitez capturer le trafic dans les emplacements suivants (en fonction de votre déclaration selon laquelle le 3500yl ne reçoit pas le paquet de découverte):

• Entre le SRX100 et le 1400.
• Entre le 1400 et l'IP670
• Entre l'IP670 et le 3500yl

Vous pouvez faire tout cela depuis votre bureau, et même si un robinet est perturbateur pendant que vous le connectez / déconnectez, cela ne devrait affecter que vous et vos appareils.

Je commencerais en haut de cette liste, car cela devrait vous permettre de capturer le paquet de découverte DHCP au moins une fois, puis toutes les captures ultérieures du paquet de découverte DHCP peuvent être comparées à celle-ci pour voir s'il y a une modification.

Vous pouvez également vouloir capturer les paquets de découverte DHCP à partir d'appareils qui fonctionnent également pour voir s'il y a des différences par rapport au paquet de découverte que le SRX100 envoie.

Une fois que vous savez où le paquet va mal, vous pouvez rechercher spécifiquement comment résoudre le problème à ce stade.

Bien que vous ayez testé le SRX ailleurs:

1. Le SRX obtient-il une adresse avec exactement la même configuration à la maison?
   • Cela devrait signifier que ce ne sont pas des problèmes:
   • set security zones security-zone host-inbound-traffic system-services dhcp a été fait
   • Configuration de l'interface de base effectuée (soit interface brute, balises vlan, interface dans le vlan correct, ce vlan dans
2. L'interface est-elle vraiment nette du côté Juniper?
   • show interfaces fe-0/0/0 extensive est votre ami
   • (Je sais que ce n'est pas approprié pour cela, mais quand même ...) Pour les interfaces optiques, vérifiez également les niveaux de puissance: show interfaces diagnostics optics ge-0/0/0
3. Ajoutez une trace au client DHCP:

configurer
définir les services système fichier dhcp traceoptions dhcp_client.log lisible par le monde
définir les services système dhcp traceoptions indicateur client
définir les services système dhcp traceoptions niveau tout
valider et quitter

Ensuite, surveillez le journal lorsque vous ouvrez l'interface avec monitor start dhcp_client.log. (N'oubliez pas de supprimer l'option trace une fois que vous avez terminé)