具体地说，我将0/0端口（软件中的fe-0 / 0/0）连接到我的现有网络，DHCP在我使用的几乎所有其他设备上都非常可靠地工作。 SRX100没有获得DHCP地址。尝试此操作时，SRX100是开箱即用的默认配置。
我将其中一台设备带到家里，然后将其插入我的家庭网络，并获得了IP地址我的家庭网络通过DHCP没问题。
我的办公室网络在我的桌面上有一个Procurve 1400（仅限第2层）交换机，上行连接到Polycom IP670 IP电话（用作简单的第2层交换机） ，向上链接到充当网络路由器的Procurve 3500yl交换机，在vlan接口上指向IP地址为DHCP中继的vlan接口上的“ ip helper-address 1.1.1.1”。通过Procurve获得SRX DHCP客户端获得IP地址（运行K.15.09.0012软件...尽管Procurve上的多个固件版本之间都存在此问题）。 SRX100出厂时似乎上面装有11.2，但我认为升级到12.1X44-D10.4时问题仍然存在。 Procurve 3500yl似乎不承认已经看到SRX100发出了DHCP客户端请求，但是该区域中Procurves的故障排除信息似乎很有限。 DHCP服务器绝对看不到任何与SRX100有关的DHCPDISCOVER数据包。
我的解决方法是在SRX100上静态配置IP地址以使其进入网络并进行其余配置，但是我正在从事的项目涉及将SRX100发送到不受我控制的远程位置，并且因此，取决于它们可靠地获取用于连接的DHCP地址，因此我真的很想解决此问题并耗尽特定原因，因此我知道如果这发生在远程站点，可能会寻找什么。
更新：我已经（仔细检查）了出厂默认的SRX100，并将其直接插入Procurve 3500yl的端口中，并且仍然看到问题，因此从讨论中删除了1400和IP670电话。我在下面包括了SRX100的tcpdump输出...正如您所看到的那样，它发送的内容可能是最简单的DHCP数据包，这往往表明问题出在3500yl的dhcp-relay函数。我找不到任何方法来从3500yl中获取任何调试输出，这些输出显示数据包命中了dhcp-relay函数（是否成功）。有关如何在3500yl上调试此功能的建议将不胜感激。
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
#1 楼
我与惠普就此问题开了一个案子。在升级到无用的Level 1技术之后，Level 2技术非常机敏地发现了我没有的东西。SRX发送其TTL为1的DHCPDISCOVER数据包。并在中继到DHCP服务器的数据包中使用所得的TTL。在这种情况下，减量会使TTL保持为0，这意味着数据包将掉落在地板上。
这实际上是DHCP / BOOTP中继的规范，尽管显然会导致互操作性降低。我已要求HPNetworking将其视为Bug / RFE并更改其行为。在这种情况下，无法立即响应该请求。
发送TTL为1的DHCPDISCOVER的SRX也可能在规格范围内，但是，再次选择降低互操作性，因此我打算打开一个在相同的基础上使用JTAC的情况。
我将在可用时添加更多有关Juniper和HP响应的信息。
我已经测试了中继行为Cisco 4506（固件版本不立即可用）和Brocade / Foundry FastIron Edge X（我相信7.2或7.3固件没有立即访问权限进行确认），它们都可以处理TTL 1中继请求，而不会出现问题。
UPDATE
有一种方法可以更改SRX在其DHCP请求上使用的TTL值，但不能在JunOS cli中更改它...它是通过底层Unix OS完成的。 。
root@% sysctl -w net.inet.ip.mcast_ttl=64
我已经与HP开通了RFE，以使它们的中继功能更具弹性，但尚未答复他们是否会/何时进行。
#2 楼
如果您不知道问题出在哪里，并且在看似看不见的情况下拥有来自三个供应商的三台设备（SRX100、1400和IP670），则很难进行故障排除。我无法与特定设备通话，但是通过跟踪数据包绝对不会出错。由于ProCurve 1400是不受管的设备，因此您需要使用网络分路器。您希望捕获以下位置的流量（基于您声明3500yl没有收到发现信息数据包）：
在SRX100和1400之间。
在1400和IP670之间
在IP670和3500yl之间
您可以从办公桌上进行所有这些操作，并且在连接/断开连接时，如果水龙头会造成破坏，但它只会影响您和您的设备。
我将从此列表的顶部开始，因为它应该允许您至少捕获一次DHCP发现数据包，然后可以将与此后的DHCP发现数据包的任何后续捕获进行比较以查看
您可能还想从运行正常的设备捕获DHCP发现数据包，以查看SRX100发送的发现数据包是否有任何差异。
一旦知道数据包哪里出了问题，就可以专门研究故障原因。
评论
是的，我还没有进行这些特定的步骤，因为我非常有信心1400和ip670仅是可靠的第2层，因此不会为DHCP流量带来麻烦。我认为问题是SRX与3500yl之间存在某种不兼容。我怀疑数据包到达了3500yl，但处理不正确。我无法得到3500yl来表示它看到了我认为更多的数据包，这是由于3500yl的调试功能有限。
–杰夫·麦克亚当斯
13年5月23日在0:43
@JeffMcAdams，我倾向于同意该评估，但之前对奇怪的问题感到惊讶。由于您可以将水龙头从桌子上的所有位置移开，因此，我将遵循此包装以确保一切正常。如果您必须在网络壁橱，楼层，建筑物或站点之间移动，那么我会说跳到问题所在并从那里开始。另外，获得一个知名的发现数据包将使您知道DHCP服务器中是否有某些“多余”的东西（选项82或其他）。
– YLearn♦
13年5月23日在0:51
#3 楼
尽管您已经在其他地方测试了SRX：SRX在家中是否获得具有完全相同配置的地址？
这应该意味着以下内容问题：
set security zones security-zone host-inbound-traffic system-services dhcp已完成基本接口配置已完成（原始接口，vlan标签，正确vlan中的接口，
中的那个vlan接口实际上在Juniper侧是否干净？
show interfaces fe-0/0/0 extensive是您的朋友（我知道不适合这样做，但仍然...）对于光学接口还检查功率级别：
show interfaces diagnostics optics ge-0/0/0 向DHCP客户端添加跟踪：
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
然后监视使用
monitor start dhcp_client.log调出接口时记录日志（记住，一旦完成，请删除traceoption）评论
1.是的，我在家里和办公室都使用了打破出厂默认配置的配置。出厂默认配置的确在我使用的fe-0 / 0 / 0.0接口上包括主机入站流量系统服务dhcp。 2.是的，接口干净整洁，如果我在上面静态配置IP信息，它就可以正常工作。 3.我正在用原始数据包的tcpdump编辑原始问题...我根本看不到返回数据包，也从来没有看到数据包到达DHCP服务器。
–杰夫·麦克亚当斯
13年5月23日在15:07
评论
您是否尝试过将SRX直接连接到3500yl，以确保1400或Polycom都没有过滤DHCPDISCOVER广播？我没有，这不是一个坏主意。但是，有时我确实以相同的方式连接其他系统，并且确实在其他系统上获得了DHCP地址，包括以这种方式一直在网络上的台式机，因此这似乎不太可能成为问题。不过，我看看是否可以测试。
在响应中更新了一些信息...特别是如何在SRX中更改DHCP请求的TTL值，并注意到我已经与HP开设了RFE。