简介：面向电信网络运维与规划人员，这份PDF是Calix官方课程《实现E7-2 AXOS everyPON数据服务》的讲义，系统讲解基于E7-2 AXOS平台构建底层网络以提供二层无源光网络数据服务的完整流程，涵盖硬件结构、订阅用户与ONT管理、VLAN传输服务及策略映射等核心环节。包体仅含1个PDF文件，共74KB，内容精炼，适合用于快速查阅与巩固实操要点。目前已有132人学习浏览，具备实际参考价值。通过该材料，读者可从零掌握创建订户模板、配置ONT、部署并验证数据服务的操作路径，尤其在熟悉Calix设备的环境中能直接作为培训参考或排错手册使用。对于需要提升网络服务交付效率的工程师而言，是一份颇具性价比的参考文档。

1. E7-2 AXOS everyPON 数据服务：难点不在 PON 口，而在服务模板和 VLAN 设计

做接入网的人通常有个错觉：只要 PON 口光功率正常、ONT 成功注册，数据服务就基本算通了。真到 E7-2 AXOS 平台上走一遍就会发现，everyPON 数据服务最容易翻车的地方恰恰不在 PON 口，而在服务模板和 VLAN 设计这几层——订阅者模板、VLAN 传输服务配置文件、类映射、策略映射，任何一个环节对不齐，用户端最终表现都是上不了网。Calix 这门 Implementing E7-2 AXOS everyPON Data Service 课程，核心就是把这套链路讲透并带你在真机上做通。这篇笔记按课程大纲拆成可执行的路径：先把硬件角色看清，再做 ONT 注册，然后按顺序配齐三个 profile，最后落到验证动作上。适合第一次在 E7-2 上交付二层数据业务的网规、运维和测试工程师。

2. E7-2 AXOS everyPON 网络基础设施：先把硬件角色和二层路径对清楚

2.1 E7-2 硬件构成：机框、业务板卡与上联口的角色分工

E7-2 是 Calix 的中大型机框式 OLT，运行的是 AXOS 操作系统。机框里主要分成三类角色：主控与交换模块、PON 业务板卡、上联模块。主控负责控制平面和系统管理，业务板卡负责把光口下行到用户侧，上联模块负责把业务往汇聚交换机或 BRAS 方向送。三者缺一不可，但日常运维里最容易忽略的是主控与业务板之间的带宽关系——多块 PON 板同时跑满时，上联口和背板交换能力才是真正的瓶颈。

在 everyPON 数据服务场景里，各硬件角色承担的工作可以参考这张表：

一个常见的误区是：把 PON 板当成全部，上联口只是随便插一根线。实际上 everyPON 数据服务的 VLAN 终结和转发都在上联口附近完成，上联口允许哪些 VLAN、链路是 trunk 还是 access，直接决定业务能不能走出去。

2.2 everyPON 的含义：一种平台承载多种无源光网络

everyPON 这个名字的意思是，在同一个 AXOS 平台上，GPON、XGS-PON 甚至不同速率等级的 ONT 可以由同一套业务模型管理。课程里讲的 everyPON 数据服务，本质上不区分你是 GPON 还是 XGS-PON——订阅者模板、ONT 管理、VLAN 服务配置的套路是通用的。

这对运维来说是个好消息，也是个坏消息。好消息是你只需要掌握一套服务配置逻辑，不用为每种 PON 技术分别学一套命令。坏消息是混插场景下，ONT 的注册方式、序列号格式、光模块类型不一样，批量创建时很容易串位。后面第 5 章会专门讲这个坑。

2.3 二层数据服务的完整链路模型

先画一条完整的数据路径：用户终端 → ONT 的 LAN 口 → ONT 光模块 → 光纤链路 → OLT 的 PON 口 → 背板交换 → OLT 上联口 → 汇聚交换机/BRAS。这条路上每个环节都有对应的配置对象，任何一个环节断掉，用户端症状都一样——获取不到地址，或者 PPPoE 拨号失败。

上行方向则反过来：BRAS 回应的帧从上联口进入 OLT，经过背板交换到 PON 口，再从光路下发到 ONT，最后从 LAN 口到用户。关键点是：OLT 在这条链路上不是一个纯透传管道，它要决定哪些帧打上哪层 VLAN 标签、按什么优先级转发、限速多少。这些决策由服务模板和 profile 承载，也就是第 3、4 章要讲的内容。

2.4 开工前的设计清单：VLAN、管理通道和带宽

动手配置之前，我一般会先花半小时把下面的表填完，而不是直接登设备敲命令。这半小时省下来的，是后面反复排查的时间。

提示：管理 VLAN 和业务 VLAN 必须分开。否则 ONT 的注册和管理报文会混在用户流量里，轻则配置混乱，重则管理通道被用户流量冲垮。

3. 管理订阅者和 ONT：模板先行，注册跟上

3.1 订阅者模板定义了什么

订阅者模板（Subscriber Template）是 everyPON 数据服务里第一个要创建的配置对象。它定义了一类 ONT 的默认行为：数据 VLAN 是什么、管理 VLAN 走哪个、默认 QoS 策略用哪套、ONT 上行业务带不带标签。课程里明确说“先创建订阅者模板，再创建订阅者和 ONT”，原因是——ONT 的很多行为参数不是每条手动敲进去的，而是注册时自动从模板继承。模板建错了，批量注册的 ONT 会全部跟着错。

这里面最关键的是 vlan-mode。它决定 ONT 上行的用户帧是打单层标签还是双层标签。大多数 FTTH 场景里，ONT 会把用户侧的无标签帧打上业务 VLAN 标签再发给 OLT，这就是 vlan-mode tag 的典型用途。如果对端设备期望接收到 untagged 帧，vlan-mode 就要改成别的模式。这个参数改错，数据链路就是通的，但 VLAN 永远对不上。

3.2 数据服务订阅者模板的创建

下面这段配置思路示例，按课程 02 章节的逻辑还原（以 AXOS CLI 语法为例，不同版本关键字略有差异，以你设备上的 help 输出为准）：

configure terminal subscriber-template DATA_SERV description "FTTH data service template" vlan-mode tag service-vlan 100 management-vlan 4000 qos-profile DEFAULT_QOS no shutdown exit

这段配置的含义：先进入 configure terminal，创建名为 DATA_SERV 的订阅者模板；description 只做备注，方便后面对照；vlan-mode tag 表示 ONT 上行业务带 VLAN 标签进入 OLT；service-vlan 100 指定数据业务默认走 VLAN 100；management-vlan 4000 指定 ONT 管理通道走 VLAN 4000；qos-profile 绑定一个默认 QoS 模板，保证没有单独做策略的 ONT 也有一套可用带宽配置。

注意一个顺序问题：qos-profile 引用的模板要提前存在。也就是说，如果设备里还没有 DEFAULT_QOS 这个策略，subscriber-template 这一行会报错。课程里把策略文件放在数据服务章节讲，实际建模板时我会先把 QoS 模板建好，再回头建 subscriber-template，省一次反复。

3.3 创建订阅者和 ONT 的注册动作

模板建好之后，开始创建订阅者和 ONT。ONT 的注册依赖序列号绑定。常见做法是先在 PON 口上做自动发现，让 OLT 上报出线缆另一端 ONT 的序列号，核对之后再手动绑定。下面是一个绑定示意：

configure terminal interface gpon 1/1/1 onu 1 serial-number ALCLF01234567 onu 1 subscriber-template DATA_SERV no shutdown exit

这里 interface gpon 1/1/1 进入 PON 口，onu 1 是在这个 PON 口下创建第一个 ONT，serial-number 绑定光猫序列号。注意序列号是 OLT 识别 ONT 的唯一凭据，录入错误或者大小写不对，ONT 就一直是 offline。一个 PON 口下面通常可以挂多个 ONT，每个 ONT 的编号要唯一。

绑定 subscriber-template 那行很关键，它决定了 ONT 上线后自动继承哪些默认参数。如果模板还没建好就先绑 ONT，绑定会失败；反过来，模板建好了但没绑，ONT 虽然能注册，但数据业务会因为没有服务配置而完全不转发。

这个环节最容易出的问题不是命令敲错，而是批量操作时序列号错位。我一般会用自动化工具从自动发现结果里直接把序列号导出来生成配置，同时运行 show 命令逐条核对，也就是第 5 章会讲的 ONT 三查。

3.4 验证 ONT 注册状态

ONT 配置完成之后，课程要求验证功能。验证分两步：第一步确认 ONT 注册成功，第二步确认光功率和误码率正常。注册状态检查常见做法是执行 show ont 相关命令，看 ONT 的管理状态是否从 discovering 变成 active；光功率看接收端光衰是否在 ONT 模块的接受范围里。

这一步不能只看 ONT 是否 active。实践中出现过 ONT 状态 active 但光功率已经踩在灵敏度边缘的情况，白天能用，晚上温度一降就掉线。所以我的习惯是：在验证记录里同时写光功率数值和预留余量，而不是只勾一个“已注册”。

提示：ONT 注册不成功时，先查序列号，再查光功率，最后查 PON 口是否 shutdown。顺序别反，序列号问题最容易定位，别一上来就动光路。

4. 数据服务三层配置：VLAN 传输、类映射与策略映射怎么配合

4.1 数据服务 VLAN 传输服务配置文件

VLAN 传输服务配置文件（VLAN Transport Service Profile）解决的是：业务 VLAN 在 OLT 上怎么被处理。它有三种常见模式——透传（transparent）、转换（translate）、终结（terminate）。透传是 VLAN 原封不动穿过 OLT，适合上游设备能直接识别该 VLAN 的场景；转换是把一个 VLAN ID 换成另一个再送出去，适合用户侧 VLAN 和局端 VLAN 规划不一致的场景；终结则是在 OLT 上直接终结二层，一般用于需要 OLT 参与三层处理的场景。

配置示意（以 AXOS CLI 为例）：

configure terminal vlan-transport-profile DATA_VLAN vlan 100 transparent vlan 200 translate 300 exit

这段配置里，vlan-transport-profile 创建传输服务配置文件，VLAN 100 使用 transparent，意思是 VLAN 100 进出 OLT 时标签不变；VLAN 200 使用 translate 300，意思是入方向命中 VLAN 200 的帧，出方向会被改写成 VLAN 300。选择哪种模式，取决于你上游交换机或 BRAS 的 VLAN 规划。如果上游和用户侧 VLAN 一致，优先用 transparent，少一层转换就少一个故障点。

4.2 Ethernet 类映射配置文件

有了 VLAN 传输规则，接下来要回答一个问题：PON 口下混着大量用户的流量，OLT 怎么区分哪些帧走哪套规则？答案是 Ethernet 类映射配置文件（Ethernet Class Map Profile）。它做的是匹配分类——按 VLAN ID、802.1p 优先级、MAC 地址等字段，把流量分成不同类别。

配置示意：

configure terminal class-map match-any DATA_CLASS match vlan 100 match vlan 200 match priority 3 exit

这段配置的含义是：创建一个名为 DATA_CLASS 的类映射，match-any 表示命中任意一条就算匹配。match vlan 100 和 200 把两个业务 VLAN 归为一类，match priority 3 把优先级为 3 的帧也归进来。实际部署中，我通常只按 VLAN 分类，优先级匹配尽量不用——因为 ONT 打上来的优先级标签经常不标准，按优先级分类容易把不该归类的流量卷进来。

4.3 策略映射配置文件

类映射只做分类，真正执行动作的是策略映射配置文件（Policy Map Profile）。它把前面分好的流量类别绑上带宽、优先级和转发行为。带宽参数里最重要的两个是 CIR 和 EIR：CIR 是承诺带宽，必须保证；EIR 是超出承诺后的尽力转发带宽。

配置示意：

configure terminal policy-map DATA_POLICY class DATA_CLASS bandwidth downstream cir 50Mbps eir 20Mbps bandwidth upstream cir 10Mbps eir 10Mbps set priority 3 class-default bandwidth downstream cir 1Mbps

这里 policy-map 创建策略映射，对 DATA_CLASS 这一类流量做双向带宽限制。downstream 是 OLT 到用户方向，CIR 50Mbps 保证基本带宽，EIR 20Mbps 允许临时突发；upstream 是用户到 OLT 方向，CIR 和 EIR 都是 10Mbps。set priority 3 给这类流量标记优先级。最后 class-default 是保底策略，给未匹配流量留 1Mbps，避免零带宽把管理流量也饿死。

4.4 在 ONT 上绑定并验证数据服务

三个 profile 各自建好之后，最后一步是把它们组合起来绑定到 ONT 的 LAN 口上。这个动作在课程 03 章节是压轴步骤，绑定成功并验证通过，数据业务才算真正交付。配置示意如下：

configure terminal interface ont 1/1/1/1 lan 1 service-profile DATA_SERV vlan-transport-profile DATA_VLAN class-map DATA_CLASS policy-map DATA_POLICY exit exit

这段配置把前面建的模板和 profile 全部挂到 ONT 的第一个 LAN 口下。service-profile 决定基础业务参数，vlan-transport-profile 决定 VLAN 行为，class-map 和 policy-map 决定分类与策略。绑定完成后，用户终端接 ONT 的 LAN 口，应该能从上层 DHCP 服务器获取到 IP 地址，或者完成 PPPoE 拨号。

验证这一步，我建议按这个顺序做：先看 ONT 还是不是 active，再看用户终端能不能获取 IP，最后用持续 ping 检验带宽和丢包。如果获取不到 IP，先查 VLAN 传输配置和上联口允许的 VLAN 列表。这中间最容易忽略的是上联口那侧——你 OLT 配好了 VLAN 100，上联交换机却不允许 VLAN 100 通过，业务依然出不去。

5. 避坑记录：五个最常见的 everyPON 数据服务故障与处理

下面是按课程覆盖面加实际交付经验整理的五个高频故障，每一条都是真实处理过的场景。现象描述按用户侧能感知到的状态来写，方便你对照判断。

5.1 现象一：ONT 一直 offline，但光模块明明收到光

很多人第一次碰到会下意识怀疑光路，拿着光功率计来回测，结果光衰减正常，ONT 的电源灯也亮，但 OLT 侧就是显示 offline。原因是三个：序列号绑定错了、序列号大小写有差异、PON 口的技术制式和 ONT 不匹配。比如把 GPON ONT 绑到 XGS-PON 口，或者把 XGS-PON ONT 绑到 GPON 口，都会表现为 offline。

解决方法是先执行自动发现，让 OLT 自己报告出对端 ONT 的序列号，然后复制粘贴到绑定配置里，不要手工敲。序列号尽量保持大写，不同厂商的序列号格式不同，Calix 的 ONT 序列号通常是一串以字母开头的字符串。核对好制式——GPON 口只绑 GPON ONT，XGS-PON 口绑 XGS-PON ONT，不要混绑。

5.2 现象二：业务能通，但丢包率明显偏高

用户报障时常说“网能上，但视频卡”，一测 ping 发现丢包集中在某一时段。这时候先别查光路，去查 policy-map 的带宽参数。最常见的原因是 EIR 给得过于紧张，业务突发流量一上来就被丢弃。还有一个隐蔽原因：class-default 没有配置默认带宽，导致未匹配的流量直接进黑洞。

解决思路是重新梳理 policy-map：把 CIR 按用户套餐实打实配足，EIR 留出至少 CIR 的一半；class-default 给一个保底带宽，比如 1Mbps，避免不可识别流量被打死。改策略前先看设备上的统计计数，确认丢包是不是精确发生在匹配该 class 的接口计数上，别凭感觉调参。

5.3 现象三：VLAN 怎么配都不通，抓包发现标签和预期不一样

VLAN 不通是 everyPON 数据服务里最玄学的问题之一。现象是 ONT active、光功率正常、用户能拨号但就是获取不到地址，或者地址能拿到但业务不通。原因绝大多数出在 vlan-transport-profile 的模式选择和上游交换机 VLAN 配置不一致。比如 OLT 侧做了 translate，从 VLAN 100 改成 300，但上联口实际允许的 VLAN 列表里只有 100，没有 300，帧到上游就被丢弃。

解决方法是先生成一个完整的 VLAN 流转记录：用户侧 VLAN 是多少、OLT 入方向是多少、出方向是多少、上联交换机允许多少，四个值串起来一致了再动设备。上联口要同时检查 trunk 允许的 VLAN 列表和 native VLAN 设置，transparent 模式下业务 VLAN 必须在上联口允许列表里。

5.4 现象四：订阅者模板改了，ONT 上的业务不跟着变

这是个很隐蔽的坑。现象是你在 subscriber-template 里改了 service-vlan，保存配置后重新查看，配置已经写入，但 ONT 侧的转发行为还是旧的。原因是模板在 ONT 注册时已经实例化，模板修改不会自动热刷新到已绑定的 ONT 实例上。AXOS 对部分参数支持动态下发，但 VLAN 这类关键业务参数往往需要重新触发 ONT 服务加载。

解决方法是不要只改模板，改完后需要显式地重新应用服务，或者触发 ONT 重新注册。常见做法是在维护窗口内重启该 ONT 的 service，观察状态重新变为 active 后再验证业务。以后遇到这类问题，先查模板修改时间与 ONT 状态变化时间是否一致，时间对不上基本就是没重新加载。

5.5 现象五：混挂 GPON 和 XGS-PON 时，ONT 注册串位

E7-2 的优势是 one box 承载 everyPON，但混挂带来了一个新问题：批量创建 ONT 时，序列号很容易串到相邻的 PON 口下面去。症状是 A 用户的光猫注册到了 B 用户的 PON 口，业务互相干扰。原因通常是批量脚本生成时，PON 口编号和序列号列表没有对应上，或者复制粘贴时串行。

解决方法是做一次“ONT 三查”：查 ONT 序列号、查绑定 PON 口、查用户 LAN 口是否一致。自动发现阶段就按 PON 口逐个确认，确认一个绑一个，不要批量完再回头核。混插场景下还可以把 GPON ONT 和 XGS-PON ONT 的序列号前缀做分类，脚本里按前缀校验，一边绑一边检查，能省不少事。

注意：这五类故障有一个共同特点——OLT 侧配置检查全部正常，但用户就是感知异常。遇到这种情况，从类映射的匹配顺序开始查，再查模板是否重新加载，最后查上联口，别在光路上一遍遍地耗时间。

6. 验证技巧：用一套固定动作把数据服务交付从玄学变成流程

数据服务交付做久了会发现，真正花时间的不是配置，而是验证。我给自己定了一套固定动作，每交付一个 everyPON 数据服务就这么走一遍，总共四步，半小时内完成。

第一步是查 ONT 状态与光功率，确认 ONT active 且光功率在合理范围内。第二步是查 VLAN 链路，在 OLT 上查看 VLAN 转发表是否命中预期接口。第三步是业务测试，用户终端能拿到 IP，PPPoE 能拨上号。第四步是持续 ping 五分钟，观察丢包和时延是否在阈值内。四步都过，才敢让业务正式交付。

抓包验证时我一般把抓包点放在上联口而不是 PON 口，因为上联口能看到最完整的 VLAN 标签形态。抓到的帧应该符合你规划的 VLAN 流转：用户侧无标签进来，ONT 打上标签，OLT 原样透传或转换后交给上游。如果抓到的标签和规划不一致，按第 5 章第三条那个排查思路逐段核对。

批量交付时，我会把前面用的 vlan-transport-profile、class-map、policy-map 存成基线片段，新用户过来直接改 VLAN ID 和带宽参数再下发。改完跑一遍上面四步。这套动作做多了以后，数据服务交付基本不会再有突发故障。从那以后我每次交付 everyPON 数据服务，都强制自己先跑完这套验证动作，再让业务上线——花不了半小时，却能省掉后面数不清的夜间故障单。希望帮到你。

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