Juniper EX4200 Stack与PFSense DHCP (发现/提供循环)

Question

我现在在和我的Juniper开关堆栈做斗争。

拓扑就像这个拓扑

堆栈上的客户端端口配置为带有dot1x (多个请求者)的标记访问，并根据Radius身份验证进行切换。这没有问题，并且正确地分配了VLAN。

2 PFSense防火墙确实为故障转移配置中的每个VLAN提供了一个DHCP实例，与VLAN位于同一个子网上。所以不需要DHCP继电器。

Windows客户端可以获得IP并正确工作，但是Linux客户端和PXE引导不能。

在tcpdump和Wireshark中，我们看到了Linux客户端上的DHCP发现/提供循环。报价到达客户端，但客户端不发送DHCP请求。我们尝试了多个Linux衍生工具和PXE实现，但都没有成功。我们还比较了来自Windows和Linux的Wireshark捕获，绝对没有区别。

关于如何追踪这个问题，有什么建议吗？

提前谢谢。

更新：

只是为了增加更多的信息。

IP分配流如下所示：

1. 客户端启动(NIC连接到切换堆栈)
2. 开关在Radius服务器上验证客户端
3. Radius服务器使用Accept和VLAN ID 940应答
4. 切换堆栈将VLAN 940分配给客户端以多个请求模式连接的端口
5. 客户端发送DHCP发现
6. DHCP (两个PFSense)都会提供报价。
7. 客户端发送DHCP请求
8. DHCP服务器发送DHCP ACK

所以很明显1-6起作用了。客户端通过Radius被分配到VLAN940，发送一个DHCP发现，两个PFSense都有一个为VLAN940配置的DHCP实例(IP范围为10.94.0.1-200/24)，并发出了报价。

这是一个PFsense防火墙上的the转储，以防有帮助。

18:55:25.538580 IP (tos 0x0, ttl 20, id 3, offset 0, flags [none], proto UDP (17), length 576)
        0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 00:19:99:f7:3d:23 (oui Unknown), length 548, xid 0x99f73d23, secs 18, Flags [Broadcast] (0x8000)
              Client-Ethernet-Address 00:19:99:f7:3d:23 (oui Unknown)
              Vendor-rfc1048 Extensions
                Magic Cookie 0x63825363
                DHCP-Message Option 53, length 1: Discover
                Parameter-Request Option 55, length 36:
                  Subnet-Mask, Time-Zone, Default-Gateway, Time-Server
                  IEN-Name-Server, Domain-Name-Server, RL, Hostname
                  BS, Domain-Name, SS, RP
                  EP, RSZ, TTL, BR
                  YD, YS, NTP, Vendor-Option
                  Requested-IP, Lease-Time, Server-ID, RN
                  RB, Vendor-Class, TFTP, BF
                  Option 128, Option 129, Option 130, Option 131
                  Option 132, Option 133, Option 134, Option 135
                MSZ Option 57, length 2: 1260
                GUID Option 97, length 17: 0.72.178.216.253.99.205.17.226.190.154.221.134.53.14.178.59
                ARCH Option 93, length 2: 0
                NDI Option 94, length 3: 1.2.1
                Vendor-Class Option 60, length 32: "PXEClient:Arch:00000:UNDI:002001"
                END Option 255, length 0
                PAD Option 0, length 0, occurs 200
    
    18:55:26.546900 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 334)
        10.94.0.253.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 306, xid 0x99f73d23, secs 18, Flags [Broadcast] (0x8000)
              Your-IP 10.94.0.5
              Server-IP 10.91.0.1
              Client-Ethernet-Address 00:19:99:f7:3d:23 (oui Unknown)
              file "pxelinux.0"
              Vendor-rfc1048 Extensions
                Magic Cookie 0x63825363
                DHCP-Message Option 53, length 1: Offer
                Server-ID Option 54, length 4: 10.94.0.253
                Lease-Time Option 51, length 4: 600
                Subnet-Mask Option 1, length 4: 255.255.255.0
                Default-Gateway Option 3, length 4: 10.94.0.254
                Domain-Name-Server Option 6, length 8: 10.0.2.1,10.0.2.2
                Domain-Name Option 15, length 9: "domain.intra"
                NTP Option 42, length 4: 10.94.0.254
                TFTP Option 66, length 9: "10.91.0.1"
                END Option 255, length 0
                
    18:55:26.547180 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 334)
        10.94.0.252.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 306, xid 0x99f73d23, secs 18, Flags [Broadcast] (0x8000)
              Your-IP 10.94.0.104
              Server-IP 10.91.0.1
              Client-Ethernet-Address 00:19:99:f7:3d:23 (oui Unknown)
              file "pxelinux.0"
              Vendor-rfc1048 Extensions
                Magic Cookie 0x63825363
                DHCP-Message Option 53, length 1: Offer
                Server-ID Option 54, length 4: 10.94.0.252
                Lease-Time Option 51, length 4: 600
                Subnet-Mask Option 1, length 4: 255.255.255.0
                Default-Gateway Option 3, length 4: 10.94.0.254
                Domain-Name-Server Option 6, length 8: 10.0.2.1,10.0.2.2
                Domain-Name Option 15, length 9: "domain.intra"
                NTP Option 42, length 4: 10.94.0.254
                TFTP Option 66, length 9: "10.91.0.1"
                END Option 255, length 0

客户端看到的是完全相同的，但只是忽略了它。看上去不对劲吗？

如果我对服务器端交换机上的Linux进行同样的操作( Radius是在其中连接的)，它就可以工作。所以我很确定问题就在Juniper交换机栈的某个地方。

更新2:

我对开关堆栈中的一个问题的假设是正确的。看来，“标记-访问”端口模式的行为并不像它应该做的那样。切换到“访问”端口模式确实解决了这个问题。但这对我来说没有多大意义，因为“访问”模式不应该能够处理不同VLAN中的多个请求者，但显然是这样的。

Answer 1

许多Linux发行版在配置网络接口时都使用klibc ipconfig (请考虑这是一个不同于在Windows中使用的同名工具)

https://kernel.googlesource.com/pub/scm/libs/klibc/klibc/+/klibc-0.130/ipconfig/README

请看变量

-c proto    

可指定为BOOTP或DHCP的

我发现，根据所使用的DHCP服务器，DHCP客户端完全忽略良好的DHCP提供，但当正确设置-c参数时，客户端接受该提议。

在启动时，即Ubuntu，可以通过在内核的命令行中添加IP=DHCP或IP=BOOTP来指定这个参数。在Debian中，它是不同的，它们将内核IP变量用于不同的目的，在本例中，您必须编辑启动initrd，并在相应的脚本中手动更改ipconfig行(通常是/lib/live/boot/9990-networking.sh)。