我们间歇性地kernel: martian source在几台服务器上看到 eth0 的日志条目。有趣的是，它们来自同一个 IP。例如：
Nov 4 02:20:27 tcffmppr6db09 kernel: martian source 10.153.242.13 from 10.153.242.13, on dev eth0.3171
这只发生在几台服务器上。大约有 60 个以相同的方式配置了 eth0（显然是不同的 IP）。
我应该注意什么来追踪这个问题？
编辑：
该特定接口的路由是默认路由，因此我认为这不是发送到错误接口的问题。
答案1
问题
我今天遇到了同样的问题，火星数据包淹没了我的内核日志。所有火星数据包都来自相同的公共 IP 地址eth0到相同的公共 IP 地址eth0（真实 IP 和标头已被删除）。
IPv4: martian source x.x.x.x from x.x.x.x, on dev eth0
ll header: 00000000: aa bb cc dd ee ff gg hh ii jj kk ll 08 00
经过一番研究，我意识到原因隐藏在ll header火星数据包中。
理论
假设在以太网连接中，ll header实际上显示了以太网类型 II 帧的开始部分，其中包含目标 MAC 地址、源 MAC 地址，以及指示数据包其余部分类型的 ID。
![以太网 II 类帧格式[1]](https://i.stack.imgur.com/ZUrzv.png)
如您所见，前 6 个字节是目标 MAC 地址，接下来的 6 个字节是源 MAC 地址，最后 2 个字节是代码。常见代码有：
08 00：IP数据包86 dd：IPv6数据包08 06：ARP数据包
解释
回到我的例子。
IPv4: martian source x.x.x.x from x.x.x.x, on dev eth0
ll header: 00000000: aa bb cc dd ee ff gg hh ii jj kk ll 08 00
这告诉我们，
- 收到具有相同源 IP 地址和目标 IP 地址的数据包。
- 它是由 发送的
GG:HH:II:JJ:KK:LL，这是一个我不知道的 MAC 地址。 - 它的目的地是
AA:BB:CC:DD:EE:FF，这是我自己的 MAC 地址。 - 这是一个 IP 数据包 (
08 00)。
如果一个数据包具有相同的源和目标IP地址，那么它一定是通过同一个网络接口发送的，但源和目标的MAC不同！怎么可能？
因此，很明显该数据包来自火星，要么存在一些路由问题，要么配置了网络内的机器，要么有人试图欺骗 IP/MAC 地址。下一步是检查有问题的源 MAC 地址。
答案2
火星数据包只不过是一个 IP 数据包，它指定了由互联网号码分配机构 (IANA) 保留供特殊使用的源地址或目标地址。
以下是此类地址块的示例：
- 10.0.0.0/8
- 127.0.0.0/8
- 224.0.0.0/4
- 240.0.0.0/4
- ::/128
- ::/96
- ::1/128
要追踪这一点，您有多种选择。您可以忽略它，您可以通过防火墙阻止它，或者您可以使用tcpdump或wireshark剖析数据包的内容，这可能会让您深入了解导致此问题的原因。
附加描述和来源
当您搜索此内容时显示的另一个短语如下：
这些是 Linux 不期望从其来源方向发出的数据包（即来自内部主机的数据包进入外部接口）。原因可能是 LAN 上的计算机配置错误。您可以关闭记录这些数据包，通过
/proc/sys/net/ipv4/conf/interface/log_martians它记录/usr/src/linux/Documentation/proc.txt
我找不到这一段的原始出处，但是如果你搜索它，它会逐字地出现很多！这将问题描述为数据包通过未指定的接口 (NIC) 进入系统。
最后，我也会引用关于这个主题的维基百科，其中的内容也与上面的内容大致相同。
火星数据包是一个 IP 数据包，它指定了源地址或目标地址保留供特殊用途经过互联网号码分配机构（互联网地址分配机构）。如果在公共互联网上看到，这些数据包实际上无法像所声称的那样产生或传递。1但是，某些保留地址可以使用多播或在专用网络、本地链路或环回接口上进行路由，具体取决于它们属于哪个特殊用途范围。2