使用UCARP（VRRP）的KEMP负载平衡器-未获取多播MAC地址

好吧-至少要连续20个小时与之抗争。.很抱歉，这似乎是长篇大论，还是写博客，但我已经精疲力竭了。

所以，这是交易。我们正在使用KEMP负载均衡器，该负载均衡器利用UCARP（CARP的Linux克隆，这是VRRP克隆）来实现HA心跳和持久状态。我们希望在我们的环境中利用IGMP来防止整个数据中心泛滥。

我们有两个运行SW 5.1.1.7的Dell PowerConnect 8124F交换机作为机架顶部。这两个连接到堆叠的Cisco 3750-X对，这是我们的核心。

当我们升级到PowerConnect 5.1.x时，问题就开始了，除非您另有说明，否则它们显然默认情况下保持IGMP侦听打开。而且，我们的负载平衡器陷入了裂脑，引起了各种温暖的模糊乐趣。

• 如果我在负载均衡器不进行多播的VLAN上禁用IGMP侦听，则多播仍然无效
• 如果我在核心上设置了IP PIM，则PowerConnect交换机可以在同一VLAN上看到它，但是仍然没有多播流量
• 如果我启用了所有未注册的多播流量的泛洪功能，那么它仍然没有任何作用。
• 如果我在PowerConnect交换机上全局禁用IGMP侦听，则所有多播流量均有效。它的工作原理如此之好，以至于我们将多播流量泛滥到了每个带有相同VLAN标签的端口上。精彩。

我注意到核心VLAN上有一些奇怪的MAC地址条目：

coresw#sh mac address-table vlan 367 | include 5e00
 367    0000.5e00.0101    DYNAMIC     Po13   seq_no:0

而且我认为..那不是组播地址吗？为什么在“ sh mac address-table multicast”中不是这样？

coresw#sh mac address-table multicast vlan 367
Vlan    Mac Address       Type        Ports
----    -----------       ----        -----
coresw#

然后在PowerConnect CLI指南中阅读以下内容：

组播流量是发往主机组的流量。主机组由目标MAC地址标识，即IPv4组播流量的范围01：00：5e：00：00：00-01：00：5e：7f：ff：ff：ff或33：33：xx：xx ：xx：xx用于IPv6组播流量。

好像我们在MAC地址的开头缺少一个“ 01”，对吗？上面的动态MAC条目以“ 00”开头。在这一点上，我正在考虑致电KEMP，让他们知道他们的产品配置错误。但是，然后我去阅读VRRP的 RFC-看到：

与虚拟路由器关联的虚拟路由器MAC地址是以下格式的IEEE 802 MAC地址：

IPv4大小写：00-00-5E-00-01- {VRID}（以十六进制表示，按Internet标准比特顺序）

好的-交换机通常不会选择VRRP的多播mac地址范围。好的，让我们在Dell交换机上配置一个静态主机组。不。

输入无效：组播MAC地址的格式必须为01XX：XXXX：XXXX

好的，然后..下一步，尝试添加静态mac条目：

osl-sys-swrack03(config)#mac address-table multicast ?

forbidden                forbid adding specific multicast addresses to
                         specific ports.

osl-sys-swrack03(config)#

所以-无法配置静态多播MAC条目。如果我尝试对常规的静态MAC条目执行相同的操作，则只能将其绑定到一个端口-该负载平衡群集跨4个不同的10gig端口运行。

更新：关于MAC地址似乎有些混乱。172.30.1.0/24是前端负载平衡器网络。172.30.1.6是群集的默认共享VIP，.7是第一个负载平衡器的管理IP，.8是第二个负载平衡器的管理IP。所有其他地址（30、40、70、80等）都是具有不同服务的VIP。当发生故障转移时，所有VIP都将其MAC地址更改为第二个LB的物理MAC地址。在底部表中的组播地址并没有改变。

coresw#sh ip arp vlan 367
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  172.30.1.6             78   0050.56b4.5004  ARPA   Vlan367    <- VIP - Loadbalancer1 physical MAC
Internet  172.30.1.40           204   0050.56b4.5004  ARPA   Vlan367    <- VIP - Loadbalancer1 physical MAC
Internet  172.30.1.80           167   0050.56b4.5004  ARPA   Vlan367    <- VIP - Loadbalancer1 physical MAC
Internet  172.30.1.70            38   0050.56b4.5004  ARPA   Vlan367    <- VIP - Loadbalancer1 physical MAC
Internet  172.30.1.66            12   0050.56b4.5004  ARPA   Vlan367    <- VIP - Loadbalancer1 physical MAC
Internet  172.30.1.35           185   0050.56b4.5004  ARPA   Vlan367    <- VIP - Loadbalancer1 physical MAC
Internet  172.30.1.60            97   0050.56b4.5004  ARPA   Vlan367    <- VIP - Loadbalancer1 physical MAC
Internet  172.30.1.30            80   0050.56b4.5004  ARPA   Vlan367    <- VIP - Loadbalancer1 physical MAC
Internet  172.30.1.61            33   0050.56b4.5004  ARPA   Vlan367    <- VIP - Loadbalancer1 physical MAC
Internet  172.30.1.7             27   0050.56b4.5004  ARPA   Vlan367    <- Management - Loadbalancer1 physical MAC
Internet  172.30.1.8             21   0050.56b4.08c2  ARPA   Vlan367    <- Management - Loadbalancer2 physical MAC

osl-sys-coresw#sh mac address-table dynamic vlan 367
          Mac Address Table
-------------------------------------------

Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
 367    0000.5e00.0101    DYNAMIC     Po13   seq_no:0   <- multicast HA mac (UCARP)
 367    0050.56b4.08c2    DYNAMIC     Po13   seq_no:0   <- Loadbalancer1 physical MAC
 367    0050.56b4.5004    DYNAMIC     Po13   seq_no:0   <- Loadbalancer2 physical MAC

这就是故事。我到底要怎么办？

我能够解决问题。在Kemp（具有HA对）上，可以选择使用“虚拟MAC地址”。如果未选中此框，则负载均衡器VIP的MAC是活动Kemp单元的物理接口的MAC。如果选中此框，则VIP的MAC地址为VRRP MAC。如上所述，VRRP RFC声明MAC为“ 00:00” {blah}，最后一个八位位组为路由器ID。默认的Kemp HA [路由器] ID为01。在使用固件5.1.xx的Powerconnects上，我未使用VRRP，但是我进行了一些跟踪，并确定如果路由器ID与自身相同，则Powerconnect将丢弃VRRP帧。即使未配置VRRP，他们也会执行此操作，并且在该模式下，它们的默认值为01。因此，将Kemp HA路由器ID更改为22（0x16）之类的东西，一切都会正常进行。

您要查找的多播地址为224.0.0.18 [mac：01005e.000012]。这是所有VRRP节点的控制通道。[edit]除非KEMP更改了代码，否则CARP（UCARP）会使用VRRP单播MA​​C [00005e.0001xx]发起流量-这是交换机自然会学到的地方。

如果您的网络上没有查询器（大概在每个网段中），那么您的交换机最终将忘记所在的组-除非询问，否则主机不会发送定期成员资格。[编辑：根据配置，交换机可能会丢弃未知的多播，而不是泛洪。]这可以是专用的查询器（它发送数据包，不关心任何答案），或更常见的是您的基础结构中的多播路由器。 。在这种简单的情况下，查询器就足够了，因为无论如何VRRP消息都被禁止跨网段。

我不熟悉Dell交换机，所以我不知道您需要什么cli命令。

[更新]

Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
367    0000.5e00.0101    DYNAMIC     Po13   seq_no:0   <- multicast HA mac (UCARP)

那不是多播mac。那就是组播流量的单播MAC 源。组播mac将不会显示在mac地址表中。在多播组表中。Cisco IOS有一个show mac-address-table multicast（在我的路由器上什么也不显示）和show ip igmp groups（显示3个组）。该路由器设置为pim稀疏模式；北电和思科交换机将其视为查询器。

通过使用主机NIC MAC作为虚拟地址，KEMP方法存在严重缺陷。您的情况是5004属于nic。当5004消失时，每个人的表中仍然会有“ IP：6 == MAC：5004”；他们将继续尝试与死主机对话，直到替换该条目为止。KEMP显然正在赌博免费网络中的一切都受到尊重。因此，HSRP，VRRP 和 OpenBSD设计的CARP 都使用虚拟MAC。（在传输多播流量时，它们似乎无法破解UCARP以使用nic mac而非VRRP虚拟mac。）

考虑到他们使用UCARP进行黑客攻击，您确定它甚至在使用多播吗？