阮志丹,劉 光,何躍平
(中國(guó)電信股份有限公司廣東分公司 廣州 510081)
為了量化地衡量用戶對(duì)Wi-Fi網(wǎng)絡(luò)質(zhì)量的真實(shí)感受,中國(guó)電信股份有限公司廣東分公司(以下簡(jiǎn)稱廣東電信)通過在Wi-Fi熱點(diǎn)現(xiàn)場(chǎng)測(cè)試模擬用戶行為,結(jié)合專業(yè)測(cè)試分析工具,獲取Wi-Fi網(wǎng)絡(luò)性能的量化數(shù)據(jù),以發(fā)現(xiàn)Wi-Fi網(wǎng)絡(luò)存在的問題。Wi-Fi測(cè)試有多項(xiàng)指標(biāo),其中DHCP(dynamic host configuration protocol,動(dòng)態(tài)主機(jī)配置協(xié)議)成功率是反映用戶動(dòng)態(tài)獲取IP地址成功率的一項(xiàng)關(guān)鍵參數(shù),如果無法快速獲取IP地址,則后面的Portal頁(yè)面彈出、認(rèn)證、上網(wǎng)都無法快速實(shí)現(xiàn),用戶使用起來就會(huì)覺得慢,對(duì)用戶感知造成較大的影響。
本文主要對(duì)Wi-Fi網(wǎng)絡(luò)DHCP獲取IP地址慢的原因進(jìn)行深入分析,結(jié)合廣東電信Wi-Fi優(yōu)化的實(shí)際案例,闡述提高Wi-Fi DHCP成功率的思路和方法。
DHCP可以自動(dòng)地為主機(jī)設(shè)定IP環(huán)境參數(shù)。由于其使用的方便性,在Wi-Fi接入上網(wǎng)方式中得到普遍的應(yīng)用。圖1描繪了DHCP客戶機(jī)與DHCP服務(wù)器之間通信、獲取IP地址的過程,具體介紹如下。
(1)尋找DHCP服務(wù)器。客戶機(jī)在本網(wǎng)段內(nèi)廣播DHCP discover報(bào)文以發(fā)現(xiàn)網(wǎng)絡(luò)中的DHCP服務(wù)器,如果客戶機(jī)不是第一次登錄網(wǎng)絡(luò),它會(huì)把上次使用過的IP地址封裝在option50中,以請(qǐng)求再次分配該IP地址。
(2)服務(wù)器提供IP租用地址。當(dāng)DHCP服務(wù)器監(jiān)聽到主機(jī)發(fā)出的DHCP discover報(bào)文廣播后,它會(huì)從那些還沒有租出的地址范圍內(nèi),選擇最前面的空閑IP地址,連同其他IP設(shè)置信息(如網(wǎng)關(guān)、掩碼、DNS等),響應(yīng)給客戶端一個(gè)DHCP offer報(bào)文。
(3)主機(jī)A接受IP租約。如果主機(jī)A收到網(wǎng)絡(luò)上多臺(tái)DHCP服務(wù)器的響應(yīng),只會(huì)挑選其中一個(gè)DHCP offer(通常是最先抵達(dá)的那個(gè)),并會(huì)向網(wǎng)絡(luò)發(fā)送一個(gè)DHCP request廣播分組。
(4)租約確認(rèn)。當(dāng)DHCP服務(wù)器接收到主機(jī)A的DHCP request之后,會(huì)向客戶端發(fā)出一個(gè)DHCP ack響應(yīng)。
DHCP成功率指標(biāo)計(jì)算方法:DHCP成功率=(成功獲取IP地址次數(shù)÷測(cè)試總次數(shù))×100%。
其中,判斷DHCP是否成功需要同時(shí)滿足兩個(gè)條件:獲取到IP地址以及不超過時(shí)間閾值。從終端發(fā)送DHCP discover請(qǐng)求開始計(jì)時(shí)(同一transaction ID的多個(gè)discover請(qǐng)求以第一個(gè)為準(zhǔn)),最后以從服務(wù)器端接收到與discover相同transaction ID的DHCP ack結(jié)束計(jì)時(shí)。如果總時(shí)長(zhǎng)小于10 s,判定為DHCP成功1次;如果總時(shí)長(zhǎng)大于10 s,則判斷為失敗。
圖1 DHCP交互流程
從廣東電信實(shí)際在Wi-Fi熱點(diǎn)現(xiàn)場(chǎng)測(cè)試的統(tǒng)計(jì)情況分析,DHCP成功率指標(biāo)失敗的最主要原因是成功獲取地址的時(shí)延超過考核閾值(10 s),并不是真正地?zé)o法獲取IP地址,但這樣給用戶造成的感覺就是使用Wi-Fi上網(wǎng)很慢。下面將從4個(gè)方面對(duì)DHCP獲取IP地址慢的原因進(jìn)行深入分析。
通過測(cè)試發(fā)現(xiàn)接入愛立信SE800 BRAS(寬帶遠(yuǎn)程接入服務(wù)器)設(shè)備的Wi-Fi熱點(diǎn)時(shí),DHCP獲取IP地址時(shí)延過大,獲得IP地址的時(shí)間一般在15 s左右,高于考核10 s的要求。
正常情況下Wi-Fi用戶獲取IP地址的DHCP報(bào)文交互流程一般為:discover-offer-request-ack,通過協(xié)議的4次交互就可以獲取IP地址,時(shí)延基本都在5 s以內(nèi)。而SE800下接入的Wi-Fi用戶獲取IP地址的DHCP報(bào)文流程 為:discover-offer-discover-offer-discover-offer-request-ack,也就是說客戶端要發(fā)3次discover報(bào)文,在第3次收到offer后才發(fā)起request交互,這樣獲得IP地址的時(shí)間就會(huì)大大延長(zhǎng)。實(shí)測(cè)中DHCP交互過程分組抓取情況如圖2所示。
通過分析發(fā)現(xiàn),該問題和SE800的IP地址分配機(jī)制有很大關(guān)系。SE800的內(nèi)置DHCP服務(wù)器在進(jìn)行地址分配時(shí)采用輪詢算法,即從地址池第一個(gè)地址開始依次分配,每次分配的地址為上一次分配地址的下一個(gè)可用地址,如此循環(huán)往復(fù)。而Windows操作系統(tǒng)的客戶端在IP地址的租用已經(jīng)過期或者之前分配的IP地址不再可用時(shí),會(huì)始終發(fā)送3個(gè)DHCP discover報(bào)文(而且會(huì)把上次使用過的IP地址封裝在option50中),以驗(yàn)證客戶端舊的IP地址不再可用,最后,客戶端計(jì)算機(jī)會(huì)接受第3個(gè)的DHCP offer報(bào)文中提供的IP地址。按照SE800的IP地址分配機(jī)制,由于IP地址繼續(xù)往下輪詢,客戶端基本上都無法獲取上次使用過的IP地址,因此需要發(fā)送3個(gè)DHCP discover報(bào)文才能獲取IP地址。
在測(cè)試過程中發(fā)現(xiàn):接入華為ME60 BRAS設(shè)備的Wi-Fi熱點(diǎn)用戶終端也普遍存在發(fā)送2次DHCP discover才能獲取IP地址的情況,這種情況下獲取IP地址的時(shí)間一般不會(huì)超出10 s,但也會(huì)使獲取IP地址的時(shí)間增加3~4 s。
通過在測(cè)試終端和BRAS上同時(shí)進(jìn)行分組抓取,發(fā)現(xiàn)BRAS側(cè)沒有收到前一次用戶下線時(shí)的DHCP release報(bào)文,即用戶側(cè)發(fā)起了release報(bào)文,但是BRAS上對(duì)用戶進(jìn)行分組抓取時(shí)并沒有收到用戶的release報(bào)文,所以BRAS不會(huì)主動(dòng)把用戶下線。用戶第一次發(fā)起discover的時(shí)候BRAS認(rèn)為用戶是在線的,這時(shí)BRAS會(huì)發(fā)起一個(gè)cut操作使用戶下線,第二次用戶發(fā)起discover的時(shí)候用戶不在線,BRAS才會(huì)按正常處理流程處理,返回一個(gè)offer報(bào)文。此時(shí),問題就在于為什么ME60沒有收到前一次的DHCP release報(bào)文?
進(jìn)一步對(duì)用戶及BRAS之間的交換機(jī)進(jìn)行分組抓取分析,發(fā)現(xiàn)交換機(jī)確實(shí)已經(jīng)將DHCP release報(bào)文發(fā)給了ME60,而ME60卻沒有收到。最后華為公司確認(rèn)原因在于ME60的Wi-Fi認(rèn)證前域配置了嚴(yán)格的地址限制,其中不包含設(shè)備本身的地址,而DHCP release中訪問的目標(biāo)IP地址正好是設(shè)備本身地址,因此被設(shè)備Wi-Fi認(rèn)證前域的ACL過濾掉。
在各地市的巡檢測(cè)試過程中,發(fā)現(xiàn)部分接入華為ME60 BRAS設(shè)備的Wi-Fi熱點(diǎn)有時(shí)也會(huì)出現(xiàn)類似第3.1節(jié)所述的接入SE800設(shè)備的情況,即DHCP獲取IP地址需要發(fā)送3次discover才能獲取IP地址。但是不同之處在于,不是所有華為ME60設(shè)備都會(huì)出現(xiàn)這種情況,而且即使出現(xiàn)這種情況的ME60設(shè)備大部分的測(cè)試情況都正常,只是有時(shí)會(huì)出現(xiàn)3次discover的情況。
圖2 接入SE800用戶DHCP交互分組抓取圖解
通過仔細(xì)地對(duì)比分析成功、失敗情況下的DHCP分組抓取數(shù)據(jù),發(fā)現(xiàn)在出現(xiàn)3次discover的情況時(shí),用戶前兩次發(fā)送DHCP discover報(bào)文時(shí),試圖請(qǐng)求再次分配上次使用過的IP地址,而ME60 BRAS設(shè)備返回的DHCP offer的地址都不是用戶所請(qǐng)求的IP地址,因此客戶端直到發(fā)送3個(gè)DHCP discover報(bào)文驗(yàn)證舊IP地址不再可用時(shí),才接受第3個(gè)DHCP offer報(bào)文中提供的IP地址。
華為公司確認(rèn)ME60的地址池分配機(jī)制是這樣的:一個(gè)地址池的IP地址被釋放后會(huì)放在本地址池的最后,如果該地址未被分配,那么ME60設(shè)備優(yōu)先為上次使用過該IP地址的用戶分配此地址;如果ME60設(shè)備上配置了多個(gè)地址池,分配方式按照配置順序依次進(jìn)行分配,前面一個(gè)地址池分配完后才開始分下一個(gè)地址池里的地址。那么在什么情況下會(huì)出現(xiàn)異常呢?試想如果在地址池比較小、用戶又比較多的情況下,一個(gè)IP地址被釋放后將被加在本地址池的最后,由于地址池使用率已經(jīng)很高,空余地址不多,很快此地址就會(huì)被其他的用戶占用,因此上次使用過該IP地址的用戶想再分配此地址的請(qǐng)求就無法得到滿足了,導(dǎo)致需要發(fā)3次discover。結(jié)合實(shí)際測(cè)試的情況來看,出現(xiàn)3次discover情況的ME60基本上是接入AC的BRAS,Wi-Fi接入用戶量大、地址池個(gè)數(shù)較多但每個(gè)地址池的地址數(shù)量較少。在設(shè)備上查看,這類ME60的前幾個(gè)地址池的利用率確實(shí)很高、空余地址不多,但是后面的地址池卻空閑著無法得到使用。
隨著Wi-Fi網(wǎng)絡(luò)建設(shè)規(guī)模的擴(kuò)大,傳統(tǒng)的胖AP組網(wǎng)方式不適應(yīng)網(wǎng)絡(luò)飛速發(fā)展的要求,目前廣東省已經(jīng)大規(guī)模引入集中控制型AC+瘦AP網(wǎng)絡(luò)架構(gòu)(如圖3所示)——采用較大容量AC設(shè)備集中部署在城域網(wǎng),統(tǒng)一接入各個(gè)熱點(diǎn)的瘦AP,增強(qiáng)了網(wǎng)絡(luò)的安全性、可擴(kuò)展性、可管理性。
集中控制型AC對(duì)組網(wǎng)提出了更高的要求,組網(wǎng)存在的問題影響面可能會(huì)比傳統(tǒng)胖AP的模式大很多。在省分公司調(diào)研時(shí)發(fā)現(xiàn),有些省分公司為了避免AC上聯(lián)電路的冗余,將AC雙掛2臺(tái)BRAS,這樣的網(wǎng)絡(luò)結(jié)構(gòu)看起來很合理,但在實(shí)際測(cè)試發(fā)現(xiàn)也存在問題。由于業(yè)務(wù)VLAN都透?jìng)鞯絻膳_(tái)BRAS上,終端發(fā)過來的DHCP discover報(bào)文會(huì)同時(shí)透?jìng)鞯絻膳_(tái)BRAS,因此兩臺(tái)BRAS均會(huì)對(duì)discover報(bào)文進(jìn)行響應(yīng),終端將會(huì)選擇最先收到的offer報(bào)文。這樣,如果用戶先接入BRAS1,獲取的是BRAS1上的地址,在DHCP租約期到期需要續(xù)租的時(shí)候,用戶會(huì)發(fā)出DHCP request報(bào)文,如果此時(shí)是BRAS2先響應(yīng)DHCP offer報(bào)文,將影響到用戶的續(xù)租。也就是說用戶可能會(huì)在租約期到期時(shí)中斷,需要重新獲取IP地址,這將影響到用戶DHCP成功率及Wi-Fi上網(wǎng)體驗(yàn)。
針對(duì)上述影響DHCP指標(biāo)的若干因素,制定了相對(duì)應(yīng)的提升優(yōu)化方案,并且在現(xiàn)網(wǎng)網(wǎng)絡(luò)中實(shí)施。
圖3 AC、瘦AP典型組網(wǎng)
針對(duì)SE800的IP地址分配機(jī)制問題,協(xié)調(diào)愛立信改進(jìn)了SE800內(nèi)置DHCP服務(wù)器的輪詢算法,即如果客戶機(jī)不是第一次登錄網(wǎng)絡(luò),并且再次請(qǐng)求分配上次使用過的IP地址,則SE800會(huì)查詢地址池中的空余地址,如果該地址未被分配,那么DHCP服務(wù)器優(yōu)先為客戶端分配此地址。愛立信在SE800設(shè)備的6.2.1.7p2以上軟件版本均已修正了該漏洞(bug),經(jīng)過現(xiàn)網(wǎng)實(shí)際測(cè)試,基本消除了客戶端需要發(fā)送3次discover才能獲取到IP地址的問題。
對(duì)于ME60認(rèn)證前域嚴(yán)格地址限制導(dǎo)致無法收到release報(bào)文的問題,解決方案是在認(rèn)證前域的ACL中增加一條:
rule XXX permit ip source user-group wlan destination ip-address X.X.X.X 0//其中X.X.X.X代表了BRAS設(shè)備Wi-Fi IP地址池的網(wǎng)關(guān)地址
另外,為了增強(qiáng)設(shè)備的安全性,也可修改為只允許對(duì)網(wǎng)關(guān)的DHCP端口進(jìn)行訪問,具體配置如下:
rule XXX permit ip source user-group wlan destination ip-address X.X.X.X 0 destination-port eq bootps
ME60設(shè)備IP地址池過小會(huì)造成在用戶量多時(shí)客戶端有時(shí)無法獲取原來的IP地址,導(dǎo)致需要發(fā)3次discover。如前所述,該問題和ME60的IP地址分配機(jī)制有關(guān),但是廠商認(rèn)為目前沒有一種好的IP地址分配機(jī)制可以解決這個(gè)問題。筆者提出一個(gè)變通的方案是可以歸并若干小的地址池合成一個(gè)大的地址池;如果小的地址池不連續(xù)、無法合并的話,可以新建一個(gè)大的地址池取代原來若干小的地址池。
使用一個(gè)大的地址池后,就不會(huì)產(chǎn)生多個(gè)地址池的情況下,前面的地址池利用率過高、后面的地址池卻空閑著無法使用的問題。如此,一個(gè)IP地址被釋放后會(huì)放在本地址池的最后,只要地址池空閑,地址非常充足,該地址短期內(nèi)就不會(huì)分配給其他用戶使用,那么曾經(jīng)用過該IP地址的用戶再請(qǐng)求分配此地址就能很快得到響應(yīng),用戶的使用體驗(yàn)就會(huì)提高很多。
針對(duì)AC雙上聯(lián)兩臺(tái)BRAS的組網(wǎng)問題,可行的優(yōu)化方法是:將兩臺(tái)上行BRAS其中一臺(tái)作為主用BRAS,另一臺(tái)作為備用BRAS,將備用BRAS下聯(lián)AC的端口關(guān)閉,用作冷備份,這樣只有一臺(tái)BRAS會(huì)對(duì)discover報(bào)文進(jìn)行響應(yīng),就不會(huì)影響到用戶的續(xù)租。在主用BRAS發(fā)生故障或主用鏈路發(fā)生故障時(shí),登錄備用BRAS,把備用BRAS下聯(lián)AC的端口打開,也能迅速將業(yè)務(wù)切換到備用BRAS。
通過對(duì)Wi-Fi網(wǎng)絡(luò)以上幾個(gè)方面的優(yōu)化,2012年上半年廣東電信組織的第三方Wi-Fi測(cè)試中,DHCP測(cè)試成功率達(dá)到了98.6%,遠(yuǎn)遠(yuǎn)超出了2011年測(cè)試值86.7%,Wi-Fi的網(wǎng)絡(luò)質(zhì)量和用戶體驗(yàn)得到大幅提升。
本文主要對(duì)影響Wi-Fi DHCP成功率、造成DHCP獲取IP地址慢的原因進(jìn)行深入分析,并結(jié)合廣東電信Wi-Fi網(wǎng)絡(luò)優(yōu)化的實(shí)際案例,有針對(duì)性地提出了提高Wi-Fi DHCP成功率的思路和方法。這些方法在廣東電信Wi-Fi網(wǎng)絡(luò)優(yōu)化中得到了全網(wǎng)推廣應(yīng)用,實(shí)踐表明,通過本文提出的優(yōu)化方法,可以非常有效地提高Wi-Fi DHCP成功率,用戶的使用感知也得到明顯的提升。在國(guó)內(nèi)掀起的Wi-Fi建設(shè)熱潮的形勢(shì)下,這些優(yōu)化方法對(duì)于運(yùn)營(yíng)商的Wi-Fi網(wǎng)絡(luò)優(yōu)化具有普遍的借鑒意義,必將得到廣泛的應(yīng)用。
1 Droms R.Dynamic Host Configuration Protocol.RFC 2131,March 1997
2 Alexander S,Droms R.DHCP Options and BOOTP Vendor Extensions.RFC 2132,March 1997