基于 VLAN 的 PPPoE 认证
来自深圳捷联讯通科技有限公司
- 在大型局域网络中 PPPoE 认证被大规模部署,为了保证网络的稳定,减小广播域,通过 vlan 交换机都创建多个 VLAN 隧道,并汇聚到一台汇聚交换机上,汇聚交换机通
- 一个 Trunk 口连接到 RouterOS 的内网口,此处配置和上一节的 trunk 配置一样,只是我们不需在每个 VLAN 上配置 IP 地址,而是创建 PPPoE 认证服务如下图,建立多
- 个 VLAN 后,在 PPPoE-Server 中对每个 VLAN 建立一个 PPPoE 服务,下图是一台 RouterOS 设备配置QinQ 后,创建的 5001 个 PPPoE Servers:
- 下面是在 interface 中独立 VLAN 下的 PPPoE 运行情况:
- 注: 如果你网络启用了 PPPoE 认证,且有多级的交换机级联,最好使用具备功能 VLAN 的交换机,减小广播域,避免网络广播风暴或病毒产生造成的问题,之前发现未划
- 注: 如果你网络启用了 PPPoE 认证,且有多级的交换机级联,最好使用具备功能 VLAN 的交换机,减小广播域,避免网络广播风暴或病毒产生造成的问题,之前发现未划
- 分 VLAN 的二层网络,因为没有使用 vlan 隔离造成了用户在 PPPoE 认证后出现随机掉线的情况。
- 以上的配置网络环境是运营商级别,用户账号带宽分布比例如下图:
- 在这样网络下基于三款设备,做相同配置的 PPPoE 认证,具体性能测试情况供大家参考:
- 以上对比是在实际环境得到,当时有大量 QinQ 配置,添加 cacti 监控时,都是在没有创建 QinQ 的情况下先添加接口,因为 5000 条 QinQ 在 cacit 获取接口 SNMP 时
- 会卡死。还要初始化大量认证配置包括 5000 条 PPPoE认证服务规则,整机达到了 1 万多条规则,基于 x86 服务器的 RouterOS,启动加载要比 CCR 慢,也是问题。
- 由于测试时间短只有一周多,而且大型运营商网络用户反馈问题,不如小宽带及时,也没有拿到一线情况,只能看到用户认证都正常,所以得到的结论也是不完整的。后续
- 又对 RouterOS 自己开发的 CCR 系列和 x86 平台做了评估,并不能说明 CCR 系列比 x86 平台占有多少优势,其实 CCR 存在的问题也比较多。(对于之前在 2018年 MUM
- 提到的 CCR 更好,其实是片面的结论,对此表示抱歉)。
- 我再次总结下:
- 从以上对比,CCR 构架平台通过多 CPU(9~72 核心)频率在 1~1.2GHz,但单核性能是无法和 x86 平台媲美的,差距是非常明显。虽然有 fastpath 功能,但开启该功能
- 受限制较多,当遇到大量数据处理时,很容易造成单个 CPU 负载 100%,会对正在转发的网络造成一定影响,因此 CCR 自身构架上存在一些弊端,要实现均衡的调度 CPU
- 很难,
- 通常我们查看到系统默认显示的 CPU 负载是平均值,当点开 Resource 下的 CPU 选项,可以看到每个 CPU 的利用率,每个 CPU 利用率并不均衡,部分应用程序还只能
- 调用一个 CPU,如 bandwidth-test,做带宽测试只会应用一个 CPU。
- 当前 x86 平台的多 CPU 发展也非常快,开启超线程后也能到 72 核心,因此,如果基于大型的 PPPoE 认证,还是建议选择 x86 服务器平台,但 x86 平台 MikroTik 基
- 本已放弃更新,转向 VM 平台,因此以上内容仅供大家参考。
QinQ 添加脚本[编辑]
- 由于较大的网络规划,涉及到 QinQ 配置,创建时需配置大量的 vlan 规则,因此这个配置操作手动非常繁琐,下面提供一个添加 QinQ vlan 的脚本,该脚本包括外层和内
- 由于较大的网络规划,涉及到 QinQ 配置,创建时需配置大量的 vlan 规则,因此这个配置操作手动非常繁琐,下面提供一个添加 QinQ vlan 的脚本,该脚本包括外层和内
- 层 VLAN 的脚本添加,外层 VLAN 是 2-1000,内层 VLAN 是 2-100
作者:余松 |
上一页 | 下一页 |