基于 VLAN 的 PPPoE 认证

来自深圳捷联讯通科技有限公司
跳转至: 导航搜索
在大型局域网络中 PPPoE 认证被大规模部署,为了保证网络的稳定,减小广播域,通过 vlan 交换机都创建多个 VLAN 隧道,并汇聚到一台汇聚交换机上,汇聚交换机通
一个 Trunk 口连接到 RouterOS 的内网口,此处配置和上一节的 trunk 配置一样,只是我们不需在每个 VLAN 上配置 IP 地址,而是创建 PPPoE 认证服务如下图,建立多
个 VLAN 后,在 PPPoE-Server 中对每个 VLAN 建立一个 PPPoE 服务,下图是一台 RouterOS 设备配置QinQ 后,创建的 5001 个 PPPoE Servers:
15-11.png
下面是在 interface 中独立 VLAN 下的 PPPoE 运行情况:
15-12.png
: 如果你网络启用了 PPPoE 认证,且有多级的交换机级联,最好使用具备功能 VLAN 的交换机,减小广播域,避免网络广播风暴或病毒产生造成的问题,之前发现未划
分 VLAN 的二层网络,因为没有使用 vlan 隔离造成了用户在 PPPoE 认证后出现随机掉线的情况。


以上的配置网络环境是运营商级别,用户账号带宽分布比例如下图:
15-13.png
在这样网络下基于三款设备,做相同配置的 PPPoE 认证,具体性能测试情况供大家参考:
15-14.png
以上对比是在实际环境得到,当时有大量 QinQ 配置,添加 cacti 监控时,都是在没有创建 QinQ 的情况下先添加接口,因为 5000 条 QinQ 在 cacit 获取接口 SNMP 时
会卡死。还要初始化大量认证配置包括 5000 条 PPPoE认证服务规则,整机达到了 1 万多条规则,基于 x86 服务器的 RouterOS,启动加载要比 CCR 慢,也是问题。
由于测试时间短只有一周多,而且大型运营商网络用户反馈问题,不如小宽带及时,也没有拿到一线情况,只能看到用户认证都正常,所以得到的结论也是不完整的。后续
又对 RouterOS 自己开发的 CCR 系列和 x86 平台做了评估,并不能说明 CCR 系列比 x86 平台占有多少优势,其实 CCR 存在的问题也比较多。(对于之前在 2018年 MUM
提到的 CCR 更好,其实是片面的结论,对此表示抱歉)。
我再次总结下:
21--16.jpg
从以上对比,CCR 构架平台通过多 CPU(9~72 核心)频率在 1~1.2GHz,但单核性能是无法和 x86 平台媲美的,差距是非常明显。虽然有 fastpath 功能,但开启该功能
受限制较多,当遇到大量数据处理时,很容易造成单个 CPU 负载 100%,会对正在转发的网络造成一定影响,因此 CCR 自身构架上存在一些弊端,要实现均衡的调度 CPU
很难,
通常我们查看到系统默认显示的 CPU 负载是平均值,当点开 Resource 下的 CPU 选项,可以看到每个 CPU 的利用率,每个 CPU 利用率并不均衡,部分应用程序还只能
调用一个 CPU,如 bandwidth-test,做带宽测试只会应用一个 CPU。
21--17.jpg
当前 x86 平台的多 CPU 发展也非常快,开启超线程后也能到 72 核心,因此,如果基于大型的 PPPoE 认证,还是建议选择 x86 服务器平台,但 x86 平台 MikroTik 基
本已放弃更新,转向 VM 平台,因此以上内容仅供大家参考。


QinQ 添加脚本[编辑]

由于较大的网络规划,涉及到 QinQ 配置,创建时需配置大量的 vlan 规则,因此这个配置操作手动非常繁琐,下面提供一个添加 QinQ vlan 的脚本,该脚本包括外层和内
层 VLAN 的脚本添加,外层 VLAN 是 2-1000,内层 VLAN 是 2-100
15-15.png
作者:余松

上一页 下一页