非对称网络不通 子网掩码导致网络不通是“祸首”

网络不通,这是最多的网络问题表像,但如果你能访问我,但我不能访问你,这个问题就比较麻烦了。本文是作者在实战中的一起由子网掩码造成的故障总结。

  网络不通是经常发生的一种现象,遇到这种现象,相信许多人都会将精力集中在网络线缆、网卡驱动、网卡参数方面;而在检查网卡参数时,他们或许又将眼光聚焦在IP地址、网关地址、DNS服务器或DHCP服务器等重点参数上。事实上,还有一个网络参数——子网掩码,同样也是非常重要的,要是我们忽略了对它的设置或将它设置错误,同样也会带来网络不通的故障。由于子网掩码参数平时不被人重视,一旦由该参数引起网络不通故障,那么该故障的排除往往很容易让人多走弯路!

  故障现象:非对称的网络不通

  某总公司及其子公司都通过宽带光纤与本地电信部门直接连接,并通过电信网络组成该公司的内部网络;平时,各个子公司网络不但能够互相访问,而且也能访问总公司网络,甚至还可以访问Internet网络,而总公司既能访问各个子公司网络,又能访问Internet网络。最近,A子公司反应,无法访问总公司的网站服务器,这么一来他们无法通过网络向总公司上报数据。总公司网络管理员经过初步检查,发现总公司与A子公司的网络互相PING不通,不过总公司不但能够PING通其他子公司的网络,而且也能访问Internet网络,A子公司虽然无法PING通其他子公司的网络和总公司网络,但是它却能访问Internet网络。

  故障排查:防火墙、电信方面?子网掩码!

  通过上面的故障描述,总公司网络管理员认为既然总公司能够PING通其他各个子公司网络,这表明总公司这边的网络工作状态是正常的,问题很可能发生在A子公司网络或本地电信部门那里,A子公司网络能访问Internet网络,这就说明A子公司网络与本地电信网络在物理连接上应该没有任何问题,该网络管理员也初步认为A子公司网络在参数配置上没什么问题。

  可是,A子公司网络无法PING通其他子公司网络,这又说明故障原因就应在A子公司网络或本地电信部门上。可是,让网络管理员感到非常疑惑不解的:通常情况下,总公司网络与A子公司网络只要都能访问Internet网络,同时都能访问相同的网站内容时,它们之间彼此也应该能够访问,除非它们启用了防火墙过滤功能拒绝了各自网络的访问。不过经过实际检查,两边的网络管理员都已经将防火墙都临时关闭了,还是无法解决网络不通故障,这说明网络不通故障与防火墙过滤功能无关。

  在排除了防火墙因素后,总公司的网络管理员认为故障原因可能出现在本地电信部门到A子公司网络的路由设置上,于是该网络管理员登录进本地路由器的后台管理界面,并在该界面中跟踪了A子公司网络的路由。为了寻找其中的猫腻,该网络管理员又分别跟踪了其他几个子公司网络的路由,经过将跟踪结果仔细对比之后,该网络管理员发现202.102.11.156地址和202.102.11.254地址之间存在明显环路现象,经查找地址备案信息,发现这些地址都是来自电信部门那里的,看来问题的关键就在这里!

  考虑到故障原因牵涉到电信部门,这位管理员很慎重,因为电信部门如果果真出现地址环路现象的话,那么相信许多用户很早就会向电信部门求援了,难道等到现在还解决不了故障?于是,这位网络管理员决定还是先从自身查找问题,如果实在找不到原因的话,再向电信部门报修网络故障也不迟;拿定注意后,该网络管理员又分别检查了总公司的服务器、路由器,同时请其他子公司的网络管理员进行配合测试,经过反复测试,该网络管理员确认总公司网络确实不存在任何问题。

  在正式向电信部门报修网络故障之前,总公司网络管理员还没有忘记告诉A子公司的网络管理员,要他对本地子网络的参数设置也进行一下认真检查,并要求他及时反馈检查结果,以便由总公司决定是否统一向电信部门报修网络故障。没有多长时间,A子公司的网络管理员打来电话说,在检查本地路由设置时,发现在设置子网掩码参数时,“255.255.255.192”被设置成了“255.255.255.0”;据A子公司的网络管理员说,虽然他是对着总公司分配下来的参数表进行设置的,可是由于操作上的习惯不小心将路由器子网掩码参数输入成了内网掩码地址。将该地址修改过来后,A子公司的网络立即就能访问总公司的服务器了。至此,本文提到的网络不通故障,就已经被顺利解决了,而该故障的最终“祸首”竟然是不引人注意的子网掩码。

  故障总结:为何能上网但连不了总部

  找到故障原因后,对于前面提到的几种奇怪网络现象我们就不难解释了。例如,A子公司的网络在子网掩码参数被设置不当的情况下仍然能够访问Internet网络,这是因为该子网的路由器存在一条默认路由记录,该路由记录可以将不是A子公司网络数据转发到外网端口,所以A子公司能够访问Internet网络中的内容。

  A子公司的网络之所以无法PING通总公司的网络,主要是由于该子公司的子网掩码参数设置出错引起的。我们知道,主机在发送上网请求之前,往往会先判断目标主机是否处于本地子网中,要是处于同一子网的话就直接将上网请求发送给目标主机,要是不处于同一子网的话,就会将上网请求发送到指定的网关。那么本地主机是如何识别目标主机属于本地子网还是外网的呢?主要是依靠子网掩码地址。假设,在正常状态下,A子公司的网络掩码地址为255.255.255.192,此时A子公司的202.102.11.87主机在尝试访问总公司的网站服务器时(该服务器地址假设为202.102.11.2),本地主机会认为202.102.11.2服务器位于外网,因此它就会将上网请求发送给本地网关,此时A子公司的202.102.11.87主机就能PING通总公司的服务器。一旦A子公司的网络掩码地址变成了“255.255.255.0”后,本地主机就会认为202.102.11.87地址和202.102.11.2地址位于同一网段中,所以本地主机就会把上网请求直接发送给目标主机,而不会将它转发给本地网关了,事实上本地子网中并没有IP地址为202.102.11.2这台目标主机,所以A子公司的202.102.11.87主机就无法PING通总公司的服务器了。总公司的网络之所以无法PING通A子公司的网络,主要是因为A子公司的网络掩码地址出错,导致来自外网的数据请求信息无法正确到达目标主机,所以会认为A子公司的路由不通。

络不通是经常发生的一种现象,遇到这种现象,相信许多人都会将精力集中在网络线缆、网卡驱动、网卡参数方面;而在检查网卡参数时,他们或许又将眼光聚焦在IP地址、网关地址、DNS服务器或DHCP服务器等重点参数上。事实上,还有一个网络参数——子网掩码……

  小提示:子网掩码的重要作用

  许多初次接触网络的朋友常常认为,只要通过观察IP地址就能判断出两个IP地址究竟是否属于同一个子网了,其实他们忽视了子网掩码这个重要的参数。通常来说,观察两个IP地址是否在同一个子网内,既要看IP地址,又要看子网掩码地址。比方说,一台工作站的IP地址为10.192.0.1,对应的子网掩码地址为255.255.255.0,另外一台工作站的IP地址为10.192.1.1,对应的子网掩码地址为255.255.255.0,那么他们就不处于相同的子网中,因为通过子网掩码地址我们可以看出前一台工作站所处的子网网络号为10.192.0.0,后一台工作站所处的子网网络号为10.192.1.0。

  再比方说,一台工作站的IP地址为10.192.0.1,对应的子网掩码地址为255.255.0.0,另外一台工作站的IP地址为10.192.1.1,对应的子网掩码地址为255.255.0.0,那么他们就处于相同的子网中,因为通过子网掩码地址我们可以看出前一台工作站所处的子网网络号为10.192.0.0,后一台工作站所处的子网网络号也为10.192.0.0。

  所以,通过上面的两个例子,我们不难看出相同的两个IP地址,如果它们对应的子网掩码地址不同,那么这两个地址可能分属于不同的子网中,也有可能处于相同的子网中。

(0)

相关推荐

  • 非对称网络不通 子网掩码导致网络不通是“祸首”

    网络不通,这是最多的网络问题表像,但如果你能访问我,但我不能访问你,这个问题就比较麻烦了.本文是作者在实战中的一起由子网掩码造成的故障总结. 网络不通是经常发生的一种现象,遇到这种现象,相信许多人都会将精力集中在网络线缆.网卡驱动.网卡参数方面;而在检查网卡参数时,他们或许又将眼光聚焦在IP地址.网关地址.DNS服务器或DHCP服务器等重点参数上.事实上,还有一个网络参数--子网掩码,同样也是非常重要的,要是我们忽略了对它的设置或将它设置错误,同样也会带来网络不通的故障.由于子网掩码参数平时不被

  • Docker网络原理及自定义网络详细解析

    Docker在宿主机上虚拟了一个网桥,当创建并启动容器的时候,每一个容器默认都会被分配一个跟网桥网段一致的ip,网桥作为容器的网关,网桥与每一个容器联通,容器间通过网桥可以通信.由于网桥是虚拟出来的,外网无法进行寻址,也就是默认外网无法访问容器,需要在创建启动容器时把宿主机的端口与容器端口进行映射,通过宿主机IP端口访问容器.这是Docker默认的网络,它有一个弊端是只能通过IP让容器互相访问,如果想使用容器名称或容器ID互相访问需要在创建启动容器时候用link的方式修改hosts文件实现.一般

  • Docker网络之单host网络及使用案例

    前言 前面总结了Docker基础以及Docker存储相关知识,今天来总结一下Docker单主机网络的相关知识.毋庸置疑,网络绝对是任何系统的核心,他在Docker中也占有重要的作用. 一.Docker默认网络 在新安装docker的主机上执行 docker network ls 便能看到docker默认安装的所有网络,分别是none网络.host网络和bridge网络. 1.1 none 网络 none网络就是什么都没有的网络.挂在这个网络下的容器除了lo,没有其他任何网卡.容器run时,可以通

  • vue网络请求方案原生网络请求和js网络请求库

    一. 原生网络请求 1. XMLHttpRequest(w3c标准)    // 没有promise时的产物 当时的万物皆回调,太麻烦 2. Fetch    // html5提供的对象,基于promise 因为promise的存在,为了简化网络请求. 使用 Fetch - Web API 接口参考 | MDN Fetch是新的ajax解决方案 Fetch会返回Promise对象.fetch不是ajax的进一步封装,而是原生js,没有使用XMLHttpRequest对象. 参数: 1.第一个参数

  • Android网络监听和网络判断示例介绍

    目录 一.在AndroidMainfest.xml中添加权限 二.NetUtilSS 网络判断工具类 三.IntentReceiver网络监听工具类 四.BaseActivity 五.MainActivity    一.在AndroidMainfest.xml中添加权限 <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" /> <uses-permission android:

  • 故障的机器修好后重启,狂拉主库binlog,导致网络问题的解决方法

    问题简述: 一周前,有一台mysql服务器发生硬件故障,停机了.我们给专门负责这块的同学提交了申请,他们负责去报修这台服务器.今天这台服务器修好后,他们将其开机启动.服务器上的4个mysql实例在开机后自动启动,开始拉主库的binlog.由于这台服务器停机时间比较久,日志丢的比较多,狂拉主库的binlog,导致主库网络出现问题. 现象: 首先,我们完全没有意识到是因为一台坏掉的服务器重启拉主库binlog导致的,因为我们压根不知道 这台服务器什么情况,只知道1周前,我们报修了1台服务器.具体什么

  • 网线破损导致“网络风暴”

    笔者筹建过某公司的网络中心,该中心以负责全市各家分公司间信息的交换,实现各分公司间资源的共享.各分公司都通过DDN专线经路由器用TCP/IP协议与主机连接. 网络中心的以太网分为两个网段:192.168.1.x和 192.168 2.x,以下简称网段 1和网段2.其中有用于处理备分公司信息的生产机及开发机各一台,另有二台与各分公司进行远程通信的路由器.另外还有一些用于开发和监控的计算机.网段2中有多台计算机,进行客一端的开发调试.开发机和一台计算机同时连在两个网段上. 某天,网络发现各分公司的数

  • Android网络编程之获取网络上的Json数据实例

    为要获取网络上的Json所以需要服务器端提供的支持. 一.创建服务器端: 服务器端项目结构: 服务器端运行效果图: 第一步:创建业务所需的JavaBean 复制代码 代码如下: package com.jph.sj.model;   import java.util.Date;   /**  * 新闻实体类  * @author jph  * Date:2014.09.26  */ public class News {     private Integer id;     private S

  • java网络编程之socket网络编程示例(服务器端/客户端)

    Java为TCP协议提供了两个类,分别在客户端编程和服务器端编程中使用它们.在应用程序开始通信之前,需要先创建一个连接,由客户端程序发起:而服务器端的程序需要一直监听着主机的特定端口号,等待客户端的连接.在客户端中我们只需要使用Socket实例,而服务端要同时处理ServerSocket实例和Socket实例;二者并且都使用OutputStream和InpuStream来发送和接收数据. 学习一种知识最好的方式就是使用它,通过前面的笔记,我们已经知道如何获取主机的地址信息,现在我们通过一个简单的

  • 深入分析Cookie的安全性问题

    Cookie的目的是为用户带来方便,为网站带来增值,一般情况下不会造成严重的安全威胁.Cookie文件不能作为代码执行,也不会传送病毒,它为用户所专有并只能由创建它的服务器来读取.另外,浏览器一般只允许存放300个Cookie,每个站点最多存放20个Cookie,每个Cookie的大小限制为4KB,因此,Cookie不会塞满硬盘,更不会被用作"拒绝服务"攻击手段. 但是,Cookie作为用户身份的替代,其安全性有时决定了整个系统的安全性,Cookie的安全性问题不容忽视. (1)Coo

随机推荐