有人问我BGP能不能做负载分担我一般先反问一句你说的分担是让两条链路都用起来还是让流量按比例精确分配这两个诉求听着差不多落地思路完全不同。入行头几年我在这上面栽过跟头后来踩了几次坑才把逻辑理顺。今天这篇就围绕BGP负载分担把概念、原理、配置和排障一次讲透。先说一个实际场景。某公司有两个运营商出口分别接入不同网段原本图的是冗余备份结果日常跑流量时一条链路常年占用80%以上另一条闲到发慌。网管把BGP邻居都配上路由也都学回来了但流量就是不走第二条路。问题出在哪出在BGP的选路规则上——它默认只挑一条最优路径根本不理会链路利用率是否均衡。要解决这个问题光会敲命令不够得先明白BGP负载分担到底在分担什么、通过什么机制去分担以及什么时候分担会失效。下面按我自己的理解从原理到配置再到排障挨个环节拆开讲。1. BGP负载分担概念拆解与适用场景1.1 先说清楚一个高频疑问负载分担不等于负载均衡很多刚接触这个领域的同行会把BGP负载分担和负载均衡混在一起实际两者是不同层面的事情。负载均衡通常指基于策略或应用层的流量调度比如把HTTP请求按比例分给多个后端服务器精确到会话甚至请求级别。而BGP负载分担发生在网络层本质上是让路由协议在转发表中同时保留多条可达同一目的网络的路径流量按哈希算法在路径之间分散转发。两者最大的区别在于负载均衡可以做非常精细的流量分配比如按权重、按会话、按源目的地址BGP负载分担则只遵循“等价路径”这个前提只有满足等价条件的路径才会被同时使用。正因为有这个限制BGP负载分担在转发粒度上比较粗通常是一个流五元组固定走一条路径不会把一个流拆到两条链路上。这种特性决定了它适合链路容量接近、且流量会话数较多的场景而不适合需要精确控制单条大流量走向的场合。1.2 哪些场景真正需要BGP负载分担我实际接触到的需求大致分三类。第一类是双运营商出口的IDC机房两个ISP各拉一条链路本地宣告自己的IP网段希望通过BGP同时利用两条带宽避免一条拥塞一条闲置。第二类是企业总部到分部的双WAN互联中间跑BGP希望两条专线都能承载业务流量同时保留故障冗余能力。第三类是多中心互联场景BGP作为核心路由协议承载内部网段互访通过负载分担提升骨干链路带宽利用率。这三类场景都有共同特点多条路径的带宽容量接近路由目的网段数量足够多流量由大量小流组成。只有当这些条件成立时基于流的负载分担才能体现出效果。如果你只有一条大流量业务比如视频点播再怎么做BGP负载分担也无法让单条流拆开走两条链路这时该考虑的就不是BGP层面的东西而是上层调度策略了。1.3 负载分担对网络的影响范围BGP负载分担的影响范围不止在路由器本身它会改变转发路径进而影响整条链路上的设备、防火墙会话、流量监控系统。举个例子内网用户访问某个公网网段原来所有流量都走运营商A开启负载分担后会有一部分流量改走运营商B出口防火墙上原本建立在运营商A链路上的会话表项就会失效必须重新建连。这意味着如果你在网络出口串联了防火墙、负载器等设备开启BGP负载分担之前必须确认这些设备支持多路径转发否则可能出现连接中断的故障。影响还体现在监控和排障层面。开启之后同一个目的地址的流量可能来自多个下一跳你在抓包分析时会发现源路径不固定。刚开始做负载分担运维时会很困惑明明目的IP一样为什么trace出来的路径一会儿走这条一会儿走那条。这不是故障而是负载分担生效的正常现象。提前跟团队交代清楚这个变化能省去后面很多无效排查时间。2. 原理拆解为什么BGP默认不分担以及怎么让它分担2.1 回顾BGP选路规则一切设计的前提要理解BGP负载分担的原理绕不开BGP的选路规则。BGP会为同一个前缀收到多条路径然后按顺序比较一系列属性挑出唯一的最优路径。这个比较顺序大致是路由器本机来源优先级最高其次是LOCAL_PREF本地优先级然后是AS路径长度、MED值、eBGP优先于iBGP等。一轮比下来通常只会剩下一条胜出路径其余路径进入备用状态这在默认情况下是单路径转发的基础。细看这套规则会发现它强调的是“有序比较唯一胜出”根本没有为同时使用多条路径留出口子。要让BGP做负载分担就得绕过或中和这些比较条件让多条路径在关键属性上打成平手无法决出唯一最优路径最终由转发层面的等价路由机制接管。需要特别提醒的是即使你打开了负载分担命令如果路径之间在选路规则中的某一项仍然有高下之分路由器依然只选一条。这也是为什么很多人配了命令却不生效问题多半出在“路径不等价”上。2.2 等价路径的形成条件等价路径是BGP负载分担的基石。两条BGP路径要形成等价需要在多个属性上保持一致最核心的包括LOCAL_PREF、AS_PATH长度、MED、origin类型等。实际上不同厂商的实现对这些条件的检查项略有差异但大原则是一致的只有BGP在选路规则的前面几步无法区分两条路径时才会进入负载分担的判定阶段。这里有个常见的理解误区所谓等价不需要两条路径的AS路径完全一模一样而是需要它们在BGP比较规则中排名靠前的关键属性相等。比如你从运营商A学到一条路由AS路径是65001 100从运营商B学到的是65002 200只要这两条路径的LOCAL_PREF相等、MED默认相同、而且AS路径长度都是2在BGP眼里它们就处于同一优先级可以形成等价关系。除此之外还有一个隐藏条件容易被忽略负载分担的最终动作基于转发表而转发表只会保留经过IGP可达的下一跳路径。换句话说BGP下一跳路由器必须能通过内部网关协议如OSPF或静态路由到达否则即使BGP层面判断两条路径等价其中一条也可能因为下一跳不可达而无法进入转发表负载分担自然无法生效。2.3 两种路径类型的取舍eBGP与iBGPBGP负载分担有两种常见路径来源eBGP等值路径和iBGP等值路径。eBGP等值路径即两个不同的eBGP邻居各自通告同一条前缀且各种属性都被调整为等价状态这种情况多见于双运营商接入。iBGP等值路径则常见于AS内部有多个出口路由器场景通过路由反射或全互联让本AS内的路由器学到来自不同边界设备的等价路径。从实施难度看eBGP负载分担调整起来比较繁琐因为你需要干预来自不同外部邻居的路径属性让它们“人为等价”常用手段包括调整MED、AS路径长度等。而iBGP负载分担更加自然因为外部路径进入AS后各边界设备可以通过本地策略把LOCAL_PREF设置成一致之后内部路由器学到这些路径时天然形成等价。在实际项目中我倾向优先规划iBGP层面的统一属性再在外联边界做精细化调节这样内部转发层面的负载分担更可控排障也容易一些。3. 实操配置从需求分析到命令落地3.1 配置前必须明确的三个问题动配置之前先问自己三个问题第一我需要分担的是出方向流量还是入方向流量第二两条链路的带宽是否一致第三下游设备知不知道我做了多路径转发第一问决定了操作重点。出方向流量本端主动发起的访问由本台路由器的转发表决定走向通过配置负载分担可以直接影响入方向流量外部访问本端宣告的网段由对端的路由决策决定你只能通过发布路由属性间接引导无法在本地强制执行。很多同行期待通过本地配置让入方向的流量自动平均分配这不现实。第二问关系到配置参数。如果两条链路带宽差距较大强行做等价负载分担会导致小链路拥塞反而影响业务质量。此时应该评估是否需要调整为非等值负载分担或者干脆放弃BGP层分担改用策略路由按流量类型分流。第三问最容易被忽略。你在这台路由器上做了多路径转发但下游接了一台不支持ECMP的防火墙那么转发的数据到了防火墙这里可能被丢弃。做负载分担之前建议沿着流量路径把所有设备过一遍确认每一跳都支持多路径转发。3.2 出方向负载分担的配置思路与示例配置出方向负载分担核心是让BGP认为到同一目的网段的路径等价。实际操作分为两个层面在路由协议层面通过调整属性让路径“打平”在转发层面使等价路径同时下发到转发表。以两个运营商邻居为例假设本地AS号为65001运营商A邻居为100.1.1.1运营商B邻居为200.1.1.1你从两边分别学到目的网段203.0.113.0/24。要让这两条路径形成等价我会在入方向上分别对两个邻居设置同样的LOCAL_PREF值同时确认MED、origin等属性一致。处理完BGP属性后需要在BGP进程或地址族下开启负载分担控制等价路径数量上限。不同厂商的命令风格有差异这里以常见的两种命令行风格示意。一种风格是在BGP进程下直接设置示例为在进程视图执行负载分担参数另一种是在地址族视图下设置。你拿到设备后先查对应版本的手册不要照抄网上的旧命令。配置完成后要验证两条路径确实进入了转发表。查看BGP路由表时如果目的网段下面列出了两个下一跳且状态标志都处于最优或有效状态说明BGP层面的等价关系已经建立。接着看IP转发表确认两条路径都以等价路由形式存在并观察计数器的增长情况。3.3 入方向负载分担的间接控制手段入方向流量控制比出方向复杂得多因为你无法直接修改对端路由器的转发表只能通过影响BGP路径属性的方式引导对端路由器选择不同的路径。常用手段包括AS路径填充、MED值调节。AS路径填充的思路是在向特定运营商通告路由时附加额外的AS号使该路径的AS路径长度变长从而降低对端选择这条路径的优先级。如果你希望运营商B的流量更多走向链路1就在通告给运营商B时把链路2方向的路径“变长”让运营商B认为走链路1更短、更优。这种方法实现简单、兼容性好但控制粒度较粗不适合要求精确比例的场景。MED值调节则更细致一些。MED是BGP选路中比较靠后的属性但它专门用于告诉对端“进入本AS时优先走哪个入口”。你可以针对不同运营商设置不同的MED值数值越小优先级越高。考虑到不同运营商对MED的处理策略可能不同实施前要确认对端是否默认比较MED避免无效配置。无论哪种手段都不可能做到按流量百分比精确控制入方向负载分担。网络实践中这是BGP本身的特性决定的与其纠结精确调配不如把重点放在保证两条链路都可用、故障时能快速切换上。3.4 验证方法与长期观察配置完成只是开始验证才是关键。我习惯分三步走第一步看BGP层的路由状态确认多条路径都是有效的第二步看转发表确认多条路径真正被下发第三步看实际流量分布通过接口流量统计确认两条链路都有流量在走。第一步检查命令一般会列出前缀的多个路径条目对应状态标志都很关键。第二步检查转发表可以看到同一目的地址前缀后面挂着多个出接口和下一跳。第三步则是观察接口流量计数这一步建议持续一段较长的时间不要只看几分钟的瞬时值因为负载分担基于流哈希短时间内的流量分布可能有波动。长期观察还需要配合监控系统记录接口利用率趋势。如果发现一周内某条链路利用率持续明显偏离需要回头检查是否有大流量应用、哈希算法是否均匀、路径属性是否被对端策略意外改变。BGP负载分担不是配置完就一劳永逸的东西它需要纳入日常网络巡检的范畴。4. 排障实录常见问题与排查技巧4.1 检查点一BGP属性是否真的“打平”了最常遇到的排障场景是命令也敲了BGP邻居也正常但流量就是不走第二条路径。这时候先回到BGP路由表把两条路径的属性挨个列出来对比。我之前遇到过一个案例两边LOCAL_PREF都是200AS路径长度也都相同看起来万事俱备结果发现其中一条路径的MED值被外部运营商设置成了50另一条是默认的0一条细节差异导致选路直接分出了先后。排查这类问题时要养成完整查看路径属性的习惯不仅看LOCAL_PREF、AS路径、MED还要关注origin类型、community值、atomic-aggregate等比较靠后的属性。两家运营商在通告路由时附加的属性组合五花八门你永远猜不到哪一项会成为压倒骆驼的最后一根稻草。条件允许时可以写几条简单的脚本批量对比来自不同邻居的同前缀路径属性把差异项列出来比肉眼一条条看高效得多。4.2 检查点二等价路径有没有真正进入转发表即使BGP路由表里显示多条路径都是最优状态也不代表它们都进了转发表。转发表有一个重要约束下一跳必须可通过IGP路由到达。在实际组网中两个运营商出口的下一跳地址有时是通过 BGP 自身学到的间接路由这种情况下负载分担就无法生效因为转发表里的等价路径必须依赖直连或IGP提供的下一跳路由。另外不少设备对转发表等价路径数量有上限默认值可能是2条、4条或者更多。如果你的场景里存在超过上限的等价路径多余的路径即使BGP层完好也不会被转发。遇到这类情况可以查看转发表确认实际生效的路径数量是否小于BGP层列出的有效路径数量再决定是否调整设备支持的等价路径最大值。4.3 检查点三回程流量的走向是否可控BGP负载分担经常出现一个不对称现象去程走了链路A回程却走了链路B。对普通IP网络来说IP包可以经不同路径往返只要路由可达就不会有问题。但如果链路A和链路B之间存在质量差异比如一条走卫星、一条走地面或者其中一条链路配置了访问控制限制不对称流量就会引发业务体验下降。排查不对称问题要先确认两侧对端路由器的选路条件是否对等。比如你的AS通告了同一个网段给两家运营商两家运营商各自根据自己的策略计算回程路径很可能出现一家优先走A、另一家优先走B的情况。常规做法是检查两端宣告的属性和前缀列表是否一致如果发现一侧做了额外的AS路径填充或MED调节回程走向就可能出现偏差。不对称流量本身不一定是故障但如果你需要回程走固定链路就得在出方向通告上做系统性的策略统一。4.4 常见问题速查表我把自己踩过和帮别人处理过的典型问题整理成了一张对照表供排查时参考。现象可能原因排查方向配置负载分担命令后仍走单条路径BGP路径属性不完全等价对比LOCAL_PREF、AS_PATH、MED等属性BGP路由表多条路径有效转发表只有一条下一跳不可达或等价路径数超上限检查IGP路由可达性和设备上限参数两条链路利用率明显不均哈希算法导致大流集中或链路带宽差异大观察流量特征评估是否适合做BGP层分担开启后业务连接中断中间设备防火墙等不支持等价多路径转发检查路径上的所有设备配置和会话机制回程路径与去程不一致对端选路策略差异核对两侧AS路径填充、MED、前缀通告策略故障切换后负载分担不恢复路由震荡导致属性缓存未刷新检查BGP会话状态刷新路由并观察收敛这张表覆盖了大多数常见场景但网络世界从来不缺新问题。排查BGP负载分担问题时我的经验是始终抓住“等价”这个核心BGP层面的等价、转发层面的等价、路径上下游的等价一层层核对下来大部分疑难杂症都能找到根源。4.5 避坑经验几件容易被忽略的小事先说硬件资源的问题。BGP负载分担开启后设备的转发芯片需要维护多条等价路径同时BGP进程要处理更多路径的存储和计算。老旧设备在路由条目较多时可能出现CPU利用率升高、转发性能下降的情况实施前先评估设备性能和当前路由规模别等上线后才发现带不动。再说配置回退的风险。BGP负载分担涉及多条路径的优劣比较回退配置后转发路径会发生切换正在进行的业务连接可能中断。所以变更尽量安排在维护窗口内配置前做好回退预案把原有配置完整备份。最后说团队协作的问题。负载分担一旦生效网络路径从“唯一确定”变成“多个可能”这会给网络安全、监控、故障定位团队带来额外的认知负担。建议在变更前就同步给相关同事输出一份简要的路径变化说明告诉大家哪些区域的流量可能走新链路遇到问题时不要被“路径变了”这个现象误导。5. 个人实践体会与扩展思路做了几年BGP相关的网络工作我最大的感受是BGP负载分担从来不是一个单纯的命令问题它更像一个需要通盘考虑的系统工程。你不仅要会调协议属性还得理解转发芯片的哈希行为熟悉整条链路上的每一个设备甚至要预判业务流量模型的变化。就实用角度来说我最后再分享两个小建议。第一个是关于实施方案的选择如果两条链路带宽一致、流量以大量小流为主BGP层面的等价负载分担简单有效值得优先考虑如果流量中存在明显的超大流或者链路带宽不对称建议在负载分担之外搭配策略路由针对特定应用做分流。第二个是关于监控的配置开启负载分担后建议在相关接口上配置基于源的流量统计这样能直观看到不同前缀的流量分布情况排障时不用临时抓包分析省时省力。BGP负载分担配置本身并不复杂真正考验功力的是对网络全貌的理解和对细节的把控。希望这篇经验分享能帮你少走一些弯路。如果你在实际操作中有不同看法也欢迎交流各自的处理思路。