1、小区里的尴尬之一
某工程师L负责A小区宽带用户上网工程的安装与维护，该小区组网方式为每个用户单元安装一台S2403F，S2403F通过25号接口（光接口）连接到该小区中心的一台S3025上。首先，L在办公室集中设置工程数据，然后安排工程队统一按照施工图进行安装和连接。
工程安装完毕后，L到各节点检查用户上网情况，发现B号楼用户无法正常上网。L首先检查S2403F的数据配置，确认光纤收发，然后在小区中心机房检查S3025的数据配置，最后又在局方机房的BAS上检查数据，确认无误。但是，用户还是无法正常上网，四五个小时过去了，L站在B号楼中感到一筹莫展。
万般无奈的L情急之下，再次观察B号楼的S2403F，发现25号接口的四个指示灯只亮了两个（DC、SP），另外两个（LK、AC）指示灯没有亮。这四个指示灯的含义分别是LK（Link）、AC（Activity）、DC（Duplexity/Collision）和SP（Speed）。DC、SP指示灯亮表明该接口工作于100M全双工状态，这是由配置决定的，LK、AC指示灯没有亮说明物理线路的连接不通。L在中心机房S3025处更换了一个与该S2403F对接的光电转换器，发现S2403F 25号接口的连接状态没有任何变化，L确认S2403F光模块或光纤出了问题，联系局方和施工队更换S2403F光模块后问题解决。
【案例分析】L碰到的情况是宽带工程中常见的一种故障现象，L在发现故障后，应该首先检查物理链路是否正常，最常用的方法就是观察指示灯。虽然指示灯不能百分之百地反映问题，但类似该案例中的LK灯是否常亮却是中低端网络产品判定物理连接是否正常的有效方法，避免跑冤枉路，节约时间。
2、小区里的尴尬之二
解决了B号楼的问题之后，L又发现C号楼用户无法正常上网，这次肯定不是“物理链路”问题，因为将S2403F的25号接口设置为UNTAG接口，用户即可上网，但设置为TAG接口则用户不能上网，说明从C号楼S2403F到中心机房S3025之间的物理链路正常。
L无奈地从中心机房查到C号楼，又从C号楼查到中心机房，没有发现数据设置错误，L迷惑地想：“这种设备到底支不支持TAG标记？”
L看着S2403F，心里想“问题会在那呢？”。UNTAG方式正常，说明从S2403F送到S3025的数据往返都正常，但S2403F的25号接口变为TAG方式后数据不通，则说明S3025相应接口不熟悉TAG标记，但是S3025相应接口的确配成了TAG接口，怎么会不熟悉S2403F送上来的TAG标记呢？答案只有一个，那就是S3025上的物理连接接口不熟悉TAG标记，换句话说，S3025插错位置了。
L联系工程队，按照图纸检查连线，发现S3025相应的网线果然插错了位置。原来，工程队负责人给每根线只发放了一对标签，由于线路连接过程中要经过一个光电转换器，所以标签被贴在光电转换器上了，在S3025上插网线时，由于没有标签，施工人员随便找了一个接口插上，导致L按照规划设置的数据不起作用。
【案例分析】在宽带小区工程中，施工队伍资质良莠不齐，经常会出现各种差错，这就要求工程师不但需要仔细配置数据，还必须注重检查此类“弱智”错误，否则会给工程进度带来诸多困难。
3、小区里的尴尬之三
经过三天的紧张工作，A小区的用户终于可以正常上网了。此时，网络忽然出现传输故障，紧急调用了一条2M线路作为小区的临时出口，要求L利用一台闲置的Quidway 2630恢复小区业务。
组网很简单，2630连接S3025，再连接S2403F，在2630出口设置NAT。数据配置好后，用户仍无法上网，但可以Ping通2630以太网口。L吸取了前几次经验，首先观察2630指示灯，发现LINK灯亮，确认“物理”连接正常。L使用Show interface命令检查2M（封装PPP协议）接口状态，发现物理层UP、链路层DOWN，但是接口统计收（INPUT）、发（OUTPUT）都有数据包。仔细分析数据发现，LCP处于Initial状态，也就是说PPP协商根本没有成功，另外发现收发的数据包数量惊人的相等，这是怎么回事？L再仔细查看数据发现，在Show interface数据中有loopback is set字样，也就是说存在自环！L马上检查2630到DDF架的连线，发现75欧姆同轴电缆的收发连接正常，然后与传输班联系，发现传输转接连接错误！
【案例分析】物理连接的故障问题并不局限于“网络设备连接处”的问题，有时还涉及到传输故障，要求工程师能够通过现有的条件判定问题的实质。
4、出现新问题
局方在割接某银行网络时，出现了某公司设备与华为设备的互通问题。G区银行的网络非常简单，中心支行使用一台某公司设备通过两条64K线路连接两个营业厅的某公司的路由器，局方采用Quidway 2631路由器替换原先的某公司路由器，数据配置好后线路工作不正常。
L赶往现场后，检查数据没有发现问题，L向局方工程师表示希望查看中心支行的路由器配置，但局方表示这是机密，只能给出原来某公司路由器的配置以供参考。L仔细检查配置发现，某公司路由器接口配置有“xxx”字样，经电话咨询发现，“xxx”是某公司的一个私有协议，华为设备并不支持，中心支行某公司设备关闭相应配置后问题解决。
【案例分析】与其他厂家设备的互通，在链路层经常会出现这样或那样的问题，需要不断地积累经验，仔细观察，多与相关厂家的技术人员进行交流，从有限的资料中寻找线索。
5、又一个新问题
经过一番努力，L终于完成了宽带小区工程的全部文档，这时接到电话投诉，最近开通的一台Quidway 3680路由器运行异常。L赶到机房发现，3680路由器的运行的确不太正常，但是对端设备JUNIPER M20却正常运行。
L仔细观察组网发现，NE16通过2M E1接口与M20相连，两端之间运行OSPF协议，路由错误主要表现为3680无法学习到M20传过来的OSPF路由，两边可以Ping通，但从NE16上Ping对端1500以上的数据包就不通了。L检查JUNIPER M20的数据配置发现，JUNIPER M20的E1接口的默认MTU是4470，而3680是1500，L将M20的更改为1500后问题解决。
L很迷惑，为什么双方的MTU不一致，会导致OSPF的路由不正常？为了彻底解释清楚上述现象，还需要从网络层的路由协议来综合考虑。
经过学习，L发现对于OSPF来说，有一种DD（具体情况请参考相关OSPF资料）报文，可能会比较大，在故障发生时，最大的DD报文有2000多字节，由于对端M40的MTU为4470，因此不分片，使3680无法正常接收，导致路由不正常。
【案例分析】网络层的故障，尤其是路由方面的故障有时非常希奇，具体的分析需要较深厚的理论素质，问题的解决也经常不一定局限于网络层的数据配置，也许和链路层的其他设置相关。
6、排除校园上网隐患
听说W大学上网经常出现问题，L前往勘察。据该校网络维护人员反映，该校的三台S2403F在三个月内出现过两到三次的死机现象，重启交换机后用户即可正常上网。L查看SS2403F数据，没有发现问题，查看S3025数据发现，某些端口设置的模式为自协商，实际端口状态为百兆半双工，而此时相应的S2403F端口模式设置却是强制百兆全双工。根据I-EEEE标准规定，自协商端口与强制端口进行通信时，会自动协商成最低效率的端口模式，即为百兆半双工，于是导致通信双方的端口工作模式一端是百兆全工，一端是百兆半双工。当网络流量变大时，端口模式不匹配的情况严重地影响了网络的转发效率，严重时甚至导致全网“不通”，感觉似乎交换机死机了一样。此时重启交换机会将刚才大量拥塞的报文清掉，用户可在短时间内恢复正常上网，给人的总体感觉好象S2403F出现过死机现象。
L根据所谓的S2403F死机问题，对现有网络进行了一次彻底的整改，使交换机双方端口的协商模式设为一致，或强制为百兆全双工，或者采用自协商方式。改动后，上述现象没有再出现过。
【案例分析】以太网设备的互连互通很轻易，但必须注重保证互连设备端口的工作模式保持一致，否则在某种网络情况下，可能导致网络出现“异常”情况，带来不必要的麻烦。
7、小结
在日常维护过程中，中低端网络产品碰到的问题往往非常繁杂，一方面是由于中低端网络产品可靠性的因素，但更重要的是由于中低端产品涉及的客户范围和施工环节过多，问题的定位和解决存在一定难度，这就要求维护人员必须在日常工作中不断总结，不断提高。
