对代理ARP技术的误读、无法完成代理ARP实验的故障分析
对代理ARP技术的误读、无法完成代理ARP实验的故障分析
问题的提出:
网络工程技术人员和或者学习者面对ARP代理技术时,通常能理解ARP代理的作用和技术要点是什么,但是无法根据技术描述去实现ARP代理的功能!
首先来看一般对代理ARP的定义:
通常根据上述文字的描述,就意味着在如图1所示的环境中,主机192.168.2.2/24可以在不配置默认网关的情况下成功的与路由器R2的192.168.3.2/24通信。其实这种理解是没有错的,但是当用户使用实验来证实代理ARP的作用时,结果却非常的意外,如果在主机192.168.2.2/24上不配置任何网关,路由器R1启动了代理ARP功能,不能让192.168.2.2访问192.168.3.2,对,不能,永远不能,那这是为什么呢,难道是理论定义有错,现在我们来做分析。
首先看验证代理ARP技术时各个通信节点上的原始配置:
计算机192.168.2.2上的配置,如图2所示,确定只配IP地址不配置默认网关:
路由器R1和R2的配置如下所示,默认情况下路由器的代理ARP技术是被启用,可以通过指令showip interface e1/0在路由器R1上来查看并确认,R1的E1/0接口的代理ARP的确是被启动的,如图3所示。
路由器R1的配置:
interfaceEthernet1/0
ip address 192.168.2.1 255.255.255.0
interfaceEthernet1/1
ip address 192.168.3.1 255.255.255.0
routerrip
version 2
network 192.168.2.0
network 192.168.3.0
no auto-summary
路由器R2的配置:
interface Ethernet1/1
ipaddress 192.168.3.2 255.255.255.0
router rip
version 2
network 192.168.3.0
noauto-summary
按照上述的原始配置,那么主机192.168.2.2/24在没配置默认网关的情况下应该就能ping通192.168.3.2,但事实上,如图4所示,结果出乎意外,192.168.2.2根本就无法ping通192.168.3.2。
然后大众会发出几种对故障的猜想和推论:
1 关于代理ARP技术的理论的定义不正确,所以导致了无法完成的实验
能被列入RFC文档的论述,都是得到了比应用级更高的专家(研发级)共同认同的公理,虽然不能说100%就是定论,但是在多数情况下是不被推翻的,所以由于这种原因产生故障的可能性不太,要么就是应用级人员没有彻底理解文档,要么就是实施有误。
2 路由器IOS存在bug(漏洞),所以无法完成实验
种个厂商的IOS的确会存在bug(漏洞),但是这种bug通常会被顶尖的高手和***所发现,然后厂商会立即作出反应,对bug进行修复,并公开bug,典型的情况就是用户在查看IOS版本时,比如出现IOS12.2(14),说明这个版本已经经过了14次的修改,修改的次数越多,存在的bug就越少,所以对于代理ARP这种技术存在bug,而没被厂商发现的可能性太小了。
3 不同厂商的设备可能对ARP代理的定义和限制是不同的
这种原因就更不可能,因为网络公理,就相当于数学几何中的证明公理一样,它具备开放和开源性,差别只在于实现的指令和配置方式不同而已,再加上OSI模型的产生,所以所有厂商的技术,除私有特性技术外,都是一样,且必须一样,不然它将无法满足市场兼容性的需求,最终被踢出局。所以这种可能基本不会发生。
注意:任何一种对故障原因的分析和判别,都必须建立在数据、理论、取证三大元素之上,而且三大元素必须联动起来形成一种对故障现象非常有针对的“链条线”!尊重实验事实!
故障原因的分析思路与解决方案:
根据代理ARP的定义,如果主机192.168.2.2/24没有配置默认网关,那么它发出对192.168.3.2的ARP请求,将被路由器的R1的E1/0接口所接收,然后R1将代理源主机192.168.2.2去请求192.168.3.2的MAC地址,然后完成不同网络的通信。
一个关键过程是:如果路由器R1确认已经启动代理ARP功能,那么主机192.168.2.2是否发送对192.168.3.2的ARP请求,如果没发送,为什么?如果发送,路由器R1是否成功的执行了代理ARP的这个过程,并将结果返回给主机192.168.3.2,所以这是需要取证的第一个过程,所以在需要在主机192.168.2.2ping192.168.3.2时取证这个过程,如下图5所示,对ping行为的取证时,整个过程主机192.168.2.2都没有发送任何ARP请求,既然通信源主机对目标192.168.3.2的ARP请求都没有,何谈代理ARP的过程,所以确认实验故障是在主机192.168.2.2上,那么,为什么会出现这个故障,主机192.168.2.2为什么不发送针对192.168.3.2的ARP请求。
主机192.168.2.2/24不发送ARP请求的原因:
基于IPv4的主机在发送ARP请求之前,它会将目标的IP地址拿来和自已的子网掩码求“与”运算,如果目标主机的IP地址与自己的子网掩码在求“与”运算后,确定目标主机和自己的IP不在同一子网,那么该主机在没有配置默认网关的情况下不会发送任何ARP请求,如果配置了默认网关那么该主机会把ARP请求发送给默认网关,在代理ARP这个实验中,主机192.168.2.2子网掩码为255.255.255.0,请大家注意看目标主机192.168.3.2与自己的子网掩码求与得出的网络ID是192.168.3.0;而自己属于192.168.2.0,并没有配置任何默认网关,所以主机192.168.2.2/24根本不会发送任何ARP请求,所以路由器R1上的代理ARP功能根本就没法工作起来,实验怎会不失败!
故障解决方案并验证代理ARP的工作过程:
然仍保持不配置任何默认网关,然后如下图6所示,将主机的子网掩码改为255.255.0.0(即16位的子网),那么目标主机192.168.3.2和255.255.0.0求“与”运算,得到网络ID为192.168.0.0/16,而改变子网掩码后,自己也属于192.168.0.0/16这个网段,所以主机192.168.2.2可以发送ARP请求,即便是192.168.2.2没有配置默认网关,由于路由器R1的E1/0接口启动了代理ARP,所以R1将代理主机192.168.2.2去对192.168.3.2进行ARP解析,此时即便主机192.168.2.2没有配置任何默认网关也能成功的与192.168.3.2通信如图7所示。
如果用户在完成主机192.168.2.2改变子网掩码为16位,再ping192.168.3.2时,启动了协议分析器,那么就该能捕获如图8所示的数据帧,主机192.168.2.2在网络上询问谁是192.168.3.2的MAC,然后路由器在代理192.168.3.2对主机192.168.2.2做应答,R1使用自己E1/0的MAC地址来应答192.168.2.2。
致此为止,描述了对代理ARP故障的分析与解决,如果此时将路由器R1的E1/0接口的代理ARP功能关闭,会发生什么情况?答案是:主机192.168.2.2在没有配置默认网关的情况下再也无法ping通192.168.3.2,因为现在的连通性是代理ARP在维持。
关闭路由器R1的E1/0接口的代理ARP功能:
R1(config)#intee1/0
R1(config-if)#noip proxy-arp *关闭代理ARP功能
注意:在关闭代理ARP功能以后,用户在作新的测试之前,如下图10首先在主机上使用ARP –a功能,查看主机的ARP缓存,如果缓存还存有没关闭代理ARP功能之前的解析结果,那么将误导您对代理ARP实验的认识,所以需要使用ARP –d清除缓存中所有的ARP记录,确认主机的ARP表已经被清空,再次ping192.168.3.2,结果是由于在R1上关闭了代理ARP的功能,连通性丢失!
如果在这个过程中,您再次启动协议分析器分析实时通信的数据帧,如下图10所示,只有主机192.168.2.2的N个ARP请求,但是没有应答,原因就是关闭了路由器R1的代理ARP功能,又没有配置默认网关,所以不会对该请求作应答,除非再次启动路由器R1的代理ARP功能。
在实践环境中代理ARP一般用在什么地方,它的优势与不足是什么?
一般在一些网络工程环境中,工程师为了防止用户错误的配置默认网关而导致通信丢失,可能会启动代理ARP功能,或者需要实现对子网划分的透明化,或者三层冗余时也会启动ARP代理。代理ARP有一定冗错的作用,但本人强烈反对这种做法,因为这会造成额外的流量,并构成很大的安全风险特别是在有可能发生ARP欺骗***的环境中。建议使用其它的冗余方案来替代它!
对代理ARP技术的误读、无法完成代理ARP实验的故障分析相关推荐
- 区块链应用 | 高烧的区块链,被误读的区块链
"你都很难想象,还有什么东西能像区块链这样,在几天之内火遍整个创投圈,并且热度居高不下."一个资深创投圈的人不无感慨地说,"现在见面了的都是区块链." 为区块链 ...
- 微软“黑屏”被严重误读
我在前几天的博客中提到,微软所谓Windows"黑屏"并不值得恐慌,即使用户是盗版的,微软采取的是仍然是很温和的政策,不象有的软件过期往往直接就罢工.所谓"黑屏" ...
- 网络基础--ARP技术介绍
1. ARP的作用 ARP(Address Resolution Protocol,地址解析协议)是将IP地址解析为以太网MAC地址(或称物理地址)的协议.在局域网中,当主机或其它网络设备有数据要 ...
- 【ARP地址解析协议(完整解析过程、ARP欺骗、免费ARP、ARP代理)】-20211125【下】
目录 一.ARP地址解析协议 ARP地址解析协议:将IP地址解析为Mac地址 ARP地址解析过程 1)pc1首先会查询自身的ARP缓存表,是否存在目标ARP缓存条目. ARP请求报文(原理) 2)由于 ...
- 雷军:风口论一直被误读 我不是机会主义者(精品)
新浪科技讯 4月23日上午消息,2016中国绿公司年会在山东济南举行.雷军在现场做了以"小米的明天:新国货运动"为主题的演讲. 雷军认为,国货不被信任的真正问题出在效率上.国货流通 ...
- 最被中国人误读的37个消费符号,绝对值得一读
Backpackers 背包旅行 曾策划过<丽江的柔软时光>的大蕃茄传媒机构的张姗姗描述她所见到的国内所谓"背包客"的怪现象:一个曾经进藏两次的老背包客和朋友一起去杭州 ...
- 【产业互联网周报】多家国产芯片设计公司获得亿级融资;中芯国际首发过会;中兴通讯澄清“7nm芯片规模量产”:系误读...
关注ITValue,看企业级最新鲜.最价值报道! 图片来源@unsplash | [产业互联网周报是由钛媒体TMTpost发布的特色产品,将整合本周最重要的企业级服务.云计算.大数据领域的前沿趋势. ...
- 容易被误读的IOSTAT
iostat(1)是在Linux系统上查看I/O性能最基本的工具,然而对于那些熟悉其它UNIX系统的人来说它是很容易被误读的.比如在HP-UX上 avserv(相当于Linux上的 svctm)是最重 ...
- pythonencode_python的encode和decode误读总结
python的encode和decode误读总结 最近在学Python,对编码有个误解的地方 下面是错误的理解: encode():编码,将对象的编码转换为指定编码格式,按照字面理解,一直以为是其他编 ...
最新文章
- Zabbix企业应用之服务器硬件信息监控
- python程序的基本框架_Python PyQt学习随笔:PyQt主程序的基本框架
- [Python图像处理] 七.图像阈值化处理及算法对比
- U盘快速​安装Ubuntu系统
- oracle 48小时内_缺血性脑梗死后48小时内使用阿替普酶能够降低脑损伤程度
- 1042: 筛法求素数
- Linux中更新java代码命令,java代码执行linux命令
- 计算机视觉(CV)中HOG算法的主要步骤
- MySQL数据库学习资料(一)
- vdbench多主机运行指导
- 区块链-公钥生成地址
- oracle所有自带系统表,oracle常用系统表
- zblog实现评论显示IP归属地方法
- datax(13):源码解读Column-datax中的数据类型
- 物联网案例(二):物联网系统如何进行实时决策
- 福州大学计算机专业排名2018,福州大学2019年排名第64位 较2018年下降3名
- 维护一个大型开源项目,例如vscode是怎样的体验?
- 华为服务器gpu卡型号,GPU运算服务器推荐
- 【access control】常用访问控制模型比较
- php钓鱼怎么使用方法,初学钓鱼最详细的方法教程