docs: add SE5420 core-switch deployment plans; note PVE VM topology
This commit is contained in:
windyboy
@@ -0,0 +1,156 @@
|
||||
# LAN 核心交换机升级计划（保留 ER-X）
|
||||
|
||||
**状态：** SE5420 **已采购**（2026-08-09）。**实施与验证以 [lan-se5420-deployment-guide.md](lan-se5420-deployment-guide.md) 为准**；
|
||||
本文保留为设计/阶段划分参考。
|
||||
**锁定硬件：** TP-Link **`TL-SE5420`**（16 × 2.5GbE RJ45 + 4 × 10GbE SFP+）。
|
||||
**目标：** SE5420 承接全部 LAN 物理接入与二层转发；ER-X 继续承担公网、NAT、防火墙、
|
||||
LAN66/LAN55 网关与 DHCP。
|
||||
|
||||
**拓扑与流量的详细说明**（职责、逻辑网、流量路径、Wi-Fi 分工、验收边界）见：
|
||||
[lan-erx-se5420-network.md](lan-erx-se5420-network.md)。
|
||||
|
||||
SE5420 官方资料：静态功耗 8 W、最大功耗 32 W；VLAN、LACP、STP/RSTP/MSTP、ACL、
|
||||
CLI/SNMP、配置导入导出与固件下载。无 PoE——AP 使用本地取电 + 普通网线。
|
||||
|
||||
## 已确认边界（摘要）
|
||||
|
||||
| 项 | 结论 |
|
||||
|---|---|
|
||||
| 硬目标 | 同 VLAN 2.5G；SFP+ 先空槽 |
|
||||
| 核心角色 | 纯 L2；不开 L3 / DHCP Server/Relay / NAT |
|
||||
| 网关 | 默认一律 ER-X `.254`；升级专用 SSID（后续）才走 `gfw` `.1` |
|
||||
| 本次 Done | 阶段 0–3；VLAN10 / 客人 SSID / 升级 SSID 另立项目 |
|
||||
| 切换 | 30–60 分钟维护窗；旧交换迁完后闲置 |
|
||||
| 首批 2.5G | NAS + 主力 PC（或 PVE） |
|
||||
| 管理 | 先本地 HTTPS/SSH；云以后再说 |
|
||||
|
||||
### 保留的 ER-X 职责
|
||||
|
||||
| 项目 | 迁移后职责 |
|
||||
|---|---|
|
||||
| PPPoE / WAN、NAT、端口转发、WAN 防火墙 | ER-X，不变 |
|
||||
| LAN66 (`192.168.66.0/24`) 默认网关与 DHCP | ER-X `eth0`，不变 |
|
||||
| LAN55 (`192.168.55.0/24`) 默认网关与 DHCP | ER-X `switch0`，不变 |
|
||||
| LAN66 ↔ LAN55 三层转发 | ER-X，不变 |
|
||||
| 升级专用 Wi-Fi 网关（后续） | `gfw` VM，不是 ER-X 或核心交换机 |
|
||||
|
||||
ER-X 与核心之间使用两条**独立无标签 access**（LAN66 + LAN55），不向 ER-X 送
|
||||
VLAN tag。
|
||||
|
||||
### 核心交换机职责
|
||||
|
||||
- 所有有线设备、AP 与 PVE 的物理接入；
|
||||
- VLAN66、VLAN55 的二层转发；
|
||||
- 为日后 U6 Lite 与 PVE 预留 VLAN10 trunk（本次不启用业务）；
|
||||
- 同 VLAN 的 1G/2.5G 转发；
|
||||
- SFP+ 预留未来 10G（DAC/AOC/光；不用 10GBASE-T 作默认）。
|
||||
|
||||
## 目标拓扑（简图）
|
||||
|
||||
```text
|
||||
Internet
|
||||
|
|
||||
ER-X / PPPoE
|
||||
+-------+--------+
|
||||
| |
|
||||
eth0, LAN66 switch0 port, LAN55
|
||||
access access
|
||||
| |
|
||||
+-------+--------+
|
||||
|
|
||||
TL-SE5420 核心（纯 L2）
|
||||
| | |
|
||||
PVE / gfw U6 Lite LAN66/LAN55 access
|
||||
（日后 trunk） （日后 trunk） NAS, PC, dns, ubnt, AC-Lite …
|
||||
```
|
||||
|
||||
完整端口表、流量路径与 Wi-Fi 分工见
|
||||
[lan-erx-se5420-network.md](lan-erx-se5420-network.md)。
|
||||
|
||||
## VLAN 与端口设计
|
||||
|
||||
| VLAN / 逻辑网络 | 核心配置 | 网关 / DHCP | 用途 |
|
||||
|---|---|---|---|
|
||||
| 66 | access；PVE/U6 日后 trunk 的 native | ER-X `eth0` / `.254` | 主 LAN、管理 |
|
||||
| 55 | access | ER-X `switch0` / `.254` | LAN55、AC-Lite |
|
||||
| 10（后续） | 仅 PVE 与 U6 trunk 上 tagged | `gfw` | 升级专用 SSID |
|
||||
| 管理 | LAN66 管理地址；不新建 VLAN | reservation / 静态 | SE5420 管理面 |
|
||||
|
||||
管理地址分配前先查 ER-X DHCP/reservation；禁用不需要的 HTTP/Telnet；云管延后；
|
||||
保留 HTTPS/SSH 与离线配置备份（备份不进本仓库）。
|
||||
|
||||
### 初始端口分配
|
||||
|
||||
| 预留 | 对端 | 模式 |
|
||||
|---|---|---|
|
||||
| 铜口 1 | ER-X `eth0` | access VLAN66 |
|
||||
| 铜口 2 | ER-X `switch0` 成员口 | access VLAN55 |
|
||||
| 铜口 3 | PVE（`gfw`） | 现 access 66；日后 trunk native66+tag10 |
|
||||
| 铜口 4 | U6 Lite | 同上；本地取电 |
|
||||
| 铜口 5 | UAP-AC-Lite | access VLAN55；本地取电 |
|
||||
| 其余铜口 | NAS、PC、`dns`、`ubnt`… | 默认 access VLAN66 |
|
||||
| SFP+ 1–4 | 未来 | 空槽 |
|
||||
|
||||
## 分阶段实施与验收
|
||||
|
||||
### 阶段 0：采购前核验
|
||||
|
||||
1. 确认 SE5420 revision、保修、手册、固件页。
|
||||
2. 确认 VLAN trunk、RSTP/MSTP、LACP、镜像、配置导出、错误计数。
|
||||
3. SFP+ 模块本次不买；有对端后再选 DAC/AOC/光。
|
||||
4. 盘点线缆与对端（LAN66/55、PVE、两台 AP）；确认关键 2.5G 链路可协商。
|
||||
|
||||
### 阶段 1：离线初始化核心
|
||||
|
||||
1. 仅电源 + 隔离管理本：管理 IP、强密码、时区、NTP、HTTPS/SSH；**关闭 L3/DHCP**。
|
||||
2. 导出初始配置（离线保存，不进仓库）。
|
||||
3. 建立 VLAN66/55/10 与端口模板；VLAN10 不接生产。
|
||||
4. 开启 RSTP/MSTP；不制造物理环路。
|
||||
|
||||
### 阶段 2：维护窗迁移 LAN66
|
||||
|
||||
1. 使用约定维护窗（约 30–60 分钟）；保留原接线作回滚。
|
||||
2. 先接铜口 1 ↔ ER-X `eth0`；验证管理地址、`.254`、DNS `.36`、互联网。
|
||||
3. 逐台迁到 VLAN66 access；每台确认地址/DNS/路由/业务。
|
||||
4. 最后迁 `ubnt`、`dns`、NAS/PC；禁止无意双上行。
|
||||
|
||||
### 阶段 3：迁移 LAN55
|
||||
|
||||
1. 接铜口 2 ↔ ER-X `switch0` 成员口。
|
||||
2. 测试设备获 `192.168.55.x`、网关 `.254`、可达 DNS。
|
||||
3. AC-Lite → 铜口 5；确认 `.55.5` 与 Inform Connected。
|
||||
4. 旧交换下电闲置。
|
||||
|
||||
### 阶段 4：VLAN10 升级专用 Wi-Fi（独立项目）
|
||||
|
||||
不与本次 Done 捆绑。仅 U6；网关 `gfw`；详见
|
||||
[lan-erx-se5420-network.md](lan-erx-se5420-network.md) 第 6.5 / 8 节与
|
||||
[unifi-network.md](unifi-network.md)。
|
||||
|
||||
## 性能预期与不变瓶颈
|
||||
|
||||
- 同 VLAN、两端在核心上的 2.5G：可测 2.5G 级二层。
|
||||
- 上网与 LAN66↔LAN55：仍经 ER-X 1G 路径。
|
||||
- 空 SFP+ 不使网络「变成 10G」。
|
||||
|
||||
## 验收清单
|
||||
|
||||
- 管理面、口令、离线备份；
|
||||
- 端口速率与错误计数；
|
||||
- LAN66/55 的 DHCP、网关、DNS、互联网与关键本地服务；
|
||||
- 两台 AP Connected；Inform 仍为 `http://192.168.66.46:9080/inform`；
|
||||
- 无无意环路；旧交换已闲置；
|
||||
- （建议）两台 2.5G 终端同 VLAN `iperf3`。
|
||||
|
||||
## 回滚
|
||||
|
||||
验证失败则停迁、恢复原接线；不改 ER-X WAN/DHCP/SSH。VLAN10 失败只撤新 SSID。
|
||||
|
||||
## 参考
|
||||
|
||||
- [ER-X + SE5420 网络与拓扑说明](lan-erx-se5420-network.md)
|
||||
- [LAN 概览](lan-overview.md)
|
||||
- [ER-X 配置记录](edgerouter-x-configuration.md)
|
||||
- [UniFi 网络](unifi-network.md)
|
||||
- [`gfw`](../hosts/gfw.windy.lan.md)
|
||||
- [TL-SE5420 官方规格](https://www.tp-link.com.cn/product_2899.html?v=specification)
|
||||
@@ -0,0 +1,321 @@
|
||||
# ER-X + TL-SE5420 网络与拓扑说明
|
||||
|
||||
**状态：** SE5420 **已采购**（2026-08-09）。**实施与验证以 [lan-se5420-deployment-guide.md](lan-se5420-deployment-guide.md) 为准**；
|
||||
本文保留为拓扑/流量路径/职责边界的设计说明。
|
||||
**锁定硬件：** EdgeRouter X（保留）+ TP-Link `TL-SE5420`（新建核心）。
|
||||
**本文目的：** 说明升级后物理拓扑、逻辑网络、流量路径与职责边界；实施步骤见
|
||||
[lan-core-switch-upgrade-plan.md](lan-core-switch-upgrade-plan.md)。
|
||||
|
||||
---
|
||||
|
||||
## 1. 一句话架构
|
||||
|
||||
```text
|
||||
公网 ← ER-X（网关 / NAT / DHCP / 防火墙）
|
||||
↑ 两条独立 access 上联（LAN66 + LAN55，无 VLAN tag）
|
||||
TL-SE5420（纯 L2 核心：所有接入、同 VLAN 转发、未来 trunk）
|
||||
↑
|
||||
有线终端 / PVE(gfw) / 两台 UniFi AP
|
||||
```
|
||||
|
||||
- **ER-X** 继续当唯一主网关：PPPoE、NAT、端口转发、LAN66/LAN55 的 `.254` 与 DHCP。
|
||||
- **SE5420** 只做二层：接线、VLAN 隔离转发、端口统计；**不开** L3、静态路由、DHCP
|
||||
Server/Relay、NAT。
|
||||
- **`gfw`（PVE 上的 OpenWrt）** 仍是旁路由；默认客户端网关仍是 `.254`。以后若启用
|
||||
「设备升级」专用 SSID，该 SSID 的客户端才把网关指向 `.1`。
|
||||
|
||||
---
|
||||
|
||||
## 2. 已确认的设计决策
|
||||
|
||||
| 决策 | 结论 |
|
||||
|---|---|
|
||||
| 硬目标 | 同 VLAN **2.5G** 二层转发；10G 仅 SFP+ 预留 |
|
||||
| 核心型号 | **`TL-SE5420`**（16×2.5G RJ45 + 4×10G SFP+） |
|
||||
| 终局形态 | ER-X 边缘网关 + 核心纯 L2；可分阶段实施 |
|
||||
| 本次升级 Done | 迁完 LAN66/LAN55 接入与验收（计划阶段 0–3）；不含 VLAN10 |
|
||||
| 默认网关 | **`192.168.66.254` / `192.168.55.254`（ER-X）** |
|
||||
| 专用升级 SSID | 仅 **U6 Lite**；客户端网关 **`gfw` `.1`**（后续项目） |
|
||||
| 客人网 | 仅 **UAP-AC-Lite**；UniFi Guest 隔离，仍在 **LAN55**（后续） |
|
||||
| 切换方式 | **30–60 分钟维护窗** 集中切；旧交换迁完后闲置 |
|
||||
| 首批 2.5G | NAS + 主力 PC（或 PVE）；其余可先 1G |
|
||||
| SFP+ | 先空槽；有明确 10G 对端再买 DAC/光模块 |
|
||||
| AP 供电 | **本地取电 + 普通网线**（SE5420 **无 PoE**） |
|
||||
| 管理面 | 先本地 HTTPS/SSH；云以后再说；L3/DHCP 严格关闭 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 设备职责
|
||||
|
||||
### 3.1 EdgeRouter X（`gw`，`192.168.66.254`）
|
||||
|
||||
| 职责 | 说明 |
|
||||
|---|---|
|
||||
| WAN | `eth4` → PPPoE（`pppoe0`），NAT、WAN 防火墙、端口转发 |
|
||||
| LAN66 网关/DHCP | `eth0` = `192.168.66.254/24`；DHCP 池与静态映射不变 |
|
||||
| LAN55 网关/DHCP | `switch0`（`eth1`–`eth3`）= `192.168.55.254/24` |
|
||||
| 跨网段路由 | LAN66 ↔ LAN55 仍由 ER-X 三层转发 |
|
||||
| 与核心的连接 | **两条无标签 access**，不是 802.1Q trunk |
|
||||
|
||||
ER-X 当前不是 trunk 设计：不要向它发送 VLAN66/55 的 tag。核心上 VLAN66 的
|
||||
untagged 帧进 `eth0`；VLAN55 的 untagged 帧进 `switch0` 的某个成员口。
|
||||
|
||||
### 3.2 TL-SE5420（新建核心）
|
||||
|
||||
| 职责 | 说明 |
|
||||
|---|---|
|
||||
| 物理接入汇聚 | 有线设备、PVE、两台 AP 都接到 SE5420 |
|
||||
| VLAN66 / VLAN55 | 二层转发（access 或 trunk 的 native/allowed） |
|
||||
| 同 VLAN 高速交换 | 两端都是 2.5G 时可跑满协商速率（受 NIC/线材限制） |
|
||||
| 未来 trunk | PVE、U6：native 66 + tagged 10（仅后续阶段启用） |
|
||||
| 不做 | 不当默认网关；不开 DHCP；不做 NAT；第一阶段不开 SVI/路由 |
|
||||
|
||||
管理地址：落在 **LAN66** 的一个未占用地址（先查 ER-X DHCP reservation，再分配）；
|
||||
不新建管理 VLAN。
|
||||
|
||||
### 3.3 旁路由 `gfw`（`192.168.66.1`）
|
||||
|
||||
| 现状 | 升级后（阶段 0–3） | 更后续 |
|
||||
|---|---|---|
|
||||
| PVE 上的 ImmortalWrt VM | 仍挂在 **untagged LAN66** | 可增 VLAN10 接口 |
|
||||
| OpenClash 旁路/透明代理 | 路径不变：客户端默认仍走 `.254` | 升级专用 SSID → 网关 `.1` |
|
||||
| 不能单独「做出」VLAN10 | 需 PVE vSwitch + 核心 trunk + U6 trunk | 见第 7 节 |
|
||||
|
||||
### 3.4 其它现网角色（地址与角色不变）
|
||||
|
||||
| 主机 | 地址 | 角色 |
|
||||
|---|---|---|
|
||||
| `dns.windy.lan` | `192.168.66.36` | AdGuard Home + Mihomo |
|
||||
| `ubnt` | `192.168.66.46` | UniFi Controller；Inform `http://192.168.66.46:9080/inform` |
|
||||
| U6 Lite | `192.168.66.6` | LAN66 AP；后续承载升级专用 SSID |
|
||||
| UAP-AC-Lite | `192.168.55.5` | LAN55 AP；后续承载客人 SSID |
|
||||
| PVE | `192.168.66.26`（DHCP 静态） | 宿主机；上挂 `gfw` |
|
||||
| NAS / 主力 PC 等 | 既有 reservation | 首批 2.5G 候选 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 物理拓扑
|
||||
|
||||
### 4.1 目标连线（阶段 3 完成后）
|
||||
|
||||
```text
|
||||
Internet
|
||||
│
|
||||
PPPoE / WAN
|
||||
│
|
||||
┌──────────┴──────────┐
|
||||
│ EdgeRouter X │
|
||||
│ (gw / 网关) │
|
||||
│ │
|
||||
│ eth0 switch0 成员口
|
||||
│ LAN66 LAN55
|
||||
│ untagged untagged
|
||||
└───┬───────────────┬─┘
|
||||
│ │
|
||||
铜口1│ │铜口2
|
||||
│ │
|
||||
┌─────────┴───────────────┴─────────┐
|
||||
│ TL-SE5420 核心 │
|
||||
│ 16×2.5G RJ45 + 4×SFP+（先空） │
|
||||
│ 纯 L2 · VLAN66 / VLAN55 │
|
||||
└───┬─────┬─────┬─────┬─────┬───────┘
|
||||
│ │ │ │ │
|
||||
铜口3 铜口4 铜口5 其余铜口 SFP+
|
||||
│ │ │ │ （预留）
|
||||
│ │ │ │
|
||||
PVE U6 AC-Lite NAS/PC/
|
||||
(gfw) Lite (LAN55) dns/ubnt…
|
||||
LAN66 LAN66 默认 LAN66
|
||||
（日后可 （日后可
|
||||
trunk) trunk)
|
||||
```
|
||||
|
||||
要点：
|
||||
|
||||
1. **星型**：终端与 AP 只上联到 SE5420；旧交换机迁完后**闲置**，避免双上行环路。
|
||||
2. **ER-X 双上联**：LAN66、LAN55 各一条独立铜缆；两条都是 access，**不打 tag**。
|
||||
3. **AP 供电**：SE5420 无 PoE；U6 / AC-Lite 在安装点**本地取电**，网线只传数据。
|
||||
4. **SFP+**：四个槽位先空着；有 10G NIC/对端与兼容模块后再上 DAC/AOC/光纤。
|
||||
|
||||
### 4.2 与「现在」的差异（概念上）
|
||||
|
||||
```text
|
||||
现在（简化） 目标
|
||||
───────────── ────
|
||||
终端/AP ──► ER-X 内置交换/旧交换 终端/AP ──► SE5420 ──► ER-X（仅网关）
|
||||
同网段 1G 交换受 ER-X/旧设备限制 同 VLAN 2.5G 在 SE5420 上本地交换
|
||||
跨网段 / 上网 仍经 ER-X 跨网段 / 上网 仍经 ER-X（不变）
|
||||
```
|
||||
|
||||
ER-X **不会被换成**「只接一条 trunk 的路由」；WAN 与双 LAN 接口模型保持不变。
|
||||
|
||||
---
|
||||
|
||||
## 5. 逻辑网络（VLAN / 子网）
|
||||
|
||||
### 5.1 本次升级范围内（阶段 0–3）
|
||||
|
||||
| 名称 | 子网 | 核心上的形态 | 网关 | DHCP | 典型成员 |
|
||||
|---|---|---|---|---|---|
|
||||
| **LAN66** | `192.168.66.0/24` | VLAN 66：access，或 trunk 的 native | ER-X `eth0` `.254` | ER-X | PVE、gfw、dns、ubnt、U6、NAS、PC… |
|
||||
| **LAN55** | `192.168.55.0/24` | VLAN 55：access | ER-X `switch0` `.254` | ER-X | UAP-AC-Lite、原 LAN55 设备 |
|
||||
|
||||
客户端 DNS 仍按现网：DHCP 下发 `192.168.66.36`（AdGuard）。
|
||||
LAN55 ↔ LAN66 互通仍走 ER-X（现网 `LAN_IN`/`LAN_OUT` 未挂到接口时，两边默认可达；不要把未生效的防火墙当隔离边界）。
|
||||
|
||||
### 5.2 后续能力（不进本次 Done）
|
||||
|
||||
| 名称 | 打算 | 网关 | 落点 | 依赖 |
|
||||
|---|---|---|---|---|
|
||||
| **升级专用 Wi-Fi** | 独立 SSID → 独立 VLAN（如 VLAN10） | **`gfw` `.1`**（该 VLAN 内） | **仅 U6 Lite** | 核心 trunk + PVE vSwitch + `gfw` DHCP/NAT |
|
||||
| **客人网** | 客人 SSID + UniFi Guest 隔离 | 仍 **ER-X `.254`（LAN55）** | **仅 UAP-AC-Lite** | UniFi 策略；**不**新建 VLAN |
|
||||
|
||||
客人网与升级 SSID **分工到两台 AP**，避免一上来就做「两台 AP 同一客人 VLAN + ER-X trunk」的改造。
|
||||
|
||||
### 5.3 核心上为何仍预配 VLAN10
|
||||
|
||||
阶段 1 可在 SE5420 上建好 VLAN10 与 trunk 模板，但：
|
||||
|
||||
- **不接生产终端**；
|
||||
- **不改 UniFi SSID**；
|
||||
- **不在 `gfw` 上启用与 ER-X 冲突的 DHCP**。
|
||||
|
||||
这样迁线项目与「专用升级 Wi-Fi」解耦：核心一次配好端口角色，业务另开窗口。
|
||||
|
||||
---
|
||||
|
||||
## 6. 流量怎么走
|
||||
|
||||
### 6.1 同 VLAN、两端都在核心上（例如 NAS ↔ PC，皆 LAN66）
|
||||
|
||||
```text
|
||||
NAS ──(2.5G)── SE5420 ──(2.5G)── PC
|
||||
（二层交换，不经过 ER-X）
|
||||
```
|
||||
|
||||
这是本次升级的**主要收益**。吞吐受 NIC、线材、磁盘限制；与 ER-X 的 1G 无关。
|
||||
|
||||
### 6.2 访问互联网（任意 LAN66/LAN55 客户端）
|
||||
|
||||
```text
|
||||
客户端 → SE5420 →（对应 access 上联）→ ER-X → PPPoE → Internet
|
||||
默认网关 = .254
|
||||
```
|
||||
|
||||
上网路径仍受 **ER-X 上联 1G** 与 PPPoE 限制；换核心**不会**把公网变成 2.5G。
|
||||
|
||||
### 6.3 LAN66 ↔ LAN55
|
||||
|
||||
```text
|
||||
LAN66 设备 → SE5420(VLAN66) → ER-X eth0
|
||||
↕ 三层转发
|
||||
LAN55 设备 → SE5420(VLAN55) → ER-X switch0
|
||||
```
|
||||
|
||||
跨网段必须过 ER-X；两条上联各 1G，且 ER-X 是否硬件加速需实测，**不要**按 2.5G 承诺跨 VLAN 吞吐。
|
||||
|
||||
### 6.4 旁路由 `gfw`（默认主网行为）
|
||||
|
||||
默认：DHCP 仍发网关 `.254`。客户端若把代理/策略指到 `gfw`，或由上游策略引流，则
|
||||
`gfw` 以旁路由身份处理；**主网关身份仍是 ER-X**。
|
||||
|
||||
### 6.5 未来：升级专用 SSID（仅说明，非本次范围）
|
||||
|
||||
```text
|
||||
手机 --SSID(升级)--> U6 Lite --tag VLAN10--> SE5420 --tag VLAN10--> PVE --> gfw
|
||||
网关 .1
|
||||
gfw 上游仍回 LAN66 → SE5420 → ER-X → Internet
|
||||
```
|
||||
|
||||
主 SSID（如现有 `ubnt-windy`）继续 untagged/LAN66，网关仍是 `.254`，互不影响。
|
||||
|
||||
---
|
||||
|
||||
## 7. 端口预留（SE5420）
|
||||
|
||||
端口号以面板为准；下表是角色预留。
|
||||
|
||||
| 预留 | 对端 | 模式 | 备注 |
|
||||
|---|---|---|---|
|
||||
| 铜口 1 | ER-X `eth0` | access VLAN66 | 主网上联 |
|
||||
| 铜口 2 | ER-X `switch0` 成员口 | access VLAN55 | LAN55 上联 |
|
||||
| 铜口 3 | PVE（`gfw` 所在宿主机） | 阶段 0–3：access VLAN66；日后 trunk native66+tag10 | 只允许需要的 VLAN |
|
||||
| 铜口 4 | U6 Lite | 同上 | 本地取电；日后升级 SSID |
|
||||
| 铜口 5 | UAP-AC-Lite | access VLAN55 | 本地取电；日后客人 SSID |
|
||||
| 其余铜口 | NAS、PC、`dns`、`ubnt`… | 默认 access VLAN66 | 首批 2.5G：NAS + 主力 PC/PVE |
|
||||
| SFP+ 1–4 | 未来 10G | 空槽 | 优先 DAC/AOC/光；不用 10GBASE-T 模块作默认 |
|
||||
|
||||
禁止：同一设备同时接旧路径与新核心形成**无意双上行**（环路/环回保护误杀/不稳定）。
|
||||
|
||||
---
|
||||
|
||||
## 8. Wi-Fi 与 UniFi（目标语义）
|
||||
|
||||
| SSID 类型 | AP | 二层落点 | 客户端网关 | 本次升级是否必须完成 |
|
||||
|---|---|---|---|---|
|
||||
| 现有主 SSID（如 `ubnt-windy`） | 按现网 | LAN66 等 | `.254` | 迁线后保持 Connected 即可 |
|
||||
| 客人 SSID | **仅 AC-Lite** | LAN55 + UniFi Guest 隔离 | `.254` | **否**（后续） |
|
||||
| 升级专用 SSID | **仅 U6** | 未来 VLAN10 | **`.1`（gfw）** | **否**（后续） |
|
||||
|
||||
Inform 仍为：`http://192.168.66.46:9080/inform`。
|
||||
AC-Lite 在 LAN55、Controller 在 LAN66：跨网段由 ER-X 转发（现网已验证可达）。
|
||||
|
||||
---
|
||||
|
||||
## 9. 管理与安全面
|
||||
|
||||
| 项 | 做法 |
|
||||
|---|---|
|
||||
| SE5420 管理 IP | LAN66 未占用地址；DHCP reservation 或静态；先查 ER-X 再写 |
|
||||
| 管理协议 | 本地 HTTPS / SSH；禁用不需要的 HTTP/Telnet |
|
||||
| 云管 | 先本地管稳；商云/App **以后再说** |
|
||||
| L3 功能 | **全部关闭**（无 SVI、无静态路由、无 DHCP Server/Relay） |
|
||||
| STP | 开启 RSTP/MSTP；合理根桥优先级；迁完后不留生产环路 |
|
||||
| 配置备份 | 离线导出；**不得**把含口令/SNMP 的备份放进本仓库 |
|
||||
| AP | 本地电源 + 数据网线；核心不供电 |
|
||||
|
||||
---
|
||||
|
||||
## 10. 性能预期（诚实边界）
|
||||
|
||||
| 场景 | 预期 |
|
||||
|---|---|
|
||||
| 同 VLAN、两端 2.5G 接在 SE5420 | 可达约 2.5G 级二层（测 `iperf3` 验收） |
|
||||
| 上网 / PPPoE | 仍受 ER-X WAN 与 1G 上联限制 |
|
||||
| LAN66 ↔ LAN55 | 必过 ER-X；按 1G 级规划，实测为准 |
|
||||
| SFP+ 空槽 | **不等于**网络已是 10G |
|
||||
| 未来 VLAN10 + `gfw` | 受 PVE NIC/vSwitch 与 `gfw` 处理能力限制，勿预先承诺 2.5G 路由 |
|
||||
|
||||
---
|
||||
|
||||
## 11. 验收时「网络算正常」的样子
|
||||
|
||||
阶段 3 完成后，应同时满足：
|
||||
|
||||
1. 有线设备从 SE5420 获取正确网段地址；默认路由为对应 `.254`；DNS `.36` 可用。
|
||||
2. 互联网、端口转发、现有本地服务行为与迁线前一致（除同 VLAN 内网吞吐变快）。
|
||||
3. U6（`.6`）与 AC-Lite（`.55.5`）在 UniFi 为 Connected；Inform 未改。
|
||||
4. SE5420 管理面仅可信 LAN66 可达；默认口令已改；配置已离线备份。
|
||||
5. 端口协商速率、CRC/错误计数正常；旧交换已下电闲置。
|
||||
6. （可选强化）两台 2.5G 终端同 VLAN `iperf3` 结果入库/记笔记。
|
||||
|
||||
VLAN10 / 升级 SSID / 客人 SSID **失败或未做，不否决**本次核心升级。
|
||||
|
||||
---
|
||||
|
||||
## 12. 回滚语义
|
||||
|
||||
任一阶段失败：停止继续搬家；把刚迁的设备插回原 ER-X/旧交换端口。
|
||||
**不要**在故障中改 ER-X 的 WAN、DHCP 池、网关地址或 SSH 策略。
|
||||
后续 VLAN10 失败：只撤 SSID/VLAN 绑定，主 SSID 与 `.254` 路径保持不动。
|
||||
|
||||
---
|
||||
|
||||
## 13. 参考
|
||||
|
||||
- 实施阶段与清单：[lan-core-switch-upgrade-plan.md](lan-core-switch-upgrade-plan.md)
|
||||
- 现网地图：[lan-overview.md](lan-overview.md)
|
||||
- ER-X：[edgerouter-x-configuration.md](edgerouter-x-configuration.md)、[hosts/gw.md](../hosts/gw.md)
|
||||
- UniFi / VLAN10 前置：[unifi-network.md](unifi-network.md)
|
||||
- `gfw`：[hosts/gfw.windy.lan.md](../hosts/gfw.windy.lan.md)
|
||||
- SE5420 规格：<https://www.tp-link.com.cn/product_2899.html?v=specification>
|
||||
+19
-4
@@ -35,6 +35,11 @@ from each section below.
|
||||
│ ubnt — UniFi Network Controller (192.168.66.46)
|
||||
```
|
||||
|
||||
> **SE5420 purchased (2026-08-09):** TP-Link `TL-SE5420` acquired; deployment plan is
|
||||
> [lan-se5420-deployment-guide.md](lan-se5420-deployment-guide.md). Design/planning refs:
|
||||
> [lan-erx-se5420-network.md](lan-erx-se5420-network.md),
|
||||
> [lan-core-switch-upgrade-plan.md](lan-core-switch-upgrade-plan.md).
|
||||
|
||||
---
|
||||
|
||||
## Hosts
|
||||
@@ -42,12 +47,20 @@ from each section below.
|
||||
| Host | Role | SSH | IPv4 | Facts |
|
||||
|------|------|-----|------|-------|
|
||||
| **gw** | EdgeRouter X primary LAN gateway | `ssh -4 zhiqiang@192.168.66.254` | `192.168.66.254` | [hosts/gw.md](../hosts/gw.md) |
|
||||
| **gfw.windy.lan** | OpenWrt LAN gateway / OpenClash | `ssh -4 root@192.168.66.1` | `192.168.66.1` | [hosts/gfw.windy.lan.md](../hosts/gfw.windy.lan.md) |
|
||||
| **dns.windy.lan** | AdGuard Home LAN DNS + Mihomo explicit proxy | `ssh -4 windy@192.168.66.36` | `192.168.66.36` | [hosts/dns.windy.lan.md](../hosts/dns.windy.lan.md) |
|
||||
| **ubnt** | UniFi Network Controller | `ssh -4 windy@192.168.66.46` | `192.168.66.46` | [hosts/ubnt.md](../hosts/ubnt.md) |
|
||||
| **PVE** | Proxmox host (`.66.26`/vmbr0 · `.55.26`/vmbr1) — hosts gfw/dns/ubnt/haos VMs | `ssh -4 root@192.168.66.26` | `192.168.66.26` | — |
|
||||
| **gfw.windy.lan** | OpenWrt LAN gateway / OpenClash — **PVE VM 140** | `ssh -4 root@192.168.66.1` | `192.168.66.1` | [hosts/gfw.windy.lan.md](../hosts/gfw.windy.lan.md) |
|
||||
| **dns.windy.lan** | AdGuard Home LAN DNS + Mihomo explicit proxy — **PVE VM 120** (`pihole`) | `ssh -4 windy@192.168.66.36` | `192.168.66.36` | [hosts/dns.windy.lan.md](../hosts/dns.windy.lan.md) |
|
||||
| **ubnt** | UniFi Network Controller — **PVE VM 160** | `ssh -4 windy@192.168.66.46` | `192.168.66.46` | [hosts/ubnt.md](../hosts/ubnt.md) |
|
||||
| **haos** | Home Assistant (HAOS) — **PVE VM 180** (LAN55) | — | `192.168.55.11` | — |
|
||||
| **NAS/FreeNAS** | NAS; `transmission` jail runs here (`.51`) | — | — | — |
|
||||
| **U6 Lite** | UniFi AP (LAN66) | `ssh -4 zhiqiangf@192.168.66.6` | `192.168.66.6` | [docs/unifi-network.md](../docs/unifi-network.md) |
|
||||
| **UAP-AC-Lite** | UniFi AP (LAN55) | `ssh -4 zhiqiangf@192.168.55.5` | `192.168.55.5` | [docs/unifi-network.md](../docs/unifi-network.md) |
|
||||
|
||||
> **Positioning facts (verified 2026-08-09):** `dns`/`ubnt`/`gfw`/`haos` are all VMs on PVE
|
||||
> (no separate physical hosts); `transmission` is a FreeNAS/NAS jail. Only gw, PVE,
|
||||
> NAS, U6, UAP-AC-Lite, and wired PCs/NAS are physical SE5420 ports. See
|
||||
> [lan-se5420-deployment-guide.md](lan-se5420-deployment-guide.md) §1.
|
||||
|
||||
---
|
||||
|
||||
## gw — EdgeRouter X (LAN gateway)
|
||||
@@ -163,6 +176,8 @@ AP SSH account is `zhiqiangf` (key-only, verified). See [docs/unifi-network.md](
|
||||
- [hosts/dns.windy.lan.md](../hosts/dns.windy.lan.md) — AdGuard Home + Mihomo detail
|
||||
- [hosts/ubnt.md](../hosts/ubnt.md) — UniFi controller + proxy contract
|
||||
- [docs/unifi-network.md](../docs/unifi-network.md) — APs, inform endpoint, recovery
|
||||
- [docs/unifi-third-party-vlan10-dhcp.md](unifi-third-party-vlan10-dhcp.md) — VLAN Wi-Fi feasibility and DHCP boundary
|
||||
- [docs/unifi-openwrt-vlan10-implementation-examples.md](unifi-openwrt-vlan10-implementation-examples.md) — supported topology and examples
|
||||
- [docs/edgerouter-x-configuration.md](../docs/edgerouter-x-configuration.md) — effective gw config
|
||||
- [docs/unifi-openclash-localhost.md](../docs/unifi-openclash-localhost.md) — proxy bypass
|
||||
- [runbooks/adguard-home-health.md](../runbooks/adguard-home-health.md) — AGH health
|
||||
- [runbooks/adguard-home-health.md](../runbooks/adguard-home-health.md) — AGH health
|
||||
|
||||
@@ -0,0 +1,397 @@
|
||||
# ER-X → RB5009 网关升级：网络形态与实施计划
|
||||
|
||||
**状态：** 规划文档（未采购、未接线、未改生产配置）。
|
||||
**重要变更（2026-08-09）：** **SE5420 已采购**，网络升级改为「保留 ER-X + SE5420 核心」路径——
|
||||
实施与验证以 [lan-se5420-deployment-guide.md](lan-se5420-deployment-guide.md) 为准。
|
||||
本文保留为「ER-X 网关未来替换为 RB5009」的备选方案；其中 PVE 透传调研与 VLAN10 实现方法仍适用。
|
||||
|
||||
---
|
||||
|
||||
## 1. 一句话架构
|
||||
|
||||
```text
|
||||
公网 ← RB5009（主网关：PPPoE / NAT / 防火墙 / DHCP / IPv6 / VLAN 66+55 三层）
|
||||
↑ 全部终端 / AP / PVE 直连其 8×1G 端口
|
||||
（SFP+ 空槽，为未来 10G 核心预留）
|
||||
```
|
||||
|
||||
- **RB5009** 兼任路由与 LAN 二层交换：所有接入设备直插 RB5009 端口。
|
||||
- 客户端默认网关仍是 **`.254`**（RB5009 沿用 ER-X 地址，客户端零感知）。
|
||||
- **`gfw`** 仍为旁路由（默认网关 `.254`）；OpenClash 行为不变。
|
||||
- **ER-X 升级后下电闲置，作为已配置的备件保存**（回滚路径）。
|
||||
- 2.5G/10G 同 VLAN 交换目标**放弃**（无 SE5420）；LAN 二层为 1G。
|
||||
|
||||
---
|
||||
|
||||
## 2. 已确认的设计决策
|
||||
|
||||
| 决策 | 结论 |
|
||||
|---|---|
|
||||
| 角色 | RB5009 单机：路由 + LAN 交换 + 双 VLAN 三层 |
|
||||
| WAN | **PPPoE**，走 **`ether1`（2.5G 铜口接 ONT/光猫）**，MTU 1492 |
|
||||
| LAN 模型 | **单 bridge + VLAN 过滤**：VLAN 66（多数端口）+ VLAN 55；VLAN 10 预留 |
|
||||
| 网关地址 | **沿用 `192.168.66.254` / `192.168.55.254`**；重编址另立项目 |
|
||||
| IPv6 | **保留对等**：PPPoE 上 DHCPv6-PD `/60` + 双 LAN SLAAC `/64` + IPv6 防火墙 |
|
||||
| 端口转发 | 4 条 **原样迁入**（hass / transmission / ssh / openvpn）+ hairpin NAT |
|
||||
| LAN55 成员 | **保持现状**（AC-Lite、Aqara 及原 LAN55 设备）不迁到 VLAN66 |
|
||||
| 管理面 | SSH **仅密钥**（`zhiqiang`）；禁用默认 `admin`；**禁 Winbox/API/WebFig** 或仅限 LAN |
|
||||
| 迁移方式 | 台面预配置（临时 `.253`）→ 维护窗（30–60 分钟）→ 验证 → ER-X 留作备件 |
|
||||
| 固件/备份 | 当前稳定 RouterOS 7.x；上线前 `.backup` + 文本导出存离线 |
|
||||
| 时区/NTP | `Asia/Shanghai` + 现有 NTP 服务器 |
|
||||
| 安全 | PPPoE 口令、SSH 私钥、`zhiqiang` 口令**只存设备上**，不落本仓库 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 升级后的网络形态（拓扑图）
|
||||
|
||||
### 3.1 目标物理拓扑（升级完成后）
|
||||
|
||||
```text
|
||||
Internet
|
||||
│ PPPoE (ether1 2.5G, MTU 1492, IPv6 PD /60)
|
||||
▼
|
||||
┌──────────────────────────────────────────────┐
|
||||
│ RB5009 (gw) RouterOS 7.x │
|
||||
│ ether1 = WAN (PPPoE) │
|
||||
│ bridge + vlan-filtering=yes │
|
||||
│ vlan66 = 192.168.66.254/24 (pvid 66) │
|
||||
│ vlan55 = 192.168.55.254/24 (pvid 55) │
|
||||
│ SFP+ = 空槽（未来 10G） │
|
||||
│ SSH-only 管理（仅 LAN） │
|
||||
└─────┬─────────┬──────────┬──────────┬────────┘
|
||||
│ pvid66 │ pvid66 │ pvid66 │ pvid55
|
||||
│ │ │ │
|
||||
gfw (.1) dns (.36) ubnt (.46) UAP-AC-Lite (.55.5)
|
||||
PVE (.26) NAS/PC… U6 Lite Aqara (.55.248)
|
||||
(.66.6)
|
||||
```
|
||||
|
||||
端口角色以面板为准；下表是建议预留：
|
||||
|
||||
| RB5009 端口 | 对端 | 模式 |
|
||||
|---|---|---|
|
||||
| `ether1` | ONT/光猫 | WAN，PPPoE |
|
||||
| `ether2`–`ether8` | PVE/gfw、dns、ubnt、U6 Lite、NAS、PC、杂项 | access，pvid 66 |
|
||||
| `ether9` | 原 LAN55 成员（AC-Lite、Aqara…） | access，pvid 55 |
|
||||
| SFP+ `sfp-sfpplus1` | 未来 10G 核心 | 空槽 |
|
||||
|
||||
> **禁止双上行：** 任一设备不得同时接旧 ER-X 与 RB5009（环路 / 双默认网关）。
|
||||
|
||||
### 3.2 逻辑网络
|
||||
|
||||
| VLAN | 子网 | 网关 / DHCP | 形态 | 成员 |
|
||||
|---|---|---|---|---|
|
||||
| **66** | `192.168.66.0/24` | RB5009 `vlan66` `.254` | 多数端口 access | gfw、dns、ubnt、U6、PVE、NAS、PC… |
|
||||
| **55** | `192.168.55.0/24` | RB5009 `vlan55` `.254` | `ether9` access | AC-Lite、Aqara…（原 LAN55 全量） |
|
||||
| 10（预留） | `192.168.10.0/24` | 未来（`gfw`） | 暂不配业务 | 升级专用 SSID（后续项目） |
|
||||
|
||||
- 客户端 DNS：DHCP 仍下发 **`192.168.66.36`**（AdGuard Home）。
|
||||
- UniFi Inform 仍为 `http://192.168.66.46:9080/inform`。
|
||||
- LAN66 ↔ LAN55 互通由 RB5009 三层转发（沿用现网默认可达语义，防火墙不设隔离边界）。
|
||||
|
||||
### 3.3 流量怎么走
|
||||
|
||||
```text
|
||||
同 VLAN（NAS ↔ PC）： 客户端 → RB5009 端口 → bridge（二层交换，1G）
|
||||
跨 VLAN（66 ↔ 55）： 客户端 → RB5009 路由（vlan66 ↔ vlan55，1G）
|
||||
上网： 客户端 → RB5009 → PPPoE → Internet（限速 = 线路；RB5009 fasttrack 去掉 ER-X ~900M 天花板）
|
||||
旁路由： 默认网关仍 `.254`；显式代理走 gfw（不变）
|
||||
未来 VLAN10： U6 trunk → RB5009 →（转发 VLAN10）→ gfw（后续项目）
|
||||
```
|
||||
|
||||
### 3.4 性能预期（诚实边界）
|
||||
|
||||
| 场景 | 预期 |
|
||||
|---|---|
|
||||
| WAN / PPPoE | 线路速率以内；若线路 >1G，RB5009 fasttrack 可跑满（ER-X 受 900M 限制） |
|
||||
| 同 VLAN 交换 | **1G**（无 SE5420；RB5009 8×1G） |
|
||||
| 跨 VLAN | 1G 级三层 |
|
||||
| SFP+ 空槽 | 不等于已是 10G |
|
||||
|
||||
---
|
||||
|
||||
## 4. 分阶段实施计划
|
||||
|
||||
### 阶段 0：采购前核验
|
||||
|
||||
1. 确认 RB5009 revision、保修、零售渠道、RouterOS 当前稳定版本号（建议 7.x 最新 stable）。
|
||||
2. 确认硬件：1× 2.5G PoE-in（ether1）、8× 1G、1× SFP+、1GB RAM。SFP+ 模块本次不买。
|
||||
3. 盘点线缆与对端：ONT ↔ ether1；原 LAN55 设备清单（AC-Lite、Aqara…）及原 ER-X `switch0` 接线。
|
||||
|
||||
### 阶段 1：离线初始化（台面）
|
||||
|
||||
1. 仅电源 + 隔离管理本。设置身份、时区 `Asia/Shanghai`、NTP。
|
||||
2. 建 `zhiqiang` 管理用户（**密钥登录，禁密码**）；**删除/禁用默认 `admin`**。
|
||||
3. 建 bridge + VLAN 66/55 + 端口模板（`ether2–8` pvid66，`ether9` pvid55）；**临时地址 `.253`**（不与 ER-X `.254` 冲突）。
|
||||
4. 配 WAN PPPoE（ether1）、默认路由、NAT masquerade、4 条端口转发 + hairpin、防火墙（input/forward）、MSS clamp、IPv6 PD + SLAAC + IPv6 防火墙。
|
||||
5. 配 DHCP 池 `.38–.243`、24h 租约、DNS `.36`、UniFi Inform 选项、**静态映射全量照搬**。
|
||||
6. 管理面收口：**禁 Winbox（8291）/ API（8728）/ WebFig（80/443）**；SSH 仅限 LAN66/55。
|
||||
7. `system backup save` + `/export`，导出到离线存储（**不落仓库**）。
|
||||
|
||||
**参考 RouterOS 配置骨架**（口令/密钥用占位符；落地前逐一核对）：
|
||||
|
||||
```text
|
||||
# 身份 / 时区 / NTP
|
||||
/system identity set name=gw
|
||||
/system clock set time-zone-name=Asia/Shanghai
|
||||
|
||||
# WAN
|
||||
/interface ethernet set ether1 name=wan
|
||||
/interface pppoe-client add name=pppoe0 interface=wan user=<PPPoE_USER> \
|
||||
password=<PPPoE_PASS> add-default-route=yes use-peer-dns=no \
|
||||
mtu=1492 mru=1492
|
||||
|
||||
# bridge + VLAN
|
||||
/interface bridge add name=bridge66 vlan-filtering=yes
|
||||
/interface bridge port add bridge=bridge66 interface=ether2 pvid=66
|
||||
... # ether3..ether8 同 pvid 66
|
||||
/interface bridge port add bridge=bridge66 interface=ether9 pvid=55
|
||||
/interface bridge vlan add bridge=bridge66 vlan-ids=66 tagged=bridge66
|
||||
/interface bridge vlan add bridge=bridge66 vlan-ids=55 tagged=bridge66
|
||||
/interface vlan add name=vlan66 interface=bridge66 vlan-id=66
|
||||
/interface vlan add name=vlan55 interface=bridge66 vlan-id=55
|
||||
|
||||
# 地址（台面先用 .253，维护窗切 .254）
|
||||
/ip address add address=192.168.66.254/24 interface=vlan66
|
||||
/ip address add address=192.168.55.254/24 interface=vlan55
|
||||
|
||||
# NAT masquerade + 端口转发 + hairpin
|
||||
/ip firewall nat add chain=srcnat out-interface=pppoe0 action=masquerade
|
||||
/ip firewall nat add chain=dstnat in-interface=pppoe0 protocol=tcp dst-port=8123 \
|
||||
action=dst-nat to-addresses=192.168.55.11 to-ports=8123
|
||||
/ip firewall nat add chain=dstnat in-interface=pppoe0 protocol=tcp dst-port=51413 \
|
||||
action=dst-nat to-addresses=192.168.66.51 to-ports=51413
|
||||
/ip firewall nat add chain=dstnat in-interface=pppoe0 protocol=udp dst-port=51413 \
|
||||
action=dst-nat to-addresses=192.168.66.51 to-ports=51413
|
||||
/ip firewall nat add chain=dstnat in-interface=pppoe0 protocol=tcp dst-port=5822 \
|
||||
action=dst-nat to-addresses=192.168.66.36 to-ports=22
|
||||
/ip firewall nat add chain=dstnat in-interface=pppoe0 protocol=udp dst-port=5822 \
|
||||
action=dst-nat to-addresses=192.168.66.36 to-ports=22
|
||||
/ip firewall nat add chain=dstnat in-interface=pppoe0 protocol=tcp dst-port=1194 \
|
||||
action=dst-nat to-addresses=192.168.66.32 to-ports=1194
|
||||
/ip firewall nat add chain=dstnat in-interface=pppoe0 protocol=udp dst-port=1194 \
|
||||
action=dst-nat to-addresses=192.168.66.32 to-ports=1194
|
||||
/ip firewall nat add chain=srcnat connection-nat-state=dstnat action=masquerade # hairpin
|
||||
|
||||
# 防火墙（input / forward），顺序很重要：SSH 放行必须早于默认 drop
|
||||
/ip firewall filter add chain=input connection-state=established,related action=accept
|
||||
/ip firewall filter add chain=input connection-state=invalid action=drop
|
||||
/ip firewall filter add chain=input protocol=icmp action=accept
|
||||
/ip firewall filter add chain=input in-interface=pppoe0 action=drop comment="drop WAN in"
|
||||
/ip firewall filter add chain=input protocol=tcp dst-port=22 \
|
||||
src-address=192.168.66.0/24,192.168.55.0/24 action=accept comment="mgmt SSH"
|
||||
/ip firewall filter add chain=input action=drop comment="drop other input"
|
||||
/ip firewall filter add chain=forward connection-state=established,related action=fasttrack-connection \
|
||||
hw-offload=yes
|
||||
/ip firewall filter add chain=forward connection-state=established,related action=accept
|
||||
/ip firewall filter add chain=forward connection-state=invalid action=drop
|
||||
/ip firewall filter add chain=forward in-interface=pppoe0 action=drop comment="drop WAN fwd"
|
||||
/ip firewall filter add chain=forward action=accept comment="accept LAN fwd"
|
||||
|
||||
# MSS clamp（PPPoE MTU 1492 → 1452；ER-X 旧值 1412 偏小，验证后按标准值收敛）
|
||||
/ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn \
|
||||
tcp-mss=1400-65535 action=change-mss new-mss=1452 passthrough=yes
|
||||
|
||||
# IPv6（PD /60 + SLAAC /64）
|
||||
/ipv6 dhcp-client add interface=pppoe0 request=prefix pool-name=pd6 \
|
||||
pool-prefix-length=60 add-default-route=yes
|
||||
/ipv6 address add from-pool=pd6 interface=vlan66 address=::1 adverts=yes
|
||||
/ipv6 address add from-pool=pd6 interface=vlan55 address=::1 adverts=yes
|
||||
# /ipv6 firewall filter 参照 IPv4：established/related accept、invalid drop、
|
||||
# icmpv6 accept、pppoe0 in drop、默认 drop，forward 同构
|
||||
|
||||
# DHCP（池 / DNS / Inform / 静态映射全量照搬 ER-X）
|
||||
/ip pool add name=pool66 ranges=192.168.66.38-192.168.66.243
|
||||
/ip pool add name=pool55 ranges=192.168.55.38-192.168.55.243
|
||||
/ip dhcp-server add name=dhcp66 interface=vlan66 address-pool=pool66 lease-time=1d
|
||||
/ip dhcp-server add name=dhcp55 interface=vlan55 address-pool=pool55 lease-time=1d
|
||||
/ip dhcp-server network add address=192.168.66.0/24 gateway=192.168.66.254 \
|
||||
dns-server=192.168.66.36
|
||||
/ip dhcp-server network add address=192.168.55.0/24 gateway=192.168.55.254 \
|
||||
dns-server=192.168.66.36
|
||||
# 静态映射：从 ER-X 导出后逐条 /ip dhcp-server lease add ...
|
||||
# UniFi Inform：DHCP option 43（hex 编码为 http://192.168.66.46:9080/inform），
|
||||
# 或依赖已 adopt AP 的 set-inform；与现网 ER-X 行为保持一致。
|
||||
```
|
||||
|
||||
### 阶段 2：上台预验证（ER-X 仍在线）
|
||||
|
||||
1. 将 RB5009 `ether2` 接入现有 LAN66 网段（管理本同网段），SSH 登录 `.253`。
|
||||
2. 全配置复查：VLAN 表、防火墙规则顺序（SSH 在 drop 前）、NAT、路由、IPv6。
|
||||
3. **暂不启用 RA/DHCP**（避免与 ER-X 冲突）。预验证 `.253` 可达、SSH 密钥生效、`zhiqiang` 无密码。
|
||||
4. 确认 ER-X 当前配置**已备份并保存**（作为回滚依据；`show configuration commands` 过滤敏感行）。
|
||||
|
||||
### 阶段 3：维护窗切换（约 30–60 分钟）
|
||||
|
||||
1. 变更 RB5009 `vlan66`/`vlan55` 地址 `.253 → .254`。
|
||||
2. **下电 ER-X**（保留原接线与配置，不作任何改动）。
|
||||
3. ONT 线从 ER-X `eth4` 移到 RB5009 `ether1`。
|
||||
4. 观察 PPPoE 拨号：`/interface pppoe-client monitor pppoe0` 直至 `status=established`；确认 WAN IP 与默认路由。
|
||||
5. 验证清单（见第 5 节），全绿才算完成。
|
||||
|
||||
### 阶段 4：上线收口
|
||||
|
||||
1. 再确认管理面：禁 Winbox/API/WebFig、SSH 仅密钥、默认 `admin` 已除。
|
||||
2. 更新固件/补丁至已核定的稳定版；重新导出备份（`.backup` + 文本）存离线。
|
||||
3. ER-X 下电收纳为**已配置备件**，把其接线与角色记录到 `hosts/gw.md` 备份节。
|
||||
|
||||
### 阶段 5（后续，另立项目）
|
||||
|
||||
**时序确认：** VLAN10 升级专用 Wi-Fi 是 RB5009 上线**稳定之后**的独立项目，不并入本次维护窗。
|
||||
|
||||
- 4 条端口转发是否仍需的审计。
|
||||
- 网关重编址（`.254 → 其它`）决策。
|
||||
- **VLAN10 升级专用 SSID → `gfw`（可行性审查，2026-08-09）**。
|
||||
- 迁移后同步本仓库事实文档：`hosts/gw.md`、`docs/lan-overview.md`、`inventory/hosts.md`、`AGENTS.md` 快速地图。
|
||||
|
||||
### 阶段 5 附：VLAN10 可行性审查
|
||||
|
||||
**结论：** 换 RB5009 后**物理上可行**，但 RB5009 只解决「交换机侧」路径；PVE 宿主机到 `gfw` 虚拟机这一段（此前判定为不可行的关键缺口）仍必须单独打通。
|
||||
|
||||
**为什么今天在 AP 上做 VLAN10 会坏 66 网：**
|
||||
|
||||
U6 接的是 ER-X `eth0`（untagged access，且 ER-X 交换机 `vlan-aware` 关闭）。给 SSID 打 VLAN10 后，U6 把客户端帧打成 **802.1Q tag 10** 发往 ER-X；ER-X 端口是普通 access、不处理 tag，VLAN10 帧被当作无标记帧**漏进 66 广播域**；全网只有一个 DHCP（ER-X），VLAN10 客户端拿到 `192.168.66.x`，泄漏的广播/发现干扰 66 网。这是「无 802.1Q 传输路径」的必然结果，不是 AP 配置问题。
|
||||
|
||||
**RB5009 下实现需要 3 个前提：**
|
||||
|
||||
1. **RB5009 bridge 增加 VLAN10 转发：**
|
||||
`/interface bridge vlan add bridge=bridge66 vlan-ids=10 tagged=<U6口>,<PVE口>`
|
||||
只在这两个口 tagged。**不要**在 RB5009 上给 VLAN10 配 IP / DHCP（gfw 才是网关与唯一 DHCP）。
|
||||
2. **PVE 宿主机路径（必须做，RB5009 解决不了这一段）：**
|
||||
PVE 物理上联口透传 tagged VLAN10；`gfw` 虚拟机有一块 VLAN10 可达的网卡
|
||||
（如 vmbr0 开 `vlan_filtering` + 给 gfw 加第二块 pvid 10 的 NIC，或 VM 内 `eth0.10`）。
|
||||
这是此前「无法实现」的同一处缺口，需在 PVE/vSwitch 层单独验证。
|
||||
3. **`gfw` 侧：** VLAN10 网卡 `192.168.10.1/24` + DHCP（`192.168.10.0/24`）+ 出 66 口
|
||||
masquerade。RB5009 无需到 `192.168.10.0/24` 的路由（gfw SNAT 后源地址即 66 网段）。
|
||||
|
||||
**两个注意点：**
|
||||
|
||||
- **单 DHCP 原则：** VLAN10 上唯一 DHCP 是 gfw；RB5009 不得在 VLAN10 提供 DHCP。
|
||||
- **设计确认：** 升级 SSID 客户端走 gfw 网关后，DNS 为 gfw 的 dnsmasq→clash（7874），
|
||||
**不是** AdGuard `.36`——这是「被代理网络」的预期行为，需接受。
|
||||
|
||||
### 阶段 5 附：PVE 上 VLAN10 透传实现（调研 2026-08-09）
|
||||
|
||||
官方 wiki + 多个社区案例支持两种模型，核心原则是 **「一层只拥有一个 tag」**——要么 PVE 拥有
|
||||
access VLAN，要么 OpenWrt 拥有 trunk，**不能在同一张 NIC 上两层都做**。
|
||||
|
||||
**方案 A（推荐）：PVE 拥有 access VLAN，gfw 加第二块 virtio 网卡**
|
||||
|
||||
1. `vmbr0` 开 vlan-aware（`/etc/network/interfaces`）：
|
||||
|
||||
```text
|
||||
auto vmbr0
|
||||
iface vmbr0 inet static
|
||||
address 192.168.66.26/24
|
||||
gateway 192.168.66.254
|
||||
bridge-ports eno1
|
||||
bridge-stp off
|
||||
bridge-fd 0
|
||||
bridge-vlan-aware yes
|
||||
bridge-vids 10 # 至少含 10；常见默认 2-4094
|
||||
```
|
||||
|
||||
2. gfw VM 添加 `net1: virtio,bridge=vmbr0,tag=10`。VM 内该网卡是**无标记**接口
|
||||
（已落在 VLAN10 广播域），**不要再建同名 8021q 子接口**。
|
||||
3. 现有 `eth0`（native/untagged = VLAN66）不动，gfw 原有角色不变。
|
||||
4. PVE 物理上联口（PVE→RB5009）改为 **trunk：native 66 + tagged 10**。
|
||||
5. OpenWrt 内：新网卡 `192.168.10.1/24` + DHCP（`192.168.10.0/24`）+ 独立 firewall zone→wan masq。
|
||||
|
||||
**方案 B：OpenWrt 拥有 trunk（单 NIC 多 VLAN）**
|
||||
|
||||
- `vmbr0` vlan-aware；VM NIC **不加 tag**；trunk 原样进 VM；OpenWrt 内建 `8021q` 设备
|
||||
（`eth0.10`，x86/virtio 用 `option type '8021q'`，不要套用 DSA 教程）。物理上联 trunk。
|
||||
- 更灵活（一块网卡多 VLAN），是 router VM 的常见做法，但需要 OpenWrt 8021q 配置，
|
||||
且方案 A 对现有单网卡 gfw 改动更小。
|
||||
|
||||
**RB5009 侧配套（U6 口 + PVE 口都做成 trunk）：**
|
||||
|
||||
```text
|
||||
/interface bridge port add bridge=bridge66 interface=<U6口> pvid=66
|
||||
/interface bridge port add bridge=bridge66 interface=<PVE口> pvid=66
|
||||
/interface bridge vlan add bridge=bridge66 vlan-ids=66 tagged=bridge66 untagged=<U6口>,<PVE口>,<其余66口>
|
||||
/interface bridge vlan add bridge=bridge66 vlan-ids=55 tagged=bridge66 untagged=<ether9>
|
||||
/interface bridge vlan add bridge=bridge66 vlan-ids=10 tagged=<U6口>,<PVE口>
|
||||
```
|
||||
|
||||
VLAN10 在 RB5009 上**纯二层桥接**（U6 ↔ PVE），三层由 gfw 承担；RB5009 无 VLAN10 IP/DHCP。
|
||||
|
||||
**常见坑（社区高复发）：**
|
||||
|
||||
- **双标签：** PVE 设了 `tag=10` 又在 OpenWrt 里建 `eth1.10` → 一帧被两层改两次。
|
||||
- **native VLAN 不一致：** trunk 上无标记帧被两端当成不同 VLAN → DHCP 消失 / 拿到错网段
|
||||
（正是你之前在 AP 上打 VLAN10 坏 66 网的同类故障）。
|
||||
- **bridge 未 vlan-aware：** tagged 帧进 host 后在 bridge 过滤层消失。
|
||||
|
||||
**诊断命令：**
|
||||
|
||||
```bash
|
||||
# PVE host
|
||||
bridge vlan show
|
||||
ip -br link
|
||||
tcpdump -eni <上联口> # 帧是否到物理口
|
||||
tcpdump -eni vmtapXXXXXX # 帧是否到 VM tap
|
||||
# OpenWrt guest
|
||||
ip -d link show
|
||||
logread -e netifd
|
||||
```
|
||||
|
||||
**参考案例：**
|
||||
|
||||
- PVE 官方 wiki — Network Configuration / VLAN 802.1Q（三种模式 + vlan-aware bridge）：
|
||||
<https://pve.proxmox.com/wiki/Network_Configuration>
|
||||
- 「OpenWrt VM on Proxmox」设计（trunk vs access 谁拥有 tag、双标签坑）：
|
||||
<https://phb-crystal-ball.org/run-openwrt-in-proxmox/>
|
||||
- PVE 论坛「Tagged and Untagged VLAN」（`bridge-vlan-aware yes` + `bridge-vids` 解法）：
|
||||
<https://forum.proxmox.com/threads/tagged-and-untagged-vlan-configuration.144421/>
|
||||
- OpenWrt 论坛 guest WiFi tagged VLAN 案例（`vmbr0.3`→VM 第三网卡；guest 拿到错误网段的
|
||||
同型故障，最终归因在 PVE/host 侧）：<https://forum.openwrt.org/t/continued-x86-openwrt-proxmox-vlan-issues/182623>
|
||||
|
||||
> **PVE host 改动风险：** 给 `vmbr0` 开 vlan-aware 是对宿主机网络栈的修改，有管理面断连风险；
|
||||
> 需在维护窗内用控制台/独立带外通道进行，先 `ifreload -a`（PVE7+ 的 ifupdown2 支持热应用），
|
||||
> 保留原配置作回滚。
|
||||
|
||||
---
|
||||
|
||||
## 5. 验收清单（「网络算正常」的样子）
|
||||
|
||||
1. 管理面：`zhiqiang` 密钥 SSH 可从 LAN66/55 登录；默认 `admin` 禁用；Winbox/API 不可达；`.254` 管理可达。
|
||||
2. VLAN：客户端取得正确网段（`.66.x` / `.55.x`），默认网关 `.254`，DNS `.36` 可用。
|
||||
3. 互联网：PPPoE 已建立；IPv4 外网通；端口转发逐条从公网验证（hass 8123、transmission 51413、ssh 5822→.36:22、openvpn 1194）。
|
||||
4. IPv6：两 VLAN 拿到 SLAAC `/64`，默认路由存在，外部 IPv6 可达；IPv6 防火墙未阻断必要 ICMPv6/DHCPv6。
|
||||
5. 本地服务：跨 VLAN（`.55.x` ↔ `.66.x`）互通；AdGuard Home、UniFi 控制器、`gfw` 旁路由行为与升级前一致。
|
||||
6. UniFi：U6 Lite（`.66.6`）与 UAP-AC-Lite（`.55.5`）在控制器显示 **Connected**；Inform 未变 `:9080`。
|
||||
7. 无环路、无双默认网关；端口协商与错误计数正常。
|
||||
8. 备份（`.backup` + 文本导出）已离线保存；ER-X 已下电收纳。
|
||||
|
||||
---
|
||||
|
||||
## 6. 回滚语义
|
||||
|
||||
任一阶段失败：**停手**。
|
||||
|
||||
- **维护窗内失败（PPPoE 未起 / 客户端不通 / 防火墙锁死）：**
|
||||
1. 下电 RB5009。
|
||||
2. ONT 线插回 ER-X `eth4`。
|
||||
3. 给 ER-X 上电 → 服务在数分钟内恢复。
|
||||
4. 不要在故障中改 ER-X 的 WAN、DHCP、网关地址或 SSH 策略。
|
||||
- **维护窗成功后** ER-X 只是备件；后续 VLAN10 失败只撤 SSID/VLAN 绑定，主 SSID 与 `.254` 路径不动。
|
||||
|
||||
---
|
||||
|
||||
## 7. 安全与记录
|
||||
|
||||
- **本仓库永不记录**：PPPoE 口令、`zhiqiang` 口令、SSH 私钥、RouterOS 备份（含口令/密钥）。
|
||||
- 每次实质性变更（切换、回滚、加固）完成后，在 Linear **`vps` 项目**记录 scope / action / verification / 遗留 follow-up（本次先不建 issue，待执行时补）。
|
||||
- SSH 与访问策略变更遵循仓库「SSH access safety」流程：ER-X 会话保持为回滚路径，新密钥登录验证成功前不关闭旧通道。
|
||||
|
||||
---
|
||||
|
||||
## 8. 参考
|
||||
|
||||
- 现网地图：[lan-overview.md](lan-overview.md)
|
||||
- ER-X 现状：[edgerouter-x-configuration.md](edgerouter-x-configuration.md)、[hosts/gw.md](../hosts/gw.md)
|
||||
- UniFi：[unifi-network.md](unifi-network.md)、[hosts/ubnt.md](../hosts/ubnt.md)
|
||||
- `gfw`：[hosts/gfw.windy.lan.md](../hosts/gfw.windy.lan.md)
|
||||
- 作废方案（**不再实施**）：[lan-erx-se5420-network.md](lan-erx-se5420-network.md)、[lan-core-switch-upgrade-plan.md](lan-core-switch-upgrade-plan.md)
|
||||
- MikroTik RB5009 官方：<https://mikrotik.com/product/rb5009ug_s_in>、RouterOS v7 手册
|
||||
@@ -0,0 +1,401 @@
|
||||
# SE5420 核心交换机升级实践指南（两步实施）
|
||||
|
||||
**状态：** SE5420 **已采购**，待实施。本文是真实可操作、可验证的升级实践文档；
|
||||
取代早期「规划说明」性质文档中的实施细节（[lan-erx-se5420-network.md](lan-erx-se5420-network.md)、
|
||||
[lan-core-switch-upgrade-plan.md](lan-core-switch-upgrade-plan.md) 保留作拓扑/设计参考）。
|
||||
|
||||
**硬件：** TP-Link **TL-SE5420**（16× 2.5G RJ45 + 4× 10G SFP+，无 PoE），440×180×44 mm（1U）。
|
||||
**架构：** ER-X **保留**为唯一网关（PPPoE/NAT/防火墙/DHCP/双网段三层）；SE5420 纯 L2 核心；
|
||||
`gfw` 旁路由（OpenClash）；VLAN10 升级专用 SSID 走 gfw 网关。
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 两步实施总览（2026-08-09 确认）
|
||||
|
||||
**第一步（本次）：只做 55/66 主网。** SE5420 初始化、ER-X 上联、PVE/AP/设备迁移、
|
||||
验收稳定。**全程不建 VLAN10、不给口 2/3 加 tagged 10、不改 gfw、不改 UniFi `ubnt-upg`。**
|
||||
|
||||
**第二步（第一步稳定 ≥1 天后，独立窗口）：整体做 VLAN10。**
|
||||
SE5420 加 VLAN10 + 口 2/3 tagged 10 → gfw 补齐 → UniFi 改 Third-party Gateway → 启用 SSID → 验证。
|
||||
|
||||
> 分离原则：**第一步与第二步不共享任何配置动作**，第一步完成后网络与升级前
|
||||
> 语义一致（仅同 VLAN 交换变 2.5G）；VLAN10 全部动作集中在第二步，回滚互不牵连。
|
||||
|
||||
| 步骤 | 范围 | Done 判定 |
|
||||
|---|---|---|
|
||||
| **第一步** | SE5420 台面配置(66/55) → ER-X 上联 → 迁移 → 稳定 | 第 7 节验收前 7 条全绿 |
|
||||
| **第二步** | VLAN10（SE5420 + gfw + UniFi + SSID） | 第 7 节第 8 条 + 验证链全通 |
|
||||
|
||||
---
|
||||
|
||||
## 0. 已验证的现状事实（2026-08-09 只读核实）
|
||||
|
||||
> 以下事实已通过 SSH/UniFi API 实测确认，直接决定下文步骤：
|
||||
|
||||
| 项 | 实测结果 |
|
||||
|---|---|
|
||||
| PVE 物理网卡 | **双网卡**：`enp1s0`→vmbr0(LAN66 .26)，`enp2s0`→vmbr1(LAN55 .26) |
|
||||
| PVE bridge | `vmbr0` **非 vlan-aware（flat bridge）** → **天然透传 tagged 帧**给所有 VM（含 gfw eth0） |
|
||||
| PVE VM 清单 | 120 `pihole`=**dns/.36**（AdGuard+Mihomo，vmbr0）、140 `gfw`(vmbr0+vmbr1)、160 `ubnt`(vmbr0)、180 `haos`(vmbr1/LAN55)、100 `gateway`(停) |
|
||||
| **dns 位置** | **dns（`.36`）是 PVE 上 VM 120，非独立物理机** → 不占 SE5420 口 |
|
||||
| **transmission 位置** | **transmission 是 NAS(FreeNAS) 内 jail（`.51`）** → 不占 SE5420 口 |
|
||||
| gfw 虚拟网卡 | `net0`→vmbr0(66)、`net1`→vmbr1(55) |
|
||||
| gfw 内部 | `eth0.10`=192.168.10.1/24 已配；DHCP(100-250)已配；fw4 `ubunt_upg` 链全建；OpenClash 全局 TPROXY 在 |
|
||||
| gfw 缺口 | **无 `ubunt_upg→wan` 转发、无 masq**；zone `forward=REJECT` → VLAN10 现在上不了网（**第二步才补**） |
|
||||
| UniFi | `ubnt-upg` 网络(VLAN10, dhcp 关) + `ubnt-upg` SSID 已存在，**且 SSID 当前 enabled（泄漏风险！）**；网络 purpose=corporate，需改 Third-party Gateway（**第二步才改**） |
|
||||
| U6 Lite | `.66.6`，有线上联，接 ER-X eth0（untagged access） |
|
||||
| UAP-AC-Lite | `.55.5`，有线上联 |
|
||||
| PVE 防火墙 | 无任何自定义规则，未拦 tagged 帧 |
|
||||
|
||||
---
|
||||
|
||||
# 第一步：SE5420 + 55/66 主网
|
||||
|
||||
## 1. 目标拓扑与端口规划（第一步范围）
|
||||
|
||||
```text
|
||||
Internet
|
||||
│ PPPoE (pppoe0)
|
||||
▼
|
||||
┌───────────────────────────────────────────┐
|
||||
│ ER-X (gw) eth0=LAN66 .254 switch0=LAN55 .254 │
|
||||
└──────┬──────────────────┬─────────────────┘
|
||||
│ access VLAN66 │ access VLAN55
|
||||
│ │
|
||||
▼ ▼
|
||||
┌──────────────────────────────────────────────────┐
|
||||
│ TL-SE5420 核心（纯 L2，VLAN-aware） │
|
||||
│ SFP+ 空槽（未来 10G） │
|
||||
└─┬──────┬───────┬──────┬──────┬──────┬───────────┘
|
||||
│ │ │ │ │ │
|
||||
PVE PVE U6 AC-Lite dns/NAS/PC
|
||||
enp1s0 enp2s0 Lite (55) (access 66)
|
||||
access access access
|
||||
66 55 66
|
||||
```
|
||||
|
||||
### 端口角色表（第一步：全部为 66/55 access；**不含 VLAN10**）
|
||||
|
||||
SE5420 前面板为 **8 口一排、共两排**（每排 8×RJ45，右侧 4×SFP+）。采用**按 VLAN 分排**：
|
||||
**上排（口 1–8）= LAN66**，**下排（口 9–16）= LAN55**。每排首位是该 VLAN 的 ER-X 上联。
|
||||
|
||||
> 端口编号假定 TP-Link 常规布局（上排 1–8、下排 9–16）；**接线前先对照实物面板标注编号**。
|
||||
|
||||
| SE5420 口 | 对端 | 第一步模式 | PVID | 成员 VLAN |
|
||||
|---|---|---|---|---|
|
||||
| **上排 1** | ER-X `eth0`（66 上联） | access | 66 | untagged 66 |
|
||||
| 2 | PVE `enp1s0`（承载 gfw/dns/ubnt VM） | access | 66 | untagged 66 |
|
||||
| 3 | U6 Lite | access | 66 | untagged 66 |
|
||||
| 4 | NAS/FreeNAS（第 1 口，含 transmission jail） | access | 66 | untagged 66 |
|
||||
| 5 | NAS/FreeNAS（第 2 口，LACP 预留） | access | 66 | untagged 66 |
|
||||
| 6 | windy-pc (.99) / hp-nas (.32) | access | 66 | untagged 66 |
|
||||
| 7–8 | LAN66 预留 | access | 66 | untagged 66 |
|
||||
| **下排 9** | ER-X `switch0` 成员口（55 上联） | access | 55 | untagged 55 |
|
||||
| 10 | PVE `enp2s0`（承载 haos VM） | access | 55 | untagged 55 |
|
||||
| 11 | UAP-AC-Lite | access | 55 | untagged 55 |
|
||||
| 12 | 隔壁房间上联（IoT 设备） | access | 55 | untagged 55 |
|
||||
| 13 | 打印机（未来） | access | 55 | untagged 55 |
|
||||
| 14–16 | LAN55 预留 | access | 55 | untagged 55 |
|
||||
| SFP+ 1–4 | 未来 10G | 空槽 | — | — |
|
||||
|
||||
> **第二步才变更（本步不动）**：口 2、口 3 从 access 66 改为 **trunk（untagged 66 + tagged 10）**，
|
||||
> 并新建 VLAN10。第一步**不要**建 VLAN10、**不要**在任何口上 tagged 10。
|
||||
|
||||
> **哪些设备不占 SE5420 口（都是 PVE 上的 VM，走 PVE 物理网卡）：**
|
||||
> - **dns / AdGuard Home / Mihomo（`.36`）** = PVE VM 120 `pihole`（vmbr0）
|
||||
> - **ubnt 控制器（`.46`）** = PVE VM 160（vmbr0）
|
||||
> - **gfw（`.1`）** = PVE VM 140（vmbr0 + vmbr1）
|
||||
> - **haos / Home Assistant（`.55.11`）** = PVE VM 180（vmbr1/LAN55）
|
||||
> - **transmission（`.51`）** = NAS(FreeNAS) 内 jail，走 NAS 网口
|
||||
|
||||
> **第一步关键约束：**
|
||||
> - 全部口为 66/55 access；**不建 VLAN10**。
|
||||
> - **不要**向 ER-X 送任何 VLAN10 tag（本步根本没有 VLAN10）。
|
||||
> - NAS 若启用 **LACP 聚合**：口 4/5 建端口聚合组（802.3ad），PVID 66；SE5420 需 `L2 → LAG` 配置。
|
||||
> - 禁止同一设备同时接旧路径与新核心（环路）。
|
||||
|
||||
---
|
||||
|
||||
## 2. 第一步·阶段 0：开工前检查（一次性）
|
||||
|
||||
1. SE5420 开箱：核对型号、前面板（模式切换按键 / 指示灯 / **Type-C Console 口** / 16×2.5G RJ45 / 4×SFP+ / 1×USB）。
|
||||
2. **固件**：下载最新官方固件并升级（V1.0 平台）。操作：
|
||||
- 下载页：TP-LINK 官网 → TL-SE5420 产品页 → **资源下载** tab → **升级软件** 分类。
|
||||
- 直达：`https://www.tp-link.com.cn/product_2899.html?v=download`（升级软件区）。
|
||||
- 已知版本：**TL-SE5420 V1.0 升级软件 20230908_1.0.0**（2023-09-08 发布，以页面当前列出的为准）。
|
||||
- 升级入口：登录 WEB 后 **系统 → 软件升级 → 选择文件 → 升级**（升级期间勿断电）。
|
||||
- 注意核对设备底部标签的 **硬件版本 V1.0** 与固件配套；V1.x 别刷 V2 版（若后续出现）。
|
||||
- 升级完确认版本号，再进入后续配置。
|
||||
3. 准备一条 Type-C 串口线（Console 本地登录）或普通网线（WEB 登录）；一台**隔离管理本**（不用接现有 66 网）。
|
||||
4. **禁用 `ubnt-upg` SSID**（UniFi 控制台 → WiFi → `ubnt-upg` → 关 enable）。它在无路径状态下已经泄漏 tag10 到 66 网，先止血。记录 SSID 原设置以便第二步回滚。
|
||||
> 这是**唯一**在第一步就涉及 VLAN10 的动作——目的只是止血，与第二步的实施无关。
|
||||
5. 备份当前 ER-X 配置（过滤敏感行），并给 `hosts/gw.md`、`docs/lan-overview.md` 留改前快照。
|
||||
|
||||
---
|
||||
|
||||
## 3. 第一步·阶段 1：离线初始化 SE5420（台面，不接生产）
|
||||
|
||||
> 本阶段细节来自官方《TL-SE5420 安装手册》V1.0（2023）与 Omada 官方 VLAN 配置指南。
|
||||
|
||||
### 3.1 首次登录
|
||||
|
||||
**WEB 登录（推荐，无需串口驱动）：**
|
||||
1. 管理本网线接 SE5420 **任意 RJ45 业务口**；管理本静态 IP 设为 `10.18.18.10/24`，网关暂留空。
|
||||
> **默认业务口 IP 是 `10.18.18.251`**（非 192.168.0.1，勿凭家用路由经验）。
|
||||
2. 浏览器访问 `http://10.18.18.251`。
|
||||
3. 首次登录行为：
|
||||
- **WEB**：要求**设置用户名和密码**（出厂无默认口令，直接创建），创建后进入管理界面。
|
||||
- **Console/Telnet/SSH**：官方《Accessing the Switch》指出默认账号为 **`admin/admin`**（首次登录后立即改密）。
|
||||
> 渠道默认值可能不同，以实物为准：若 WEB 已设口令，CLI 用它登录；若尚未设置，尝试 `admin/admin`。
|
||||
|
||||
**Console 本地登录（可选，WEB 不可用时兜底）：**
|
||||
1. 电脑装「TP-LINK USB 串口驱动程序」（官网下载或随机光盘）。
|
||||
2. 终端仿真程序参数：**波特率 38400**、数据位 8、校验无、停止位 1、流控无。
|
||||
3. 回车出现 `TL-SE5420>` 提示符即登录成功；输入 `enable` 进特权模式。
|
||||
|
||||
### 3.2 基础安全设置
|
||||
1. 改强口令（不落仓库）；设时区 `Asia/Shanghai`、NTP。
|
||||
2. **关 Telnet/HTTP**；保留 HTTPS + SSH：
|
||||
- 关 Telnet：GUI `Security → Access Security → Telnet Config`，关闭 Telnet；或 CLI `telnet disable`。
|
||||
- 关 HTTP：`Security → Access Security → HTTP Config`，关闭 HTTP server。
|
||||
- 开 SSH：`Security → Access Security → SSH Config`，Enable SSH（默认端口 22）。
|
||||
3. **关云管理**（商云 `smbcloud.tp-link.com.cn` 全局开关不开启；云管后续单独评估）。
|
||||
4. **保存配置**——安装手册强调「配置实时生效，但断电前必须点保存配置」，每次改完都点保存。
|
||||
|
||||
### 3.2b SSH 登录 SE5420（覆盖确认）
|
||||
|
||||
> 参考官方《Accessing the Switch》与《OpenSSH 7.0+ 登录》指南。SSH 默认端口 **22**，
|
||||
> 两种认证：口令模式（默认 `admin/admin`，改后为自定义口令）、密钥模式（PuTTY Key Generator 生成）。
|
||||
|
||||
**在 WSL/管理本上 SSH 登录：**
|
||||
```bash
|
||||
ssh -o KexAlgorithms=+diffie-hellman-group1-sha1 \
|
||||
-o HostKeyAlgorithms=+ssh-rsa,ssh-dss \
|
||||
admin@192.168.66.253
|
||||
# 输入口令后进 User EXEC 模式，再输入 enable 进特权模式
|
||||
```
|
||||
|
||||
> ⚠️ **OpenSSH 7.0+ 兼容性（官方指南）**：TP-Link 交换机旧算法默认被新版 OpenSSH 禁用，
|
||||
> 需在客户端 `~/.ssh/config` 为 `192.168.66.253` 显式启用：
|
||||
> ```text
|
||||
> Host 192.168.66.253
|
||||
> KexAlgorithms +diffie-hellman-group1-sha1
|
||||
> HostKeyAlgorithms +ssh-rsa
|
||||
> PubkeyAcceptedAlgorithms +ssh-rsa
|
||||
> ```
|
||||
> 若 `ssh` 仍报算法协商失败，用 `-o` 逐项追加；具体以本机 OpenSSH 版本提示为准。
|
||||
|
||||
**关 SSH（如不需 CLI 远程管理）**：GUI `SSH Config` 关闭，或 CLI `no ip ssh server`。
|
||||
|
||||
**保存（CLI）**：`copy running-config startup-config`。
|
||||
|
||||
### 3.3 管理地址与 VLAN（第一步：只建 66/55）
|
||||
|
||||
> 菜单路径来自 TP-Link 官方《Omada 802.1Q VLAN 配置指南》与《管理 VLAN 指南》（SE5420 同平台）。
|
||||
> 具体菜单名以设备 WEB 界面为准。**本步不建 VLAN10。**
|
||||
|
||||
**1. 管理地址**（官方：`L3 FEATURES → Interface`，编辑 VLAN 接口的 IPv4；不是 System）：
|
||||
- 改为静态 **`192.168.66.253/24`**，网关 **`192.168.66.254`**（池外地址，无冲突）。
|
||||
- 默认网关（官方：`L3 FEATURES → Static Routing → IPv4 Static Routing Config`）：
|
||||
目的 `0.0.0.0`、掩码 `0.0.0.0`、下一跳 `192.168.66.254`、距离 `1`。
|
||||
- **管理 VLAN 限制**（官方指南）：`Security → Access Security → Access Control` 建 IP 规则，
|
||||
接口 HTTP/HTTPS，源 `192.168.66.0/24`——仅管理 VLAN 内主机可访问 GUI。
|
||||
- ⚠️ 改完管理地址后，管理本网卡要改回 `192.168.66.x` 同网段（或 DHCP）才能继续登录。
|
||||
|
||||
**2. 建立 VLAN**（`L2 Features → VLAN → 802.1Q VLAN → VLAN Config`，**只建 66 / 55**）：
|
||||
- 每个 VLAN 页内把端口按「tagged / untagged」勾选进成员：
|
||||
- **66**：untagged 口 1、2、3、4、5、6、7、8（本步全为 access）
|
||||
- **55**：untagged 口 9、10、11、12、13、14、15、16
|
||||
|
||||
**3. 端口 PVID**（`L2 Features → VLAN → 802.1Q VLAN → Port Config`，逐口设 PVID）：
|
||||
- 口 1–8：PVID **66**（access）
|
||||
- 口 9–16：PVID **55**（access）
|
||||
- 逐口核对 tagged/untagged 归属，避免漏配。
|
||||
|
||||
**4. 关闭一切 L3 能力**：不开三层接口/SVI、不配静态路由、不开 DHCP Server/Relay；SE5420 只做二层。
|
||||
|
||||
**5. 生成树**（`L2 Features → Spanning Tree`）：启用 RSTP（或 MSTP），STP 优先级设低（如 4096）——即便拓扑无环也兜底。
|
||||
|
||||
**6. 保存配置**：改完立即保存（`System → Save Config` 或右上角保存按钮），否则断电丢失。
|
||||
|
||||
**7. 导出配置备份**（离线保存，**不进本仓库**）。
|
||||
|
||||
### 3.4 台面验证（未接生产）
|
||||
1. 管理本接上排任意口（access 66）：应能访问 `192.168.66.253`，且仅限 66 网段。
|
||||
2. 查看端口状态全 up；确认口 1–8 PVID=66、口 9–16 PVID=55（`show vlan` / 对应 CLI）。
|
||||
3. 确认**没有** VLAN10（本步应无 VLAN10 表项）。
|
||||
|
||||
---
|
||||
|
||||
## 4. 第一步·阶段 2：维护窗迁移（30–60 分钟）
|
||||
|
||||
> 原则：**先断旧、后接新**；每次移动一根线后立即验证；全程保留 ER-X 管理会话与 PVE 会话。
|
||||
> **本步所有口都是 66/55 access，不涉及 VLAN10。**
|
||||
|
||||
### 4.0 准备
|
||||
- 打印第 1 节端口表；给所有现网线缆贴标签。
|
||||
- 保留现有 ER-X 原接线不动（作为回滚路径）**直到最后一步**。
|
||||
- 通知中断窗口；确认 ER-X 管理 SSH 与 PVE 管理 SSH 两个会话均可用（`BatchMode=yes` 测试）。
|
||||
|
||||
### 4.1 建立 ER-X ↔ SE5420 两条上联
|
||||
1. 接 SE5420 **上排口 1 ↔ ER-X `eth0`**（LAN66 上联）。
|
||||
- 此刻 ER-X eth0 可能还连着旧设备 → **先拔旧设备**，再接口 1（避免 eth0 同时连 SE5420 与旧路径形成环路）。
|
||||
- 验证：管理本（或从 66 网）ping `192.168.66.253`（SE5420）、`192.168.66.254`（ER-X）、外网。
|
||||
2. 接 SE5420 **下排口 9 ↔ ER-X `switch0` 某个成员口**（LAN55 上联）。
|
||||
- 同样先拔该口旧接线。
|
||||
- 验证：从 55 网 ping `192.168.55.254`、`192.168.66.46`（控制器）。
|
||||
|
||||
### 4.2 迁移 PVE（双网卡）
|
||||
1. PVE `enp1s0` → SE5420 **口 2（access 66）**。
|
||||
2. PVE `enp2s0` → SE5420 **口 10（access 55）**。
|
||||
3. 验证（SSH PVE）：`ip -br addr` 显示 `.66.26`、`.55.26`；`ping 192.168.66.254`；`ping 192.168.55.254`。
|
||||
4. 确认 gfw VM 两块网卡都活着：SSH gfw → `ip -br addr` → eth0(.66.1)、eth1(55)。
|
||||
|
||||
> PVE 是宿主，**只要 PVE 活着，gfw/dns/ubnt 虚拟机就不会断**；这是迁移 PVE 放在最先的原因。
|
||||
|
||||
### 4.3 迁移 AP 与接入设备
|
||||
1. U6 Lite → SE5420 **口 3（access 66）**。本地取电，网线只走数据。
|
||||
- 验证：U6 拿到 `.66.6`，UniFi 控制器显示 Connected；Inform 仍 `:9080`。
|
||||
2. UAP-AC-Lite → SE5420 **口 11（access 55）**。
|
||||
- 验证：`.55.5` Connected。
|
||||
3. **隔壁房间上联 → SE5420 口 12（access 55）**。
|
||||
- 对端是 **IoT 设备**（未来会有打印机）。迁移前确认那端是单台设备还是小交换机；若对端已是一台设备，直接拔 ER-X switch0 旧口、接口 12 即可。
|
||||
- 验证：隔壁房间 IoT 设备恢复地址（LAN55 网段）、网关 `.254`、可达 DNS `.36`。
|
||||
4. NAS/FreeNAS（含 transmission jail）→ **口 4/5**；windy-pc/hp-nas/杂项 → **口 6**（均为 access 66），逐个验证地址/DNS/业务。
|
||||
- dns/.36、ubnt/.46、gfw/.1、haos 均随 PVE 网卡迁移，**不单独插口**——只验证 PVE 后这些 VM 的 IP 与业务即可。
|
||||
5. **旧交换/旧接线全部下电**；确认无任何设备仍走 ER-X 直连旧口（双上行=环路）。
|
||||
|
||||
### 4.4 全局验证（第一步 Done 判定）
|
||||
见第 7 节验收清单前 7 条全绿。**VLAN10 完全不在本步范围。**
|
||||
|
||||
---
|
||||
|
||||
# 第二步：VLAN10 升级专用 SSID（第一步稳定 ≥1 天后，独立窗口）
|
||||
|
||||
> **时机确认（2026-08-09）：** 第一步验收前 7 条全绿、网络稳定运行 ≥1 天后，再进入本步。
|
||||
> 本步所有动作（SE5420 VLAN10、gfw、UniFi）互相独立但按序执行，任一步失败可单独回滚。
|
||||
|
||||
## 5. 第二步·阶段 1：SE5420 增加 VLAN10
|
||||
|
||||
1. **建 VLAN10**（`L2 Features → VLAN → 802.1Q VLAN → VLAN Config`）：
|
||||
- **10**：**tagged 口 2、口 3**（只这两个，其余口不放）。
|
||||
2. **口 2、口 3 改为 trunk**（`VLAN → Port Config`）：
|
||||
- 口 2（PVE enp1s0）：PVID **66**，untagged 66 + **tagged 10**。
|
||||
- 口 3（U6）：PVID **66**，untagged 66 + **tagged 10**。
|
||||
- 其余口不动（保持第一步的 66/55 access）。
|
||||
3. **保存配置**（`System → Save Config`）。
|
||||
4. **验证**：`show vlan` 确认 VLAN10 仅 tagged 口 2/3；口 2/3 的 66 流量不受影响（66 上联仍通）。
|
||||
> 此时 VLAN10 无任何客户端流量（SSID 未启用），配置就位但无害。
|
||||
|
||||
## 6. 第二步·阶段 2：gfw 补齐 VLAN10 上网能力（SSH `root@192.168.66.1`）
|
||||
|
||||
```sh
|
||||
# 1) ubunt_upg zone 加 masq + 允许 forward
|
||||
uci set firewall.ubunt_upg.masq='1'
|
||||
uci set firewall.ubunt_upg.forward='ACCEPT'
|
||||
uci set firewall.ubunt_upg.forward_policy='ACCEPT' # 若 fw4 版本支持
|
||||
# 2) 增加 ubunt_upg -> wan 转发
|
||||
uci add firewall forwarding
|
||||
uci set firewall.@forwarding[-1].src='ubunt_upg'
|
||||
uci set firewall.@forwarding[-1].dest='wan'
|
||||
uci commit firewall
|
||||
/etc/init.d/firewall reload
|
||||
# 3) 确认 DHCP 已绑定（应已存在，无则补）
|
||||
uci show dhcp.ubunt_upg # interface='ubunt_upg', start=100, limit=150
|
||||
```
|
||||
|
||||
> **为什么必须 masq**：VLAN10 客户端源地址 `192.168.10.x` 经 gfw 出 eth0 到 ER-X 后，
|
||||
> 若无 masq，ER-X 无法把公网回包路由回 `192.168.10.0/24`。masq 后源地址变成 66 网段。
|
||||
|
||||
**验证（gfw 自测，纯本地无副作用）：**
|
||||
```sh
|
||||
nft list chain inet fw4 forward_ubunt_upg # 应有 jump accept_to_wan / wan 处理
|
||||
uci show firewall | grep -A2 ubunt_upg_to_wan
|
||||
# 确认 eth0.10 能 ping 通自身（接口 up）
|
||||
ping -c1 192.168.10.1
|
||||
```
|
||||
|
||||
## 7. 第二步·阶段 3：UniFi 改网络 + 启用 SSID
|
||||
|
||||
1. **UniFi → Networks → `ubnt-upg`**：
|
||||
- 网络类型/路由器设为 **Third-party Gateway**（或 equivalent，视 9.5.21 UI），**DHCP 保持关闭**；
|
||||
- VLAN ID `10`、子网 `192.168.10.0/24`、网关 `192.168.10.1`；
|
||||
- **广播范围只选 U6 Lite**（勿让 UAP-AC-Lite 广播，它在 LAN55 无 VLAN10 通道）。
|
||||
2. **UniFi → WiFi → `ubnt-upg` enable**（广播范围仅 U6 Lite）。
|
||||
3. **验证链（必须逐级）：**
|
||||
- a. gfw：`tcpdump -eni eth0.10` 观察——应看到来自新 SSID 客户端的 DHCP/数据帧
|
||||
（`tcpdump` 若缺用 `apk add tcpdump` / `opkg update && opkg install tcpdump`）。
|
||||
- b. 客户端连 `ubnt-upg` → 应获 `192.168.10.100~250`，网关 `192.168.10.1`，DNS 为 gfw(clash)。
|
||||
- c. gfw：`cat /tmp/dhcp.leases | grep 192.168.10` 出现客户端租约。
|
||||
- d. gfw：`nft list chain inet fw4 dstnat | grep -A1 "7892"` 计数增长 → 证明被 OpenClash 接管。
|
||||
- e. 客户端能访问外网，且**不能**访问 LAN66（`Block-ubunt-upg-to-LAN66` 规则预期生效）。
|
||||
4. 失败处理：只撤 SSID（enable off），不动主 SSID 与 `.254` 路径。
|
||||
|
||||
---
|
||||
|
||||
## 8. 回滚语义
|
||||
|
||||
| 步骤/阶段 | 失败动作 |
|
||||
|---|---|
|
||||
| 第一步·阶段 1 | 无生产影响；还原 SE5420 台面配置或出厂即可 |
|
||||
| 第一步·阶段 2（维护窗内） | **停手**；把刚迁的线插回 ER-X 原口；不动 ER-X WAN/DHCP/SSH |
|
||||
| 第二步·阶段 1（SE5420 VLAN10） | 删 VLAN10、口 2/3 恢复 access 66 |
|
||||
| 第二步·阶段 2（gfw） | 撤 `ubunt_upg` 的 masq/forwarding，恢复原 zone |
|
||||
| 第二步·阶段 3（SSID） | 只关 `ubnt-upg` SSID；主 SSID、`.254`、gfw 66 路径不受影响 |
|
||||
|
||||
### SE5420 恢复出厂（忘记口令 / 需要重配）
|
||||
|
||||
> 官方《安装手册》附录 A「问题1」方法（**需 Console 串口**）：
|
||||
|
||||
1. 管理本连 SE5420 **Type-C Console 口**（波特率 38400，8N1，无流控）。
|
||||
2. 交换机断电重启；终端出现 **`Press CTRL-B to enter the bootUtil`** 时同时按 `Ctrl+B` 进 bootUtil 菜单。
|
||||
3. 输入 `2`（软件复位），复位后恢复出厂默认；此后首次 WEB 登录为创建新用户名/密码（初始管理 IP 恢复 `10.18.18.251`）。
|
||||
4. 恢复后按第一步·阶段 1 重配，并**重新保存配置**。
|
||||
|
||||
---
|
||||
|
||||
## 9. 验收清单（「网络算正常」的样子）
|
||||
|
||||
**第一步 Done（前 7 条全绿）：**
|
||||
1. SE5420 管理面：`192.168.66.253` 仅 LAN66 可达；默认口令已改；配置已离线备份。
|
||||
2. LAN66：客户端 DHCP 拿 `.66.x`、网关 `.254`、DNS `.36`；外网通。
|
||||
3. LAN55：客户端拿 `.55.x`、网关 `.254`、DNS `.36`；跨网段互通（`.55.x ↔ .66.x`）。
|
||||
4. 端口转发逐条从公网验证（hass 8123 / transmission 51413 / ssh 5822→.36:22 / openvpn 1194）。
|
||||
5. UniFi：U6(`.66.6`) 与 AC-Lite(`.55.5`) Connected；Inform `:9080` 未变。
|
||||
6. 无环路、无双默认网关；端口协商与错误计数正常；旧交换已下电。
|
||||
7. `gfw` 旁路由行为与升级前一致（主网默认网关仍 `.254`）。
|
||||
|
||||
**第二步额外（第 8 条）：**
|
||||
8. `ubnt-upg` 客户端 `192.168.10.x`、网关 `.10.1`、可上网、不可达 LAN66；gfw 侧 DHCP 租约与 OpenClash 计数可查。
|
||||
|
||||
**贯穿：**
|
||||
9. IPv6 行为与升级前一致（SE5420 纯二层不碰 IPv6）。
|
||||
|
||||
---
|
||||
|
||||
## 10. 安全与记录
|
||||
|
||||
- **本仓库永不记录**：SE5420 口令、ER-X 配置快照（含 PPPoE/口令）、gfw 凭据。
|
||||
- 每次实质变更后，在 Linear `vps` 项目记录 scope / action / verification / 遗留 follow-up。
|
||||
- SE5420 配置备份离线保存；不做云管。
|
||||
- SSH/访问策略变更遵循仓库「SSH access safety」流程。
|
||||
|
||||
---
|
||||
|
||||
## 11. 参考
|
||||
|
||||
- 设计说明：[lan-erx-se5420-network.md](lan-erx-se5420-network.md)
|
||||
- 早期阶段计划（已细化于本文）：[lan-core-switch-upgrade-plan.md](lan-core-switch-upgrade-plan.md)
|
||||
- 现网地图：[lan-overview.md](lan-overview.md)
|
||||
- ER-X：[edgerouter-x-configuration.md](edgerouter-x-configuration.md)、[hosts/gw.md](../hosts/gw.md)
|
||||
- UniFi / VLAN10 前置：[unifi-network.md](unifi-network.md)、[unifi-third-party-vlan10-dhcp.md](unifi-third-party-vlan10-dhcp.md)
|
||||
- `gfw`：[hosts/gfw.windy.lan.md](../hosts/gfw.windy.lan.md)
|
||||
- PVE：[PVE 透传方法调研](lan-rb5009-upgrade.md#阶段-5-附pve-上-vlan10-透传实现调研-2026-08-09)
|
||||
- SE5420 官方安装手册（默认 IP `10.18.18.251`、Console 38400、恢复出厂）：<https://service.tp-link.com.cn/download/202310/TL-SE5420%20V1.0安装手册%201.0.2.pdf>
|
||||
- **SE5420 安装手册（Markdown 整理版）**：[se5420-official-manuals/tl-se5420-install-manual.md](se5420-official-manuals/tl-se5420-install-manual.md)
|
||||
- SE5420 规格：<https://www.tp-link.com.cn/product_2899.html?v=specification>
|
||||
- SE5420 固件下载：<https://www.tp-link.com.cn/product_2899.html?v=download>
|
||||
- Omada 802.1Q VLAN 配置指南（`L2 Features → VLAN → 802.1Q VLAN → VLAN Config / Port Config`）：<https://support.omadanetworks.com/en/document/12981/>
|
||||
- Omada 管理 VLAN 配置指南：<https://support.omadanetworks.com/en/document/13135/>
|
||||
- TP-Link「Accessing the Switch」（WEB/Console/Telnet/SSH 登录、管理 IP 与网关、保存配置）：<https://www.tp-link.com/us/configuration-guides/accessing_the_switch/?configurationId=18231>
|
||||
- TP-Link「OpenSSH 7.0+ 登录交换机」（KexAlgorithms/HostKeyAlgorithms 兼容）：<https://support.omadanetworks.com/en/document/12963/>
|
||||
@@ -0,0 +1,262 @@
|
||||
# TL-SE5420 官方安装手册（整理版）
|
||||
|
||||
> **来源：** TP-LINK《TL-SE5420 V1.0 安装手册 1.0.2》（PDF），已整理为 Markdown。
|
||||
> 官方 PDF：<https://service.tp-link.com.cn/download/202310/TL-SE5420%20V1.0安装手册%201.0.2.pdf>
|
||||
> 配套实施文档：[../lan-se5420-deployment-guide.md](../lan-se5420-deployment-guide.md)
|
||||
> 说明：PDF 中示意图已省略（仅保留文字）；正文以官方 PDF 为准。
|
||||
|
||||
---
|
||||
|
||||
## 声明
|
||||
|
||||
- Copyright © 2023 普联技术有限公司，版权所有，保留所有权利。
|
||||
- 产品规格和资讯仅供参考，如有内容更新，恕不另行通知。本手册仅作为使用指导，所作陈述均不构成任何形式的担保。
|
||||
|
||||
## 相关文档
|
||||
|
||||
| 文档名称 | 用途 |
|
||||
|---|---|
|
||||
| 《安装手册》 | 交换机的安装过程、启动以及常见故障处理 |
|
||||
| 《用户手册》 | 交换机的各个功能应用以及常见功能使用问题处理 |
|
||||
| 《命令行手册》 | 交换机 CLI（Command Line Interface，命令行界面）参考信息 |
|
||||
| 《防雷安装手册》 | 安装中如何做好防雷措施以避免设备雷击损坏 |
|
||||
|
||||
技术支持：服务热线 `400-8863-400` · 邮箱 `fae@tp-link.com.cn` · 微信公众号「TP-LINK商用网络」/「TP-LINK商云APP」
|
||||
|
||||
## 阅读对象与约定
|
||||
|
||||
- 适合阅读对象：网络工程师、网络管理员。
|
||||
- 本手册如无特别说明，均以 **TL-SE5420** 机型为例介绍，所指交换机为 2.5G 三层网管交换机。
|
||||
- 产品规格标贴位于设备底部，扫描二维码可查看安规符号释义。
|
||||
|
||||
---
|
||||
|
||||
## 第 1 章 产品介绍
|
||||
|
||||
### 1.1 产品简介
|
||||
|
||||
2.5G 三层网管交换机，支持静态路由和动态路由 RIP 协议，提供完备的安全防护机制、完善的 QoS 策略和丰富实用的 VLAN 功能。适用于中小型企业网、校园网络、酒店、网吧等使用场景。
|
||||
|
||||
### 1.2 产品外观
|
||||
|
||||
**前面板组成：** 1 模式切换按键 · 2 指示灯 · 3 1 个 Type-C Console 端口 · 4 16 个 2.5Gbps RJ45 端口 · 5 4 个 SFP+ 端口 · 6 1 个 USB 端口
|
||||
|
||||
**模式切换按键：** 用于切换指示灯的指示状态，支持「端口模式」和「堆叠模式」切换。任意模式下超过 45s 不按动按钮，自动恢复为端口模式。（模式切换功能软件后续升级支持，以实际软件功能为准。）
|
||||
|
||||
**指示灯状态：**
|
||||
|
||||
| 指示灯 | 名称 | 工作状态 | 工作说明 |
|
||||
|---|---|---|---|
|
||||
| PWR | 电源指示灯 | 常亮 / 熄灭 / 闪烁 | 供电正常 / 未通电或供电异常 / 供电异常 |
|
||||
| SYS | 系统指示灯 | 绿色闪烁 / 红色闪烁 | 系统正常 / 系统异常 |
|
||||
| Master | 堆叠指示灯 | 绿色常亮 / 黄色常亮 / 熄灭 | 堆叠主设备 / 堆叠错误 / 非主设备 |
|
||||
| Stack | 模式指示灯 | 绿色常亮 / 熄灭 | 端口指示灯工作在堆叠模式 / 其它模式 |
|
||||
| 1-16（端口模式） | 端口指示灯 | 绿色常亮 / 黄色常亮 / 闪烁 / 熄灭 | 2.5Gbps / 10/100/1000Mbps / 传输中 / 未连接 |
|
||||
| 17-20（端口模式） | 端口指示灯 | 绿色常亮 / 黄色常亮 / 闪烁 / 熄灭 | 10Gbps / 2.5Gbps 或 1000Mbps / 传输中 / 未连接 |
|
||||
| USB | 端口指示灯 | 绿色常亮 / 熄灭 | USB 连接正常 / 未连接或异常 |
|
||||
|
||||
**Console 端口：** 用于和计算机或其他终端的串口相连以管理或配置交换机。TL-SE5420 提供 **1 个 Type-C Console 端口**。
|
||||
|
||||
**2.5Gbps RJ45 端口：** 16 个，支持 10M/100M/1000M/2.5Gbps 速率，每个端口对应一个端口指示灯。
|
||||
|
||||
**10Gbps SFP+ 端口：** 支持接入 1Gbps/2.5Gbps SFP 光/电模块或 10Gbps SFP+ 光/电模块，每个端口对应 1 个 Link/Act 指示灯。
|
||||
|
||||
**USB 端口：** 标准 USB2.0，480Mbps。可和交换机 Flash 文件系统交互（上传/下载应用程序、配置文件）。支持**交换机 U 盘开局**（详见《用户手册》）。
|
||||
|
||||
> 注意：不同厂商 USB 设备的兼容性和驱动存在差异，TP-LINK 不保证所有 USB 设备都能正常使用；如不能使用不属于交换机故障。
|
||||
|
||||
**后面板组成：** 1 防雷接线柱 · 2 电源插座（三相，220V~50Hz 交流电源）。
|
||||
|
||||
> 注意：请使用原装电源线；请通过电源线插头连接到有接地连接的输出插座；请远离水、火、潮湿或炎热环境；不要自行拆卸、修理、修改设备或更换电池（有爆炸危险）。
|
||||
|
||||
---
|
||||
|
||||
## 第 2 章 产品安装
|
||||
|
||||
### 2.1 物品清单
|
||||
|
||||
- 交换机 ×1 · 电源线 ×1 · 机架 L 型支架 ×2 · 安装手册 ×1 · 接地线 ×1 · 其他配件
|
||||
|
||||
### 2.2 安装注意事项
|
||||
|
||||
**安装安全：**
|
||||
- 安装过程中电源保持关闭，佩戴防静电手环并保证接地良好；
|
||||
- 确认供电电压与交换机标示电压相符；
|
||||
- 通电前确认不会引起电源电路超负荷；
|
||||
- 工作时不要打开外壳；
|
||||
- 清洁前先拔电源插头，勿用湿润面料擦拭或液体清洗；
|
||||
- 保持交换机底部朝下水平放置。
|
||||
|
||||
**环境要求：**
|
||||
|
||||
| 环境描述 | 温度 | 相对湿度 |
|
||||
|---|---|---|
|
||||
| 工作环境 | 0℃ ~ 40℃ | 10% ~ 90%RH 无凝结 |
|
||||
| 存储环境 | -40℃ ~ 70℃ | 5% ~ 90%RH 无凝结 |
|
||||
|
||||
- 海拔：仅适用于 2000m 以下地区。
|
||||
- 室内防尘、防电磁干扰、防雷：确认设备与大地接地良好；远离高频大功率设备；室外布线建议使用信号防雷器。
|
||||
- 安装台：机架或工作台需承重至少 **5.5Kg**；供电插座与交换机距离不超过 1.5 米。
|
||||
|
||||
### 2.3 安装工具准备
|
||||
|
||||
十字螺丝刀 · 防静电手环 · 网线、光纤
|
||||
|
||||
### 2.4 产品安装
|
||||
|
||||
**桌面安装：** 底部朝上放置于稳定桌面 → 粘贴 4 个脚垫到机壳底部四角凹槽 → 翻转放平。机壳周围预留 5~10cm 空隙确保散热。
|
||||
|
||||
**19 英寸机架安装：** 检查机架接地与稳定性 → 两侧安装 L 型角铁并固定 → 安放到机架内由托架支撑 → 螺钉固定 L 型角铁到机架导槽。机架内一般由下至上安装。
|
||||
|
||||
---
|
||||
|
||||
## 第 3 章 硬件连接
|
||||
|
||||
### 3.1 连接 RJ45 端口
|
||||
通过 RJ45 端口连接交换机和对端设备。
|
||||
|
||||
### 3.2 连接 SFP+ 端口
|
||||
连接 SFP/SFP+ 光/电模块或 SFP+ 电缆。**SFP+ 端口默认支持 10Gbps；若使用千兆 SFP 光模块，需先将 SFP+ 端口速率设置为 1000Mbps。** 使用 SFP+ 电缆时确保最小弯曲半径符合要求。
|
||||
|
||||
### 3.3 连接 Console 端口
|
||||
Type-C Console 端口，连接后可通过命令行管理交换机（登录方法见 4.2）。
|
||||
|
||||
### 3.4 连接电源线
|
||||
接入 220V~50Hz 交流电源；确认供电电源与大地良好接触，确认电源开关位置以便及时断电。
|
||||
|
||||
### 3.5 设备初始化
|
||||
接通电源后自动初始化：
|
||||
- PWR 指示灯亮 = 电源连接正确，灭 = 供电异常；
|
||||
- SYS 指示灯闪烁 = 系统初始化成功，灭或常亮 = 初始化失败；
|
||||
- Link/Act 指示灯会闪烁一下后熄灭，指示系统已复位。
|
||||
|
||||
### 3.6 安装后检查
|
||||
- 周围散热空间与空气流通；
|
||||
- 电源插座供电符合规格；
|
||||
- 电源、交换机、机架正确接地；
|
||||
- 与其它网络设备连接正常。
|
||||
|
||||
---
|
||||
|
||||
## 第 4 章 配置指南
|
||||
|
||||
### 4.1 WEB 登录
|
||||
|
||||
> **TL-SE5420 业务口固定 IP 为 `10.18.18.251`**；电脑连接业务口时需设 IP `10.18.18.x`（x 为 2-250 任意值），子网掩码 `255.255.255.0`。
|
||||
|
||||
1. 普通 PC 用网线连接交换机任意一个 RJ45 业务端口；
|
||||
2. 浏览器输入 `http://10.18.18.251` 回车；
|
||||
3. **设置用户名和密码**，点击<确认>登录 WEB 管理界面；
|
||||
4. 首页左上角商标可访问 TP-LINK 官网；左侧主菜单进行功能配置。
|
||||
|
||||
### 4.2 本地登录（Console）
|
||||
|
||||
1. 连接 Type-C Console 口到计算机；
|
||||
2. 安装「**TP-LINK USB 串口驱动程序**」（官网下载或随机光盘）；
|
||||
3. 终端仿真程序参数：
|
||||
- 波特率 **38400bps** · 数据位 **8** · 奇偶校验 **无** · 停止位 **1** · 数据流控制 **无**
|
||||
4. 输入回车，出现 **`TL-SE5420>`** 提示符即登录成功。
|
||||
|
||||
### 4.3 远程登录（Telnet）
|
||||
|
||||
1. cmd 输入 `telnet 10.18.18.251`；
|
||||
2. 输入登录用户名和密码；
|
||||
3. 输入 `enable` 回车进入特权模式。
|
||||
|
||||
### 4.4 云管理
|
||||
|
||||
1. Web 界面 →<云管理> → 开启<全局开关>；
|
||||
2. 访问 `https://smbcloud.tp-link.com.cn/login.html`，登录 TP-LINK ID；
|
||||
3. 项目集中管理 → 设备列表 → 添加设备（输入 MAC、名称、用户名、密码、分组；MAC 可扫设备底部二维码获取）；
|
||||
4. 设备信息页找到对应条目 →<远程配置> → 云平台远程管理。
|
||||
|
||||
---
|
||||
|
||||
## 附录 A 常见故障处理
|
||||
|
||||
**问题1：忘记用户名和密码（恢复出厂设置）**
|
||||
1. 串口连 Console 口，打开终端；
|
||||
2. 交换机断电重启，终端出现 **`Press CTRL-B to enter the bootUtil`** 时按 `Ctrl+B` 进入 bootUtil 菜单；
|
||||
3. 输入 **`2`** 进行软件复位，恢复到出厂默认设置，登录用户名和密码均为 **admin**。
|
||||
|
||||
**问题2：电源指示灯显示不正常**
|
||||
- 电源线连接是否正确；供电电源是否匹配（100-240V~ 50/60Hz）。
|
||||
|
||||
**问题3：无法登录 WEB 管理界面**
|
||||
- 是否达到 HTTP 管理人数上限；
|
||||
- 端口线缆连接与端口状态；
|
||||
- 电脑 IP 与交换机 IP 是否同网段；
|
||||
- `ping 127.0.0.1`（本机 TCP/IP）与 `ping 10.18.18.251`（交换机）。
|
||||
|
||||
**问题4：断电后配置消失**
|
||||
- 配置实时生效，但**断电前必须点保存配置**。
|
||||
|
||||
---
|
||||
|
||||
## 附录 B 技术参数规格
|
||||
|
||||
| 项 | 值 |
|
||||
|---|---|
|
||||
| 产品型号 | TL-SE5420 |
|
||||
| 技术标准 | IEEE 802.3 / 802.3i / 802.3u / 802.3ab / 802.3z / 802.3bz(2.5G/5G) / 802.3ae(10G) / 802.3ad(链路聚合) / 802.3x(流控) / 802.1p(QoS) / 802.1q(VLAN) / 802.1x / 802.1d(STP) / 802.1s(MSTP) / 802.1w(RSTP) / 802.1ab(LLDP) |
|
||||
| 端口 | 16× 10/100/1000/2.5G RJ45 + 4× 10G SFP+ |
|
||||
| 传输方式 | 存储转发 |
|
||||
| 数据传输速率 | 10M半双工/20M全双工 · 100M半/200M全 · 千兆2000M全 · 2.5G 5000M全 · 10G 20000M全 |
|
||||
| 包转发速率 | 10BASE-T:14881pps · 100BASE-TX:148810pps · 1000BASE:1488095pps · 2.5GBASE-T:3720238pps · 10GBASE:14880952pps（每端口） |
|
||||
| 电源输入 | 220V~50Hz |
|
||||
| 工作温度 | 0℃~40℃ |
|
||||
| 存储温度 | -40℃~70℃ |
|
||||
| 工作湿度 | 10%~90%RH 无凝结 |
|
||||
| 存储湿度 | 5%~90%RH 无凝结 |
|
||||
|
||||
网络介质（部分）：10BASE-T 3类线≤100m · 100BASE-TX 5类线≤100m · 1000BASE-T 超5类≤100m · 2.5GBASE-T 超5类≤100m · 10GBASE-SR OM1/OM2/OM3 MMF 2m~300m · 10GBASE-LR SMF 2m~10000m。
|
||||
|
||||
---
|
||||
|
||||
## 附录 C 连接 SFP+ 端口补充说明
|
||||
|
||||
- **光纤**：单模（芯径 9/10μm，模间色散小，适合远程）；多模（芯径 50/62.5μm，传输距离较近，一般几公里）。
|
||||
- **光模块**：按性质分单模/多模；按速率分百兆/千兆/万兆。SFP/SFP+ 端口兼容单模、多模光模块，推荐使用 TP-LINK 光模块。
|
||||
|
||||
**TP-LINK 光模块参考表：**
|
||||
|
||||
| 模块类型 | 产品型号 | 速率 | 距离 | 传输介质 |
|
||||
|---|---|---|---|---|
|
||||
| 光模块 | TL-SM512LS-10KM | 10Gbps | 10km | SMF 双纤 LC |
|
||||
| 光模块 | TL-SM512LM-300m | 10Gbps | 300m | OM3 MMF 双纤 LC |
|
||||
| 光模块 | TL-SM411LSA/B-5KM | 2.5Gbps | 5km | SMF 单纤 LC |
|
||||
| 光模块 | TL-SM411LSA/B-500m | 2.5Gbps | 500m | SMF 单纤 LC |
|
||||
| 光模块 | TL-SM411SSA/B-500m | 2.5Gbps | 500m | SMF 单纤 SC |
|
||||
| 光模块 | TL-SM412LS-5KM | 2.5Gbps | 5km | SMF 双纤 LC |
|
||||
| 光模块 | TL-SM311LSA/B-20KM | 1Gbps | 20km | SMF 单纤 LC |
|
||||
| 光模块 | TL-SM311LSA/B-2KM | 1Gbps | 2km | SMF 单纤 LC |
|
||||
| 光模块 | TL-SM311SSA/B-2KM | 1Gbps | 2km | SMF 单纤 SC |
|
||||
| 光模块 | TL-SM312LS-40KM | 1Gbps | 40km | SMF 双纤 LC |
|
||||
| 光模块 | TL-SM312LS-20KM | 1Gbps | 20km | SMF 双纤 LC |
|
||||
| 光模块 | TL-SM312LS-20KM工业级 | 1Gbps | 20km | SMF 双纤 LC |
|
||||
| 光模块 | TL-SM312LM-550m | 1Gbps | 550m | OM2 MMF 双纤 LC |
|
||||
| 电口模块 | TL-SM510U | 10Gbps | 30m | 超六类网线 |
|
||||
| 电口模块 | TL-SM410U | 2.5Gbps | 100m | 超五类网线 |
|
||||
| 电口模块 | TL-SM310U | 1Gbps | 100m | 超五类网线 |
|
||||
|
||||
---
|
||||
|
||||
## 附录 D 产品保修卡（要点）
|
||||
|
||||
- 免费保修范围外的情况：超出保换/保修期限、未按要求安装使用、擅自改动设置或拆机、意外或人为损坏、运输损坏、不可抗力等。
|
||||
- 技术支持热线：`400-8863-400` · 邮箱 `fae@tp-link.com.cn` · 官网 `www.tp-link.com.cn`。
|
||||
- **售后服务承诺：三年保修。**
|
||||
- 外置电源保换 1 年，电池 6 个月，鼠标 3 个月；无线外置天线及光纤头 3 个月。
|
||||
- 购机 15 天内出现性能问题且外观无划伤可换新。
|
||||
|
||||
---
|
||||
|
||||
## 附录 E 有毒有害物质含量声明
|
||||
|
||||
（详见官方 PDF 附表。）
|
||||
|
||||
---
|
||||
|
||||
公司地址：深圳市南山区深南路科技园工业厂房 24 栋南段 1 层、3-5 层、28 栋北段 1-4 层
|
||||
公司网址：<http://www.tp-link.com.cn> · 技术支持 E-mail：`smb@tp-link.com.cn` · 技术支持热线：`400-8863-400`
|
||||
文档版本：REV1.0.2
|
||||
@@ -0,0 +1,158 @@
|
||||
# 希力威视 SR-S25G3218F 调查（2026-08-08）
|
||||
|
||||
**结论：** 若需求是大量 2.5G 终端、少量 10G 光上联，`SR-S25G3218F` 的端口密度
|
||||
更合适；厂商已公开该型号的固件页，但仍缺少完整规格书、管理手册与兼容矩阵。若需求是 8 条全部可协商
|
||||
1/2.5/5/10G 的铜缆链路，且希望有可查的 L3 能力和固件入口，兮克
|
||||
`SKS8300-8T` 是资料更完整、风险更低的选择；它的代价是主动风扇、外置 12 V 电源、
|
||||
无 SFP+ 光口，且仍不应把消费级/SMB 设备当作安全边界或唯一核心。两者都应在
|
||||
到货可退换期内完成实机验收。
|
||||
|
||||
本页为采购前资料调查，不代表已接入本地网络；检索日期为 2026-08-08。
|
||||
|
||||
## 已能核实的事项
|
||||
|
||||
| 项目 | 结论与证据强度 |
|
||||
|---|---|
|
||||
| 型号/端口 | 京东的希力威视商品标题称该 SKU 为 `SR-S25G3218F`，有 16 个 2.5G 电口和 2 个万兆光口，并宣传 VLAN、端口隔离与 LACP。该店铺被厂商官网列为可购买的「京东旗舰店」，因此可作为销售规格，非技术手册。[京东商品页](https://item.jd.com/100165071727.html)；[厂商购买渠道说明](https://en.sirivision.com/contactus/) |
|
||||
| 厂商身份 | 厂商官网为 Shenzhen/Guangdong Sirivision Communication；英文官网说明其自 2016 年起提供接入、汇聚和核心交换机方案。[厂商首页](https://en.sirivision.com/) |
|
||||
| 公开的二手厂家资料 | 同一制造商名义的 Alibaba 出口页将精确型号写成 `16*2.5G+2*10G`、`120Gbps`，并列出 QoS、VLAN、SNMP、L3 与 stackable。这是制造商发布在平台上的销售资料，**不是**官网数据表；其中后五项不能据此视为已验收的功能承诺。[制造商平台页](https://www.alibaba.com/pla/SR-S25G3218F-QoS-Managed-SFP-Switch-1625G210G_1601494946214.html) |
|
||||
| 固件入口 | 厂商已发布此精确型号的[固件页](https://www.sirivision.com/sr-s25g3218f%E5%9B%BA%E4%BB%B6/)。公开变更记录提到“光口自适应”和“增加 DAC 配置”；这证明厂商维护过该路径，**不**代表任意 SFP+/DAC/铜模块均兼容。 |
|
||||
| 本机可计算的带宽 | 端口线速相加为单向 60 Gb/s（16 × 2.5 + 2 × 10）；若厂商所谓 `120Gbps` 是全双工交换容量，则数学上吻合。它**不**证明缓冲、PPS、表项规模或实际无阻塞性能。 |
|
||||
|
||||
## 网管/L2/L3 能力边界
|
||||
|
||||
京东标题足以支持把 VLAN、端口隔离、LACP 作为「卖家声称提供」的功能；不得由此推导出
|
||||
ACL、IPv4/IPv6 静态路由、SVI 数量、DHCP relay、OSPF/RIP、VRRP、IGMP、ERPS、
|
||||
802.1X、RADIUS/TACACS+、SSH/HTTPS 管理、SNMP 版本、日志/审计、配置备份或固件
|
||||
安全维护一定存在。
|
||||
|
||||
尤其要注意：厂商官网把真正列出的 2.5G L3 产品标为
|
||||
`SR-S25G3412F (8 × 2.5G + 4 × 10G SFP+)`；其 2.5G 类目只显示 7 个型号，
|
||||
不含 `SR-S25G3218F`。官网也把 L2+、Web Smart、L3 分成不同产品类别。这个目录
|
||||
差异**不是**证明 3218F 没有 L3，而是说明「三层」无法通过官网的精确型号文档确认。
|
||||
[2.5G 产品目录](https://en.sirivision.com/product-category/products/2-5g-switches/)；
|
||||
[官网的 10G L3 目录](https://en.sirivision.com/product-category/products/10g-switches/10g-layer3-managed-switches/)；
|
||||
[官网的 L2+ 分类示例](https://en.sirivision.com/product-category/products/gigabit-switches/gigabit-layer2-managed-switches/)。
|
||||
|
||||
采购前请向京东/厂商索取**与机身 SKU、硬件 revision 和固件版本对应**的 PDF
|
||||
数据表、管理手册和 release notes，并要求书面回答至少以下问题：
|
||||
|
||||
1. L3 是只有 VLAN Interface/IPv4 静态路由，还是另有 IPv6、ACL、动态路由、DHCP relay
|
||||
等；每项的最大 VLAN、MAC、ARP、路由、ACL、LAG 数量分别是多少？
|
||||
2. LACP 是否符合 802.3ad、一个 LAG 最多多少成员、能否跨两台设备（若销售页的
|
||||
`stackable` 属实，堆叠的线缆/模块、最大成员、控制面和软件版本为何）？
|
||||
3. 管理面是否支持 HTTPS/SSH、禁用 HTTP/Telnet、独立管理 VLAN、SNMPv3、syslog、NTP、
|
||||
配置导出/回滚和已签名或可校验的固件；默认凭据首次登录是否强制修改？
|
||||
|
||||
## 供电、散热和光口：当前不能确认
|
||||
|
||||
针对该精确 SKU，厂商官网目录与公开搜索未找到说明书/数据表，所以以下均为**待确认，
|
||||
不能猜测**：
|
||||
|
||||
- 是否为内置 AC 电源、额定输入范围/最大功耗、是否带电源开关和接地端子；是否完全
|
||||
不提供 PoE（本型号名和京东标题均未写 PoE，但这不足以替代规格书）。
|
||||
- 风扇数量、常态/满载噪声、风向、环境温湿度、机架深度与安装耳；不要将「金属壳」
|
||||
或产品照片等同于无风扇/静音。
|
||||
- 两个槽是否均为 **10G SFP+**，是否可协商 1G SFP；支持的 SR/LR/BiDi 波长距离、
|
||||
DAC/AOC 长度、第三方模块/EERPOM 兼容策略、10GBASE-T SFP+ 模块的功耗/温度限制，
|
||||
以及是否支持 GPON/XPON ONU「猫棒」。
|
||||
|
||||
厂商确实单列「SFP Optical Modules」产品分类，但这不构成 3218F 的兼容清单。
|
||||
[厂商产品导航](https://en.sirivision.com/)。购买光模块/直连线时，应要求厂商按这台
|
||||
设备的硬件/固件 revision 出具兼容型号清单；没有书面清单时，先在可退换期实测两端的
|
||||
链路、重启恢复、热插拔与长时间满载错误计数。
|
||||
|
||||
## 风险与建议验收
|
||||
|
||||
- **文档/生命周期风险（中到高）：** 精确型号不在厂商当前官网 2.5G 目录，虽有固件下载页，
|
||||
但未公开完整型号手册、明确 release notes 或兼容矩阵。官网的售后条款也要求按具体产品查询保修期，配件（含光纤头）
|
||||
的保修条款与主机不同；不要把平台页的「3 年」当作中国零售 SKU 的已确认保修。
|
||||
[厂商售后条款](https://en.sirivision.com/after-sale-protection/)
|
||||
- **功能表述风险（高）：** 页面将 L2 特性和「三层网管」并列；在命令/网页菜单、
|
||||
手册和测试证明之前，将其当作 L2 VLAN/LACP 设备部署，跨 VLAN 路由仍由现有网关承担。
|
||||
- **双 10G 上联约束（中）：** 两个 SFP+ 可作双上联或一个二成员 LAG，但 LAG 增加的是
|
||||
多流量总吞吐，单一 TCP/UDP 流通常仍受一条 10G 链路限制；上级设备也必须匹配 LACP
|
||||
配置。
|
||||
- **管理面风险（中到高）：** 家用/低价网管设备常见明文管理、弱默认口令或不透明的固件
|
||||
更新周期；采购后先置于受限管理 VLAN，改口令、升级已验证固件，且不将管理界面暴露
|
||||
到 WAN/访客网。
|
||||
|
||||
最低验收应包括：逐口协商 100M/1G/2.5G、两只不同厂家 SFP+/DAC（仅在卖家承诺支持的
|
||||
范围内）、VLAN trunk/access/PVID、STP/环路保护、LACP 故障切换、端口隔离、满载
|
||||
双向 iperf3 与错误计数、冷启动后的配置保留，以及管理面的 HTTPS/SSH/SNMPv3/配置备份。
|
||||
如无法提供与型号匹配的正式资料或其中任一关键项失败，应在退换期内退货，并选择公开
|
||||
数据表、固件与兼容矩阵更完整的型号。
|
||||
|
||||
## 备选：兮克 SKS8300-8T 对比
|
||||
|
||||
### 已核实的厂商规格
|
||||
|
||||
兮克官网的精确型号页明确将 `SKS8300-8T` 定位为三层管理型 10G 全电口交换机，并列出：
|
||||
|
||||
- 8 × 1/2.5/5/10GBASE-T RJ45；160 Gb/s 交换容量、119.05 Mpps、12 Mbit 缓存、
|
||||
16K MAC、12 KB 巨帧、512 MB DRAM、32 MB Flash，尺寸 207 × 136 × 35 mm；
|
||||
- QoS、ACL、IP+MAC+端口绑定、流分类/优先级标记、多端口镜像、静态/灵活 QinQ、
|
||||
sFlow，以及「基于策略的 IPv4/IPv6 单播路由」。
|
||||
|
||||
这些是厂商能力声明，并非对每一种路由协议或表项上限的承诺；但相对 3218F 的仅有
|
||||
销售标题，它给出了精确型号、转发性能和 L3 范围。[兮克 SKS8300-8T
|
||||
产品页](https://seekswan.com/user/custom-pages/SKS8300-8T.html)
|
||||
|
||||
独立的 OpenWrt 设备资料将其识别为 Realtek RTL9303、512 MB RAM，记录了原厂固件
|
||||
下载入口和串口/TFTP 恢复路径；其硬件数据页列为 12 V / 4 A。这支持「可恢复、可替换
|
||||
系统」的可操作性，但**不是**兮克对原厂功能的支持承诺。
|
||||
[OpenWrt 设备页](https://openwrt.org/toh/xikestor/sks8300-8t)；
|
||||
[OpenWrt 硬件数据](https://openwrt.org/toh/hwdata/xikestor/xikestor_sks8300-8t)。
|
||||
|
||||
### 能力、物理与运维比较
|
||||
|
||||
| 维度 | 希力威视 SR-S25G3218F | 兮克 SKS8300-8T |
|
||||
|---|---|---|
|
||||
| 接口/典型用途 | 16 × 2.5G 电口 + 2 × 10G SFP+（销售规格）；适合很多 2.5G 终端/NAS，以 10G 光或 DAC 上联。 | 8 × 1/2.5/5/10GBASE-T；适合 10G 铜缆设备、2.5/5G 多速率 NAS/主机。没有 SFP+，光纤上联必须经媒体转换或选另一型号。 |
|
||||
| 可确认的三层范围 | 仅销售/平台资料称 L3；没有精确型号官方手册，不能确认静态路由以外的功能。 | 官网明确写策略型 IPv4/IPv6 单播路由、ACL/QoS/sFlow/QinQ；动态路由、VRRP、IPv6 ACL/SNMP/认证等仍须按当前固件手册确认。 |
|
||||
| 冗余/二层 | 卖家声称 VLAN、端口隔离、LACP；STP/环网的实现与规格未知。 | 官网声明 L3 和多项转发特性，但未在产品页给出 STP/LACP/ERPS 的精确限制；购买前仍索取手册。 |
|
||||
| 散热/噪声 | 无可核实的精确型号风扇、噪声、功耗或风向数据。 | 独立手册镜像和产品图均称智能温控风扇，但厂商产品页未给 dBA；应按「有风扇、可能听得见」规划，不能承诺静音。 |
|
||||
| 供电 | 未找到精确型号官方输入/功耗资料。 | OpenWrt 硬件数据记录 12 V / 4 A；确认随附电源适配器的插头、余量和地区认证。官方产品页未给满载功耗。 |
|
||||
| 固件/恢复 | 有精确型号官方固件页；公开记录包含光口自适应与 DAC 配置改动，但未找到完整 release notes、恢复步骤或兼容矩阵。 | 厂商产品页提供「相关下载」区，OpenWrt 还记录原厂固件入口、RJ45 串口和 U-Boot/TFTP 恢复；原厂镜像是否签名、漏洞修复 SLA、配置回退仍未知。 |
|
||||
|
||||
关于 8T 的风扇、满载功耗（常见转述为 ≤36 W）、温度范围、芯片型号等，本次未找到
|
||||
相应的**厂商原始数据表**；不将第三方手册转录当作已核实规格。若噪声、UPS 容量或
|
||||
机柜散热是购买约束，请先让卖家提供产品铭牌照片、适配器铭牌照片、额定/实测功耗和
|
||||
dBA 测试条件。
|
||||
|
||||
### 选择与验收建议
|
||||
|
||||
- 选 **3218F**：必须有 ≥12 个 2.5G 接入端、10G 光/DAC 上联、且 L3 留给现有路由器。
|
||||
下单前先取得精确型号手册和 SFP+/DAC 兼容承诺；否则端口数量优势不足以抵消资料风险。
|
||||
- 选 **8T**：最多 8 个设备但需要多速率 10G RJ45、明确的 IPv4/IPv6 静态/策略路由和
|
||||
以后自行维护/恢复的余地。不要把其 160 Gb/s 标称交换容量误解为 8 端口同时 10G
|
||||
全双工的性能保证——该标称与端口总线速数学相等，但仍须以实测和厂商 PPS/缓冲说明为准。
|
||||
- 两台都不应单独承担防火墙、访客/IoT 安全隔离或 WAN 暴露；VLAN 的跨网段策略和公网
|
||||
边界留在受支持的网关/防火墙上。先为管理面创建专用 VLAN，仅从管理主机访问，禁用
|
||||
未使用的远程管理协议，备份配置和原厂固件后再接入生产网络。
|
||||
|
||||
## 低功耗核心备选（8 × 2.5G + 2 × SFP+）
|
||||
|
||||
如果核心只需接最多 8 台铜缆终端、上联/连接 NAS 使用 DAC 或光纤 10G，优先考虑没有
|
||||
PoE 的以下两款。它们都满足 VLAN trunk、LACP 和至少两个 10G SFP+ 的需求；不要为
|
||||
AP 选 PoE 版来承担核心，因为 PoE 预算、风扇和待机损耗都会明显增加。
|
||||
|
||||
| 型号 | 端口与管理能力（厂商声明） | 厂商功耗 / 噪声资料 | 对当前 LAN 的判断 |
|
||||
|---|---|---|---|
|
||||
| **TP-Link Omada SG3210X-M2** | 8 × 100M/1G/2.5G RJ45、2 × 10G SFP+，并有 RJ45 和 Micro-USB console。厂商规格列出 802.1Q VLAN、STP/RSTP/MSTP、静态 LAG 和 802.3ad LACP（最多 8 个聚合组、每组最多 8 端口）；L3 是 32 个 IPv4/IPv6 接口、48 条静态路由。 | **无风扇**；100–240 V AC 内置电源。`UN 1.20` 数据表：待机最高 **6.0 W**（220 V/50 Hz、25 °C），最高 **15.3 W**（220 V）或 **15.0 W**（110 V）。 | **首选低功耗方案。** 足以做 LAN66 核心、给 PVE/gfw 与 U6 Lite 做 VLAN 10 trunk，并以 SFP+ DAC/光口连接 10G NAS/主机；它不提供 5G/10G RJ45，10G 铜缆需外置转换或 SFP+ 10GBASE-T 模块。 |
|
||||
| **MikroTik CRS310-8G+2S+IN** | 8 × 2.5G RJ45、2 × 10G SFP+；SFP+ 笼支持 1G/2.5G/10G。RouterOS v7（也可选 SwOS）支持 VLAN、链路聚合与 ACL。 | 18–57 V DC 外置供电；官方给出“无附件”最高 **21 W**、总体最高 **34 W**，且机内 **1 个风扇**。厂商没有在该页给出 dBA。 | 可用且软件/文档/恢复路径成熟，但不是本题的静音低功耗优先项：官方最大功耗显著高于 TP-Link，且有风扇。适合明确偏好 RouterOS/SwOS 与其可维护性时选。 |
|
||||
|
||||
功耗数字是各厂商的**上限/待机测试条件**，不是你实际墙插读数；SFP+ 光模块、DAC/AOC，尤其
|
||||
10GBASE-T SFP+ 模块，会另增功耗和热量。对于本网络，用被动 DAC 或短距光模块连接 10G
|
||||
设备，通常比全 RJ45 10G 核心更容易保持低温、低噪。
|
||||
|
||||
`SG3210X-M2` 的上表数据对应 TP-Link 的 `UN 1.20` 数据表；不同地区/硬件版本的包装、
|
||||
认证和功耗标注可能不同，购买中国零售版本前应让卖家确认**准确硬件版本、保修渠道和固件地区**。
|
||||
本次未找到 TP-Link 中国官网的该精确型号页，因此不能把海外官方页面当作大陆现货/售后承诺。
|
||||
MikroTik 同样应通过其官方零售商查询渠道确认本地库存和保修。两台购买前还应确认所选
|
||||
SFP+/DAC 的兼容清单。
|
||||
|
||||
来源：[TP-Link 产品规格](https://www.tp-link.com/uk/business-networking/omada-switch-access-pro/sg3210x-m2/)；
|
||||
[TP-Link `UN 1.20` 数据表](https://static.tp-link.com/upload/product-overview/2025/202512/20251224/SG3210X-M2%28UN%29%201.20_datasheet.pdf)；
|
||||
[MikroTik 产品页](https://mikrotik.com/product/crs310_8g_2s_in)；
|
||||
[MikroTik 用户手册](https://help.mikrotik.com/docs/spaces/UM/pages/214630429/CRS310-8G%2B2S%2BIN)。
|
||||
@@ -68,6 +68,62 @@ db.device.find(
|
||||
).pretty()
|
||||
```
|
||||
|
||||
## Dedicated Wi-Fi through a third-party gateway
|
||||
|
||||
### Architecture boundary discovered on 2026-08-08
|
||||
|
||||
`gfw` is a virtual machine connected only to the native LAN 66 network; the
|
||||
physical Wi-Fi uplink is also an ER-X LAN 66 path. The ER-X provides DHCP for
|
||||
that LAN. There is no verified 802.1Q-capable path from the U6 Lite to `gfw`.
|
||||
|
||||
Consequently, the proposed `ubnt-upg` design is **not implementable on the
|
||||
current topology without an additional VLAN-capable L2 path**. Giving the VM
|
||||
an `eth0.10` interface alone does not create VLAN 10 on the physical switch or
|
||||
deliver tagged frames to it.
|
||||
|
||||
UniFi APs associate clients and bridge an SSID into a selected 802.1Q VLAN;
|
||||
they do not allocate DHCP addresses. The controller configures that AP
|
||||
behavior, but it is not a DHCP service for a third-party-gateway VLAN. The
|
||||
gateway on the corresponding VLAN provides DHCP. In the existing topology, the
|
||||
ER-X DHCP service legitimately answers untagged LAN 66 requests.
|
||||
|
||||
The observed `192.168.66.91` lease on `ubnt-upg` is therefore expected when
|
||||
traffic reaches the existing untagged LAN 66. It is not a failure that can be
|
||||
fixed by changing the controller or by adding another DHCP server to the same
|
||||
broadcast domain.
|
||||
|
||||
### Conditions for a future implementation
|
||||
|
||||
The design becomes viable only after adding and proving one of these:
|
||||
|
||||
1. A VLAN-capable switch/trunk from the U6 Lite to a VLAN-10 interface on the
|
||||
actual gateway, with native LAN 66 retained for AP management; or
|
||||
2. A hypervisor/vSwitch and physical uplink configured to pass VLAN 10 end to
|
||||
end to the `gfw` VM, plus the corresponding tagged port towards the U6.
|
||||
|
||||
Then configure one UniFi virtual network with **Router: Third-party Gateway**
|
||||
and VLAN ID `10`, map only `ubnt-upg` to it, and have the VLAN 10 gateway be
|
||||
the sole DHCP server for `192.168.10.0/24`. A test client must obtain
|
||||
`192.168.10.x`, with traffic and its lease visible on that gateway, before the
|
||||
SSID is considered working.
|
||||
|
||||
### Protecting existing Wi-Fi
|
||||
|
||||
`ubnt-windy` is the existing 5 GHz SSID and has been restored on the U6 Lite.
|
||||
Keep its network and broadcast/device assignment unchanged. If the dedicated
|
||||
SSID is ever retried, use the controller's normal **Specific -> U6 Lite**
|
||||
broadcast selection for `ubnt-upg` only; do not reuse, move, or manually edit
|
||||
an existing SSID's AP group. An AP configuration push can still briefly
|
||||
reassociate clients, so zero-impact work on the same AP cannot be guaranteed.
|
||||
|
||||
### References
|
||||
|
||||
- [Feasibility and DHCP responsibility](unifi-third-party-vlan10-dhcp.md)
|
||||
- [Supported topology and implementation examples](unifi-openwrt-vlan10-implementation-examples.md)
|
||||
- Ubiquiti: [Creating Virtual Networks (VLANs)](https://help.ui.com/hc/en-us/articles/9761080275607-Creating-Virtual-Networks-VLANs),
|
||||
[Creating WiFi SSIDs](https://help.ui.com/hc/en-us/articles/26136823938583-Creating-UniFi-WiFi-SSIDs), and
|
||||
[Switch Port VLAN Assignment](https://help.ui.com/hc/en-us/articles/26136855808919-Switch-Port-VLAN-Assignment-Trunk-Access-Ports).
|
||||
|
||||
## Managed access points
|
||||
|
||||
| Name | Model | Management IP | Firmware | Management network | Inform port |
|
||||
|
||||
@@ -0,0 +1,120 @@
|
||||
# UniFi AP + OpenWrt VLAN-backed Wi-Fi: implementation evidence
|
||||
|
||||
**Research date:** 2026-08-08
|
||||
**Scope:** research only. This file does not assert that the local physical
|
||||
path currently carries VLAN 10, and no controller, AP, ERX, or OpenWrt setting
|
||||
was changed while preparing it.
|
||||
|
||||
## Conclusion
|
||||
|
||||
Yes. This is a normal, supported deployment pattern: UniFi APs and Network
|
||||
Application manage the SSID-to-VLAN mapping, while a non-UniFi gateway such as
|
||||
OpenWrt owns the tagged VLAN interface, its subnet, DHCP, routing, and
|
||||
firewall/policy routing. The existing untagged LAN DHCP server remains in
|
||||
place; it serves only the native LAN, while OpenWrt serves the tagged VLAN.
|
||||
|
||||
Ubiquiti's current third-party-gateway recipe specifically says to configure
|
||||
the subnet, VLAN ID, and DHCP **on the third-party gateway first**, then create
|
||||
a UniFi virtual network with **Router = Third-party Gateway** and the same VLAN
|
||||
ID. [Ubiquiti: Creating Virtual Networks (VLANs)](https://help.ui.com/hc/en-us/articles/9761080275607-Creating-Virtual-Networks-VLANs)
|
||||
|
||||
That supported pattern requires an end-to-end tagged path. It is not feasible
|
||||
on the current local topology: `gfw` is a VM connected only to untagged LAN 66
|
||||
and there is no verified physical or virtual switch trunk carrying VLAN 10 from
|
||||
the U6 Lite to that VM. Creating `eth0.10` inside the VM cannot supply the
|
||||
missing L2 transport.
|
||||
|
||||
## The reusable topology
|
||||
|
||||
```text
|
||||
main SSID ── untagged/native LAN66 ── ERX DHCP ── 192.168.66.0/24
|
||||
│
|
||||
U6 Lite ── AP uplink trunk (native LAN66 + tagged VLAN 10) ── gfw/OpenWrt
|
||||
└── ubnt-upg SSID ── VLAN 10 ── gfw.10: 192.168.10.1/24 + DHCP + OpenClash
|
||||
```
|
||||
|
||||
This is not two DHCP servers answering one broadcast domain. They serve two
|
||||
separate L2 broadcast domains. An AP bridges a station's DHCP request into the
|
||||
VLAN selected for its SSID; it does not allocate the address itself. Ubiquiti
|
||||
states that SSID clients become members of the selected VLAN and that every
|
||||
port between AP and gateway must allow that VLAN. [Ubiquiti: Creating UniFi
|
||||
WiFi SSIDs](https://help.ui.com/hc/en-us/articles/26136823938583-Creating-UniFi-WiFi-SSIDs)
|
||||
|
||||
OpenWrt's own VLAN documentation shows the same mixed-link model: an untagged
|
||||
LAN plus tagged VLAN interfaces on a common link, and explicitly notes that a
|
||||
separate DHCP server can serve each segment. [OpenWrt: VLAN / switch
|
||||
configuration](https://openwrt.org/docs/guide-user/network/vlan/switch_configuration)
|
||||
|
||||
## Evidence of existing deployments
|
||||
|
||||
### Protocol and product documentation (authoritative)
|
||||
|
||||
* Ubiquiti's third-party-gateway workflow is an exact product-supported recipe
|
||||
for the UniFi half: gateway first, then matching VLAN in UniFi. It does not
|
||||
require a UniFi gateway or switch. [Creating Virtual Networks
|
||||
(VLANs)](https://help.ui.com/hc/en-us/articles/9761080275607-Creating-Virtual-Networks-VLANs)
|
||||
* Ubiquiti specifies the exact Wi-Fi half: choose the network in the SSID's
|
||||
**Network** dropdown, select the APs that should broadcast it, and permit the
|
||||
VLAN on all intervening ports. [Creating UniFi WiFi
|
||||
SSIDs](https://help.ui.com/hc/en-us/articles/26136823938583-Creating-UniFi-WiFi-SSIDs)
|
||||
* Ubiquiti's troubleshooting topology specifically calls an SSID VLAN made
|
||||
native on the AP port, or absent as a tagged VLAN upstream, a broken setup;
|
||||
it directs operators to trace every AP-to-gateway port. [Virtual Network
|
||||
(VLAN) Troubleshooting](https://help.ui.com/hc/en-us/articles/9592924981911-Virtual-Network-VLAN-Troubleshooting)
|
||||
* OpenWrt documents Linux 802.1Q interfaces and bridge VLAN membership. Its
|
||||
example calls out a trunk carrying untagged traffic and tagged VLANs, which
|
||||
is the link gfw needs. [OpenWrt: VLAN / switch
|
||||
configuration](https://openwrt.org/docs/guide-user/network/vlan/switch_configuration)
|
||||
|
||||
### User-reported working deployments (official Ubiquiti Community; anecdotal)
|
||||
|
||||
These are not Ubiquiti support guarantees, but they demonstrate that the exact
|
||||
vendor split is in real use:
|
||||
|
||||
* A user reports a UniFi site whose upstream router/DHCP server is **OpenWrt**;
|
||||
they create a Third-Party Gateway network, assign its VLAN tag, then bind it
|
||||
to the Wi-Fi SSID. The report says it works without a UniFi gateway or switch.
|
||||
[UniFi Network Application 7.4.156 discussion](https://community.ui.com/releases/UniFi-Network-Application-7-4-156/15ac6260-9cd1-4ac3-a91c-4880c1c87882?page=36)
|
||||
* A second user reports two SSID VLANs over an **OpenWrt Linksys WRT32X 802.1Q
|
||||
trunk**, with no USG or UniFi switch; the controller network is selected in
|
||||
the SSID's Network dropdown. [Assigning VLANs to SSIDs on Controller
|
||||
6](https://community.ui.com/questions/Assigning-VLANs-to-SSIDs-on-Controller-6/3e656047-685f-470e-954c-703077e89aaa)
|
||||
* A Ubiquiti Community post describes an existing multi-VLAN UniFi deployment
|
||||
with an OpenWrt NanoPi R6S gateway and all UniFi networks configured as
|
||||
Third-party Gateway. [OpenWrt third-party-gateway
|
||||
deployment](https://community.ui.com/questions/Replacing-an-existing-third-party-router-firewall-with-a-UXG-Lite-on-an-existing-UniFi-network/5de2504a-fac2-437a-b893-495a6be2f3c0)
|
||||
|
||||
## Exact mapping for this network
|
||||
|
||||
| Layer | Required configuration |
|
||||
|---|---|
|
||||
| `gfw` / OpenWrt | Only after a tagged path reaches the VM: create/retain VLAN-10 interface, address `192.168.10.1/24`, run the **only** DHCP server for that segment, and apply the intended OpenClash/policy routing. |
|
||||
| U6-to-gfw path | Native/untagged LAN66 for U6 management; tagged VLAN 10 allowed at every switch/link. Do not replace the native LAN with VLAN 10. |
|
||||
| UniFi network | One VLAN 10 virtual network with **Router: Third-party Gateway**. This is controller metadata that makes the AP tag the selected SSID; it is not a DHCP service. |
|
||||
| `ubnt-upg` Wi-Fi | Select that VLAN 10 network. Do not enable UniFi Hotspot/guest portal unless deliberately required. |
|
||||
| Existing Wi-Fi | Leave `ubnt-windy`, `ubnt-windy-2`, and `ubnt-haas` network/VLAN choices untouched; they remain on their existing LANs and DHCP servers. |
|
||||
|
||||
The acceptance test is therefore unambiguous: after reconnecting, a device on
|
||||
`ubnt-upg` must receive `192.168.10.x` from the VLAN 10 gateway, while a device
|
||||
on existing Wi-Fi continues to receive its established LAN address. A
|
||||
`192.168.66.x` lease on the dedicated SSID means VLAN 10 was not selected or
|
||||
did not pass the L2 path; it is not evidence that the U6 should run DHCP.
|
||||
|
||||
## Protecting the existing Wi-Fi during a retry
|
||||
|
||||
The current UniFi UI supports **All**, **Specific**, and **Groups** independently
|
||||
for each SSID's Broadcasting APs selection. [UniFi WiFi SSID and AP Settings
|
||||
Overview](https://help.ui.com/hc/en-us/articles/32065480092951-UniFi-WiFi-SSID-and-AP-Settings-Overview)
|
||||
|
||||
Given the earlier incident where changing a virtual/AP group removed
|
||||
`ubnt-windy` from the U6 Lite, the low-risk control is to leave every existing
|
||||
SSID's Broadcasting APs selection unchanged and set **only `ubnt-upg`** to
|
||||
**Specific → U6 Lite**. Do not reuse or move the default SSID into a temporary
|
||||
group. This does not eliminate the short re-provision/reassociation caused by
|
||||
an AP config push, but it prevents the configuration-level loss of the default
|
||||
SSID that was observed.
|
||||
|
||||
Before enabling the dedicated SSID, inspect the saved settings and AP's
|
||||
effective configuration, then test with one client. Only the dedicated SSID
|
||||
should be affected by a failure; LAN66 DHCP and the existing SSIDs require no
|
||||
change.
|
||||
@@ -0,0 +1,104 @@
|
||||
# UniFi Wi-Fi VLAN 10 with a third-party gateway
|
||||
|
||||
**Research date:** 2026-08-08
|
||||
**Scope:** evidence-backed design only; no controller, AP, switch, EdgeRouter,
|
||||
or OpenWrt settings were changed by this research.
|
||||
|
||||
## Answer: who assigns client addresses?
|
||||
|
||||
Neither a UniFi Network controller nor a UniFi AP is the DHCP server for a
|
||||
normal third-party-gateway deployment. The controller configures the AP; the
|
||||
AP maps a selected SSID to an 802.1Q VLAN and bridges the client's DHCP
|
||||
broadcast into that VLAN. A UniFi **Gateway** can provide DHCP, but Ubiquiti's
|
||||
DHCP documentation expressly describes the DHCP server as a service of UniFi
|
||||
Gateways, not APs or the Network Application. [UniFi DHCP Server](https://help.ui.com/hc/en-us/articles/360012097513-UniFi-DHCP-Server)
|
||||
|
||||
Accordingly, an existing DHCP server on the native/untagged LAN (here, the
|
||||
EdgeRouter X for `192.168.66.0/24`) is expected to answer an SSID that is not
|
||||
actually VLAN-tagged. It must **not** provide the lease for a genuinely
|
||||
separate dedicated VLAN. That VLAN's gateway would provide its DHCP service.
|
||||
|
||||
## Required architecture
|
||||
|
||||
```text
|
||||
client → SSID ubnt-upg → U6 Lite
|
||||
│ VLAN 10 (802.1Q tagged)
|
||||
▼
|
||||
every intervening L2 link permits VLAN 10
|
||||
▼
|
||||
gateway VLAN-10 interface: 192.168.10.1/24 + DHCP + routing/OpenClash
|
||||
```
|
||||
|
||||
The AP's management traffic may remain untagged on LAN66. VLAN 10 is only
|
||||
the client traffic emitted by `ubnt-upg`; it must be carried, tagged, from the
|
||||
U6 Lite through every intervening switch/link to `gfw`. Ubiquiti explicitly
|
||||
states that selecting a network for an SSID makes connected clients members of
|
||||
that VLAN and that all ports between AP and gateway must permit its VLAN ID;
|
||||
it recommends AP uplinks be trunked for the relevant VLANs. [Creating UniFi
|
||||
WiFi SSIDs](https://help.ui.com/hc/en-us/articles/26136823938583-Creating-UniFi-WiFi-SSIDs)
|
||||
|
||||
On a managed UniFi switch, this means the AP uplink and every upstream port in
|
||||
the path have native LAN66 (for AP management) plus tagged VLAN 10. Ubiquiti
|
||||
defines that as a trunk, and warns that an AP uplink must not restrict VLANs
|
||||
needed downstream. [Switch Port VLAN Assignment](https://help.ui.com/hc/en-us/articles/26136855808919-Switch-Port-VLAN-Assignment-Trunk-Access-Ports)
|
||||
|
||||
If a non-UniFi switch is in the path, its 802.1Q settings must be configured
|
||||
equivalently (or it must be verified to transparently forward VLAN 10); UniFi
|
||||
does not manage that switch. This is a physical/L2 requirement, so merely
|
||||
creating a controller network cannot make a VLAN reach `gfw`.
|
||||
|
||||
## Local feasibility result
|
||||
|
||||
The local `gfw` instance is a VM attached only to untagged LAN 66, and the U6
|
||||
Lite's physical path is the same ER-X LAN 66 network. No VLAN-capable physical
|
||||
trunk or verified hypervisor/vSwitch VLAN handoff exists between them. The
|
||||
diagram above is therefore a valid design pattern but **not a description of
|
||||
the current deployable topology**. An `eth0.10` interface inside the VM cannot
|
||||
create that missing L2 path.
|
||||
|
||||
To make this architecture feasible, add a VLAN-capable switch/trunk from AP to
|
||||
gateway, or configure an end-to-end tagged VLAN handoff through the hypervisor
|
||||
and its physical uplink. Until then, leave the ER-X LAN 66 DHCP design in place
|
||||
and do not expect `gfw` to serve an SSID-only subnet.
|
||||
|
||||
## Correct controller model (after the L2 prerequisite exists)
|
||||
|
||||
Use one UniFi virtual network for VLAN 10 whose **Router** is **Third-party
|
||||
Gateway** and whose VLAN ID is `10`; assign that network to Wi-Fi
|
||||
`ubnt-upg`. Configure the subnet, VLAN and DHCP on the VLAN gateway first.
|
||||
This follows Ubiquiti's documented third-party-gateway workflow: create the
|
||||
VLAN on the gateway, then add a UniFi virtual network with Router =
|
||||
Third-party Gateway and the matching VLAN ID. [Creating Virtual Networks
|
||||
(VLANs)](https://help.ui.com/hc/en-us/articles/9761080275607-Creating-Virtual-Networks-VLANs)
|
||||
|
||||
Do not enable a second DHCP service in UniFi for this VLAN. The controller
|
||||
entry is the AP/switch VLAN definition; the gateway on VLAN 10 remains the
|
||||
sole DHCP server and default gateway. The EdgeRouter X's LAN66 DHCP service
|
||||
can remain unchanged because it is for untagged LAN66, not VLAN 10.
|
||||
|
||||
## Safe verification sequence
|
||||
|
||||
1. Read-only confirm on `gfw` that its VLAN-10 interface has
|
||||
`192.168.10.1/24`, DHCP is enabled for `192.168.10.0/24`, and no other
|
||||
DHCP daemon serves that VLAN.
|
||||
2. In the controller, verify `ubnt-upg` selects the Third-party Gateway VLAN
|
||||
10 network, not `Default`/LAN66 and not an unassigned VLAN-only placeholder.
|
||||
3. Trace the U6 Lite-to-`gfw` L2 path and permit tagged VLAN 10 on every link
|
||||
while retaining LAN66 as the AP's native/management network.
|
||||
4. Reconnect a test client (forget/rejoin or renew lease). The expected lease
|
||||
is `192.168.10.x`, gateway/DNS `192.168.10.1` (or the DNS option configured
|
||||
by `gfw`), never `192.168.66.x`.
|
||||
5. Confirm a lease appears on `gfw` and that the VLAN-10 interface's RX/TX
|
||||
counters advance. Ubiquiti's VLAN troubleshooting guide identifies
|
||||
upstream ports not allowing the VLAN as the common cause when Wi-Fi clients
|
||||
cannot receive a correct IP address. [Virtual Network (VLAN)
|
||||
Troubleshooting](https://help.ui.com/hc/en-us/articles/9592924981911-Virtual-Network-VLAN-Troubleshooting)
|
||||
|
||||
## What the observed `192.168.66.91` proves
|
||||
|
||||
It is evidence that the client's DHCP discover reached the LAN66 broadcast
|
||||
domain and was answered by the EdgeRouter X. It does not show a DHCP failure
|
||||
on `gfw`; it shows that the client was bridged untagged (or VLAN 10 was not
|
||||
carried end-to-end) at that attempt. The corrective work is therefore to make
|
||||
the SSID-to-VLAN association and L2 trunk path real, then test the lease—not to
|
||||
make the AP/controller compete with the LAN DHCP server.
|
||||
@@ -7,6 +7,7 @@
|
||||
| IPv4 | `192.168.66.36` |
|
||||
| SSH | `ssh -4 windy@192.168.66.36` |
|
||||
| OS | Debian 12 |
|
||||
| **Host** | **PVE VM 120 (`pihole`)** — not a separate physical host (verified 2026-08-09) |
|
||||
| Roles | AdGuard Home LAN DNS; Mihomo explicit-proxy service |
|
||||
|
||||
Use `windy` for routine inspection. Do not store credentials, AdGuard Home
|
||||
|
||||
+16
-1
@@ -8,6 +8,7 @@
|
||||
| IPv4 | `192.168.66.1` |
|
||||
| SSH | `ssh -4 root@192.168.66.1` (key-only, verified 2026-08-06) |
|
||||
| OS | ImmortalWrt 25.12.0 (r37854), Linux `6.12.87`, x86/64 |
|
||||
| **Host** | **PVE VM 140 (`gfw`)** — dual NIC: `net0`→vmbr0(LAN66), `net1`→vmbr1(LAN55) (verified 2026-08-09) |
|
||||
|
||||
Do not store the root password in this repository.
|
||||
|
||||
@@ -42,6 +43,21 @@ OpenClash runs `/etc/openclash/clash` (clash_meta core) with configuration
|
||||
`8443` is not an OpenClash listener and has no runtime nftables forwarding rule.
|
||||
It is included only in OpenClash's common TLS-sniffing port list.
|
||||
|
||||
## VLAN 10 Wi-Fi feasibility
|
||||
|
||||
`gfw` is a VM attached to untagged LAN 66, rather than a physical VLAN-trunk
|
||||
endpoint. The U6 Lite likewise reaches the ER-X over LAN 66, whose DHCP
|
||||
service supplies client addresses. Therefore `gfw` cannot currently receive an
|
||||
SSID's VLAN 10 traffic merely by creating an `eth0.10` interface inside the VM.
|
||||
|
||||
Do not treat a local `eth0.10`/`192.168.10.1` configuration as a deployable
|
||||
Wi-Fi gateway unless the hypervisor/vSwitch and the complete physical path to
|
||||
the AP have first been configured and verified to carry tagged VLAN 10. The
|
||||
`ubnt-upg` test receiving a `192.168.66.x` lease was the expected consequence
|
||||
of the available untagged path, not evidence that this host should compete
|
||||
with ER-X DHCP. See
|
||||
[UniFi Network: Dedicated Wi-Fi through a third-party gateway](../docs/unifi-network.md#dedicated-wi-fi-through-a-third-party-gateway).
|
||||
|
||||
## Operational note
|
||||
|
||||
When OpenClash logs a LAN client request such as
|
||||
@@ -50,4 +66,3 @@ an explicit-proxy client sending its own loopback request to the gateway. Fix
|
||||
the originating host's `NO_PROXY` / `no_proxy` configuration; do not create a
|
||||
listener on this router to mask the problem. See
|
||||
[the UniFi localhost proxy note](../docs/unifi-openclash-localhost.md).
|
||||
|
||||
|
||||
@@ -8,6 +8,7 @@
|
||||
| IPv4 | `192.168.66.46` |
|
||||
| SSH | `ssh -4 windy@192.168.66.46` |
|
||||
| Hostname | `ubnt` |
|
||||
| **Host** | **PVE VM 160 (`ubnt`)** — not a separate physical host (verified 2026-08-09) |
|
||||
| Privilege | `windy` has passwordless sudo and is in the `docker` group |
|
||||
|
||||
The current SSH ED25519 host-key fingerprint is
|
||||
|
||||
+3
-3
@@ -23,10 +23,10 @@ the software deployed there, see [the LAN overview](../docs/lan-overview.md).
|
||||
| pdns.wsvc.info | Poweradmin UI | — (HTTPS) | → hk2 | active | see hk2 |
|
||||
| pgweb.wsvc.info | PowerDNS Postgres UI | — (HTTPS) | → hk2 | active | see hk2 |
|
||||
| **synapse.chans.xyz** | Matrix homeserver (ESS: Synapse + MAS + Element) | `ssh -4 windy@synapse.chans.xyz` | `169.58.86.13` | **active** | [hosts/synapse.chans.xyz.md](../hosts/synapse.chans.xyz.md) |
|
||||
| **gfw.windy.lan** | OpenWrt (ImmortalWrt) LAN gateway / OpenClash | `ssh -4 root@192.168.66.1` | `192.168.66.1` | **active** | [hosts/gfw.windy.lan.md](../hosts/gfw.windy.lan.md) |
|
||||
| **dns.windy.lan** | AdGuard Home LAN DNS + Mihomo explicit proxy | `ssh -4 windy@192.168.66.36` | `192.168.66.36` | **active** | [hosts/dns.windy.lan.md](../hosts/dns.windy.lan.md) |
|
||||
| **gfw.windy.lan** | OpenWrt (ImmortalWrt) LAN gateway / OpenClash (PVE VM 140) | `ssh -4 root@192.168.66.1` | `192.168.66.1` | **active** | [hosts/gfw.windy.lan.md](../hosts/gfw.windy.lan.md) |
|
||||
| **dns.windy.lan** | AdGuard Home LAN DNS + Mihomo explicit proxy (PVE VM 120) | `ssh -4 windy@192.168.66.36` | `192.168.66.36` | **active** | [hosts/dns.windy.lan.md](../hosts/dns.windy.lan.md) |
|
||||
| **gw** | EdgeRouter X primary LAN gateway | `ssh -4 zhiqiang@192.168.66.254` | `192.168.66.254` | **active** | [hosts/gw.md](../hosts/gw.md) |
|
||||
| **ubnt** | UniFi Network Controller | `ssh -4 windy@192.168.66.46` | `192.168.66.46` | **active** | [hosts/ubnt.md](../hosts/ubnt.md) |
|
||||
| **ubnt** | UniFi Network Controller (PVE VM 160) | `ssh -4 windy@192.168.66.46` | `192.168.66.46` | **active** | [hosts/ubnt.md](../hosts/ubnt.md) |
|
||||
|
||||
`status: stub` = known to exist; fill `hosts/<name>.md` when next touched.
|
||||
|
||||
|
||||
@@ -0,0 +1,2 @@
|
||||
version: 1
|
||||
profile: minimal
|
||||
Reference in New Issue
Block a user