一个网络问题的解决
2010-06-12 18:23
211 查看
网络环境:
前提:所有涉及的机器都允许ping通过,手头只有上图中的机器。
问题描述:在PC上ping 10.11.12.13,无法联通,但是在路由器上却能ping通10.11.12.13。
排查过程:
1. 确定路由器的ip_forward为1。
结论:路由器可以路由。
2. 确定路由器上配置正确的路由和NAT,以及清空路由器iptables的filter表。
结论:可以暂时忽略路由器故障。
3. 在2之后重新在PC上ping 10.11.12.13,仍然不通。
结论:大体上是PC的问题。
4. 在PC上删除除了到服务器10.11.12.13之外的任何路由,确认仅有一条到外网的路由。
目的:去掉尽可能多的干扰因素。
5. 在PC上ping路由器,同时在PC以及路由器上抓取icmp包,能ping通且PC上抓包成功,路由器上没有抓到任何包(tcpdump时要加上-e -vv参数,显示以太头)。
结论:a.路由生效了;
b.可能是ip冲突,但是不排除路由器网络协议栈故障。
6. 分析步骤6中tcpdump的结果中的以太头以及执行arp命令,得到目的地址的mac为A,然后在路由器上执行ip link show或者ifconfig得到相关ip地址的mac地址为B,A和B不等。
结论:数据包送往了错误的目的地。
7. 清除PC上的arp缓存,然后再次执行ping 192.168.1.1,同时在PC和路由器上抓取arp包,发现送出一个arp request,同一局域网内回复了两条arp reply。
结论:局域网内一定有ip冲突,定位一个问题,但是不排出是否还有其它问题导致网络不通。
8. 清除PC的arp缓存,然后用arp命令强行配置arp缓存而不是让PC自动学习:arp -s “192.168.1.1” B(步骤6中的B),之后重新ping 192.168.1.1,这次则通了,ping 10.11.12.13,也通了。
结论:导致网络不通的问题确实是由于ip冲突进而arp学习错误导致。
补充说明:由于我们无法确定和路由器冲突的主机的位置以及用途,因此不能拔掉冲突主机,又因为我们不知道详细网络ip配置情况,如果修改了路由器的ip则可能引入新的ip冲突,因此不能修改路由器的ip,故只能强制设置arp映射,这只是为了定位问题,实际中应该避免强制配置arp映射,几乎任何OS内核的TCP/IP协议栈的实现中,都会实现arp过程,包括学习,缓存,失效等事件。
注解:用traceroute命令可以查看数据通路情况,但是在某一跳打印一排”*”并不能说明链路不通,而可能是中间路由器屏蔽了ttl死亡的icmp回应或者回应超时导致,因此traceroute如果失败,一定要采取别的排错方案。现将traceroute的原理列为下:
本质上在linux中,traceroute是由UDP实现的,目的端口采用一个很大的端口。Traceroute的执行过程其实是一系列ttl死亡的过程,首先源主机发送一个ttl为1的udp包,然后到达去往目的地址的第一跳之后,转发之前,递减ttl之后发现ttl为0了,因此回应一个ttl已死的icmp报告,源主机接收后视为第一跳,打印之,接下来发送ttl为n++(n>1)的udp数据包…traceroute有一个等待时间参数-w waittime,并且每一个ttl重复次数参数-q nqueries,一般默认每个ttl尝试发送3个udp包,每次等待waittime时间,等一次不回应icmp则打印一个”*”, nqueries次都不回应者则将ttl+1继续,因此如果一路上所有的路由器都屏蔽了ttl已死的回应或者发送udp数据包和中间路由器发送ttl已死回应的间隔大于waittime(这是可能的,很多路由器将回应这种icmp数据包视为额外的行为,因此将之安排在优先级比较低的内核线程中执行,回复超时是经常的事)的话,那么源主机将完全打印”* * * …”,但是最终链路还是通的,数据到达目的地时会回应一个“端口不可达”消息,如果想尝试一下上述论述,请执行:traceroute W -w M -q N,W尽可能远,不易达,M尽可能小,N随意,结果几乎是很多行的”*”,每行N个,如果去往W的网络异常顺利,则也有可能出现不是全*的行,总之,traceroute只是能给出一个大致的路线,并不是唯此一条,甚至同一次执行traceroute中,ttl为n+1时所走的路由和ttl为n时所走的路由都有可能不同。在windows中tracert发送的是一个icmp request的数据包,收到icmp reply时停止,并不是通过udp实现的,但是ttl死亡机制和linux一致。
因此,网络排错的步骤中使用的命令一般为:traceroute/tracert,netstat,ping,iptables,route,ifconfig ,ip,arp,tcpdump。
本文出自 “我来,我看,我征服” 博客,请务必保留此出处http://dog250.blog.51cto.com/2466061/1271829
前提:所有涉及的机器都允许ping通过,手头只有上图中的机器。
问题描述:在PC上ping 10.11.12.13,无法联通,但是在路由器上却能ping通10.11.12.13。
排查过程:
1. 确定路由器的ip_forward为1。
结论:路由器可以路由。
2. 确定路由器上配置正确的路由和NAT,以及清空路由器iptables的filter表。
结论:可以暂时忽略路由器故障。
3. 在2之后重新在PC上ping 10.11.12.13,仍然不通。
结论:大体上是PC的问题。
4. 在PC上删除除了到服务器10.11.12.13之外的任何路由,确认仅有一条到外网的路由。
目的:去掉尽可能多的干扰因素。
5. 在PC上ping路由器,同时在PC以及路由器上抓取icmp包,能ping通且PC上抓包成功,路由器上没有抓到任何包(tcpdump时要加上-e -vv参数,显示以太头)。
结论:a.路由生效了;
b.可能是ip冲突,但是不排除路由器网络协议栈故障。
6. 分析步骤6中tcpdump的结果中的以太头以及执行arp命令,得到目的地址的mac为A,然后在路由器上执行ip link show或者ifconfig得到相关ip地址的mac地址为B,A和B不等。
结论:数据包送往了错误的目的地。
7. 清除PC上的arp缓存,然后再次执行ping 192.168.1.1,同时在PC和路由器上抓取arp包,发现送出一个arp request,同一局域网内回复了两条arp reply。
结论:局域网内一定有ip冲突,定位一个问题,但是不排出是否还有其它问题导致网络不通。
8. 清除PC的arp缓存,然后用arp命令强行配置arp缓存而不是让PC自动学习:arp -s “192.168.1.1” B(步骤6中的B),之后重新ping 192.168.1.1,这次则通了,ping 10.11.12.13,也通了。
结论:导致网络不通的问题确实是由于ip冲突进而arp学习错误导致。
补充说明:由于我们无法确定和路由器冲突的主机的位置以及用途,因此不能拔掉冲突主机,又因为我们不知道详细网络ip配置情况,如果修改了路由器的ip则可能引入新的ip冲突,因此不能修改路由器的ip,故只能强制设置arp映射,这只是为了定位问题,实际中应该避免强制配置arp映射,几乎任何OS内核的TCP/IP协议栈的实现中,都会实现arp过程,包括学习,缓存,失效等事件。
注解:用traceroute命令可以查看数据通路情况,但是在某一跳打印一排”*”并不能说明链路不通,而可能是中间路由器屏蔽了ttl死亡的icmp回应或者回应超时导致,因此traceroute如果失败,一定要采取别的排错方案。现将traceroute的原理列为下:
本质上在linux中,traceroute是由UDP实现的,目的端口采用一个很大的端口。Traceroute的执行过程其实是一系列ttl死亡的过程,首先源主机发送一个ttl为1的udp包,然后到达去往目的地址的第一跳之后,转发之前,递减ttl之后发现ttl为0了,因此回应一个ttl已死的icmp报告,源主机接收后视为第一跳,打印之,接下来发送ttl为n++(n>1)的udp数据包…traceroute有一个等待时间参数-w waittime,并且每一个ttl重复次数参数-q nqueries,一般默认每个ttl尝试发送3个udp包,每次等待waittime时间,等一次不回应icmp则打印一个”*”, nqueries次都不回应者则将ttl+1继续,因此如果一路上所有的路由器都屏蔽了ttl已死的回应或者发送udp数据包和中间路由器发送ttl已死回应的间隔大于waittime(这是可能的,很多路由器将回应这种icmp数据包视为额外的行为,因此将之安排在优先级比较低的内核线程中执行,回复超时是经常的事)的话,那么源主机将完全打印”* * * …”,但是最终链路还是通的,数据到达目的地时会回应一个“端口不可达”消息,如果想尝试一下上述论述,请执行:traceroute W -w M -q N,W尽可能远,不易达,M尽可能小,N随意,结果几乎是很多行的”*”,每行N个,如果去往W的网络异常顺利,则也有可能出现不是全*的行,总之,traceroute只是能给出一个大致的路线,并不是唯此一条,甚至同一次执行traceroute中,ttl为n+1时所走的路由和ttl为n时所走的路由都有可能不同。在windows中tracert发送的是一个icmp request的数据包,收到icmp reply时停止,并不是通过udp实现的,但是ttl死亡机制和linux一致。
因此,网络排错的步骤中使用的命令一般为:traceroute/tracert,netstat,ping,iptables,route,ifconfig ,ip,arp,tcpdump。
本文出自 “我来,我看,我征服” 博客,请务必保留此出处http://dog250.blog.51cto.com/2466061/1271829
相关文章推荐
- 一个网络问题的解决
- iOS 网络图片处理问题中,怎么解决一个相同的网络地址重复请求的问题
- 一个我很长时间才解决的关于xp与2000共享的网络问题
- 使用网络目录映射虚拟目录出现 500.19 权限不足问题的一个解决办法
- 用tensorflow 创建一个基于策略网络的Agent来解决CartPole问题
- 一个我很长时间才解决的关于xp与2000共享的网络问题
- 关于Windows 7启动后网络一直转的问题的一个解决方法
- 一个奇怪网络问题的解决:执行sql时客户端卡死
- 解决网络问题,提供解决方案,全力打造一个辉煌而有趣的网络安全交流群。
- 今天在网络上找到了一个比较好的解决Rhythmbox中文乱码的问题的方法
- 分享一个在XP系统的无线网络问题解决方法
- 解决window7下网络未识别问题,挺不错的一个办法
- 一个古怪的VISTA网络问题解决的坎坷经历
- 网络打印机提示的“功能地址0x造成了一个保护错误”问题解决方案
- 一个古怪的VISTA网络问题解决的坎坷经历
- DOS与网络问题的解决
- 解决学习tensorflow的LSTM模型中遇到一个版本不兼容问题
- 倒是在网上有看到显卡没装风尚导致该问题的,最后换了一个带风扇的显卡就解决的:
- 解决Angularjs中循环网络请求回调中值的调用问题