☰

类似 VRRP/keepalived 的东西，没有 MAC 地址影响？（RHEL 8）

tag-icon • tag-icon redhat linux-networking keepalived
类似 VRRP/keepalived 的东西，没有 MAC 地址影响？（RHEL 8）

我正在寻找一个带有 VIP 的集群（由两个系统组成），这正是 keepalived 可以做到的。在不同的环境中，我已经让 keepalived 运行良好。但是，我们的网络团队告诉我不要引入任何新的 VRRP MAC 地址，因为它可能会与他们自己的一些 VRRP 配置发生冲突。

我也不想为此添加反向代理。像这样的单点故障会破坏 VIP 的初衷。

有没有办法将 keepalived 配置为仅使用第 3 层构造，或者使用无需降至第 2 层即可执行相同操作的其他工具？

我意识到虚拟 MAC 地址的原因之一是 ARP 解析。由于更改 MAC 地址而导致的短时间中断是不可取的，但在我的场景中是可以接受的。

答案1

以下示例假设 IPv4，配置类似于此处为基本 Red Hat 示例：一个节点的地址为 192.168.122.101/24，另一个节点的地址为 192.168.122.102/24，使用 VRRP 实例 VI_1 和 VRRP VIP 192.168.122.200/24。

这将不再符合 VRRP 要求，因为RFC 5798告诉在 ARP 回复中使用 VRRP MAC 地址。

无论如何，你可以配置保持活跃以遵守您的网络团队设定的政策。

  • 不要use_vmac在 VRRP 实例配置中使用该选项

    阻止来源类型 00:00:5E:00:01:XX 的虚拟路由器 MAC 地址永远不会被使用。

    • 可以简单地删除该use_vmac选项，

      客户不会遇到太多麻烦故障转移，因为每次一个节点保持活跃成为 VRRP 地址的主控，它首先通过 5 个 DAD ARP 请求宣布其 (VIP) 地址，以进行无偿 ARP 请求（pacemaker/corosync 在这方面的行为相同），并将在 10 秒后再次执行此操作。例如，对公告的捕获将发生变化：

      00:00:5e:00:01:33 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.122.200 (ff:ff:ff:ff:ff:ff) tell 192.168.122.200, length 28

      到：

      56:24:20:bf:2a:37 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.122.200 (ff:ff:ff:ff:ff:ff) tell 192.168.122.200, length 28

      因此，交换机不会注意到必须使用不同的端口才能到达相同的 MAC 地址并更新其转发数据库，​​而是 IPv4 客户端会注意到必须使用不同的 MAC 地址才能到达相同的 IPv4 地址，并会更新其 ARP 表。

    • 或者如果确实需要，将其替换为use_ipvlan（以两个额外的 IPv4 地址为代价！），

      达到同样的效果（和上面的最后一个例子完全相同的在线捕获）。

      仅当集群配置依赖于由以下项创建的附加虚拟接口时才需要这样做：保持活跃在每个节点上，并避免彻底的重新配置。虚拟局域网界面行为与麦克维兰接口，除非它将使用来自其父接口的 MAC 地址（并​​在内部处理 IP 数据包如何多路复用到正确的接口）。

      在 IPv4 上，此选项需要使用额外的IPv4 地址。此地址不能是 VRRP，也不应是父接口的 IP 地址（否则会出现路由问题），因此如果它与系统网络配置位于同一接口/LAN 上，则 2 个节点集群现在可能需要 5 个地址，而不是 3 个：两个原始系统定义的地址、2 个额外的虚拟局域网地址和VRRP地址。

      例如，一台服务器除了使用其原有的 192.168.122.101 系统配置地址外，还会使用：

      use_ipvlan vip0 192.168.122.103

      除 192.168.122.102 之外的另一个：

      use_ipvlan vip0 192.168.122.104

      如果可以选择的话我会避免这个选择。

  • 使用unicast_peer块

    防止使用 IPv4 VRRP 多播地址 224.0.0.18 和相应的目的地VRRP MAC 多播地址 01:00:5E:00:00:12。

    这还需要禁用strict_modeif 设置（或者 if在块vrrp_strict中设置global_defs），并且不支持use_ipvlan上面描述的（也不use_vmac）。check_unicast_src也可以启用以防止第三方系统的配置错误，而不是为了任何安全。

    例如，节点 192.168.122.101 可以使用：

    vrrp_instance VI_1 {
    ...
    strict_mode off
    check_unicast_src
    unicast_peer {
        192.168.122.102
    }
}

    以及 192.168.200.102 的节点：

    vrrp_instance VI_1 {
    ...
    strict_mode off
    check_unicast_src
    unicast_peer {
        192.168.122.101
    }
}

    执行此操作时，只有单播流量将被使用保持活跃。

    请注意，删除strict_mode可能会改变防火墙的行为保持活跃。

相关内容