奇怪的发往MAC地址00:00:00:00:00:00的数据包

孤独的意尹者

在用户处抓取数据包，发现了一些奇怪的发往MAC地址00:00:00:00:00:00的数据包，有没有兄弟见过这个现象呢？一起讨论下吧。

[ 本帖最后由 孤独的意尹者 于 2008-8-18 21:59 编辑 ]

快乐橙子

难道是广播？？？？？

快乐橙子

广播应该是FFFFFFFFFF啊。
也有可能MAC就是00-00-00-00-00-00

孤独的意尹者

请大家先参考下这个帖子http://www.csna.cn/forum.php?mod ... p;highlight=%2B1259，论坛里提到的类似的问题

孤独的意尹者

但是请大家注意：
我抓的这个包跟1259兄抓的包是有区别的，1259兄抓的包中出现的目的MAC为00:00:00:00:00:00的数据包对应的IP只有一个，那么，说人为的或其他原因导致主机MAC为00:00:00:00:00:00，主机可以正常通讯似乎可以解释得过去。
但是，我抓取的数据包中，目的MAC为00:00:00:00:00:00的数据包多次出现，而且对应的目的IP有好几个，而且不知大家注意到没有，这种数据包都是单向的，那么这样解释就行不通了。

徐徐渐进

可否说下抓包的环境和一些相关的应用.

孤独的意尹者

抓包环境很简单，就是通过交换机的端口镜像抓取出口链路的数据包。
应用主要就是访问互联网的应用，没什么特殊的应用

从零开始

内网主机的访问和应用正常吗？
好像有欺骗的嫌疑。

孤独的意尹者

原帖由 从零开始 于 2008-8-18 11:19 发表
内网主机的访问和应用正常吗？
好像有欺骗的嫌疑。

内部其他应用都正常，没有反馈有异常

徐徐渐进

但是请大家注意：
我抓的这个包跟1259兄抓的包是有区别的，1259兄抓的包中出现的目的MAC为00:00:00:00:00:00的数据包对应的IP只有一个，那么，说人为的或其他原因导致主机MAC为00:00:00:00:00:00，主机可以正常通讯 ...

个人认为与1259所说的情况是一样的，因为数据包的多个IP对应的是同一个MAC。


不知是否对该主机进行检查。

孤独的意尹者

原帖由 徐徐渐进 于 2008-8-18 11:26 发表

个人认为与1259所说的情况是一样的，因为数据包的多个IP对应的是同一个MAC。
10143

不知是否对该主机进行检查。

1259兄所说的情况是因为那个主机的MAC就是00:00:00:00:00:00，而且这个主机可以正常通讯，而在我抓取的数据包中，这些MAC为00:00:00:00:00:00对应的IP都是单向通讯，外网发往这些内部IP的，而内部这些IP都没回应。
另：抓包现场未注意到，没来得及检查主机

徐徐渐进

现在还不能排除这台机器的mac就是00:00:00:00:00:00；
楼主能去检查下这台机器吗？
期待结果。

[ 本帖最后由 徐徐渐进 于 2008-8-18 13:08 编辑 ]

从零开始

用MAC地址扫描器看内网中是否有这台主机及其对应的主机名和IP；
搜了一下，有资料说这是Windows服务器开启了负载均衡产生的虚拟地址，不知是否是这样？

[ 本帖最后由 孤独的意尹者 于 2008-8-18 17:44 编辑 ]

孤独的意尹者

原帖由 从零开始 于 2008-8-18 13:16 发表
用MAC地址扫描器看内网中是否有这台主机及其对应的主机名和IP；
搜了一下，有资料说这是Windows服务器开启了负载均衡产生的虚拟地址，不知是否是这样？

1,因为抓包现场没注意到这个现象，所以没做相应的测试；
2,不知能否把相关资料贴上来参考下呢？

oldjiang

02:01:00:00:00:00 是MS的负载平衡包用到的虚拟MAC地址

[ 本帖最后由 oldjiang 于 2008-8-18 21:06 编辑 ]

孤独的意尹者

最新发现：我上面所说的单向通讯是错的，某些机器是存活的，而且其MAC的确不是 00:00:00:00:00:00，并可以看到正常的数据交互。
看样子有时候使用过滤器反而容易造成不便啊，谨记！数据包重新更新，欢迎大家接着发表高见。

[ 本帖最后由 孤独的意尹者 于 2008-8-18 22:00 编辑 ]

孤独的意尹者

先顶上去再说

徐徐渐进

发包的MAC是正常的，而收包的MAC则是0；

在机器上执行一下MAC扫描器，看看它的二层通讯是怎样的呢？

另外，在ARP表中，MAC也是为0吗？

徐徐渐进

整个数据包的源MAC为同一地址，可能是此所致。

孤独的意尹者

原帖由 徐徐渐进 于 2008-8-19 13:18 发表
整个数据包的源MAC为同一地址，可能是此所致。
10152
10153

这个就是我们做端口镜像的交换机，港湾的，我也怀疑是否是港湾交换机的bug导致的

Nelson

即使是镜像端口，也不应该改变每个数据帧的源mac地址和目的地址。因为纯2层交换机不做路由，一般来说是不会修改2层帧头的。

假设172.16.0.0为内网
DNS服务器在外部网

如果是路由器，则必然有2个interface，每个interface有一个mac地址
但是从包内容来看，无论是去向dns还是从dns来的地址都是同一个mac

那么有理由相信，是使用了interface vlan 或单臂路由
这里我相信是用了interface vlan作为网关

那么有理由相信这是一个3层交换设备，并且做了vlan，以每个vlan interface作为该vlan的网关。SVI

假设该MAC地址00:05:3b:81:10:e0为interface vlan 1的网关，则ip地址为172.16.5.0/24中某一个，那么它在路由本网段数据包（目的172.16.5.248）的时候必然会直接和该IP地址arp，获得mac地址，进行本地通讯。

当目的地址为172.16.4.34时，由于该包从interface vlan 1进来，那么交由172.16.4.0/24网段的网关处理。假设为interface vlan 2。 由于interface vlan 1和interface vlan 2是在同一个物理设备上的两个虚拟网关。因此interface vlan 1直接以全0的mac地址把它转给vlan 2 （172.16.4.0网段）。因为本来就是一个设备内部的过程，所以mac地址为0 （实际上每个3层交换机都应该为其vlan interface保留MAC地址。每增加一个SVI则MAC值+1。）

以上内容，纯属猜测，如有雷同，纯属巧合。

uniland

这种情况我也出现了，我们可以交流一下！
QQ：149871762

uniland

原帖由 从零开始 于 2008-8-18 13:16 发表
用MAC地址扫描器看内网中是否有这台主机及其对应的主机名和IP；
搜了一下，有资料说这是Windows服务器开启了负载均衡产生的虚拟地址，不知是否是这样？

是的，我的也出现这个问题！原因一直不明。