设备发出、接收数据帧的工作机制

笔者最近遇到一个很有趣的题目，如下：

问：A能否ping通B？问了很多朋友，

答案1：能，因为两个的IP地址和掩码相与，不就是同一个网段吗？（有点道理）

答案2：不能，因为ARP不能跨网段（也有道理）

答案3：不能，要是能通信那子网掩码有什么作用？（这个是认真思考了）

......

其实答案都不正确，我们可以先来ping试一试，并且通过wireshark抓包分析

首先ApingB，发现ping不通。接着看抓包分析

A首先将ARP广播请求发送了出去，然后也收到了来自B的ARP回应，随后A就把B的MAC地址作为数据帧的MAC地址，使用ICMP协议发出，但是一直没有收到B的ping回复，为什么呢？

别急，我们再来看看BpingA的情况

不难发现，B根本没有发出任何数据帧（报文、流量）

我们根据收发原理来分析，A在发出数据前，不知道B的MAC地址，就要使用ARP解析，在解析之前，IP层通过将自己的ip地址和掩码相与计算，得出192.168.10.0/24，在将B的IP地址和自己的掩码相与计算，也得出192.168.10.0/24，所以A认为自己跟B是在同一个网段的，于是进行二层通信，ARP解析报文广播直接找B，于是广播发出；

B收到后，发现目的IP地址就是自己的IP地址，就回应A

A得到了B的MAC地址，发送ICMP报文给B

B收到该报文之后，IP层也将自己的IP地址和A的IP地址分别与本地的掩码相与计算，计算出来之后B发现自己跟A是不在同一个网段的，但是B又没有默认路由，于是它无法发出ICMP报文来进行回应，既然IP层没有过关，也就无法触发ARP机制，因此B没有发出任何信息。

下面我们在SW1上接入一个路由器，将0接口设置为A和B的网关

再来使用A去pingB，发现是可以ping通的，并且我们在AR6到SW1的链路上抓包分析：

A还是通过本地进行计算，发现自己和B是在同一网段的，所以最开始的ARP是直接去找B的

然后B进行了回应，发现很奇怪，这个报文信息是B在找网关的MAC（Tell 192.168.10.3）

经过刚刚的分析，可以得出，A的广播ARP发给B之后，B计算出自己跟A是不在一个网段的，于是它就默认找网关，因为还不知到网关的MAC地址，就进行了ARP请求

所以第三个报文中，网关回应了B的ARP请求，于是B就给网关发送了ICMP报文

该报文到达网关之后，查路由表，然后又ARP请求，寻找A的MAC地址，同时A也进行了回应

不过又奇怪的又出现了，后续的流量中，居然只有B到A的ICMP报文，没有A发出的报文，why？

可以再思考一下，既然A认为B是同一网段，那么发出的报文中的目的MAC都是B，而不是网关

所以，一个报文从A到B再回到A，所经过的路径是不同的

可以让BpingA，我们再次来抓包分析

可以发现，BpingA时，路径又是正常的，B先发给网关，网关发给A，A回应网关，网关回应B

我想，这是因为A对收到的回应报文和请求报文处理机制不同，A发出报文是在IP层通过计算，来决定通信方式，所以它发出报文时，不关心收到的报文从哪里来，但是它回应报文时，就得按照收到的请求报文来决定通信方式（原路返回）