配置参数也惹祸 (图)

作者:惠州 梁钊作为一名网络管理员，会面对各种各样的故障，而故障现象可能千奇百怪，原因也多种多样。要快速、准确的定位和处理故障，需要网络管理员有比较扎实的网络理论基础和丰富的实践经验。同时，还要求网络管理员掌握一些操作系统的网络设置等方面的知识。在日常的网络故障中，物理层、链路层和网络层这下三层的故障占了70%以上，应用层等上三层约占了30%，其中尤以物理层的问题居多，而应用层一旦出了问题，排查就比较困难。在这里，笔者谈谈去年曾经处理过的一例并不常见的涉及系统层面的通讯故障，但具有比较典型的意义。

系统介绍

故障系统是我行与移动公司的联网实时代收费系统。移动公司前置机用的是SCO Unix操作系统平台，Informix数据库，通过一个多用户卡串行连接各个代收费银行和单位。由于历史的原因，在移动公司代收费系统中，不同的代收费单位有不同的接口服务进程，系统配置也不尽相同；我行的前置机用Windows NT系统平台，通过串口以DTU到DTU方式直连到移动公司，双方以19200bps速率连接，连接如下图1：

图1

故障现象

我行和移动公司的联网代收费系统已正常运行了一个多月，国庆节休假回来第一天早上，发现交易异常：我行发送到移动公司收费前置机的数据包，如泥牛入海，全部收不到返回包。

诊断处理过程

面对这种情况，首先想到的是对方可能没有启动业务系统，于是打电话问对方，回复说收到乱码，所以没有数据包返回，同时反映说其他行到移动公司的交易也做不了，但其他代收费单位没有问题，业务交易正常。笔者马上想到通讯问题，致电电信公司的数据局检查和测试线路，看看是否出现通讯线路故障。经检查，数据局反映工行的问题是局端的交换端口出现了故障，更换设备后，下午交易恢复正常。但反馈说我行的线路正常，误码率也在正常范围之内。于是问数据局是否更改过速率，回答说没有。
后来想想，会不会是移动公司的多用户串口或我们服务器的串口坏了呢？于是双方协调各自调换了端口，故障依旧。而后笔者问对方可有改动过配置文件或程序，回复说没有。
这就奇怪了，因为通讯和应用系统接口一经确定，正常情况下是不会变更的，之前双方系统已经正常运行了一个多月，双方程序亦无改动过。因为是走串口，而不是走TCP/IP方式，所以无法用ping等网络工具进行诊断，这就给故障的诊断带来了一定困难。前面的诊断未能彻底排除中间环节（如：多用户卡的串口单点或多点故障）是否存在问题，那到底是中间环节出问题了呢，还是因为不小心变动了系统配置而导致故障的出现？
为了确定故障点，笔者决定到移动公司去一趟，跳过多用户卡，直连其串口进行测试。到移动公司后，打开手提电脑，接好直连线，启用超级终端后，看不到SCO Unix的login登陆画面。不可能！因为移动公司证实该串口是好的，SCO Unix的串口也已经激活启用，怎么回事？真是一波未平一波又起!难道是转接头接线不对吗？我检查了一下线序，没问题啊，再看看超级终端的设置：
波特率：9600bps
数据位：8位
校验：  无奇偶校验
停止位：1位
流控：  硬件
都是典型的设置，为什么没有终端画面出现呢？后来想到硬件流控是需要有专门的信号线来控制（我的转接线是临时做的，只用了收、发和信号地3根线缆，没有用到其他的信号线），故调整了超级终端的流控（把硬件流控改为软件流控Xon/Xoff），login的终端画面出现，但还是做不了业务交易，故障依旧，这样彻底排除了中间环节的链路故障。既然双方都没有改动过程序，那肯定是双方系统或应用设置的速率不匹配造成的。
到底是哪里的速率配置出问题呢？我们看了彼此的应用通讯设置，是一样的，都是19200bps，奇怪，到底怎么回事？这时，我突然想起会不会是串口的速率设置问题，但移动公司的工程师很确切地说：并没有更改过参数啊！仔细思量，其它可能的情况都排除了，就剩下这里了，于是决定还是检查一下，我们查看了SCO Unix的/etc/inittab文件，显示如下：
......
Se1a:234: respawn:/etc/getty tty1a m    （以下4行为标准串口设置）
Se1A:234:off:/etc/getty -t60 tty1A 3
Se2a:234:respawn:/etc/getty tty2a m
Se2A:234:off:/etc/getty -t60 tty2A 3
......
ma11:23: respawn:/etc/getty ttya11 m    （以下部分为多用户串口设置）
mA11:23: off:/etc/getty ttyA11 o
ma12:23: respawn:/etc/getty ttya12 m
mA12:23: off:/etc/getty ttyA12 o 
......

发现用于我行的端口速率设置为m (9600bps)（见划线部分），问题就出在这里了。
把定义我行通讯的划线部分由速率m (9600bps) 改为n (19200bps)，即修改为：ma12:23: respawn:/etc/getty ttya12 n
同时修改/etc/conf/cf.d/init.base及相应的多用户卡配置文件/etc/conf/init.d/moxa的相应内容，（这两个文件在Unix重新链接核心时会生成新的inittab文件覆盖原来的/etc/inittab文件，如不更改，核心重链时会导致修改后的/etc/inittab文件配置失效）。
重新启动接口服务进程，故障排除，业务交易恢复正常。

故障原因

在银行与移动公司之间的通讯链路虽然采用了64K的DDN(数字数据网)，但因为DDN是一种采用数字交叉连接技术和时分复用技术的全透明传输网，可以面向各类数据用户，所以在这段通讯链路上没问题。然而由于在Unix系统中串口不具备速率自适应功能，导致在系统端口速率不匹配，解码错误，出现乱码。故障产生的原因可能有两个：
1．可能是因为对方的失误，在检查系统时，犯了经验主义错误，以为我行的速率也应该是9600bps，不小心更改了配置参数导致（因为除我行外，其他银行和代收费单位均采用系统默认的9600bps配置速率）。
2．可能是因为在上一次Unix核心链接后，才上了该收费系统并修改了/etc/inittab文件，但未同时修改Unix核心链接源文件/etc/conf/cf.d/init.base及相应的多用户卡配置文件/etc/conf/init.d/moxa的相应内容，使得这几个配置文件的内容并不完全吻合，而后因为机器硬件或软件的变更（如增加、删除等）重新进行了Unix的核心链接，使得核心重新链接后，新的目标配置文件/etc/inittab的配置参数变了，导致了故障的出现。

排除心得

从这个问题出发，我们可以看出，作为一位网络管理员，不仅需要掌握网络方面的知识，也必须具备各种操作系统方面的一些相关知识，特别是系统上与通讯配置相关的知识。了解、掌握与之相关的配置文件和参数，对于我们处理故障，将会大有裨益，可大大缩短故障处理时间。同时，在系统规划和设计上，应尽量采用一些系统缺省的或常用的、典型的参数，这可避免许多类似问题的出现，减少系统故障出现的几率和维护成本。另外，在故障排除时，不可完全依赖经验和记忆，因为有时经验和记忆并不完全可靠（例如这次故障，对方凭记忆说没有更改过配置参数，而实际上却是更改了，不管是有意还是无意），这就给故障的排除设置了一个错觉和障碍，反而影响了故障的排除效率。
以上是笔者的一点心得和体会，借此抛砖引玉，希望能够和大家一起交流，给大家带来一点启发与思考。

[编辑提示：]
1. 在SCO Unix中，/dev/tty1a与/dev/tty1A实际上是同一个串行端口（/dev/tty2a与/dev/tty2A也是如此）。对于每一种设备，操作系统使用不同的设备驱动子程序。/dev/ttyA* 或 /dev/tty*A是用于modem拨号的设备，而/dev/ttya*或/dev/tty*a是用于串口连接的，两者不能同时使用，否则将会看到警告信息：
Cannot open：device busy.
2.在SCO Unix中，速率m代表9600bps，n 代表19200bps，o代表38400bps，该定义在/etc/gettydefs中有定义。