出于提升帶寬、內(nèi)網(wǎng)應(yīng)用類型調(diào)整等目的,企業(yè)互聯(lián)網(wǎng)出口會涉及更換運營商接入鏈路的情況。隨之而來的既是內(nèi)部網(wǎng)絡(luò)平滑遷移的問題,本文結(jié)合實例闡述某集團(tuán)公司總部信息網(wǎng)絡(luò)改造項目過程中所涉及該類問題的解決思路。
圖1
本例中所描述項目為某電力傳媒集團(tuán)總部信息網(wǎng)絡(luò)改造項目,其中包括信息內(nèi)、外網(wǎng)增加設(shè)備、結(jié)構(gòu)調(diào)整及新建無線網(wǎng)絡(luò)系統(tǒng)。在信息外網(wǎng)改造部分包括了互聯(lián)網(wǎng)出口調(diào)整,即由原來的ISP1專線切換為ISP2專線接入互聯(lián)網(wǎng),其網(wǎng)絡(luò)結(jié)構(gòu)示意圖如圖1所示。
原集團(tuán)信息外網(wǎng)用戶及服務(wù)器接入都由ISP1負(fù)責(zé)進(jìn)行NAT(地址轉(zhuǎn)換),切換至ISP2后需要由用戶自行完成NAT,因此增加了虛框中的Huawei AR2200路由器,用戶接入及服務(wù)器發(fā)布NAT都由該設(shè)備完成。
當(dāng)前新增鏈路部分已調(diào)試完畢,并完成了用戶接入及服務(wù)器發(fā)布測試。但由于現(xiàn)網(wǎng)服務(wù)器需要公網(wǎng)用戶訪問,因此在ISP1中申請了公網(wǎng)DNS域名若干,并由ISP1的DNS服務(wù)器負(fù)責(zé)解析;切換至ISP2后需通過ISP2的DNS服務(wù)器對這些域名進(jìn)行解析,由于域名服務(wù)更迭、全網(wǎng)同步需至少24至48小時,為了保證對外發(fā)布的這些服務(wù)器在線路切換過程中仍能保證公網(wǎng)用戶通過域名訪問,經(jīng)與ISP1方協(xié)商后,10.2.237.0/24網(wǎng)段中的服務(wù)器仍然通過ISP1專線對外發(fā)布,待ISP2完成域名服務(wù)更迭、全網(wǎng)同步后再行斷開專線鏈路,除此之外的其他網(wǎng)段不再提供互聯(lián)網(wǎng)接入服務(wù)。
當(dāng)前現(xiàn)網(wǎng)所有網(wǎng)段的網(wǎng)關(guān)均指向核心交換機,核心交換機再通過靜態(tài)默認(rèn)路由的方式指向ISP互聯(lián)設(shè)備地址。經(jīng)過對現(xiàn)網(wǎng)結(jié)構(gòu)分析,擬采用通過在核心交換機上配置策略路由的方式解決該問題,用戶通過重定向下一跳的方式從ISP2出口接入,服務(wù)器網(wǎng)段通過默認(rèn)路由保持ISP1出口接入。
由于核心交換機H3C 7506E的軟件版本較老,不能直接采用PBR(策略路由)方式實現(xiàn)功能,只能通過QoS(MQC)功能完成流量重定向,因此做了如下配置:
嘗試在用戶接入VLAN、物理接口、及全局下對該QoS策略進(jìn)行逐個下發(fā),同時在各網(wǎng)段主機中通過tracroute跟蹤路由測試,發(fā)現(xiàn)數(shù)據(jù)包仍然從ISP1出口流出,并未切換至ISP2出口,重定向功能并未生效。特別是在全局下發(fā)該策略時還出現(xiàn)了斷網(wǎng)現(xiàn)象。經(jīng)與廠商工程師溝通,該交換機在執(zhí)行QoS策略時ACL里面的deny表示不再匹配也不執(zhí)行相應(yīng)動作,建議刪除ACL 2001中的 deny條目。根據(jù)提示將ACL 2001中的rule 30刪除后,在各接入VLAN上下發(fā)該策略后,tracroute發(fā)現(xiàn)已經(jīng)切換至ISP2出口,功能生效。但是問題隨之而來,網(wǎng)管人員反映無法Ping、telnet到核心交換機本VLAN網(wǎng)關(guān)地址,刪除網(wǎng)管VLAN的QoS策略后,恢復(fù)正常。判斷原因為所有匹配源地址為10.2.236.0網(wǎng)管網(wǎng)段的數(shù)據(jù)均重定向到了ISP2出口路由器的互聯(lián)地址,造成網(wǎng)關(guān)地址不可達(dá)。同時,該問題也會導(dǎo)致其他用戶VLAN的網(wǎng)關(guān)地址無法Ping通,給今后的運維排障也造成了一定影響。
初步的調(diào)整方法是將流分類中的ACL改為擴展ACL,將各網(wǎng)段到網(wǎng)關(guān)的流量排除在外。
流分類從匹配ACL 2001變?yōu)?匹配 ACL 3001 ,其他配置保持不變,重新在相應(yīng)VLAN下應(yīng)用,策略路由功能生效,但各VLAN網(wǎng)關(guān)仍無法Ping通。按照在以往其他品牌產(chǎn)品的配置經(jīng)驗,在實現(xiàn)策略路由的時候,ACL中的deny項目的是該項目不通過策略路由而做普通路由轉(zhuǎn)發(fā)。但經(jīng)與廠家技術(shù)支持溝通,給出的答復(fù)是ACL中deny項不會被匹配,順序匹配下面的項。如果要實現(xiàn)該功能建議新建一個acl,匹配目的地址是各VLAN 網(wǎng)關(guān)地址,再創(chuàng)建一個QoS 類匹配這個ACL;創(chuàng)建一個流行為,里面什么都不寫然后在QoS里面關(guān)聯(lián),關(guān)聯(lián)時放在QoS策略的第一位。這個時候訪問交換機網(wǎng)關(guān)地址的會匹配這QoS策略,但是沒有動作,所以不會被重定向且不會再去匹配下面重定向的策略,根據(jù)提示對策略做了如下調(diào)整:
重新關(guān)聯(lián)QoS策略,新建的條目放在重定向條目的前面。
在相關(guān)VLAN中下發(fā)策略時,會收到如下的因存在空行為造成策略無法下發(fā)的報錯消息
將相關(guān)behavior的動作變?yōu)轱@式的允許后,再次在相關(guān)VLAN下應(yīng)用該策略,沒有報錯信息,經(jīng)測試重定向功能生效,且各網(wǎng)段均能Ping通網(wǎng)關(guān),網(wǎng)管網(wǎng)段也能telnet到網(wǎng)關(guān)地址遠(yuǎn)程管理交換機了。
不同廠商、品牌型號的3層交換設(shè)備在實現(xiàn)同一功能時,存在細(xì)微差異。本例中根據(jù)對核心交換機QoS實現(xiàn)機制的分析、測試并結(jié)合廠家提供的技術(shù)支持,最終實現(xiàn)了分流目的,同時保證了網(wǎng)管人員對設(shè)備的遠(yuǎn)程管理。
相關(guān)鏈接:
MQC(Modular QoS ) : 模塊化QoS命令行接口
配置步驟如下:
1.x類別映射,通過DSCP值,MAC地址,IP地址等對流量進(jìn)行分類;
2.行為動作,主要的行為包括對數(shù)據(jù)包進(jìn)行過濾、整形、排隊、重定向、 鏡像等功能。
3.策略關(guān)聯(lián),將類別、動作關(guān)聯(lián)形成最終的QoS策略
4.將策略的應(yīng)用在相應(yīng)接口、VLAN、全局等。