FIB Trie 路由动画演示
0.1. 内核 FIB Trie 路由效果演示通过动画展示下内核路由树(FIB trie)插入路由时，对应节点的变化。👉 点击这里全屏查看动画
Kernel Study Notes
fib data struct
0.0.1. 综述fib tie是一个多叉树。其原理可以简化为：根据前缀每一位是0还是1， 决定走左子树还是右子树。绝大部分路由树，都没有那么多条目路由，所以再优化下， 多个联系节点只有一个子树,如 仅有两条路由：8.8.2.0/24和8.8.3.0/24, 前面16+6位都完全一样。 多级子树转换成一个节点下多个孩子。 仅有5条路由： 123458.8.4.0/248.8.5.0/248.8
linux内核多路由表与策略路由的实现
0.1. 使用场景接上篇文章，我们提到在网口eth1 上增加一个 ip 地址，内核会生成 3 个路由。 local 路由表：增加/32 主机路由 main 路由表：增加本网段前缀的网络路由 为什么需要使用local/main 两个路由表呢？ ip地址引发的路由变化或者手动添加一个目的网段的路由，这些场景看起来，完全可以使用一个路由表就能满足场景需求。那内核为什么要支持多个路
内核如何管理 local(主机)路由表
今天遇到一个有意思的问题：Q：Linux系统在内核初始化完成后，默认创建了多少个路由表？这个问题在技术社区中存在不少争议，无论是询问AI、Google搜索还是查阅博客，都能得到各种不同的答案。问题的核心争议点在于：内核如何管理主机路由（local路由）对应的本地路由表。下面让我们逐步分析不同的观点： 0.1. step 1：咨询deepseek，系统创建了 4 个路由表DeepSeek不仅给出了结
ping本机网口的IP地址，tcpdump在lo口才能抓到对应报文
0.0.1. 问题背景Q1：ping 本机eth1口的ip地址时，对应的ICMP报文会被发送到eth1口上吗？ 0.0.1.1. 实验： ping本机网口地址 通过tcpdump抓包命令，我们发现报文被发送到lo上，而不是对应的物理口 eth1。虽然ip 地址被配在本机的物理口上，但是报文并没有被发送到物理口。为了理解这个问题，我们需要先看下下面这个问题。 Q2： 当一个IP地址被添加到一个网口后
fib_unmerge：把local路由从main表里切割出来
fib_unmerge 是内核路由子系统中一个精巧的按需优化设计： 默认状态下，local 表只是 main 表的别名，所有路由合并在一张表里，fib_lookup 只需查一次表，性能最优 添加策略路由时，fib_unmerge 将 local 路由从 main 表中切割出来，放入独立的 local 表，确保策略路由能正确匹配 切割四步走：创建新 local 表 → 复制 local 路由 →
lo口与local路由表
0.0.1. 小实验接上篇文章 ping本机网口的IP地址，tcpdump在lo口才能抓到对应报文，我们知道在网口eth1上增加一个IP地址192.168.8.8/24后，内核会生成3条路由： local表：增加192.168.8.8/32的主机路由（RTN_LOCAL） main表：增加192.168.8.8/24的网段路由（RTN_UNICAST） local表
tcpdump命令与网口`PROMISC`状态标志位
0.1. 问题现象tcpdump/iproute2 是很多网络问题下的调试工具，大家也都很熟他的一些特性。比如， 执行tcpdump命令后，如果没有使用-p参数, 网口会进入PROMISC状态。 通过ip link命令可以查看网口状态，其中状态位里有个PROMISC标志。但是，后台执行一个在 eth0 口上抓包的tcpdump命令，就会发现一个问题： 当tcpdump命令在后台运