[j-nsp] DHCP relay helper ignoring non-zero source address?

[Jason Healy]

I'm troubleshooting a network issue with an appliance that isn't getting on our network.  We've already solved one problem (hash-collision causing the MAC not to be learned), and JTAC is working on that.  However, even with that worked around, the equipment isn't getting a DHCP address.  We suspect this is an issue with the device (not the switch), and I have a question for the list:


Does the QFX5100 dhcp-relay or EX4200 DHCP snoop have any built-in feature that drops non-compliant DHCP packets?


The device is being worked on, so I can't have it in the failure state right now to take a trace.  I'm hoping someone might know off the top of their head.

The device is giving itself an auto-assigned IP (169.254.36.130).  Nothing wrong with that, but it's using that address as the source of its DHCPDISCOVER packets:

18:19:51.846671 00:10:7f:5b:a0:d4 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 128, id 23, offset 0, flags [none], proto UDP (17), length 328)
    169.254.36.130.49152 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:10:7f:5b:a0:d4, length 300, xid 0x7bad5324, Flags [Broadcast] (0x8000)
	  Client-Ethernet-Address 00:10:7f:5b:a0:d4
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Discover
	    Client-ID Option 61, length 7: ether 00:10:7f:5b:a0:d4
	    Parameter-Request Option 55, length 7: 
	      Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
	      Netbios-Name-Server, Netbios-Node, Netbios-Scope
	    Hostname Option 12, length 15: "DMPS3-A0D4-BHDH"
	    END Option 255, length 0
	    PAD Option 0, length 0, occurs 21

Per RFC 2131:

"DHCP messages broadcast by a client prior to that client obtaining its IP address must have the source address field in the IP header set to 0."

So, does anyone know if this might cause the packets not to get relayed?

Also, any opinions on the client behavior?  Doesn't seem RFC-compliant, but there's plenty of that to go around so I'm not sure if that's the root cause here.

Thanks for any help; I'll try to get a full trace at some point when the tech for the equipment is available to fail it back to DHCP (we have it set to static temporarily as a workaround).

Thanks,

Jason