关于静态路由和ARP协议冲突的分析
2013-08-02 16:22
316 查看
文档所有,权属个人;若有转载,注明出处,侵权必究。(文档撰写:蚯蚓)
静态路由协议:协议冲突(静态路由协议、arp协议)一、案例研究实验拓扑中,R3模拟服务器,网桥连接R1、R2。因为网桥还有其他的连接,负责的流量十分大。而又R1传送的数据有十分重要,所以,网络管理员便在R1上专门配置了一条主机路由,只向R2的Fa0/0口发送数据。二、
实验拓扑
拓扑中连接网桥的是12.1.1.0/24网段,R1、R2之间直接连接的是21.1.1.0/24网段。三、实验配置R1:no ip domain lookup//关闭域名解析interface FastEthernet0/0ip address 12.1.1.1 255.255.255.0//为Fa0/0口配置IP地址interface FastEthernet0/1ip address 21.1.1.1 255.255.255.0//为Fa0/1口配置IP地址ip route 12.1.1.3 255.255.255.255 21.1.1.2//配置主机路由line con 0exec-timeout 0 0//防止超时登出logging synchronous//防止日志解析打断命令行R2:no ip domain lookupinterface FastEthernet0/0ip address 12.1.1.2 255.255.255.0interface FastEthernet0/1ip address 21.1.1.2 255.255.255.0interface Ethernet1/0ip address 23.1.1.2 255.255.255.0line con 0exec-timeout 0 0logging synchronousR3:no ip domain lookupinterface FastEthernet0/0ip address 12.1.1.3 255.255.255.0ip route 12.1.1.1 255.255.255.255 12.1.1.2//配置去往12.1.1.2主机的路由条目line con 0exec-timeout 0 0logging synchronous此时,我们来查看R1上的路由表:Codes: C - connected, S - static, R - RIP, M - mobile, B - BGPD- EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1- OSPF NSSA external type 1, N2 - OSPF NSSA external type 2E1- OSPF external type 1, E2 - OSPF external type 2i- IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2ia- IS-IS inter area, * - candidate default, U - per-user static routeo- ODR, P - periodic downloaded static routeGateway of last resort is not set21.0.0.0/24is subnetted, 1 subnetsC21.1.1.0 is directly connected, FastEthernet0/112.0.0.0/8is variably subnetted, 2 subnets, 2 masksC12.1.1.0/24 is directly connected, FastEthernet0/0S12.1.1.3/32 [1/0] via 21.1.1.2注意红色加粗的下划线字体,路由器会发现静态路由精确匹配到了32位,并且与直连12.1.1.0/24网段位于同一网段,所以,路由器选择从Fa0/1发送数据。按照我们学习的只是,数据包是可以到达R3,但是事实并非如此,我们在R1上测试:R1(config)#do ping 12.1.1.3Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 12.1.1.3, timeout is 2 seconds:.....Success rate is 0 percent (0/5)从红色字体中可以看出,没有一个数据包传送出去之后并没有收到回复信息。利用trace命令,来对R1发送的数据包进行追踪。
我们可以发现,数据包一直在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地址:
显然,cc0a:066c:0000这个MAC地址是R1Fa0/0接口的MAC地址。思考既然问题已经查明,那应该怎样解决。管理员的想法并没有错,因为网络中的流量分布,需要通过分流部署,来减轻网桥的负担。同时,这样的网络部署,可以保护重要数据的安全可靠。问题出在协议的冲突上,在R1上同时使用静态路由和代理ARP导致了问题的发生,所以,可以通过关闭R1上的代理ARP,便可以解决问题。R1:
在R1的Fa0/0接口下关闭ARP代理,此时,我们再来ping 12.1.1.3:
我们发现,还是没有成功通信。在ARP表中,ARP条目一旦存在,都有其一定的存活时间,这个时候,如果不对ARP表进行清理,它就会一直存在。我们到R2上进行ARP表的清理R2:
清理完成以后,我们可以发现失去了12.1.1.3的ARP映射,此时我们再到R1上进行测试R1:
第一个包丢失是因为在进行ARP请求广播,R1的Fa0/0不做应答,所以在R2上存在的映射就是R3发给R2的正确应答。通信成功。至此,试验成功,问题解决。
静态路由协议:协议冲突(静态路由协议、arp协议)一、案例研究实验拓扑中,R3模拟服务器,网桥连接R1、R2。因为网桥还有其他的连接,负责的流量十分大。而又R1传送的数据有十分重要,所以,网络管理员便在R1上专门配置了一条主机路由,只向R2的Fa0/0口发送数据。二、
实验拓扑
拓扑中连接网桥的是12.1.1.0/24网段,R1、R2之间直接连接的是21.1.1.0/24网段。三、实验配置R1:no ip domain lookup//关闭域名解析interface FastEthernet0/0ip address 12.1.1.1 255.255.255.0//为Fa0/0口配置IP地址interface FastEthernet0/1ip address 21.1.1.1 255.255.255.0//为Fa0/1口配置IP地址ip route 12.1.1.3 255.255.255.255 21.1.1.2//配置主机路由line con 0exec-timeout 0 0//防止超时登出logging synchronous//防止日志解析打断命令行R2:no ip domain lookupinterface FastEthernet0/0ip address 12.1.1.2 255.255.255.0interface FastEthernet0/1ip address 21.1.1.2 255.255.255.0interface Ethernet1/0ip address 23.1.1.2 255.255.255.0line con 0exec-timeout 0 0logging synchronousR3:no ip domain lookupinterface FastEthernet0/0ip address 12.1.1.3 255.255.255.0ip route 12.1.1.1 255.255.255.255 12.1.1.2//配置去往12.1.1.2主机的路由条目line con 0exec-timeout 0 0logging synchronous此时,我们来查看R1上的路由表:Codes: C - connected, S - static, R - RIP, M - mobile, B - BGPD- EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1- OSPF NSSA external type 1, N2 - OSPF NSSA external type 2E1- OSPF external type 1, E2 - OSPF external type 2i- IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2ia- IS-IS inter area, * - candidate default, U - per-user static routeo- ODR, P - periodic downloaded static routeGateway of last resort is not set21.0.0.0/24is subnetted, 1 subnetsC21.1.1.0 is directly connected, FastEthernet0/112.0.0.0/8is variably subnetted, 2 subnets, 2 masksC12.1.1.0/24 is directly connected, FastEthernet0/0S12.1.1.3/32 [1/0] via 21.1.1.2注意红色加粗的下划线字体,路由器会发现静态路由精确匹配到了32位,并且与直连12.1.1.0/24网段位于同一网段,所以,路由器选择从Fa0/1发送数据。按照我们学习的只是,数据包是可以到达R3,但是事实并非如此,我们在R1上测试:R1(config)#do ping 12.1.1.3Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 12.1.1.3, timeout is 2 seconds:.....Success rate is 0 percent (0/5)从红色字体中可以看出,没有一个数据包传送出去之后并没有收到回复信息。利用trace命令,来对R1发送的数据包进行追踪。
我们可以发现,数据包一直在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地址:
显然,cc0a:066c:0000这个MAC地址是R1Fa0/0接口的MAC地址。思考既然问题已经查明,那应该怎样解决。管理员的想法并没有错,因为网络中的流量分布,需要通过分流部署,来减轻网桥的负担。同时,这样的网络部署,可以保护重要数据的安全可靠。问题出在协议的冲突上,在R1上同时使用静态路由和代理ARP导致了问题的发生,所以,可以通过关闭R1上的代理ARP,便可以解决问题。R1:
在R1的Fa0/0接口下关闭ARP代理,此时,我们再来ping 12.1.1.3:
我们发现,还是没有成功通信。在ARP表中,ARP条目一旦存在,都有其一定的存活时间,这个时候,如果不对ARP表进行清理,它就会一直存在。我们到R2上进行ARP表的清理R2:
清理完成以后,我们可以发现失去了12.1.1.3的ARP映射,此时我们再到R1上进行测试R1:
第一个包丢失是因为在进行ARP请求广播,R1的Fa0/0不做应答,所以在R2上存在的映射就是R3发给R2的正确应答。通信成功。至此,试验成功,问题解决。
相关文章推荐
- 关于MFC库和CRT库冲突的分析
- 关于MFC库和CRT库冲突的分析
- 关于 byval 与 byref 的区别分析总结
- 老码农:关于需求分析的几点体会
- 关于Entity Framework更新的几种方式以及可能遇到的问题(附加类型“Model”的实体失败,因为相同类型的其他实体已具有相同的主键值)在使用 "Attach" 方法或者将实体的状态设置为 "Unchanged" 或 "Modified" 时如果图形中的任何实体具有冲突键值,则可能会发生上述行为
- SVN多用户同时修改一个文件冲突过程分析及解决方法(非用锁方法)
- java学习,关于接口理解,实例分析
- 关于Android 的内存泄露及分析(转)
- Openstack研究:关于实例不能创建的分析:
- 关于Android ScrollView嵌套WebView冲突问题
- 关于 self 和 super 在oc 中 的疑惑 与 分析
- 黑马程序员--关于交通灯管理系统的分析和思考
- 关于错误 syntax error : missing ';' before 'type' 的分析
- 下拉刷新和UITableView的section headerView冲突的原因分析与解决方案
- 关于RadioGroup和Scrollview联动带来的事件冲突
- 关于hadoop集群的简单性能测试——mapreduce性能,hive性能,并行计算分析(原创)
- 关于《OPENCL异构并行计算》中卷积优化的分析
- 关于TFT、AMLED、IPS,ASV 、SLCD 屏幕的优缺点分析
- web客户端,服务端,android客户端关于JSON的使用分析