对外映射应用服务器问题处理案例分享

15

前言

随着社会信息化的快速发展,网络中的互联设备趋于复杂化,给网络管理员排除网络故障也带了较大的挑战。网络一旦出现问题,排查起来非常困难,甚至无从下手,难以找到问题根源,如何进行问题定位,一个较好的排查故障的方法对于网络管理员极其重要。

本次简单分享一个网络故障排除法的案例,通过网络故障现象进行初步定位,配合一些有必要的测试工作,然后通过准确抓包分析,再快速定位故障点,最后解决问题。

1

故障描述

2018年x月x日某客户提出需求,需要将新上线的内部服务器10.0.183.10:1521在外部路由器上映射至10.1.67.142:1521,但部署后发现在外部终端10.0.64.50无法访问映射后的服务器应用端口10.1.67.142:1521。

2

处理过程

排除法是一个较好的处理方法,本次便采用排除法来进行网络排障。

现场网络拓扑图

在外单位的终端10.0.64.50的终端上进行测试访问,显示访问失败,但在外单位的终端10.0.79.99上进行访问测试,能够正常访问。下图为外单位终端10.0.64.50测试访问10.1.67.142:1521的结果。

首先排查各网络设备之间网络联通性,各互连网络设备之间能够互ping通。从外部终端10.0.64.50能够ping通10.1.67.142。

为了继续排查问题出在哪,在SW1上面布署一台测试应用服务器10.0.184.11:1521,在对外服务器变更10.1.67.142:1521映射至10.0.184.11:1521,然后在外部终端10.0.64.50去访问10.1.67.142:1521,能够正常访问,说明问题很可能在内部SW1与应用服务器10.0.183.10之间

决定抓取内部SW2上联内部SW1的物理接口G0/0/1的包,以确定问题出在哪。用外部终端10.0.64.50/10.0.79.99同时访问10.1.67.142:1521,然后抓包发现10.0.64.50访问10.0.183.10:1051有请求包,无回应包;而10.0.79.99访问10.0.183.10:1051既有请求包,又有回应包。

从抓包现象可判定问题很可能出现在内部SW2上面,继续检查内部SW2的路由,在SW2上tracert 10.0.64.50发现下一跳没有跳至内部SW1,继续核对内部SW2的路由表,发现有一条静态路由10.0.64.0/255.255.255.0并没有指向内部SW1。

ip route 10.0.64.0 255.255.255.0 10.0.172.3,而10.0.172.3不是内部SW1与内部SW2互连的IP地址。

新建一条主机路由10.0.64.50/32指向内部SW1,请外部终端10.0.64.50测试访问10.1.67.142:1521,测试访问正常。

3

结论和建议

遇到此类问题,先检查互联网络设备之间的网络联通性,然后使用排除法,一步步缩小范围,确认导致问题所在的设备范围后,用正确的方法进行测试,解决之。

—END—

  • 发表于:
  • 原文链接:https://kuaibao.qq.com/s/20181105G1B75J00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券