宽带接入的认证发生在 BRAS，但 BRAS 只看到 IP 报文，看不到用户接在哪根光纤上。没有线路信息时，三种问题会同时出现：
地址池无法按区域划分。 同一个池子发给全城，某个片区地址耗尽，只能临时扩池。
私接无法约束。 用户接一台路由器，后面挂十台设备，BRAS 只看到路由器的 MAC，全部放行。
故障无法定位。 用户报修，客服只能问地址，运维再去翻台账找 PON 口，中间全靠人。
OLT 作为接入侧的汇聚点，是唯一知道"这个报文从哪个 PON 口、哪台 ONU、哪个 UNI 口进来"的设备。让它把这段信息插进报文，BRAS 就能把"线路"和"用户"绑起来。DHCP 场景用 Option 82，PPPoE 场景用中间代理（PPPoE+），两者思路一致。
Option 82 定义在 RFC 3046，正式名称是 DHCP Relay Agent Information Option。它由中继设备（这里是 OLT）插入，服务端原样回送，中继再剥掉。
结构很简单：
| 字段 | 长度 | 含义 |
|---|---|---|
| Option Code | 1 字节 | 固定 82 |
| Length | 1 字节 | 后续内容总长，最大 255 |
| Sub-option 1 | 可变 | Circuit-ID，线路标识 |
| Sub-option 2 | 可变 | Remote-ID，远端设备标识 |
| Sub-option 5 | 可变 | Link Selection，RFC 3527 定义，用于选择地址池 |
两个子选项的内容没有标准格式，由厂商自定义，这也是互通问题的根源。常见的编码方式：
Circuit-ID：gpon 0/1:15 这类，表示框/槽/ PON 口/ONU-ID，有的平台还会带 UNI 口号
Remote-ID：ONU 的 MAC 或 SN，作为设备身份
两者的分工值得说清：Circuit-ID 标识位置，Remote-ID 标识设备。 用户换 ONU 时，位置不变、设备变；用户搬家时，设备不变、位置变。BRAS 侧把两者都记下来，才能区分"换机"和"移机"这两种完全不同的运维事件。
长度上要留余量。Option 82 的 Length 字段只有 1 字节，上限 255。一个典型配置：Circuit-ID 11 字节加子选项头 2 字节，Remote-ID 17 字节加头 2 字节，加上 Option 82 自身的 2 字节头，总共 34 字节。DHCP 报文最小 300 字节，加 34 字节仍是 334 字节，离 MTU 1500 很远。真正会顶到上限的是把整条描述性字符串塞进 Circuit-ID 的做法，没必要。
PPPoE 走的是另一条路。RFC 2516 定义的发现阶段有四个报文：PADI（客户端广播找接入集中器）、PADO（集中器回应）、PADR（客户端选定）、PADS（会话确认）。会话建立后才是 PPP 的 LCP 认证。
PPPoE+ 又叫 PPPoE 中间代理（Intermediate Agent），宽带论坛的 TR-101 给了定义。它做的事是：OLT 拦截 PADI 和 PADR，在报文里插入一个厂商私有 tag，标明线路信息，再转发给 BRAS。
与 Option 82 的差别在于生效阶段：
| 维度 | DHCP Option 82 | PPPoE+ |
|---|---|---|
| 适用协议 | DHCP（RFC 3046） | PPPoE 发现阶段（RFC 2516 / TR-101） |
| 承载位置 | DHCP 选项区 | PPPoE 发现报文的 vendor-specific tag |
| 插入时机 | 中继转发时 | PADI / PADR 上行时 |
| 主要用途 | 地址池选择、地址绑定 | 账号与线路绑定、防账号盗用 |
| 依赖 | 中继（giaddr）必须正确 | BRAS 需支持对应 tag 格式 |
两者的共同点是：信息由接入设备插入，由 BRAS 消费，用户侧无法伪造。 用户能改自己路由器里的任何设置，但改不了 OLT 插入的字段。
拿到线路信息后，BRAS 能做四件事。
其一，选地址池。 按 Circuit-ID 里的 PON 口或区域字段，把用户分配到对应的地址段。好处是每个片区的地址独立管理，某一区耗尽不影响其他区。
其二，校验绑定关系。 开户时把账号与 Circuit-ID 一起写进 AAA，拨号时比对，不一致就拒绝。这能挡住"账号在 A 小区办，拿到 B 小区用"的情况。
其三，计费落到线路。 按线路而不是按 MAC 计费，用户换设备不影响账务。
其四，定位故障。 用户报修时，客服凭账号就能查到 PON 口和 ONU-ID，不用问地址。
这四件事里，第二件是防私接的关键，但它只能防"账号异地使用"，防不了"同一线路下挂多台设备"。后者要靠 MAC 数限制或端口隔离，属于另一个层面。
| 手段 | 作用层面 | 能防什么 | 防不了什么 |
|---|---|---|---|
| Option 82 / PPPoE+ | 认证与地址分配 | 账号异地使用、地址池串用 | 同线路下挂多台设备 |
| MAC 数限制 | 二层转发 | 单端口学习过多 MAC（私接路由） | 伪造 MAC、MAC 克隆 |
| UNI 端口隔离 | 二层隔离 | 同 ONU 下设备互访、用户侧成环 | 上行流量超限 |
三者要叠起来用。只配 Option 82，用户接个路由器照样能带十台设备；只配 MAC 数限制，用户把账号拿到别处用照样能通。一个管"你是谁"，一个管"你能带几个"，一个管"你们之间能不能通"。
MAC 数限制的取值要留余量。家庭场景常见 4–8 个，商户 8–16 个，企业专线按合同定。取太紧会误伤（用户换了手机、加了智能家居设备），取太松等于没配。
一个 1024 户的小区，1 台 OLT、4 个 PON 口，每口 1:256 分光（实际按 1:128 配两台分光器级联）。核算三笔账。
第一笔，Option 82 长度。
Circuit-ID 取 gpon 0/1:15 格式，11 字节；Remote-ID 取 MAC 的 17 字节文本格式。
Option 82 总长 = 2（头）+ 2（子选项头）+ 11 + 2 + 17 = 34 字节
DHCP 报文 300 + 34 = 334 字节，远小于 1500，无分片风险。
第二笔，MAC 表容量。
每户平均 3 台设备（手机、电视、电脑），1024 户 = 3072 个 MAC。
单 PON 口按 256 户算，256 × 3 = 768 个 MAC。若 OLT 的 MAC 表按整机 4096 条设计，4 个口合计 3072 条，占用 75%。余量只剩 25%，一旦有用户私接路由器带 10 台设备，表项就会被吃紧。 这也是必须配 MAC 数限制的实际理由，不只是"防蹭网"。
第三笔，BRAS 绑定表容量。
每条记录包含 Circuit-ID（约 12 字节）、Remote-ID（17 字节）、账号（约 20 字节）、索引开销（约 32 字节），合计约 81 字节。
10,000 用户的绑定表 ≈ 810 KB。这个量级对 BRAS 内存没有压力，真正的约束在查表性能——按 Circuit-ID 建哈希索引，万级条目下仍是常数时间。所以绑定表不是瓶颈，"开户时有没有把 Circuit-ID 写进去"才是。
结论：Option 82 的长度不是问题，MAC 表余量是问题；绑定表容量不是问题，开户流程是问题。这两条决定了项目上线后是稳定运行还是天天救火。
故障一：用户能拿到 IP，但上不了网。 先看 BRAS 有没有收到 Option 82。OLT 侧中继没开、giaddr 没配、或者上联口没放行 DHCP 报文，都会导致中继失效。抓包位置选在 OLT 上联口，看报文里有没有 option 82 字段。
故障二：换了 ONU 之后上不了网。 如果绑定表里同时记了 Remote-ID，换机后 Remote-ID 变了，绑定校验失败。处理方式是先解绑再换机，或者开户时只用 Circuit-ID 做绑定、Remote-ID 仅作记录。
故障三：PPPoE 拨号失败但 DHCP 正常。 说明 PPPoE+ 的 tag 没插上或格式不匹配。TR-101 只规定了 tag 的用途，具体格式各家不同，BRAS 与 OLT 必须用同一套编码。跨厂商组网时，这一条要提前联调。
故障四：同一 PON 口下部分用户拿不到地址。 检查地址池与 Circuit-ID 的映射规则。常见错误是按 PON 口分池后，池子容量小于该口用户数。
三段示意，不同平台命令不同，以实际 CLI 为准。
! 示意：OLT 侧开启 DHCP 中继并插入 Option 82 interface gpon 0/1 dhcp relay enable dhcp relay information option 82 enable dhcp relay circuit-id format slot/port/onuid ! 示意：PPPoE 中间代理 pppoe intermediate-agent enable pppoe intermediate-agent circuit-id include-uni
配完之后必须做一次端到端验证：从 ONU 侧发起 DHCP 请求，在 OLT 上联口抓包，确认 Option 82 存在且内容符合预期，再看 BRAS 的分配结果。只配不验，等于没配。
锐应 L102P 这类 2 口 mini GPON OLT 单口支持 1:128 分光，配合 XPON ONU 用在小区和园区场景时，Option 82 与 PPPoE+ 的开关位置、Circuit-ID 的编码格式要按软件版本确认，不同版本支持的子选项不完全一样。设备规格与接法见 PON 方案页，上联侧若是工业交换机承载，端口与 VLAN 配置见 工业交换机方案。
OLT 加。OLT 作为 DHCP 中继，在转发用户请求时插入 Option 82，同时填写 giaddr。BRAS 或 DHCP 服务器收到后原样回送，OLT 在回程剥掉再转发给用户。用户侧看不到这个字段，也改不了。
Circuit-ID 标识"接在哪"，Remote-ID 标识"接在什么设备上"。前者通常编码为框/槽/PON 口/ONU-ID，后者放 ONU 的 MAC 或 SN。换 ONU 时 Circuit-ID 不变、Remote-ID 变，这是区分"换机"与"移机"的依据。绑定策略要按业务需要选其中一个或两个都用。
能，而且常见。一个小区里可能既有 DHCP 接入的 IPTV 机顶盒，又有 PPPoE 拨号的上网业务，两套机制各管一类。配置时注意别把 PPPoE 的 tag 和 DHCP 的选项搞混，它们的插入位置和报文类型完全不同。
防不住。Option 82 管的是"账号与线路的绑定"，用户在同一线路下接路由器带多台设备，Option 82 完全放行，因为线路没变。要防这种情况，得配 MAC 数限制或端口隔离。三者叠加才完整。
因为绑定表里记了 Remote-ID（ONU 的 MAC 或 SN）。新 ONU 的 Remote-ID 不同，校验失败。解决办法有两个：一是运维流程上加"换机先解绑"，二是绑定策略只认 Circuit-ID，Remote-ID 仅作资产记录。后者的运维成本更低，但防不住"整台 ONU 被搬到别处"。
Option 82 与 PPPoE+ 都属于"基础设施型"功能：平时感觉不到，出事时全靠它。上线前把编码格式、绑定策略、池子容量三件事定下来，后面几年都省心；定不下来就上线，故障会以"用户能拨号但上不了网"这种最难查的形态出现。设备侧的支持情况见 关于锐应。
