简介：GPON网络配置脚本解析文档，面向从事接入网运维的网络工程师及正在学习无源光网络的技术人员，以实际OLT配置脚本为线索，清晰拆解从登录设备、创建业务VLAN与QinQ、配置管理接口到ONU注册、下发管理地址和service-port绑定的完整过程，同时涉及服务端口绑定、display board与display ont状态检查等关键命令。包体为1个PDF文件，压缩包仅9KB，体积小巧，适合作为现场配置时的快速参考手册。内容聚焦常见命令及其作用，例如VLAN 4000与QinQ、VLANIF 100私网地址、SN认证添加ONU、网管模板下发等，并配有display验证与save保存环节，能帮助读者理解设备配置逻辑、减少命令行误操作，还可延伸到带宽分配、QoS策略与安全管理等网络规划问题。目前已有一百人学习下载，适合需要快速掌握GPON基础配置与排错思路的入门及中级网络运维人员。

1. GPON 配置脚本：OLT 和 ONU 侧命令到底怎么落

光猫注册不上、OLT 上查不到 ONU、业务 VLAN 透传不通——这三句话基本概括了 GPON 开局最常见的三种翻车现场。这份 GPON 配置脚本恰好把华为 MA5680T（OLT）和 MA5626（ONU）从登录到业务通道建完的完整命令串了一遍，覆盖 VLAN 规划、QinQ 打标、ONT 注册、管理地址下发、SNMP 模板绑定、service-port 通道建立，甚至连 ONU 侧批量建 VLAN 和端口映射的批命令模板都附上了。对刚接触 GPON 开局的人，这份脚本是能直接照着敲的作业；对已经配过几台设备的人，它更像一份排错对照表——哪条命令没生效、哪个参数写错，回头翻一翻就能定位。我按自己拆解这份脚本的顺序，把命令逐段拆开讲清楚，重点放在为什么这么配、参数怎么改、踩坑点在哪。

2. VLAN 规划先行：业务 4000 走 QinQ，管理 100 单独隔离

VLAN 规划是整个 GPON 开局的地基。一份脚本里先建业务 VLAN 还是先建管理 VLAN，直接决定后面 ONT 注册和下业务通道时会不会绕弯路。我一般把这一步理解成「先把路修好，再让车跑」——这里的路就是 VLAN，车就是管理报文和业务报文。

2.1 业务 VLAN 和 QinQ 标签：为什么业务 VLAN 要打 q-in-q

脚本里的第一条关键命令是vlan 4000 smart，这是创建了一个 smart 类型的业务 VLAN，然后紧接着执行vlan attrib 4000 q-in-q。

MA5680T(config)#vlan 4000 smart MA5680T(config)#vlan attrib 4000 q-in-q

logical 解释：第一行创建 VLAN 4000，类型为 smart——smart 类型表示这个 VLAN 可以跨多个端口透传，不绑定具体物理端口属性。第二行给 VLAN 4000 打上 QinQ 属性，意味着从 ONU 上来的报文进入 OLT 后，会在这个 VLAN 外层再封装一层 802.1Q 标签。

参数说明里最关键的是q-in-q这个属性。在 GPON 场景下，ONU 下挂的每个用户端口需要区分不同业务或不同用户，但 OLT 上只用一个业务 VLAN 承载，这时就用外层 VLAN 4000 做通道标识，内层 VLAN 保留用户原始标签。常见做法是内层 VLAN 透传用户的业务区分，外层 VLAN 只负责从 ONU 到 OLT 再到上层交换机的物理通道。这样做的直接好处是：OLT 上行口只需要透传一个 VLAN 4000，上层设备不用为每个用户单独配 VLAN，VLAN 资源占用大幅下降。

很多新手在这里会纠结：既然已经有 VLAN 4000 了，为什么还要vlan attrib 4000 q-in-q？其实不加这行，ONU 上来的带 tag 报文在 OLT 上只会被当作普通 VLAN 处理，内层标签会被剥掉或直接丢弃，业务就断了。这行命令是给业务 VLAN 开「嵌套通道」的开关。

执行完这两条命令后，再把 VLAN 4000 透传到上行口：

MA5680T(config)#port vlan 4000 0/19 0

这里的0/19 0是框/槽/端口的完整编号——0 框 19 槽 0 口，也就是 OLT 的上联口。这条命令的作用是把 VLAN 4000 放行到这个物理端口上，让带 QinQ 标签的报文能往上送。

2.2 管理 VLAN 和管理地址：私网互通是第一优先级

业务通道之前，管理通道必须先通。脚本里单独建了 VLAN 100 作为管理 VLAN，同样透传到上行口：

MA5680T(config)#vlan 100 smart MA5680T(config)#port vlan 100 0/19 0 MA5680T(config)#interface vlanif 100 MA5680T(config-if-vlanif100)#ip address 192.168.1.1 255.255.255.0

这里我特别想强调的是vlanif 100这个逻辑接口。VLAN 100 是三层的管理网段，OLT 通过interface vlanif 100进入三层接口配置模式，配了192.168.1.1/24这个私网地址。这个地址就是 OLT 在管理网络里的网关，ONU 的管理 IP 必须和它同网段才能互通。

管理 VLAN 和业务 VLAN 分开配的用意很明确：业务流量再大、再乱，管理通道始终独立，不会互相挤占。实际开局时我见过有人图省事，把管理地址直接放在业务 VLAN 里，结果 ONU 上线后被业务广播报文冲得频繁掉线，属于典型的省一步、坑一路。

管理 VLAN 规划时还要注意网段别和其他网元冲突。192.168.1.1/24是常见的私网段，如果机房已经有设备占用了同一网段，必须换地址后再执行。这个判断要在敲命令之前完成，因为后面 ONU 管理地址是一个个发下去的，中途改网段就要全部重配。

3. ONU 注册与管理通道：sn-auth 绑定和 ipconfig 下发的三个关键点

VLAN 通道建好后，下一步就是让 ONU 上线。GPON 里 ONU 上线分两阶段：先注册——让 OLT 认识它；再下发管理配置——让 OLT 能管它。这两个阶段对应两组命令，任何一组出问题，ONU 都起不来。

3.1 发现未注册 ONU：autofind 输出的三个信息

配置 ONU 之前，先看哪些 ONU 已经物理接入但没有注册：

MA5680T(config)#display ont autofind all ------------------------------------------------------------------------ Number F/S/P SN Password ------------------------------------------------------------------------ 1 0/ 1/ 0 4857544368F933040000000000 ------------------------------------------------------------------------

这条命令列出所有被发现但未注册的 ONU。输出里最关键的是 F/S/P 列——0/1/0表示这个 ONU 在 0 框 1 槽 0 号 PON 口下；SN 则是 ONU 的光模块序列号，4857544368F93304是有效部分，后面补零的是填充位。

注意这里的 SN 是 16 字节的完整序列号，后面注册命令里只需要前 12 位十六进制字符。每次开局我都会先把 autofind 结果截图保存，因为紧接着的ont add命令必须精确匹配这个 SN，抄错一位 ONU 就注册不上，而抄错的原因往往是 SN 里 0 和 O、8 和 B 没分清。

3.2 ONU 注册和管理地址下发：ont add 与 ipconfig 的依赖关系

找到未注册的 ONU 后，进入 PON 口执行注册命令：

MA5680T(config)#interface gpon 0/1 MA5680T(config-if-gpon-0/1)#ont add 0 0 sn-auth "4857544368F93304" snmp ont-lineprofile-id 10 desc "MA5626-1"

这条命令的完整理解方式是这样的：ont add后面的两个数字，第一个0是 PON 口下的 ONU 序号，第二个0也是 ONU 序号——这里其实是「0 号 PON 口下的 0 号 ONU」。sn-auth指定认证方式为 SN 认证，后面引号里的就是前面 autofind 查到的序列号。snmp ont-lineprofile-id 10是绑定一个 ID 为 10 的 ONT 线路模板，这个模板里预定义了上下行带宽、DBA 类型等参数。desc是备注名，建议写成「站点名-设备型号-序号」这种可读格式，后面批量管理时靠这个备注认设备。

注册之后紧接着下发管理地址：

MA5680T(config-if-gpon-0/1)#ont ipconfig 0 0 static ip-address 192.168.1.100 mask 255.255.255.0 vlan 100 priority 3

这条命令把管理 IP192.168.1.100配到刚才注册的 0 号 ONU 上，管理 VLAN 是 100，报文优先级是 3。它和ont add的关系是严格的前后依赖：ONU 没有注册成功，ipconfig 命令会直接报错；反过来，ONU 注册了但没下发 IP，OLT 就无法 telnet 进 ONU 做后续配置。

下发管理地址这一步经常有个疑问：既然 OLT 已经给 ONU 配了管理 IP，为什么还要再下发 SNMP 模板？因为 IP 只是通了网络层，网管系统还需要通过 SNMP 协议去读 ONU 的状态、下发告警上报策略。下面这条命令就是把网管模板绑定到 ONU 上：

MA5680T(config-if-gpon-0/1)#ont snmp-profile 0 0 profile-id 1

profile-id 1引用的是 N2000 网管系统的预定义模板，这个模板里包含读团体字、写团体字、Trap 上报地址等参数。实际环境中 profile-id 的编号要看网管侧的规划，开局前要先确认这个模板在 OLT 上已经创建好了，否则命令能敲进去，但网管上看不到 ONU。

3.3 注册状态验证：Match SR 和 active 的判定逻辑

配置完成后，退出 PON 口模式，检查 ONU 的注册状态：

MA5680T(config)#display board 0/1 ------------------------------------------------------------------------------ F/S/P ONT-ID SN Control Run Config Match DBAflag state state state type ------------------------------------------------------------------------------ 0/ 1/0 0 4857544368EE7704 active up normal matchSR 0/ 1/0 1 4857544368F4BB04 active up normal matchSR ------------------------------------------------------------------------------

这张表要看四列：Control state 为 active 表示 ONU 已被管理并处于激活状态；Run state 为 up 表示 ONU 在线；Config state 为 normal 表示配置下发成功；Match type 为 matchSR 表示 SN 认证匹配，如果这里显示的不是 matchSR，说明认证方式和 SN 记录不一致。

有一个细节值得注意——上面显示了两个 ONU，但前面 autofind 只找到一个。这说明第二个 ONU 是之前已经注册过的。判断一个 ONU 是新接入还是旧设备，看 Control state 和 autofind 列表就能区分：autofind 列出来但 display board 里没有，才是真正待注册的新 ONU。

注册阶段最常见的翻车点是把 SN 里的前导字符弄错，尤其是以4857开头的一串——这是华为设备的固定厂商标识，后面才是设备唯一序列号。ont add命令只取前 12 位十六进制字符，但 autofind 显示的是完整 16 字节，复制时要么手工截取，要么写脚本做字符串截取。我见过有人直接把 16 字节整串粘进sn-auth，设备报 SN 长度错误，卡了半小时才发现。

4. service-port 双通道绑定：gemport 选错，业务通但管理断

GPON 里 ONU 注册成功不等于业务通了。OLT 和 ONU 之间还要建立 service-port 通道，这道工序决定了管理报文和业务报文各自走哪条路。脚本里同时配了两条 service-port，一条管理通道、一条业务通道，两条命令看起来结构相似，但参数含义完全不同。

4.1 管理通道和业务通道的差异：user-vlan other-all 的语义

MA5680T(config)#service-port vlan 100 gpon 0/1/0 ont 0 gemport 2 multi-service user-vlan 100 rx-cttr 6 tx-cttr 6 MA5680T(config)#service-port vlan 4000 gpon 0/1/0 ont 0 gemport 0 multi-service user-vlan other-all rx-cttr 6 tx-cttr 6

先看第一条——管理通道。service-port vlan 100表示这条通道承载的是 VLAN 100，gpon 0/1/0是物理位置，ont 0是 0 号 ONU，gemport 2是 GEM 端口编号。GPON 技术里，GEM Port 是承载业务的逻辑通道，一个 ONU 可以建立多个 GEM Port，分别承载不同类型流量。这里管理报文走 GEM Port 2，对应user-vlan 100——只有 VLAN 100 的报文会进入这条通道。

再看第二条——业务通道。service-port vlan 4000指定外层 VLAN 是 4000，但user-vlan other-all的含义是：除了管理 VLAN 100 之外的所有其他 VLAN 报文都走这条通道。这相当于一个 trunk 端口放行了所有业务 VLAN，只是它们都被外层 VLAN 4000 的 QinQ 标签包着上行。

MA5680T(config)#display service-port port 0/1/0 ont 0 --------------------------------------------------------------------------- 0 100 common gpon 0/1/0 ont 0 gemport 2 vlan 100 6 6 up 1 4000 QinQ gpon 0/1/0 ont 0 gemport 0 vlan other-all 6 6 up ---------------------------------------------------------------------------

display 输出里能看到两条 service-port 的状态都是 up。值得关注的是第一条的管理通道类型是 common，第二条业务通道类型是 QinQ——这个区别正好对应 VLAN 配置阶段对 VLAN 100 和 VLAN 4000 的不同属性设定。如果 VLAN 4000 在配置阶段没有打 q-in-q 属性，这里第二条通道就建不起来，display 里会出现 down 状态。

4.2 gemport 分配原则和 rx-cttr/tx-cttr 的带宽含义

gemport 的分配是有讲究的。脚本里管理通道用 gemport 2，业务通道用 gemport 0，剩下 gemport 1 可以留给将来的专线业务或 VoIP。这是常见做法，不是固定标准，但原则是：管理通道和业务通道必须分开，不能共用同一个 gemport，否则业务流量异常时会把管理通道也堵死，OLT 彻底失去对 ONU 的管控。

rx-cttr 6 tx-cttr 6里的 cttr 是 traffic contract 的缩写，两个参数分别定义上下行带宽模板编号。这里的 6 号模板是预先在 OLT 上定义好的带宽配置，通常对应一个固定的带宽上限。实际项目里，带宽模板要根据用户套餐来定——普通宽带业务可能用的是 4 号或 5 号模板，专线用户可能单独建模板。敲命令前必须先确认模板存在，不然命令会报错；就算命令通过了，display 时也可能出现带宽参数不匹配。

管理通道的带宽模板可以配小一点，因为管理报文就那么点；业务通道的模板要看用户实际带宽需求。脚本里两条通道都用了同一个 6 号模板，这在测试环境没问题，生产环境建议管理通道和业务通道分开用不同模板，避免业务侧带宽占满后影响管理通道。

4.3 配置顺序：先建 VLAN 通道，再绑 service-port

service-port 配置有一个强制性的先后逻辑：必须先有 VLAN，再有 PON 口下的 ONU 注册记录，才能执行 service-port。如果 ONU 还没注册成功就敲 service-port，系统会报 ONU 不存在；如果 VLAN 4000 还没创建就敲第二条命令，系统会报 VLAN 不存在。

这个顺序在脚本里本来是对的，但实际开局时经常有人跳过注册步骤直接配 service-port，回头才发现 ONU 根本没上线。所以每次配完我都习惯用一条display service-port port 0/1/0 ont 0检查通道状态——只要看到 up，说明前面 VLAN、ONU 注册、通道绑定这条链路是通的。

配完 service-port 后还有最后两步收尾：display current-configuration查看全部配置，确认没有遗漏或误配；然后执行save保存。这一步是后悔药——GPON 设备配错是常态，不改了就保存可以，但改完不保存、设备一重启全丢，那才是真的白干。

5. ONU 侧配置：MA5626 的 VLAN 批量创建与端口映射

OLT 侧配置完成后，还需要进入 ONU 内部做业务配置。MA5626 作为 ONU 设备，通过 OLT 的 telnet 跳转登录，完成业务 VLAN 的创建和以太网端口到业务 VLAN 的映射。这个阶段的配置逻辑和 OLT 侧有相似之处，但粒度更细——每个物理用户端口对应一个单独的 VLAN。

5.1 从 OLT 跳转 telnet 到 ONU：管理地址即登录通道

ONU 侧配置的第一步是通过 OLT 跳转：

MA5680T(config)#telnet 192.168.1.100 Connected to 192.168.1.100 ... >>User name:root >>User password: mduadmin

这个操作的核心依赖是：上一步在 OLT 上通过ont ipconfig给 ONU 下发了192.168.1.100的管理地址，OLT 和 ONU 处于同一管理网段，telnet 才能通。这里有个很容易被忽略的点——ONU 侧的管理账号密码和 OLT 侧不一样，OLT 是 root/admin，ONU 是 root/mduadmin。开局前先确认这两个账号的权限范围，别在交互式登录时卡住。

登录后依次执行 enable、config 进入全局配置模式。ONU 的命令风格和 OLT 是一脉相承的，上手没有额外成本。

5.2 批量创建业务 VLAN：vlan 1000-1015 smart y 的语法细节

MA5626 上创建业务 VLAN 的命令是一条区间批量命令：

MA5626(config)#vlan 1000-1015 smart y MA5626(config)#port vlan 1000-1015 0/0 1 y

这条命令一次性创建 VLAN 1000 到 1015 共 16 个 VLAN，类型为 smart。末尾的y表示对命令确认提示自动应答——批量创建 VLAN 时系统会逐个确认，加y参数可以跳过交互。

第二行命令把 VLAN 1000-1015 透传到0/0 1口——这是 ONU 的上行口，也就是连接 OLT 的 PON 口。注意这里的端口编号格式和 OLT 不一样：OLT 是0/19 0，ONU 是0/0 1，含义是 0 框 0 槽 1 号口，这个口在 MA5626 上是上行口。

批量 VLAN 里的编号规划要留出余地。脚本里用了 1000-1015，对应 16 个以太网口，如果设备有 24 口，就要改成 1000-1023。编号段最好和自然网段对应——用户订购的宽带业务 VLAN 是多少，就映射到哪个编号段，别让 VLAN 编号和业务毫无关联，否则后期维护就是一场灾难。

5.3 业务通道映射：一个端口一个 VLAN 的批量规律

VLAN 创建后，逐个给每个以太网口绑定业务通道：

MA5626(config)#service-port vlan 1000 eth 0/1/1 multi-service user-vlan untagged rx-cttr 6 tx-cttr 6 MA5626(config)#service-port vlan 1001 eth 0/1/2 multi-service user-vlan untagged rx-cttr 6 tx-cttr 6 MA5626(config)#service-port vlan 1002 eth 0/1/3 multi-service user-vlan untagged rx-cttr 6 tx-cttr 6

这里的规律是：业务 VLAN 1000 绑定以太网口 0/1/1，VLAN 1001 绑定 0/1/2，VLAN 1002 绑定 0/1/3，以此类推。user-vlan untagged表示用户侧报文不带 VLAN 标签，ONU 在入口处给报文打上对应该端口的 VLAN ID，然后向上送到 OLT。

端口和 VLAN 的映射可以整理成一张对照表：

每个端口的 service-port 命令结构完全一样，只是 VLAN 和端口号递增。这意味着可以写一个循环批处理来生成这 16 条命令——批命令模板在脚本末尾附了，后面单独展开说明。

Onu 侧配置完成后，两条验证命令：

MA5626(config)#display board 0 MA5626(config)#display board 0/1

display board 0查看主控板状态，display board 0/1查看业务板状态。输出里的 Status 列显示 Active_normal 表示业务板正常，Online/Offline 列显示在线状态。执行save保存 ONU 配置。ONU 的保存和 OLT 一样关键——MA5626 配置不保存，重启后 VLAN 和 service-port 全丢，需要重新配置。

5.4 ONU 配置和 OLT 配置的联动关系

ONU 侧 VLAN 1000-1015 和 OLT 侧 VLAN 4000 之间的关系，值得特别说明。ONU 侧是给用户端口打 VLAN 标签——每个端口一个 VLAN；OLT 侧是给这些 VLAN 打外层 QinQ 标签——把 VLAN 1000-1015 统一封装进 VLAN 4000 上行。这个两层标签的设计，就是 GPON 网络中「用户隔离」和「通道复用」的结合点。

如果 ONU 侧的 VLAN 编号和 OLT 侧的内层 VLAN 规划没对齐，报文进入 OLT 时会因为内层标签不匹配而丢包或错乱。常见做法是：ONU 侧的 VLAN 段由接入网统一规划，OLT 侧只关心外层 VLAN 和 QinQ 属性，两侧各管一层，互不干扰。

ONU 侧配置还有一个隐蔽的坑——port vlan 1000-1015 0/0 1 y里的端口必须是上行口，不能随手填成用户口。如果填错，VLAN 透传不出去，OLT 上怎么调都收不到业务报文。判断上行口的方法是看 ONU 的物理连接——接到 OLT PON 口的那个口就是上行口，MA5626 一般固定是 0/0/1 或 0/0/0，开局前先display board 0确认槽位状态。

6. 常见问题与排查：五个必踩的坑和验证路径

GPON 配置里有几个高频踩坑点，每个都对应明确的现象、原因和解决方式。把这些坑记下来，开局时能省掉大量排查时间。

6.1 ONU 注册后状态 abnormal：SN 认证失败的典型表现

现象：ont add命令执行成功，但display board 0/1里 Control state 不是 active，而是 abnormal 或 initial。

原因：大概率是 SN 认证信息和 OLT 上保存的授权记录不一致。GPON 的 SN 认证是严格匹配的，ont add命令里的 SN 和 ONU 光模块实际序列号必须完全一致，差一个字符都不行。

解决：用display ont autofind all重新查看实际 SN，和ont add命令里的 SN 逐字符比对。常见错误是手工录入时把0和O、B和8混淆，建议直接复制粘贴而不是手敲。如果确认 SN 无误，检查是不是同一 PON 口下已经有过一个相同 SN 的 ONU 注册记录，先删除旧记录再重新注册。

6.2 Match type 不是 matchSR：认证方式错误

现象：ONU 能正常上线，但display board 0/1里 Match 列显示的不是 matchSR，或者干脆是空白。

原因：ont add命令里用了sn-auth，但 OLT 上该 PON 口预配置了其他认证方式，比如 password-auth 或混合认证。ONU 注册时 OLT 会按照预配置的认证方式去匹配，认证方式不一致就匹配不上。

解决：确认该 PON 口的认证模式是 SN 认证。在 GPON 口模式下执行display ont register-info查看当前认证方式配置，如果不对，删除该 ONU 后重新用sn-auth添加。注意删除 ONU 用ont delete，会同时删除该 ONU 下的所有配置，操作前要确认没有在用业务。

6.3 管理 VLAN 通了但业务 VLAN 不通：service-port 的 user-vlan other-all 理解偏差

现象：OLT 能 telnet 进 ONU，管理报文正常，但用户宽带业务拨号不上或不通过。

原因：service-port 业务通道里user-vlan other-all的含义被误读成了「所有 VLAN 都不处理」，导致业务通道没建立或只放行了部分 VLAN。另外检查 ONU 侧是否已创建对应的业务 VLAN——有些情况下，ONU 的 VLAN 没建，service-port 命令就执行不了，或者执行了也不生效。

解决：在 OLT 上执行display service-port port 0/1/0 ont 0，确认第二条记录的 VLAN 是 other-all 且状态为 up。再到 ONU 上执行display vlan 1000确认内部 VLAN 已创建并透传到上行口。同时检查 ONU 侧port vlan 1000-1015 0/0 1 y的端口编号是否正确——填错上行口会导致 VLAN 无法从 PON 口送出去。

6.4 批量命令跳错号：批命令模板里 %d 的错位

现象：用批命令脚本批量配置 ONU 时，部分 ONU 的 IP 地址、VLAN 编号和预期不一致，出现跳号、重号。

原因：批命令模板里多个%d参数是独立填充的，但脚本在循环展开时，ONU 序号、IP 地址末位、VLAN 编号没有用同一个循环变量，导致错位。比如 ONU 序号为 0 时 IP 是 .100，序号为 1 时 IP 变成了 .102，中间跳了一个。

解决：写批量脚本时，所有随 ONU 变化的参数必须由同一个循环变量派生。脚本里 ONU 的 IP 地址若为192.168.1.%d，则%d的取值从 100 开始，每增加一个 ONU 递增 1。拉通检查时，用display ont info逐个核对 ONU 的管理 IP 和 desc 字段，确认一一对应。

6.5 配置保存不生效：save 后重启配置丢失

现象：配置完成后一切正常，但设备断电重启后 ONU 掉线，OLT 上配置全部丢失。

原因：CLI 下的save只保存当前生效配置到配置文件中，如果保存前有未保存的命令或保存时设备正处于繁忙状态，配置可能没有完整落盘。另外 OLT 和 ONU 需要分别执行save——只保存了 OLT 配置，ONU 配置在重启后同样丢失。

解决：OLT 和 ONU 上分别执行save，执行后通过display saved-configuration对比当前配置和已保存配置。确认无误后做一次设备重启验证，这是最稳妥的做法。生产环境开局时，我一般会在所有配置完成后强制做一轮「保存→重启→验证」的闭环，虽然多花几分钟，但能杜绝后续批量故障。

7. 批量开局提速：把命令模板改造成循环脚本

单个 ONU 的配置流程走通之后，接下来的问题是：如果 32 个 ONU 要同时上线，逐条敲命令要敲到什么时候？脚本末尾附带的批命令模板就是为了解决这个问题。这里把模板展开讲透，并给出一个可落地的改造方法。

OLT 侧的批量命令模板：

ont add 0 %d sn-auth "48575443F5266F02" snmp ont-lineprofile-id 10 desc "MA5626-%d" ont ipconfig 0 %d static ip-address 192.168.1.%d mask 255.255.255.0 vlan 100 priority 3 gateway 192.168.1.1 service-port vlan 100 gpon 0/1/0 ont %d gemport 2 multi-service user-vlan 100 rx-cttr 6 tx-cttr 6 service-port vlan 4000 gpon 0/1/0 ont %d gemport 0 multi-service user-vlan other-all rx-cttr 6 tx-cttr 6

ONU 侧的批量命令模板：

service-port vlan %d eth 0/1/%d multi-service user-vlan untagged rx-cttr 6 tx-cttr 6

这两个模板里的%d是占位符，需要用一个脚本生成实际命令。以常见的 bash 环境为例，OLT 侧的命令可以这样生成：

for i in $(seq 0 31) do ip=$((100 + i)) echo "ont add 0 $i sn-auth \"48575443F5266F02\" snmp ont-lineprofile-id 10 desc \"MA5626-$i\"" echo "ont ipconfig 0 $i static ip-address 192.168.1.$ip mask 255.255.255.0 vlan 100 priority 3 gateway 192.168.1.1" echo "service-port vlan 100 gpon 0/1/0 ont $i gemport 2 multi-service user-vlan 100 rx-cttr 6 tx-cttr 6" echo "service-port vlan 4000 gpon 0/1/0 ont $i gemport 0 multi-service user-vlan other-all rx-cttr 6 tx-cttr 6" done

这个循环里的关键点在于：循环变量i同时驱动 ONU 序号、IP 地址末位和 desc 序号，保证三者的对应关系不会错位。IP 从 100 开始递增，是因为 192.168.1.1 已经被 OLT 的 vlanif 100 占用了，ONU 的管理地址从 .100 起跳是为后续扩容留出空间。执行生成脚本后，把输出的命令粘贴到 OLT 终端即可，每行命令之间不需要额外处理，OLT 的 CLI 会自动逐条执行。

ONU 侧的批量生成逻辑类似，需要特别注意端口号从 1 开始，和 VLAN 号相差 1000：

for i in $(seq 1 16) do vlan=$((999 + i)) echo "service-port vlan $vlan eth 0/1/$i multi-service user-vlan untagged rx-cttr 6 tx-cttr 6" done

这段脚本的对应关系是：i=1时生成service-port vlan 1000 eth 0/1/1，i=16时生成service-port vlan 1015 eth 0/1/16，完全对齐前面 5.3 节的端口映射表。

用批量脚本时有一个强制习惯：生成命令后先人工抽查几条，确认 IP 段、VLAN 段、端口号三段不串位，再粘到设备上执行。执行完后一定要用display service-port做一次全量核查——批量配置最容易出「大部分对、个别错」的情况，全部依赖命令输出确认，不靠肉眼判断。

从那以后，我每次 GPON 开局都会强制走一遍「VLAN 通道 → 单 ONU 全流程验证 → 批量脚本生成 → 全量 display 核对 → 双侧 save」这套流程，哪怕只有两台 ONU 也照样执行。批量模板的价值不是省那几分钟敲命令的时间，而是把重复性操作从「手工逐条输」变成「脚本生成 + 命令输出核对」，少掉一个坑，开局就顺一大截。希望这份脚本的拆解和踩坑复盘能帮到你——GPON 这活儿，看着是命令，拼的是细心。

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