阿裡雲的網絡和彈性計算類産品很多，使用場景也多種多樣，本文是一些使用場景的集錦。主要思路是從使用特定場景中發生的典型問題出發，總結網絡産品使用中的關鍵點。
場景1:
使用VPN打通多個資料中心架構
使用者自己的資料中心通過專線和阿裡雲相連，同時使用者使用了其他公有雲的資源，利用
阿裡雲VPN網關 和其他公有雲廠商打通IPsec VPN。架構和網段如下：
，基本架構是可行的。這個場景和文檔中的場景很類似，是阿裡雲VPN網關支援的場景之一。
但問題來了，使用者在IDC機器上ping其他雲上的資源10.200.1.15時，出現了如下報錯資訊，表示封包超過了TTL：
From 10.100.1.18 icmp_seq=1 Time to live exceeded
繼續用 traceroute探測到目的位址的路徑，可以看到在中間某節點出現了環路：
# traceroute 10.200.1.15
traceroute to 10.200.1.15 (10.200.1.15), 30 hops max, 60 byte packets
1 10.200.1.254 (10.102.81.254) 0.924 ms 1.249 ms 2.431 ms
2 172.17.0.3 (172.17.0.3) 0.544 ms 0.522 ms 0.673 ms
// 省略
7 10.100.1.18 (10.100.1.18) 2.641 ms 2.268 ms 2.156 ms
8 10.100.1.18 (10.100.1.18) 2.136 ms
9 10.100.1.18 (10.100.1.18) 2.328 ms
10 *
11 *
// 省略
29 10.100.1.18 (10.100.1.18) 2.828 ms
30 10.100.1.18 (10.100.1.18) 3.241 ms 3.168 ms 3.552 ms
從traceroute資訊和網段資訊可以判斷10.100.1.18已經是阿裡上的節點，但是使用者表示這個出現環路的IP位址10.100.1.18是一個“未知”位址，是不是阿裡雲網絡出了問題？
分析首先IP位址10.100.1.18确實是阿裡雲中的位址，并且是VPN網關的私網位址，這個資訊确實需要阿裡雲同學協助确認。在明确了這點後，再來看看上面的環路意味着什麼。
在使用了阿裡雲VPN網關的情況下，要把去往
其他雲廠商目的CIDR10.200.0.0/20的流量從VPN網關送出去，在VPC中需要添加如下路由條目：
正常的VPN網關應該怎麼工作呢？收到去往CIDR 10.200.0.0/20的封包後，将封包封裝後送進IPsec VPN隧道，通過公網送往對端。看看為什麼可能出現環路。檢視了VPC路由表配置是正常的，有一種可能性是去往CIDR 10.200.0.0/20的封包送到VPN網關後，VPN網關又來查VPC路由，看到封包下一跳是VPN自己，結果又把封包扔給自己，直到封包的TTL減少到0為止。
那VPN網關為什麼沒有将封包從公網送到對端呢？有一種可能性是去往CIDR 10.200.0.0/20的封包根本就沒有做IPsec封裝，進而接下封包還是走VPC路由，而沒走公網路由送出去。
根因沿着這個思路，再來看現象。發現有環路的IDC用戶端位址是10.64.3.22，而有另外一些用戶端可以正常ping通，位址基本上在10.16.x.y/16網段。是以這個問題變成了“ping相同目标位址，源IP位址不通，效果不通”，該問題并非路由問題了。
我們有理由懷疑是VPN網關沒有配置對相映的内網網段做封裝。查下VPN網關IPsec連接配接的本端網段和對端網段的配置(感興趣流)，如下：
// 10.16.0.0/16表示線下IDC的網段，10.200.0.0/20表示其他公有雲中的私有網段
10.16.0.0/16 === 10.200.0.0/20
可以看到本端網段設定為10.16.0.0/16，這個網段并不包括10.64.3.22，是以封包确實不會被封裝進IPsec隧道，而一直在VPC路由的影響下形成環路。在本端網段中加入10.64.3.22所在的CIDR即解決問題。當然也可以簡單地配置成0.0.0.0/0。
總結用VPN/專線打通多個資料中心或者VPC是一個常用的混合雲場景。但是因為VPN網關未能正确地配置相關感興趣流網段，導緻封包環路在一個對使用者不可知的未知節點，帶來了一定的排查成本。通過這個案例可以進一步了解VPN網關的在混合雲中的使用場景，如何對封包進行封裝，以及封裝異常的後果。
場景2: ECS 作業系統内路由表對網絡聯通性的影響以雲企業網為例子，使用者利用雲企業網打通了3個不同區域的VPC，預設3個VPC之間full mesh聯通。
3個區域各自分别有1台測試ECS機器：
- Region1 VPC, ECS1 IP 位址：172.17.0.64
- Region2 VPC, ECS2 IP 位址：172.18.1.22
- Region3 VPC, ECS3 IP 位址：172.31.4.18
安全組配置類似，都放行對方。ECS内也沒有iptables規則
問題現象：ECS1 172.17.0.64 ping不通ECS3 172.31.4.18，但是ECS2 172.18.1.22可以ping通ECS3 172.31.4.18。
這個問題本身并不複雜，但是如果把排查聚焦在雲産品本身的屬性和配置上，最終會徒勞無功。除了雲産品保證跨地域的VPC順利打通外，ECS作業系統主機網絡相關的因素也直接影響聯通性。最典型的就是作業系統内的iptables規則，其次作業系統内的路由表配置，ECS多網卡的政策路由等因素都會影響到網絡連通性。
在這個案例裡，如果對docker有所了解，那麼172.17.0.64所屬的網段172.17.0.0/16是帶有典型特征的，這個是網橋docker0的預設網段。檢視下ECS3 172.31.4.18作業系統的路由表，如下：
# ip route show
default via 172.31.0.253 dev eth0
169.254.0.0/16 dev eth0 scope link metric 1002
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.31.0.0/24 dev eth0 proto kernel scope link src 172.31.4.18
ECS3中去往目的網段172.17.0.0/16的封包會走docker0網卡。ECS1發往ECS3上的ICMP echo request被ECS3的eth0網卡接受到，但是回包走了docker0網卡，是以ECS1無法收到ICMP echo reply的回包，導緻ECS1無法ping通ECS3。
如果不太熟悉docker，對該問題用正常的檢查和抓包也能發現問題點。關鍵點是需要進行端到端的排查，即以作業系統開始為起始點開始分析。
這個問題是ECS作業系統内路由表對網絡連通性影響的一個簡單示例。在ECS上跑很多複雜業務的情況下，業務軟體(如docker, tunnel等)對主機路由表的影響應該也應該被更多地考慮進去。
雲伺服器ECS位址：阿裡雲·雲小站 From 10.100.1.18 icmp_seq=1 Time to live exceeded
# traceroute 10.200.1.15
traceroute to 10.200.1.15 (10.200.1.15), 30 hops max, 60 byte packets
1 10.200.1.254 (10.102.81.254) 0.924 ms 1.249 ms 2.431 ms
2 172.17.0.3 (172.17.0.3) 0.544 ms 0.522 ms 0.673 ms
// 省略
7 10.100.1.18 (10.100.1.18) 2.641 ms 2.268 ms 2.156 ms
8 10.100.1.18 (10.100.1.18) 2.136 ms
9 10.100.1.18 (10.100.1.18) 2.328 ms
10 *
11 *
// 省略
29 10.100.1.18 (10.100.1.18) 2.828 ms
30 10.100.1.18 (10.100.1.18) 3.241 ms 3.168 ms 3.552 ms
// 10.16.0.0/16表示線下IDC的網段，10.200.0.0/20表示其他公有雲中的私有網段
10.16.0.0/16 === 10.200.0.0/20
# ip route show
default via 172.31.0.253 dev eth0
169.254.0.0/16 dev eth0 scope link metric 1002
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.31.0.0/24 dev eth0 proto kernel scope link src 172.31.4.18