文档适用产品型号：SRX5308，FVS318G，FVS318N，FVS336G

拓扑

配置参数

1. FVS318G NAT模式，外网接口以实际情况配置，本例拟为123.123.123.122/30，默认路由123.123.123.121， LAN IP 172.16.0.1
2. FVS318N路由模式(由于禁用了NAT，设备已无所谓哪一侧是WAN，哪一侧是LAN，本例中我们会仍然沿用设备前面板印刷接口名称)，WAN IP 172.16.0.100/24， LAN IP 172.16.1.1/24，默认路由 172.16.0.1
3. SRX5308路由模式，WAN IP 172.16.1.100/24，LAN IP 172.16.2.1/24，默认路由172.16.1.1
4. PC1 IP 172.16.2.2/24 网关172.16.2.1
5. PC2 IP 172.16.0.7/24 网关 172.16.0.1
6. 三台防火墙LAN-WAN间进出站均allow any any
7. 三台防火墙各接口响应ping，允许内外网登录
8. 三台防火墙使用RIPv1协议互通路由信息。
9. 三台防火墙均关闭DHCP，拓扑中涉及所有接口或网卡IP手工配置。
10. PC2网卡MAC为CadmusCo_XX:6a:70
11. FVS318G LAN MAC为Netgear_XX:e1:b1
12. FVS318N WAN MAC为Netgear_XX:bf:ef

故障描述

当FVS318G LAN管理地址配置为24位掩码时PC1可以ping通PC2，可以访问互联网
当FVS318G LAN管理地址设为16位掩码时PC1无法ping通PC2

排错思路与步骤

1. 查看FVS318G路由表，寻找子网掩码的修改对路由表的影响.下图为LAN掩码为24位时FVS318G的路由表，其中有前往网络172.16.2.0的条目
    
   

   Interface Name	Destination	Mask	Gateway	Metric
   BroadBand	123.123.123.121	255.255.255.252	0.0.0.0	0
   BroadBand	123.123.123.121	255.255.255.252	123.123.123.122	1
   LAN	172.16.2.0	255.255.255.0	172.16.0.100	3
   LAN	172.16.0.0	255.255.255.0	0.0.0.0	0
   LAN	172.16.0.0	255.255.255.0	172.16.0.1	1
   LAN	172.16.1.0	255.255.255.0	172.16.0.100	2
   BroadBand	default	0.0.0.0	0.0.0.0	0

   
    
2. 将FVS318G LAN掩码改为16位并查看路由表
    
   

   Interface Name	Destination	Mask	Gateway	Metric
   BroadBand	123.123.123.121	255.255.255.252	0.0.0.0	0
   BroadBand	123.123.123.121	255.255.255.252	123.123.123.122	1
   LAN	172.16.0.0	255.255.0.0	0.0.0.0	0
   LAN	172.16.0.0	255.255.0.0	172.16.0.1	1
   BroadBand	default	0.0.0.0	0.0.0.0	0

   
    
3. 在FVS318G LAN掩码为16位时，PC2 ping往172.16.2.2的数据包会根据PC2的默认路由丢给172.16.0.1(FVS318G LAN)
4. 由于此时FVS318G LAN掩码为16位， FVS318G会认为172.16.2.2与自己的LAN在同一网络，FVS318G将尝试根据ARP表封装172.16.2.2的数据链路层地址，并将数据直接丢到FVS318G所认为直连的PC1。
5. 由于FVS318G ARP表中没有172.16.2.2条目，设备将会以广播形式请求172.16.2.2 MAC地址，我们可以在FVS318G的LAN侧抓包以验证这一观点，
   
6. 如上图所示，由于FVS318G无法知晓172.16.2.2的链路层地址，目的MAC地址也就无从填写，ping包甚至从来都不会从FVS318G的LAN侧发送出去.
7. 在FVS318G LAN侧抓包时我们会发现，除了FVS318G LAN发出的ARP请求外，PC2也在请求172.16.2.2的MAC地址
   
8. 为了说明步骤7的成因，我们将FVS318G LAN掩码改为24位，从PC2 ping往PC1并在PC2上抓包查看
   
9. 对比步骤8截图中的数据包7和数据包14
   
10. 步骤8与9的截图中我们可以发现，同样是由172.16.0.7发往172.16.2.2的数据包，数据包7与数据包14的目的MAC地址是不同的.数据包7目的MAC为FVS318G的LAN;数据包14目的地址为FVS318N的WAN。
11. 造成上述这一改动的原因是步骤8中的数据包10，我们来看一下数据包10的详细内容
    
12. 步骤11中我们可以看到，数据包10(ICMP重定向)由FVS318G发往PC2，告知PC2去往172.16.2.2(PC1)的数据包可以直接丢向172.16.0.100(这是因为路由器发现自己不是最优路径)。
13. 当传递的数据包不是源地址路由数据包，且路由器内核被设置为可发送ICMP重定向的情况下，如果数据包源IP与下一跳IP在同一网络或者路由器即将转发数据包的接口与收到这个数据包的接口相同时，路由器会在转发这个数据包后向数据来源发送一个ICMP重定向，以通告更优路径。
14. 本例中，如果PC2对应网卡的secure_redirect与accept_redirect设置为TURE，且ICMP重定向的发送源为PC2的默认网关(172.16.0.1)时，PC2会接受这条ICMP重定向，并将发往PC1数据包的下一跳改为FVS318N WAN口(如数据包14所示).在步骤8的截图中可见，PC2在接收到数据包10( ICMP重定向)后在数据包11中请求了新的下一跳(FVS318N WAN)数据链路层地址，并在紧接着的ping请求(数据包14)中得以体现。
    
15. 接下来我们可以在PC2上验证这一更新，首先ping PC1。
    
16. 参考步骤8与步骤15的截图可知，首2数据包被发往了默认网关(FVS318G LAN)，在PC2收到了来自FVS318G(172.16.0.100)的ICMP重定向后，余下的数据包将直接丢给FVS318N WAN口(172.16.0.100)。
17. 此时您可能期望在PC2的路由表中看到更新的H路由条目以验证ICMP重定向对PC2的改变，但结果可能令人失望。
    
18. PC2的路由表并未得以更新，原因是在转发数据包时，Linux kernel将优先匹配路由缓存，而后才是路由表.ICMP重定向更改的恰为此缓存表。
    
19. 至此我们也回答了步骤7中提出的问题，PC2正是由于收到了FVS318G发出的ICMP重定向，所以试图将数据包直接发往PC1(172.16.2.2)，故而发送ARP请求PC1的链路层地址。