基於facebook atc搭建企業級弱網絡模擬平台

背景

為了提升產品在復雜網絡環境下的體驗，性能，所以搭建了一套模擬網絡的環境來提高效率，主要通過Ubuntu分享小范圍Ap，使用Facebook的開源項目ATC（argumented traffic control）進行流量控制。介於目前公司沒有一套相關的工具，就衍生了我去搭建一套企業級別的復雜網絡模擬平台的想法。

實際效果

目前為了先讓功能跑起來，UI是基於ATC Demo直接修改，後續大家可以針對這個平台進行訂制化修改。

搭建方式

ATC的搭建，配置，分享Wifi熱點配置方式。（這種目前網上資料很多，可以先搭建這種，成功之後再嘗試搭建企業級的平台）

優點：網上資料充足，搭建要求低

缺點：接入量少，覆蓋范圍只有10米，不穩定。

企業化的配置方式。

優點：接入量大，覆蓋范圍大，穩定。

缺點：網上沒有相關資料，搭建要求高，成本高。

前期准備

AP設備覆蓋

為了降低成本，直接和IT部門同學溝通，使用公司網絡的AP設備

如何實現弱網絡模擬服務，並清楚依賴細節

自己通過tc+iptables實現。 基於facebook atc進行二次開發實現。

網絡拓撲圖設計

在設計之前需要想清楚幾個問題：

新建網絡，還是對現有網絡進行架構變更？ 流量如何遷移到弱網絡服務上？ 預期使用的用戶量，使用場景，給出大概需要的IP數量，IP段

物理連接－搭建方案

弱網絡服務部署在公司現有測試網絡mogu-alpha上，為了降低網絡架構變更成本，采用橋接透傳的模式。

在alpha網關服務器和H3C交換機中間串聯一台弱網絡服務器，弱網絡服務器內外網口橋接，做流量透傳，當流量經過弱網絡服務器設備時候，會進行檢測並對當前IP的流量進行控制，再轉發出去。

弱網絡模擬服務－實現方案

要實現流量模擬，有幾個准備工作：<喎?/kf/ware/vc/" target="_blank" class="keylink">vcD4NCtXmyrXB98G/sdjQ676tuf2/2NbGt/7O8cb3INKqttRJUL340NC/2NbGo6y+zdDo0qq21ElQvfjQ0LTyserH+LfWo6hpcHRhYmxlcyBzZXRtYXJro6kgz7XNs9Do0qrWp7PWwfe/2Lf+zvGjqExpbnV4IHRjw/zB7qOpILj5vt3O78Dtway907XEt73KvaOs0aHTw7K7zay1xGlwdGFibGVzst/C1CDLq834v6ijqL2o0unBvbj2zu/A7b/ao6zI57n71rvT0LWlv9qjrNDo0qrQ6cTi0ru49rP2wLSjqQ0KPGgyIGlkPQ=="配置facebook-atc">配置Facebook ATC

參考官方文章，搭建

https://github.com/facebook/augmented-traffic-control

遇到問題 (沒有遇到這些問題的可以跳過)

弱網絡服務器與alpha網關服務器網線直連不通，弱網絡服務器與S3C交換機直連不通
服務器網線直連不通，是否是網線問題排查。 弱網絡服務器（10.54.0.20）和alpha服務器（10.54.0.1）之間網線直連網絡不通 手機連不上mogu-alpha wifi wifi無法訪問外網（比如www.baidu.com無法訪問） Python升級之後導致yum不可用。 弱網絡模擬服務不生效。 Facebook ATC 內核不支持bridge的方式。

解決問題細節

一. 弱網絡服務器與alpha網關服務器網線直連不通，弱網絡服務器與S3C交換機直連不通

這個問題，是有好幾個問題組合而成，消耗了不少時間。

服務器網線直連不通，是否是網線問題排查。

將alpha網關服務器直連交換機，發現是互通的。 用工作本替換alpha網關服務器，直連弱網絡服務器，發現是互通的。

通過這些驗證，網線沒有問題，定位在alpha網關服務器配置上。

弱網絡服務器（10.54.0.20）和alpha服務器（10.54.0.1）之間網線直連網絡不通

通過查看arp表，發現10.54.0.20沒有學到10.54.0.1的arp表項。出現incomplete arp表項的原因一般有兩種：

arp表項被刪除了 arp學習失敗了

由於10.54.0.20與10.54.0.1之間網絡是不通的，所以推測出現出現10.54.0.1的incomplete arp表項的原因是因為arp失敗了，所以問題定位的重點是為什麼這兩台機器之間網絡不通。

所以查看了，當前的組網方式如下

分析結果：發現因為Vlan不匹配導致不通。

弱網絡服務器：網橋br0橋接eth1、eth0兩個物理口，配置管理ip:10.54.0.20/16

alpha網關服務器：單物理口p4p1，配了幾個Vlan，其中一個p4p1.54配置了10.54.0.1/16。所以可以得出10.54.0.1/16這段的ip都是走Vlan:54 這個虛擬口，該Vlan:54的真實設備是p4p1。又由於10.54.0.1是在p4p1.54上的。而10.54.0.20是在native device上的，那麼10.54.0.20發的arp request for 10.54.0.1都會被Vlan device p4p1.54給丟掉（因為直連的弱網絡服務器沒有與之匹配的Vlan:54 device），所以不會有arp relply。這也是為什麼直連不通的原因。

為了解決這個問題，我們在弱網絡服務器的eth0口上創建一個vlan54 device，然後再把eth0.54加到br0上，組網方式如下圖所示

通過這樣修改之後，10.54.0.20就可以和10.54.0.1相通了。

手機連不上mogu-alpha wifi

在解決了10.54.0.20和10.54.0.1之間直連網絡不通的問題後，又發現使用手機連不上alpha wifi，判定原因出在dhcp的請求失敗導致，alpha wifi的dhcp功能是由alpha機器上的dhcp服務提供的，所以懷疑弱網絡服務器獲得數據包之後，丟棄了。

我們繼續分析了現在的組網圖

在eth1和eth0上抓了下包，發現在eth1上可以抓到發往10.54.0.1的arp request，並且該arp request還攜帶vlan:54。
在eth0上抓不到發往10.54.0.1的arp request，這是因為攜帶vlan:54的arp request在到達eth0.54 device時會被其丟掉。

所以我們發現Vlan的出入口都需要匹配，對組網又進行了一次修改，通過在eth1上創建一個vlan:54 deivce，然後將eth1.54加到br0上，如果下圖所示

分析因為請求dhcp的設備本身處於10.54.0.x/16段，所以這些設備請求的內網服務都是帶vlan:54的標識，所以通過這樣修改之後，手機就可以連上alpha wifi了。

wifi無法訪問外網（比如www.baidu.com無法訪問）

通過在10.54.0.20的eth0上抓包，可以抓到source IP為172.17.0.12的包，是不帶vlan的，那這個包肯定會被eth0.54給丟掉。
於是確認alpha服務器上的路由配置，發現默認網關是172.17.0.1，device是p4p1；同時確認了dns配置/etc/resolv.conf，nameserver是172.17.0.7和172.17.0.8，所以連接baidu時會首先跟nameserver通信，獲取baidu.com的IP，這時發出去的包的source ip是172.17.0.12，走的是p4p1。
這時需要在10.54.0.20上把native通道打通，我們可以給每個vlan都創建一個bridge，用來給alpha服務器的各個Vlan提供相應的轉發通道，組網圖如下

通過這樣的修改，就可以訪問公網IP地址了，但是有個缺點就是，每添加一個Vlan都需要創建一個bridge作為透傳。

二. Centos Python升級之後導致yum不可用。

解決了網絡問題之後，就需要對弱網絡服務的依賴環境進行配置，搭建，由於系統默認Python2.6.6，弱網絡服務器依賴Python2.7，升級之後導致了yum不可用（錯誤：import no module yum），大大影響了一些工具的下載安裝。

網絡上推薦的幾種解決方案：

修改python解釋器地址

vim /usr/bin/yum 修改第一行#!/usr/bin/python 修改成 #!/usr/bin/python2.6.6

這種解決方案適用於：系統centos6.5自帶的python2.6.6沒有被卸載，只是軟引用被修改。

但是當時我把python2.6.6給卸載了，重裝python2.4,2.6都沒有用，所以這個解決方案並不適用所有人。

卸載所有python，完全重新安裝python和yum（這裡一定要小心，千萬別把rpm包給卸載了，否則就得重裝系統）

上述的解決方案不可行，只能卸載重裝，但是需要注意的是，重裝的版本最好要根據當前系統依賴的版本，可以到http://mirror.centos.org/ 找到本機系統版本對應的安裝包，可以寫個shell腳本，批量下載或者手動一個個載也行。

操作步驟：

卸載Python

rpm -qa|grep python|xargs rpm -ev –allmatches –nodeps ##強制刪除

whereis python |xargs rm -frv ##刪除所有殘余文件

卸載yum

rpm -qa|grep yum|xargs rpm -ev –allmatches –nodeps

whereis yum |xargs rm -frv

下載重裝的python ,yum的rpm安裝包（以我的機器centos6.5為例，需要下載centos6.5默認的那些版本號，可以google查下）

到http://mirror.centos.org/centos-6/6/os/x86_64/Packages/ 裡面找到需要下載的安裝包，在安裝過程中，有漏什麼，自己在去上面下載相應的包即可。如果沒有就google找到相應的版本，手動下載。

安裝rpm

rpm -Uvh –replacepkgs .rpm ## 專門起一個文件夾，存放相關的安裝包，可以用這個命令，或者自己寫一個shell腳本，把 .rpm 改成相應的rpm包即可。

最好裝一個安裝python2.7，隔離系統python2.6.6版本

如果要python默認為2.7版本，那麼需要做如下操作：

rm -rf /usr/bin/python
ln -s /usr/local/bin/python2.7 /usr/bin/python

之後將vim /usr/bin/yum 第一行#!/usr/bin/python 修改成 #!/usr/bin/python2.6.6

如果不修改python默認，後續想使用2.7版本可以通過python2.7來使用。

三、 弱網絡模擬服務(tc)不生效。

通過上面的操作，網絡通了，服務也搭建起來了，流控界面對本手機設置限速，沒有效果，比如設置18Kbps，訪問百度依然很流暢。通過監控tc流量分配，發現iptables沒有生效，流量根本沒有走相應的class裡面。而tc的流控都是基於HTB策略，通過class來區分每個ip的。


如果生效的話，流量應該走的qdisc netem 802d: parent 1:2 limit 1000 delay 650.0ms loss 2%裡面。

分析流控原理，主要是通過在traffic control服務器的bridge上的FORWARD chain上設置iptables規則，然後在eth0.54和eth1.54上使用tc的HTB策略進行發包限速。（facebook atc 內核裡面默認配置的），順籐摸瓜，發現了以下幾個問題。

netfilter相關模塊沒有加載，iptables服務未啟動。

service iptables start 沒有反應。（如果有反應的，那就忽略這個問題）

iptables 是一個用戶態工具，其設置的規則最終需要在kernel netfilter的各個hook point上執行。在當前的traffic control服務器上沒有加載netfilter相關模塊，因為上面的iptables service啟動失敗了，導致沒有正常加載相關的netfilter模塊。

我們可以先手動加載這些模塊（不過還是建議重新安裝下iptables service）

ip_tables
iptable_filter
iptable_nat
iptable_mangle
nf_defrag_ipv4
nf_conntrack_ipv4
nf_conntrack
nf_nat

當然也可以自行google解決。

沒有enable netfilter in bridge

traffic control服務器上把netfilter in bridge給disable了，因為其/etc/sysctl.conf配置文件中設置了

net.bridge.bridge-nf-call-iptables=0

需要修改為

net.bridge.bridge-nf-call-iptables=1

然後執行sysctl -p，這種方式可以保證下次啟動服務器還會設置成1；
也可以直接echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables，這種方式對下次重啟無效。

bridge-nf-call-iptables=1是用來使能bridge將ip包傳給各種chains進行包處理的，包括我們當前用到的mangle表的forward chain處理，說白了，bridge-nf-call-iptables=1可以使bridge的netfilter利用IP層的netfilter代碼。

內核中默認是enable的，除非你在用戶態通過設置net.bridge.bridge-nf-call-iptables=0主動disable。

iptables規則設置不對

默認的iptables配置的是路由方式，而我們采用的是橋接方式，所以通過查閱iptables官網發現，橋接方式需要使用另外的配置命令。

目前的iptables設置規則是

iptables -A FORWARD -t mangle -s 10.54.4.155 -i eth1.54 -j MARK —set-mark 0x2/0xffffffff

iptables -A FORWARD -t mangle -d 10.54.4.155 -i eth0.54 -j MARK —set-mark 0x2/0xffffffff

這種規則並不會在bridge的forward chain上生效，針對bridge上的iptables專門新增了一個physdev的模塊，使用戶能夠透過iptables -m physdev -h 在bridge模式下生效，規則需要按如下方式設置。

iptables -A FORWARD -t mangle -s 10.54.4.155 -m physdev --physdev-in eth1.54 --physdev-out eth0.54 -j MARK --set-xmark 0x2/0xffffffff

iptables -A FORWARD -t mangle -d 10.54.4.155 -m physdev --physdev-in eth0.54 --physdev-out eth1.54 -j MARK --set-xmark 0x2/0xffffffff

physdev參數是專門給設置nf_bridge提供的。

所以問題的根本，還是在iptables上，當解決了iptables的問題，那麼流量就恢復了正常，如下圖

四、Facebook ATC 內核不支持bridge的方式。

雖然我們知道了是iptables的使用姿勢問題，但是我們使用facebook的ATC框架，這些代碼都封在內核中，並且atc並不支持bridge的方式，針對這些問題，所以需要對atc的內核源碼進行研究，並進行相應的修改。最終發現了最終設置iptables的地方

原來的iptables的配置


那麼我們需要對原來的iptables策略進行修改，如下


修改完成之後，將服務器代碼更新，服務重啟即可，效果圖如下

後續可能會幫他們新增一個支持bridge方式的功能。

五、弱網絡服務如何後台運行。

借助nohup命令進行，不過如果服務掛了，需要手動重啟。

nohup atcd --atcd-lan eth1.54 --atcd-wan eth0.54 &

nohup python2.7 manage.py runserver 10.54.0.20:8000 &

通過上述步驟，就完成了一個企業級別的弱網絡模擬平台搭建，當然這只是搭建過程，關於弱網絡的展示頁面，功能都需要大家自行開發。

最後，希望能幫到有需要的同學，歡迎討論 。