10

I am trying to bootstrap the config on some Juniper SRX100s and am having some DHCP issues.

Specifically, I am connecting the 0/0 port (fe-0/0/0 in the software) to my existing network, where DHCP has worked quite reliably for just about every other device I've used. The SRX100s are not getting DHCP addresses. The SRX100 is out-of-the-box default config when I'm attempting this.

I brought one of the devices to my house and plugged it into my home network and it got an IP address on my home network via DHCP with no problems.

My office network has a Procurve 1400 (layer 2 only) switch on my desktop, uplinked to a Polycom IP670 IP phone (acts as a simple layer 2 switch), uplinked to a Procurve 3500yl switch acting as a router for the network with "ip helper-address 1.1.1.1" on the vlan interface pointing to the DHCP server for DHCP relay.

Does anyone have any experience with getting an SRX DHCP client getting an IP address via a Procurve (running K.15.09.0012 software...though the problem has existed across multiple firmware versions on the Procurve). The SRX100s seem to have 11.2 on them when they come out the box, though I think the problem continues to exist when upgraded to 12.1X44-D10.4.

Does anyone have any suggestions for troubleshooting this? The Procurve 3500yl doesn't seem to admit to having seen the DHCP client request coming in from the SRX100, but troubleshooting info on the Procurves in this area seems limited. The DHCP server definitely does not see any DHCPDISCOVER packets arrive relating to the SRX100.

My workaround has been to statically configure an IP address on the SRX100s to get them on the network and do the rest of my config, but the project I am working on involves sending the SRX100s out to remote locations that are not under my control and, thus, depends on them reliably getting DHCP addresses for connectivity so I would really like to troubleshoot this and run down a specific cause so I know what to potentially look for if this happens at remote sites.

Update: I have (to double-check) factory-defaulted the SRX100, and plugged it directly into a port on a Procurve 3500yl and am still seeing the problem, so that removes the 1400 and the IP670 phone from the discussion. I've included the tcpdump output from the SRX100 below...as you can see, its sending out about the simplest possible DHCP packet possible, when tends to suggest that the problem is with the dhcp-relay function on the 3500yl. I can't find any way to get any debug output from the 3500yl showing packets hitting the dhcp-relay function (successfully or otherwise). Suggestions on how to debug this function on the 3500yl would be greatly appreciated.

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
  • Have you tried connecting the SRX directly to the 3500yl to ensure than neither the 1400 or the Polycom are filtering the DHCPDISCOVER broadcasts? – David Rothera May 22 '13 at 22:22
  • I haven't, and that's not a bad idea. I do, however, on occasion, connect other systems in the same manner and do get DHCP addresses on the other systems, including my desktop machines that are constantly on the network in this manner, so that seems unlikely to be the problem. I'll see if I can test that, though. – Jeff McAdams May 22 '13 at 22:48
  • Updated with some information in my response...specifically with how to change the TTL value of DHCP requests in the SRX, as well as noting that I've opened an RFE with HP. – Jeff McAdams Aug 27 '13 at 13:54
9

I opened a case with HP concerning this issue. After escalating past the useless Level 1 tech, the Level 2 tech very alertly spotted something that I had not.

The SRX is sending its DHCPDISCOVER packet with a TTL of 1. The Procurve's apparently will decrement the TTL and use the resulting TTL in the relay'ed packet to the DHCP server. In this case, the decrement leaves the TTL at 0 meaning the packet gets dropped on the floor.

This is actually in spec for DHCP/BOOTP relay, though clearly it causes reduced interoperability. I have asked HPNetworking to treat this as a bug/RFE and change the behavior. No immediate response to that request in the case.

The SRX sending the DHCPDISCOVER with a TTL of 1 is also probably within spec, but, again, a choice of reduced interoperability, so I plan to open a case with JTAC on the same basis.

I'll add more info on the response of Juniper and HP as it becomes available.

Incidentally, I have tested the relay behavior of a Cisco 4506 (firmware version not immediately available), and a Brocade/Foundry FastIron Edge X (7.2 or 7.3 firmware, I believe, don't have immediate access to confirm) and they both handle relaying the request with TTL 1 without issue.

UPDATE There is a way to change the TTL value that the SRX uses on its DHCP requests, but its not from within the JunOS cli...its done from the underlying Unix OS.

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

I have opened an RFE with HP to make their relaying function more resilient, but not response from them yet on if/when that will be worked on.

2

It can be tough to troubleshoot when you don't know where the problem lies and you have three devices from three vendors before you seem to have any visibility (the SRX100, the 1400, and the IP670). I can't speak to the specific devices, but you can never go wrong by tracing the packets. Since the ProCurve 1400 is an unmanaged device, you would need to use a network tap.

You would want to capture the traffic in the following locations (based on your statement that the 3500yl is not receiving the discover packet):

  • Between the SRX100 and the 1400.
  • Between the 1400 and the IP670
  • Between the IP670 and the 3500yl

You can do all these from your desk, and while a tap is disruptive while you are connecting/disconnecting it, it should only affect you and your devices.

I would start at the top of this list, because it should allow you to capture the DHCP discover packet at least once and then any subsequent captures of the DHCP discover packet can be compared against this one to see if there is any modification.

You may also want to capture DHCP discover packets from devices that are working as well to see if there are any differences from the discover packet the SRX100 sends out.

Once you know where the packet goes wrong, you can look into specifically troubleshooting why it goes wrong at that point.

  • Yeah, I haven't gone into those specific steps yet as I have pretty good confidence that the 1400 and ip670 are reliably layer 2 only and thus not mucking about with the DHCP traffic. I think the problem is some sort of incompatibility between the SRX and the 3500yl. I suspect the packet is getting to the 3500yl, but its not handling it correctly. That I can't get the 3500yl to indicate that it has seen the packet I think is more due to the limited debugging capabilities on the 3500yl. – Jeff McAdams May 23 '13 at 0:43
  • @JeffMcAdams, I would tend to agree with that assessment, but have been surprised by strange issues before. Since you can move the tap in those places all from your desk, I would follow the packet to guarantee things are working as expected. If you had to move between network closets, floors, buildings or sites, then I would say jump to where the problem is and start there. Plus, getting a good known discover packet will let you know if there might be something "extra" in it your DHCP server doesn't like (option 82 or something else perhaps). – YLearn May 23 '13 at 0:51
1

Although you've tested the SRX elsewhere:

  1. Does the SRX get an address with the exact same config at home?
    • This should mean the following are not issues:
    • set security zones security-zone host-inbound-traffic system-services dhcp has been done
    • Basic interface config done (either raw interface, vlan tags, interface in correct vlan, that vlan in
  2. Does the interface actually come up cleanly on the Juniper side?
    • show interfaces fe-0/0/0 extensive is your friend
    • (I know it's not appropriate for this, but still...) For optical interfaces also check power levels: show interfaces diagnostics optics ge-0/0/0
  3. Add a trace to the DHCP client:
configure
set system services dhcp traceoptions file dhcp_client.log world-readable
set system services dhcp traceoptions flag client
set system services dhcp traceoptions level all
commit and-quit

Then monitor the log as you bring up the interface with monitor start dhcp_client.log. (Remember to delete the traceoption once you're done)

  • 1. Yes, I'm doing this with break-the-seal-out-of-the-box-factory-default configs, both at home, and in the office. The factory default config does include host-inbound-traffic system-services dhcp on the fe-0/0/0.0 interface that I'm using. 2. Yes, the interface is up cleanly, and if I static config IP info on it, it works fine. 3. I've editing the original question with a tcpdump of the packet going out...I never see a return packet at all, and don't ever see the packet hit the DHCP server. – Jeff McAdams May 23 '13 at 15:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.