(翻译)：如何部署Contrail网关以及它是如何与Contrail协同工作的

最新推荐文章于 2020-08-03 09:49:16 发布

ljyfree

最新推荐文章于 2020-08-03 09:49:16 发布

阅读量786

点赞数

分类专栏：网络通信

原文链接：https://iosonounrouter.wordpress.com/2019/04/11/setting-up-a-contrail-sdn-gateway-and-how-it-works-with-contrail/

版权

网络通信专栏收录该内容

29 篇文章 3 订阅

订阅专栏

原文链接：https://iosonounrouter.wordpress.com/2019/04/11/setting-up-a-contrail-sdn-gateway-and-how-it-works-with-contrail/
很多固定词语如果硬是翻译成汉语，反而难以理解，因此予以保留，不做翻译。

Juniper的Contrail并不是带着OVS的“香草味”的OpenStack。(没有get到这里的“梗”)

虚机(VM)通常是使用Neutron/OVS,通过被称为“运营商网络”的网络离开数据中心(DC)的。它们使用VLAN网络在数据中心的二层网络架构上与其它网络通信。这意味着配置和管理这些vlan都是在二层网络架构上进行的。

Contrail的方案是不同的。我们只有一个vlan：Contrail控制+数据都在这个vlan。在这个vlan中，Contrail会建立隧道用于计算资源之间的通信，也可以将虚机流量发送到数据中心之外。当这些流量需要离开数据中心，它们会经过一台作为SDN网关的设备。“SDN网关”并不是一个新概念；数据中心本来就会有“数据中心网关”，就像企业网会有一个“广域网(WAN)网关”一样，用来连接国际互联网上的各个分支机构。

SDN gateway跟DC gateway的不同之处在于前者是跟SDN控制器(controller)集成在一起的。在一个标准的Neutron/OVS环境中，DC gateway是绑定在OpenStack上的；它只是接收属于这些vlan的流量。而SDN gateway会和SDN controller相互作用，参与到控制平面信息交换(通过BGP协议)和数据平面流量(通过tunnel)。

接下来我们会一起来试着理解上面提到的这些。

我们使用下面这个简单地拓扑(topology)作为参考：

一台MX交换机作为SDN gateway，这样我们就有了一个Contrail云。我们接下来聚焦两个两个元素：控制节点和计算节点(VM就跑在计算节点上)：

这里是理解contrail如何工作的关键点。接下来我们将看到Contrail只是复用众所周知的概念，只是将它们带入了新时代：SDN。
下面要展示的内容和我们已经熟知的L3 VPN非常类似：

SDN gateway就像是支持VRF隔离功能的PE
这些计算节点也像是支持VRF隔离功能的PE(请记住，从Contrail的视角来看，一个虚拟网络就是vrouter上的一个vrf)
控制节点就像是一台路由反射器
虚机就像是正在通过协议(静态路由或BGP路由)作为PE-CE之间交换信息的CE(与vrouter交换路由信息)

后面上述概念会进一步进行说明。

让我们从SDN gateway的Contrail控制“对话”开始。这个“对话”使用BGP协议，用作控制平面通信。路由信息在SDN gateway和contrail之间进行交换。和L3VPN一样，route target被用来标识路由该被哪个/些VRF处理。这意味着从SDN gateway向虚拟网络(被指定了route target的VRF)通告路由，反之亦然。

这个BGP的会话，可以使用iBGP或是eBGP；这里因为contrail和SDN gateway属于不同的AS，因此使用eBGP。此外因为BGP的端点不在一个LAN内，因此BGP session要设置为多跳(multihop)。

首先，需要确认SDN gateway是可达的。在我们的环境中存在两台SDN gateway，这样就会有两个BGP session。我们先关注其中一台，另外一台和这台的工作原理是一样的。Contrail必须有一个接口是在控制+数据网络中(这个已经在二层交换网络中配置好了)。

[root@cctrl ~]# ifconfig eth1
eth1: flags=4163  mtu 9000
        inet 192.168.200.10  netmask 255.255.255.0  broadcast 192.168.200.255
        inet6 fe80::200:ff:fe42:11  prefixlen 64  scopeid 0x20
        ether 00:00:00:42:00:11  txqueuelen 1000  (Ethernet)
        RX packets 18811623  bytes 28524979120 (26.5 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 16157459  bytes 1514455749 (1.4 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

控制节点必须有到SDN gateway的路由

[root@cctrl ~]# ip route
...
192.168.255.101 via 192.168.200.1 dev eth1
192.168.255.102 via 192.168.200.1 dev eth1

并且网络可达

[root@cctrl ~]# ping -c 3 192.168.255.101
PING 192.168.255.101 (192.168.255.101) 56(84) bytes of data.
64 bytes from 192.168.255.101: icmp_seq=1 ttl=61 time=23.7 ms
64 bytes from 192.168.255.101: icmp_seq=2 ttl=61 time=8.45 ms
64 bytes from 192.168.255.101: icmp_seq=3 ttl=61 time=10.6 ms
--- 192.168.255.101 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 8.457/14.292/23.769/6.761 ms
 
[root@cctrl ~]# ping -c 3 192.168.255.102
PING 192.168.255.102 (192.168.255.102) 56(84) bytes of data.
64 bytes from 192.168.255.102: icmp_seq=1 ttl=62 time=1.88 ms
64 bytes from 192.168.255.102: icmp_seq=2 ttl=62 time=9.62 ms
64 bytes from 192.168.255.102: icmp_seq=3 ttl=62 time=9.34 ms
--- 192.168.255.102 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 1.884/6.952/9.626/3.587 ms

在Contrail的图形化界面(GUI)上我们可以配置BGP路由器。在当前场景下会配置两个：

下面展示是如何配置的：

Vendor设置为Juniper
IP地址和Router ID设置为BGP端点地址
AS号设置为SDN gateway的AS号
选择你需要支持的address families

最后我们将它关联到控制节点(这里我们还关联到其它设备，不过在我们可以先忽略)。

Contrail节点这边，只需要完成这些就可以了。

下面开始配置SDN gateway。

我们配置BGP session:

tim@mx10003-4-ES-2# show protocols bgp group Contrail-Control
type external;
multihop;
local-address 192.168.255.102;
family inet-vpn {
    unicast;
}
family route-target {
    external-paths 3;
}
export BGP-Contrail-Control-EXP;
vpn-apply-export;
remove-private;
peer-as 64520;
multipath;
neighbor 192.168.200.10;

BGP类型是外部(external)
session是多跳
本地地址使用的是一个从contrail可达的地址(配置在loopback端口上)
是能的address-family包括 inet-vpn unicast和route-target
对等体的AS号就是Contrail的AS号
当通告路由的时候，我们将私有AS号删除掉
邻居就是Contrail控制节点
是能多路径(用来做负载均衡)
一个export策略被应用到vpn路由上了

这个export策略如下：

tim@mx10003-4-ES-2# show policy-options policy-statement BGP-Contrail-Control-EXP
term INET-VPN {
    from family inet-vpn;
    then {
        community add COM-ENCAP-UDP;
    }
}
then reject;

这条策略的作用就是将要发给Contrail的vpn路由加一条团体属性。

来看一下这条属性

tim@mx10003-4-ES-2# show policy-options community COM-ENCAP-UDP
members 0x030c:64520:13;

这条团体属性并不是随机的。我们认得64520，这就是Contrail的AS号，但这个并不是最重要的。真正关键的是“0x030c”和“13”。它表示“这条路由将会使用MPLSoUDP(MPLS作为UDP的payload)封装”。MPLSoUDP是Contrail支持的一种overlay的技术。L3的overlay可以使用MPLSoUDP或是MPLSoGRE，L2的overlay使用VXLAN。虽然也可以使用MPLSoGRE，但是我们还是建议使用MPLSoUDP，因为MPLS0UDP可以提供更好的负载均衡(UDP的源端口可以设置为内部报文的hash值)。此外MPLSoUDP是计算资源之间通信的默认overlay方式。

小结一下，这条团体属性让Contrail明白它需要将去往包含这条属性的路由的报文做MPLSoUDP的封装。

上面说的都是控制平面。

还有数据平面。下面做一下澄清：我们使用BGP作为控制平面，MPLSoUDP作为数据平面。简而言之，SDN gateway通过MP-eBGP从Contrail节点学习到VM IP。这些BGP路由包含了运行着VM的主机节点信息。计算节点就是MPLSoUDP隧道的端点。数据平面使用这个隧道作在VM和SDN gateway之间发送报文。

这些MPSLoUDP隧道是动态建立的，这意味它们只会在需要的时候才会被创建出来。例如，当SDN gateway一收到来自一个计算节点上VM的主机路由，立刻就会创建一条隧道。稍后我们会更好地理解这一点。

基本是动态建立，我们还是需要提前告知SDN gateway准备创建这些动态隧道：

tim@mx10003-4-ES-2# show routing-options dynamic-tunnels
ComputeNode {
    source-address 192.168.255.102;
    udp;
    destination-networks {
        192.168.200.0/24;
    }
}

这条配置告诉SDN gateway允许使用192.168.255.102作为源IP，在计算节点所在的控制+数据网络中，动态创建MPLSoUDP隧道。在设置控制+数据网络过程中，我们也需要覆盖控制节点；这是为了保证在inet.3中有到达控制节点的路由，使得MX交换机可以解析BGP路由(这和我们使用RR发布VPN路由的原理是一样的)。

目前为止所需的配置都已经到位了。

我们来检查一下BGP session的状态：

tim@mx10003-4-ES-2> show bgp neighbor 192.168.200.10 | match State
  Type: External    State: Established    Flags: 
  Last State: OpenConfirm   Last Event: RecvKeepAlive

我们可以看到之前配置的选项：(但是并没有选项显示啊？)

tim@mx10003-4-ES-2> show bgp neighbor 192.168.200.10 | match Options
  Options: 
  Options:

协商后的address families：

tim@mx10003-4-ES-2> show bgp neighbor 192.168.200.10 | match NLRI
  NLRI for restart configured on peer: inet-vpn-unicast route-target
  NLRI advertised by peer: inet-vpn-unicast inet6-vpn-unicast route-target evpn
  NLRI for this session: inet-vpn-unicast route-target
  NLRI that restart is negotiated for: inet-vpn-unicast route-target
  NLRI of received end-of-rib markers: inet-vpn-unicast route-target
  NLRI of all end-of-rib markers sent: inet-vpn-unicast route-target

Contrail会通告更多的address families(例如evpn)，但是只有 inet-vpn-unicast和route-target会用到。这两个BGP peer之间交换的路由包括x下述表:

tim@mx10003-4-ES-2> show bgp neighbor 192.168.200.10 | match Table
  Table LTE-TRAFFIC.inet.0
  Table bgp.l3vpn.0 Bit: 20000
  Table bgp.rtarget.0 Bit: 10000

可以通过查看收到的路由信息进行确认：

tim@mx10003-4-ES-2> show route receive-protocol bgp 192.168.200.10
 
inet.0: 30 destinations, 32 routes (30 active, 0 holddown, 0 hidden)
 
inet.3: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
 
LTE-TRAFFIC.inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 0.0.0.0/0               192.168.200.11                          64520 65101 I
* 172.30.124.10/32        192.168.200.11       100                64520 ?
* 172.30.124.11/32        192.168.200.11       100                64520 ?
* 192.168.20.3/32         192.168.200.11       200                64520 ?
* 192.168.20.4/32         192.168.200.11       200                64520 ?
 
mpls.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
 
bgp.l3vpn.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  192.168.200.11:5:0.0.0.0/0
*                         192.168.200.11                          64520 65101 I
  192.168.200.11:5:172.30.124.10/32
*                         192.168.200.11       100                64520 ?
  192.168.200.11:5:172.30.124.11/32
*                         192.168.200.11       100                64520 ?
  192.168.200.11:5:192.168.20.3/32
*                         192.168.200.11       200                64520 ?
  192.168.200.11:5:192.168.20.4/32
*                         192.168.200.11       200                64520 ?
 
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
 
LTE-TRAFFIC.inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
 
bgp.rtarget.0: 50 destinations, 50 routes (37 active, 0 holddown, 13 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  64520:64520:101/96
*                         192.168.200.10                          64520 I
  64520:64520:102/96
*                         192.168.200.10                          64520 I
  64520:64520:6100/96
*                         192.168.200.10                          64520 I
  64520:64520:6200/96
*                         192.168.200.10                          64520 I
...

这里涉及到了一个众所周知的表——bgp.l3vpn.0。再次验证了理解Contrail和SDN gateway是如何协作，只需要我们已经非常熟悉的概念，不需要额外的学习成本。

我们来看一条具体的路由(VM的地址)：

tim@mx10003-4-ES-2> show route receive-protocol bgp 192.168.200.10 172.30.124.10/32 extensive table bgp.l3vpn.0
 
bgp.l3vpn.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
* 192.168.200.11:5:172.30.124.10/32 (1 entry, 1 announced)
     Import Accepted
     Route Distinguisher: 192.168.200.11:5
     VPN Label: 34
     Nexthop: 192.168.200.11
     MED: 100
     AS path: 64520 ?
     Communities: target:64520:102 target:64520:8000004 encapsulation:unknown(0x2) encapsulation:mpls-in-udp(0xd) mac-mobility:0x0 (sequence 1) unknown type 0x8071:0xfc08:0x7

关注一下团体属性，其中两个非常的重要：MPLSoUDP和RT:64520:102。这个是我们配置在contrail内部虚拟网络的RT。

此外，我们看到了VPN标签(VPN Label: 34),这个是MPLSoUDP的内部报文用到的标签。

Route distinguisher是192.168.200.11:5，其中192.168.200.11是计算节点控制+数据地址，上面跑的VM的IP是172.30.124.10。这个可以在下面的表项中得到确认：nexthop field: 192.168.200.11。

这里清晰地验证了我们之前说过的：我们通过BGP在Contrail控制节点和SDN gateway之间交换路由，我们在SDN gateway和计算节点之间通过MPLSoUDP隧道发送/接收实际数据流量。

我们之前看到过SDN GW上的一个VRF被使用了，让我们再看一下

tim@mx10003-4-ES-2# show routing-instances LTE-TRAFFIC | match vrf
instance-type vrf;
vrf-import LTE-IMPORT;
vrf-export LTE-EXPORT;
vrf-table-label;

我们查看一下import policy：

tim@mx10003-4-ES-2# show policy-options policy-statement LTE-IMPORT
term 1 {
    from {
        protocol bgp;
        community 64520:102;
    }
    then accept;
}
term 2 {
    then reject;
}
tim@mx10003-4-ES-2# show policy-options community 64520:102
members target:64520:102;

VRF被用来导入输入INGRESS虚拟网络的路由。这就是我们从VM扩展虚拟网络到外边使用的方法！这并不是新引入的概念：这就是标准的L3VPN！从SDN GW的角度来看，这不过是PE从路由反射器(RR)收到的如何到达其它PE的路由。它根本不知道，也无需要知道真正发布路由的PE其实是一些vRouter。一旦我们完成将contrail的路由导入到vrf，剩下的事情就顺理成章了：通往远端PE的MPLS隧道， 0/0 next-table to GRT(这句不知道如何翻译)，以此类推……

我们来看一下VRF内的VM路由的细节：

tim@mx10003-4-ES-2> show route table LTE-TRAFFIC.inet.0 172.30.124.10/32 extensive
 
LTE-TRAFFIC.inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
172.30.124.10/32 (1 entry, 1 announced)
TSI:
KRT in-kernel 172.30.124.10/32 -> {indirect(1048577)}
        *BGP    Preference: 170/-101
                Route Distinguisher: 192.168.200.11:5
                Source: 192.168.200.10
                Next hop type: Tunnel Composite, Next hop index: 639
                Import Accepted
                VPN Label: 34
                Localpref: 100
                Router ID: 192.168.200.10
                Primary Routing Table bgp.l3vpn.0
                Indirect next hops: 1
                        Protocol next hop: 192.168.200.11
                        Label operation: Push 34
                        Indirect path forwarding next hops: 1
                                Next hop type: Tunnel Composite
                                Next hop:
                                192.168.200.11/32 Originating RIB: inet.3
                                  Node path count: 1
                                  Forwarding nexthops: 1
                                        Next hop type: Tunnel Composite
                                        Tunnel type: UDP, nhid: 0, Reference-count: 4, tunnel id: 0
                                        Destination address: 192.168.200.11, Source address: 192.168.255.102

这里有很多有趣的事情。我们可以很容易找到MPLS标签。下一跳的类型是隧道(MPLSoUDP tunnel),还有这条隧道的端点。源IP是192.168.255.102(这个是我们在动态tunnel下配置的)，目的IP是192.168.200.11(承载VM的宿主机IP)。这条路由在inet.3中，所以正如我们已经知道的，在inet.3 这个address family中解析这条BGP路由。

关注一下：这条路由的源是192.168.200.10(contrail控制节点，RR，控制平面，BGP)，下一跳是192.168.200.11(计算节点，vrouter，数据平面，MPLSoUDP)。

SDN GW的路由也会发布给contrail：

tim@mx10003-4-ES-2> show route advertising-protocol bgp 192.168.200.10
 
LTE-TRAFFIC.inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.10.0.0/24            Self                 0                  I
* 10.20.0.0/24            Self                 0                  I
* 170.170.170.1/32        Self                 0                  I
* 192.168.254.38/31       Self                 2                  I
 
bgp.l3vpn.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  192.168.255.102:100:10.10.0.0/24
*                         Self                 0                  I
  192.168.255.102:100:10.20.0.0/24
*                         Self                 0                  I
  192.168.255.102:100:170.170.170.1/32
*                         Self                 0                  I
  192.168.255.102:100:192.168.254.38/31
*                         Self                 2                  I
 
bgp.rtarget.0: 50 destinations, 50 routes (37 active, 0 holddown, 13 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  3269:64520:102/96
*                         Self                                    I

请记住这些路由，我们会发现它们全都出现在contrail的虚拟网络路由表中。

我们来观察其中一条路由：

tim@mx10003-4-ES-2> show route advertising-protocol bgp 192.168.200.10 10.10.0.0/24 table bgp.l3vpn.0 extensive
 
bgp.l3vpn.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
* 192.168.255.102:100:10.10.0.0/24 (1 entry, 1 announced)
 BGP group Contrail-Control type External
     Route Distinguisher: 192.168.255.102:100
     VPN Label: 16
     Nexthop: Self
     Flags: Nexthop Change
     MED: 0
     AS path: [3269] I
     Communities: target:64520:102 rte-type:0.0.0.0:5:1 encapsulation:mpls-in-udp(0xd)

这里设置了两条团体属性：RT与contrail的虚拟网络匹配，封装也是MPLSoUDP。当然，我们也会通告MPLS标签。请记住，此处的标签和L3VPN中的标签含义一般无二！

那条路由是VRF通过OSPF学习到的：

tim@mx10003-4-ES-2> show route table LTE-TRAFFIC.inet.0 10.10.0.0/24
 
LTE-TRAFFIC.inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
 
10.10.0.0/24       *[OSPF/171] 2d 19:22:13, metric 0, tag 0
                    >  to 192.168.254.40 via ae3.2

OSPF在这里用作PE-CE之间交换路由的协议，跑在SDN GW和另外的设备之间(不在上述拓扑中)。

我们的vrf export policy匹配OSPF路由，并添加必须的RT:

tim@mx10003-4-ES-2# show policy-options policy-statement LTE-EXPORT
term 1 {
    from protocol ospf;
    then {
        community add 64520:102;
        accept;
    }
}
then reject;

Contrail虚拟网络默认会导入和自己的RT一致的路由。

可选的，我们可以为虚拟网络配置多个import/export RT，跟我们在运行Junos设备上使用import/export policy是一样的。

上述描述涵盖了Contrail-SDN GW基本的通信过程。

我觉得很容易从中找出一些优势。例如contrail的控制+数据只需要一个vlan。此外，还有一个BGP session可以承载多个虚拟网络的路由分发。DC之外的设备再也不需要和每一个VM建立邻居关系，所需的信息只要一个MP-eBGP session就全部搞定！

ljyfree

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
(翻译)：如何部署Contrail网关以及它是如何与Contrail协同工作的

原文链接：https://iosonounrouter.wordpress.com/2019/04/11/setting-up-a-contrail-sdn-gateway-and-how-it-works-with-contrail/很多固定词语如果硬是翻译成汉语，反而难以理解，因此予以保留，不做翻译。Juniper的Contrail并不是带着OVS的“香草味”的OpenStack。(没...
复制链接

扫一扫