SRX DHCP客户端与HP Procurve DHCP Relay的兼容性

我正在尝试在某些Juniper SRX100上引导配置，并且遇到一些DHCP问题。

具体来说，我将0/0端口（软件中的fe-0 / 0/0）连接到我现有的网络，在该网络中，DHCP对于我使用的几乎所有其他设备都非常可靠。SRX100没有获得DHCP地址。尝试此操作时，SRX100是开箱即用的默认配置。

我将其中一台设备带到家里，然后将其插入我的家庭网络，它通过DHCP毫无问题地在我的家庭网络上获得了IP地址。

我的办公室网络在我的桌面上有一个Procurve 1400（仅限第2层）交换机，上行链路到Polycom IP670 IP电话（充当简单的第2层交换机），上行链路到Procurve 3500yl交换机，充当带有“ ip vlan接口上的“ helper-address 1.1.1.1”，指向用于DHCP中继的DHCP服务器。

有没有人有通过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

我与惠普就此问题开了一个案子。在升级到无用的Level 1技术之后，Level 2技术非常机敏地发现了我没有的东西。

SRX正在发送其TTL为1的DHCPDISCOVER数据包。Procurve显然将减少TTL，并使用中继数据包中的结果TTL发送给DHCP服务器。在这种情况下，减量将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中继请求。

更新 有一种方法可以更改SRX在其DHCP请求上使用的TTL值，但不能在JunOS CLI内更改它...它是通过基础Unix OS完成的。

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

我已经与HP开设了RFE，以使它们的中继功能更具弹性，但是在何时/何时可以解决这些问题方面尚未得到他们的回应。

如果您不知道问题出在哪里，并且在您似乎没有任何了解之前，已经有来自三个供应商的三台设备（SRX100、1400和IP670），则很难进行故障排除。我无法与特定设备通话，但是通过跟踪数据包绝对不会出错。由于ProCurve 1400是不受管理的设备，因此您需要使用网络接头。

您可能希望捕获以下位置的流量（基于您的声明3500yl没有收到发现数据包）：

• 在SRX100和1400之间。
• 在1400和IP670之间
• 在IP670和3500yl之间

您可以从办公桌上进行所有这些操作，并且在连接/断开连接时，如果水龙头会造成破坏，但它只会影响您和您的设备。

我将从此列表的顶部开始，因为它应该允许您至少捕获一次DHCP发现数据包，然后可以将与此后的DHCP发现数据包的任何后续捕获进行比较，以查看是否有任何修改。

您可能还想从运行良好的设备捕获DHCP发现数据包，以查看SRX100发送的发现数据包是否有任何差异。

一旦知道数据包出了什么问题，就可以专门研究故障原因。

尽管您已经在其他地方测试了SRX：

1. SRX 在家中是否获得具有完全相同配置的地址？
   • 这应该意味着以下不是问题：
   • set security zones security-zone host-inbound-traffic system-services dhcp 已经完成
   • 基本接口配置完成（原始接口，VLAN标签，正确VLAN中的接口，
2. 接口在Juniper端是否干净利落？
   • show interfaces fe-0/0/0 extensive 是你的朋友
   • （我知道这不适合这样做，但仍然...）对于光学接口，还请检查功率水平： show interfaces diagnostics optics ge-0/0/0
3. 将跟踪添加到DHCP客户端：

配置
设置系统服务dhcp traceoptions文件dhcp_client.log世界可读
设置系统服务dhcp traceoptions标志客户端
设置系统服务dhcp traceoptions级别全部
提交并退出

然后在通过调出界面时监视日志monitor start dhcp_client.log。（记住，一旦完成，请删除traceoption）