SRX DHCP-Client-Kompatibilität mit HP Procurve DHCP Relay

Ich versuche, die Konfiguration auf einigen Juniper SRX100s zu booten, und habe einige DHCP-Probleme.

Insbesondere verbinde ich den 0/0-Port (z. B. 0: 0/0 in der Software) mit meinem vorhandenen Netzwerk, in dem DHCP für nahezu jedes andere Gerät, das ich verwendet habe, ziemlich zuverlässig funktioniert hat. Die SRX100 erhalten keine DHCP-Adressen. Der SRX100 ist eine sofort einsatzbereite Standardkonfiguration, wenn ich dies versuche.

Ich brachte eines der Geräte zu mir nach Hause und steckte es in mein Heimnetzwerk. Es erhielt problemlos eine IP-Adresse in meinem Heimnetzwerk über DHCP.

In meinem Büronetzwerk befindet sich auf meinem Desktop ein Procurve 1400-Switch (nur Layer 2), der mit einem Polycom IP670 IP-Telefon (fungiert als einfacher Layer 2-Switch) verbunden ist und mit einem Procurve 3500yl-Switch verbunden ist, der als Router für das Netzwerk mit "ip" fungiert Hilfsadresse 1.1.1.1 "auf der vlan-Schnittstelle, die auf den DHCP-Server für DHCP-Relay verweist.

Hat jemand Erfahrung damit, dass ein SRX-DHCP-Client über eine Procurve eine IP-Adresse erhält (mit der Software K.15.09.0012 ... obwohl das Problem bei mehreren Firmware-Versionen auf der Procurve aufgetreten ist)? Die SRX100s scheinen 11.2 zu haben, wenn sie aus der Box kommen, obwohl ich denke, dass das Problem weiterhin besteht, wenn sie auf 12.1X44-D10.4 aktualisiert werden.

Hat jemand Vorschläge zur Fehlerbehebung? Der Procurve 3500yl scheint nicht zuzugeben, dass die DHCP-Client-Anfrage vom SRX100 eingegangen ist, aber die Informationen zur Fehlerbehebung bei den Procurves in diesem Bereich scheinen begrenzt zu sein. Der DHCP-Server sieht definitiv keine DHCPDISCOVER-Pakete, die sich auf den SRX100 beziehen.

Meine Problemumgehung bestand darin, eine IP-Adresse auf den SRX100 statisch zu konfigurieren, um sie in das Netzwerk zu übertragen und den Rest meiner Konfiguration durchzuführen. Das Projekt, an dem ich arbeite, umfasst jedoch das Senden der SRX100 an entfernte Standorte, die nicht unter meiner Kontrolle stehen, und Daher hängt es davon ab, ob sie zuverlässig DHCP-Adressen für die Konnektivität erhalten. Daher möchte ich dieses Problem unbedingt beheben und eine bestimmte Ursache ermitteln, damit ich weiß, wonach ich möglicherweise suchen muss, wenn dies an Remotestandorten geschieht.

Update: Ich habe den SRX100 (zur Überprüfung) auf die Werkseinstellungen eingestellt und ihn direkt an einen Port eines Procurve 3500yl angeschlossen. Das Problem wird weiterhin angezeigt, sodass das 1400- und das IP670-Telefon aus der Diskussion entfernt werden. Ich habe die tcpdump-Ausgabe des SRX100 unten aufgeführt ... wie Sie sehen können, wird das einfachste mögliche DHCP-Paket gesendet, wenn das Problem auf die DHCP-Relay-Funktion des 3500yl zurückzuführen ist. Ich kann keine Möglichkeit finden, eine Debug-Ausgabe vom 3500yl zu erhalten, die Pakete zeigt, die die DHCP-Relay-Funktion treffen (erfolgreich oder auf andere Weise). Vorschläge zum Debuggen dieser Funktion auf dem 3500yl sind sehr willkommen.

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

Ich habe mit HP einen Fall zu diesem Thema eröffnet. Nachdem ich an der nutzlosen Level 1-Technologie vorbeigekommen war, entdeckte die Level 2-Technologie sehr aufmerksam etwas, was ich nicht hatte.

Der SRX sendet sein DHCPDISCOVER-Paket mit einer TTL von 1. Die Procurve dekrementiert anscheinend die TTL und verwendet die resultierende TTL im weitergeleiteten Paket an den DHCP-Server. In diesem Fall belässt das Dekrement die TTL bei 0, was bedeutet, dass das Paket auf den Boden fallen gelassen wird.

Dies ist tatsächlich in der Spezifikation für DHCP / BOOTP-Relais vorgesehen, führt jedoch eindeutig zu einer verringerten Interoperabilität. Ich habe HPNetworking gebeten, dies als Fehler / RFE zu behandeln und das Verhalten zu ändern. Keine sofortige Antwort auf diese Anfrage in dem Fall.

Der SRX, der den DHCPDISCOVER mit einer TTL von 1 sendet, liegt wahrscheinlich ebenfalls innerhalb der Spezifikation, aber auch hier besteht die Wahl einer reduzierten Interoperabilität. Daher plane ich, auf derselben Basis einen Fall mit JTAC zu eröffnen.

Ich werde weitere Informationen zur Reaktion von Juniper und HP hinzufügen, sobald diese verfügbar sind.

Im Übrigen habe ich das Relaisverhalten eines Cisco 4506 (Firmware-Version nicht sofort verfügbar) und einer Brocade / Foundry FastIron Edge X-Firmware (7.2 oder 7.3, glaube ich, haben keinen sofortigen Zugriff zur Bestätigung) getestet, und beide verarbeiten Weiterleiten der Anfrage mit TTL 1 ohne Probleme.

UPDATE Es gibt eine Möglichkeit, den TTL-Wert zu ändern, den der SRX für seine DHCP-Anforderungen verwendet, jedoch nicht innerhalb der JunOS-Cli ... sondern über das zugrunde liegende Unix-Betriebssystem.

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

Ich habe eine RFE mit HP eröffnet, um deren Weiterleitungsfunktion widerstandsfähiger zu machen, aber noch keine Antwort von ihnen, ob / wann daran gearbeitet wird.

Es kann schwierig sein, Fehler zu beheben, wenn Sie nicht wissen, wo das Problem liegt, und wenn Sie drei Geräte von drei Anbietern haben, bevor Sie scheinbar sichtbar sind (SRX100, 1400 und IP670). Ich kann nicht mit den spezifischen Geräten sprechen, aber Sie können niemals etwas falsch machen, indem Sie die Pakete verfolgen. Da es sich bei ProCurve 1400 um ein nicht verwaltetes Gerät handelt, müssen Sie einen Netzwerk-Tap verwenden.

Sie möchten den Datenverkehr an den folgenden Orten erfassen (basierend auf Ihrer Aussage, dass der 3500yl das Erkennungspaket nicht empfängt):

• Zwischen dem SRX100 und dem 1400.
• Zwischen dem 1400 und dem IP670
• Zwischen dem IP670 und dem 3500yl

Sie können all dies von Ihrem Schreibtisch aus tun, und während ein Tippen während des Verbindens / Trennens störend ist, sollte es nur Sie und Ihre Geräte betreffen.

Ich würde am Anfang dieser Liste beginnen, da es Ihnen ermöglichen sollte, das DHCP-Erkennungspaket mindestens einmal zu erfassen, und dann können alle nachfolgenden Erfassungen des DHCP-Erkennungspakets mit diesem verglichen werden, um festzustellen, ob Änderungen vorgenommen wurden.

Möglicherweise möchten Sie auch DHCP-Erkennungspakete von Geräten erfassen, die ebenfalls funktionieren, um festzustellen, ob es Unterschiede zu dem vom SRX100 gesendeten Erkennungspaket gibt.

Sobald Sie wissen, wo das Paket schief geht, können Sie sich speziell mit der Fehlerbehebung befassen, warum es an diesem Punkt schief geht.

Obwohl Sie den SRX an anderer Stelle getestet haben:

1. Bekommt der SRX zu Hause eine Adresse mit genau der gleichen Konfiguration ?
   • Dies sollte bedeuten, dass Folgendes keine Probleme sind:
   • set security zones security-zone host-inbound-traffic system-services dhcp wurde getan
   • Grundlegende Schnittstellenkonfiguration abgeschlossen (entweder Raw-Schnittstelle, VLAN-Tags, Schnittstelle im richtigen VLAN, das VLAN in
2. Wird die Schnittstelle auf der Juniper-Seite tatsächlich sauber angezeigt?
   • show interfaces fe-0/0/0 extensive ist dein Freund
   • (Ich weiß, dass dies nicht angemessen ist, aber dennoch ...) Überprüfen Sie bei optischen Schnittstellen auch die Leistungsstufen: show interfaces diagnostics optics ge-0/0/0
3. Fügen Sie dem DHCP-Client eine Ablaufverfolgung hinzu:

konfigurieren
set system services dhcp traceoptions datei dhcp_client.log weltlesbar
Setze System Services DHCP Traceoptions Flag Client
Setze System Services DHCP Traceoptions Level alle
festschreiben und beenden

Überwachen Sie dann das Protokoll, während Sie die Schnittstelle mit aufrufen monitor start dhcp_client.log. (Denken Sie daran, die Traceoption zu löschen, wenn Sie fertig sind.)