网络工程师成长日记314-汉中某银行工程感想

网络工程师成长日记314-汉中某银行工程感想

这是网络工程师成长日记的第314篇连载文章,记录网络工程师行业的点点滴滴,结交IT行业有缘之人

前日,老大带领我和老王,前往汉中对汉中某银行总行网络故障进行排错,在这次排错经历中,我受益匪浅

去之前,我们向刘工了解了下设备的情况

经过我们了解,设备是6500的H3C核心交换机两台,故障时两台核心设备,在工作期间经常发生主备前换,每次切换都出现长达几分钟的断网时间,网络状况十分不稳定,对于银行这样的单位,网络状况不稳定是十分致命的,得知事情的紧急重要性,我们片刻都不敢耽误,郑sir 也亲自开车将非我们一行4人送到了汉中。

6点出发,晚上9点,我们到达了目标地址,联系负责人,得知银行10点将自动打开所有的警报系统,所以今天想解决问题不可能了,因此我们只能找一宾馆暂行休息

晚上,我们对有可能发生的状况进行了小小的猜测,老大发给我们了一些H3c的文档,我们预习了下一些常用的命令

毕竟实战接触h3c的设备这还是第一次,而且还是核心设备,且是银行重要核心

稍微有什么不注意的地方将会引起巨大的损失,知道事情的严重性,我们自然也不敢怠慢啊。

由于对cisco 的命令行比较了解,且对理论掌握的还不错,因此在查阅h3c的文档的时候也没有出现太大的阻碍,很快,心里就有了底气,时间也不早了,还是早点休息吧,明天希望可以尽快的解决问题。

清早,我们来到银行,和负责人协商后,在其带领下,进入了银行的大楼,整个铺网的区域总共为9层,旁边还有一宿舍楼也连接进网络,我们对整个的网络环境进行了简单的了解。进入机房的时候后,首先映入眼帘的是一排一排的服务器,总共有5排每排都有67个服务器左右,仔细观察,全是清一色的IBM服务器,有FTP服务器,事后视频服务器(应该是监控录像的放服务器),还有很多部门的服务器这里就不介绍了。

在门左侧放了三个机柜,里面整齐的排放着路由和交换设备,布线整齐又调理,不愧是大单位的机房,整个机房干净整齐,还有十分全面的灭火系统。下来画一个草图来介绍下设备情况吧。

我第一次见到IDS设备,呵呵就是一铁壳子,防火墙的品牌我也没有记住,机架上的设备摆放大概就是这样的,和科技科科长进行简短的沟通,我们了解了下网络的拓扑情况和问题的故障。

这两台h3c 6500switch 核心交换机之间做了基于vlan间vrrp 冗余备份负载均衡,各楼层的设备通过楼层交换机连接进核心机房,大部分连接在h3c 6500的核交换机上,还有些连接在核心上面的3600交换机上。两台路由器是用来做链接外网冗余的设备,因此这次故障我们就不考虑路由上的问题。IDS 了解不是很多,只知道是安全设备而且很昂贵。

简短的沟通,也无法对整个网络的环境了解清楚,由于时间原因,当前是上班时间,设备都在运转,所以我们也不能做太大动作,通过科长的描述,连接在h3c6500 switch 的vlan 23 vlan 24 即 g5/0/23 5/0/24两个接口在近日来,系统经常报错,说流量太大,端口经常出现up down ,由于这两个端口的UP DOWN 影响到核心设备主 备之间发生切换,每次切换都会使网络不稳定,网络状态时好时坏,尤其影响到2楼营业厅的工作,考虑到责任的重大,为了不影响2楼设备的工作,暂时将23 24 两个接口拔下,网络变恢复了正常,但是这仍然不是长远之计。

简短了解,我们希望可以看到一个完整的拓扑,但是,由于规定原因,对方无法提供,我们只能通过谈话,和一些IP记录的表单,简单的对网络拓扑作出一个草图,这样才有利于我们对网络故障进行分析嘛。

23 连接的是9楼办公区,24 连接的是对面综合楼,据介绍,对面综合楼仅仅连接了一台电脑在使用网络,由于不能对网络做出任何的改动,因此我们决定先从23 24 下的用户群电脑进行入手,我们来到了9楼,进入了九楼的机房,这里放着3台H3C的交换机,负责人介绍,两台交换机是直接连接到3楼的核心机房,另外一台是提供公司上internet使用,说是物理隔离,这样貌似十分的安全,但是我们后来的发现,其实并不是这样的。这在网络的部署中,其实是一种看似安全,却隐患百出的部署。

连接上交换机,我们查看了下配置,这里做了MAC 地址绑定,看来看去也没看出什么端倪,因此对昨天问题出现比较严重的时候,谁在开机,谁在使用电脑做了了解,我们在部分电脑上使用了抓包工具,检测是否存在病毒的情况,在交换机上抓包,和在个人电脑上抓包,我们发现了一个共同点,9楼这个网络遭受着一个ID为HANGZHOU 的ARP攻击,但是数量不是很多,虽然这是隐患,经过分析,我们认为这不可能是是交换机崩溃的罪魁祸首,

紧接着对用户群的了解,我们发现了在用户办公桌上,基本都放着两台电脑,一台是台机,一台笔记本,用户说,台机不能上外网,只能上OA 和公司内部的网站,访问公司内部的信息,而笔记本可以上外网,然后,我们对用户对其笔记本是否有病毒进行询问,用户显然对病毒的意识不是特别敏感,但是用户称这并不是导致网络故障的原因,因为他们上网的网络是物理隔离的,意思是他们用的单独的交换机。

这样我们心里都有了一个底,这个公司的网络状况不是十分乐观,尤其是内网的安全,存在很多的隐患,对外网有防火IDS 应该是没什么大问题了。机房管理比较严格,干净整齐,设备损坏,线路损坏的可能性不是很高,初步认为,是数据原因导致,有可能是ARP病毒,因为,之前老大曾有过这样的工作经验。对九楼排查完毕后,时间差不多到中午了,我们回到了三楼机房,准备利用中午下班的时间,将23 24 接上看看错误的状况,就象是看病,我们看看不到真实的线性,在网络现在运行正常的情况下,对历史的状况分析,仅仅是帮助我们理清思路,最终还是要看到真实的故障,立即查找原因,但是这么大的网络排查,真的还是比较困难的,连接上23 24 端口,我们紧张的监控者vrrp的切换状况,大概半小时没有发现任何不正常的现象,于是我们就先吃饭了,1点半准时回来仍然没有任何状况,这就有点奇怪了。由于没有现象发生,使我们的排错陷入和两难的境地,一头雾水,不知如何是好,快要上班了,我们和科长商量,如果没有现象,就没法排错,在努力沟通和请求,科长同意延长测试到工作时间,科长向各个部门通知,如果出现断网立即通知,这里将停止排错,按之前网络拔掉23 24 ,得到科长的允许,我们焦急的等待着 状况发生,到2.30 22 23 两个端口出现了连续的 up down ,奇怪的事情发生了之前的23 24 今天却成了22 23 ,问题又变得不在那么明朗了,科长迫于压力和责任的重大,停止了排错恢复了网络,我们也意识到,现在这个问题不是一个简单的点到点的网络故障。大家变得一筹莫展起来,从哪里开始排错呢,我们需要理出来一条思路,科长答应我们下班后才能继续测试。

我们和老大 对网络进行分析,各自拿出了自己的排错方案,等待着下午的排错,下面画一张草图,说明下我们的排错思路。

当VLAN 23 24连接在核心交换上以后,vlan2下的PC出现了不稳定的,无法访问到同样连接在核心6500 的server服务器,经过我们对配置的查看,公司网络中所谓的物理隔离上internet的交换机所指的网关也在核心路由,也就是说这个物理隔离,也仅仅是2层上的物理隔离,当然不同vlan间是不会相互影响的,但是对核心来说,数据的压力呢?

方案1:Vrrp 在发生跳转的时候有一个阀值,假设internet 这里产生了巨大的流量,占用了6500的很多资源,导致数据堵塞,核心会认为该接口阻塞,因此发生vrrp跳转,而导致PC网络中断。

方案2:在网络发生故障的时候,在PC ping 网关,同时从核心ping server,缩小错误的范围,因为,我们在考虑数据的同时,同样不可以忽视了接口的损坏和线路的损坏,这也是导致Up down的原因。也是导致网络不稳定的原因。

我们还列举很很多的可能行,和很多证明其不可能的理由,所有的一切推论,都需要我们下午的实践才能得到证实。当前也没什么事情,我们就将两台设备的VRRP 配置进行了对比,希望从中可以找到问题所在,尽管心里明白,配置出错的可能性几乎为0因此设备之前的运转时正常的,且从来没有人修改过任何配置。种种的推论,种种猜测,种种现象,涌上我们的思绪。

下午6点正,准时开工,我们仍然将23 24 连接上了核心交换机,等待是否有状况发生,我随老大 来到了2楼的营业厅,对2楼营业厅进行排查,甲方安排了人在这里守候,此时办公区,也就是9楼已经没有任何的流量产生了,我们在2楼需要测试网络,我们打开6 7 台电脑,由于是下班时间,没有太多的流量,我们需要打开电脑Ping 网关用来产生大量的流量,等待了一段时间,终于故障发生了,而且时断时续,老大立刻要求确定这里的交换机连接的核心设备的端口是什么,因为,我们怀疑,交换机连接核心的线路或者端口存在一定的故障,由于甲方无法提供拓扑,我们的排查也是困难重重。但是作为一名网络工程师,这步能成为你无法排错的理由,我们使用自己画的简短拓扑。

但是由于时间问题,甲方拒绝了我们的要求。经过协商未果,我们也只能收工了。

晚上,我们回到了住处,总结了下这次项目的得与失。

协调,在工程的实施中,协调时十分重要的,作为一个网络工程师,我们外出工作,和默认的人处理好这种关系,有助于我们更好的工作,很好的协调能力会得到对方的信任。

对网络的整体把握,在进行网络排错的时候,我们要排除的不仅仅是物理上的故障,况且有很多的物理故障都是肉眼无法看到的,因此我们需要测试。来到项目现场,不应当只在出错的设备上下文章,网络是一个整体,我们需要了解这个网络的工作状况,比如说是用户群的工作性质,他们的数据流量是以什么为主之类,检查他们的网络状况,个人PC的健康情况,等等。

在排错的时候,需要一个思路,列出一个提纲,就想我们写作文一样,目的是为了让我们不断的缩小排错的范围。最终找出错误的范围。

尊重客户的意见,因为客户比你更了解这个网络的使用状况,仔细了解客户对网络的描述,做记录。对以后的排错是十分有帮助的。

绘制出网络拓扑,最少要绘制一个比较简单的网络拓扑。

将一些有意义的线索记录下来,为了以后的综合分析。

等等还有很多很多的经验,这些都需要我们用以后一生的工作时间去积累

这次项目我向说的是网络不是简单的点到点,他是一个整体。

(0)

相关推荐

  • Mesh有线回程如何接网线,手把手教你为家中布置信息高速公路

    创作立场声明:算是一个补丁帖子吧,因为之前几次路由器推荐列表的帖子,太多人问有线回程的事情了.而评论区的言语远没有画图更让人直观易懂,所以这篇帖子就出现了,整合了之前写的一些零碎的东西,都会给出导航位 ...

  • 周三装X——伪文艺青年变身数据狗,鬼知道他经历了什么?

    (听着歌 看故事) 故事很长,回忆也比较碎片化,文笔青涩将就着看吧.写下这段经历并没有其它意思,只是想给这两年一塌糊涂的生活一个交代.感谢这两年遇到的所有人,感谢自己. 伪文艺青年如何入坑数据狗 文 ...

  • 网络工程师成长日记376-某市某银行工程心得体会

    网络工程师成长日记376-某市某银行工程心得体会 这是我的第376篇原创文章,记录网络工程师行业的点点滴滴,结交IT行业有缘之人 (为保证客户信息安全,本文中IP地址使用X.X进行隐藏) 经历了一些网 ...

  • 网络工程师成长日记321-阿克苏诺贝尔工程感想

    网络工程师成长日记321-阿克苏诺贝尔工程感想 这是网络工程师成长日记的第321篇连载文章,记录网络工程师行业的点点滴滴,结交IT行业有缘之人 西安市高新区创业广场阿克苏诺贝尔Internationa ...

  • 网络工程师成长日记349-榆林某银行项目

    网络工程师成长日记349-榆林某银行项目 这是我的第349篇原创文章,记录网络工程师行业的点点滴滴,结交IT行业有缘之人 陕西省某银行分行会计远程监控系统网络工程回忆录 一.拓扑结构 注:RT-MSR ...

  • 网络工程师成长日记315-汉中某银行技术支持

    这是网络工程师成长日记的第315篇连载文章,记录网络工程师行业的点点滴滴,结交IT行业有缘之人 9/10随同老大到汉中市人民银行总行,对网络故障进行排查 主要是核心交换机上的VRRP热备份冗余出现不稳 ...

  • 网络工程师成长日记306-西安保时捷项目实习感想

    网络工程师成长日记306-西安保时捷项目实习感想 这是网络工程师成长日记的第306篇连载文章,记录网络工程师行业的点点滴滴,结交IT行业有缘之人 前几天接到老大的通知,星期一要去北二环的保时捷,做一个 ...

  • 网络工程师成长日记421-某银行技术支持

    网络工程师成长日记421-某银行技术支持 这是我的第421篇原创文章,记录网络工程师行业的点点滴滴,结交IT行业有缘之人 由于昨天的任务没有完成,客户要求我们今天继续去完成昨晚没有完成的任务. 今天良 ...

  • 网络工程师成长日记415-浦发银行

    网络工程师成长日记415-浦发银行 这是网络工程师成长日记的第415篇连载文章,记录网络工程师行业的点点滴滴,结交IT行业有缘之人 时光飞逝,一转眼我的实习已经结束. 想来实习的这一个月到底有一些什么 ...

  • 网络工程师成长日记385-某银行线路优化

    这是我的第385篇原创文章,记录网络工程师行业的点点滴滴,结交IT行业有缘之人 咸阳市某银行项目报告 14日早上我和老大去中国某银行咸阳支行调设备,出发的不算晚,但他们的设备之前没有拉过去提设备耽搁了 ...

  • 网络工程师成长日记383-某银行某市中心支行市县网络扩容项目工程感想

    网络工程师成长日记383-某银行某市中心支行市县网络扩容项目工程感想 这是我的第383篇原创文章,记录网络工程师行业的点点滴滴,结交IT行业有缘之人 某银行某市中心支行市县网络扩容项目工程感想 接到老 ...