RIP v1因掩码不同产生主机路由而ping不通

共三个部分,前两个部分讲两个现象,第三个部分尝试根据现象分析原因

• 第一个部分 , 拓扑图 (所有 IP 为 24 位掩码):

先给 R1 配置:

#
rip 1
 version 1
 network 192.168.1.0
 network 192.168.2.0
#

配置完立刻在 R1 g0/0/1 接口抓包:

可以看出 R1 此时向外通告 1.0 网段和 2.0 网段,没有携带掩码信息

此时在 R2 上做配置:

#
rip 1
 version 1
 network 192.168.3.0
 network 192.168.2.0
#

然后立刻查看抓到的包:

• R1 发出的包:
  

• R2 发出的包:
  
  观察发现 R1 与 R2 互相发出的包中两个路由器共同的 2.0 网段都被置为了16跳,稍等片刻后再看两者发出的包:

• R1 发出的包:
  

• R2 发出的包:
  
  观察发现 R1 与 R2 共同的 2.0 网段都不再互相通告,所以一开始短暂的将共同的网段置为16跳是正常现象

• 第二个部分 , 拓扑图 (所有 IP 为 28 位掩码):

R1 配置:

#
rip 1
 version 1
 network 192.168.1.0
#

R2 配置:

#
rip 1
 version 1
 network 192.168.1.0
#

配置完后在 R1 g0/0/1 接口抓包:

• R1 发出的包:
  
• R2 发出的包:
  

1. 观察可知与第一部分情况相同, R1 与 R2 共有的 1.16/28 网段被置为16跳,稍等片刻后两个路由器均不再通告此网段
2. 观察分析可得即便在命令行中 R1 和 R2 通告的都是 192.168.1.0 的标准主类网段,但是 路由器实际发送出去的路由条目都是根据自身接口的掩码计算得出的汇总后的网段

• 此时 R1 的路由表:
  
  观察可知 R1 上的 1.0/28 和 1.16/28 均为直连, 1.32/28 是从 R2 学习得来的,掩码均正常为28位

• 此时 R2 的路由表:
  
  观察可知 R2 上的 1.16/28 和 1.32/28 均为直连, 1.0/24 是从 R1 学习得来的,其中两个直连的路由掩码均正常为 28 位,但是从 R1 学来的 1.0/24** 路由掩码却为 24 位**

分析可得之所以 R2 将 R1 通告的 1.0(无掩码信息) 路由条目误认为成 1.0/24 而不是正确的 1.0/28 ,是因为从 R1 路由器收到的 192.168.1.0 网段是标准的 C 类主类(A,B,C类)地址,所以直接将此路由条目掩码置为 24 位

• 第三个部分 , 拓扑图 ( PC1,R1和R2 为 24 位掩码, R3和R4 为 28 位掩码):

R1 配置:

#
rip 1
 version 1
 network 192.168.3.0
 network 192.168.2.0
#

R2 配置:

#
rip 1
 version 1
 network 192.168.1.0
 network 192.168.2.0
#

R3 配置:

#
rip 1
 version 1
 network 192.168.1.0
#

R4 配置:

#
rip 1
 version 1
 network 192.168.1.0
#

• 此时 R1 的路由表:
  
  观察发现没有 1.16/28 网段的路由,只从 R2 学习到了 1.0/24 网段的路由
• 此时 R2 的路由表:
  
  观察发现从 R3 学习到了 1.16/32 主机路由 (实际上没有任何端口和主机使用1.16这个IP), 而没有 1.16/28 网段的路由
• 此时 R3 的路由表:
  
  无异常 ( 但是1.0 网段的路由为何掩码为 28 位? 而不是 24 位?)
• 此时 R4 的路由表:
  
  观察发现 1.0/24 网段路由的掩码为 24 位,但是在 R3 上 1.0/28 网段路由的掩码为 28 位,而此条路由是 R4 通过 RIP 从 R3 学习到的,理应和 R3 路由表中的掩码相同,但是到了 R4 上却变为了 24 位

分析以上可得:

1. R3 路由表中 1.0/28 网段是直连的,所以是根据实际接口的 IP 产生的路由条目,而接口 IP 的掩码是我们在命令行中敲进去的 28 位掩码,所以这条直连路由的掩码就是 28 位,而不能是从 R2 学习到的 24 位
2. 虽然 R2 路由表中有 1.16/32 和 1.0/24 两条路由,但是在 R2 看来 1.16/32 主机路由在 1.0/24 网段路由内,所以在向 R1 通告时只需要通告 1.0/24 ,所以在 R1 上根本看不到 1.16/32 的相关路由(哪怕这条路由本就是错的)
   在 R1 g0/0/1 接口抓包:
   
   观察发现 R2 的确在向 R1 通告时只通告了 1.0(无掩码信息) 网段
3. 在 R2 g0/0/1 接口抓包:
   R2 发出的包:
   
   R3 发出的包:
   
   稍等片刻后再次抓取 R2 与 R3 发出的包便出现与第一部分相同的情况,两台路由器共有的 1.0(无掩码信息) 网段均不再通告
   所以分析可得, R2 在收到 R3 发送的 1.16(无掩码信息,但实际上R3想要发出的是1.16/28) 路由条目时,用 R2 自身接口 g0/0/1 的 IP 的掩码(24)与 192.168.1.16 这个条目做匹配可得出:
   R1 g0/0/1接口的网络号:192.168.1.0
   192.168.1.16 的网络号:192.168.1.0
   发现网络号完全相同,所以 R2 判定 1.16(无掩码信息) 这条路由条目和自己处于相同网段,又因为 1.16(无掩码信息) 这个路由条目按照自身接口 IP 的 24 位掩码计算后发现其主机位不为零,所以 R2 认为 1.16(无掩码信息) 这条路由条目是与自己处于同一网段的一台 PC,所以在 R2 上 1.16 这条路由的掩码为 32 位,自然也就没有了通往 1.16/28 网段的路由
4. R4 通过 RIP 从 R3 收到的 1.0(无掩码信息) 网段路由被识别为了 24 位掩码的路由,但是在 R3 的路由表中可以看出 1.0/28 这个网段路由的掩码为 28 位,根本不存在 1.0/24 的网段路由,所以可以推断出, RIP v1 在收到标准的主类(A,B,C类)路由时,会直接将掩码对应的置为 8,16或24 ,所以在 R4 上即便自身接口 IP 的掩码为 28 位,但是在收到 1.0(无掩码信息的标准C类网段)网段路由时直接将掩码置为了 24 位(此情况与第二部分相同)

所以 R2 上产生 1.16/32 这条主机路由的原因是, R3 发送给 R2 的 1.16(无掩码信息) 这条路由条目不是标准的主类路由,所以 R2 不会直接将掩码置为 8,16或24 ,而是会拿自身 g0/0/1 接口 IP 的 24 位掩码和 1.16(无掩码信息) 这条路由做匹配得出网络号,然后发现网络号与自身接口的网络号相同,则 R2 认为 1.16(无掩码信息) 这条路由条目和自己处于相同网段内,又因为匹配完成后得出的主机位不为零,所以 R2 认为 1.16(无掩码信息) 这条路由是处于和自己相同网段内的一条主机路由,所以将这条路由的掩码置为了 32

• 在 R4 上 ping 192.168.3.2(PC1) ,然后在 R1 的 g0/0/0 接口抓包:
  
  发现 PC1 实际收到了 request 包并给与了回复

• 在 R4 上 ping 192.168.3.2(PC1) ,然后在 R2 的 g0/0/1 接口抓包:
  
  发现 response 包从 R2 发往 R3 时 R2 直接询问 1.18 的 MAC 地址(因为 R2 只有1.0/24 网段路由,没有更优的1.16/28 网段路由),根本没有继续发往 1.16/28 网段,又因为 ARP 是二层隔绝的,所以 ARP 不可能收到对应的回复, R2 也就无法继续将 response 发送给 1.18 ,所以在 R4 上根本 ping 不通 PC1