(翻译)：如何部署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。(没有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 9000inet 192.168.200.10  netmask 255.255.255.0  broadcast 192.168.200.255inet6 fe80::200:ff:fe42:11  prefixlen 64  scopeid 0x20ether 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 0TX 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 StateType: External    State: Established    Flags: Last State: OpenConfirm   Last Event: RecvKeepAlive

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

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

协商后的address families：

tim@mx10003-4-ES-2> show bgp neighbor 192.168.200.10 | match NLRINLRI for restart configured on peer: inet-vpn-unicast route-targetNLRI advertised by peer: inet-vpn-unicast inet6-vpn-unicast route-target evpnNLRI for this session: inet-vpn-unicast route-targetNLRI that restart is negotiated for: inet-vpn-unicast route-targetNLRI of received end-of-rib markers: inet-vpn-unicast route-targetNLRI 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 TableTable LTE-TRAFFIC.inet.0Table bgp.l3vpn.0 Bit: 20000Table bgp.rtarget.0 Bit: 10000

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

tim@mx10003-4-ES-2> show route receive-protocol bgp 192.168.200.10inet.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 path192.168.200.11:5:0.0.0.0/0
*                         192.168.200.11                          64520 65101 I192.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 path64520:64520:101/96
*                         192.168.200.10                          64520 I64520:64520:102/96
*                         192.168.200.10                          64520 I64520:64520:6100/96
*                         192.168.200.10                          64520 I64520: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.0bgp.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 AcceptedRoute Distinguisher: 192.168.200.11:5VPN Label: 34Nexthop: 192.168.200.11MED: 100AS 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 extensiveLTE-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/-101Route Distinguisher: 192.168.200.11:5Source: 192.168.200.10Next hop type: Tunnel Composite, Next hop index: 639Import AcceptedVPN Label: 34Localpref: 100Router ID: 192.168.200.10Primary Routing Table bgp.l3vpn.0Indirect next hops: 1Protocol next hop: 192.168.200.11Label operation: Push 34Indirect path forwarding next hops: 1Next hop type: Tunnel CompositeNext hop:192.168.200.11/32 Originating RIB: inet.3Node path count: 1Forwarding nexthops: 1Next hop type: Tunnel CompositeTunnel type: UDP, nhid: 0, Reference-count: 4, tunnel id: 0Destination 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.10LTE-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                  Ibgp.l3vpn.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)Prefix                  Nexthop              MED     Lclpref    AS path192.168.255.102:100:10.10.0.0/24
*                         Self                 0                  I192.168.255.102:100:10.20.0.0/24
*                         Self                 0                  I192.168.255.102:100:170.170.170.1/32
*                         Self                 0                  I192.168.255.102:100:192.168.254.38/31
*                         Self                 2                  Ibgp.rtarget.0: 50 destinations, 50 routes (37 active, 0 holddown, 13 hidden)Prefix                  Nexthop              MED     Lclpref    AS path3269: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 extensivebgp.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 ExternalRoute Distinguisher: 192.168.255.102:100VPN Label: 16Nexthop: SelfFlags: Nexthop ChangeMED: 0AS path: [3269] ICommunities: 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/24LTE-TRAFFIC.inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both10.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就全部搞定！

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

项目部署时网关怎么回事_使用Kubernetes部署聊天网关（或技术按预期运行时）...
项目部署时网关怎么回事 by Richard Li 理查德·李(Richard Li) 使用Kubernetes部署聊天网关(或技术按预期运行时) (Using Kubernetes to deplo ...
06-Windows Server 2012 R2 会话远程桌面-标准部署-RD网关(RemoteApp)
Windows Server 2012 R2 会话远程桌面-标准部署-RD网关(RemoteApp) 马博峰一.什么是RD网关远程桌面网关(RD 网关),在早期版本的远程桌面连接中称为TS网关,在 ...
freeswitch部署及网关调试
freeswitch部署及网关调试目录 freeswitch部署及网关调试... - 1 - 一.freeswitch部署... - 3 - (一)基础部署... - 3 - (二)根据实际情况需求 ...
Docker的部署-包括网关服务(Ocelot)+认证服务(IdentityServer4)+应用服务
本文主要介绍通过Docker来部署通过.Net Core开发的微服务架构,部署的微服务主要包括统一网关(使用Ocelot开发).统一认证(IdentityServer4).应用服务(asp.net c ...
k8s集群中部署kong网关与konga
kong官方文档中的部署方案因为某种奇葩的原因,不能对helm文件中的镜像拉取,所以我这里对kong的docker镜像部署. 首先要搭建postgresql 可以选择集群外搭建,也可以集群内搭建. 参 ...
Linux网络部署（网关、dns、网桥）
文章目录 1 网关 2.设置不同网段的网络通信(网关) 2.1 在企业7添加一块网卡是企业7主机变成双网卡主机(桥接模式) 2.2 设置rhel7主机两块网卡地址为: 2.3 在rhel7中打开内核路 ...
猫头鹰的深夜翻译：API网关的重要性
前言在非技术术语中,"网关或门是进入一个由墙围住的封闭空间的入口点."同理,API网关是指位于防火墙或互联网后面的服务的入口点.在微服务的世界中,网关坐镇于API前面,直接面向 ...
Istio流量管理实践之(5): 使用cert-manager部署Istio自定义入口网关及进行证书管理...
Istio Gateway提供多个自定义入口网关的支持能力,通过开放一系列端口用于承载网格边缘的进入连接,同时可以使用不同loadbalancer来隔离不同的入口流量.cert-manager可用于使 ...
开箱即用Bumblebee独立部署搭建webapi网关详解
在之前的章节里都是讲述如何在程序中使用Bumblebee来构建一个Webapi网关:但这样显然有些麻烦,毕竟很多时候可能只需要一个简单负载处理,还需要写个程序针对服务进行编写代码或配置的确是比较麻烦的 ...
成都天府七中智慧校园蓝牙网关部署方案
北京桂花网蓝牙路由器及物联网控制器参与部署成都天府七中智慧校园,成都天府七中坐落于四川省成都市,目前已在学校的教室.校门口及其他公共区域区域部署蓝牙网关,为学校的走班制教学提供了新式管理方式,受到学校 ...

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

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

最新文章

热门文章