企业官网建设流程全解析

简介：格林威尔网管功能与业务开通以PPT形式梳理了UniView DA网管系统的操作要点，适合从事光传输网络维护、设备开局与业务开通的工程师参考。内容从网管Server与Client启动开始，逐步讲解主菜单、拓扑窗口、告警面板等界面，并针对用户、网元创建、局站与区域管理给出操作路径；对数据库上载与校验、槽位配置、E1业务、以太网配置、时钟源和虚级联等环节亦有说明，可帮助读者按步骤完成业务部署与排障。资源包共1个文件，类型为pptx，整体大小6.44MB，便于直接阅读或投屏培训使用。该PPT目前已有254人学习，适合网管初学入门及日常配置对照复习。

1. 格林威尔这份网管PPT，讲的就是开局第一天那两件事

拿到“格林威尔网管功能、业务开通.pptx”这类标题的PPT，一般是接入网项目交付期或代维交接的培训材料。格林威尔做的是接入层MSAP设备和光传输系统，网管功能核心就是两件事：把散在各站点的设备纳入网管统一管理，再在网管上端到端开通业务并保证它稳定运行。这份材料适合工程交付、代维和售前工程师，它把开局调试里最含糊的两个动作——网管功能配置和业务开通流程——拆成了可照做的步骤。

业务开通不是只在网管上点几下鼠标，背后还有时隙规划、VLAN映射、时钟同步和保护倒换。新手下发完配置发现业务不通，多半是某个中间环节没对上。下面把能复现的操作步骤和踩过的坑摊开讲，先看网管怎么管设备，再看业务怎么放通，最后聊哪些参数值得多看两眼。

2. 先把网管管什么理顺：拓扑、告警与配置下发

网管功能菜单看着很多，实际上就四块：拓扑管理、告警管理、配置管理、性能管理。开局阶段不用每个菜单都摸一遍，把通道建好、把设备加进来、把告警读懂，后面所有业务开通都建立在“网管能看到设备真实状态”这个前提上。

2.1 带外还是带内：网管通道怎么建，开局就定死

格林威尔的网管通道有两种接法：带外和带内。

带外是设备上单独留一个网管口，通过交换机连到网管服务器，和业务通道物理隔离。优点是业务流量再大、业务光纤再断，网管通道通常还在，排障时有退路；缺点是每个站点多占一个网口、多拉一根线，对于只有一两台远端设备的接入点来说成本偏高。带内则是借用业务以太网口或E1里的一个时隙来跑网管协议，省线省端口，但网管流量和业务流量挤在同一条通道，一旦业务光纤中断或拥塞，网管也就跟着失联了。

开局选哪种，我的习惯是：汇聚节点一律带外，远端接入点用带内。带内网管配置时要单独划一个管理VLAN，业务VLAN和管理VLAN严格分开。很多项目图省事把网管地址直接放在业务VLAN里，表面看少配一样东西，等业务量上来、广播报文一多，网管卡顿、掉地址就成了常态化问题。

设备首次初始化一般用串口。串口参数不同设备固件版本有差异，常见是115200或9600，8位数据位、1位停止位、无校验，登进去先看提示符，不要闷头敲。初始化要设三样：设备管理IP、掩码、网关。IP规划表必须在开局前做好，一台设备一个管理地址，备注站点名称和业务归属。这个表我一般做成Excel，带子网和VLAN分配，后面加设备、加网元全靠它，临时起地址大概率会撞。

网管服务器侧还有SNMP团体字要约定。读写团体字不要用默认的public，开局时统一改掉。格林威尔网管添加设备时填的IP、团体字、协议版本必须和设备侧一致，否则会出现“网元添加成功但一直灰色”的假象。通道建好之后，第一步就完成了，后面所有动作都在这条通道上跑。

2.2 设备发现与拓扑生成：网管里添加一台格林威尔设备的完整动作

网管连上设备，拓扑里能看到设备图标，才算开局第一步走完。常见做法是手动添加网元：进入网管客户端的“网元管理”，点添加，填设备名称、管理IP、掩码、网关、SNMP团体字和协议版本。填完提交，网管会先做一次可达性检测。

检测通过后，设备会出现在拓扑区，图标状态逐渐变成绿色。此时不要急着配业务，先做两件事。一件事是把设备之间的光纤连接关系在拓扑上画出来，也就是拉链路。网管上拉链路要选两端的光口，填写链路名称。这个动作看起来只是画图，实际上后面的保护倒换和告警定位都依赖链路关系，链路画错或者漏画，出故障时网管判断的根因位置就是错的。

另一件事是立即做一次配置备份。格林威尔网管大多支持把设备当前配置导出到服务器，导出文件按站点和设备IP命名，例如“GTZH-XX局-10.10.10.2.cfg”，存到项目配置库。这一步是开局阶段的后悔药，后面改配置改坏了大不了导回，不用扛着设备跑现场。

网元命名也要规范。拓扑图上设备名不要用默认IP或随意字母，命名规则建议是“站点名-设备角色-序号”，比如“XX局汇聚-MSAP-01”。拓扑视图上信息有限，名字起得清楚，排障时一眼能认出是哪个站的哪台设备。交付后期运维值班人员依赖的就是这些基础信息，开局图省事，后面全是麻烦。

自动发现功能也值得用，但建议分网段扫描，不要全内网一把扫。扫出来的设备要认真核对类型和软件版本，网管对设备的协议兼容版本有范围，老型号设备配上新版网管，可能出现“协议协商失败”或者性能数据读不到的提示。遇到这种情况，直接查设备软件版本是否在网管支持列表里，别先怀疑网管坏了。

2.3 告警窗口别只看状态灯：把性能数据当排查依据

告警管理是网管使用频率最高的页面，尤其是当前告警和历史告警两个视图。告警分级别显示，光口收无光、E1信号丢失这类属于严重告警，端口CRC超限可能只是性能告警。运维有个坏习惯是把告警一条条确认掉就完事，真正干活的人应该反过来想：这些告警只是结果，性能数据才是原因。

格林威尔网管里一般有性能监视功能，可以统计每个光口的收发光功率、E1通道的误码和帧失步、以太网口的收发帧数及CRC错误帧。看这些计数器时，先选时间窗口，15分钟或24小时，看平均值、最大值、最小值。平均值最能说明问题：如果某光口收光功率平均值已经接近接收灵敏度下限，那链路时断时续只是时间问题，早该安排清洁光纤或更换光纤。E1误码要看滑码和帧失步，只要这两个计数持续上涨，哪怕当前告警为空，业务迟早要抖。

定期看性能数据还有一个用处：在业务割接前做预检。比如第二天要割接一条专线，头一天晚上先把经过的光口收光功率、误码计数、丢包计数记录下来，割接后对比同一组数据，就能判断割接是否真正影响了链路质量。这个习惯我一直在用，很多割接后的问题其实割接前就存在，留了基线才不会背锅。

另一个常用功能是告警相关性或告警屏蔽。接入网最怕的是下面一台设备掉电，网管上冒出上百条告警，全是下游链路中断、网元不可达。开局时把同一下游网元的告警归并规则配好，或者在告警显示里做过滤，让根因告警浮在最上面，子告警折叠起来。告警抖动抑制参数也可以设，防止光口瞬断反复上报刷屏。这些参数网管默认未必全部开启，交付前要专门检查一遍，否则第一次全网掉电就会是告警风暴现场。

3. 在格林威尔网管上开通一条业务：从端口规划到交叉连接生效

业务开通进入实操环节。格林威尔设备上最常见的两类业务是二层以太网专线和E1专线，开通思路一致：规划、配置、下发、验证。很多人直接在网管里点“新建业务”，一路Next，配通了也不清楚自己到底建了什么东西，后面维护就抓瞎。先规划再动手，业务才可维护。

3.1 业务开通前先拉一张端口与VLAN映射表

业务开通的第一个动作不是登网管，而是画一张表。以一条以太网专线为例，至少要列清楚：业务编号、客户名称、A端站点、A端设备名、A端用户端口号、A端上联光口、业务VLAN、B端对应信息、保护要求、带宽值。下面是一张我在项目里常用模板的简化版：

这张表的意义在于把网管上每个参数都落到物理位置。E1业务要额外加“时隙范围”字段，比如“1-4时隙”，以及两端时隙一一对应关系。做这张表时最常犯的错是把VLAN规划得随心所欲，今天用100，明天用200，中间又是透明传输，最后全网VLAN混乱，查故障时谁都不敢动。VLAN分配应该跟业务方向或客户绑定，汇总表和IP规划表一样，放在项目配置库共享。

端口与VLAN映射表还有一个作用，就是给运维留操作依据。半年后客户报障说某条专线不通，运维打开表一看就知道这条业务两端落在哪个机柜的哪个端口上，上联光口是哪一根纤，VLAN是多少。没有这张表，运维只能登录网管一条条翻业务，时间成本完全不同。

表画完，还要确认一个物理前提：两端设备之间的光路已经调通。业务在网管上配置之前，建议先在光路上做一次光功率测试，接收光功率要在设备光模块的动态范围内。光路没调通就去配业务，是不少项目返工的原因。

3.2 在网管里创建一条以太网专线的操作顺序

以两端各一台MSAP设备、中间光路已通的场景为例。在网管上开通以太网专线，我习惯按以下顺序操作，先单点后端到端，出了问题好定位。

第一步，在A端设备上配置以太网端口。把用户侧端口设为access口，PVID设为业务VLAN，端口状态打开；如果对端局域网是trunk模式，这里要按对方要求改为trunk并放行指定VLAN。第二步，在A端上联光口上放行业务VLAN。这一步经常漏，端口配了半天、网管上业务也存在，但光口不放行VLAN，报文就过不了设备。第三步，在B端设备上重复前两步，确保两端VLAN、端口模式、PVID完全一致。第四步，在网管的“业务管理”或“交叉连接管理”里创建端到端业务，选择A端端口和VLAN、B端端口和VLAN，网管会自动生成一条业务路径，页面会显示“未下发”。第五步，下发配置。下发时网管会做参数校验，常见校验失败原因是端口已经被占用、VLAN已有业务，或者两端设备版本不一致。下发成功后业务状态变为“已生效”，拓扑上能看到业务连线。

为什么要在端口配置之外再建一层端到端业务？因为物理端口配置只解决了单点转发，网管需要一条“业务路径快照”来管理保护和告警。有了这层业务，光口断纤时网管才能自动把告警关联到具体客户业务，保护倒换时才知道哪些业务受影响。很多代维人员查不到业务就改端口配置，把设备配置改得面目全非，就是这个环节没理解。

下发配置有一个关键动作：保存。之前讲过，网管下发分“仅运行时”和“保存”两种情况，未保存的配置在设备重启后丢失。点完业务生效，马上到网管或设备侧做保存，这个动作要养成肌肉记忆。

注意：配置下发并保存后，再做端到端测试。测试中发现异常需要改配置时，每次改动都重复“下发、保存、验证”三步，任何一步都不要跳。

3.3 用 ping 和环回把业务验证到“敢交工”

网管显示业务已生效，只是第一步，业务真正能承载用户流量才算开通完成。二层以太网专线最直接的验证是接一台测试PC，在A端用户口接笔记本，B端用户口接另一台笔记本或交换机，设置同网段IP，连续ping。

# 业务开通后基础验证：连续发送 500 个 ping 包统计丢包 ping -i 1 -c 500 10.10.10.2 | tail -n 3 # 若发现间歇丢包，用 mtr 以报告模式观察路径上的丢包点 mtr -r -c 300 10.10.10.2

ping命令里-i 1表示每秒发一个包，-c 500表示一共发500个，tail -n 3只取统计汇总行，重点关注丢包率和延迟抖动。mtr的-r是报告模式，-c 300表示探测300次，它能列出从本机到对端的每一跳丢包率，适合把问题定位到具体设备。二层专线里mtr看到的是转发路径，如果某台设备丢包率明显高于其他跳，问题大概率在那里。

这里要说明，ping通只代表三层通了，还要在网管上看端口计数：两侧用户口和光口的收发字节数是否在增长，CRC错误包是否增加。如果ping通但CRC持续上涨，说明链路物理层存在劣化，交工之后会很麻烦。E1业务则用误码仪或网管的软件环回做测试，软件环回会短暂中断业务，必须申请维护窗口后操作，测试完立即取消环回。

验证不要只看几分钟。接入网很多问题是间歇性的，我会建议在网管上开临时性能台账，观察15分钟到24小时的丢包和误码趋势，再正式交工。多等一个晚上，比来回跑两趟现场划算。

4. 让已开通的业务经得起割接：保护、限速与时钟三个细节

业务通了只是开始，交付前的割接和长期稳定运行才会暴露问题。这一章讲三个经常在业务开通后一两个月才被发现的设置：保护倒换、端口限速、时钟同步。它们不是默认配置就能用好的，需要主动规划和调参。

4.1 通道保护与环网自愈：什么时候用，什么时候别用

格林威尔设备提供的保护方式常见两类：一类是光口1+1通道保护，一类是环网自愈。1+1通道保护的思路是主用光口和备用光口同时收发相同数据，接收侧根据光功率和误码选优，主备之间切换对业务基本无感。它适合星型组网里从接入点到汇聚点这一段，实现简单、倒换快，代价是光纤资源翻倍。

环网自愈则是把多个节点串成一个环，正常时业务走主环，断纤时环网协议把业务倒换到备用路径。它节省光纤，但倒换时间受协议实现和节点数影响，配置不当还会出现全网广播风暴。选型时不用贪多：节点少、有现成主备光路的就做1+1；节点多、必须省光纤的才考虑环网保护。

保护组参数里有两个要重点看：恢复模式和非恢复模式。恢复式是故障消失后业务自动切回主用口；非恢复式是故障消失后业务继续走在用的备用口，不再切回。开局阶段我一般建议先用非恢复式，因为线路刚刚调通，主备光路状态未必稳定，频繁自动切回会造成业务闪断。等观察一两周，确认主用路径稳定，再改成恢复式。

还要注意保护组里的“倒换门限”。有的网管以收光功率为门限，有的以误码率为门限，默认值未必适合你的光路。如果光路质量本来就一般，门限设得太灵敏，保护组会反复倒换，用户业务频繁瞬断，那就不叫保护而是灾难。设置前先看当前收光功率和误码统计，再留出合理裕量。

4.2 端口限速和优先级：格林威尔设备上容易被忽略的QoS点

接入设备的QoS能力有限，但端口限速基本都有。专线业务要按合同带宽设CIR（承诺速率），否则一个用户跑满带宽，同链路其他业务全部变慢，最后运营商和客户的矛盾都集中到你身上。

在网管上找到以太网端口的“带宽配置”或“流量整形”，把CIR设为合同带宽，PIR设为CIR的1.2到1.5倍。PIR的意思是允许突发，给TCP突发留点空间，但也别设太大，否则限速形同虚设。同时把超过CIR的流量标记为低优先级，这样拥塞发生时先丢低优先级报文，保障承诺带宽内的业务不丢包。

这里有个容易踩的坑：限速方向。有些设备的限速分上行和下行，上行是用户往设备方向发，下行是设备往用户方向发，两个方向要分别设置。现实里不少业务上下行不对称，比如视频监控上行带宽大，办公业务下行带宽大，按合同分别设置，别图省事填同一个数。限速配置还有一个容易忽略的关联项：广播和组播风暴抑制。接入设备端口默认对广播报文没有限制，一旦用户侧交换网络出现环路，广播风暴会打满上联带宽，此时端口限速只限制总速率，并不能阻止广播报文占满带宽。端口属性里一般有广播、组播、未知单播的速率限制配置，按端口带宽的百分比设置，比如广播不超10%，组播不超20%，这个设置对保障专线业务质量很有用，但很多开局人员只做了总限速就结束了。

配置完成后在网管上看端口收发速率，判断限速是否真的生效。如果业务速率长期超过CIR但端口统计里没有任何丢包，多半是限速策略没有真正下发到端口，只是界面显示成功。这时候到设备侧查看端口配置确认，或者重新下发一次并保存。

4.3 E1与以太网混跑的时钟设置：漏了它后患无穷

E1业务对时钟的敏感程度远超以太网业务。两端设备如果各自用自由振荡或内时钟，频率偏差积累到一定程度就会出现滑码。网管上看到的现象是：E1端口偶发AIS、帧失步告警，或用了一段时间后发现数据有单字节错位。很多人以为是运营商线路问题，最后查出来是自己时钟配置没做。

格林威尔设备时钟配置一般有几种模式：内时钟（本地振荡作为主时钟）、线路时钟（从E1接收信号中提取时钟）、外时钟（从外部时钟口输入）。组网原则很简单：同步网必须有唯一的主节点，主节点用内时钟或外时钟，下游节点全部线路时钟跟随上游。

开局时把汇聚侧设备设为主时钟，接入侧设备设为线路时钟，然后看网管上的滑码计数和帧失步记录，持续10到15分钟增长为零，才算真正锁定。如果接入侧设备下面还串着别的设备，要一级一级传下去，形成一条完整的时钟链。时钟链路上只要有一个节点配置错，下游全都会抖。

时钟失步的另一个隐蔽来源是中间传输链路本身有滑码。比如E1专线中间经过运营商传输网，对端设备如果时钟质量差，你这边线路时钟提取出来的信号本身就带漂移，网管上同样表现为偶发误码。这种情况可以尝试把本端改为内时钟，与对端协商由业务侧吸收漂移；如果协商不下来，就要把误码统计和告警截图留档，作为与传输侧对接的依据。

有些业务是E1和以太网混跑，以太网业务看似对时钟不敏感，但设备里E1部分失步引发内部总线时序抖动，以太网也会跟着间歇丢包。所以遇到混合设备上以太网掉包、查不到原因时，先去看E1时钟状态，这是血泪经验。

5. 格林威尔网管业务开通避坑：五个常见翻车现场与排查顺序

业务开通这个环节，翻车最多的不是设备本身，而是配置动作的顺序和细节。下面五条都是实际项目里反复出现的场景，按现象、原因、解决三段写，可以直接照着排查。

5.1 网管能看见设备，业务却死活不通

现象：网管拓扑里设备图标是绿色，告警为空，但两个用户端口之间互ping不通。

原因：最典型的是业务配置只在单端生效。比如A端用户口和光口都放行了VLAN，B端光口没放行；或者两端业务VLAN不一致，一个配了100，另一个配了200。另一种情况是网管走带内通道，网管能通只说明带内管理通道是好的，用户业务走的可能是另一条光口路径，路径上没有配置放行。

解决：按“端口状态 → VLAN放行 → 交叉连接 → 用户终端”顺序查。先看两端用户口和光口是否都UP；再在设备侧或网管上查VLAN放行和PVID；再看端到端业务是否已下发成功；最后确认测试PC的网口本身没有问题。排查时每确认一步就在映射表上打个勾，避免漏查。

5.2 设备一重启，昨天开的业务全没了

现象：前一天配置好的业务和数据全部正常，第二天站点断电重启，设备起来后业务全部丢失，甚至恢复到开局初始状态。

原因：配置下发到了设备运行内存，但没有被保存进存储介质。格林威尔网管或设备串口下发配置时，默认动作可能只是“应用”，有计划地重启后配置才真正写入存储。很多配置界面里“应用”和“保存”是两个按钮，点应用后不点保存，就埋下了这个雷。

解决：养成“配置三连”的习惯：下发、保存、备份。无论通过网管还是串口改配置，改完都立即执行保存命令，再导一份配置备份到网管服务器。备份文件备注日期和改动内容。设备重启后第一时间对比当前配置和备份文件，差异一眼就能看出来。

5.3 E1 接口满屏告警，时钟背锅最多

现象：E1端口或2M通道反复上报AIS、LOM一类告警，业务时好时坏，用仪表测试又发现偶发滑码和误码。

原因：一是两端时钟源不一致，接入侧设备没有跟随上游线路时钟；二是E1线缆的收发两根线接反；三是中间传输链路存在衰耗或抖动。最隐蔽的是第一种，因为网管上不一定直接显示“时钟失步”，只会表现为误码和告警。

解决：先把E1线缆收发对调排除物理接错，再用软件环回或误码仪把问题限定到线路还是设备。然后查时钟配置：主用设备开内时钟，从设备开线路时钟。查完时钟后看网管性能统计里的滑码计数，15分钟不再增长才算锁定。这里最容易翻车的是把责任推给运营商，其实自己设备时钟配置错的概率很高。

5.4 拓扑上链路红绿交替，先查三级光衰

现象：网管拓扑里两个设备之间链路状态反复UP、DOWN，光口告警时有时无，业务表现为周期性中断。

原因：光路处于临界状态。常见来源是光纤活接头污染、法兰盘松动、光纤弯曲半径过小、光模块收光功率接近灵敏度下限。这种问题在网管上往往只看到链路抖动，看不到具体原因，属于接入网最常见的玄学问题。

解决：第一步在网管性能管理里看两端收光功率，低于接收灵敏度上限3dB以上就要警惕；第二步拿光功率计现场测光路衰耗，重点查法兰盘和跳线接头；第三步确认两端光口速率和双工模式一致。排查时还要留意尾纤类型和波长匹配，单模光纤配多模模块、1310nm模块对上1550nm光路这类情况在接入网并不少见，现象同样是收光功率异常或链路时断时续。开局时在映射表上记录每个光口的波长和光纤类型，能省掉不少现场往返。光功率计测出衰耗大，先清洁接头再考虑换跳线，别急着换设备。

5.5 全网告警风暴，别在风暴中心排查

现象：某个接入点掉电后，网管上刷出几十上百条告警，当前告警页面滚动不停，真正影响业务的根因被淹没。

原因：一台下游设备掉电，它下面挂的所有设备同时失联，每台设备失联都产生网元不可达和链路中断告警；如果再有环网，关联告警会进一步翻倍。这不是设备故障，是告警归并策略没做好。

解决：在网管里配置告警相关性规则或过滤规则，把同一下游方向的告警收敛为一个根因事件。已经发生的告警风暴，先按拓扑结构找到最上游的失联节点，从它开始查供电和主链路，不要在风暴中心逐条处理。风暴过后清空历史告警，把告警阈值和屏蔽规则调好，避免下次再来一轮。

6. 照着PPT功能清单做一次自查：把网管交到运维手上

6.1 把PPT里的功能清单变成一张验收自查表

PPT里列出的网管功能和业务开通流程，到交付阶段应该变成一张可勾选的验收表。下面这张表是我验收时常用的最小集，每一项都对应一个具体动作：

验收自查表的价值在于：PPT讲得再漂亮，最终要落到“哪台设备、哪个端口、按什么标准验证”。这张表填完，网管系统才算真正具备交到运维手里的条件。

6.2 交运维之前的两个固化动作：备份与告警阈值

交付运维前还有两个动作一定不能省。一个是全量配置备份，把开局配置、业务配置、IP规划表、VLAN映射表打包放到项目共享目录，文件名带日期和设备IP，半年后设备故障需要更换时，这套资料就是恢复业务的底稿。另一个是告警阈值设置。光功率低门限不能设得太靠近灵敏度极限，否则光路正常波动就会误报；也不能设得太松，否则光路已经劣化还没有预警。我一般把低门限设在正常收光功率以下4到5dB的位置，具体数值根据现场实测调整。

说实话，我每次做完一个点位的业务开通，都会把网管功能清单和业务开通流程缩印成一张A4纸贴在机柜内侧。这样半年后运维打电话说业务不通，我先问拓扑是不是红色，再问哪一段光纤动过，比现场抓瞎快得多。设备会换，网管版本会升级，但“先看哪里、后动哪里”的顺序不会变。希望帮到你。

本文还有配套的精品资源，点击获取