HP 5400Rzl2 奇怪的 ACL 行为

网络工程 路由 转变 acl hp-procurve 第 3 层
2022-02-05 12:09:30

大家好，各位专家。

如果这是一个愚蠢的问题，我很抱歉（我通常不会问这些问题，但我是人类），但我不知道在这种环境中出了什么问题。

我希望允许我所有的 VLAN只与VLAN 1 和互联网通信。

All internal traffic is inside 192.168.0.0/16 range like:
. VLAN 1: 192.168.1.0/24 (ip addr 192.168.1.1)
. VLAN 2: 192.168.2.0/24 (ip addr 192.168.2.1)
. VLAN 3: 192.168.3.0/24 (ip addr 192.168.3.1)

This is the only routing-activated layer3 switch on campus 
and is the default gateway for everybody

因此，我创建了“ acl_default ”并将其应用于每个 VLAN 的入站（显然 VLAN 1 除外）

ip access-list extended "acl_default"
   10 permit ip 192.168.0.0 0.0.255.255 192.168.1.0 0.0.0.255
   900 deny ip 192.168.0.0 0.0.255.255 192.168.0.0 0.0.255.255 
   950 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 
   exit

它可以工作......但是，每天早上， VLAN（不是 VLAN 1）中的所有用户都无法与 VLAN 1 上的某些服务器通信。

如果我从 VLAN 120 (192.168.120.0/24) 跟踪路由到服务器，我会看到一个循环：

traceroute to 192.168.1.69 ,
          1 hop min, 30 hops max, 5 sec. timeout, 3 probes
 1 192.168.120.1        1 ms      1 ms      1 ms
 2 192.168.120.1        0 ms      1 ms *
 3 192.168.120.1        1 ms      1 ms      1 ms
 4 192.168.120.1        1 ms      1 ms *
 5 192.168.120.1        1 ms      1 ms      1 ms
 6 192.168.120.1        1 ms      1 ms *
 7 192.168.120.1        1 ms      1 ms      1 ms
 8 192.168.120.1        1 ms      1 ms *
 9 192.168.120.1        0 ms      2 ms      0 ms
10 192.168.120.1        1 ms      1 ms *
11 192.168.120.1        1 ms      1 ms      1 ms

但是...如果我去 server_69 并 ping 回 120_gateway，一切都开始工作了！！

这就是为什么早上无法访问某些服务器的原因：那些不经常与非 vlan1 子网通信的服务器。

Chassis info: HP Procurve 5400Rzl2 Software: KB.15.17.0003

我错过了什么？

提前谢谢大家（即使只是为了阅读这篇长文）

瑞

2个回答

我不确定那是一个循环。我不太确定那是什么。ACL 看起来不错，因此您可能想与 HP 讨论这个问题。

我有一个类似的案例，基于 procurve 的 L3 交换机无法正确管理其 arp 表。我认为它也和你在同一个软件分支上。打电话给惠普，5 分钟后，它被确认为已知问题，将在下一个版本中修复。

如果您查看下一个固件版本的发行说明，它是否提到有关 ARP 已修复的任何内容？还是在当前固件版本说明（您正在运行的固件版本）中将其列为已知问题。第二天早上它发生了，尝试用 clear arp 清除 arp 表/缓存。尝试再次从 vlan 120 ping 到服务器，看看它是否有效。

我认为惠普免费提供固件版本（至少在低端型号上）。我们正在考虑将 5400 用作核心，最终选择了基于 Comware 的 HP 交换机，并且它很稳定。Procurve 很棒（我们有很多客户在访问层使用它们），但我看到过类似这样的奇怪问题，尤其是在较新的固件版本上。

知道了！

这是KB.15.17.0008 之前版本的软件错误。

从发行说明：

CR_0000174881 , CR_0000176140对于进入具有路由访问列表 (RACL) 的 VLAN 的路由 IPv4 流量，交换机不会向下一跳 IPv4 地址发起 ARP 请求(....)

因此，IPv4 路由流量无法到达其目的地，因为交换机没有在交换机 ARP 表中为下一跳 IPv4 地址创建 ARP 条目， (....)

该问题可能是间歇性的，因为可能有其他来源试图到达相同的下一跳 IPv4 地址，这将导致创建 ARP 条目。由于 20 分钟的 ARP 老化时间，该问题可能会在 20 分钟后再次出现。

他们举了一个和我一样的例子：

例如，如果路由的 IPv4 流量也通过没有 RACL 的 VLAN 进入交换机，或者如果您从受影响的交换机 ping 它。从交换机 Ping 到无法访问的 IPv4 目标地址暂时解决了可达性问题；但是，它可能会在 APR 过期到期后或调用 CLI 命令 clear arp 后再次发生。

尽管我可以在发布这个问题之前先检查软件版本，但我不确定这不是我在 ACL 实现上的一些错误。总是有些东西可能会在不经意间溜走。就像它对每个使用它进行 5 个软件版本的人所做的那样。

我把它留在这里以防其他人遇到这个问题。

感谢@Mark 让我知道我做的事情是正确的。他的第二个意见引导我进行下一步：寻找软件版本。如果我在上面没有找到任何东西，我会打开一个关于 HP（HPE 部门）的案例。

其它你可能感兴趣的问题
上一篇数据中心终端服务器的价值 下一篇防止 Cisco 路由器出现在 traceroute 中