将vrrp协议禁止了，还能在网卡上抓到别的服务器发来的vrrp心跳，为什么？

台虚机：192.168.3.4 ，192.168.3.14。

在192.168.3.14上执行iptables禁用进来的vrrp数据包，但是还能收到192.168.3.4的数据包，这是为什么？

直奔主题

一个packet从网卡的DMA Receive Ring buffer向内核Stack流水线内推（input），内核stack已经提前将packet通过callback发给抓包软件如Wireshark、TCPDUMP、Sniffer，谁运行发给谁。如果3个都运行，3个软件都会收到。

Stack的input流水线并没有因为抓包软件的存在而停止，而是继续内推packet。当推到iptable/NF模块时，恰好match到题主的Filter Policy：

-A input -p vrrp -j DROP

其中：

A = Append

p = protocol

j = jump

通俗地说，增加（Append）一个Policy条目，input方向(packet从网卡上行到stack)，如果protocol ==vrrp，直接Drop。

以上是完整的答案。如果对VRRP的工作原理了解，接下来的文字不用阅读了。

VRRP

Virtual Router Redundancy Protocol的缩写。

广播域里每一个主机离开本地广播域依靠谁？

当然是网关(Gateway)了。

如果这个Gateway挂了，包括重启、崩溃、以及莫名其妙的故障，广播域每一个主机还能离开广播域，访问外面的世界（Internet）或公司其它内网网段？

肯定不能了。

电脑前的员工哈哈太爽了，不用干活了。

老板肯定不太爽，什么破网络？赶紧修复并改进，严格杜绝一个节点（网关）失效而造成的网络故障。

如果一个广播域，有多个路由器充当Gateway，且多个路由器拥有相同的IP地址、相同的MAC地址，当其中的一个Gateway挂了，流量会自动切换到其它网关上，是不是就可以避免单点故障（Single Point Failure）？

是的。

但是，一个广播域内多个网关同时使用相同的IP地址/MAC地址会造成地址冲突。

有没有一个解决既什么（物理冗余）又什么（避免地址冲突）的解决方案？

有的，它的名字叫VRRP。

假设，该广播域提供的Virtual IP = 192.168.3.1，它对应的Virtual MAC是多少呢？

图片里显示该广播域使用的vrid(Virtual Router ID) ==51。

将vrid从十进制的51，换算成16进制，得到

vrid == 51 ==0x33（16进制）

加上一个固定的前缀00-00-5E-00-01，得到00-00-5E-00-01-33

Virtual MAC = 00-00-5E-00-01-33

Virtual IP = 192.168.3.1

广播域内的主机在DHCP动态IP地址等参数时，被分配的

Default Gateway= 192.168.3.1

恰好就是上文的Virtual IP，只要有任何一个物理网关可以工作，主机就可以无障碍上网。当ARP广播请求192.168.3.1的MAC地址时，返回的应答MAC==00-00-5E-00-01-33。

以上是VRRP呈现给用户光鲜靓丽的一面，但是VRRP协议是怎么工作的？

VRRP使用的IP = 224.0.0.18，对应的MAC地址可以算出来！

将IP换算成2进制，取从右到左的23位，应该是

0000000.00000000.00010010（2进制）

换算成16进制

0x0.0.12 (16进制)

在左侧添加一个固定的前缀01.00.5e，最终的呈现效果是：

01.00.5e.0.0.12

这个就是VRRP协议自身通信的MAC地址。

当你配置vrrp成功时，发生了什么？

系统将“01.00.5e.0.0.12” 下发到物理网卡，系统有人对这个MAC地址感兴趣，请允许它进入！

当外部vrrp报文到达网卡时，由于上文的高层指示，网卡会用packet的destination MAC做一个判断：

Packet’s Destination MAC ==？ 01.00.5e.0.0.12

很显然，会顺利匹配并允许上行。

上行的流水线，抓包工具如tcpdump对流量同样感兴趣，被copy一份走raw socket特殊通道上行。

上行流水线继续上行，到达iptable/NF被policy匹配到扔了。

题主将VRRP配置删除，网卡的感兴趣MAC地址列表立马删除01.00.5e.0.0.12，抓包工具、应用进程再也不会收到来自VRRP的消息了。

为什么？