IP Interconnect Fabrics in Calico
Calico 爲大規模集羣以及雲環境的節點提供了 end-to-end 的網絡互聯。爲此，calico 需要一個物理層的互聯架構。
大多數情況下， 以太網架構是最合適的。但是對於已有的三層架構，可能會對 calico 造成影響。
由於Calico本身就是路由基礎設施，因此在運行Calico時使用IP路由互連結構需要考慮更多的工程，架構和操作注意事項。 我們將簡要介紹這篇文章的其餘部分。 也就是說，Calico可同時在以太網或IP互連架構上保持良好運行。
Background
Basic Calico architecture overview
有關calico 架構的詳述可以在 architectural overview 中找到。
在 calico 中，計算節點充當了路由器的角色。它們爲運行在本機上的容器或是虛擬機提供路由。因此我們稱之爲 vRouter。Linux Kernel 負責數據數據包路由， 通過BPG協議來控制路由分發， calico agent Flelix 來管理路由信息。
The data path is provided by the Linux kernel, the control plane by a BGP protocol server, and management plane by Calico’s on-server agent, Felix.
處於節點上的 Endpoint 只能同本節點 vRouter 通信， calico 中，數據包的第一條和最後一條都是通過 vRouter 中路由規則來實現。vRouter 間通過BGP協議來同步節點上的 Endpoint 信息
Overview of current common IP scale-out fabric architectures
對於可橫向擴展的集羣，有兩種方式構建IP架構。然而， 迄今爲止，這兩種方案需要當邊界路由器同時負責機架間上行數據交換的時候才ok。在 calico 中，計算節點本身已經集成了該功能。
此外，在絕大多數虛擬化場景中，都會採用 overlay 或者 Nat 的方式來封裝 vm 或者 容器間通信的報文。例如 weave 和 docker 自帶的網絡。
- 路由架構基於某種形式的IGP。由於IGP網絡的擴展限制（see the why BGP post for discussion of this topin）, calico 工程小組認爲使用IGP協議可能導致 Endpoint 路由無法全部分發到所有節點。但同時使用 IGP 和 BGP 是可行的。其中 IGP 傳遞
vRouter下一跳路由信息（在 calico 中對應目的計算節點），BGP 用於分發 endpoint 的下一跳路由信息。實際上，這是廣泛分佈的IP網絡（比如運營商的骨幹網絡）中最常見的做法。由於其設計較爲複雜，本文不做詳述。 - 路由架構完全使用BGP協議。在這種模式下，IP 網絡需要足夠的緊湊才能保障 BGP 協議用於 endpoint 路由信息的分發（如果集羣太大，會導致同步時間過長）。同時
vRouter間的路由也會被所有節點所掌握。本文將會重點介紹這個方案。
BGP-only interconnect fabrics
構建一個 BGP-only 的通信架構有多種方案。主要關注三種實現方案，其中每個方式又包含2個變體。
兩種變體如下：
1. 第一種BGP架構：每個TOR交換機（包括交換機下附屬的服務器）是一個獨立的 Autonomous System(AS). 各個TOR交換機之間通過 leaf/spine 架構中的 spine switch 交換設備通信（如下圖）,或者通過一系列的 spine swtiches。同樣，每個 spine switch 是獨立的 AS。 我們將其稱之爲每個 AS per rack model 。 該模型在 IETF working group draft 中有詳細介紹
2. 第二種BGP架構：每個計算節點都是獨立的AS，TOR 交換機實現AS間通信。我們將其稱之爲 AS per server model
每種方案都包含一個2層或者3層變體。
在第一種架構下（2層），每個 spine switch 提供一個隔離的2層連接平面（個人理解：vlan）來作爲 Calico 以太網互聯結構模型。每個 TOR 交換機和每個 spine switch 互連。
另一種架構下（3層），每個 spine switch 看做是一個隔離的 AS，TOR 交換機和 spine switch BGP對等。在這兩種情況下， TOR 交換機使用 ECMP 實現所有可用 spine switch 的負載均衡。
BGP: Border Gateway Protocol，邊界網管協議
BGP用於在不通的AS 間交換路由信息。當兩個AS需要交換路由信息時，每個AS都必須指定一個運行BGP的節點，來代表AS與其他的AS交換路由信息。這個節點可以是一個主機。但通常是路由器來執行BGP。兩個AS鍾利用BGP交換信息的路由器也被稱爲邊界網關（Border Gateway) 或邊界路由器(Border Router)。
由於可能與不同的AS相連，在一個AS內部可能存在多個運行BGP的邊界路由器。同一個AS中的兩個或多個對等實體之間運行的BGP被稱爲IBGP(Internal/interior BGP)。歸屬不同的AS的對等實體之間運行的BGP稱爲EBGP(External/Exterior BGP)。在AS邊界上與其他AS交換信息的路由器被稱爲邊界路由器(Border/edge router)。在互聯網操作系統(Cisco IOS)中，IBGP通告的路由距離爲200， 優先級比EBGP和任何內部網關協議(IGP)通告的路由都低。其他的路由器實現中，優先級順序也是EBGP高於IGP，而IGP又高於IBGP。
BGP屬於外部網關路由協議，可以實現AS間無環路的域間路由。BGP是溝通Internet 廣域網的主要路由協議，例如不同省份、不同國家之間的路由大多要依靠BGP協議。BGP可分爲IBGP和EBGP.BGP的鄰居關係(或稱爲通信對端/對等實體)是通過人工配置實現的，對等實體之間通過TCP(179端口)會話交互數據。BGP路由器會週期地發送19字節的
keep-alive消息來維護連接(默認週期爲30s)。在路由協議中，只有BGP使用TCP作爲傳輸層協議。ECMP: 等價路由
ECMP存在多條不同鏈路到達同一目的地址的網絡環境中，如果使用傳統的路由技術，發往該目的地址的數據包只能利用其中的一條鏈路，其它鏈路處於備份狀態或無效狀態，並且在動態路由環境下相互的切換需要一定時間，而等值多路徑路由協議可以在該網絡環境下同時使用多條鏈路，不僅增加了傳輸帶寬，並且可以無時延無丟包地備份失效鏈路的數據傳輸。
ECMP最大的特點是實現了等值情況下，多路徑負載均衡和鏈路備份的目的，在靜態路由和OSPF中基本上都支持ECMP功能。
但是實際情況是，各路徑的帶寬、時延和可靠性等不一樣，把Cost認可成一樣，不能很好地利用帶寬，尤其在路徑間差異大時，效果會非常不理想。例如，路由器兩個出口，兩路徑，一個帶寬是100M，一個是2M，如果部署是ECMP，則網絡總帶寬只能達到4M的利用率。
Some BGP network design considerations
同主流的意見相比，BGP 實際上是個相對簡單的協議。eg. BGP 在 calico 節點上的配置大約只有6行（除去註釋）。只是BGP的使用方式會讓人感覺很複雜。許多BGP使用場景都涉及到了複雜的策略規則，用來滿足技術需求(比如商業,金融等)。Calico 默認不考慮這些複雜的需求，因此相當簡潔。
也就是說，在設計 Calico 節點網絡時只需要記住少數幾條設計原則即可。這些設計要求可以被移植，如果有必要，但是這樣做會使設計人員脫離標準的BGP封裝，只能由一個對高級BGP設計非常熟悉的實現者來完成。
注意事項：
AS continuity
or AS puddling Any router in an AS must be able to communicate with any other router in that same AS without transiting another AS.
不會翻 ╮(╯▽╰)╭
Next hop behavior
默認情況下，對於位於同一AS下的對等實體，BGP路由器不會改變下一跳路由。反之也成立， 對等實體處於其它AS，BGP路由器會重設自己的下一跳路由。Router reflection
位於同一AS下的所有BGP 路由器彼此對等，這種行爲又稱爲complete BGP mesh(IBGP全連接)。當路由器數量擴張時，這種全網狀的連接就會產生問題。Router reflection可以減輕全網連接的負載。當然，route reflection也需要做擴容考慮。路由反射器
提供了在大型IBGP實現中IBGP全網狀連接問題的一個簡單解決方案。爲保證IBGP對等體之間的連通性，需要在IBGP對等體之間建立全連接關係。假設在一個AS內部有n臺路由器，那麼應該建立的IBGP連接數就爲n(n-1)/2。當IBGP對等體數目很多時，對網絡資源和CPU資源的消耗都很大。
利用路由反射可以解決這一問題。在一個AS內，其中一臺路由器作爲路由反射器RR（Route Reflector），其它路由器作爲客戶機（Client）與路由反射器之間建立IBGP連接。路由反射器在客戶機之間傳遞（反射）路由信息，而客戶機之間不需要建立BGP連接。
Endpoints
在 Calico 網絡中，每個Endpoint都對應一條路由。 硬件網絡平臺有學習路由數量的限制，一般在 10,000 ~ 100,000 條之間。路由聚合是個辦法，但這通常取決於編排軟件（例如OpenStack）使用的調度程序的功能。
The AS Per Rack model
將一個機架看做一個AS（一般TOR交換機和連接該交換機的服務器位於同一個機架上）。這種模式最接近 IETF’s Routing Area Working Group draft on BGP use in data centers. 中給出的建議。
正如之前所提到的，這種方案有兩個變種，一個使用一組二層平面，平面間節點通過 TOR 交換機通信，另外一種則使用三層平面，通過Spine switch 通信。
This diagram shows the AS per rack model where the ToR switches are physically meshed via a set of Ethernet switching planes.
This diagram shows the AS per rack model where the ToR switches are physically meshed via a set of discrete BGP spine routers, each in their own AS.
在這種方案裏，每個Tor 交換機到Tor 交換機或者TOR交換機到 spine switch 的鏈路是EBGP對等的。那就意味着北向 tor 交換機無法使用 RR(Route Reflector)。
如果使用了2層的方式，結果就是每個Tor 交換機之間必須彼此對等(可能有上百個對等)，可能會造成負載過重。
如果使用3層的方式，那麼每個TOR 交換機只需要和上級的 spine switch 對等即可。雖然spine switch 下會有許多TOR 交換機，可以使用RR（如上圖所示），而且絕大部分spine switch擁有比TOR交換機更好的平面控制能力，在多數環境下更易擴展。
兩者的配置基本相同，只是在TOR 交換機的北向配置上有些差異。
TOR 交換機，作爲EBGP router 會獲取其他TOR switch 以及數據中心上的路由，重新分配到該AS下的每個計算節點上。並且會將自身AS內的所有路由信息向外通告。這就意味着，每個計算節點會將該AS內的TOR 交換機視爲到外部路由的下一跳。外部路由到該AS的下一跳則是該AS下的某臺計算節點
The ToR, as the eBGP router redistributes all of the routes from other ToRs as well as routes external to the data center to the compute servers that are in its AS, and announces all of the routes from within the AS (rack) to the other ToRs and the larger world. This means that each compute server will see the ToR as the next hop for all external routes, and the individual compute servers are the next hop for all routes external to the rack.
The AS per Computer Server model
這種模式的概念同 The AS per rack 類似。在早期的 IETF draft 中，整個架構的路由和匯聚都由TOR發起。在 Calico 中，那麼路由和匯聚的起始點爲各計算節點。如果TOR爲3層的路由器，也只能作爲2機的路由和匯聚點。
因此，順着架構往下分析，計算節點會作爲AS的邊界router。同 The AS per rack 的差異可從下面2張圖體現。
This diagram shows the AS per compute server model where the ToR switches are physically meshed via a set of Ethernet switching planes.
This diagram shows the AS per compute server model where the ToR switches are physically connected to a set of independent routing planes.
從上圖不難發現，TOR 和 spine swtich 和 AS per rack 模式中一樣。真正的不同在於，計算節點和TOR處於不同的AS中。爲了擴展集羣，需要使用4字節的AS編號(RFC 4893). 如果不使用4字節的AS編號（默認2字節），那麼calico 平面中的TOR 和計算節點大約只有5000左右的私有AS編號可使用。如果採用了4字節，則會有接近92,000000私有AS編號可用。
4字節AS*
AS (Autonomous System number，自治域系統號)是指擁有同一選路策略，在同一技術管理部門下運行的一組路由器的集合。BGP的RFC1771裏留給AS的範圍是2個字節，所以AS的取值範圍爲
1-65535，其中64512以上的爲私有AS。由於BGP在鄰居協商以及路由發送接受的時候都需要使用AS屬性, 鑑於IPv4地址空間不夠這個前車之鑑，在RFC4893裏定義了一個BGP的新功能——4字節AS（BGP Support for Four-octet AS Number，一般用M.N來描述）。
還有個差異，就是在per AS Compute Server 模式中沒有 RR(Router Reflector)。所有設備都是EBGP對等的。當同一機架下的兩個計算節點之間需要通信時，會通過TOR來路由。
可以將這種模式看做The AS per rack 的縮影。
The Downward Default model
最後一種模式會顯得有些不同。在上面介紹的架構中，路由器需要收集機構中所有的路由表，並使他們的AS路徑保持原樣。這種模式在路由階段將AS號移除。
This is to prevent routes from other nodes in the network from not being installed due to it coming from the local AS (since they share the source and dest of the route share the same AS).
不會翻 ╮(╯▽╰)╭
In this diagram, we are showing that all Calico nodes share the same AS number, as do all ToR switches. However, those ASs are different (A1 is not the same network as A2, even though the both share the same AS number A ).
所有TOR使用一個AS，結算節點使用另一個AS的做法簡化了部署（使用標準配置即可），帶來的好處就是簡化了TOR中的路由表。
這種模式下，每個 Router 都向上級節點彙報自己的路由信息（vRouter –> TOR –> spine switch）。however, 作爲迴應，上級節點僅僅返回一條默認路由。在這種情況下，vRouter 只有本機Endpoint的路由以及到TOR的默認路由。同樣，對於TOR來說只有到直連vRouter和spine switch的路由。即使我們一個機架下有80臺計算節點，每個計算節點上有200個Endpoint, 那在TOR上也就16000條記錄左右。（大多數交換機都能達到這個數目）
由於路由下發默認是由 spine 發起的，所以下游的AS接受者無法下發路由，這就避免了AS的干擾問題。
原文：
Since the default is originatedby the Spine (originally) there is no chance for a downward announced route to originate from the recipient’s AS, preventing the AS puddling problem.
這種模式下，有個主要的缺點：非法目的地址（eg. 目的地址不存在）的流量都會被送往spine switch。
值得注意的是，spine switch會收集 calico 網絡中所有的路由條目。這種模式並不會使spine switch 中的路由條目比原來更多，但卻着實減少了TOR上的路由信息。同時也減少了vRouter上的路由信息。但這並不是關注的重點，因爲Calico中的完整路由表所消耗的內存量是現代計算服務器上可用總內存的一部分。
Recommendation
如果TOR和SPINE可以容納所產生的路由條目，Calico 團隊建議使用 AS per rack 模式。記得考慮後期擴容問題。
如果擔心TOR交換機路由表大小，Calico 團隊建議使用 Downward default 模式。
如果對TOR路由表大小不放心，以及希望運行非常簡單的2層架構來連接Calico節點，則考慮上文介紹的Ethernet fabric(2層平面模式)。
如果Calico用戶對每個計算節點一個AS的模式感興趣，則Project Calico團隊將非常有興趣討論該模型的部署。