简介中兴传输网管入门知识PPT面向零基础或初级运维人员系统讲解电信管理网TMN基础、SDH网管概述、信产部对EMS系统的技术规范及E300网管实例应用内容从TMN的引入背景、功能结构和信息结构展开逐一说明OSF、NEF、QAF、WSF等功能块q、f、x参考点DCF数据通信功能以及功能元件MAF、ICF、WSSF等、逻辑分层和管理信息模型等基础概念。随后过渡到SDH网络管理的监控、配置、性能与故障管理流程并结合信产部规范梳理EMS在功能、性能、接口、安全等方面的建设要求最后以E300网管系统为实例演示实际配置、操作流程和常见问题处理帮助读者把抽象标准落到真实运维场景中。资源包含1个PPT演示文稿压缩包仅741KB内容聚焦便于快速翻阅学习目前已有606人学习浏览可作为传输网管入门及岗位培训的参考资料。1. 中兴传输网管入门先搞清楚它管什么再谈怎么上手刚进传输维护岗的兄弟多半会被中兴传输网管那密密麻麻的拓扑图吓一跳一条链上二三十个光方向、几百个网元告警框每秒都在滚。其实这台网管说白了就干四件事——看见网元、配置业务、收告警、查性能。你不需要一上来就懂SDH和OTN的全套框架只要先把「网管能看到哪些网元、怎么登录、怎么找一条业务、怎么看一条告警」这四个问题接住后面所有操作都建立在它们上面。这篇文章按我当年带人的顺序写先认界面再搞懂网元和网管之间是怎么连着、怎么编号的然后跟着跑一条最小业务最后把最容易翻车的几个场景提前说破。适合刚接手中兴传输网管、或者准备从数通转向传输的运维新人。2. 从登录到第一张拓扑图先别急着点刷新先认清网管在管什么2.1 登录前的三项确认浏览器、账号和网管版本中兴传输网管的常见形态是NetNumen系列老一代习惯叫E300很多局点现在还在用采用服务器加瘦客户端的方式访问。你桌面上装的那个只是客户端真正存数据的是机房里的服务器。登录前我一般先做三次确认。第一是浏览器兼容。老版本管理面基于IE内核新版逐步支持Chrome内核但ActiveX控件、JRE环境这类依赖还在里面常见做法是把网管服务器地址加到「受信任站点」并把「启用保护模式」的勾选去掉否则容易出现登录页打开了、点进去白屏的情况。如果你手头是全新的浏览器先问同事要一份客户端环境包不要自己装最新版JRE去赌兼容。第二是账号权限。入门期一般给的是只读或操作员权限别指望第一次登录就能删除网元或改全网数据。用只读账号把「查询」「查看」类功能摸熟再申请配置权限。这样最大的好处是新手期手滑的概率被权限挡掉一大半。第三是版本和所在子网。登录框里通常要选服务器地址或区域同一个网管下可能划分了多个子拓扑。先确认你的站点在哪个子网里别进错区域后对着不存在的网元找半天。2.2 界面四大区拓扑、告警、配置和性能在哪儿看登录后你会看到一块主拓扑区周围嵌着若干面板。不同版本界面布局有差异但功能分区高度一致我按自己习惯把它分成四块。第一块是拓扑区也是平时盯得最多的。它显示网元图标、链路、光方向。颜色规则要记牢绿色正常、黄色有次要告警、红色有紧急告警、灰色代表网管暂时失去与网元的联系。灰色不是网元坏了先想传输通道和DCN的问题。第二块是告警面板通常分「当前告警」和「历史告警」当前告警可以按网元、告警级别、首次发生时间过滤历史告警是查账用的。第三块是配置管理入口网元的创建、删除、属性修改、业务路径配置都在这里属于权限最敏感的区域。第四块是性能管理入口用来开性能监测任务、看误码率和光功率趋势。很多新手喜欢一上来就点「全网刷新拓扑」结果所有网元闪一遍红黄告警乱跳什么也没看出来。我一般会先按子网展开只看自己责任区那一段链路确认没有新的灰网元或红链再往后查。这样定位快也不会给网管服务器增加无谓负担。2.3 正式动手前先做一次「网元摸底」在配置任何业务之前先用只读操作把责任区内的网元过一遍我管这叫摸底大概十分钟能避免后面很多糊涂账。主要做三件事第一打开网元属性面板核对网元名称、网元ID、网元IP这几项是否和台账一致。网元名称常见约定是「城市-站名-设备类型」再加序号比如「SZ-PARK-01」别小看命名后续所有脚本化操作都要靠它定位。第二在拓扑上双击一个网元看它的单板列表和保护类型确认它是汇聚层还是接入层设备这决定了它该跑多少业务。第三查看网元的版本号和单板软件版本记录到本地的运营台账里很多告警跟板件版本强相关排查时会用得上。这一轮下来你会发现网管不是黑匣子它的多数信息都可以用「右键-属性」或「视图-网元列表」这类入口找到。如果每个网元都要点一遍说明你的网管里还没有建好子网视图需要找管理员把拓扑按环或按片区整理好。摸底项查看入口关注点网元名称/ID/IP网元属性与台账一致不重不漏单板类型与保护网元单板视图有无11、有无复用段软件版本网元版本管理与局点基线一致主控/交叉状态网元运行状态备用主控是否同步3. 网元是怎么被网管「管住」的DCN、网元ID与IP规划三张表3.1 带内与带外DCN通道决定了你能不能点到网元传输网管和网元之间不是靠「接了根网线就能管」这么简单它依赖一个叫DCNData Communication Network的管理通道。这个通道有带外和带内两种形态理解它你才能看懂为什么某个网元在拓扑上灰掉。带外DCN是指每个站点单独拉了一条管理通道常走站内独立的交换机或用网元上的专用管理口接入一个管理网段。这种方式的优点是巡检、开局时即使业务光路没通网管也可以远程拿到网元。缺点是每个站点都要做数据配置和接入资源建站初期工作量大。带内DCN则是让管理报文搭载在传输业务的开销字节里沿复用段或光通道一路穿过去。实际局点里这两种经常混用。比如核心站点用带外接入层站点通过带内汇聚到核心站再由核心站统一上送网管。这样接入层可以少拉一根管理网线但代价是接入侧光路断了网管对下面整片网元的可视性会同步丢。新手遇到拓扑灰了一片时第一反应往往是「设备断电了」或「光缆断了」。在传输网里更准确的说法是「网管到这些网元的DCN路径断了」。哪怕业务光路正常只要用来带管理的开销通道异常网管照样看不到它。所以排查灰色网元先沿着管理路径查沿线路侧或DCN口逐跳ping。这个差异不大常用但特别管用。3.2 网元ID不只是一个编号命名与规划网元ID是网管用来唯一标识一个网元的逻辑编号类似于数据库主键。网元IP是它在IP网络里的管理地址两者在网管上共同决定身份。新建网元时最容易犯的错就是随便编一个ID觉得「数字不重复就行」但ID的规划背后还牵扯到日后维护效率。常见做法是按层级和区域划分ID段。比如核心层用01-99汇聚层用101-199接入层用201往上走。每加一个站先在台账里找到这个区域的下一个空闲ID再去网管里创建。ID一旦下发并与网元绑定后面再改就需要先在网管上删除原记录再重建操作期间业务不会断但管理会短暂中断所以尽量一次性规划对。IP规划我一般建三张表第一张是管理网段分配表记录每一段网段分给了哪个环或哪个片区第二张是网元IP明细表记录网元名称、ID、IP、掩码、网关、所属子网第三张是DCN口和网关网元的关系表。没有这三张表之前不要批量新建网元否则出了冲突排查成本远高于建表那半小时成本。同时要留意网元IP不要跟运维网内其他设备交换机、服务器冲突。传输网管服务器在向网元发包时用的是TCP/IP协议族IP重复会导致网管一会儿能管一会儿不能管像极了设备「间歇性失联」实际是地址冲突。3.3 验证连通性的最小操作新建完网元或发现网元灰掉时我习惯先做一轮连通性验证。在网管界面上通常会提供「Ping网元」的功能入口它的原理就是网管向网元管理地址发送ICMP报文可以直观判断带内带外通道是否通。如果界面上只能一个个ping那就用一段脚本把待验证的网元IP拉成列表逐条探测把结果按「可达/不可达」分到两个文件里。下面是一个通用做法适合在运维跳板机上跑#!/bin/bash # 网元管理IP列表一行一个放在 ne_ip.txt cat ne_ip.txt | while read ip; do # 发4个包等待3秒兼顾速度和准确性 ping -c 4 -W 3 $ip /dev/null 21 if [ $? -eq 0 ]; then echo $ip reachable reachable.txt else echo $ip unreachable unreachable.txt fi done这段脚本的要点在ping参数上-c 4指发4个包太少可能会误判瞬时丢包太多在成百上千网元列表上耗时太慢-W 3指每个包等3秒对传输网管的链路延时来说是合理阈值。脚本跑完先看不可达列表有多少如果一整段都是不可达基本可以判断是这一段的DCN通道问题而不是网元单点故障。值得补一句的是ping通只代表网络层通了不代表网管应用层一定没问题。如果ping通但网管依旧显示不可管那要往网管服务器的连接数、用户名密码同步这类方向查。也就是说「ping通」只是第一步门槛不是最终结论。4. 跑通第一条业务路径从单站创建到时隙核对4.1 把SDH和OTN的路径概念先对齐中兴传输网管本身同时管理SDH和OTN两类网络两者在业务配置上的逻辑层级不一样。如果你的站点还在跑SDH路径的颗粒是VC4或VC12一条业务从A站穿到Z站中间经过多个网元每一步都要占用对应方向的时隙。OTN这边更常用的是ODUk和OCh波长管理面侧重在光层和电层交叉上。入门阶段不要求你把交叉连接背全但要在脑子里立住一个模型任何一条传输业务都可以拆成「路径」和「交叉」两样东西。路径是A到Z的逻辑走向交叉是每个中间网元内部从某个端口到另一个端口的连接关系。网管界面上配业务本质上就是在若干网元内部各建交叉并把它们拉到一条路径里。所以当你发现业务不通时排查顺序也不是先去现场插光功率计而是先看网管上「这条路径是不是真的建成完整了」再看每个交叉点的相关端口有没有告警最后才轮到物理层。做传输维护的都知道数据上的BUG往往藏在某个中间网元漏配交叉上。4.2 搜时隙、配路径一个最小业务配置顺序下面给一套最小可用的配置顺序适合你在网管上用一条VC4做通A、B两个站点的双向业务。前提是这两个站点已经在拓扑上可见且光方向已经建好。第一步先做源宿网元的端口确认。在A网元上查业务接入端口一般是支路板上的某个光口或电口记下端口编号。第二步在B网元上做同样操作。第三步打开网管里的「路径管理」或「业务配置」向导源选A端口宿选B端口网管会自动搜索可用时隙。这时注意看搜索出来的路径走向是不是你想让它走的那一段。搜索完成后界面上一般会列出整条路径经过的每一跳网元和占用的时隙。逐跳核对一次A到中间站的线路板时隙、中间站交叉后的时隙、再到B站的落地时隙。这步花不了几分钟但能挡掉后面一半的业务配置翻车。确认无误后提交网管会把交叉配置下发给各个网元。下发成功的标准是每个网元返回配置成功而不仅仅是界面提示「创建成功」。很多新手看着向导走完了就以为没事结果现场业务不通回来看中间网元交叉压根没写进去。配置完成后做一发一收的环回测试或用网管自带的业务测试工具从A端口打一个测试信号到B端口看远端能不能收到。如果收到说明这一条VC4路径全程贯通。4.3 配置下发不成功时先看这四行配完路径不成功别急着拆了重配。先在网管任务列表里找到刚才那条配置下发记录重点看四行信息第一行是下发失败的网元名称它告诉你故障点在哪一段第二行是失败原因编码常见如「时隙冲突」「端口已被占用」「网元不可达」第三行是已下发成功的网元列表用来评估有没有形成半配状态第四行是需要手工核对的数据比如端口模式变了或单板类型不支持。时隙冲突是最常见的失败原因。往往是你搜索时只搜了主用路径没查保护路径结果保护路径上的时隙被别人占用。解决方向不是换一个主用时隙硬配而是先去时隙占用表里查整条保护通路的空闲情况再回来重新搜索。另外要留意业务方向。SDH业务讲究收和发两个方向配对网管向导一般会一次性把双向建好。如果只建了单向A到B忘了B到A业务表现为「能收不能发」。查这条的时候别只看网管路径列表的完成状态要分别看正向和反向路径是否都存在。检查顺序建议 1 网元是否在线拓扑灰色就先修DCN不修DCN不发配置 2 时隙有没有冲突到时隙占用表里核对整条路径 3 端口是否正确方向、板位、光/电口类型 4 保护关系是否介入11保护时主备路径需同时满足条件第一次跑通一条路径之后你会建立对整个网管配置流程的信任感它本质上是一个「选端口、搜路径、核对、下发」的标准动作。之后配OTN波长、配MSP保护、配SNCP步骤虽有差异但都是这个套路上的变种。5. 避坑这些操作会让网管「翻车」现象、原因和后悔药5.1 网元ID冲突三台网元轮流掉线现象某天拓扑上三台接入层网元开始轮流变灰有时是A掉有时是B掉每次持续时间不长告警面板上反复出现「网元通信中断」又自动恢复。业务倒是没有大碍但值班电话被打爆。原因后来查台账发现三台网元在网管上的ID段规划乱套有两条记录把ID重复用在了不同网元上。网管在下发数据时往这个ID对应的通道上发命令结果多个网元都认为是发给自己的造成互相抢答。现象就成了轮流失联。解决先在网管网元列表里按ID排序把所有相同ID的记录摘出来对照IP确认实际设备各自的真实编号。把多余记录删除或重建并重建ID规划表。这事情是典型的初始化没做细的后果后期根除只能逐个改动并验证没有捷径。5.2 浏览器白屏与Java运行环境现象登录网管时账号密码都正确页面也跳转到了主框架但拓扑区域一片白刷新没用重启客户端也没用。原因老版本网管客户端的拓扑组件依赖Java运行环境或特定ActiveX控件。很多人图省事装了最新版Java或者浏览器默认把网管地址的脚本拦截掉导致拓扑组件加载不完整。属于环境类问题不是网管本身坏了。解决把网管服务器地址加入受信任站点关闭保护模式卸载后重装运维要求的Java版本。装完记得完全关闭浏览器再重开Java插件常需要新会话才生效。以后每次升级浏览器或打系统补丁后习惯先验证一次网管能不能正常显示拓扑省得用到时再抓瞎。5.3 网关网元断了整片网元全灰现象某个汇聚站点停电或光缆中断后网管拓扑上不只是那一个站灰掉它下面带的一整片接入网元全灰告警面板里出现一大批通信中断告警。原因接入层网元通常走带内DCN且默认只有一条管理路径上送给上端汇聚站。一旦汇聚站本身脱管下游所有走它转发管理报文的网元全部失去管理通道。业务可能没有中断如果业务光路还通但你在网管上已经什么都看不到了。解决在每个汇聚点启用两个网关网元或为接入层网元再开一条备用DCN路由。维护中如果发现某一片网元集中灰掉先把排查重心放在这一片的汇聚点电源和上联光口上。另外光路余量允许的区域可以做带内管理路由冗余虽然多占一点开销带宽关键时刻是保命的。5.4 配置改完不下发业务「假成功」现象在网管上把某个端口的环回状态或开销字节改了界面提示修改成功但现场测试业务行为没变化。原因网管界面操作分「改内存数据」和「下发到网元」两步。不少新手只做了第一步数据只存在于网管本地缓存里网元实际没执行。一些网管版本在操作完成后会弹一个「是否下发」的选择框被随手关掉数据就留在缓存里悬空。解决每次修改配置后养成习惯打开配置管理里的「未下发修改」列表看一眼。有挂起的修改确认无误后逐个下发。这个列表是网管的后悔药但也可能变成翻车源头——如果里面攒了几十条旧修改一次性下发会把老配置一起改动所以建议每天下班前清理一遍未下发项。5.5 网络拓扑画错位置数据对看起来不对现象业务配置、告警查询都正常但拓扑图上有一条链路画在了一个不存在的站之间看着特别别扭。新人常以为是显示故障反复刷新去不掉。原因拓扑图上的连线和网元位置一部分靠网管自动发现一部分靠人工整理。人工拖动网元图标或手工连光方向时手滑存错了位置。拓扑图严格来说只是给人看的不会影响底层数据但会影响下一个值班人员的判断。解决在网元或链路属性里核对两端实际端口把画错的连线删除后重新拉线。千万不要为了「图好看」去反复拖动图标而忽略底层关系。拓扑图是你的作战地图地图画错了后续查障等于在迷宫里转圈。6. 收尾技巧把告警和性能导出发成接班报表脚本入门三个月后你大概率会接到一个固定任务每天交班前导出当天告警整理成一篇「今日传输网运行情况」。手动在网管上导Excel再复制粘贴每天耗掉二三十分钟机械又容易漏。我建议你把这一步做成半自动脚本把时间留给真正要判断的事。中兴传输网管普遍支持把告警和性能数据导出为CSV或TSV文件先从网管里按时间范围把「当前告警」导出成文本文件再用脚本去重、按站点归类、按级别排序。下面的脚本是通用做法适配你本地导出的文件字段即可import csv from collections import defaultdict # 假设导出的告警文件为 alarms.csv字段含告警名, 网元名称, 级别, 发生时间 alarm_file alarms.csv stats defaultdict(list) with open(alarm_file, encodinggbk) as f: for row in csv.DictReader(f): level row[级别] ne row[网元名称] # 只统计紧急和主要两级次要告警太多单独留底 if level in (紧急, 主要): stats[ne].append(f{row[告警名]}{row[发生时间]}) for ne in sorted(stats): print(f[{ne}] 告警 {len(stats[ne])} 条) for item in stats[ne][:5]: # 每个站最多列5条避免刷屏 print(f {item})这段脚本里有两个参数很关键。encodinggbk是应对网管导出文件常用编码的常见做法如果你打开报编码错误改成utf-8或gb18030再试。stats[ne][:5]做了截断因为接入层站点告警一多就是几十条全打印出来反而没法一眼抓到重点。跑通告警脚本后可以顺手把性能导出的光功率历史文件做同样处理按站点算出平均值和极值这样接班的人不用翻几十页图表一眼能看出哪个站光功率在往下掉。我现在每次做这类数据工作一定会先看导出的时间范围是不是跨了日切再确认编码脚本再顺手也会被这两个细节坑过。希望帮到你。本文还有配套的精品资源点击获取