简介华为OLT配置手册是华为官方发布的OLT设备配置指南面向负责宽带接入网络规划、部署与维护的网络管理员和工程师。资源包含1个PDF文件压缩包大小约19.24MB目录以配置模块为主线便于按场景快速定位。手册覆盖专线、VPLS、FTTx/FTTH等关键内容专线部分给出QinQ VLAN、VLAN Stacking批发业务、PWE3等配置示例VPLS部分包含上网、组播和企业专线示例FTTH部分则详述IP地址、QoS、语音、IPTV及安全等数据规划原则并针对桥接语音型ONT、桥接型ONTHGW、网关型ONT三类常见组网分别展示GPON与EPON接入下的完整流程包括OLT增加ONT、上网/语音/BTV/VoD业务配置以及聚合拥塞控制与安全策略部分场景还提供CLI、Web或网管三种操作路径便于在不同现网环境中直接参考。该手册已有9137人学习是一份适合OLT开局、业务开通和故障排查使用的案头资料。1. 华为OLT配置手册从专线到FTTx按场景复现比背命令更实用在接入侧干过几年的人都有这种体会OLT本身不难难的是每个业务场景都藏着一堆关联项。QinQ的Tag留哪一段语音放ONT还是HGW上基站回传的时钟走哪个源这些在华为OLT配置手册里被拆成几十个章节按FTTH、FTTB/FTTC、FTTO、FTTM分门别类但很少有人帮你串成一条能直接落地的链路。这本手册要解决的就是这个问题专线业务、VPLS、FTTx端到端组网、语音和组播配置全覆盖既有单功能命令示例也有端到端配置流程适合刚接手OLT维护的新人照着推演一遍也适合回来核对边界参数的老手。这篇笔记把我从手册里抽出的配置思路、CLI片段和踩坑记录整理成一条可复现的路。2. 专线业务三件套QinQ VLAN、VLAN Stacking、PWE3与VPLS怎么选2.1 QinQ VLAN专线业务外层Tag归运营商内层Tag留给用户专线业务里最常见的诉求是企业分支之间在公网上跑私网流量。QinQ VLAN的实现方式是用两层VLAN Tag内层是用户自己能看懂的原始VLAN外层由运营商统一分配用户VLAN可以随意复用只在进入OLT那一刻被套上外层Tag到对端再剥掉。对OLT来说这就是一条固定的配置链路先注册ONU、再建管理通道、然后配业务流、最后做VLAN映射手册给的单网元示例也正好是按这个顺序写的。我一般上手先看ONU侧的端口透传再看OLT侧的服务端口绑定。下面这段配置把ONU下用户原VLAN 100映射到业务VLAN 200并挂到GEM Port上# GPON ONU注册SN认证 interface gpon 0/1 ont add 0 0 sn-auth 48575443XXXXXXXX olt ont-lineprofile-id 10 ont-srvprofile-id 20 # ONU侧用户口把内层VLAN 100映射到业务VLAN 200 ont port vlan 0 0 eth 1 translation vlan 100 to vlan 200 # OLT侧创建QinQ业务流 service-port vlan 200 gpon 0/1 ont 0 gemport 1这段命令的逻辑分三段理解。ont add负责让OLT认出这台ONU其中lineprofile决定DBA模板和GEM Port通道能力srvprofile决定ONU端口工作模式ont port vlan做的是VLAN透传或Tag切换translation关键字表示把进来的100改写为200如果只写vlan 100 then vlan 100则是纯透传service-port则是把业务VLAN和物理位置绑定OLT把从用户侧进来的打上Tag 200的流量映射到gem port 1继续上行。三个配置段缺一个专线都起不来。参数上最需要小心的是lineprofile里GEM Port映射方式。透传、Tag转换、双层Tag虽然都叫mapping但命令格式不同混了之后外层Tag要么没打上、要么打了两次。QinQ专线排错时如果发现用户侧进来的包在OLT上没出现预期Tag先回这里看映射类型。另一个常见的坑是外层VLAN规划冲突同一个OLT上如果专线外层VLAN 200和上网业务用了同一个VLAN流量会被转发到两个方向这就是典型的配置都正常但业务乱串。我的习惯是给专线单独留一段VLAN比如从2000开始奇数给QinQ、偶数给VLAN Stacking排错的时候看一眼VLAN号就能判断业务类型。提示QinQ和VLAN Stacking的区别在于外层Tag的用途。QinQ侧重把私网VLAN透明地搬运Stacking侧重用外层Tag标识业务归属域选型时先问自己这个Tag是给谁看的。2.2 VLAN Stacking批发业务外层Tag标ISP内层Tag标用户VLAN Stacking和QinQ在OLT上经常被混着说实际应用场景差别很大。批发业务出现在一个二层交换城域网部署了多个ISP的场景运营商要把用户群批量送到指定ISP手里ISP再把业务下发给用户。这时外层VLAN Tag用来标识ISP内层Tag继续标识用户用户自己的VLAN规划完全不必改ISP侧仍然能拿到原来的内层VLAN。对企业来讲分支机构可以各用各的VLAN运营商只按外层Tag分流。配置上的核心动作是ONU上行口加StackingOLT再按外层VLAN建业务流。手册里VLAN Stacking批发业务示例的做法和QinQ的差异就在tag action# ONU上行口给用户流量统一加外层Tag 1000标识ISP-A ont port vlan 0 0 uplink 1 stacking vlan 1000 # OLT侧按外层VLAN 1000创建业务流转发到ISP-A service-port vlan 1000 gpon 0/1 ont 0 gemport 1参数上最关键的是外层VLAN的分配原则。给多个ISP做批发时要按ISP划分外层VLAN段每个ISP一个段段内还可以再按用户群细分。比如ISP-A占用1000到1009、ISP-B占用1010到1019这样OLT侧一条service-port命令就能把整个用户群批量挂进同一个域。内层VLAN完全不用管用户改不改内层Tag都不影响分流这正是批发业务能快速放号的底气。这个方案在排查上有个特别隐蔽的坑外层VLAN如果和城域网里已有的透传VLAN冲突用户流量会在OLT上被错误吸入其他域现象是业务时通时断。因为ONU和OLT侧配置都显示正常很容易往光路上想。我的做法是在总VLAN规划表里把批发业务外层段和普通业务段物理隔开并加注释说明归属ISP防止后来接手的人撞车。另一个容易忽略的点是如果用户自身也要做QinQONU侧就会变成三层Tag叠加实际部署前要确认ONT芯片支持三层Tag否则数据面会丢帧这在FTTx数据规划里要提前确认。2.3 PWE3与VPLS点到点和点到多点专线的配置分水岭当专线要从二层跨越到MPLS网络时就要分清楚PWE3和VPLS的边界。PWE3是把以太业务仿真成一条点到点虚拟线路适合企业两个分支互连这种需求明确、流量模型固定的场景VPLS是点到多点让多个分支像接在同一台虚拟交换机上一样互通MAC表在VSI里自动学习扩散。手册里VPLS给了三种示例上网业务、组播业务、企业专线业务选哪种取决于你让谁在VSI里跑。配置上VPLS比PWE3多一层VSI封装以企业专线为例核心是把用户的QinQ业务流绑定进VSI# 创建VSI实例PW信令走LDP vsi ce-vsi pwsignal ldp vsi-id 100 quit # 把用户的QinQ业务绑定进VSI service-instance 100 encapsulation qinq vid 1000 xconnect vsi ce-vsi两个关键参数要记牢vsi-id是整个VPLS域的全局标识两端必须一致对不上就是VSI起不来encapsulation qinq vid 1000 指定哪个外层VLAN进入VSI这里如果写成纯透传而用户实际上是QinQ封装业务流会整个丢失。PWE3则直接用PW ID在两个PE间建隧道通过LDP或静态方式协商标签命令形态比VPLS收敛。VPLS场景里最容易被忽略的是MTU问题。加入双Tag后MPLS标签栈加上以太头会让报文超过1500字节如果骨干网不启用jumbo帧大帧业务会非常规律地丢包。之前遇到一次跨城VPLS专线故障现象就是普通浏览正常、大文件传输必断最后定位到骨干MTUVLAN和PW配置都是对的。所以排这种问题第一步用1500字节以上的ping验证不要上来抓包。维度PWE3VPLS业务模型点到点点到多点VLAN映射一条PW对应一个业务流一个VSI承载多个业务流典型场景企业双分支互连多分支组网、组播、共享上网配置核心PW ID与隧道参数VSI ID与业务绑定3. FTTH端到端配置桥接、HGW和网关型ONT的选型与落地3.1 桥接语音型ONTGPON和EPON的配置流程差异点FTTH场景里桥接语音型ONT对应的是不需要内置路由的普通家庭用户ONT做二层透传语音由ONT自带的语音口承载光猫后面再接运营商或用户自备的路由器拨号。手册为这个场景分别写了GPON和EPON两套配置流程结构差异比很多新人预想的大。差异主要在认证方式和承载通道上。GPON用GEM Port承载业务ONU注册时绑定DBA模板业务流以GEM Port为粒度EPON用LLID承载OLT侧要给ONU分配管理IP和VLAN业务通道和管理通道是完全独立的二层转发。很多人第一次在EPON上做FTTH被管理VLAN带偏把业务VLAN配进了管理通道最后ONU注册成功但用户拨号永远没响应。这个坑在手册里没有单独强调但数据规划原则里实际写了管理数据和业务数据必须分开规划。# GPON先建DBA模板和GEM Port再把业务VLAN映射进去 ont lineprofile 10 tcont 1 profile tcont1 gemport 1 tcont 1 gemport 1 mapping vlan 100 # EPON管理通道和业务通道分开 interface epon 0/1 onu 0 sn-auth XXXX ont ip 0 0 vlan 300 ip-address 192.0.2.10 mask 255.255.255.0 gateway 192.0.2.1参数说明tcont profile对应不同的DBA调度模板带宽型、保障型、尽力而为型在流量模型上完全不同gemport是GPON承载业务的逻辑通道一个gemport可以承载多个VLAN但一个VLAN只能映射到一个gemportEPON的ont ip只是管理地址和业务VLAN不在一个转发域。桥接语音型ONT如果出现注册但拨不上号先看ONT的LAN口有没有被业务服务流覆盖再检查语音口的H.248或SIP网关地址是否可达别急着怀疑VLAN。3.2 桥接型ONTHGW拨号放HGWONT只做二层透传桥接型ONTHGW是家庭宽带里最常见的一种组合。ONT只管光电转换和二层透传PPPoE拨号、路由、Wi-Fi全部交给HGW好处是ONT故障换一台不影响账号数据HGW可以自由选择型号。手册对这类场景的配置流程沿用同一个骨架OLT增加ONT、配置管理通道、配置业务通道HGW侧再放上网、语音、IPTV业务。语音业务在这个场景里要确认到底由谁承载。如果语音由ONU提供ONT就要单独给语音VLAN留一条GEM Port两个LAN口分别透传上网VLAN和语音VLAN数据规划上VLAN要分段。如果语音由HGW提供ONT侧只需要放行语音VLAN透传SIP或H.248账号配置全部在HGW完成。实际维护里经常看到有人把语音账号配到ONT自带的语音口HGW侧却一直注册不上根因就是没搞清语音承载点在哪个方向。判断方法很简单ONT侧有没有配置H.248或SIP网元地址配了就表示ONU承载语音没配就表示语音必然在HGW上。下面这段配置展示了两个LAN口分开透传的写法# LAN1透传上网VLAN 100LAN2透传语音VLAN 101 ont port vlan 0 0 eth 1 translation vlan 100 to vlan 100 ont port vlan 0 0 eth 2 translation vlan 101 to vlan 101 # OLT侧两条业务流分开创建语音走优先队列 service-port vlan 100 gpon 0/1 ont 0 gemport 1 service-port vlan 101 gpon 0/1 ont 0 gemport 2需要注意的是QoS队列。语音VLAN最好独立建一条业务流并配置为EF优先级上网和IPTV共享带宽时也不会把语音链路压垮。手册在FTTH数据规划原则里反复强调QoS规划指的就是这类事后很难补救的拥塞控制策略建议在规划阶段就定好而不是等语音质差再回来打补丁。3.3 网关型ONTWi-Fi、CATV与Any Port Any Service一把抓网关型ONT把光猫、路由、Wi-Fi、语音和CATV功能集成在一台设备里FTTH里常见形态就是一台带多个LAN口、Wi-Fi天线和有线电视口的设备。手册把它单独列成一个场景给的配置项也最全上网业务、Wi-Fi接入、H.248/SIP语音、BTV、VoD、CATV还有Any Port Any ServiceAPOS。APOS是网关型ONT最有价值的一项能力ONU后面任意LAN口不再按业务固定哪个口插机顶盒就自动跑IPTV插电脑就上网。对装维人员来说少了一次端口绑定对用户来说乱插也不至于完全没网。配置这种模式的重点在ONU的端口模板把每个LAN口的模式设成Multiple-ServiceOLT侧再给该ONT配置多条业务流对应不同VLANONU自动按业务类型分流。这个场景操作大部分在ONT的web界面完成OLT侧配置反而简单给网关型ONT一个足够的DBA模板放行业务VLAN即可。CATV业务是例外它没有IP承载由OLT的CATV光模块直接送RF信号OLT侧几乎不需要配置但它对ONT的光接收功率有硬性要求功率不足会花屏、没台或者噪声大。这类故障容易被误判成IPTV配置问题因为现象都是电视看不了排查时先看ONT光功率和CATV接入状态再动VLAN。注意Any Port Any Service的配置里语音VLAN和IPTV组播VLAN不建议占用同一个QoS行为。语音走高优先级EF队列IPTV组播走AF队列两者叠加在高负载时会出现随机丢包。4. FTTB/FTTC、FTTO和FTTM从xDSL接入到基站回传的进阶场景4.1 FTTB/C的xDSL接入Vectoring和G.fast的参数边界FTTB和FTTC共用一套ONU形态ONU提供LAN口或xDSL口区别只是FTTB把设备放楼道、FTTC放路边。手册把这两个场景合并讲解配置流程一致只是xDSL场景多了DSL参数和线路模板。对机房的人来说这类ONU记住一条先确认接入类型再配业务流因为ADSL2、VDSL2、G.fast的模板参数互不通用。三种xDSL技术边界要说清楚。ADSL2适合长距离、中低速VDSL2在短距离上能跑百兆以上是FTTB/C的主流G.fast频率高、速度快但只适合几百米内的极短距离而且和普通电话线共存时要做好频段分离。Vectoring和SuperVector用来消除串扰有效的前提是所有线对必须在同一个Vectoring组里单独漏掉一对不参与整组的串扰消除效果都会退化。这在现场排障时要留意少了一根线的绑定这类问题。# VDSL2端口配置示例ONU侧 interface vdsl 0/1 line-profile 1 mode vdsl2 vectoring enable # SuperVector需要ONU和板卡都支持 super-vector enablexDSL场景最容易被忽略的是G.fast的高频特性。G.fast工作在30MHz以上如果线路上的分离器或者滤波器件老化会直接拉低协商速率这不是配置问题但表现得很像配置问题。部署时先做一遍线路质量测试再想着调模板参数。Vectoring的边界也提醒一下它是物理层技术配置后如果OLT侧板卡固件版本不一可能一整组都失效建议同一Vectoring组内的用户尽量落在同一块板卡上。4.2 大企业接入从二层互通到DDN、PBX和E1大企业接入通常走FTTO手册把SOHO/SME和大企业分成两个章节前者的核心词是Wi-Fi、语音和二层互通后者的核心词是专线企业分支二层互通、DDN专线、IP PBX、PRA PBX、E1统一接入。大企业场景和家庭业务的差别在两点一是要配端到端可靠性二是要配时钟同步后者在很多传统接入工程师手里是盲区。二层互通业务和前面QinQ专线的配置原理一样差别在于多了可靠性配置常见做法是GE上行链路聚合、双上联组网。IP PBX场景是把企业IP电话通过OLT接入上层软交换OLT和ONU之间的管理业务流、QinQ VLAN和业务流配置与普通专线一致差别在于语音流量要单独保障不能跟企业办公数据抢BE队列。PRA PBX场景更传统一些要支持透传语音业务流部分场景还支持VoIP PRA接入把TDM的PRA信号转换后走IP承载。手册里SOHO和SME部分的Wi-Fi Sharing则走了另一条路通过SoftGRE隧道或VLAN隧道把商铺Wi-Fi信号回传到平台隧道参数必须和上层平台对齐否则ONT侧配好了也建立不起会话。E1统一接入是FTTO大企业里比较硬核的业务。GPON侧用SAToP把E1封装成MPLS PWEPON侧对应CESoP同样是E1仿真但承载机制不同。这类业务里时钟是硬指标只配SAToP连接、不配时钟同步E1链路上误码会高到业务几乎不可用而且故障现象很像光缆劣化。手册给出的方案基本是四种时钟源BITS、线路时钟、以太时钟、1PPSToDTDM业务优先用BITS或者从E1上位侧提取线路时钟。4.3 FTTM基站接入时钟同步比业务VLAN更重要FTTM和前面几个章节最大的不同是ONU在这里的角色变成了基站回传单元下行接2G/3G/4G基站上行经OLT到基站控制器。基站对接入网络的第一要求不是带宽而是频率和时间同步手册在FTTM章节用了大量篇幅写时钟同步配置这在业务配置章节里是非常罕见的顺序本身说明了优先级。时钟方案的选择逻辑可以这样记E1线路上跑Native TDM或SAToP时优先用线路时钟或BITS分组交换网络上的基站回传用同步以太或1588V2需要绝对时间同步的用1PPSToD。Small Cell基站多用QinQ VLAN方式接入对时钟要求相对宽松但也建议做组网保护比如双上行或链路聚合。GPON场景里TDM PWE3对称接入是最复杂的组合OLT侧配置TDM连接和TDM PWONU侧建立对称的TDM通道两端配置必须一一对应。TDM PWE3配置里有个容易忽略的点当PW两端都接在OLT上通过MPLS网络互连两个分支机构两端的时钟源必须取自同一个BITS或者同一个上游线路两端频率不一致时滑码会直接反映在E1误码里。排除时钟问题再谈业务流是FTTM排障的铁律。另一个实践技巧是在部署阶段把时钟源、BITS缆、1588V2的端口配置都写入交付文档否则半年后设备重启时钟恢复配置经常会被漏掉导致基站批量告警。时钟方案适用业务配置要点BITSTDM、E1、全网同步从BITS时钟板引线到OLT配置主备时钟源线路时钟SAToP/CESoP从E1链路提取时钟跟随上游同步同步以太分组回传、Small Cell物理层逐跳同步依赖设备支持1588V24G基站回传时间戳协议需要配置BC/OC模式1PPSToD需绝对时间同步单独时间接口主备双路5. OLT配置避坑清单VLAN、语音、组播与时钟的现场排查5.1 ONT注册成功但业务不通先查GEM Port还是先查DBA现象ONU在OLT上显示在线光功率正常但用户拨号失败或ping不通网关。很多人第一反应是改VLAN实际上更常见的根因是GEM Port和service-port的映射没有完全建好或者DBA模板带宽配成了零。解决步骤是先在OLT上用display ont info确认实际生效的lineprofile和gemport再检查service-port是否覆盖了ONU端口。这类故障先查承载通道再查VLAN能省一半时间因为VLAN错了通常表现为完全不通而承载通道缺失往往表现为间歇性不通。display ont info 0 0 display service-port port 0/1/05.2 语音H.248注册失败网关地址和媒体端口对不上现象电话摘机没拨号音H.248注册状态一直停在idle。这类问题大部分不是SIP/H.248协议配置的问题而是ONT侧的媒体网关地址和OLT侧语音VLAN的三层网关不在同一网段ONT发出去的注册请求根本没到正确的设备。解决方法是先确认ONT的管理VLAN和语音VLAN能互通再检查SIP/H.248注册服务器地址是否填写正确。语音业务的QoS也要单独看如果语音流被默认调度进BE队列高负载时注册消息会重发超时看起来就像网关配错。5.3 IPTV组播黑屏IGMP复制方式没对上现象单播点播正常切台黑屏组播频道起不来。常见原因是OLT的组播复制模式或IGMP组播VLAN没配置和ONU侧的组播VLAN不一致。排查时先确认OLT组播VLAN和IGMP查询器在正确VLAN里再通过display igmp group查看组成员是否建立。GPON和EPON的组播复制差异要注意GPON由GEM Port复制组播流EPON按LLID和组播VLAN复制配置时要对应设备类型不能拿GPON的模板往EPON上套。5.4 TDM业务闪断时钟源不一致现象E1或TDM PWE3业务偶尔闪断误码高但状态切换不明显。根因常常是时钟源不一致或者主备时钟切换后没有通知到所有网元。解决方法是统一时钟源给OLT配置BITS或从上游线路提取时钟ONU侧的SAToP/CESoP配置也使用同一套时钟参考。排查时先用display clock source确认各设备当前时钟状态再检查时钟板卡的主备配置。如果没有独立时钟板却配置了BITS以太时钟和线路时钟之间会互相竞争。5.5 QinQ内外层VLAN对不上两端Tag规划不一致现象专线小包通、大包通但业务应用间歇性失败。原因是企业两端的内层VLAN规划不一致运营商侧又没有做映射或者外层VLAN在骨干侧被错误剥离。解决方法是确认两端内层VLAN的原始值在OLT或ONU侧统一做tag translation把两端的VLAN改写成同一值。这类故障最绕因为从OLT侧看配置一切正常问题在对端用户设备上排障时让两端把VLAN规划表摆在一起逐一核对几分钟就能定位。5.6 管理通道不通导致预部署失效区分管理VLAN和业务VLAN现象ONT能注册但网管无法纳管远程批量下发模板一直失败。原因大多是EPON场景里管理VLAN、ONT IP和网关规划冲突或GPON场景里管理通道复用了错误的GEM Port。解决方法是把管理通道独立规划管理VLAN全网统一分配ONT管理IP单独建段OLT侧单独创建一条管理业务流不和用户业务混用同一条GEM Port。最好的习惯是把管理VLAN固定成一个全局统一的数字比如3000段这样任何一台ONT上线都能被纳管工具自动识别。6. 把手册示例改成生产数据前我每次都会强制走的几道验证手册里的示例数据和操作步骤都明确标注了仅为便于理解而设计不能作为模板使用这句话很多人扫一眼就过去了实际上它才是排障知识里最贵的一句。示例里的VLAN号、IP地址、ONT命名都是为说明流程服务的直接照抄上线等于把练习卷答案写进生产答题卡。如果你刚开始读这套手册建议先翻配置导读那一节它会说明整本的写作结构再直接定位到你自己负责的接入场景。手册正文按FTTH、FTTB/FTTC、FTTO、FTTM分大章同一类ONT形态又按GPON和EPON各写一遍所以找到入口比从头通读更快。所以我形成了一套固定的验证习惯。每配完一个业务流先display service-port核对端口、VLAN、GEM Port三项一致再在用户侧做PPPoE拨测能拿到地址并正常上网才算过语音业务必须实际摘机听拨号音呼入呼出各测一次组播频道连续切换几个台等三秒看是否出图E1和TDM业务做完后先display clock source确认时钟状态再跑一遍误码测试。专线业务要额外用1500字节以上的大包ping验证大包通、小包也通才算链路合格。这些步骤原本没什么技术含量但真到上线或者处理故障的时候每跳过一步都可能埋一个后遗症。有一次为了赶割接窗口跳过了ONT侧的大包验证结果专线开了两天客户才反馈丢包最后定位到MTU配置和骨干侧不一致那次的教训是验证步骤可以少但关键的几步一步都不能省。从那以后凡是专线、基站回传这类关键业务每次交付都强制走完上面五步并把验证命令的输出保存下来作为交付附件。希望这些步骤和踩坑记录能让你在接手OLT配置时少绕几圈。本文还有配套的精品资源点击获取
