2. Junos BGP基础配置与邻居建立

在MX系列平台上，BGP邻居能否建立，取决于三个层面的匹配：传输层可达性、BGP层参数协商、以及策略层的准入控制。很多初学者把“邻居起不来”简单归因于配置写错，实际上更常见的原因是TCP 179端口被过滤、Router ID冲突、或AS号与对端不匹配。本节围绕iBGP与eBGP的差异、邻居配置结构、认证与多跳、路由反射器与联盟的初步配置，以及如何用 show bgp neighbor 定位问题展开。

iBGP与eBGP的本质差异

iBGP指同一AS内的BGP会话，eBGP指不同AS之间的会话。两者最关键的差别不在配置命令，而在路由传播规则：eBGP从对端学到的路由，默认AS_Path会增加本端AS号，并可以通告给其他eBGP邻居和iBGP邻居；iBGP从对端学到的路由，不会修改AS_Path，且默认不会通告给其他iBGP邻居——这就是iBGP需要全互联或路由反射器的根本原因。

另一个差异是下一跳处理。eBGP默认将下一跳改为自身接口地址；iBGP默认保留从eBGP学到的下一跳不变。如果iBGP邻居之间没有到达该下一跳的路由，路由虽然进入BGP表，却无法进入转发表，表现为 show route 可见但转发不通。这是MX上排查iBGP路由“有表无转发”的高频原因。

邻居配置的基本结构

Junos的BGP配置采用层次化结构，邻居参数写在 protocols bgp group 下。以下是一个典型的eBGP邻居配置示例，AS 65001与AS 65002互联：

protocols {
    bgp {
        group EBGP-PEER {
            type external;
            peer-as 65002;
            neighbor 192.0.2.2;
        }
    }
}

iBGP邻居则使用 type internal，且通常需要指定本地AS号或依赖全局AS配置：

protocols {
    bgp {
        group IBGP-CORE {
            type internal;
            local-address 10.0.0.1;
            neighbor 10.0.0.2;
            neighbor 10.0.0.3;
        }
    }
}

注意 local-address 的作用：它决定BGP会话的源地址，也影响Router ID的选择。如果一台MX有多个环回地址，未显式指定local-address时，Junos会按Router ID选择规则选取，可能导致与预期不符的会话源地址。

认证与多跳

BGP认证通过TCP MD5实现，配置在邻居或组级别：

protocols bgp group EBGP-PEER {
    authentication-key "$9$...";
    neighbor 192.0.2.2;
}

两端密钥必须一致，否则TCP握手阶段就会失败，show bgp neighbor 会显示 Authentication failure。多跳场景用于eBGP邻居不直连的情况，例如通过环回地址建立会话：

protocols bgp group EBGP-MULTIHOP {
    type external;
    peer-as 65002;
    multihop ttl 5;
    neighbor 203.0.113.2;
}

multihop ttl 5 表示允许BGP报文经过最多5跳。同时必须保证到达对端环回地址的路由存在，通常通过静态路由或IGP提供。缺少这条路由时，TCP无法建立，邻居停留在 Active 状态。

路由反射器与联盟的初步配置

iBGP全互联在邻居数量增加时呈平方级增长，路由反射器（RR）是常用解决方案。RR将客户端学到的iBGP路由反射给其他客户端和非客户端，打破水平分割限制。配置上，RR端将邻居标记为client：

protocols bgp group IBGP-RR {
    type internal;
    cluster 10.0.0.1;
    neighbor 10.0.0.2;
    neighbor 10.0.0.3;
    neighbor 10.0.0.2 client;
    neighbor 10.0.0.3 client;
}

cluster 值通常设为RR的Router ID，用于防止环路。联盟（Confederation）则是将一个大AS划分为多个子AS，子AS之间用eBGP风格会话，对外仍表现为一个AS。初步配置涉及 confederation 语句：

routing-options {
    confederation 65001 members [65010 65011];
}
protocols bgp group CONFED {
    type external;
    peer-as 65010;
    neighbor 10.0.0.2;
}

联盟配置相对复杂，实际部署中RR使用更广泛。本节只需理解两者都能减少iBGP全互联需求即可。

用show bgp neighbor验证会话状态

配置完成后，最直接的验证命令是 show bgp neighbor。输出中需要关注几个关键字段：Type 显示Internal或External，State 应为Established，Last State 和 Last Event 能反映最近一次状态变化原因。如果State停留在Active，通常意味着TCP连接未建立；如果停留在Connect，可能是对端未响应；如果显示 Idle，则可能是配置错误或路由不可达。

以下SVG展示了BGP邻居从配置到Established的完整状态路径，以及各阶段的关键检查点：

从图中可以看到，邻居状态从Idle到Established经历Connect、Active、OpenSent、OpenConfirm等阶段。实际排障时，Last State 和 Last Event 比当前State更有价值——它们告诉你上一次状态变化的原因。例如 Last Event: RecvKeepAlive 表示正常收到保活报文，而 Last Event: ConnectRetry 则说明TCP连接反复失败。

最后需要强调，BGP邻居建立只是第一步。会话Established后，还需要确认路由是否正确交换。可以用 show bgp summary 查看各邻居的前缀接收数，用 show route receive-protocol bgp 192.0.2.2 查看从特定邻居收到的路由。如果接收数为0，说明对端没有通告路由，或本端入方向策略过滤了所有路由。这些验证手段与邻居状态检查配合使用，才能完整判断BGP会话是否真正可用。