IP 转发与 Overlay

• TTL/Hop Limit 每跳减 1
• IPv4 首部校验和需要更新，IPv6 无首部校验和
• 校验和更新方式（增量更新）

转发时 IPv4 的 TTL 和 IPv6 的 Hop Limit 每经过一跳路由器都减 1，减到 0 时丢弃并回送 ICMP 超时（IPv4 用 ICMPv4 type 11，IPv6 用 ICMPv6）。差异在于校验和：IPv4 首部包含 checksum 字段（覆盖整个首部），TTL 变化后发送端必须重新计算/更新首部校验和，路由器通常用增量更新（incremental update）只对变化的字段做调整，避免全量重算；IPv6 首部没有校验和，Hop Limit 变化无需更新任何校验和，因而转发更简单高效。IPv6 的传输层校验和（TCP/UDP）因依赖伪首部，在 IPv6 下是必选的（IPv4 的 UDP 可选）。

IPv6 移除首部校验和是"简化转发"的体现，因为链路层已有较强差错检测，且每跳重算校验和增加开销。这是 IPv4 与 IPv6 在转发路径上的本质差异之一。

• LSA 类型 1-5（Router、Network、Summary、ASBR、External）
• 区域类型与外部路由（Type 4/5）的过滤
• 默认路由注入

OSPF LSA 类型：Type 1（Router LSA）描述本路由器的链路；Type 2（Network LSA）由 DR 生成描述网络；Type 3（Summary LSA）在区域间传递，描述区域外网络；Type 4（ASBR Summary LSA）描述 ASBR 可达性；Type 5（External LSA）描述区域外（AS 外部）路由，由 ASBR 生成。区域类型限制外部路由：stub 区域不接收 Type 4/5（外部路由），只保留内部与区域间路由，并注入默认路由；totally-stubby 区域进一步也不接收 Type 3（区域间明细），只保留默认路由和内部路由；nssa 区域允许在区域内通过 Type 7 LSA 引入外部路由，但区域间不传递 Type 5，由 ABR 把 Type 7 转成 Type 5 后再发布。stub 系列省去外部路由的洪泛，减小路由表与开销。

区域类型本质是"控制哪些路由允许进入区域"，stub 剔除外部路由（Type 4/5），totally-stubby 再剔除区域间明细（Type 3），nssa 则是"允许本地引入外部但隔离于主干外部洪泛"。核心是隔离与路由规模控制。

• 最长前缀匹配原则
• 转发查表与路由决策
• 策略路由（ip rule/PBR）介入

最长前缀匹配（LPM）指在有多个路由前缀重叠（如 10.0.0.0/8 与 10.1.0.0/16）时，选择前缀长度最长（更具体）的那条路由，因为更具体的路由更精确地描述目的地址。传统转发流程是"查目的地址→最长前缀匹配→选下一跳"。策略路由（PBR）改变了这一流程：它先按多项条件（如源地址、入接口、TOS、fwmark、5 元组）匹配策略规则，再根据规则命中的路由表及其优先级决定走哪条路径，而不只是按目的地址查表。Linux 中用 ip rule 定义策略数据库，ip route 的 rule 域基于优先级和匹配条件选择路由表，从而在目的地址之外补充源地址、fwmark 等维度。

LPM 解决"目的地址有多条路由"的选路，是"最具体优先"；PBR 解决"同一目的想走不同路径"，通过"先匹配策略、再选路由表"改变默认的目的地址查表。两者是"路由选择"与"路由策略"的分工。

• IS-IS 直接跑在链路层 vs OSPF 跑在 IP 上
• 扩展性（IS-IS 的 TLV 机制）
• 运营商骨干与 IPv6

IS-IS 直接运行在数据链路层（封装在 L2 帧中），使用 TLV 扩展，不依赖 IP 地址，因此天然支持 IPv6 和 MPLS 等；OSPF 直接运行在 IP 之上（OSPFv2 用 IPv4、OSPFv3 用 IPv6），基于 LSA 洪泛。扩展性上，IS-IS 的 TLV 结构使得新增协议能力（如 IPv6、TE、Segment Routing）只需新加 TLV，比 OSPF 的固定 LSA 结构更灵活，是运营商骨干广泛选 IS-IS 的原因之一；同时 IS-IS 的 Level-1/2 两级层次与 OSPF 的 area 类似。IPv6 时代：OSPFv3 支持 IPv6 但 OSPFv2 不支持，IS-IS 通过 TLV 同时承载 IPv4/IPv6，且配合 SRv6 等新能力，在运营商骨干（尤其双栈+SR）中地位仍很稳固；OSPF 在企业和数据中心仍广泛使用。

差异核心是"协议层级"（L2 vs IP）与"扩展机制"（TLV vs 固定结构）。IS-IS 的 TLV 扩展性+承载 IPv6 与 SR 的能力，使其在运营商骨干保持优势；OSPFv3 与 IS-IS 在 IPv6 上各有场景。

• rp_filter（反向路径过滤）三种模式
• 源地址选择（源地址策略）
• 策略路由与多接口回程

Linux 双网卡主机上，若回程包从与路由表不一致的接口到达，rp_filter（net.ipv4.conf.*.rp_filter）会按反向路径过滤：mode 0 关闭、mode 1 严格（strict，要求源地址能够从收到接口回程）、mode 2 宽松（loose，只需源地址可达任一接口）。排查时先确认为何"走错接口"：检查源地址选择（源地址策略，Linux 用 ip rule 的 src 或路由表里的 src 字段决定源地址），若源地址与出接口不匹配，回程会走错接口并被严格 rp_filter 丢弃。这时需联合检查：1) rp_filter 模式（网络侧设严格需保证回程路径可逆）；2) 源地址选择（路由表 src 是否与接口一致）；3) 策略路由（用 ip rule 按源地址/入接口把回程分到正确路由表）。通常设 rp_filter 为 loose 或按需添加策略路由，或用 ip rule 的 iif 规则强制回程。

"回程走错接口"的根因是"源地址→出接口→路由表"三者不一致。rp_filter 只是"侦探"，真正修复要靠源地址选择与策略路由把回程绑定到正确接口。

• ip rule 策略数据库与 ip route 路由表
• lookup fail mode 与回退
• 源地址选择回环根因

Linux 的源地址选择在确定路由后，会反查"该路由能否带出该源地址"：即用目的地址、源地址、出接口等信息查路由表，看是否存在匹配路由。若策略路由（ip rule）中某条规则 lookup 失败（无匹配路由）且未配置 fail mode 回退，或用对端地址做源地址选择时默认落到 local 表，可能选出 127.0.0.1 之类的回环地址。具体"回环"根因：当路由表里没有与源地址匹配的项，源地址选择会遍历所有路由表，若某规则 lookup 的表中没有合适源地址，可能落到默认的回环表（local 表）或按规则回退，导致选出的源地址是 127.0.0.1/::1，再从错误接口发出。fail mode 决定 lookup 失败时是否继续尝试下一条规则。

源地址选择是"目的路由确定后反查源"，若策略路由表与该源地址不匹配或 lookup 失败回退不当，就会取到回环地址。修复需保证源地址所在路由表与出接口一致，并正确配置 fail mode 与 rule 顺序。

• URPF 原理与不对称路由
• 严格模式（strict）与宽松模式（loose）
• 场景适用

URPF 在收到数据包时，以源地址为"目的地址"反向查路由表，判断该源地址是否应从收到该包的接口到达：严格模式要求源地址必须能从收到接口恰当地回程（即路由表里该源地址的最佳路径指向收到接口），否则丢弃；宽松模式只要求源地址存在可达路由（任意接口可达即可），不要求回程接口一致。不对称路由下，去程走 A 回程走 B，若严格 URPF 开启，从 B 接口收到的包反向查表发现源地址应走 A，接口不符，被丢弃。严格模式适用于边界设备、对称路由、防 spoofing 严格场景；宽松模式适用于有不对称路由或复杂拓扑的网络，用于防 DoS 的同时容忍非对称路径。

URPF 把"反向查表"作为合法性校验，天然与不对称路由冲突。严格模式过滤强但要求路径对称，宽松模式容忍不对称但过滤弱。选型取决于网络是否对称与安全需求。

• SLAAC 与 RA 前缀自动配置
• DHCPv6 有状态配置
• 默认路由来源（RA）

IPv6 主机通过 RA（路由器通告）触发 SLAAC：根据 RA 中的前缀自动生成地址（EUI-64 或随机），并根据 RA 的 other-config 标志判断是否需要 DHCPv6 获取其他参数（如 DNS）。两者可协同：SLAAC 提供地址，DHCPv6 提供额外配置（有状态地址或 DNS 等参数）。默认路由由 RA 提供，RA 携带 Router Lifetime 和默认网关信息，主机据此在路由表中建立默认路由，而不是由 DHCPv6 提供。临时地址（privacy address，RFC 4941）是主机为隐私保护生成的随机/临时 IPv6 地址，周期性更换，用于外发连接，避免泄露基于 EUI-64 的稳定 MAC 衍生地址，与 SLAAC 的稳定地址共存。

协同关系是：SLAAC 管地址与默认路由（RA），DHCPv6 管额外参数（有状态地址/DNS），临时地址是隐私增强。默认路由一定来自 RA（无状态），这是 IPv6 的关键特点。

• ip rule 的 priority 排序
• 匹配字段（src/dst/fwmark/iif/oif/tos）
• 命中即用、查表与回退

ip rule 按 priority 从小到大排列，每一条规则由一组匹配条件（src/dst/fwmark/iif/oif/tos 等）和动作（lookup 某路由表、goto、from 表等）组成。内核按 priority 顺序逐条匹配，命中条件后执行该规则的 lookups 动作（查指定路由表），若查表成功则用该表结果；若查表失败，根据规则是否带 fail 处理决定是否继续下一条规则。多条规则叠加的语义是"顺序裁决 + 首条命中优先"：先通过高优先级（小数值）规则筛选，命中后即用其路由表，未命中才落到更低的规则，最终落到默认的 local/main 表。fwmark 等可为特定流量打标，再路由到指定表。

策略数据库是"按优先级的有序过滤器"，每条规则决定"这类流量查哪张表"。多条规则叠加实现"先细分再回退"的层次化路由，是 PBR 的基础。

• RTNH 与多下一跳（ECMP）
• 递归下一跳解析
• 数据面安装

路由表项（fib_route）中的下一跳（RTNH）描述转发目标。ECMP 时一条路由对应多个 RTNH（next hop 列表），转发时按哈希选择其中一个，实现等价多路径负载均衡。递归下一跳（recursive next hop）指下一跳本身不是直连接口，而是一个需要再解析的地址（如 BGP 的 next hop 是一个远端地址，需递归解析到直连的 IGP 路由），解析链工作：路由表先记录下一跳地址，再递归查该地址的直连路由，直到找到出接口与 L2 地址，最终安装到 FIB/硬件转发表。若递归解析失败（如 IGP 路由消失），该路由不可用，触发重新收敛。

RTNH 是"路由到下一跳"的抽象，ECMP 是"多下一跳并行"，递归是在"下一跳需要再解析"时逐层展开。理解解析链对排查 BGP/IGP 联动故障很关键。

• 邻居状态机各状态含义
• 状态迁移条件
• 探测时机（PROBE）

邻居状态机（IPv4 ARP 与 IPv6 NDP 类似）：INCOMPLETE 表示收到解析请求但尚未得到地址，此时会发送解析请求；收到响应后进入 REACHABLE。REACHABLE 超时（reachable time）后进入 STALE（过期但未确认不可达）。STALE 状态下若有流量需要发送，不会立即探测，而是进入 DELAY（延迟确认）；DELAY 期间若收到流量确认则回到 REACHABLE，否则 DELAY 超时后进入 PROBE。PROBE 阶段才真正发送邻居探测（单播 NS/ARP 请求），连续多次（默认 3 次）无响应则进入 FAILED/INCOMPLETE 并可能回收。因此探测只在 PROBE 阶段发送，STALE 到 DELAY 是"等确认"的缓冲，避免过早探测。

状态机设计意图是"非必要不探测"：STALE 只过期不探测，DELAY 用流量来"顺便确认"，只有确认失败才 PROBE 主动发探测。这平衡了邻居新鲜度与探测开销。

• VRF 与 netns 的隔离粒度
• 内核实现（路由表、表编号）
• VRF 路由泄漏（import/export、外卡）

网络命名空间（netns）是内核级完全隔离的网络环境：每个 netns 有独立的协议栈、路由表、接口、防火墙、socket 等，隔离性强，但开销大、资源重复。VRF 是更轻量的"虚拟路由与转发域"：在系统内共享协议栈与接口，但通过独立的虚拟路由表（Linux 用独立路由表编号 + l3mdev 规则）隔离转发，接口可绑定到某个 VRF。根本差异是隔离粒度：netns 隔离整套网络栈，VRF 只隔离路由表（和部分三层转发），故 VRF 更轻量、资源共享。多 VRF 路由泄漏实现：Linux 用 VRF 的 l3mdev 规则 + 显式把路由导入/导出（如通过 policy routing 在 VRF 表之间 add 路由，或用 4.6+ 的 VRF 设备 + ip route add 指向另一 VRF 的接口），也可用 ip rule 把 VRF 表的内容引入另一表，或通过 BGP/L3VPN 的 import/export RT 实现。

"netns 隔离整套协议栈，VRF 只隔离三层路由表"是核心差异。路由泄漏本质是"在独立路由表之间按需打通"，用 l3mdev、ip rule 或 L3VPN 的 RT 机制实现。

• BFD 与路由协议 hello 的分工
• BFD 的毫秒级检测（3 次握手）
• 故障检测与路由收敛联动

路由协议（OSPF/IS-IS/BGP）的 hello 用于建立和维护邻居，但 hello 间隔通常为秒级（如 10s），故障检测慢。BFD 是独立的快速转发检测协议，在一跳/多跳链路上以毫秒级间隔（如 100ms 甚至更低）发送 BFD 报文，检测到对端连续丢失（通常 3 次）即判定链路故障，并快速通知上层的路由协议、VRRP、MPLS 等。BFD 与路由协议 hello 的关系是"解耦"：BFD 只负责快速检测链路状态，路由协议把 hello 的检测职责接给 BFD 的反馈，从而把收敛时间从秒级降到毫秒级。BFD 的作用是"快速感知故障、触发快速收敛"，是毫秒级故障检测的关键。

路由协议 hello 慢，BFD 快，二者配合"BFD 检测 + 协议收敛"。BFD 作为一个独立检测载体，可被多个协议共用，避免每个协议都开快间隔 hello 的开销。

• 策略路由/规则优先级
• VRF 与路由表归属
• 邻居项、netfilter、offload

路由存在但无法转发，按如下层次排查：1) 规则优先级——确认 ip rule 中该流量命中的规则是否查到了含目标路由的表，是否存在更高优先级规则把流量导到错误表或 drop；2) VRF——确认接口的 VRF 归属与路由表，流量是否落到了错误的 VRF 表；3) 邻居项——确认目标下一跳的 ARP/NDP 邻居是否可达（INCOMPLETE/不可达会导致无法封装 L2）；4) netfilter——检查 iptables/nftables 的 FORWARD 链、filter/raw 规则是否 drop 或 log；5) 设备 offload——确认硬件转发表（如 TC flower offload、路由 offload）是否与控制面同步，devlink/hw 表是否过期导致数据面不转发。按此顺序逐层定位，可快速隔离是"路由决策"还是"数据面"问题。

"路由存在但不可转发"往往是"决策与执行不一致"：规则/VRF 决定"查哪张表"，邻居决定"能否封装"，netfilter 决定"是否放行"，offload 决定"硬件是否执行"。逐层排除是系统化定位的路径。

• xfrm 策略（SPD）与路由的关系
• 策略路由与 xfrm 交叉
• IPsec 选路的复杂性（多隧道、多源）

Linux 的 IPsec 使用 xfrm 策略（SPD）来决定哪些流量应加密/解密，路由决定流量去向。两者在策略路由下交叉生效：发出流量先经 xfrm 策略匹配决定是否加密及用哪个隧道（按 src/dst/fwmark/协议等匹配），加密后的外出接口选择又依赖路由；若用策略路由（ip rule），同一目的地址可能因源地址、fwmark 而定不同的隧道/路由。因此 IPsec 隧道选路不能仅依赖目的地址，因为同一目的地址可能对应多个隧道（不同源、不同安全域、不同 fwmark），需要结合 xfrm 策略（目的、源、fwmark）与路由共同决定。若只按目的地址选路，可能把流量发错隧道或不加密到达。

xfrm 策略是"哪些流量进哪个隧道"的决策，路由是"怎么走"的决策，二者在策略路由下联合生效。IPsec 的多隧道/多源场景要求选路维度包含 fwmark、源地址等，不能只看目的。

• offload 路由缓存与一致性
• devlink reload
• 软件回退与 fallback

现代 NIC 支持把路由/流表 offload 到硬件转发表，控制平面（内核）变更路由时，若硬件表未同步更新，数据面会按过期表转发。排查时用 devlink 检查硬件转发状态（devlink dev param、devlink trap），并用 devlink reload 触发硬件重新加载/重同步，使设备重新下发路由表。若硬件 reload 失败或不可用，可回退到软件转发：关闭 offload（如 ethtool -K 或 TC 的 skip_hw 标志、devlink 关闭 offload 参数），让流量回到内核软件转发路径，保证正确性。实现路径是"devlink 同步硬表 + 失败时回退软件转发"。

offload 提升了转发性能，但引入"控制面与硬件表一致"问题。devlink reload 是显式重同步手段，软件回退是保证正确性的兜底，两者结合确保 offload 失败不影响转发。

• Router Lifetime 与默认路由失效
• RA 的前缀/路由选项
• 兼容行为

IPv6 RA 的 Router Lifetime 指示这台路由器作为默认路由的有效时间。若为 0，主机应立即停止（或很快停止）将该路由器作为默认路由使用，即从路由表中移除该默认路由。实际中，Router Lifetime 为 0 意味着"此路由器不再作为默认网关"，主机收到后不再使用它转发无前缀流量。RA 中的 route information option 可携带具体前缀对应的路由（而非仅默认路由），其 Lifetime 独立控制这些前缀路由的存活；当 Router Lifetime 为 0 时，默认路由失效，但 route option 指定的具体前缀路由可依据各自 Lifetime 继续存在。兼容行为：旧主机可能忽略 route option、只处理默认路由，因此需保证 RA 同时提供默认路由或前缀路由。

Router Lifetime 管"默认路由寿命"，route information option 管"具体前缀路由寿命"，两者独立。Router Lifetime=0 剥夺默认路由，但不必然清除带独立 Lifetime 的前缀路由。

• GRE 无加密、IPsec 有加密
• 封装开销与隧道模式
• 密钥管理（IKE）

GRE 隧道只做封装（GRE 头 + 外层 IP），不提供加密，也无需密钥管理，开销小（约 24 字节），适合封装多协议、用于隧道承载。IPsec 隧道模式既封装又加密，提供机密性、完整性和认证，安全性高；但开销大（ESP 头、IV、认证尾等，约 50-60+ 字节），且需要密钥管理（IKE 协商 SA、密钥生命周期，也可用预共享密钥或证书）。加密边界上，GRE 不做加密，明文传输；IPsec 在隧道边界加密，隧道内数据机密。部署上常两者结合（GRE over IPsec 或 IPsec tunnel 内承载 GRE），以兼顾多协议封装与加密。

GRE 是"纯封装"，IPsec 是"封装+加密+认证"。开销、安全与密钥管理的差异是选型核心：需要机密性用 IPsec，仅需封装用 GRE。

• cryptokey routing（对端到密钥到地址映射）
• SPD 基于策略的路由
• 配置思路差异

WireGuard 采用 cryptokey routing 模型：每个对端（peer）绑定一个公钥和一组允许的 IP 地址（AllowedIPs），流量通过"目标地址是否在某个 peer 的 AllowedIPs 内"来决定使用哪个对端及其密钥，即"地址到公钥到加密隧道"的映射，无需单独的 SPD 策略表。传统 IPsec 用 SPD（安全策略数据库）按 5 元组/协议等策略规则决定哪些流量走哪个 SA，配置复杂（策略、握手、SA 生命周期）。根本差异：WireGuard 把"路由决策"与"密钥/加密"耦合进一个简单的 peer+AllowedIPs 模型，配置极简、无状态 SA 管理；IPsec 把策略与封装分离，策略自由度高但配置繁琐。WireGuard 的 AllowedIPs 同时充当路由来源与加密路由表。

WireGuard 用"允许 IP 集合"一行完成"路由+加密"绑定，IPsec 用 SPD 策略表做灵活策略路由。WireGuard 简洁但策略粒度粗，IPsec 灵活但复杂。

• 多层封装与 MTU 黑洞
• ICMP 被过滤导致 PMTUD 失效
• 系统排查

隧道嵌套（VXLAN over IPsec）意味着多层封装叠加，外层总头长（VXLAN 50 + IPsec 50+）会让内层 MTU 显著变小，若各层 MTU 未协调，大包分片或黑洞概率大增。PMTUD 依赖 ICMP "需要分片"反馈，但在隧道嵌套中，中间设备的 ICMP 常因安全策略被过滤，且 ICMP 报错可能本身也超过 MTU 或被打包在隧道内无法回传，导致发送端收不到反馈，PMTUD 失效，形成黑洞。系统排查：1) 逐层核对每层接口 MTU（物理、VXLAN、IPsec、veth）；2) 用 ping 带 DF 分级测各层可用 MTU；3) 抓包确认是否收到 ICMP fragmentation needed、ICMP 是否被过滤；4) 在应用层设置合适的 MSS clamp（把 MSS 调成内层 MTU-40）；5) 用支持 PLPMTUD 的协议/工具主动探测、不依赖 ICMP。

嵌套隧道把"每层都要算 MTU"的复杂度放大，且 ICMP 在多跳隧道中更容易被过滤。根因是"多封装 + ICMP 依赖"叠加，解法是"主动探测 + MSS clamp + 逐层 MTU 统一"。

• LDP 与 RSVP-TE 的标签分发机制
• L2VPN/L3VPN 的分工
• 控制面故障与转发

LDP 基于 IGP 自动分发标签（为每个 IGP 前缀分发标签），无需显式路径，配置简单、适合大规模 IP/MPLS 转发，但只做最短路径分发、不支持 TE。RSVP-TE 通过显式路径（Explicit Route）建立带带宽预留的隧道，支持流量工程（TE）与快速重路由（FRR），但需要逐条配置、状态多、扩展性差。L2VPN 用 LDP 分发伪线标签（PW），L3VPN 用 LDP 分发 VPN 标签 + BGP 分发 VPN 标签（外层 VRF 标签）；RSVP-TE 常用于隧道的 TE/Fast Reroute。关于控制平面故障：转发依赖标签转发表（LFIB），若控制面（LDP/RSVP 会话）故障，已有标签转发表仍可继续转发（数据面独立工作），但新标签无法分发、重收敛受影响，可能因标签过期/未更新导致转发中断，FRR 或备份路径可缓解。

LDP 简单自动、适合大规模；RSVP-TE 支持 TE/FRR 但复杂。转发与控制面解耦（数据面可用已有标签继续转），但控制面故障影响更新与收敛，需 FRR 等保护。

• Geneve 的可变长 TLV
• VXLAN 固定头部限制
• SDN 控制面的可编程性

VXLAN 头部固定（8 字节 VXLAN 头，含 VNI 和保留字段），无法携带可选元数据，扩展性受限。Geneve 头部在固定的 8 字节基础上支持可变长 TLV（Type-Length-Value）选项，可携带任意上下文元数据（如租户信息、虚拟网络上下文、服务链信息等），由控制面（如 OpenFlow/OVN）定义和下发，因此扩展性更强、支持 SDN 的可编程需求。SDN 控制面青睐 Geneve 的原因：TLV 让控制面可灵活封装任意编排元数据，作为 OVN/SDN 的通用隧道后端，实现租户隔离、服务链、可观测性等，而 VXLAN 的固定头难以承载这些扩展语义。

核心是"固定头 vs 可变 TLV"。Geneve 把"可扩展元数据"作为一等公民，正是 SDN 控制面需要下发的编排信息，而 VXLAN 的固定头限制了表达力。

• 三个分片字段的作用
• 重组算法
• 重组位置（目的主机）

IPv4 分片用三个字段标识：Identification 标识同一原始数据报的所有分片（同源同标识即属于同一包）；Fragment Offset 表示该分片在原始数据报中的偏移（按 8 字节为单位），用于按顺序放置；MF（More Fragments）标志指示是否还有后续分片（MF=1 表示还有分片，MF=0 表示最后一个分片）。重组时接收端按 Identification 归集分片，用 Fragment Offset 排序拼接，最后一个分片（MF=0）的 offset+长度决定总长度，重组完成前等待所有分片到达。重组发生在目的主机（端到端），因为只有最终目的地才需要完整数据报；中间路由器只负责分片，不重组（除非在隧道出口等特殊场景）。

分片是"中间路由器拆分、目的主机重组"，IP 无状态，重组必须由最终接收端完成。三个字段分别回答"属于谁、在第几块、还有没有"。

• 各属性的传播范围（AS 内/跨 AS）
• BGP 决策顺序
• 常用属性

BGP 路径属性：NEXT_HOP 是到达目的的下一条地址，跨 AS 传播时由对等体更新，只在本地/AS 内有意义；AS_PATH 记录了经过的 AS 列表，跨 AS 传播，用于防环与选路；LOCAL_PREF 是本地 AS 内设定的优先级（同 AS 内比较，不跨 AS 传播，值越大越优先）；MED 是向邻居 AS 通告的度量（值越小越优先，跨 AS 传播但只在相邻 AS 间有意义）。BGP 决策顺序：1) 权重最高（Cisco 本地优先）；2) 本地优先级最高；3) 本地起源（i 优于 e 优于 ?）；4) AS_PATH 最短；5) 起源类型；6) MED 最小；7) eBGP 优于 iBGP；8) 可达性/下一跳；9) 其他（地址、路由来源等）。

属性有"传播范围"理解：LOCAL_PREF 只在 AS 内、NEXT_HOP 按跳更新、AS_PATH 跨 AS、MED 跨 AS 但仅相邻有效。决策顺序是"AS 内策略优先于 AS 间路径长度"。

• SRv6 的 SID 与可编程性
• uSID/compress 编码
• 硬件 offload 挑战

SRv6 把段（Segment）编码为 IPv6 地址（SID）放在 SRH 扩展头中，无需独立标签栈，天然与 IPv6 地址空间融合，可编程性更强：SID 可编码服务功能、拓扑路径、可编程行为，控制面可灵活编排（服务链、TI-LFA、可达性），且不依赖 MPLS 标签分配协议。uSID（unified SID）是 SID 压缩编码，把多个段压缩进一个 IPv6 地址的多个 128 位段内，减少 SRH 头开销，但需要硬件能解析压缩的 SID 结构、在 locator 内做段压缩转发，对硬件 NF（网络功能）的挑战是：需要支持 SRH 解析、uSID 压缩段处理、locator 匹配与 SID 弹出的能力，老 ASIC 难以实现，需专门硬件支持，否则只能软件转发，影响性能。

SRv6 的优势是"用 IPv6 地址承载可编程段"，可编程性高；uSID 压缩牺牲一点简单性换取头开销，但依赖硬件对新 SRH 解析与压缩段处理的支持，是硬件 NF 的挑战。

• jumbogram（大于 65535 字节）
• IPv6 无分片 vs IPv4 分片
• 硬件支持

IPv6 普通载荷最大 65535 字节，jumbogram（RFC 2675）通过 Jumbo Payload Option 支持超过 65535 字节的载荷，但要求整条路径 MTU 足够大且不支持中间分片（IPv6 端到端不分片，由源端分片）。IPv4 则在中间路由器可分片，支持超大分组靠分片。兼容性问题：jumbogram 需要路径上所有设备支持巨型 MTU 且无分片，一旦某跳 MTU 不足就会丢弃（依赖 PMTUD）；PMTUD 在 jumbogram 下更敏感，ICMP 被过滤则黑洞。硬件 ASIC 卸载：jumbogram 的 32 位载荷长度、Jumbo Payload Option 解析、以及超长包在 NIC/ASIC 的缓冲与 offload（如 TSO/GRO）支持不普遍，多数硬件不支持 jumbogram，导致只能软件处理、性能受限。

jumbogram 靠"路径 MTU 足够大且不分片"来承载超大包，与 IPv4 的分片思维不同，依赖 PMTUD 且中间不可分片，硬件支持有限是其推广瓶颈。

• RIB（路由信息库）与 FIB（转发信息库）
• RIB 到 FIB 下发
• ECMP 安装

RIB（路由信息库）由控制平面（路由协议、静态路由）维护，保存所有可用路由及其属性（如下一跳、度量、来源、管理距离），是"全部路由候选"。FIB（转发信息库）由数据平面使用，保存"最优、可转发"的路由（已解析出出接口与下一跳），用于逐包快速转发。RIB 经过选路（最优路由）后下发给 FIB。ECMP 下一跳安装：当存在多条等价路径（相同度量、同前缀）时，RIB 把多个下一跳一起下发给 FIB，FIB 中该前缀对应一个"下一跳列表"（ECMP 组），转发时按哈希（如 5 元组）选择其中一个下一跳，实现负载均衡，同时保证同一流走同一路径。

RIB 是"决策库"（控制面），FIB 是"执行库"（数据面），两者解耦使路由收敛与转发独立。ECMP 在 FIB 中表现为"多下一跳 + 哈希选择"。

• REACHABLE 到 STALE
• STALE 的惰性探测
• 有流量时的发送

邻居状态机中，REACHABLE 时间到期后进入 STALE，表示"已过期但未确认不可达"。STALE 状态下并不立即探测，因为设备希望"免打扰"：如果之后没有流量发往该邻居，就不必浪费探测；只有当有流量需要发送时，才进入 DELAY 状态，等待一小段时间看是否收到该邻居的确认（如对端回包），若收到确认则回到 REACHABLE，否则进入 PROBE 才真正发送探测。这样设计避免对每个过期邻居都主动探测，只在"确实要发流量"时才确认，减少探测开销并利用实际流量做可达性确认。

"先尝试发送再做确认"是惰性确认：STALE 只是过期标记，DELAY 用实际流量顺便确认，PROBE 才主动探测。这平衡了邻居新鲜度与探测开销。

• 24 位 VNI（1600 万）
• UDP 4789 封装
• 多租户二层隔离

VXLAN 用 24 位 VNI（VXLAN Network Identifier）标识虚拟二层网络，可支持 1600 万个 VNI，突破 VLAN 的 12 位（4096）上限，满足大规模多租户需求。VXLAN 把二层帧封装进 UDP 报文（默认端口 4789），外层是 IP/UDP 头，通过 underlay IP 网络传输，实现"二层帧在三层网络上的扩展"（bridge over IP）。每个 VNI 对应一个独立的虚拟二层广播域，不同 VNI 之间隔离，从而实现多租户二层隔离：租户 A 的 VNI 100 与租户 B 的 VNI 200 互不可见、互不广播，同时边界可延伸到数据中心任意位置。

"24 位 VNI + UDP/IP 封装"是 VXLAN 的两个核心：VNI 扩展规模并隔离租户，UDP/IP 让二层跨三层传输。VLAN 的 4096 上限与二层范围受限被同时解决。

• 6in4（手动配置隧道）
• 6to4（自动隧道）
• 各自的局限

6in4 是手动配置的 IPv6-over-IPv4 隧道：网络管理员在两端显式配置 IPv4 隧道端点，把 IPv6 包封装进 IPv4 包传输，稳定可控但需要手动逐点配置，无法自动扩展。6to4 是自动隧道：利用 2002:V4ADDR::/48 的地址前缀，把 IPv4 地址内嵌到 IPv6 地址中，自动确定隧道对端，无需手动配置，但依赖公共 6to4 中继，地址空间受限、存在任播中继依赖、可靠性差，且 NAT 后无法工作。二者局限：6in4 需手动配置、扩展性差；6to4 自动但依赖中继、地址受限、NAT 不友好、性能与可靠性差。两者都只是过渡方案，最终应迁移到原生 IPv6。

6in4 是"手动点对点"，6to4 是"自动内嵌地址"。6to4 的自动化以可靠性/中继依赖为代价，多用于过渡期，长期应原生 IPv6。

• underlay MTU 与 overlay MTU 的关系
• 外层封装头预留
• 预留不足的后果

Overlay 网络需保证 underlay 物理 MTU 大于 overlay 报文的总长度（overlay 内层 MTU + 外层封装头）。规划时：underlay 启用 jumbo frame（如 9000），overlay 的 veth/虚拟接口 MTU 设为 1450（9000-50）或 1500-封装开销，使内层包 + 外层头不超过 underlay MTU。若外层封装头预留不足（如 underlay 是 1500 而 overlay 也是 1500），内层大包加上 VXLAN/IPsec 等外层头就超过 1500，被中间设备丢弃，形成 MTU 黑洞——表现为小包通、大包丢、分片或长连接卡顿。正确规划是"underlay 留足余量，overlay 减去封装开销"。

规划核心是"overlay MTU + 封装开销 <= underlay MTU"。预留不足是 overlay 丢包黑洞的常见根因，解决方式是 underlay 开 jumbo 或 overlay 调小 MTU/MSS。

• EVPN 控制面 MAC 学习（BGP 分发）
• 多归属（MH）与 ESI
• 相比泛洪的优势

EVPN 在 VXLAN 之上用 BGP 控制面（EVPN 地址族）分发 MAC/IP 路由（Type-2）、多播组（Type-3）、Ethernet Segment（Type-1/4）等，实现控制面 MAC 学习：VTEP 把本地学到的 MAC 通过 BGP 通告给远端 VTEP，无需依赖数据面泛洪学习 MAC。多归属（Multi-homing）通过 ESI（Ethernet Segment Identifier）标识同一主机接入的多个 VTEP，支持 Active/Active 或 Active/Standby，并做 DF（Designated Forwarder）选举避免 BUM 重复投递。相比数据面泛洪，优势：MAC 学习收敛更快、BUM 泛洪大大减少、支持多归属与快速收敛、隔离性好、可扩展性强，避免了数据面泛洪的广播风暴与重复泛洪问题。

EVPN 把"MAC 学习"从数据面搬到控制面（BGP），是"以控制面换取数据面效率"的典型。多归属用 ESI 解决"同一主机多接入"的转发与去重问题。