简介这是一份关于光传输网管系统的专业课件面向通信工程、网络运维学习者系统梳理了电信管理网TMN、SDH管理网、E300网管系统及ZXONM网管产品等核心概念帮助理解电信网自动化管理的演进脉络与分层架构。压缩包内仅1个PPTX文件全篇46页体积599KB内容紧凑适合作为高校相关课程或企业培训的辅助讲义。课件从手工网管、交换机控制下分散式数据收集讲到网管中心自动控制的发展历程详细解析TMN五种节点职能与四层管理功能模型并具体展开性能管理、故障管理、计费管理、配置管理及安全管理等实现要点同时介绍SDH管理网结构、E300功能接口及ZXONM产品定位章节安排清晰。目前已有80人浏览学习适合需要系统掌握光传输网络管理原理的入门及进阶读者参考能有效辅助理解抽象的网络管理框架与各网管系统的关系。1. 光传输网管系统是什么它不是监控软件而是传输网络的“控制面”光传输网管系统这个词做传输的工程师几乎天天挂在嘴边可真要把它讲清楚的人不多。它可以是一套软件也可以是一张PPT里画给客户看的拓扑图但它真正的角色是光传输网络里负责“管理、监控、配置、保护”的控制面系统。SDH时代它管复用段和通道OTN时代它管波长和ODUk没有它一张几十个网元的光传输网络就是一堆盲盒——业务断了你连断在哪一段都不知道。这篇文章写给三类人刚接手传输网管的运维新人要被它救过命的骨干工程师以及需要把这套系统讲给客户或学生听的售前和讲师。我会把网管的分层机制、组网配置、日常运维和踩坑经历串成一条线保证你看完既能复述原理也能回去对照自己的网管系统做一遍体检。2. 光传输网管的底层逻辑三层管理模型和它依赖的“神经通道”2.1 为什么非要把网管分成网元、网络、业务三层你看任何一款主流的光传输网管产品打开界面左侧一定有三层树形结构网元层、网络层、业务层。这不是UI设计师的习惯而是光传输设备的工作方式决定的。网元层管单台设备比如某个OptiX或ZXMP设备的单板状态、光功率、温度、风扇转速网络层管设备之间的连接关系比如复用段、光纤拓扑、保护子网业务层管端到端的电路比如一条从A站到D站的155M业务走了哪几条交叉占用了哪些时隙。这样的分层有一个直接好处故障定位时能逐层收缩。你看到一条业务告警先在业务层看它走了哪个路径再到网络层看这条路径上的哪个网元告警最后切到网元层看是哪块单板哪个光口报R-LOS或B1_OVER。三层对应三种操作权限也对应三种管理粒度单板级、拓扑级、电路级。很多新手一上来就扎进告警列表里翻效率极低本质上是没用这个分层结构去引导排查。2.2 DCC与OSC光传输网管的数据“神经”是怎么长出来的光传输网管最容易被误解的一点是以为它靠IP网络就是平时说的局域网、公网和设备通信。真相是在SDH时代网管数据和业务数据走的是同一根光纤但“各走各的道”——业务用净负荷区网管数据用开销区。SDH帧结构里的D1到D12字节是专门留给网管通信的DCC通道分再生段DCCD1~D3速率192kbps和复用段DCCD4~D12速率576kbps。OTN时代类似靠光监控通道OSC或者OTU开销里的其他保留字节。这意味着网管通道在物理上和业务通道同缆甚至同纤业务断网管的可见性也可能一起断。所以光传输网管系统在设计上有一个“带内带外结合”的说法带内就是走DCC/OSC带外就是单独拉一根网线或光纤把网管系统接到某个网元的以太网口。真实工程里骨干核心站点几乎都要求带外管理接入层站点才允许用带内DCC。带外能保证核心网元在业务光纤全断时还能被网管访问到这是故障时唯一能摸到设备的通道。2.3 网管协议栈从网元侧ECC到北向CORBA链路有多长网管和网元之间、网管和上级系统之间其实走的是两套完全不同的协议。网管服务器到网元这一段SDH设备普遍用OSI协议栈走DCC或者TL1命令行华为设备在这个层面的私有实现叫ECCEmbedded Control Channel名字不同干的事一样封装网管对象的属性读取和设置。中兴、烽火、Nokia各有各的私有协议但它们对上提供的北向接口却高度统一——电信运营商OSS系统如果要接多厂商网管基本都要求提供标准北向接口常见的是CORBATMF814标准和SNMP。这套协议链路的含义很实际你在网管界面上点一下“查询光功率”背后是网管服务器封装一个请求通过TCP/IP发到网关网元网关网元再把它转成ECC报文经过DCC逐跳跳到目标网元目标网元收集数据后再原路返回。理解这个链路你就明白为什么跨多跳DCC的查询会慢——不是网管软件卡而是数据在光缆里绕了一大圈。这也是为什么网络规模大时要按区域划分部署多套网管而不是一套网管连遍全网。3. 把网管系统搭起来组网选型把DCN规划、网关网元和服务器部署一并解决3.1 一套完整的光传输网管系统需要哪些实体部分很多人以为网管系统就是一台电脑装个客户端。实际生产环境远不止这个。我的常规做法是把网管系统拆成四块实体来看网管服务器含数据库、网管客户端操作员终端、网关网元或叫管理网元、DCN网络。服务器装网管软件主程序和数据库客户端通过局域网连服务器进行操作网关网元承担协议转换DCN就是网管到网元之间的数据通道。反过来规划一个站点的网管接入你要先回答四个问题这个站点是核心节点还是边缘节点它到最近的网管服务器走什么路由它的网元OSI或IP地址在全局规划里的哪一段它需要不需要远程终端接入能力我习惯在Excel里把这些信息做一张“网元-地址-网关网元-机柜位置”的映射表每加一个网元先填表再动手配置这比事后用网管扫描发现网元要靠谱得多。地址冲突和网元不可管百分之七十是这张表没做好。3.2 DCN域划分一个网管管多少个网元怎么划网管系统的DCN通道和带宽是有限的这是必须理解的一个瓶颈。DCC通道总共就那么几百kbps且还在被网元间的OSI邻居发现、告警上报、性能数据查询共享。所以网管系统不可能无限挂网元。我的经验值一套网管管理500~1000个网元已经算比较大的规模再多就会出现告警上报延迟、性能采集超时、ECC风暴连锁反应。DCN域的划分原则常见做法是按传输网络的拓扑结构分一个汇聚环或一条干线的所有网元划入一个管理域一个管理域配置一个网关网元。域之间不直接通DCC要跨域管理就得把两套网管系统通过上级互联。划域的同时要做好组合键规划SDH网元在ECC里的标识由OSI地址等字段唯一确定。一旦有两个网元OSI地址网段设置重叠就会出现管理串扰——你在网管上操作的是A站实际下配置到了B站这是非常危险的事故。所以组合键规划不能拍脑袋统一由一个网管负责人维护一张分配表。3.3 网关网元全网管理的“唯一入口”与主备配置网关网元是网管服务器与普通网元之间的中介它的选择有讲究。生产网里一般选在靠近网管机房、电源可靠性高、在拓扑中处于枢纽位置的网元。一旦网关网元脱管它后面所有只依赖它进行DCC转发网元会全部不可见。于是现在工程规范里都要求做网关网元的主备主网关网元和备网关网元同时在线网管平时通过主网关管理主网关故障后自动切换。这个功能在华为设备上叫“网关网元主备”中兴叫“代理网元备份”原理一样备网关也跟网管保持连接并且同步维护着全网拓扑和路由信息。配置网关网元时我见过最多的错误是只配了IP地址而忘了配置到网管的静态路由。网管服务器到网关网元是走局域网IP的但网关网元转发到下游网元是走DCC里的OSI或IP这中间需要网管软件里填写网关网元的“下行路由表”。漏配这段典型现象是网关网元在线但全网只有它自己可见其它网元全部灰掉。排查时不要先去怀疑设备故障先检查这段路由表。3.4 网管服务器与数据库容量规划、备份与重装预案网管服务器不是跑个桌面软件那么简单它的数据库承担了告警历史、性能历史、配置数据、操作日志四大类数据的存储。规划服务器时我比较保守500网元规模的网管建议至少8核CPU、16GB内存、SSD容量1TB以上操作系统用厂商认证过的主流服务器系统数据库用自带的私有库或厂商指定的Oracle/PostgreSQL版本。很多维护团队把网管服务器当成普通PC装完能用就行结果半年后性能库占满磁盘网管系统开始丢历史数据那时候才想起来要扩容。备份策略是网管系统运维里最容易被忽略的一项。我见过某地网管服务器硬盘故障整机没做任何备份几百个网元的配置数据连同历史告警全部丢失只能一台台网元重新上载配置。常见的做法是每日自动备份数据库和配置镜像文件至少保留最近7天的备份轮转备份文件不要和网管数据库放同一块盘这点属于血泪教训。下面是我在Linux服务器上常用的备份脚本结合crontab每晚执行#!/bin/bash # 网管系统每日备份脚本适用于基于Linux的网管服务器 BACKUP_DIR/backup/nms # 备份文件存放目录建议挂载独立磁盘或远程存储 KEEP_DAYS7 # 保留7天避免磁盘被备份文件写满 DATE$(date %Y%m%d) mkdir -p ${BACKUP_DIR}/${DATE} # 备份数据库导出文件。不同厂商网管的数据库工具不同 # 此处以PostgreSQL pg_dump为例Oracle可用expdp替代。 /usr/bin/pg_dump -h 127.0.0.1 -U nmsadmin nmsdb | gzip ${BACKUP_DIR}/${DATE}/nmsdb.sql.gz # 备份网管软件的配置文件目录例如 /opt/nms/config tar -czf ${BACKUP_DIR}/${DATE}/config.tar.gz /opt/nms/config # 清理7天前的旧备份 find ${BACKUP_DIR} -maxdepth 1 -type d -name 20* -mtime ${KEEP_DAYS} -exec rm -rf {} \; # 记录备份日志 echo backup finished at $(date) ${BACKUP_DIR}/backup.log这段脚本的逻辑是先用pg_dump把网管数据库整个导出并压缩再单独打包配置目录。配置目录和数据库分开备份有一个好处——如果只是某条业务配置改错了想恢复某一个时间段的状态只恢复配置目录的快照粒度就够了如果数据库膨胀或损坏则必须恢复数据库文件。KEEP_DAYS设成7是平衡成本与安全的选择如果磁盘充裕我会设到14天。注意脚本里备份目录不能和网管程序目录在同一个逻辑卷上否则数据库文件系统满了备份也跟着写不进去。4. 日常运维怎么做告警定位、误码性能监测、保护倒换验证、北向接口自动化4.1 告警看得懂从一条R_LOS顺藤摸瓜到业务影响面网管系统界面上最常见的操作是看告警但告警列表里几千条记录没有重点等于没有告警。我一般先做两层过滤第一层按严重级别过滤只看紧急和主要告警第二层按网元分区过滤先把非本区域的告警暂时屏蔽。然后看告警之间的因果关系这在SDH和OTN设备上是有规律可循的。比如某光口报R_LOS接收信号丢失它下游的网元通常会同步报AU_LOP或TU_LOP之类的衍生告警再往业务方向看还会出现UNEQ或AIS真正要处理的是最上游那个R_LOS下游那些告警会自动在根源修复后消失。很多人不懂这个相关性看到全网几百条告警就慌挨个去清费时费力还搞不清根因。正确的做法是利用网管里的“告警相关性分析”功能或者你手工按“光口—再生段—复用段—通道—业务”的层级关系去剥。有一句话可以帮你记住先找物理层告警光功率、R_LOS、LOF再往上找信号劣化类告警误码越限、指针调整、J0失配最后才看业务层告警TU_AIS、TU_LOP。这个顺序就是光传输从低层到高层失效的逻辑顺序。4.2 性能监测B1、B2、B3三组误码分别代表哪一段光传输网管的性能管理功能里最核心的是误码性能监测。SDH帧结构里专门留了B1、B2、B3字节用于误码检测B1监测再生段也就是光口到光口这一段的误码B2监测复用段网元之间线路段的整个STM-N信号的误码B3监测高阶通道端到端VC-4级别业务的误码。换句话说B1误码代表某一根光纤或某个光模块出了问题B2误码代表某个线路复用段性能劣化B3误码则直接关系到某个客户业务端到端的质量。日常运维中查误码要用历史性能而不是当前性能。当前性能只能看到“这一刻”的累计值而历史性能按15分钟和24小时两个粒度存储能看出误码是持续攀升还是偶尔一次瞬时抖动。我的经验是先看15分钟性能历史里误码出现的时段分布如果集中在夜间某个时间点那多半有外部干扰如果全天都有持续的B2高误码大概率是光路衰耗过大或单板光模块劣化。查到有误码的段以后去测光功率、看收光余量、检查法兰头是否污染三步走完基本能定位。4.3 保护倒换验证SNCP和复用段保护怎么测试才不算“假通”传输网络最重要的价值是保护而保护功能必须实测不能看网管界面上“保护正常”四个字就当真。常见的保护类型里SNCP子网连接保护是双发选收发端复制两份信号走两条不同路由收端择优接收MSP复用段保护是K1/K2字节协商倒换11或1:N方式。做保护测试时我在网管上的标准操作是先记下当前业务的路径和保护状态然后强制在保护组里发起倒换看业务能否在50ms内恢复再恢复主用通道确认倒回正常。全程观察网管上的倒换事件记录是不是有“FAIL”等级的事件。这里有一个最容易翻车的地方很多工程验收时只测“拔光纤看业务痛不痛”业务没断就认为保护是好的。但SNCP双发选收跟MSP不一样前者断了主用路由业务自动切到备用后者需要K1/K2字节在两个网元之间完成状态协商如果协商状态不对看似“业务没断”可能是备用通道本身就在承载业务。更隐蔽的坑是保护组里主备两个方向配置了同一条物理光路表面上看有保护实际光缆被挖断时两条路由一起断这就是所谓的“假保护”。所以验证保护时要看网管上的保护拓扑图确认主备路由是真的物理分离。4.4 北向接口自动化用CORBA或SNMP把网管数据接进自己的平台规模稍大一点的维护团队不会天天坐在厂商网管客户端前面点鼠标而是把网管的数据接到自己的运维平台里统一展示。北向接口就是干这个的。老一代设备以CORBA为主新设备很多支持SNMP也有不少厂商提供RESTful API。实际项目里最常见的是用SNMP轮询网管的告警和性能数据再转换成内部工单或监控大屏的显示。下面给一段用Python通过SNMP读取网管系统告警表的示例逻辑目的是让你理解北向接口对接时“轮询增量比对”的基本套路而不是真的指望这一段就接上厂商设备厂商MIB库里的OID你需要从设备资料里查# 北向接口告警轮询示例通过snmpwalk拉取活动告警表并做增量比对 # 依赖python3 pysnmp生产环境建议改用scandir或异步并发提升速率 from pysnmp.hlapi import * from datetime import datetime HOST 192.168.1.100 # 网管北向接口IP COMMUNITY nms_ro # SNMP只读团体字生产环境建议用snmpv3 def fetch_alarms(): alarms [] # 假设厂商MIB中告警表的OID前缀为 1.3.6.1.4.1.2011.2.23.3.1.1此处为占位 iterator nextCmd( SnmpEngine(), CommunityData(COMMUNITY), UdpTransportTarget((HOST, 161), timeout3, retries1), ContextData(), ObjectType(ObjectIdentity(1.3.6.1.4.1.2011.2.23.3.1.1)), lexicographicModeFalse ) for errorIndication, errorStatus, errorIndex, varBinds in iterator: if errorIndication or errorStatus: break for varBind in varBinds: oid, value varBind alarms.append((str(oid), str(value))) return alarms def diff_and_process(new_alarms, old_alarms): new_set set(new_alarms) old_set set(old_alarms) added new_set - old_set cleared old_set - new_set # 新增告警转工单或推送通知已清除告警关闭工单 for item in added: print(f[{datetime.now()}] 新增告警: {item}) for item in cleared: print(f[{datetime.now()}] 告警恢复: {item}) return added, cleared if __name__ __main__: old_cache fetch_alarms() while True: new_cache fetch_alarms() diff_and_process(new_cache, old_cache) old_cache new_cache time.sleep(30) # 轮询间隔30秒太短会对网管造成压力这段代码的核心是“全量拉取本地差异比对”每30秒把网管的活动告警表全部拉一次跟上次的缓存做集合减法。新增的告警去开单消失的告警去关单。这样做的好处是不用依赖厂商主动推送通用性强缺点是大批量网元时全量拉取开销较大轮询间隔要谨慎设置。真正生产对接时强烈建议优先走厂商北向接口文档里的告警同步机制多半支持告警事件主动上报效率和时效性都远好于轮询。5. 光传输网管的常见翻车点现象、原因、解决办法5.1 网关网元脱管后全网“消失”现象网管上某个核心网元图标变灰紧接着它下游一大片网元全部不可达告警列表里全是管理通道中断类告警。原因你管理域里的其他网元都是靠这个网关网元转发管理数据的它一脱管整个DCN域对网管来说就断了。诱因多数是网关网元电源故障、到网管的IP路由失效或是该网元的ECC主控单板复位。解决先不要慌着去现场插光功率先查网管服务器到网关网元之间网络能不能通——用网管服务器ping网关网元的带外IP通了就说明是网关软件侧问题切到备网关即可不通就按“带外IP不通优先查交换机端口通着但网元无响应优先查主控单板”的路径走。事后一定要检查备网关配置是否完整很多“全网消失”的故障因为备网关没配静态路由主网关一挂就全线崩溃。5.2 ECC风暴全网性能数据采集把管理通道堵死现象网管系统突然变得异常缓慢大量网元的性能查询超时甚至出现设备间ECC通信告警但业务性能测试正常。原因常常是某次操作批量触发了全网性数据采集比如有人用网管脚本一次性查询几百个网元的24小时性能历史DCC通道带宽瞬间被填满网元间的ECC报文彼此碰撞形成风暴。解决即时缓解手段是在网管上取消批量查询任务必要时把非关键网元的性能采集临时停掉恢复后再逐批查。长期方案是给大网元数的管理域配置多个网关网元按网元分区把DCC压力分散同时把那些可预见的大批量数据查询任务安排在凌晨业务低谷期执行避免白天高峰时段撞车。5.3 时隙错配业务配置时“通而不对”的隐患现象某条新开业务在网管上配置完成状态显示正常但客户侧测试发现A端和B端数据不通或者通了却连到了错误的站点。原因SDH业务配置的核心是交叉时隙每个网元上把上游时隙交叉到下游时隙。如果中间某个网元的时隙分配表写错位置比如把时隙1交叉到了时隙5全链路看着是通的实际业务却拐到了别的方向。解决所有时隙调整必须先在规划表上把整条路径的“网元×板卡×端口×VC4/VC12时隙”矩阵填写完整再照表配置配置完成后在网管上逐个网元做“查询交叉连接”核对看实际配置和规划表是否一致。我自己的习惯是每个新开业务配完以后在网管上发起一次端到端的业务路径追踪逐跳核对时隙这一步能拦掉九成以上的错配问题。5.4 误码越限误报一看误码就换板子换了还没解决现象网管上出现B2误码越限告警维护人员赶到现场更换了线路板告警仍在或者隔几小时又复现。原因B2误码反映的是复用段性能即整段线路的信号质量。线路板只是其中一个可能点更常见的是光纤法兰头污染、光缆弯曲半径过小、相邻光路功率过高造成交叉干扰。你换了板子污染的法兰头还在问题自然没解决。解决严格按照“先查光路再查单板”的顺序排查。先用光功率计和OTDR实测该段的收光功率和光纤衰耗用无水酒精清洁法兰头和尾纤端面重新插拔后再看网管上的误码曲线只有光路指标全部正常而误码依旧的情况下才考虑更换光模块或线路板。这个顺序能避免很多无谓的板件更换成本。5.5 北向接口不同步投诉过来了监控平台还没告警现象客户电话打来说业务断了你们的监控平台什么告警都没有网管客户端上却明明报着紧急告警。原因北向接口的告警同步方式一般是增量推送但双方链路抖动或消息队列阻塞时告警事件会丢失。如果你用的又是全量比对轮询方案轮询间隔内新增又恢复的告警会被整体跳过造成“漏报”。解决生产环境建议同时启用两条补偿链路一条走事件订阅推送保证时效另一条每隔5~10分钟做一次活动告警全量比对兜底增量丢失的场景。同时轮流检查北向接口连接的日志查看有没有周期性的连接中断记录有则先去查中间的网络设备端口协商配置很多“不同步”其实是网管和平台之间的交换机端口出现了半双工或CRC丢包。6. 把光传输网管系统讲给不同人听课件的组织方式和我的最后一个习惯如果你需要把光传输网管系统做成PPT课件面对三类听众讲法应该完全不同。给刚入职的新人讲重点放在三层管理模型和一条业务路径如何走通让他会看告警、会查时隙、会跟路径给管理者讲重点放在网管系统能减少多少故障定位时间、怎么通过性能数据做预防性维护给客户讲重点则是功能覆盖能力——告警管理、性能管理、配置管理、安全管理、系统管理五大功能域各自能解决客户什么问题。我常用的课件结构是第一页画一张“网元—DCN—网管服务器—客户端—北向接口”的总体架构图第二页到第四页分别讲三层模型、DCC/OSC通道、网络拓扑和保护机制第五页放一组真实告警和性能截图做案例最后三页讲维护流程和常见故障排除。你在讲的时候要注意别一上来就讲私有协议细节先让听众形成“业务信号和管理信号在同一根光纤上各走各道”的画面感后面所有的DCC、网关网元、ECC技术点都能挂在这个画面上。课件做完以后我习惯自己对着拓扑把一条跨环业务的完整路径走一遍从A站客户侧端口开始沿交叉时隙逐跳走到Z站边讲边在网管上操作演示。不演示客户不一定信演示翻车了自己至少心里有底是哪个环节没弄明白。早年我给客户讲保护倒换时曾经把“光功率正常”和“光模块健康”混为一谈被客户现场用一根脏法兰头打了脸。后来我养成了一个习惯讲网管系统之前先亲手在网管上把要演示的每一个操作跑一遍顺手把误码历史和倒换日志截图留底。这个习惯救了我好几次希望你也能用上。本文还有配套的精品资源点击获取