静态路由协议和ARP协议冲突

OPENLAB西安实验室静态路由协议:协议冲突（静态路由协议、arp协议）一、案例研究实验拓扑中，R3模拟服务器，网桥连接R1、R2。因为网桥还有其他的连接，负责的流量十分大。而又R1传送的数据有十分重要，所以，网络管理员便在R1上专门配置了一条主机路由，只向R2的Fa0/0口发送数据。二、实验拓扑拓扑中连接网桥的是12.1.1.0/24网段，R1、R2之间直接连接的是21.1.1.0/24网段。三、实验配置R1：noipdomainlookup//关闭域名解析interfaceFastEthernet0/0ipaddress12.1.1.1255.255.255.0//为Fa0/0口配置IP地址interfaceFastEthernet0/1ipaddress21.1.1.1255.255.255.0//为Fa0/1口配置IP地址iproute12.1.1.3255.255.255.25521.1.1.2//配置主机路由linecon0exec-timeout00//防止超时登出loggingsynchronous//防止日志解析打断命令行R2：noipdomainlookupinterfaceFastEthernet0/0ipaddress12.1.1.2255.255.255.0interfaceFastEthernet0/1ipaddress21.1.1.2255.255.255.0interfaceEthernet1/0ipaddress23.1.1.2255.255.255.0linecon0exec-timeout00loggingsynchronousR3：noipdomainlookupOPENLAB西安实验室interfaceFastEthernet0/0ipaddress12.1.1.3255.255.255.0iproute12.1.1.1255.255.255.25512.1.1.2//配置去往12.1.1.2主机的路由条目linecon0exec-timeout00loggingsynchronous此时，我们来查看R1上的路由表：Codes:C-connected,S-static,R-RIP,M-mobile,B-BGPD-EIGRP,EX-EIGRPexternal,O-OSPF,IA-OSPFinterareaN1-OSPFNSSAexternaltype1,N2-OSPFNSSAexternaltype2E1-OSPFexternaltype1,E2-OSPFexternaltype2i-IS-IS,su-IS-ISsummary,L1-IS-ISlevel-1,L2-IS-ISlevel-2ia-IS-ISinterarea,*-candidatedefault,U-per-userstaticrouteo-ODR,P-periodicdownloadedstaticrouteGatewayoflastresortisnotset21.0.0.0/24issubnetted,1subnetsC21.1.1.0isdirectlyconnected,FastEthernet0/112.0.0.0/8isvariablysubnetted,2subnets,2masksC12.1.1.0/24isdirectlyconnected,FastEthernet0/0S12.1.1.3/32[1/0]via21.1.1.2注意红色加粗的下划线字体，路由器会发现静态路由精确匹配到了32位，并且与直连12.1.1.0/24网段位于同一网段，所以，路由器选择从Fa0/1发送数据。按照我们学习的只是，数据包是可以到达R3，但是事实并非如此，我们在R1上测试：R1(config)#doping12.1.1.3Typeescapesequencetoabort.Sending5,100-byteICMPEchosto12.1.1.3,timeoutis2seconds:.....Successrateis0percent(0/5)从红色字体中可以看出，没有一个数据包传送出去之后并没有收到回复信息。利用trace命令，来对R1发送的数据包进行追踪。OPENLAB西安实验室我们可以发现，数据包一直在12.1.1.1和21.1.1.2之间记性传送，发生了类似环路的现象。但问题具体出在哪里，就需要去了解数据链路层的工作机制。当R2接收到从R1的Fa0/1口过来的数据包时，R2发现目的网络是自己的直连网段。R2第一个包发送ARP请求，因为是连在网桥上的，R1也会接收到请求包。R1发现请求主机ip地址存在自己的路由条目中，就发送了一个ARP应答（代理ARP）。由于网桥的延时，R1发送的ARP应答比R3回复的ARP应答要迟，后到的ARP应答就覆盖了原先ARP表中的条目。这里来解释一下代理ARP，当网络中的主机收到ARP请求时，发现自身身后的链路网段中包含有该ARP请求的ip地址，就会伪装成请求的ip地址主机回复请求包。此时，R2得到了一条ARP映射，ip地址为R3的Fa0/0接口ip地址，但是MAC对应的确是R1的Fa0/0接口的MAC地址。此时，得到ARP应答的R2就会将该条信息放入ARP表中，以后通往12.1.1.3的所有数据，都通过映射发向了R1的Fa0/0口。我们来查看R2的ARP表：从截图中我们可以发现，在R2的ARP表中，12.1.1.3（即R3的Fa0/0）的MAC地址为cc0a：066c：0000（冒号分十六进制）。我们再到R3中查看Fa0/0接口的MAC地址：从截图中我们发现，R3的Fa0/0接口MAC地址为cc0c：066C：0000。再来看R1中的MAC地址表：从R1的ARP表中看到，cc0a：066c：0000是ip地址为12.1.1.1接口的MAC地址。我们再来查看该接口的MAC地址：OPENLAB西安实验室显然，cc0a：066c：0000这个MAC地址是R1Fa0/0接口的MAC地址。思考既然问题已经查明，那应该怎样解决。管理员的想法并没有错，因为网络中的流量分布，需要通过分流部署，来减轻网桥的负担。同时，这样的网络部署，可以保护重要数据的安全可靠。问题出在协议的冲突上，在R1上同时使用静态路由和代理ARP导致了问题的发生，所以，可以通过关闭R1上的代理ARP，便可以解决问题。R1：在R1的Fa0/0接口下关闭ARP代理，此时，我们再来ping12.1.1.3：我们发现，还是没有成功通信。在ARP表中，ARP条目一旦存在，都有其一定的存活时间，这个时候，如果不对ARP表进行清理，它就会一直存在。我们到R2上进行ARP表的清理R2：清理完成以后，我们可以发现失去了12.1.1.3的ARP映射，此时我们再到R1上进行测试R1：第一个包丢失是因为在进行ARP请求广播，R1的Fa0/0不做应答，所以在R2上存在的映射就是R3发给R2的正确应答。通信成功。至此，试验成功，问题解决。