★ FEATURED ARTICLE 搞 BGP 的人都会遇到同一个场景业务方说“我们到对端有两个方向主链路负责平时流量备链路只在故障时才顶上”你打开设备一看两条链路上都收到了同样的前缀。如果你一直是用静态路由的思路做网络大概率会认为这不是很简单吗静态路由还能写优先级呢。但在 BGP 的世界里答案没那么直白甚至多数时候“选哪条路”根本不由目标可达性决定而是由一串属性按顺序 PK 出来的。这就是 BGP 的选路和属性。BGP边界网关协议是所有大规模网络之间交换路由事实上的标准协议。它的难点从来不是“能不能通”而是“明明都通为什么偏偏走这条”“我想让它走那条到底改哪个属性”。这篇文章就是写给正在跟 BGP 较劲、想彻底搞懂选路规则、准备上手调优流量路径的工程师把决策链从头到尾拆一遍再结合实操中的坑说清楚。1. 先搞清楚 BGP 选路到底在解决什么问题1.1 为什么“通的链路”不能直接用先说一个反直觉的事实BGP 路由器收到同一前缀的多条路径时即便这些路径在传输层面都完全可用路由器也只会选择一条放进全局路由表并且只向邻居通告这一条。它不是不会负载均衡而是 BGP 的设计目标本身就不是“把流量打散到所有链路上”。BGP 跑在自治系统之间每个自治系统都有自己的出口策略、商业关系和流量成本。如果默认把所有等价路径都塞进路由表那流量走向就会变得不可控今天走 A 运营商明天走 B 运营商业务方根本没办法做专线成本核算也谈不上主备切换和流量调度。所以 BGP 必须给每一条路径“打分”打完分只留最高分。这个打分体系就是路径属性。从这个角度看BGP 选路更像招聘流程候选人都能干活但岗位只有一个那就要看学历、经历、薪资期望、稳定性等一系列指标逐项对比最后只录用一个人。属性就是这些指标选路顺序就是指标的优先级。1.2 选路时机路由器先做什么后比什么很多人一上来就背九条选路顺序结果实战里一头雾水因为忽略了前置条件。BGP 选路不是路由器一收到路由就开始比它是在路由已经进入 BGP 表之后才做的“最终裁决”。实际流程大致是这样第一步邻居建立会话通过 Update 报文收到若干条前缀。此时路由器先做合法性检查比如确认下一跳可达、确认 AS 环路AS Path 里包含了自己所在的 AS 号、确认有没有被入方向策略过滤。第二步通过检查的路径进入 BGP 表BGP Table此时 BGP 表里会同时存在同一前缀的多条候选路径每条路径旁边是完整的属性集。第三步路由器对同一前缀的多条候选路径执行决策过程按照选路顺序逐级比对直到挑出唯一的最优路径。第四步将最优路径发往全局路由表并按照出方向策略通告给自己的邻居。这里有个非常关键的实操点你修改策略时要看它到底影响的是哪一步。入方向策略决定哪些路径允许进入 BGP 表出方向策略决定路由器向别人通告时修改哪些属性。很多人用路由策略做了过滤却发现流量没按预期走原因就是把“是否入表”和“是否选优”两件事混在一起了。2. 从高到低的决策链每一条路由都要过的关卡以主流网络设备的常见实现为例BGP 决策过程在收到同一前缀的多条路径后会按照下面的顺序逐项比较。我不打算只列清单而是把每一项背后的设计逻辑和使用场景都讲透。比较顺序属性作用范围默认值典型用途1Weight单台路由器本地本地始发路径较高其余为 0本设备强制走某条链路2Local Preference本 AS 内100AS 内统一出站偏好3本地始发路径本路由器BGP 表项里自产路由优先聚合/network 注入优先4AS Path 长度全局 AS 间实际路径长度通过前置控制入站流量5Origin 类型全局IGP 优于 EGP 优于 Incomplete标记来源可信度6MED相邻 AS 间0控制对端入站流量7eBGP 优于 iBGP本 ASeBGP 优先外部路径优先8去往下一跳的 IGP 开销本 AS实际开销选择内部可达更优的路径9Router-ID / 对端地址单台路由器数值小者优先兜底裁决提示这个排序不是各路设备厂商用同一个标准文件写死的它是基于公开规范 RFC 4271 的常见实现。不同厂商可能在个别顺位上做调整比如 EGP 已经基本消失第六七位的处理也可能有差异。但前四个属性在所有主流实现里都占据决定性地位实战中盯着这几个调基本不会跑偏。2.1 第一梯队Weight 与 Local PreferenceWeight 的优先级最高但它也是最“自私”的属性因为它只存在于单台路由器本地不出现在路由的传递过程中也不通告给任何邻居。它的存在意义就是当你在某台设备上明确想让某条路径胜出又不想影响全网其他设备时直接给这条路径设定一个大权重。举个例子某台设备同时从两个对端收到 /24 前缀你想让这台设备自己优先走 A 链路而 B 链路只是备胎。此时给 A 链路收到的路径设 Weight 200B 链路收到的路径保持默认 0选路结果立刻就是 A。同一台设备上其他路由不受影响其他设备也不受影响。因为 Weight 不传到别处排查问题时它也是最隐蔽的经常出现“明明策略都改了路由还是不走”的情况一查才发现是半年前在某台设备上加的 Weight 忘记清理了。Local Preference简称 Local Pref作用范围是整个自治系统。它比 Weight 更常用因为它才是 AS 内部协商出站方向的“共识变量”。默认值是 100数值越大越优先。它本质上是把“想走哪条出口”这个意图传递到 AS 内的每一台路由器。典型场景是双出口接入两个上游希望 AS 内所有路由器访问外部时优先走运营商 A。你只需要在一台设备上对从 A 收到的路由设置 Local Pref 200从 B 收到的保持 100然后这个属性会跟随路由传递到 AS 内的所有 iBGP 邻居全网设备都会自动倾向 A 出口。注意一个关键细节Local Pref 不会传递到 AS 之外。你的 eBGP 邻居从你这里收到路由时会把 Local Pref 重置为默认值。也就是说Local Pref 只能管住你自己 AS 内部的出站流量管不了别人怎么进你的网络。想控制“入站流量”得靠后面的 AS Path 和 MED。2.2 第二梯队AS Path 与 OriginAS Path 是 BGP 防环的核心机制同时也是选路时最有“全局视野”的属性。它的值是路由经过的自治系统编号序列。选路时比较的是 AS Path 长度越短越优因为跨过的自治系统越少通常意味着管理边界更少、时延和故障概率相对更低。实战中AS Path 最常见的用途是“AS Path Prepending”也就是在自己的出方向策略里把本 AS 号在 AS Path 里多重复几遍人为加长路径从而降低对端选路时对本条路径的偏好。比如你同时接了运营商 A 和运营商 B希望外部流量进来自家网络时优先走 A于是在 B 方向的通告里做as-path prepend把 AS Path 从“65001”编成“65001 65001 65001”。对端一看A 方向路径长度是 1B 方向路径长度是 3默认就会从 A 进来。但这招不是万能的。对端如果在你通告的路径上设置了更高的 Local Pref或者对端网络内部有自己的选路策略AS Path 就不是决定性因素了。另外网络上还有一类更狠的做法叫 AS Path 过滤直接不允许包含某个 AS 号的路由通过那就不光是加长路径能解决的了。Origin 属性标记路由起源类型有 IGP、EGP、Incomplete 三种。EGP 已经是历史产物现实中基本只会看到 IGP 和 Incomplete。用 network 命令显式注入的路由通常是 IGP通过重分发进入 BGP 的路由通常是 Incomplete。选路规则是 IGP 优于 EGP 优于 Incomplete。这个属性在日常选路里刷存在感的频率不高因为大多数情况下两条候选路径的 Origin 一致。但有一种情况要注意当一条路径的 AS Path 更短但 Origin 是 Incomplete另一条路径 AS Path 稍长但 Origin 是 IGP选路顺序是先比 AS PathAS Path 短的赢不会因为 Origin 更优而翻盘。很容易被人记反。2.3 第三梯队MED 与下一跳可达性MED全称 Multi-Exit Discriminator多出口区分器是控制“入站流量”的核心手段之一。它是在邻居 AS 之间传递的可选非传递属性默认值为 0数值越小越优。理解 MED 的关键是“比较范围”。MED 只在来自同一个邻居 AS 的路径之间对比来自不同 AS 的路径不比较 MED。比如路由器同时从 AS65001 和 AS65002 收到同一前缀即使其中一条 MED 是 10另一条是 200路由器也不会拿这两个值做比较。只有当同一个前缀的多条路径都来自 AS65001 时MED 才进入比较环节。这个限制很多刚上手的人会忽略结果发现设置了 MED 但选路结果没变就是因为比较对象来自不同的 AS。MED 典型用法是你在跟同一个对端之间存在两条互联链路比如两个地域的接入点希望对端访问你的时候优先走其中一个接入点。你在该接入点方向的通告里设置较低的 MED另一个方向设置较高的 MED对端收到后就会把流量引导到 MED 低的那个接入点。2.4 最后决定eBGP 优选、Router-ID 与“兜底规则”前面几条都比完了还分不出胜负才会走到后面的比较项。这里有几个值得注意的规则。在常见实现里eBGP 路径会优于 iBGP 路径。设计意图很直接数据包既然要离开本 AS那就尽量沿着 AS 边界处学到的外部路径走避免在 AS 内部绕一大圈再到边界。如果 eBGP 和 iBGP 路径都可用eBGP 胜出。但实际网络中很多人会故意用next-hop-self或路由反射器把 iBGP 路径伪装成更优此时需要结合具体策略来看不能死记“eBGP 一定走”。如果所有属性全部相同最后就轮到 Router-ID 和对端 IP 地址大小。一般是 Router-ID 较小者胜出再不行就比较对端 BGP Identifier也是小者获胜。这一层严格说是“为了分出胜负而分出胜负”没有太多业务含义。但也正因为它足够底层当两条链路完全等价时选路结果可能出乎意料地稳定——永远选小 ID 的那个所以在设计主备链路时别指望最后这层能给你带来预期的切换效果你仍然要在上层用属性明确区分主备关系。还有一点很多人从没注意过BGP 选路发生在同一前缀的多条路径之间。如果两条路由的前缀长度不同比如一个是 /24另一个是 /25它们根本不进入这个决策过程。路由表直接按最长前缀匹配/25 更精确就优先使用这是转发层面的规则和 BGP 属性无关。这个混淆是排障中最常见的误判之一。3. BGP 属性的“可见范围”哪些能传哪些只能自己用3.1 公认属性、可选属性、传递属性的真实差异BGP 属性分类看着像概念题实际上直接决定了你的选路策略能在多大范围内生效。理解它你才知道配置一个属性之后影响的是三台设备、一个 AS还是互联网上的所有自治系统。属性整体分四大类公认必遵、公认自决、可选传递、可选非传递。公认必遵的意思是所有 BGP 实现都必须识别并且必须携带的属性包括 AS Path、Next Hop、Origin。这类属性你无法删除只能修改比如 AS Path 可以追加Next Hop 可以改。公认自决也是所有实现都必须识别但具体通告与否由设备决定Local Preference 和 Atomic Aggregate 属于这一类。可选传递属性是设备不一定认识但即使不认识也必须原样传递的属性。Community 和 Extended Community 是最典型代表。这类属性特别适合做跨 AS 的策略协同因为你可以把策略意图附着在路由上让下游或对端根据 Community 值去做自己的决策。可选非传递属性则相反不认识就直接丢弃典型的代表就是 MED 和 Cluster List。这带来的实操含义很直接你想让 Local Pref 在 AS 内生效没问题但别指望 eBGP 对端帮你传你想让 MED 起作用它是可以传给对端的但对端是否按照 MED 决策取决于对端自己的选路策略——它如果先比了 Local Pref你的 MED 设得再低也可能白搭。属性传输范围这件事本质上定义了你的“策略可控边界”。3.2 Community 属性跨 AS 精细化协作的利器Community 是所有 BGP 属性里最有“编程感”的一个。它本质上是一个 32 位的标记值常见写法是AS:值比如65001:100。它不直接参与选路但可以被路由策略识别并触发动作比如“看到这个 Community就把 Local Pref 设成 50”“看到那个 Community就过滤掉”。这个机制的意义在于它把选路策略从“逐台设备硬编码”变成了“跟着路由走”。上游在通告某条路由时打上一个 Community 标签下游收到后用自己的本地策略处理这个标签。双方不需要就具体选路参数反复协商只需要约定好标签的含义即可。举个例子你作为下游同时从两个上游收到某条前缀希望临时降低其中一路的优先级。你可以在入方向策略里匹配上游打过来的 Community65002:200然后set local-preference 80。这样上游不需要知道你内部 Local Pref 是多少只需在通告路由时携带约定好的 Community你就能按预设动作做出反应。很多内容分发网络和运营商之间的互联调度本质上就是靠这种 Community 约定实现的只是外部看不到细节而已。实操中有个常用技巧配置 route-map 时使用community additive关键字在保留原有 Community 值的基础上追加新的标记而不是覆盖。如果直接覆盖可能把对端原有的标记清掉导致对端后续策略失灵。这个坑我在联调时踩过排了半天才发现是自己把路由原本带的一个关键 Community 值覆盖没了。3.3 下一跳属性看起来基础影响却被低估Next Hop 是公认必遵属性日常可能不太关注因为只要邻居关系正常设备会自动处理好。但在 iBGP 场景里下一跳的处理往往成为选路和转发问题的根源。默认情况下从 eBGP 邻居收到的路由通告给 iBGP 邻居时Next Hop 保持为 eBGP 对端的地址。如果你的 iBGP 邻居没有到该地址的路由这条 iBGP 路由的下一跳不可达选路时会被认为无效路径直接不参与比较。这就是为什么大型网络里普遍配置next-hop-self把 iBGP 通告的 Next Hop 改成自己的地址。排查经验是看到 BGP 表里有前缀但状态是 not advertised优先看下一跳可不可达别急着怀疑过滤器。很多初学 BGP 的人在这个环节耗费大量时间抓包、查策略最后发现只是忘了处理 Next Hop。4. 实操选路属性怎么改改了之后流量怎么走4.1 出站流量控制Local Preference 和 AS Path 是关键出站流量指“本 AS 内的用户访问外部网络”的流量。你作为自治系统的管理者能完全控制的只有出站方向因为路由是你从上游学到的选路是在你的设备上做的。控制出站流量最常见的做法就是在入方向策略里修改 Local Preference。拿双运营商接入举例你希望所有内部用户访问外部时优先走上游 A只有 A 断掉才走 B。可以在“从 A 的入方向路由策略”中把收到的路由 Local Pref 设为 200B 方向的入站策略保持默认 100 或显式设为 100。因为 Local Pref 会随 iBGP 在 AS 内传递全网设备都会跟着这个偏好走。配置写法以通用的路由策略风格示意如下# 入方向策略针对来自上游A的所有路由设置Local Pref route-policy FROM-ISP-A permit 10 match ... set local-preference 200 neighbor 192.0.2.1 route-policy FROM-ISP-A in # 入方向策略来自上游B的路由保持默认Local Pref route-policy FROM-ISP-B permit 10 set local-preference 100 neighbor 198.51.100.1 route-policy FROM-ISP-B in这里有个细节如果只是改变出站选路偏好一般不需要动 AS Path因为 AS Path 是 AS 间传递的改动会影响入站流量方向。想专门控制出站Local Pref 是最干净的手段。有时候你只希望某一个前缀的出站方向特殊化而不是全局都走 A。那就需要在策略里增加匹配条件只对指定的前缀做 Local Pref 修改而不是无脑匹配所有路由。否则今天调完明天新增一条业务前缀也会被全局策略带偏。4.2 入站流量控制MED、社区和 AS 路径前置入站流量指“外部用户访问本 AS 内业务”的流量这类流量选路发生在对端设备上你只能“影响”不能“决定”。所以入站流量控制的核心思路是主动调整自己通告出去的属性尽量让对端按照你的预期选路。最常用的手段是 MED 和 AS Path Prepending。两者的适用场景略有差异。如果对方跟你有多个接入点你希望对方优先从一个接入点进来就在那个接入点方向通告的路由上设置更低的 MED。如果对方比较看重 AS Path 长度比如它的选路策略先比 AS Path那么你通过前置加长 AS Path 可能更有效。入方向策略示意# 向对端通告时给指定前缀设置较高的MED route-policy TO-PEER permit 10 match ip-prefix PREFIX-LIST-B set med 200 # 或者对某类前缀做AS Path前置 route-policy TO-PEER-PREPEND permit 10 as-path-prepend 65001 65001 65001注意AS Path 前置和 MED 不是二选一经常配合使用。比如针对某个大前缀你在备链路上既设置 MED 200又做 AS Path 前置双管齐下让对端无论先比哪个属性都倾向于走主链路。这在复杂互联里能提升策略的鲁棒性。还有一个更容易被忽略的点入站控制要确保你的“主链路”真的有足够容量承接所有外部流量。如果只通过属性把流量引过来了但主链路带宽不足那压缩、丢包、延迟抖动都会出现底下的网络团队反而会质疑你的路由策略。先做容量规划再做选路优化顺序不能反。4.3 查看当前选路结果与属性常用排障命令不管改什么属性最终都要回到“查看 BGP 表”这一步验证。通用的查看思路大致如下。查看某条前缀在 BGP 表里的完整信息和最优路径标志常用命令形如display bgp routing-table 192.0.2.0/24不同厂商命令前缀略有差异重点关注输出里标注为最优路径通常有符号或*标记的那一项以及它旁边的 AS Path、Local Pref、MED、Next Hop 等属性数值。如果想看“为什么另一条路径落选”可以查看该前缀的所有候选路径输出里会列出每条路径的完整属性。拿到这些属性值后对照选路顺序逐项比较就能定位是在哪一轮被淘汰的。比如看到一条路径 Local Pref 是 200另一条是 100而前者没有成为最优那就要回看是不是 Weight 环节出了问题或者前者根本是最优但没进路由表。技术命令本质上只是把属性摊开给你看。真正的分析能力是你对选路顺序的熟悉程度以及能否快速判断“当前胜负手是哪一个属性”。我的习惯是排障时先把两条路径的所有属性并列写出来然后用选路顺序做一轮手工比对确认预期和实际一致后再去检查策略下发是否生效。# 查看BGP邻居状态 display bgp peer # 查看特定前缀的BGP表详情 display bgp routing-table 192.0.2.0/24 # 实测中常配合使用查看该前缀在路由表中的最终状态 display ip routing-table 192.0.2.0/24改完策略后要关注 BGP 会话是否需要软重置或手工刷新。很多路由策略在修改后不会自动对已存在的路由重新生效需要执行一次软重置让设备重新跑一遍入方向或出方向的策略。这一步忘了做会出现“策略明明改了BGP表没变化”的假故障。4.4 修改属性时最容易翻车的细节第一不同方向的路由策略作用对象别搞混。入方向策略修改的是“从对端收到的路由”的属性影响的是本设备和本 AS 的选路出方向策略修改的是“通告给对端的路由”的属性影响的是对端网络的选路。一个典型错误是想控制入站流量却把 MED 写在入方向策略里——那只是给本设备自己看对端根本收不到这个 MED。第二修改 Local Pref 时要意识到它会在 iBGP 全网传递。你在边界路由器上修改了该属性的同时如果 AS 内还有路由反射器或联邦要确认属性不会被其他策略二次覆盖。我遇到过在入口处设了 Local Pref 200结果反射器上还有一个出方向策略把 Local Pref 覆盖回 50导致全网路由选择完全偏离预期。第三重置会话的风险。有些场景下软重置做不到必须硬重置 BGP 会话这意味着邻居关系断开、路由全部重新收敛在业务高峰期可能直接造成流量中断。任何重大策略变更都建议先在维护窗口执行并且提前写回滚方案。听到“先重置试试”这类建议时要多留个心眼谨慎操作。5. 高频坑与经验实录5.1 改了 Local Preference 却只在局部生效有朋友反馈我在边界设备上设置了 Local Pref为什么内网另一台路由器还是走了别的出口排查后发现Local Pref 确实会随路由传递给 iBGP 邻居但前提是路由是通过 iBGP 传递的。如果你的边界设备与内网设备之间没有建立 iBGP 邻居而是通过静态路由、IGP 重分发等方式把 BGP 路由引进去Local Pref 这种 BGP 属性根本不在传递链路里自然无法生效。正确的做法是在同一 AS 内建立完整的 iBGP 会话包括路由反射器或联盟并且在所有参与者之间保持一致的策略。只改一台设备的 Local Pref不保证全网生效。这也是为什么规范化的网络设计总是强调“控制平面统一”任何一台边界设备上的策略都要通过 iBGP 体系传遍全网。5.2 MED 比较的“同源”限制前面反复强调过MED 只在来自同一个 AS 的路径之间比较。但还有一个细节即使两个路径都来自同一个 AS如果去往那个 AS 时经过了不同的第三方 AS有些实现也会在这个场景下跳过 MED 比较。原因是 MED 是发送方 AS 在特定互连连路上设置的偏好当路径中间又插入了其他 AS这个偏好的语义就变模糊了。这条规则实战中的影响是想靠 MED 控制入站流量尽量在直接互联的邻居间使用。如果你的上游是二级运营商他上面还有一级运营商你把 MED 给了二级二级是否原样把 MED 传给一级行为可能不一致。如果路径经过了中间商控制力就大打折扣。遇到这种情况优先回到 AS Path 前置或 Community 协作。5.3 路由聚合对属性的影响聚合路由是 BGP 里很常见的操作把多条细前缀聚合成一条大前缀通告能显著减少路由表条目。但聚合会带来一个选路层面的副作用聚合路由的来源路径被重写原来细前缀上的 AS Path、MED、Community 可能全部丢失或简化。不同设备处理聚合的方式有差异有的会保留部分属性有的会生成 Atomic Aggregate 属性表示聚合后的路由不完整。实操建议是在做路由聚合时明确设计聚合路由需要携带哪些属性并通过出方向策略重新设置。不要默认聚合路由会继承原始明细路径的属性。否则你辛辛苦苦设置的入站选路策略很可能在聚合点的通告环节就被无声无息地抹掉了。5.4 主备切换后的“路由摇摆”问题使用 BGP 属性实现主备链路时有一个容易被忽略的场景主链路故障恢复后流量是否自动切回BGP 本身会重新收敛把最优路径切换到恢复后的主链路上。但如果你的主备设计依赖的是外部注入的策略比如上游周期性地改变 Community 值或者通过监控脚本动态调整属性那切换逻辑就会复杂很多。我见过最稳妥的落地方式是设备层面用 BFD 联动 BGP 邻居状态保障链路故障时快速收敛业务层面用属性策略决定逆向但在主备切换后加入延迟回切机制避免因链路抖动导致频繁翻转。追求“故障后立即回切”不一定是最好的很多场景下保持备链路稳定运行一段时间观察无异常后再回切反而更符合实际业务需要。5.5 处理次优路径问题次优路径指的是BGP 表里存在一条路径理论上属性更优但转发面没有使用它原因是路由表里被其他更高优先级的路由来源占位了。比如同一前缀既通过 BGP 学习到又通过静态路由或直连路由获得而静态路由或直连的优先级更高这时 BGP 最优路径不会进入路由表。碰到这种问题先别急着怀疑 BGP 属性配错了要去看全局路由表里这条前缀的来源。如果看到了静态路由或 IGP 引入的路由就用管理距离来调整优先级或者删除多余的静态路由。BGP 选路再精细也只是在 BGP 内部做裁决进了全局路由表还要服从跨协议的路由优先级规则。6. 一句话总结属性的“适用边界”写了这么多最后说点实际的。BGP 的选路和属性说到底是一套“可编程的流量调度协议”。想在真实网络里用好它不能只背选路顺序还要记住每个属性的作用范围Weight 只管一台设备Local Preference 管整个 AS 内部的出站偏好AS Path 和 MED 能影响对端网络的入站选择Community 则是跨 AS 协商的“通用接口”剩下的 Router-ID、IGP 开销基本都是兜底。我个人调试 BGP 策略时有一个习惯每次修改前先问自己一个问题——这条流量是哪一端做最终决策如果是本端优先改 Weight 和 Local Preference如果是远端优先改 AS Path 和 MED如果是多方协作就引入 Community 机制。明确了这个“决策权归属”排障思路就清晰了一大半。最后再分享一个小技巧在测试环境做 BGP 选路验证时尽量使用文档保留的测试地址段比如192.0.2.0/24或2001:db8::/32不要拿现网真实前缀做实验。否则策略一旦配错影响的就是真实业务。属性可以随便改流量不会说假话多改几次你对选路的感知就会完全不一样。
阅读完成 · 觉得有帮助？
