第10篇FDB 与 MAC 地址学习MAC 地址表数据中心的通讯录想象你管理一栋写字楼的前台。每天有几百号人出入你需要知道张三在 3 楼、“李四在 7 楼”有快递来了直接送到对的楼层而不是逐层喊。交换机里的FDBForwarding Database也叫 MAC 地址表就是这个前台通讯录。它记录的核心信息很简单MAC 地址端口VLAN类型00:11:22:33:44:55Ethernet4100dynamicaa:bb:cc:dd:ee:ffEthernet8200static有了这张表交换机收到一个二层帧时查目的 MAC 对应的端口直接从那个端口转发出去——不用广播、不用猜。在数据中心里一台 ToR 交换机下面挂着几十台服务器每台服务器可能跑几十个容器每个容器都有独立 MAC。一台交换机的 FDB 可能要维护数万条条目。这就是为什么 MAC 学习必须由硬件 ASIC 完成——CPU 软件学习根本来不及。没有 FDB 会怎样如果交换机不知道目的 MAC 在哪它只能做一件事flooding泛洪——把帧从除入口外的所有端口复制一份发出去。这就像前台不知道张三在哪层只好每层都广播一遍。少量 flooding 没问题但如果每个帧都 flood一台 48 口 100G 交换机上单播帧变广播 → 带宽浪费 47 倍所有端口被无关流量淹没CPU 也会收到大量冗余帧FDB 的核心价值就是把广播域变成点对点转发。硬件学习 vs 软件学习硬件学习ASIC 的看家本领现代交换芯片内置了 MAC 学习逻辑。当一个帧从端口进来芯片在流水线pipeline里做两件事查目的 MAC→ 决定从哪个端口转发或 flood看源 MAC→ 如果不在表里自动写入 “源 MAC → 入口端口” 的映射整个过程在硬件里完成处理时间在纳秒级别。对于一个 100GbE 端口线速意味着每秒约1.488 亿个 64 字节帧。硬件可以轻松应对这个速率下的 MAC 学习软件做不到。硬件 FDB 的存储结构通常是Hash 表优点查找是 O(1)速度快缺点有碰撞collision实际可用容量小于理论值常见实现4-way 或 8-way set-associative hash有些芯片还支持TCAMTernary CAM存储 FDB 条目可以做通配匹配但 TCAM 贵且耗电一般只用于存放少量静态条目。软件学习Linux bridge 的方式在纯软件网络Linux bridge、OVS里MAC 学习靠内核每收到一个帧内核检查源 MAC更新 bridge 的 fdb 表。软件学习的瓶颈在于每个帧都要经过 CPU 中断处理受限于 CPU 频率和内存访问速度通常能处理每秒几十万到几百万帧对虚拟化环境每台物理机上几十个 VM来说这够用但对数据中心硬件交换机需要处理数亿 pps远远不够。SONiC 的策略硬件学、软件管SONiC 采用分层策略┌─────────────────────────────────────────┐ │ 管理层FdbOrch │ ← 软件策略、告警、联动 ├─────────────────────────────────────────┤ │ 通信层Redis syncd │ ← 事件传递 ├─────────────────────────────────────────┤ │ 数据面ASIC │ ← 硬件线速学习 └─────────────────────────────────────────┘ASIC 负责线速学习维护硬件 FDB 表保证转发不受影响学到新 MAC 或 MAC 老化时ASIC 通过 SAI 回调通知 syncdsyncd 把事件写入 RedisSTATE_DBFdbOrch 读取事件更新软件状态、做策略判断、联动其他模块这样硬件永远不会因为软件处理慢而丢包软件也能掌握全局状态做管理决策。FdbOrchMAC 事件的调度员FdbOrch 是 orchagent 内部处理 FDB 事件的模块。它订阅两个数据源APPL_DB 的 FDB_TABLE— 来自管理员配置静态 MACSTATE_DB 的 FDB_TABLE— 来自 ASIC 硬件学习通知它的核心工作是一个事件处理循环不断消费这两个来源的事件。学习事件LEARN当 ASIC 学到一条新 MAC 时事件经过这样的路径ASIC 芯片检测到新源 MAC → SAI fdb_event 回调触发event_type SAI_FDB_EVENT_LEARNED → syncd 进程收到回调 → syncd 写入 STATE_DBFDB_TABLE|Vlan100:00:11:22:33:44:55 → FdbOrch 通过 ConsumerStateTable 订阅到变化 → FdbOrch 验证 更新内部数据结构FdbOrch 拿到学习事件后的验证清单端口存在吗— 如果端口已被删除或 admin down丢弃事件VLAN 有效吗— MAC 必须关联到一个已配置的 VLANVlanOrch 已创建端口属于该 VLAN 吗— 如果端口不是这个 VLAN 的成员事件无效表满了吗— 如果 FDB 容量已满记录日志但无法阻止硬件已经学了通过验证后FdbOrch 把这条 MAC 记录到自己的内部 map 中供其他模块查询。老化事件AGEMAC 表不能无限增长。就像通讯录里离职的人要删掉一样ASIC 有个老化定时器aging timer。工作原理ASIC 为每条动态 MAC 维护一个时间戳每次看到该 MAC 的流量刷新时间戳如果超过 aging time 没看到流量删除条目并通知软件默认老化时间通常是600 秒10 分钟可以通过FDB_AGING_TIME配置项调整。老化的意义释放硬件表项— Hash 表容量有限过期条目占着坑位适应拓扑变化— 服务器迁移、网线重插后旧条目自动清除安全性— 减少过期条目被攻击者利用的风险设置太短的老化时间也有问题如果一台服务器有周期性的低频流量比如每 15 分钟发一次心跳太短的 aging time 会导致 MAC 反复学习-老化-学习产生不必要的 churn。删除事件DELETE主动删除发生在以下场景管理员执行sonic-clear fdb all端口从 VLAN 中移除端口 admin downVLAN 被删除FdbOrch 调用sai_fdb_api-remove_fdb_entry()通知硬件删除对应条目。MAC Move同一个 MAC 换了位置什么时候会发生 MAC move虚拟机热迁移Live MigrationVM 从物理机 A 移到物理机 BMAC 不变但物理位置变了服务器双网卡主备切换主网卡故障备网卡接管 MAC网络环路错误配置导致帧从多个路径到达MAC 在端口间跳动容器调度Kubernetes 把 Pod 调度到不同 NodeASIC 如何处理当 ASIC 收到一个帧源 MAC 已在表里但入口端口不同表中记录MAC-A → Port1 实际收到MAC-A 从 Port3 进来 动作更新为 MAC-A → Port3通知软件 MOVE 事件这个处理是即时的、无条件的——硬件不做判断直接更新。判断这是正常迁移还是异常的工作留给软件。FdbOrch 的 MAC Move 处理# 伪代码defhandle_mac_move(mac,old_port,new_port,vlan):# 1. 验证新端口合法ifnotport_exists(new_port)ornotport_in_vlan(new_port,vlan):return# 2. 更新内部表fdb_map[mac]new_port# 3. 通知相关模块如 NeighOrch 更新 ARP 关联notify_observers(mac,new_port)# 4. MAC move 抖动检测move_count[mac]1ifmove_count[mac]threshold_in_window:raise_alarm(MAC flapping detected,mac)MAC Flapping 检测在错误配置下比如 STP 没跑好导致环路同一个 MAC 会在两个端口间疯狂跳动——每秒可能 move 几百次。这就是MAC flapping。SONiC 的 MAC flapping 检测机制维护每个 MAC 的 move 计数和时间窗口默认阈值5 秒内 move 超过 5 次触发后动作生成 syslog 告警可选禁用端口# syslog 示例 WARNING: MAC 00:11:22:33:44:55 is flapping between Ethernet4 and Ethernet8 in Vlan100静态 MAC vs 动态 MAC特性动态 MAC静态 MAC来源ASIC 自动学习管理员手动配置老化超时后自动删除永不老化MAC move允许被覆盖不可被动态学习覆盖重启后丢失需重新学习从配置恢复典型数量数千到数万通常很少几条到几十条静态 MAC 的使用场景场景一安全锁定关键基础设施设备如带外管理服务器你不希望任何人伪造它的 MAC 接管流量。把 MAC 静态绑定到指定端口后即使攻击者从另一个端口发送相同源 MAC 的帧硬件不会更新表项攻击者的帧会被当作源地址错误处理具体行为取决于芯片实现场景二流量黑洞把某个 MAC 指向 “discard”SAI 里的SAI_NULL_OBJECT_ID或特殊的 drop 端口相当于二层的黑洞路由。所有发给这个 MAC 的帧直接在硬件丢弃。场景三固定路径在某些网络设计中你希望特定流量永远走固定链路比如低延迟交易流量静态 MAC 可以确保转发路径不被动态学习改变。在 SONiC 中配置通过 CONFIG_DB 配置静态 MAC{FDB|Vlan100|00:11:22:33:44:55:{port:Ethernet4,type:static}}配置被 fdbsyncd 读取 → 写入 APPL_DB → FdbOrch 消费 → 调用 SAI 创建静态条目sai_fdb_entry_tentry;entry.switch_idswitch_id;entry.mac_address00:11:22:33:44:55;entry.bv_idvlan_100_oid;sai_attribute_tattrs[2];attrs[0].idSAI_FDB_ENTRY_ATTR_TYPE;attrs[0].value.s32SAI_FDB_ENTRY_TYPE_STATIC;attrs[1].idSAI_FDB_ENTRY_ATTR_BRIDGE_PORT_ID;attrs[1].value.oidport_4_bridge_port_oid;sai_fdb_api-create_fdb_entry(entry,2,attrs);FDB 容量与资源监控不同芯片的 FDB 容量芯片典型 FDB 容量存储方式Memory Memory Memory T3128KHash (4-way)MEMORY Spectrum-2128KHash TCAMBroadcom Memory 56980288KShared memoryFDB 满了会怎样当硬件 FDB 表满时新 MAC 无法被学习发往未知目的 MAC 的帧被 floodingFlooding 消耗带宽、增加其他端口负载极端情况下可能触发广播风暴CRM 监控SONiC 的 CRMCritical Resource Monitoring模块持续监控 FDB 使用率# 查看 FDB 资源使用crm show resources fdb# 输出示例# Resource Name Used Available# --------------- ------ -----------# fdb_entry 12450 115550可以配置高低水位告警crm config thresholds fdb high85crm config thresholds fdb low70当使用率超过 85% 时生成告警低于 70% 后解除。FDB 与其他模块的交互FDB 不是孤立存在的它和 SONiC 里多个模块有紧密联动交互模块关系描述VlanOrchMAC 必须关联 VLANVLAN 删除时级联清除所有相关 MACPortsOrch端口 link down/删除时清除该端口所有动态 MACNeighOrchARP/NDP 邻居解析需要 MAC → Port 映射来确定下一跳出口MirrorOrchERSPAN 镜像可能需要查询目的 MAC 来封装外层帧头AclOrchACL 规则可以匹配源/目的 MAC 做过滤或 QoS 分类MuxOrch双活dual-ToR场景下 MAC 指向 active 还是 standby与 NeighOrch 的协作细节当系统学到一个 ARP 条目IP → MACNeighOrch 需要把它编程为一条邻居表项neighbor entry。这时 NeighOrch 会查 FDB这个 MAC 当前在哪个端口找到后才能确定硬件邻居表项的出口。如果 MAC 还没学到FDB 里没有NeighOrch 会把这条邻居暂存起来等 FDB 学到后再触发编程。这就是为什么有时候 ARP 解析成功了但流量短暂不通——硬件邻居表还没编程完成。实战命令# 查看所有 MAC 条目show mac# 按 VLAN 过滤show mac-vVlan100# 按端口过滤show mac-pEthernet4# 查看 MAC 表计数show mac count# 清除所有动态 MACsonic-clear fdb all# 查看 Redis 中的 FDB 状态redis-cli-n6keysFDB_TABLE*# 查看 FDB 老化时间配置redis-cli-n4hgetallSWITCH|switch小结FDB 表面简单——就是 MAC → 端口的映射。但在数据中心规模下它涉及性能硬件线速学习支撑亿级 pps可靠性老化机制保证表项新鲜度安全MAC flapping 检测防止环路弹性MAC move 支持 VM 迁移等场景联动与 VLAN、端口、邻居等模块深度协作SONiC 通过硬件学习 SAI 回调 FdbOrch 管理的三层架构把这些复杂性优雅地分层处理硬件保证性能软件保证智能。参考资料SAI FDB API: https://github.com/opencomputeproject/SAI/blob/master/inc/saifdb.hSONiC Architecture: https://github.com/sonic-net/SONiC/wiki/ArchitectureCRM HLD: https://github.com/sonic-net/SONiC/blob/master/doc/crm/CRM_requirements.md*上一篇第9篇PortsOrch——端口管理全流程