配置同享DCC
同享DCC中1個物理接口可以屬于多個Dialer bundle(撥號捆綁),服務于多個Dialer接口但1個Dialer接口只對應1個目的地址,只能使用1個Dialer bundle;1個Dialer bundle中可以包括多個物理接口,每一個物理接口具有不同的優先級。
支持同享DCC的物理接口包括:ADSL接口、G.SHDSL接口、VDSL接口、E1-IMA接口、WAN側以太網接口、ISDN PRI接口和ISDN BRI接口。
同享DCC的主要配置任務以下(必須的只有前3項)
--- 配置鏈路層協議和IP地址
--- 使能同享DCC并配置DCC撥號ACL及接口的關聯。
--- 配置同享DCC呼喚
--- (可選)配置DCC撥號接口屬性。
--- (可選)配置DCC呼喚MP捆綁
--- (可選)配置通過DCC實現動態路由備份
1)配置鏈路層協議和IP地址
與輪詢DCC中的鏈路層協議配置相同,只是對同享DCC,如果是主叫端,需要在Dialer接口下配置PPP的相干命令,但建議用戶在物理撥號接口下也配置相同的PPP相干命令,以確保PPP鏈路參數協商的可靠性;如果被叫端,需要在物理撥號接口下配置PPP相干命令。
2)使能同享DCC并配置DCC撥號ACL及與接口的關聯
在同享DCC中,使能同享DCC、配置DCC撥號ACL及與接口的關聯僅能在Dialer接口下配置,不能在物理接口下配置。
3)配置同享DCC呼喚
使用同享DCC實現按需撥號時,由于物理接口隨著撥號串的不同而具有不同屬性,因此必須在Dialer接口上配置DCC參數,并且只能使用dialer number命令呼喚對真個撥號串。1個Dialer接口只能配置1個撥號串。
4)配置DCC撥號接口屬性
步驟與表4⑹相同,只是這里僅可在Dialer接口上配置。
5)配置DCC呼喚MP捆綁
步驟與表4⑺相同。
6)配置通過DCC實現動態路由備份
步驟與表4⑻,只是僅能在Dialer接口上配置。
DCC管理
1)display dialer 【interface interface-type interface-number】:查看撥號接口(可在物理撥號接口中,也可在Dialer接口上)的DCC信息,包括撥號接口的相干參數
2)display interface dialer 【number】:查看Dialer接口的信息,包括Dialer接口的狀態信息和統計信息。
3)reset counters interface 【dialer 【number】】:清除Dialer接口統計信息后,之前的統計信息將沒法恢復。
如果為了減緩網絡壓力或調劑撥號配置需要臨時撤除撥號鏈路時,可通過dialer disconnect 【interface interface-type interface-number】任意視圖命令手動撤除撥號鏈路。但此命令只是臨時撤除撥號鏈路:如配置了自動撥號,當到達自動撥號時間時,會重新建立撥號鏈路;如未配置自動撥號,則當有報文傳輸時,會再次觸發撥號。
PPP配置與管理
PPP是在點對點鏈路上承載網絡層數據報文的1種鏈路層協議,路由器中的serial接口鏈路缺省運行的協議就是PPP。Async接口、CPOS接口、ISDN BRI接口、E1-F接口、CE1/PRI接口、T1-F接口、CT1/PRI接口、3G Cellular接口、Dialer接口、虛擬模板接口、POS接口都可運行PPP。
1、PPP介紹及基本工作機制
PPP是在SLIP(Serial Line Internet Protocol,串行線IP)基礎上發展起來的。PPP能夠提供用戶認證、易于擴充、并且支持同/異步通訊,取得廣泛利用。配置PPP可以實現PPPoE、PPPoA、PPPoEoA撥號上網及廣域網互聯。
相對其他鏈路層協議,PPP有以下優點:
1)對物理層而言,PPP既支持同步鏈路又支持異步鏈路,而X.25、FR等僅支持同步鏈路,SLIP僅支持異步鏈路;
2)PPP具有良好的擴大性。
3)提供LCP(Link Control Protocol,鏈路控制協議),主要用來建立、撤除和監控PPP數據鏈路;
4)提供各種NCP(Network Control Protocol,網絡控制協議),如IPCP、IPXCP,主要用來協商在該數據鏈路上傳輸的數據包的格式和類型,更好的支持了網絡層協議;
5)提供認證協議CHAP(Challenge-Handshake Authentication Protocol,質詢握手認證協議)、PAP(Password Authentication Protocol,密碼認證協議),用于網絡安全方面的認證;
6)無重傳機制,網絡開消小,速度快。
LCP、NCP、CHAP/PAP就是PPP所包括的3大擴大子協議,而PPP的工作機制正是在這3大擴大子協議協同工作基礎上實現的。
全部PPP運行流程分為5個階段,即Dead(死亡)階段、Establish(鏈路建立)階段、Authentication(身份認證)階段、Network(網絡控制協商)階段和Terminate(結束)階段。不同階段進行不同協議的協商,只有前面的協議協商出結果后,才能轉入下1個階段協議的協商。
通訊雙方開始建立PPP鏈路時,先進入到Establish階段。
在Establish階段,PPP鏈路進行LCP協商。協商內容包括工作方式是SP(Single-link PPP)還是MP(Multilink PPP)、最大接收單元MRU(Maximum Receive Unit)、驗證方式和魔術字(magic number)等選項。LCP協商成功落后入Opened狀態,表示底層鏈路已建立。
如果配置了驗證,將進入Authenticate階段,開始CHAP或PAP驗證。如果沒有配置驗證,則直接進入Network階段。
在Authenticate階段,如果驗證失敗,進入Terminate階段,撤除鏈路,LCP狀態轉為Down。如果驗證成功,進入Network階段,此時LCP狀態仍為Opened。
在Network階段,PPP鏈路進行NCP協商。通過NCP協商來選擇和配置1個網絡層協議并進行網絡層參數協商。只有相應的網絡層協議協商成功后,該網絡層協議才可以通過這條PPP鏈路發送報文。
NCP協商包括IPCP(IP Control Protocol)、MPLSCP(MPLS Control Protocol)等協商。IPCP協商內容主要包括雙方的IP地址。
NCP協商成功后,PPP鏈路將1直保持通訊。PPP運行進程中,可以隨時中斷連接,物理鏈路斷開、認證失敗、超時定時器時間到、管理員通過配置關閉連接等動作都可能致使鏈路進入Terminate階段。
在Terminate階段,如果所有的資源都被釋放,通訊雙方將回到Dead階段,直到通訊雙方重新建立PPP連接,開始新的PPP鏈路建立。
PPP協議在協議棧中的位置
PPP主要由3類協議族組成:
鏈路控制協議族(Link Control Protocol),主要用來建立、撤除和監控PPP數據鏈路。(應當主要使用于Establish階段和Terminate階段)
網絡層控制協議族(Network Control Protocol),主要用來協商在該數據鏈路上所傳輸的數據包的格式與類型。(Network階段)
擴大協議族CHAP(Challenge-Handshake Authentication Protocol)和PAP(Password Authentication Protocol),主要用于網絡安全方面的驗證。(Authentication階段)
各字段的含義以下:
Flag域
Flag域標識1個物理幀的起始和結束,該字節為0x7E。
Address域
Address域可以唯1標識對端。PPP協議是被應用在點對點的鏈路上,因此,使用PPP協議互連的兩個通訊裝備不必知道對方的數據鏈路層地址。依照協議的規定將該字節填充為全1的廣播地址,對PPP協議來講,該字段無實際意義。
Control域
該字段默許值為0x03,表明為無序號幀,PPP默許沒有采取序列號和確認應對來實現可靠傳輸。
Address和Control域1起標識此報文為PPP報文,即PPP報文頭為FF03。
Protocol域
Protocol域可用來辨別PPP數據幀中信息域所承載的數據包類型。
Protocol域的內容必須根據ISO 3309的地址擴大機制所給出的規定。該機制規定協議域所填充的內容必須為奇數,也就是要求最低有效字節的最低有效位為“1”。
Information域
Information域最大長度是1500字節,其中包括填充域的內容。Information域的最大長度稱為最大接收單元MRU(Maximum Receive Unit)。MRU的缺省值為1500字節,在實際利用當中可根據實際需要進行MRU的協商。
如果Information域長度不足,可被填充,但不是必須的。如果填充則需通訊雙方的兩端能辨認出填充信息和真正需要傳送的信息,方可正常通訊。
FCS域
FCS域的功能主要對PPP數據幀傳輸的正確性進行檢測。
在數據幀中引入了1些傳輸的保證機制,會引入更多的開消,這樣可能會增加利用層交互的延遲。
如果當發送端發送的PPP數據幀的協議域字段不符合上述規定,接收端則會認為此數據幀是不可辨認的。接收端向發送端發送1個Protocol-Reject報文,在該報文尾部將填充被謝絕報文的協議號。
在鏈路建立階段,PPP協議通過LCP報文進行鏈路的建立和協商。此時LCP報文作為PPP的凈載荷被封裝在PPP數據幀的Information域中,PPP數據幀的協議域的值固定填充0xC021。
在鏈路建立階段的全部進程中信息域的內容是變化的,它包括很多種類型的報文,所以這些報文也要通過相應的字段來辨別。
Code域
Code域的長度為1個字節,主要是用來標識LCP數據報文的類型。
在鏈路建立階段,接收方接收到LCP數據報文。當其Code域的值無效時,就會向對端發送1個LCP的代碼謝絕報文(Code-Reject報文)。
Identifier域
Identifier域為1個字節,用來匹配要求和響應,當Identifier域值為非法時,該報文將被拋棄。
通常1個配置要求報文的ID是從0x01開始逐漸加1的。當對端接收到該配置要求報文后,不管使用何種報文回應對方,但必須要求回應報文中的ID要與接收報文中的ID1致。
Length域
Length域的值就是該LCP報文的總字節數據。它是Code域、Identifier域、Length域和Data域4個域長度的總和。
Length域所唆使字節數以外的字節將被當作填充字節而疏忽掉,而且該域的內容不能超過MRU的值。
Data域
Data域所包括的是協商報文的內容,這個內容包括以下字段。
Type為協商選項類型。
Length為協商選項長度,它是指Data域的總長度,也就是包括Type、Length和Data。
Data為協商選項的詳細信息。
2、配置PPP基本功能
PPP基本功能包括配置接口的鏈路層協議為PPP和配置端口的IP地址。基本功能配置完成后,可以初步建立PPP鏈路。主要包括以下兩項任務:
1)配置接口封裝的鏈路層協議為PPP
2)配置接口的IP地址
1種是在接口上直接配置IP地址,另外一種是通過IP地址協商獲得IP地址。配置PPP協商IP地址又分為兩種情況:
-- 配置裝備作為PPP客戶端:如本端裝備接口封裝的鏈路層協議為PPP,且未配置IP地址,對端已有IP地址時,可把本端裝備配置為客戶端,使本端裝備接口接收PPP協商產生的由對端分配的IP地址。這類方式主要利用于通過ISP訪問Internet
--- 配置裝備作為PPP服務器
裝備作為服務器時可以為對端指定IP地址,但首先要在系統視圖下配置本地IP地址池,指明地址池的地址范圍,
3、配置PPP的PAP認證
PPP基本功能實現后,用戶根據需要配置PAP或CHAP認證。
1)PAP認證:這是1種兩次握手驗證協議。以明文方式在鏈路上發送驗證密碼,完成PPP鏈路建立后,被驗證方會不停地在鏈路上反復發送用戶名和密碼,直到身份驗證進程結束,安全性不高
PAP認證有PAP單向認證與PAP雙向認證:PAP單向認證是指1端作為認證方,另外一端作為被認證方。雙向認證是單向認證的簡單疊加,即兩端都是既作為認證方又作為被認證方。
2)CHAP認證:是1種3次握手驗證協議。只在網絡上傳輸用戶名,而不傳輸用戶密碼,安全性高。
CHAP認證有CHAP單向認證與CHAP雙向認證:
CHAP單向認證是指1端作為認證方,另外一端作為被認證方。雙向認證是單向認證的簡單疊加,即兩端都是既作為認證方又作為被認證方。
CHAP認證進程分為兩種情況:認證方配置了用戶名和認證方沒有配置用戶名。推薦使用認證方配置用戶名的方式,這樣可以對認證方的用戶名進行確認。
PAP認證需要同時在認證方(實行認證的1方)和被認證方進行配置。在認證方本地要創建好用于對被認證方進行認證的用戶賬戶信息(包括用戶名和密碼),而在被認證方要配置進行認證時要發送的用戶賬戶信息,并且要與認證方本地用于認證的用戶賬戶信息完全1致。固然,兩端還要配置采取相同的PPP認證方式。
4、配置PPP的CHAP認證
當認證方配置了用戶名時,可使被認證方驗證認證方的資格,以防連接到非法的服務器端,也就是被認證方也有資格驗證對方是不是有資格對自己進行認證。就相當于1個雙向認證:不但認證方可以對被認證方進行認證,被認證方也可對認證方進行認證,這就是CHAP3次握手進程的基本原理。在認證方沒有配置用戶名時,CHAP認證進程與PAP認證進程1樣。
認證方配置了用戶名后的CHAP認證具體步驟以下表4⑴3。雙方都要配置認證用戶名,創建用于對方認證的本地用戶名賬戶,因此此時被認證方同時需要對認證的資格進行確認。認證方沒有配置用戶名的CHAP認證的具體步驟如表4⑴4,此時被認證方不需要對認證資格進行確認。
表中所列都是針對CHAP單向認證,雙向認證時需要雙方同時配置表中的認證方和被認證方。
5、配置PPP協商參數
在裝備上還可以有選擇的配置1些用于協商的參數具體包括以下可選配置任務
1)協商超時時間間隔
在PPP協商進程中,如果在某個時間間隔內沒有收到對真個應對報文,則PPP會重發1次發送的報文,這個時間間隔稱為“超時時間間隔”。
2)協商輪詢時間間隔
指接口發送keepalive(保持活躍)報文的周期。keepalive報文用于鏈路狀態監測保護,接口如果在5個keepalive周期以后沒法收到keepalive報文,認為鏈路產生故障。
3)協商DNS服務器地址
裝備在進行PPP地址協商進程中可以進行DNS地址協商,此時裝備可以配置成接受對端分配的DNS地址,也可配置為向對端提供DNS地址。當不可以同時都配。
6)PPP管理
RouterA對RouterB進行單向認證,RouterB不需要對RouterA進行認證。采取PPP PAP認證方式最簡單,RouterA作為PAP認證的認證方,RouterB作為PAP認證的被認證方。
認證方RouterA上的配置
①配置接口Serial1/0/0的IP地址及封裝的鏈路層協議為PPP。
②配置PPP認證方式為PAP,認證域名為system
③配置本地用戶賬戶和域。由于要對被認證方進行認證,需要在本地創建用于認證的用戶名和密碼。
④重啟接口,保證配置生效。
被認證方RouterB上的配置
①配置接口serial2/0/0的IP地址及封裝的鏈路層協議為PPP。
這時候PING 10.10.10.9是不通 的。
②配置向認證方RouterA發送PAP認證的PAP用戶名和密碼
③重啟接口,保證配置生效
測試連通性:
8)PAP雙向認證配置實例:
拓撲結構通上圖,不同的地方是既希望RouterA對RouterB進行簡單的PAP認證,也希望RouterB對RouterA進行認證。
RouterA上的配置
①配置接口色rial/0/0的IP地址及封裝的鏈路層協議為PPP。
②配置PPP認證方式為PAP,認證域名為system
③配置本地用戶及域,此處的用戶名要與RouterB發送的PAP認證用戶名和密碼1致
④配置本地向RouterB發送的PAP認證用戶名和密碼,并重啟接口,使配置生效
RouterB上的配置
①配置接口serial2/0/0的IP地址及封裝的鏈路層協議為PPP
②配置PPP認證方式為PAP,認證域為system
③配置本地用戶及域。此處的用戶名要與RouterA發送的PAP認證用戶名和密碼1致(即user2@system,huawei2)
④配置本地向RouterA發送PAP認證用戶名和密碼,并重啟接口,使配置生效。
這里故意將RouterB向RouterA發送認證的密碼寫錯,發現PING不通,修改過來:
用戶必須寫全,上面進行了測試,如果user1@system寫成user1,也不通。
9)CHAP單向認證配置實例:
拓撲圖同上面,不同的地方是希望RouterA對RouterB進行可靠的CHAP認證,而RouterB不需要對RouterA進行認證。僅需配置RouterA作為CHAP認證的認證方,RouterB作為CHAP認證的被認證方。
認證方RouterA上的配置
被認證方RouterB上的配置
RouterB上配置被RouterA以CHAP方式認證時RouterB發送的CHAP用戶時,只配置了用戶名,沒配置密碼,1直PING不同,使用ppp chap password cipher password命令加上密碼后通了。
上一篇 Retrofic 源碼閱讀