calico共有兩個容器網路方案：calico bgp和calico ipip。
calico bgp資料面如下：
容器a訪問容器b，資料面流程如下：
容器a內的calic0裝置的掩碼長度為32，即與容器b屬於不同網路，需要通過閘道器進行通訊
容器a查詢路由表，存在default路由，下一跳為169.254.1.1，且169.254.1.1可通過cali0直達
容器a傳送arp請求給169.254.1.1，arp請求報文到達veth裝置的另一端calif***接收
由於calif***裝置使能了arp proxy，linux核心會以calif***的mac位址來響應arp請求，並從calif***發出；
容器a收到arp響應後，得到169.254.1.1的mac位址，封裝二層報文，傳送報文給169.254.1.1，報文從cali0裝置發出
報文通過veth裝置進入host核心協議棧；
由於目的ip不在本節點，host核心會進行報文**（ip_forward已開啟）
host核心超找路由表，發現路由條目，通過califyyyyyy裝置可以直達
host核心傳送arp請求給容器b，通過califyyyyyy裝置發出
arp請求報文通過veth裝置到達容器b，容器b響應arp請求，arp響應通過veth裝置到達host核心
host核心更新報文的二層頭，從califyyyyyy裝置發出
報文通過veth裝置到達容器b
host的本地路由在建立容器的時候就能夠建立，不依賴bgp容器a訪問容器d，資料面流程如下：
容器a內的calic0裝置的掩碼長度為32，即與容器b屬於不同網路，需要通過閘道器進行通訊
容器a查詢路由表，存在default路由，下一跳為169.254.1.1，且169.254.1.1可通過cali0直達
容器a傳送arp請求給169.254.1.1，arp請求報文到達veth裝置的另一端calif***接收
由於calif***裝置使能了arp proxy，linux核心會以calif***的mac位址來響應arp請求，並從calif***發出；
容器a收到arp響應後，得到169.254.1.1的mac位址，封裝二層報文，傳送報文給169.254.1.1，報文從cali0裝置發出
報文通過veth裝置進入host1核心協議棧；
由於目的ip不在本節點，host1核心會進行報文**（ip_forward已開啟）
host1核心查詢路由表，發現路由條目，通過下一跳192.168.0.102（host2）可以到達，而192.168.0.102可以直達
host1核心傳送arp請求給host2，通過eth0裝置發出
arp請求報文通過底層網路到達host2，host2響應arp請求，通過底層網路到達host1
host1核心修改報文二層頭，傳送報文給host2
host2收包報文，由於目的ip不在本節點，host2核心會進行報文**（ip_forward已開啟）
host2查詢路由表，發現路由條目，通過califyyyyy裝置可以直達
host2核心傳送arp請求給容器d，通過califyyyyy裝置發出
arp請求報文通過veth裝置到達容器d，容器b響應arp請求，arp響應通過veth裝置到達host2核心
host2核心更新報文的二層頭，從califyyyyy裝置發出
報文通過veth裝置到達容器d
host1中關於容器d的路由資訊是如何獲取的？ 這就是calico bgp方案的核心，答案是通過bird在節點間同步得到方案優勢
方案劣勢
改進想法
使用etcd同步路由資訊，去除對bgp的依賴
由於calico bgp方案把容器網路暴露到了底層網路中， 而calico ipip方案把容器網路資訊通過ip隧道遮蔽了，而且通過ipip方案可以提供加密傳輸的功能，防止報文被竊聽
calicao ipip資料面如下：
容器a訪問容器b，資料面流程如下（同calico bgp）：
容器a內的calic0裝置的掩碼長度為32，即與容器b屬於不同網路，需要通過閘道器進行通訊
容器a查詢路由表，存在default路由，下一跳為169.254.1.1，且169.254.1.1可通過cali0直達
容器a傳送arp請求給169.254.1.1，arp請求報文到達veth裝置的另一端calif***接收
由於calif***裝置使能了arp proxy，linux核心會以calif***的mac位址來響應arp請求，並從calif***發出；
容器a收到arp響應後，得到169.254.1.1的mac位址，封裝二層報文，傳送報文給169.254.1.1，報文從cali0裝置發出
報文通過veth裝置進入host核心協議棧；
由於目的ip不在本節點，host核心會進行報文**（ip_forward已開啟）
host核心超找路由表，發現路由條目，通過califyyyyyy裝置可以直達
host核心傳送arp請求給容器b，通過califyyyyyy裝置發出
arp請求報文通過veth裝置到達容器b，容器b響應arp請求，arp響應通過veth裝置到達host核心
host核心更新報文的二層頭，從califyyyyyy裝置發出
報文通過veth裝置到達容器b
host的本地路由在建立容器的時候就能夠建立，不依賴bgp容器a訪問容器d，資料面流程如下：
容器a內的calic0裝置的掩碼長度為32，即與容器b屬於不同網路，需要通過閘道器進行通訊
容器a查詢路由表，存在default路由，下一跳為169.254.1.1，且169.254.1.1可通過cali0直達
容器a傳送arp請求給169.254.1.1，arp請求報文到達veth裝置的另一端calif***接收
由於calif***裝置使能了arp proxy，linux核心會以calif***的mac位址來響應arp請求，並從calif***發出；
容器a收到arp響應後，得到169.254.1.1的mac位址，封裝二層報文，傳送報文給169.254.1.1，報文從cali0裝置發出
報文通過veth裝置進入host1核心協議棧；
由於目的ip不在本節點，host1核心會進行報文**（ip_forward已開啟）
host1核心查詢路由表，發現路由條目，通過下一跳192.168.0.102（host2）可以到達，而192.168.0.102可以直達
host核心傳送arp請求給host2，通過eth0裝置發出
arp請求報文通過底層網路到達host2，host2響應arp請求，通過底層網路到達host1
host1核心傳送報文給tun10裝置（因為ipip是三層裝置，不需要二層頭，所以不會向192.168.0.102傳送arp請求）
ipip裝置封裝外層ip頭（ipip裝置是端到端裝置，建立時指定了對端）
ipip裝置封裝外層mac頭，並從eth0發出報文
host2接收到ipip報文，交給ipip協議進行收包處理
ipip協議處理完成後，最終進行ip_forward處理
host2查詢路由表，發現路由條目，通過califyyyyy裝置可以直達
host2核心傳送arp請求給容器d，通過califyyyyy裝置發出
arp請求報文通過veth裝置到達容器d，容器b響應arp請求，arp響應通過veth裝置到達host2核心
host2核心更新報文的二層頭，從califyyyyy裝置發出
報文通過veth裝置到達容器d
對節點外的裝置，遮蔽了容器網路資訊，對底層網路無依賴
容器網路Calico高階實踐 褚向陽
各位晚上好,我是數人雲的褚向陽,接下來要跟大家分享的主題是 容器網路calico高階實踐 距離上次聊 calico 已經過去快半年的時間了，數人雲也一直在努力將容器網路方案應用到企業客戶的環境中，calico v2.0 也馬上就要發布了，這次跟大家一起感受下新版.需要說明下，本人跟 calico 沒...
容器網路（一）docker容器網路驅動
一 linux網橋和veth pair 1 linux網橋，虛擬的交換機，工作在資料鏈路層，通過學習到mac位址，將資料報 到網橋的不同埠上。2 veth pair，可以理解為一根虛擬的網線，建立veth pair後，會以兩張虛擬網絡卡的形式成對出現，在其中乙個網絡卡發出的資料報，會直接出現在與它對...
容器網路 為docker容器新增網路介面
一 背景 預設情況下容器啟動後只有乙個網路介面，一般外圍為eth0，且其ip位址已經提前分配。有時候我們希望為乙個容器建立多個網路介面，此時可以嘗試如下的方式。二 為容器新增網路介面 1 以預設的網路方式執行乙個容器 docker run name tst add inf it tst img bi...