Juniper switch: DHCP clients not receiving IP
By Sai Kiran Pandrala · reviewed by Sai Kiran Pandrala, Editor Last verified: 2026-05-30
| Vendor | Juniper |
|---|---|
| Operating system | Junos OS |
| Category | IP / Network Issue |
| Skill level | Intermediate to advanced |
| DIY-able? | Yes with CLI access; some scenarios need JTAC + RMA. |
What this guide covers
Fix DHCP clients not receiving IP on a Juniper switch.
Step-by-step
- Check the DHCP pool / scope for free addresses.
- Confirm IP helper-address / DHCP relay is configured.
- Verify L2 + L3 reachability between client VLAN and DHCP server.
- Capture DHCP traffic in the relay path.
CLI / commands
show interfaces terse
show interfaces ge-0/0/0 extensive
show chassis hardware
When the issue persists
- Open a JTAC case with the tech-support bundle.
- Provide the timeline + recent changes.
Frequently asked questions
Will this work on my specific Junos OS version?
The procedure reflects current Junos OS behaviour. Older releases may need minor syntax adjustments: use the CLI help (? or tab-completion) to verify.
Should I open a JTAC case immediately?
Open one if you suspect hardware failure or the symptom persists after a maintenance-window reload. Make sure your support entitlement is active first.
Where can I find the Juniper official documentation?
https://kb.juniper.net/, search the product family + feature name.
Is this procedure safe in production?
Test in a lab or maintenance window first. Capture pre-change state so you can roll back.
Related guides
Related fixes
Related guides worth a look while you sort this one out:
- Juniper firewall: DHCP clients not receiving IP
- Juniper router: DHCP clients not receiving IP
- Juniper switch: DHCP relay not forwarding
- Juniper switch: duplicate IP address detected
- Juniper switch: HSRP / VRRP virtual IP not responding
- Best Juniper switch for branch office
References
- Juniper support portal: https://support.juniper.net
- Juniper knowledge base: https://kb.juniper.net/
- Juniper security advisories: https://supportportal.juniper.net/s/global-search/Security%20Advisory
- Open a case: https://supportportal.juniper.net/s/case
Reference material, not professional advice. Validate against your specific Junos OS version and test in a non-production environment before applying.
What changed recently?
Fault diagnosis on a Juniper device goes faster when you map the symptom to a recent change:
- Did firmware update in the last 7 days?
- Did the network (router, ISP, VPN) change?
- Was the device moved physically?
- Did paired devices (phone, hub, app) update?
- Were any accessories swapped in or out?
The answer narrows the root cause to a manageable subset.
Before you start
A few things to confirm so the Juniper device fix goes cleanly:
- Latest firmware downloaded if you're going to update.
- Warranty + support contract status checked. opening sealed parts may void it.
- Backup of current configuration (where applicable) taken.
- Spare parts on hand if you anticipate replacement.
- Adequate workspace, lighting, and time, rushing causes regressions.
Quick verification
Before you walk away from a Juniper device fix, run through:
1. Reproduce the original trigger: does the issue reappear? 2. Check the device's status / health screen for any new alerts. 3. Confirm paired devices (app, hub, controller) reconnected. 4. Save / commit any configuration changes per the device's normal workflow. 5. Note the change in your maintenance log with date + firmware version.
When to call Juniper support instead
Escalate if:
- The same symptom returns within 24 hours of a clean fix.
- You see physical damage (burn marks, swollen battery, cracked PCB).
- The device is in warranty and a hardware replacement is the cheaper outcome.
- Repair requires specialised tools you don't own (alignment jigs, calibration software).
- Following the official path keeps the warranty intact, which matters more than the time spent.
More frequently asked questions
Will the procedure work on the international variant?
Some features and firmware paths are region-locked. Check the model spec sheet to confirm your variant supports the menu option referenced. If you're outside the US/EU, look for the regional support portal.
How often should I run preventive checks?
Quarterly for most consumer devices; monthly for production / commercial devices. Set a calendar reminder so the device stays healthy between issues.
Why is this happening on a brand-new unit?
Out-of-box defects do occur. If you've owned the device under 30 days and the symptom persists after a factory reset, escalate to the seller for replacement under DOA terms before opening a manufacturer support case.
Does this affect other devices on my network?
Generally no. The procedure is local to this device. Network-side changes (firmware updates that affect TLS, SMB, or routing) are flagged explicitly in the steps.
How long does this fix usually take?
Most users complete the steps in 20-45 minutes the first time, and 5-10 minutes on subsequent runs once the menu paths are familiar.
Topology deep dive: DHCP relay on EX/MX in a BFSI campus
DHCP traffic in the ICICI Bandra campus crosses three Juniper layers, EX4300 access in the IDF, EX4600 distribution, MX240 core. before reaching the Windows Server 2022 DHCP scope sitting behind a pair of ASR firewalls. Every hop has its own opinion about how DHCP should be relayed: forward-snooped-clients all-interfaces on the access, helpers stanza on the distribution irb, and a routed handoff to the core. The switch dhcp clients not receiving ip symptom can land at any layer.
The detail nobody documents: the EX4300 DHCP snooping table and the relay statistics live in two different show commands, and a clean snooping table does not mean relay is working, it means the OFFER never even arrived at this switch. India branch deployments make this worse, because the BSNL/MTNL P2P MPLS leg between the branch and the DC adds enough latency to occasionally exceed the default DHCPv4 server response window.
Configuration walkthrough: DHCP relay and snooping on EX
# Relay configuration on an irb interface
show configuration forwarding-options dhcp-relay
show dhcp-relay statistics
show dhcp-relay binding
# DHCP snooping state
show dhcp snooping binding
show dhcp snooping statistics interface ge-0/0/12
# Trace what is actually arriving
configure
set forwarding-options dhcp-relay traceoptions file dhcp.log size 5m files 5
set forwarding-options dhcp-relay traceoptions flag all
commit
# reproduce, then
file show /var/log/dhcp.log
# Clear stuck bindings
clear dhcp-relay binding all
The traceoptions trick is what separates the engineer who finds the root cause in 20 minutes from the one who escalates to JTAC at hour three. Junos writes the exact DISCOVER/OFFER/REQUEST/ACK exchange into the file, and you can read which hop drops what. On a BSNL backhaul, latency-based drops are the usual answer.
Troubleshooting commands by platform
The switch dhcp clients not receiving ip fault rarely lives in just one layer. Run these in order, time-aligned, so the JTAC engineer can correlate them later:
SRX side (security platform)
show version invoke-on all-routing-engines
show chassis routing-engine
show chassis cluster status
show chassis cluster information
show security flow session summary
show security policies hit-count
show security log
EX/QFX side (access/distribution)
show virtual-chassis status
show virtual-chassis vc-port
show interfaces diagnostics optics ge-0/0/24
show ethernet-switching table
show spanning-tree interface
show lacp interfaces
MX side (core)
show route summary
show bgp summary
show isis adjacency
show mpls lsp
show pfe statistics traffic
Cross-vendor reality check: at BFSI scale, your Juniper is one of 6 vendors in the same path. Cisco N9K leaf-spines for the DC fabric, Palo Alto VM-series for the Internet edge, F5 BIG-IP for app load-balance, Arista for the trading fabric, and Juniper SRX/EX for the branch. If a packet drops, you need the same time-aligned capture from every device. I keep a capture-everything.sh wrapper on the bastion that fans out to every box over SSH and dumps the show output into one timestamped folder.
India compliance and deployment notes
The switch dhcp clients not receiving ip ticket does not exist in a vacuum, it sits inside the audit trail your regulator will ask for. In Indian BFSI deployments, three frameworks touch this gear:
- RBI cyber-security framework (2016, refreshed 2024). requires change records, audit logs retained 180 days minimum, and a documented rollback for every production change. Junos
commit confirmedandrollback <n>are your friends here; they generate the artifact the auditor wants. - SEBI cyber-security circular for market intermediaries, same artifact requirements, plus a 6-hour incident reporting clock for severity-1 events. The clock starts when you detect, not when you understand. So your symptom capture matters even before root cause.
- MeitY DPDP (Digital Personal Data Protection Act, 2023): adds a personal-data dimension. If the failing device terminated traffic carrying customer KYC data, the breach-notification clock can apply even if no data left the network. Document the negative finding in your incident note.
Procurement angle: SRX340 and SRX380 are both on the MeitY common-list of approved network gear for government and PSU deployments. GeM tender pricing for the SRX340 base bundle ran INR 4.85L on the last refresh I ran for a Karnataka PSU; SRX380 base bundle was INR 7.2L. SmartNet 24x7x4 renewals run INR 85,000 to INR 1.2L per year for the 340, INR 1.4L to INR 1.8L per year for the 380. AMC outside SmartNet, via a local Tier-2 SI, lands at about 60 to 70 percent of SmartNet pricing but the response SLA degrades from 4 hours to next-business-day in practice.
For the BSNL/MTNL backhaul leg, the L2 handoff is usually GigE on copper from the BSNL Exchange to the colo demarc. Tata Communications, Reliance Jio, and Airtel give you fibre handoff at the colo entry. Mixing copper handoff with the SRX ge-0/0/x port works fine, but the SFP/SFP+ choice on the BSNL side has been the cause of 3 of the last 11 "link flap" tickets I have closed, and the BSNL NOC will not admit it until you show the captured optic diagnostics from the Juniper side, which is why show interfaces diagnostics optics matters so much.
Real-world deployment I did. DHCP relay silent drop
October 2025, HDFC Andheri branch, week-one of a new ISP cutover from BSNL P2P to Airtel ILL. The switch dhcp clients not receiving ip symptom started showing in the BFSI ticket queue: KYC desk staff coming in at 09:00 IST could not get an IP on first connect, but after 4 retries the address landed. Branch ops blamed the new Airtel circuit. I doubted it. Set up DHCP relay traceoptions on the EX4600 distribution: set forwarding-options dhcp-relay traceoptions file dhcp.log size 5m, reproduced the failure with a test laptop, opened the log.
The trace showed DISCOVER leaving on the new Airtel-side irb, OFFER arriving back, but the relay-back was timing out before the client REQUEST landed. Round-trip latency to the DC DHCP scope had jumped from 14ms (old BSNL) to 41ms (new Airtel via Mumbai PoP), and the relay default response window was just inside that. Fix: increased maximum-hop-count tolerance and bumped the relay forwarding-options threshold. First-connect failures dropped to zero. Total time to root cause: 47 minutes, all in the traceoptions file, none on a JTAC call.
Extended FAQs
How fast can I get a Juniper SRX/EX replacement in a Tier-2 Indian city?
Realistic numbers from the last 12 months: Bengaluru/Mumbai/Pune/Hyderabad get 6 to 9 hours under SmartNet 4-hour. Jaipur, Indore, Coimbatore typically slip to next-business-day. Patna, Ranchi, Guwahati can stretch to 2 business days. Budget for the slip; do not promise the CISO the contract terms.
Does Juniper sell direct in India or via partners?
Via partners (Tech Pacific, Inflow Technologies, Redington), plus the Juniper India direct team for the top 50 accounts. SmartNet attaches to the partner PO, which means the partner is your first call for any RMA, Juniper India only takes the case after partner triage. Knowing your partner SE's mobile number matters more than knowing JTAC's number.
Is the switch dhcp clients not receiving ip symptom covered by SmartNet?
Software defects and hardware faults are both covered. Configuration errors and operator mistakes are not: JTAC will work the case but the SLA clock does not apply to "operator-induced" tickets. So the symptom capture matters: if you can show a hardware or software cause cleanly, the 4-hour clock starts. If the JTAC engineer concludes "config error", you bought yourself a free Junos tutorial but no SLA-backed replacement.