Posts

• 2026-05-16

  【FadianRoam发电漫游】蓝图笔记（3）— SSID投票、数据面方案确定和社区讨论

  今天Telegram群里讨论了不少东西，而且数据面的方案也有了新的想法，记录一下。

  SSID命名投票

  之前一直纠结SSID到底叫什么，是FadianRoam（大写R）还是fadianroam（全小写）还是fadian_roam（下划线），所以直接在群里开了个投票。

  结果出来了：

  • FadianRoam — 60%（3票）
  • fadianroam — 40%（2票）
  • fadian_roam — 0%
  • Other — 0%

  所以就定了，SSID统一用 FadianRoam，大写R。

  

  数据面方案：选了方案B

  上一篇蓝图笔记说了两个方案还在纠结，今天想清楚了，倾向方案B（内部环回 + 归属路由）。

  之前方案B的描述比较简单，现在完善一下设计：

  核心思路

  FadianNet所有站点强制BGP，没有BGP就不能成为FadianNet的骨干节点。大家用自己的ASN通过eBGP互联，组成一个虚拟的BGP骨干网。每个站点分配一个内部环回IP（类似OSPF的Loopback），/32路由在骨干网内通过Regional RR传播。

  用户漫游之后，流量路由回自己的归属站点上网——就是你注册在哪个站点，流量就回到哪个站点出网。

  FadianNet 骨干网（eBGP mesh）
  │
  ├── 站点 A (AS204921) ← 自有互联网出口
  │   ├── FadianRoam AP（自有用户 → 在 A 出网）
  │   └── 非BGP站点 X（挂在 A 下面 → 也在 A 出网）
  │
  ├── 站点 B (AS65001) ← 自有互联网出口
  │   └── FadianRoam AP（自有用户 → 在 B 出网）
  │
  └── 站点 C (AS65002) ← 自有互联网出口
      └── FadianRoam AP（自有用户 → 在 C 出网）
  

  漫游场景

  场景1：站点A的用户跑到站点C连WiFi → 认证通过 → 数据从站点C走FadianNet骨干网回到站点A出网

• 2026-05-15

  【FadianRoam发电漫游】蓝图笔记（2）— 联盟治理、网络分层和数据面设计

  距离上一篇蓝图笔记过了几天，这几天一直在想FadianRoam到底应该怎么设计才合理，之前第一篇写的是头脑风暴阶段，现在终于有了一些比较完整的想法，记录一下。

  FadianRoam 和 FadianNet 到底是什么关系？

  之前一直把这两个混在一起说，但是越想越觉得应该分开，因为它们本质上做的事完全不一样：

  • FadianRoam — 就是认证漫游这一层，你的手机连上FadianRoam这个SSID，802.1X认证，RADIUS请求通过MGMT VPN走到Federation Relay再转发到你的Home Site验证身份，这整个过程就是FadianRoam干的事
  • FadianNet — 认证通过之后你上网的数据要走哪里？走FadianNet。这是一个BGP骨干网，各个BGP站点用自己的ASN互联，提供实际的数据传输

  所以FadianRoam运行在FadianNet之上，SSID、认证、项目品牌都是FadianRoam的，但是你实际上网的流量是FadianNet在承载。

  而且FadianNet本身是公益的！BGP站点之间互联互通是大家一起维护的公共基础设施，不收费。但是FadianRoam作为业务层就不一样了，后面会说到。

  FadianNet的两种角色

  想清楚分层之后，FadianNet的参与者其实分两种：

  FadianNet Site（服务商+使用者）：有自己的ASN，跑BGP，可以给别人提供网络服务，同时自己也用FadianNet。这种就是骨干网的建设者。

  Access Member（纯使用者）：没有ASN，不会BGP也没关系！通过FadianLink连到一个FadianNet Site上，拨PPPoE拿一个/32 IP，AP用户NAT出去就行了。

  所以一个完整的FadianRoam站点，如果你同时能提供BGP网络服务，那你就是FadianRoam Site + FadianNet Site双重身份；如果你只是想部署AP让大家漫游上网，那你就是FadianRoam Site + Access Member。

  联盟治理：>50% 投票制

  这个是今天新想的，之前的加入流程太随意了——提交个PR维护者看看就合并了。但是这不对，FadianRoam是一个联盟，谁能加入应该是大家共同决定的。

  新的流程：

  1. 想加入的人提交PR（带上自己的RADIUS信息）
  2. 所有现有的FadianRoam Site代表在PR上投票（GitHub Review: Approve/Request Changes）
  3. 超过50%的现有成员批准才能加入
  4. 投票期3天

  人少的时候也一样适用这个阈值，2个成员需要2票，3个成员需要2票。至少人少的时候我是这么想的。

  等体系成熟了之后，由核心成员组建「发电委员会」（FadianRoam Governance Committee），负责组织运营、战略决策、争议仲裁这些事。

  VLAN隔离

  每个FadianRoam站点的AP必须做VLAN隔离：

  AP
   ├── SSID: FadianRoam ──→ VLAN 10 ──→ FadianNet (PPPoE /32 出网)
   └── SSID: 你自己的WiFi ──→ VLAN 20 ──→ 本地网络出口
  

  为什么要隔离？因为FadianRoam的流量需要可计量、可审计。如果你把FadianRoam和自己家的WiFi混在一起走，那没法统计也没法做公平使用限制。而且安全上FadianRoam用户也不应该能访问你的本地网络。

• 2026-05-14

  【手搓运营商】自己在家手搓运营商的记录1

  这次是我写的第二个博客文章，今天主要检索了一下心中对于网络的设计的规划，AS204921 v2 指日可待。

  在v1的时候，每一个节点都是手动配置的文件，虽然配置文件都是一套，但是不同的节点还是需要改很多地方，甚至创建Session的时候都是单独复制一遍之前同类型的Session改endpoint，并且之前用的是完全静态的过滤器，每一个Session都需要单独配置，十分麻烦！

  在芸峥实验网v2的环境下，上线了兼容bird（gobgp agent）和Mikrotik（ROS RestAPI）节点管理的配置下发面板（当然是vibe出来的），彻底托管配置，无需手动编辑，可以自定义所有Session以及单独的过滤器和RTBH策略等，所以自动化虚拟骨干网指日可待！

  

  在v1网络中，之前的经验是FullMesh+静态IBGP，每一个端口的endpoint都要配置静态保护路由，才会保证不会掉线，十分不灵活，之前改ospf cost还需要用脚本去检测，但是v2网络中就设计了自动化流程，十分方便。

  一些理解

  但是在之前v1的网络中，我似乎有一个理解错误，那就是 “使用Tunnel LAN 做Peering Endpoint（nexthop）”，这样就丧失了OSPF的意义，因为OSPF的定位就是IGP Peering中传递 内部路由（内网地址） 的协议，也就是说 会有一个 LoopBack CIDR用于 OSPF内部传播，比如YunZhengNet v2 在LoopBack使用的prefix是 10.204.0.0/24 ，那么这一段就是OSPF的Whitelist（个人理解），然后每个router通过OSPF传播自己的 /32，如果在OSPF Mesh中，某个pop上线了传递自己的/32，那就相当于全部成员都有着一条路由表的不同路线。

  参考了一直以来的挚友的建议，她说IBGP Session应该建立到OSPF Pop Endpoint上面，而不是Tunnel Endpoint，这样才能是动态的传递IBGP路由（因为链路层就是IGP的动态），这样似乎才是合理的，OSPF Loopback as Multihop IBGP PeeringLAN(Mabe?)

  顺便之前IBGP起来了之后，不论我加上保护路由，机器还是会掉线，起初我还以为是机器问题，后来才发现，先简历保护路由后起IBGP，因为IBGP也跑的事FullTable所以导入内核的路由就会影响之前配置的静态Endpoint，导致短路。所以新的方法还是稳妥的跟bird一样导入不同table（bird目前是bgp在main，保护路由在table1000）ros同理。

  有趣的事

  不过有一个有趣的点，因为我一直使用RestAPI下发配置给ROS，所以ROS那边会出现下发成功或者下发到一半的时候突然卡住，但是ssh能连上，webui和winbox全都卡住，让我迷惑了很久；询问了Jasper Yu大佬之后，大佬说可能是机器硬件问题maybe？（他不知道我用rest API），我也一度以为是机器硬件有什么问题，直到vibe过程中codex告诉我：是因为添加静态路由的时候会lookup全表，导致webserver拖炸了））如果你们之前也遇到过这样的问题希望给你们解决思路;;;

  

  这是我写的第二篇blog，我不会写，希望各位给予评价和建议，谢谢！

• 2026-05-12

  【FadianRoam发电漫游】类eduroam项目的蓝图笔记（1）

  起初……ywq大佬说 话说群友有没有在自己加建 eduroam 的

  

  在水群一会儿之后：

  

  所以，Fadianroam诞生了！（也是ywq大佬的命名），建立了Telegram交流讨论群组 https://t.me/+WLLU-KOXcQFiMTg1

  最开始啦来了几个感兴趣的初创人员，但是看起来有很多我高攀不起的大佬QAQ!

  不过最初设计的理念其实很简单，也就是：大家只要在家里部署自己的idp+radius部署认证即可，不过我这种蠢人的灵机一动，哆嗦出来了这些想法：

  

  然后继续头脑风暴：

  

  啊这张是开玩笑的（x：

  

  然后与此同时确定了接下来的目标？

  

  持续头脑风暴中：

  

  也体会到了我这种菜鸡看不懂的设计：

  

  所以这大概就是关键进程吧，blueprint网站：fadianroam.yunzheng.space

  在这个过程中，YunZheng Lab IDP出现了：auth.yunzheng.space yeah！

  好吧我还不太会写博客，大概记录了一下项目初期的头脑风暴