从一道题目开始提及

 

目录

• 从一道题目开始提及
  • 从一道题目开始提及
  • 本身
  • 疑惑与荒诞
  • 真实一点
    • A老师
    • B老师
    • C老师
  • 到底谁说的是对的？
  • 意外收获
  • 补充一点
  • 再补充一点

 

从一道题目开始提及

• 在阅读下面的内容时，要求读者对十进制二进制的转换、子网划分、arp协议、三层交换机比较了解，这部份内容属于通讯的基础知识，在下文当中会直接带过，不作分析。
• 写这一篇可太费劲了，模拟实验作了五六次;

从一道题目开始提及

B主机pingA主机能ping通吗？不管通或者不通，请说明通讯流程。

交换机配置至关简单，以下所示，除此以外无它。

vlan 12
vlan 13

int vlan 12
	ip add 10.100.12.1 24
int vlan 13
	ip add 10.100.13.1 24

int g1/0/13
	port link-type access
	port access vlan 13
int g1/0/12
	port link-type access
	port access vlan 12

本身

在作实验、或请教别人以前，本身应该先分析和思考，下面是个人思考：

1. B主机认为自己所处的网络是10.100.12.0/24，同时B主机认为A主机所在的网络是10.100.13.0/24，B认为A与本身不在一个网段，因此B主机想要与A主机通讯应该先询问B主机所在网络的网关，获得网关的MAC以后，进行ICMP的的请求包封装交给网关。
2. 网关位于交换机的vlanif接口上，收到了B的ICMP请求报文以后，查看了ICMP的目标IP，根据路由表ICMP的请求包将转发到交换机13口，ICMP的请求顺利到达 A主机。
3. 主机收到了网关转发给它的数据帧，发现源IP是10.100.12.231，运算后发现与本身所处在同一个网段，因而arp广播B主机的MAC地址，但vlan13里面，只有A主机和它的网关，并无其它主机，网关又隔绝广播，arp的广播请求没法到达B主机 ，A主机由于没法获得B主机的MAC地址，因此也就没法封装ICMP的回复报文，因此主机B与主机A通讯是不通的。

疑惑与荒诞

后面开始验证本身的想法，我打开ensp模拟了这个实验，经过屡次抓包发现当交换机将B主机的ICMP请求交给A以后，A主机居然直接将回复包交给网关转发了，B主机由于收到A主机 的回复因此显示是可以通讯的！

• 个人分析是错误的吗？有可能，我拿捏不许；
• ENSP出了问题？也有可能，由于ENSP这种垃圾软件出现这种问题也不奇怪。

在此处展现我在ENSP作的拓扑：

用PC2 PING PC1 在通的前提下，在PC1上抓包，以下图所示：

经过上图咱们看到PC2发给PC1的请求包是网关转发的，回复包居然也是网关转发的，这和咱们分析的那种状况不符。

将ENSP与vmware workstation结合一下,但愿再贴近一下真实环境：

这样环境比较真实，至少PC是真的，用10.100.12.231 PING 10.100.13.178 不通，在这种状况下，在10.100.13.178上抓包：

在10.100.12.231上抓包，看下，以下图所示：

经过上面这种方式，却是验证个人分析，可是有一点奇怪，那就是两个vlanif接口的MAC居然一致，这与真的交换机仍是不太同样，真正的交换机两个vlanif接口的MAC不可能同样，模拟器果真仍是差点意思，并不能百分百贴近真实的环境。

怎么办？我想到我有几位大牛老师的联系方式，这几位老师都是高手，在IT圈子里面是有名号的，好多人都认识的，下面我会贴一下聊天记录。值得一提的是，当我在某个IE培训机构的群里面向老师提问时，老师言语中透露出个人基本功不够扎实，我没有反驳，也没有在乎，可能真的是我错了。

真实一点

幸亏我是在企业环境当中，手边有华三在的S5560和峰火的三层交换机。找了两台笔记本、找到了一台宇视的三层交换机和一台华三S5560三层交换机，我作了一个真实的实验，仍是在B PING A的时候，在A主机上抓包。

仍是上面这个环境。

A的MAC是：70b5:e898:7af6

B的MAC是：F8B1-56AB-419A

vlan13的接口MAC是：5c:a7:21:0c:7a:c3

vlan12的接口MAC是：5c:a7:21:0c:7a:c2

而后在B主机上抓包看下：

先用宇视的三层交换机，而后再用华三交换机，主机B与主机A都是不通，抓到分析后发现与我所说的结论同样，我震惊了，这么一番折腾，最终发现我是对的！

同时我还发现了一位知名老师老师写的关于计算机网络原理的书里面错误的地方，他们大牛的形象在我心中坍塌了，同时内心的名言警句来我心中浮现，什么尽信书不如无书，纸上得来终觉浅，都好有道理呀！同时我也发现了林沛满的《wireshark网络分析就是这么简单》一书是基于真实环境编写的，并非在模拟器上编写的，很是真实可靠，做者水平至关之高，你们能够放心阅读。

上述我询问的这些讲师，有讲课10多年经验的，也有就在大学里面任教的，有两位老师在回答的时候都是答非所问，只有一位老师尊重事实，但也仅限于根据模拟环境的当中的答案当中推导理论，自圆其说。缘由其实有不少了，老师们多是由于太忙了，给学生答疑成了例行工做，作麻木了，无论怎样吧，反正最后还得靠咱们本身，在这些大牛都在“蒙蔽”你的时候，要勇敢，勇敢的挑战本身、勇敢的挑战别人，若是最终结果发现是本身错误的，那也要勇敢的修正的本身知识体系。

下面让咱们看看这些老师的回答；

A老师

我认为我已经把问题说的够清楚，但仍然感受沟通上有障碍，以为A老师是答非所问，反正我是啥都没听懂。哎，QQ沟通原本就是有这种阐述不明的感受。

B老师

一样的问题，我又问了B老师，下面就是B老师给个人答案，怎么说呢？不作评价，我是失望 的，我没有有看懂，哎~

C老师

C老师不愧是有经验的老师，并无轻易回答我，而让本身在ENSP作实验验证，而后C老师给了以下的解释，我和这位老师是电话沟通的，就没有截图了，C老师经过作实验抓到获得结果，而后经过抓到结果推理原理给我讲，A主机收到B主机的ICMP请求报文以后，就原路返回了！抱歉，这种解释我不能接受……

到底谁说的是对的？

我先说结果，是我分析的结论是对的，最终这老师们不得不认可。

意外收获

第一点

当咱们的windows电脑配置完ip、掩码、网关以后，即便什么也不作，在开机状态下，网卡会向外发送arp广播，询问网关的mac是多少，其实这没有什么，当把这个发现放到上述场景当中就有意思了。当交换机收到B的icmp的请求包以后，在转发给A主机之际，A主机所在的网关会不会arp请求A的MAC地址呢？我屡次抓包都没看到，缘由是由于当A主机配置完IP、掩码、网关以后，立马就会发送一个询问网关的arp广播，而后网关会回应，这一回应不只仅会意味着A主机会获得网关的MAC，也意味着网关所在的交换机也会获得A主机的MAC。在这种状况下之下，当B主机所在的vlan网关获得B发往A主机的ICMP请求报文时，就不会再arp广播A主机的MAC地址了，就会直接封装。

再延伸一点，若是咱们在一个设备不上配置网关，仅配置IP和掩码，这样当开机的时候，也会发送一个arp广播，询问是否有使用它当前使用的地址，咱们能够利用这点，在某些不方便接外设的设备开机时，就在它的网口上等着抓arp包，其实就能看到他的IP地址，获取了设备的IP地址以后在链接它就简单了。

第二点

从这个实验当中获得最重要的结论是虽然A主机已经收到网关转发给它的B主机发送的ICMP请求报文，但A主机仍然会坚持对源IP地址进行判断，判断是否与其是一个网段，若是判断是一个网段，A主机无论请求报文是怎么来的，A主机依然会arp广播请求目标主机的MAC，主机会独立判断，这是很是重要的一点。其实我想说并非这个，我想说的是有没有哪些地方是不须要判断，就本能发送的？这让我联系到二层的arp，arp无论对方是谁，只要是有人问，那我就会回应，这样的理解若是放到下面这个场景当中，就有点意思了。

两台主机都在一个广播域之下，而且真的有网关，正常状况下，主机能与网关通讯。

A主机：192.168.0.10/24 网关是192.168.0.1

B主机： 192.168.0.130/27 网关也是192.168.0.1

仍是说一下，B能不能ping通A？

B对A的icmp请求报文仍是要给网关，网关也会转发给A，那A这时候认为B和本身是一个网段，这时候会发arp请求广播，B会收到，那B这时候会不会回应？B在回复A发送的arp广播时会不会考虑到A和本身不在一个网段，从回复包交给网关或者丢弃掉呢？实际上是不会的，B在回复arp请求的时候并不会作判断，这一点要和上面作一个区分。

补充一点

当咱们分析完上面这种比较复杂的题目时，再来看下面这道题，就发现很是简单了。

其实我一眼就能看出来这道题出自哪里，这道题应该是出自林沛满写的《wireshark网络分析就是这么简单》一书，就只把IP地址的第三个部分给改了，原书中是26，这里改为了242。

A：192.168.242.129/24 192.168.242.2
B：192.168.242.26/27 192.168.242.2

B到A的话，B会将请求交给网关，而后网关将给A，A直接广播B的MAC，B会忽略arp的子网判断，B会回应A的arp请求，A如愿获得B的mac，成功回复ICMP的回复报文，通的。

A到B的话，A广播B的MAC，如愿收到以后，A的ICMP的请求顺利到达B，B怎么回复呢？B会将icmp的回复包交给网关，而后网关再给A，通的。

再补充一点

如上所示，掩码有点奇怪，显示拨号成功了，这个掩码就是把这个IP掩死的意思，我在ACL的时候会用到，可是这种拨号场合我也是第一次见。

那么问题来了，这么设置能正常通讯吗？先来分析一下。

掩码的做用就是作与运算的，若是这台设备ping 223.6.6.6通讯的话，本机会把10.108.176.145这一整个当作网络位，与对方不在同一个网络当中，那下一步天然要交给网关，嗯，这和掩码是24的时候转发路径是相同的。

window7会提示一个警告，其实能够强行设置，在centos7系统若是将掩码设置为32的话，重启网卡以后，一点都不会报错，并且与外界通讯正常。

若是一个主机将掩码设置32位的话，通讯就会变成了样，主机根本不会区分目标主机是是否和本身一个网络位，由于在它看来，除了本身，因此的地址都和本身不是一个网络位，会将发往除了本身以外的的IP的数据包全都交给网关。

那问题来了，在主机看来网关也和它不是一个网段，主机跟不是一个网段的主机通讯时要交给网关，但网关跟主机就是一个网段，问题自己成了问题，怎么搞？其实像windows和linux这种成熟的系统，早就想到了这种状况，我抓包看了一下，也搞一个环境。

A：192.168.80.2/32 192.168.80.1

B：192.168.80.208/24 192.168.80.1

A主机ping B主机？怎么通讯？

先说结论，是能通的，主机将ICMP请求数据包交给网关，而后B主机不经过网关，B主要认为A和它一个网段，因此A直接扔了过来。

其实当A主机配置完网关的时候，A主机是无论网关和本身是否是在一个网段，A主机这时候不会作判断，直接就广播网关的mac，当问题本地成为问题，这就是一个很是好的解决方案。

若是在主机上这么设置掩码，实在是犯不上，为何的呢？有点脱了裤子放屁的感受，本地局域网通讯都不须要让网关参与，但这种方式若是配置在ppoe这种拨号场景当中，就无所谓了，反正原本就是想让对方转发。