输入您的问题查找答案
   
 
相关文库文档
更多相关文库文档 >>
联系客服
在线技术支持
客户服务热线:

电话销售热线:

服务时间(法定节假日除外):
家庭产品:
周一至周六:9:00-18:00
商用产品:
周一至周五:9:00-18:00
商用网络动态

与 NETGEAR 监控专用交换机亲密接触

选择德才兼备的 PoE 交换机

NETGEAR 交换机助力聊城第二人民医院智能监控建设

更多动态 >>

网件文库 » VPN 及安全产品  »  ICMP重定向排错
ICMP重定向排错

编号:40112       来自:NetGear       更新日期:2015-03-01       访问数量:6362

文档适用产品型号: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的链路层地址。


序号 no.

日期 date

跟进人

摘要 summary

1

2012-09-18

Vicissi

文档创建

 

  
 
以上内容是否为您所需要的答案?
以上内容是否清晰、简明和易于理解的?
您是如何知道网件社区的?