菜单

[BGP]从零开始设计运营商级community (上)

2020年1月10日 - BGP

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

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

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

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

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

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

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

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

ref: 新华三技术官网

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

完整拓扑如下:

你需要准备的事项有:

我们向上游购买带宽后,运营商会为我们拉一条物理链路,并给我们 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 (中)

发表评论

电子邮件地址不会被公开。 必填项已用*标注