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.
Unknown VLANs are the primary cause of Input Discards (ifInDiscards
) in my environment; usually from inappropriate VLANs spanning a trunk port. Depending on the services active in the VLAN in question, those counters can increase exponentially over short periods of time.
Keep in mind that Input Discards are the result of valid frames being dropped due to an internal forwarding issue. Another thing to note: Input Discards encompass a drastically smaller amount of issues, most everything else results in an interface error.
Best Answer
The basic process is as follows:
Configure your VLANs
Attach VLANs to switch ports
Configure IP Interfaces
Attach IP interfaces to VLANs
Configure a default route
Create Security Zones
Attach IP Interfaces to Security Zones
Create security policies
Hopefully the topology is fairly self-explanatory - just substitute the IP Addresses you wish to use.
If you are connecting to the Internet on the EXTERNAL network, I would recommend tightening up the security policies to only allow specific subnets out, and specific applications