Compatibilità client SRX DHCP con HP Procurve DHCP Relay

Sto cercando di avviare la configurazione su alcuni Juniper SRX100 e sto riscontrando alcuni problemi DHCP.

In particolare, sto collegando la porta 0/0 (fe-0/0/0 nel software) alla mia rete esistente, dove DHCP ha funzionato in modo abbastanza affidabile per quasi tutti gli altri dispositivi che ho usato. Gli SRX100 non ottengono indirizzi DHCP. L'SRX100 è una configurazione predefinita pronta all'uso quando sto provando questo.

Ho portato uno dei dispositivi a casa mia e l'ho collegato alla mia rete domestica e ho ottenuto un indirizzo IP sulla mia rete domestica tramite DHCP senza problemi.

La mia rete aziendale ha uno switch Procurve 1400 (solo layer 2) sul desktop, collegato a un telefono IP Polycom IP670 (funge da semplice switch layer 2), collegato a uno switch Procurve 3500yl che funge da router per la rete con "ip helper-address 1.1.1.1 "sull'interfaccia vlan che punta al server DHCP per l'inoltro DHCP.

Qualcuno ha qualche esperienza con ottenere un client DHCP SRX ottenere un indirizzo IP tramite Procurve (eseguendo il software K.15.09.0012 ... sebbene il problema si sia verificato su più versioni del firmware su Procurve). Gli SRX100 sembrano avere 11.2 su di loro quando escono dagli schemi, anche se penso che il problema continui ad esistere quando viene aggiornato a 12.1X44-D10.4.

Qualcuno ha qualche suggerimento per la risoluzione di questo? Procurve 3500yl non sembra ammettere di aver visto la richiesta del client DHCP proveniente dall'SRX100, ma le informazioni sulla risoluzione dei problemi su Procurves in quest'area sembrano limitate. Il server DHCP non vede sicuramente alcun pacchetto DHCPDISCOVER in arrivo relativo all'SRX100.

La mia soluzione è stata quella di configurare staticamente un indirizzo IP sugli SRX100 per metterli in rete e fare il resto della mia configurazione, ma il progetto a cui sto lavorando prevede l'invio degli SRX100 in posizioni remote che non sono sotto il mio controllo e, quindi, dipende dal fatto che ottengano in modo affidabile indirizzi DHCP per la connettività, quindi mi piacerebbe davvero risolvere questo problema ed eseguire una causa specifica, quindi so cosa cercare potenzialmente se questo accade in siti remoti.

Aggiornamento: ho (per ricontrollare) l'SRX100 predefinito in fabbrica e l'ho collegato direttamente a una porta su Procurve 3500yl e sto ancora vedendo il problema, in modo da rimuovere il telefono 1400 e IP670 dalla discussione. Ho incluso l'output di tcpdump dall'SRX100 di seguito ... come puoi vedere, il suo invio sul pacchetto DHCP più semplice possibile, quando tende a suggerire che il problema è con la funzione di relè dhcp sul 3500yl. Non riesco a trovare alcun modo per ottenere alcun output di debug dal 3500yl che mostra i pacchetti che colpiscono la funzione dhcp-relay (con successo o meno). I suggerimenti su come eseguire il debug di questa funzione sul 3500yl sarebbero molto apprezzati.

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

Ho aperto un caso con HP relativo a questo problema. Dopo aver superato l'inutile tecnologia di livello 1, la tecnologia di livello 2 ha individuato molto prontamente qualcosa che non avevo.

SRX sta inviando il suo pacchetto DHCPDISCOVER con un TTL di 1. Apparentemente il Procurve decrementerà il TTL e utilizzerà il TTL risultante nel pacchetto inoltrato al server DHCP. In questo caso, il decremento lascia il TTL a 0, il che significa che il pacchetto viene lasciato cadere sul pavimento.

Questo è in realtà nelle specifiche per il relè DHCP / BOOTP, sebbene chiaramente causi una ridotta interoperabilità. Ho chiesto a HPNetworking di considerare questo come un bug / RFE e cambiare il comportamento. Nessuna risposta immediata a tale richiesta nel caso.

L'SRX che invia DHCPDISCOVER con un TTL di 1 è probabilmente anche all'interno delle specifiche, ma, ancora una volta, una scelta di interoperabilità ridotta, quindi ho intenzione di aprire un caso con JTAC sulla stessa base.

Aggiungerò ulteriori informazioni sulla risposta di Juniper e HP non appena saranno disponibili.

Per inciso, ho testato il comportamento del relè di un Cisco 4506 (versione del firmware non immediatamente disponibile) e un FastIron Edge X di Brocade / Foundry (firmware 7.2 o 7.3, credo, non hanno accesso immediato per confermare) ed entrambi gestiscono inoltro della richiesta con TTL 1 senza problemi.

AGGIORNAMENTO C'è un modo per cambiare il valore TTL che SRX utilizza nelle sue richieste DHCP, ma non è all'interno del client JunOS ... è fatto dal sistema operativo Unix sottostante.

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

Ho aperto una RFE con HP per rendere la loro funzione di inoltro più resiliente, ma non ho ancora una risposta da parte loro su se / quando ciò funzionerà.

Può essere difficile risolvere i problemi quando non sai dove si trova il problema e hai tre dispositivi di tre fornitori prima che sembri avere alcuna visibilità (SRX100, 1400 e IP670). Non posso parlare con i dispositivi specifici, ma non puoi mai sbagliare tracciando i pacchetti. Poiché ProCurve 1400 è un dispositivo non gestito, è necessario utilizzare un tocco di rete.

Si desidera acquisire il traffico nelle seguenti posizioni (in base alla propria affermazione che il 3500yl non sta ricevendo il pacchetto di rilevamento):

• Tra SRX100 e 1400.
• Tra il 1400 e l'IP670
• Tra IP670 e 3500yl

Puoi fare tutto ciò dalla tua scrivania e, mentre un tocco interrompe la connessione / disconnessione, dovrebbe interessare solo te e i tuoi dispositivi.

Vorrei iniziare in cima a questo elenco, perché dovrebbe consentire di acquisire il pacchetto di rilevamento DHCP almeno una volta e quindi eventuali acquisizioni successive del pacchetto di rilevamento DHCP possono essere confrontate con questo per vedere se vi sono modifiche.

È inoltre possibile acquisire pacchetti di rilevamento DHCP da dispositivi che funzionano anche per verificare se vi sono differenze rispetto al pacchetto di rilevamento inviato dall'SRX100.

Una volta che sai dove il pacchetto va storto, puoi esaminare specificamente la risoluzione dei problemi perché a quel punto va storto.

Sebbene hai testato SRX altrove:

1. SRX ottiene a casa un indirizzo con la stessa configurazione ?
   • Ciò dovrebbe significare che i seguenti non sono problemi:
   • set security zones security-zone host-inbound-traffic system-services dhcp è stato fatto
   • Configurazione dell'interfaccia di base eseguita (interfaccia grezza, tag vlan, interfaccia in vlan corretta, che vlan in
2. L'interfaccia in realtà si presenta in modo pulito sul lato Juniper?
   • show interfaces fe-0/0/0 extensive È tuo amico
   • (So ​​che non è appropriato per questo, ma comunque ...) Per le interfacce ottiche, controlla anche i livelli di potenza: show interfaces diagnostics optics ge-0/0/0
3. Aggiungi una traccia al client DHCP:

configure
imposta i servizi di sistema dhcp traceoptions file dhcp_client.log leggibile in tutto il mondo
impostare i servizi di sistema dhcp traceoptions client client
imposta tutti i servizi di sistema dhcp traceoptions a livello di tutti
commit e-esci

Quindi monitorare il registro mentre si apre l'interfaccia monitor start dhcp_client.log. (Ricorda di eliminare la traceoption al termine)