[BGP]从零开始设计运营商级community （上）

我们都知道 IDC 需要使用 BGP 协议来与上游交换路由表和发送自己的 IP Prefix，而且可以通过 BGP 来对路由属性对自己和客户的网段进行修改以达到控制路径的效果。但是有多少人知道其实 BGP 可以使用 community 来实现非常方便的路由路径调整呢？这篇文章将讲述如何使用 community 来打造适合机房的路由控制方案。

要想知道如何使用 BGP community，我们则先需要了解一下 BGP 的属性。

BGP 的属性分以下几种类型，分别是公认必遵，公认自决，可选可过渡，可选不可过渡。而这些属性又有属于他们不同的特点。

公认必遵（Well-Known Mandatory）是所有路由器都必须识别的属性，且这些属性必须出现在路由描述中并传递给 BGP 邻居。公认必遵的属性有以下几个：

ORIGIN（起源）：这个属性说明了源路由是怎样放到 BGP 表中的。在路由选择的时候，ORIGIN中，IGP优于EGP，EGP优于INCOMPLETE。
AS_PATH（AS路径）：指出包含在 UPDATE 报文中的路由信息所经过的自治系统的序列。
Next_HOP (下一跳)声明路由器所获得的BGP路由的下一跳，对 eBGP 会话来说，下一跳就是通告该路由的邻居路由器的源地址。

公认自决（Well-Known Discretionary）也是所有路由器必须识别的属性，但是可以让路由器自己决定该属性需不需要传递，以及出不出现在路由描述中。公认自决的属性有以下几个：

LOCAL_PREF (本地优先级)：仅在IBGP对等体之间交换，不通告给其他AS。当BGP的路由器通过不同的IBGP对等体得到目的地址相同但下一跳不同的多条路由时，将优先选择LOCAL_PREF属性值较高的路由。
ATOMIC_AGGREGATE (原子聚合)：原子聚合属性指出已被丢失了的信息。

可选可过渡（Optional Transitive） 与 可选不可过渡（Optional Nontransitive）并不要求所有运行BGP协议的系统都识别。如果属性是可选过渡的，那么，即使运行BGP的系统不能识别该属性，也要接受该属性并将其转发给它的对等体。而如果属性是可选不可过渡的，运行BGP的系统可以忽略包含该属性的消息并且不向它的对等体转发。这两种类型的属性分别有以下几个：

COMMUNITY(团体) 是一组共享相同属性的目的地集合，用来简化路由策略的应用和降低维护管理的难度，没有物理上的边界，与其所在的AS无关。
AGGREGATOR(聚合者) 该属性补充了路由信息在哪里丢失——它包含了发起路由聚合的AS号码和形成聚合路由的BGP发布者的IP地址。
MULTI_EXIT_DISC(多出口区分)被用来区分同一个邻接AS的多个接口。
ORIGINATOR_ID(起源ID) 用于标识路由反射器，防止引入路由反射器之后出现环路，增加ORIGINATOR_ID这个属性来标识，反射器在发布路由时加入ORIGINATOR_ID，当反射器收到的路由信息中的ORIGINATOR_ID就是自己的ROUTER_ID时，就可以发现路由环路的出现，将该路由丢弃，不再转发。
CLUSTER_LIST(簇列表) 用于标识路由反射器组，也是用来防止环路，在路由经过路由反射器时路由反射器会将自己的CLUSTER_ID添加到路由携带的CLUSTER_LIST中，当路由反射器发现接收的路由的CLUSTER_LIST中包含有自己的CLUSTER_ID，则将该路由丢弃，不再转发。

那么我们很清楚的看到了，公认属性已经被定义好了该属性所应发挥的作用，我们无法对其进行个性化修改来实现自己想要的效果。而可选属性大部分都是在多出口选路用以及网络内存在路由反射器 (Route reflector) 对其进行标识以起到防环的作用。而唯一的可自定义的属性则是 COMMUNITY（团体）属性了。要使用 COMMUNITY 来对路由路径进行控制，我们得先了解下该属性的定义。

团体属性可以添加在每一个路由前缀中，由RFC1997定义，是一个transitive optional属性。包含有团体属性的路由，表示该路由是一个路由团体中的一员，该路由团体具有某种或多种相同的特征。根据这些特征区分不同的路由，可以大大简化路由策略的配置工作，同时也增强路由策略的能力。
ref: 新华三技术官网

我们可以预先定义 community 来标识路由并管理路由。但是在这之前，我们需要一个 BGP 网络来进行操作。那么我们就先开始搭建一个数据中心的网络吧！

完整拓扑如下：

你需要准备的事项有：

一台 Juniper MX 路由器（本实验使用 Juniper 路由器进行模拟）
一位找你购买了 Transit 的客户
你向你的上游们购买了 Transit

我们向上游购买带宽后，运营商会为我们拉一条物理链路，并给我们 Transit info 来配置 BGP Peer，Transit info 如下所示：

（以下数据均为模拟环境数据，真实操作请使用运营商给予的信息进行配置）

Transit info：

[AS 1299] Telia carrier 47.0.0.1/31 <-> 47.0.0.0/31 LittleWolf Connect [AS 138667]

[AS 2914] NTT 74.1.0.1/31 <-> 74.1.0.0/31 LittleWolf Connect [AS 138667]

好了，我们现在已经索取到 BGP 信息，是时候开始组建网络了。话不多说，开始搭建！

LittleWolf Router conf:

root@Littlewolf-Backbone> show system rollback compare 2 0
[edit]
+  interfaces {
+      ge-0/0/0 { // 配置 telia 侧的 IP
+          unit 0 {
+              family inet {
+                  address 47.0.0.0/31;
+              }
+          }
+      }
+      ge-0/0/1 { // 配置客户侧的 IP
+          unit 0 {
+              family inet {
+                  address 10.0.0.1/31;
+              }
+          }
+      }
+      ge-0/0/2 { // 配置 NTT 侧的 IP
+          unit 0 {
+              family inet {
+                  address 74.1.0.0/31;
+              }
+          }
+      }
+  }
+  routing-options {
+      static {
+          route 0.0.0.0/0 discard; // 手动汇总默认路由用于发给客户
+      }
+  }
+  protocols {
+      bgp {
+          group upstream { // 配置上游链路组，组名 upstream
+              type external; // 定义邻居类型为 ebgp 邻居
+              local-as 138667; // 本地 ASN 138667 
+              neighbor 47.0.0.1 { // telia carrier bgp 配置文件
+                  import accept-in; // 定义收路由的策略
+                  export export-client; // 定义发路由的策略，这里是将客户路由向外发送
+                  peer-as 1299; // 对端 asn
+              }
+              neighbor 74.1.0.1 { // ntt bgp 配置文件
+                  import accept-in;
+                  export export-client;
+                  peer-as 2914;
+              }
+          }
+          group downstream { // 配置与客户侧相连的下游链路组，组名 downstream
+              type external; // 定义邻居类型为 ebgp 邻居
+              local-as 138667; // 本地 ASN 138667
+              neighbor 10.0.0.0 { // 下游客户的配置文件
+                  import export-client; // 过滤客户路由，只接受合法的 IP段，拒收其他的非客户IP的段（防止客户乱发路由）
+                  export export-default; // 给客户发默认路由
+                  peer-as 65535;
+              }
+          }
+      }
+  }
+  policy-options {
+      policy-statement accept-in {
+          term bgp {
+              from protocol bgp; // 接受 bgp 路由
+              then accept;
+          }
+      }
+      policy-statement export-client {
+          term export-client {
+              from {
+                  protocol bgp;
+                  route-filter 45.0.0.0/24 exact; // 接受客户该合法IP段，若匹配，则存入转发表并发送给上游
+              }
+              then accept;
+          }
+          term reject {
+              then reject; // 拒绝其他路由，一定要写，不然会漏路由
+          }
+      }
+      policy-statement export-default {
+          term export-default {
+              from {
+                  route-filter 0.0.0.0/0 exact; // 将手动汇总的默认路由发送给客户，且只需要发这一条路由
+              }
+              then accept;
+          }
+          term reject {
+              then reject; // 拒绝其他路由，一定要写，不然会漏路由。真实环境中，客户的设备可受不了全表的轰炸！一定要小心！
+          }
+      }
+  }

配置完成了，我们来验证是否成功建立了 BGP 邻居吧！毕竟想要使用 community 必须要已经有正常工作的 BGP 网络呢。

验证骨干路由器的 BGP 邻居：

root@Littlewolf-Backbone> show bgp summary
Groups: 2 Peers: 3 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0
                       7          4          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.0.0.0              65535        107        110       0       0       47:07 1/1/1/0              0/0/0/0
47.0.0.1               1299        112        109       0       0       48:13 3/3/3/0              0/0/0/0
74.1.0.1               2914        112        113       0       0       48:10 0/3/3/0              0/0/0/0

邻居关系建立正确，而且从上游已经收到了来自 Google, Microsoft, Apple 的路由条目。那么我们继续观察下路由表。

验证骨干路由器的路由表：

root@Littlewolf-Backbone> show route protocol bgp

inet.0: 11 destinations, 14 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

8.8.8.8/32         *[BGP/170] 00:42:51, localpref 100
                      AS path: 1299 4785 I, validation-state: unverified
                    > to 47.0.0.1 via ge-0/0/0.0
                    [BGP/170] 00:05:09, localpref 100
                      AS path: 2914 4785 I, validation-state: unverified
                    > to 74.1.0.1 via ge-0/0/2.0
13.64.0.1/32       *[BGP/170] 00:42:51, localpref 100
                      AS path: 1299 4785 I, validation-state: unverified
                    > to 47.0.0.1 via ge-0/0/0.0
                    [BGP/170] 00:00:35, localpref 100
                      AS path: 2914 4785 4785 4785 4785 I, validation-state: unverified
                    > to 74.1.0.1 via ge-0/0/2.0
17.0.0.1/32        *[BGP/170] 00:42:51, localpref 100
                      AS path: 1299 4785 I, validation-state: unverified
                    > to 47.0.0.1 via ge-0/0/0.0
                    [BGP/170] 00:05:09, localpref 100
                      AS path: 2914 4785 I, validation-state: unverified
                    > to 74.1.0.1 via ge-0/0/2.0
45.0.0.0/24        *[BGP/170] 00:51:34, MED 0, localpref 100
                      AS path: 65535 I, validation-state: unverified
                    > to 10.0.0.0 via ge-0/0/1.0

可以看到已经从上游收到了路由表，且与下游客户的路由器也建立了 BGP 连接。那么我们再来看一下客户的路由器吧！

验证客户路由器 BGP 数据库：

client#show ip bgp
BGP table version is 14, local router ID is 10.0.0.0
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal

     Network          Next Hop            Metric LocPrf Weight Path
 *>   0.0.0.0          10.0.0.1                               0 138667 i
 *>   45.0.0.0/24      0.0.0.0                  0         32768 i

可见客户已经成功建立了与我们的 BGP 链接，且已收到我们发过来的默认路由。那么现在网络已经通了吗？

验证网络连通性：

client#ping 8.8.8.8 source 45.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 45.0.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/5/11 ms
client#traceroute 8.8.8.8 source 45.0.0.1
Type escape sequence to abort.
Tracing the route to 8.8.8.8
VRF info: (vrf in name/id, vrf out name/id)
  1 10.0.0.1 [AS 138667] 10 msec 11 msec 3 msec
  2 47.0.0.1 [AS 138667] 6 msec 14 msec 3 msec
  3 101.0.0.0 [AS 138667] 8 msec 10 msec *

Ping 与 Traceroute 结果正常，可见 BGP 工作正常，对方已接受我们的 IP 段，通信正常。

有人会说：小狼小狼，我觉得这管理也不麻烦啊？

对于这种疑问，我想说的是，如果客户网络规模很大而且条目很多，而且客户有要求那些段只能发给哪个 transit，哪些段不能发给哪个 transit，需要维护好几个过滤表，那岂不是很麻烦？为了方便维护，我们就需要是用 community 来进行一站式管理。

欲知后事如何，且听下回分解。

下一篇：从零开始设计运营商级community （中）

《[BGP]从零开始设计运营商级community （上）》有1个想法

Pingback 引用通告： [Cisco]从零开始设计运营商级community （上） | 南ことりの小窝 - 记录我的日常

发表回复取消回复

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据。

LittleWolf Network Universe

小狼的网络世界

[BGP]从零开始设计运营商级community （上）

《[BGP]从零开始设计运营商级community （上）》有1个想法

发表回复取消回复

[BGP]从零开始设计运营商级community （上）

《[BGP]从零开始设计运营商级community （上）》有1个想法

发表回复 取消回复

发表回复取消回复