RK3566之armvirt转发能力

2024-03-02 作者:

一言以蔽之,同用双核,略逊Pi 4B,明显不如RK3399。虽然制程和频率双双强过BCM2711(Pi 4B),但A55相比A72应该还是有明显差距的…吧,当然发行版对比也略有差异(尽管都基于debian),无法精确对比哈。

至于想劝俺上什么iStoreOS就算了,原因在之前提过,尽管估计物理跑NAT(开启软件流量分载)大概率能接近跑满千兆转发,但选型喜好是很个人的事情,总觉得所谓all-in-one在架构上反过来(upside down)不好玩。

数据上,iperf3上行700左右,下行850,看起来即使另外两核跑个容器带点儿负载,保障个500Mbps宽带应该没啥鸭梨。

完整阅读本篇»

主动散热加持,应对夏天

2023-06-12 作者:

没错,食言而肥

但咱也是有理由的,看下Intel i210AT的spec页面,不难发现如下字样。嗯,虽说CPU飙到80℃没啥问题,但没法保证网卡芯片不会超过70吧,稳妥起见,试一下主动散热。毕竟小小一片网卡也要100大洋,总不算为醋买螃蟹吧。

12V供电,带数码管显示的控制器,可以显示温度(及3个阈值设定)以及当前风扇转速,设定可谓简便易用。

完整阅读本篇»

路由虚拟化,意义何在?

2023-06-04 作者:

见此题目,心急的路由玩家,可能等不及要说,我要all in one啊。

“主路由还要承担NAS、HA、运行docker,甚至一些通用win/linux虚拟机的脚本工作,我已经按大佬教程在ikuai/openwrt上搞了kvm,挺香,你不搞么?”

非也,我是反向操作,先虚拟化,再跑路由,理由也很简单 –

“首先,专业方案解决专业问题,所以尽管底层都是kvm,我不喜欢用一个路由系统做virtualization host,NAS系统也同理。其次,我要极致灵活性和对特殊需求的支持能力。”

对第二点,我举个简单的例子,我希望ikuai实现以下需求 –

  • 对硬件#1物理口做成单臂路由,vlan id 3为WAN去拨号,vlan id 12为LAN,且开DHCP。
  • 然后把#2物理口加入ikuai WAN2(第二条宽带,或者4G wwan转成有线接入做冗余连接备用)。
  • 再把#3物理口加入LAN,而#3物理口vlan id 22放给二级路由的LLAN。
  • 二级路由的WAN不走物理口,直接走host内部虚拟交换机接在ikuai LAN的下边。

如果路由裸装ikuai系统,我不知道是否方便实现,花点心思或许可以吧。但如果物理机是Proxmox VE,我实际遇到的使用场景应该比如上说的还复杂些,完全不是问题,ikuai完全不需要设置任何vlan,如上需求可以都在pve host的linux vlan和bridge的层面做好,进路由看到的完全是多块virtio独立网卡。

“那么今天你要讲,怎么在pve+ikuai上实现这个需求?这种需求一般人用不上,我为何要了解?”

非也,今天想讲下我在家中遇到一个更有意义的需求,给智能电视(尤其某些第三方APP)限速,且主要针对上传速度。


 

首先,为何要限速?观察下图,黑线两侧,是限速前后状态对比。

我们可以很明确的发现,限速前上传速度是4MBytes/s左右,可以说基本把家宽的上行带宽吃完了,此外我们的RK3399被迅速推高了15℃,温度达到70℃左右,别忘记现在还只是春末夏初。

完整阅读本篇»

M.2转接Intel i210千兆

2023-06-01 作者:

先说句题外话,个人不喜2.5G,一直觉得就是民用市场卷出来的临时产品。反正六类线跑电口万兆没问题,2.5G抑或10G都是贵,买个中间态产品?图便宜就留在千兆方案,不差钱直接万兆完事,2.5G这不上不下,就那么几个网卡方案不升级还断流,厂家重视与否么显而易见,对吧。

为什么要提2.5G,前两天说Tinker Board 2s带了一个key A+E的m.2,一旦做路由,这种wifi卡显见没啥用,可以考虑:

  • 另一块网卡,这样路由就不再单臂,更实至名归一些(板子还是天生12v供电,你不做路由谁做路由?)。
  • 扩SATA。也是好主意,但这板自带16GB emmc跑host和kvm足够,还空一个TF卡槽,需要的话插卡就很方便。再扩SATA就没啥必要了,并且SATA供电也得外接,板上并无接口,鸡肋了。
  • 其他PCIe设备,意思不大。

某宝上转了一圈,其实基于i225V B3(或者RTL 8125)的m.2接口2.5G网卡,居然比i210的千兆还便宜20块,赫然写着新版绝不断流……

犹豫再三我还是入了i210版本,综合考虑了自己对2.5G的不感冒,以及RK3399的转发能力,适合自己才是最好的嘛。即使接单块2.5G网卡,再做2.5G单臂路由的话,还需要2.5G vlan switch,没事咱就别给自己挖坑了。

卡么,看板子糙了点儿,但外观毕竟不能当饭吃。

 

完整阅读本篇»

为RK3399换金属壳降温

2023-06-01 作者:

这个没啥技术含量,就看愿不愿意为这么块小铁皮出90块。板子太冷门,周边没人做,所以商家估计本着开张吃半年的原则,这么个壳子收90,而且隔壁还有140的……我感觉140买x86的瘦客户端洋垃圾几乎能买整机了……

效果也比较明显,在室温影响差异不到1℃的前提下,同样被动散热能多拉下来6℃,只能说没有白花的钱,至于值不值就另说了。

完整阅读本篇»

基于CM4 Sensing双WAN冗余路由

2023-05-12 作者:

把手头能玩的板子全玩了一遍,完全停不下来。基于virt-manager和virsh cli的libvirt方案虽然没有PVE的纯web使用便利,但毕竟ARMv8有完全可用的libvirt支持已经很方便了,还要啥自行车哦。

既然Pi 4B据测已经能够很好的承担虚拟化路由职责,那么基于CM4并集成了4G LTE连接能力的CM4 Sensing就完全有能力实现双路外网的负载均衡+故障切换,对吧?

那即使技术实现上的选择已经很清晰,我们还是列一下目前已知的可能途径:

  • 基于一般Linux发行版使用iptables + connmark + policy-based routing直接手打路由。我曾用一台Debian 11 vm做过实验并且跑通了最基本的双wan负载均衡,想来感兴趣这种原始手工方式的玩家想必不是很多,所以也没有过多记录。且继续往下,在Linux上做这些策略的持久化、多ISP定时监控、故障切换,都有大量的脚本工作;而这方面已有大量成熟方案,我的目的仅仅是通过实验理解原理,目的达到,见好就收。感兴趣的可以通过关键词检索相应文章学习,另外B站的“金枪鱼之夜”的课堂录像(上下两集),可以帮你很好的由浅入深搞懂iptables。
  • 直接按Pi 4B编译/下载OpenWrt固件。如我们之前的mwan3负载均衡测试,功能实现上不应存在潜在问题,但这里显然要开始考虑4G/5G模块的驱动编译,wan口支持wwan的相应库的选择,最终编译结果固件的长期可靠性测试,硬件如果升级(比如4G模块,比如CM4载板)必然重新编译……一圈玩下来可以说是实现产品的精力了。
  • 第三个选择就要轻松的多。完全无需重新编译,把我们已经玩6的armvirt镜像直接扔Sensing里,给vm多加一个虚拟网卡eth2,打完收工。

没理解是吧,没关系,先把上一篇《基于Raspberry Pi 4B单臂路由》复习一下,接下来我们看图说话。

完整阅读本篇»