转:网络工作经历
第一章 初出茅庐，新来乍到小点兵 夏去秋来，天高云淡，从远处走来了我们的 主人公小L，他刚刚从象牙塔中走出，感受了百草原的芬芳，接受了车工庙的熏陶，现在正走向办事处，走向工程第一线，等待他的将是什么呢？是“灿烂的鲜花和笑脸”？抑或是“血与火的洗礼”？让我们随着他初出茅庐的脚步，从小事作起。 1.1 小区里的尴尬之一小L第一次从事的工程是负责A小区宽带用户上网工程，该小区的组网方式为每个用户单元放一台2403F，2403F通过25口（光口）连接到该小区中心的一台3025上，该工程的设备首先由L在办公室集中作好数据，然后交由工程队统一按照施工图安装、连线。工程安装完毕后，L到各个节点的2403F下面检查用户上网情况，发现B号楼中的用户无法正常上网，L首先检查2403F的数据配置并确认了光纤的收发，然后又跑到小区中心机房检查3025的数据配置，然后又跑到客户机房的BAS上检查数据，都确认无误后，用户还是无法正常上网，四五个小时已经过去了，L站在B号楼中面对用户和客户随工，感到非常尴尬。万般无奈的L情急之下，再次观察B号楼的2403F，发现25口的4个灯只亮了2个，分别是DC和SP，另外两个LK和AC灯都没有亮。（注：四个灯分别是LK（Link）、AC（Activity）、DC（Duplexity/Collision）、SP（Speed））DC灯和SP灯亮代表该接口工作在100M全双工状态，是由配置决定的，而LK、AC没有亮，则说明物理线路的连接就没有通。L立刻在中心机房3025处更换了一个和该2403F对接的光电转换器（该光电转换器确认是好的），发现2403F25口的连接状态没有任何变化，L立刻确认是2403F的光模块、或者是光纤出了问题，联系客户和施工队，通过更换2403F的光模块解决了问题。【案例分析】 L碰到的情况是宽带工程中一种常见故障现象，L在发现故障后，首先应该检查物理链路是否正常，而判断的常用方法就是看指示灯。虽然指示灯并不是一定百分之百正确，但是类似该案例中的LK灯是否常亮却是中低端网络产品判断物理连接是否正常常用的方法。这样常常可以避免跑冤枉路，节约许多时间。 1.2 小区里的尴尬之二 L成功的解决了B号楼的问题之后，又发现C号楼的用户无法正常上网，L很忧郁，因为这次肯定不是“物理链路”问题，因为这次如果将2403F的25号口设置为UNTAG口，用户就可以上网，但是设置为TAG口，用户就不能上网，说明从C号楼2403F到中心机房3025之间的物理链路是通的。 L无奈的从中心机房查到C号楼，又从C号楼查到中心机房，数据没有任何错误，客户人员看着L，疑惑的问：“你们公司的设备到底支不支持TAG标记呀？”L听了很委屈，说：“应该支持呀！”客户人员很疑惑，L感到很尴尬。 L独自一人蹲在C号楼的地下室，看着2403F，心理想“问题会在那呢？”首先如果说UNTAG方式可以，那就是说从2403F送到3025的数据来回都是正常的，可是当2403F的25口变为TAG方式后，数据就不通了，只能说是3025相应的接口不认识TAG标记，可是3025相应的接口的确是配成了TAG口呀，怎么会不认识2403F送上来的TAG标记呢？那么问题的答案只有一个，就是3025上实际物理连接的接口不认识TAG标记，换句话说，3025上的接口插错了。 L立刻联系工程队，按照图纸检查连线，发现3025上相应的网线果然插错了位置，原因是工程队负责人给每根线只发放了一对标签，但是由于线路连接过程中要经过一个光电转换器，所以标签被贴在了光电转换器上，所以再往3025上插的时候，因为没有标签，所以施工队就随便找了一个接口插上完事。导致L按照规划做的数据不顶用。【案例分析】宽带小区工程中，具体的施工队由于资质良莠不齐，所以经常出现许多差错，所以工程师不但需要仔细配置数据，保证软件方面的正确性，还要注意检查许多“弱智”类错误，否则会给正常工程进度带来许多困难。 1.3 小区里的尴尬之三经过三天的紧张工作，A小区的用户终于都可以正常上网了，L非常高兴，兴奋的向客户提交了割接报告，客户也很满意。但这时由于传输故障，客户紧急调用了一条2M线路作为小区的出口，要求L利用一台客户闲置的2630先为该小区恢复业务。L心理很晦气，觉得很倒霉，但也没有办法。组网很简单，是2630连接3025，再连接2403F，2630在出口做NAT。数据配置好后，用户仍然无法上网，但可以PING通2630的以太口。L吸取前几次的经验，首先观察2630出口的灯，发现LINK灯是亮的，确认“物理”连接正常。但是当L使用Show interface命令检查2M（封装PPP协议）接口状态的时候，发现物理层UP、链路层DOWN，可是接口统计收（INPUT）、发（OUTPUT）都有数据包。客户工程师不断的催L，用户也不断有投诉电话打来，机房里极为混乱。在这样混乱的环境中，L感觉非常不好。但是L还是静下心来仔细看了一下Show intface中的数据，发现LCP处于INITIAL状态，也就是说PPP协商根本没有成功，另外发现收发的数据包数量惊人的相等，这是怎么回事？L再仔细的看了一下数据，发现 show interface数据中有loopback is set字样，也就是说存在自环！L立刻检查2630到DDF架的连线，发现75欧姆同轴电缆的收发连接正常，然后L通过客户工程师和传输联系，发现原来是传输转接时连接错误！【案例分析】物理连接的故障问题并不局限于“网络设备连接处”的问题，有时还涉及传输故障，需要工程师利用现有条件仔细判断问题的实质，而不能手忙脚乱。 1.4 小区里的尴尬之四【思考题】： L调通2630后，客户对L的工作效率很满意，认为L在专线方面的水平很高，要求L帮助调试另外一台3640设备，该设备利用2根2M线路分别和2台CISCO3640设备互通。由于CISCO设备的E1接口默认封装协议为HDLC，所以客户要求L使用HDLC协议和对端互通。 L作完数据后，发现第一根线路相应的接口的物理和链路都是DOWN的，但是SHUT，NO SHUT之后，接口立刻能够物理和链路层都转为UP，过一会又全部转为DOWN。第二根线路相应的接口的物理UP，但是链路层是DOWN。可是第二根线路对端的CISCO设备却物理和链路都UP。第一根线路的情况，L认为是物理链路的问题，可是客户问为什么SHUT、NO SHUT之后能够UP？L却无法回答。第二根线路的情况，面对客户的诘问，L也感到非常尴尬。问题到底在那呢？为了彻底解释这些问题，需要从链路层角度来分析。【后记】：小L作为一名不谙数通技术的新员工，面对一个又一个开局难题，不骄不躁，从小事作起，从细微处着眼，解决了许多难题。但是仅凭认真的态度和良好的服务规范，终究无法满足客户越来越高的技术和服务要求。这不，小L又碰到难题了，那么小L最终将如何闯过这道险关呢？欲知后事如何？请看小L历险记的第二篇——“机房鏖兵”。 国演义 之 华为 (二) 第二章 机房鏖兵，宝剑锋从磨砺出【序】：书接上文，话说小L面对客户的诘问，着实吓了一身冷汗，发现有时候用户并不是解决了问题就什么也不管，至于小L如何应对，以及小L又有什么新的历险？他如何从机房中顺利脱身？让我们拭目以待。 2.1 机房中的问题之一 L在机房中调试2630过程中发现问题后，寻找HDLC的相关资料，发现对于HDLC协议来说，出现第一种线路的情况是正常的。换句话来说，如果物理线路不通，SHUT、NO SHUT端口之后，封装HDLC的端口会相应的出现短暂的UP，但实际上是假的，过一会儿会DOWN掉（详细原因可以参看相关HDLC的资料）。对于第二种情况，L发现对端设备在相应的接口下配置了NO KEEPALIVE之类的字样，而2630默认情况下KEEPALIVE不为零，而是等于10，这就是说由于对端不检测KEEPALIVE，所以能够转UP，而2630侧却不能转为UP。【案例分析】链路层的故障在判断时常常需要一定程度的理论素质，或者说对于常见链路协议有一定的了解，但是如果一点基础也没有，也可以尝试“照猫画虎”，对端怎么配，本端就怎么配，除了两端IP ADDRESS保持不同外，其他保持一致。 2.2 机房里的问题之二 L成功完成了和CISCO的3640互通后，客户对于L的水平越发敬重了。这时客户正在割接一个银行网络，出现了问题，由于刚好涉及CISCO和华为设备的互通问题，所以诚邀L前往协助，L虽然很不愿意，但挡不住市场的压力，被迫再次出马。 G区的银行网络非常简单，结构是中心支行使用一台CISCO设备通过2条64K线路分别连接2个营业厅的CISCO2610，但是由于某种原因客户需要将CISCO2610替换为华为公司的2631路由器，可是设备数据配置好后，线路无法正常。 L赶往现场后，检查数据后没有发现什么问题，然后向客户工程师表示希望查看中心支行的路由器配置，但客户表示这是机密，只能给出原来CISCO2610的配置以供参考。 L经过检查2610的配置，发现CISCO2610设备的接口上配置有“CDP”字样，L经过电话咨询，发现原来CDP是CISCO的一个私有协议（详细资料请参考CISCO资料），华为设备并不支持，所以需要中心支行的CISCO设备关闭相应的配置。【案例分析】与其他厂家的设备互通，在链路层常常出现这样或那样的问题，需要不断积累经验，仔细观察，多和相关厂家的技术人员进行交流，或者从有限的资料中寻找蛛丝马迹。 2.3 机房里的问题之三 L在机房解决问题的过程中和用户工程师C结成了深厚的友谊，C有一天突发奇想，想要实现一个功能，具体来说就是在两台S3026交换机上都同时创建10和20两个VLAN（每台交换机上都有若干个 端口属于10和20），但是两台交换机之间不用TRUNK连接，而是各用一个只属于VLAN10和VLAN20的端口相连。连接如图（红色线属于VLAN10，蓝色线属于VLAN20）：网络连接后，C想到如果单纯这样连接，害怕存在路由环路，所以配置了RSTP功能，但是配置完成后属于VLAN20而分布在两个交换机的用户之间突然不通了，关闭RSTP就能够解决。C决定问问L是为什么？ L仔细查阅了RSTP的相关资料，给C解释道原因在于RSTP协议并不能识别VLAN信息，协议认为，两台3026通过两个端口相连，一定会产生环路。所以必须将其中的一个端口阻塞掉。而实际上由于划分了不同的VLAN，根据VLAN的定义，不同VLAN之间的报文是不能互通的。所以实际上网络并不存在环路。而由于RSTP的错误判断其中一个有用的端口阻塞了。但是，如果所有的端口都属于同一个VLAN，此时确实会产生环路，必须阻塞一个端口。 【案例分析】根本原因是由于RSTP协议设计的时候没有考虑VLAN的情况，目前在最新的协议MSTP中增加了对VLAN的考虑，可以根据不同的VLAN，形成不同的生成树。但MSTP目前还处于草案阶段，没有最终定稿。目前大部分厂家还不支持（包括我司产品）。由于VLAN的应用非常普遍，所以在启动RSTP协议时一定要小心判断。如果在划分VLAN后不会有环路，就不必启动RSTP，以免导致强某些正在使用的端口阻塞。 2.4 机房里的问题之四经过一翻努力，L终于完成了宽带小区工程的全部文档，赶回了办事处。可是H市的客户又打过来了电话，说最近开通的一台NE16路由器运行异常。 L急急忙忙的赶到H市的客户机房，发现NE16路由器的运行的确不太正常，而对端设备JUNIPER M40却没有问题，用户具此对NE的软件质量产生怀疑。 L仔细观察了一下组网，发现NE16通过155M的POS口和M40相连，两端之间运行OSPF协议，路由错误主要表现为NE16无法学习到M40传过来的OSPF路由，两边可以PING通，但是从NE16上PIING 对端1500以上的数据包就不通了。 L要求客户检查JUNIPER M40的数据配置，发现JUNIPER M40的POS接口的默认MTU是4470，而NE16是1500，要求客户将M40的更改为1500。问题解决。但是客户要求解释为什么双方的MTU不一致，导致OSPF的路由不正常？ L也很疑惑。为了彻底解释清楚问题，需要从网络层的路由协议来考虑问题。【案例分析】网络层的故障，尤其是路由方面的故障常常非常奇怪，详细分析和解决需要较深厚的理论素质，但是常常问题的解决却不一定局限于网络层的数据配置，也许和链路层的其他相关设置有关。【后记】：虽然说小L经过多次锻炼，技术水平在实践中提高很快，但是面对这样一个更高难度的新问题，小L的一颗小心还是不禁扑腾扑腾跳个不停，但回想当初多少风浪都闯了过来，怎么能在这样的“小河沟”里翻船？一想到这儿，小L立刻气定神闲，欲知小L如何化险为夷，请看小L历险记的第三篇——“东征西讨”。 出错误了吧！老兄： G区的银行网络非常简单，结构是中心支行使用一台CISCO设备通过2条64K线路分别连接2个营业厅的CISCO2610，但是由于某种原因客户需要将CISCO2610替换为华为公司的2631路由器，可是设备数据配置好后，线路无法正常。 L赶往现场后，检查数据后没有发现什么问题，然后向客户工程师表示希望查看中心支行的路由器配置，但客户表示这是机密，只能给出原来CISCO2610的配置以供参考。 L经过检查2610的配置，发现CISCO2610设备的接口上配置有“CDP”字样，L经过电话咨询，发现原来CDP是CISCO的一个私有协议（详细资料请参考CISCO资料），华为设备并不支持，所以需要中心支行的CISCO设备关闭相应的配置。 CDP跟你设备通讯没关系啊。只是占用少量的带宽而已，而且极小的。所以不会影响设备互通的。而且CDP靠的是SNAP传输，链路不up ，CDP也不好使的。一点看法，仅供参考。 三国演义 之 华为 (三) 第三章 东征西讨，攻坚克险火中炼 第三章 东征西讨，攻坚克险火中炼【序】：书接上文，话说小L面对自己从来没有接触过的OSPF协议，心中不禁涌起了一丝丝寒意，到底小L是如何使出了一招“天外飞仙”？又是如何在东征西讨中全身而退？让我们细细道来。 【案例分析】面对客户的问题，L经过学习，发现对于OSPF来说，有一种DD（详细情况请参考相关OSPF资料）报文，可能会比较大，在故障发生时，最大的DD报文有2000多字节，但是对端M40的MTU由于为4470，所以并不分片，导致NE16E（NE16E的最大接收单元只有1500）无法正常接收下来，所以导致路由不正常。注意：接口的最大接收单元（MRU）是在链路起来时协商决定或是芯片固定了的，无法手工设定。并且一般来说MTU（最大发送单元）要小于或等于最大接收单元。 3.1 都是HGMP惹的祸 L经过连续几个月的东奔西走，终于开完了全部的宽带小区，刚刚赶回办事处所在地，突然接到用户电话，说某宽带接入小区，在小区中心机房中使用了数十台S3025，每台S3025管理近20台S2403F，昨天小区停电以后，来电后下挂很多用户都不能上网，客户收到的用户投诉不断，客户工程师要求我方工程师一同火速赶往现场。L抵达现场后，通过S3025上发现其所挂S2403F只有为数不多的几台能够PING通，且能Telnet，数量众多的S2403F都无法Telnet，无奈之下。只能背着便携爬到小区放置交换机的地方，交换机并无破损，用串口连接到交换机发现数据全部丢失，故障版本是V120，当时因为小区用户反映非常强烈，所以L只好迅速将数据重新做了一遍，并确认保存。后来查实在原来工程中在做数据的时候，并没有将SYSTEM中启动方式HGMP改为LOCAL，而S2403FV120版本出厂默认启动方式恰为HGMP。而对于S2403F，如果启动方式设置为HGMP，交换机在启动后，主动向规定的上行口(那些可能用来连接管理设备的端口)发送注册报文，如果有设备对其回应注册成功报文，则表示已经同一台管理设备建立了联系，而后通过HGMP方式从管理设备取得交换机的配置数据，之后两者间定时通过握手报文进行联系，以保证通讯没有中断。如果申请不到，则将FLASH中的默认配置数据读入内存中运行，因为在这个小区中使用的并非HGMP管理方式，而是Telnet管理方式，交换机无法从HGMPserver处获得配置数据，于是就出现前面的情况，无奈两人只能一个一个楼道的爬，一台一台的配置，将所有的S2403F配置数据重新做了一遍。【案例分析】在本案例中虽然没有用到HGMP，进行保存的时候也不会有提示注意的事项，这就为后面的数据丢失埋下了祸根，而实际上在这个组网中与HGMP却是一点关系也没有，这是软件设计中存在的一个问题，配置S2403F时需要注意，其他产品则没有这个问题。 3.2 不定时启动的炸弹最近听说W大学的上网经常出现问题，L亲自前往W大学进行勘察，据该校的网络维护人员反应，该校的三台S2403F在三个月内出现过两到三次的运行时死机的现象，重启交换机后，用户即能正常上网。L为此首先查看S2403F的数据，没发现有什么问题。后来又到S3025上查看数据，发现某些端口设置的模式为自协商，但实际的端口状态为百兆半双工。而此时相应的S2403F上端口模式设置却是强制百兆全双工。根据I-EEEE的标准规定，自协商端口与强制端口进行通信时，会自动协商成最低效率的端口模式，即为百兆半双工。这样导致通信双方的端口工作模式一端是百兆全工，一端是百兆半双工。由于存在这样的问题，当网络流量大的时候，两端这种端口工作模式不匹配的情况会严重影响网络的转发效率，严重时会导致全网“不通”，这时给人的感觉就好像是交换机“死掉”了，或者说不再工作了似的。此时重启交换机的话，会把刚才大量拥塞的报文清掉，用户在短时间内又可以正常上网了。这样给人的总体感觉就是S2403F有死机的现象。针对以上现象，L采取了如下措施：对于所谓的S2403F死机问题，我们建议对现有的网络进行一次彻底的整改，使交换机双方端口的协商模式一定要设为一致。或者都是强制百兆全双工，或者都是自协商。改动后，以上故障现象没有再次出现。【案例分析】以太网设备的互连，互连互通非常容易，但是仍然要保证互连设备端口的工作模式保持一致，否着在某种网络情况下仍然可能导致网络出现“异常”情况，给工程师在维护过程中制造不必要的麻烦。 3.3 如何运筹帷幄 L在作完某银行的工程后，虽然把各个营业点都调通了，但是由于营业点众多且离中心机房较远，为了便于管理路由器，客户要求能够远程通过AUX口拨号登录到路由器。 L以前没有配过这个，幸好有指导书。L参照指导书用AUX电缆将MODEM连在quidway2631的AUX口上，接上电话线，然后又将自己的便携接上电话线，打开超级终端，输入“at”，显示“OK”，L很高兴，又输入“at 12345678”，听到了MODEM开始拨号了，接着听到了对端的回铃音，过一下，在超级终端上显示“connect 115200”，表示接通了，L更高兴了，以为又一个问题解决了。没想到紧跟着整个超级终端全部显示一堆乱码，这下L心里慌了，一下子不知道该如何下手。急忙翻看指导书，结果在指导书的注意事项里有一项就是关于乱码的，这跟AUX的工作方式有关。L根据指导书将AUX口的工作方式改为“interactive”，然后重新拨号，经过一阵拨号之后在超级终端上终于显示出了那熟悉的“QUIDWAY>”，L心中的一块石头终于落地了。【案例分析】默认的情况下AUX口的工作方式就是“interactive”的，这种工作方式是为了远程拨号登录到路由器的，但是有时经过一些配置或*作之后我们有可能将AUX口的工作方式设成了“dedicated”，一般是AUX口在配置DDR时才采用这种工作方式的。如果是配置远程拨号登录到路由器而AUX口的工作方式却是“dedicated”，则会在超级终端上显示乱码。 3.4 为用户传授经验由于L在工作过程中不断的摸索，并且服务响应积极，客户对L的工作很满意，鉴于客户在维护银行系统过程中经常需要解决许多DDR的难题，所以为了提高自身水平，特意要求L将DDR的一些常见简单经验作些传授，L欣然答应，并根据自身经验有给出了如下一些总结。【故障之一】：Modem不拨号故障排除：路由器配置拨号DDR后，若发送数据时Modem不拨号，可能是以下原因中的一种。 (1) 硬件原因与Modem连线是否正确。 Modem的初始化是否正确。 (2) 软件原因若接口是同/异步串口，没有设置为异步方式。没有配置modem in、modem out命令。没有使能DDR。没有配置与数据包对应的dialer map或dialer string。没有配置dialer-group命令。数据包是uninteresting包，它不触发呼叫。可通过dialer-list命令将数据包设置为interesting包。【故障之二】：Modem不接收呼叫故障排除：可能是以下原因中的一种。 (3) 硬件原因与Modem连线是否正确。 Modem的初始化是否正确，是否没有设为非自动应答。详见本手册的Modem部分。电话线连接是否正确。 (4) 软件原因若接口是同/异步串口，没有设置为异步方式。没有配置modem in、modem out命令。没有使能DDR。【故障之三】：Modem接通后，仍无法ping通对方。故障排除： 可能是以下原因中的一种。两端的封装是否一致。若使用encapsulation ppp，两端的验证是否配置正确。没有使能DDR。接收端配置了dialer map，但没有与呼叫端匹配的dialer map。【后记】：无论是风是雨，是苦是甜，小L从一名新员工开始，从小事作起，点点滴滴，虽然经历了许多的 坎坷，但是他坚信生命不惜，奋斗不止，在他的前方又会有什么样的问题和困难呢？欲知后事如何，请看小L历险记的第四篇——“路在何方？”
