- 產品與解決方案
- 行業解決方案
- 服務
- 支持
- 合作夥伴
- 關於我們
01-PPP配置
本章節下載： 01-PPP配置 (709.13 KB)
PPP（Point-to-Point Protocol，點對點協議）是一種點對點的鏈路層協議。它能夠提供用戶認證，易於擴充，並且支持同/異步通信。
PPP定義了一整套協議，包括：
· 鏈路控製協議（Link Control Protocol，LCP）：用來建立、拆除和監控數據鏈路。
· 網絡控製協議（Network Control Protocol，NCP）：用來協商在數據鏈路上所傳輸的網絡層報文的一些屬性和類型。
· 認證協議：用來對用戶進行認證，包括PAP（Password Authentication Protocol，密碼認證協議）、CHAP（Challenge Handshake Authentication Protocol，質詢握手認證協議）、MSCHAP（Microsoft CHAP，微軟CHAP協議）和MSCHAPv2（微軟CHAP協議版本2）。
PPP協議處於TCP/IP的數據鏈路層，主要用在支持全雙工的同異步鏈路上，進行點到點之間的數據傳輸。
圖1-1 PPP在協議棧中的位置
PPP主要由以下幾類協議族組成：
· 鏈路控製協議族，主要用來建立、拆除和監控PPP數據鏈路。
· 網絡層控製協議族，主要用來協商在該數據鏈路上所傳輸的數據包的格式與類型。
· PPP擴展協議族，主要用於提供對PPP功能的進一步支持。例如，PPP提供了用於網絡安全方麵的認證協議族CHAP和PAP。
PPP報文封裝格式如圖1-2所示。
圖1-2 PPP報文格式
· Flag域
Flag域標識一個物理幀的起始和結束，該字節為0x7E。
· Address域
Address域可以唯一標識對端。PPP協議是被運用在點對點的鏈路上，因此，使用PPP協議互連的兩個通信設備無須知道對方的數據鏈路層地址。按照協議的規定將該字節填充為全1的廣播地址，對於PPP協議來說，該字段無實際意義。
· Control域
該字段缺省值為0x03，表明為無序號幀，PPP默認沒有采用序列號和確認機製來實現可靠傳輸。
Address和Control域一起標識此報文為PPP報文，即PPP報文頭為FF03。
· Protocol域
Protocol域可用來區分PPP數據幀中信息域所承載的數據包類型。
Protocol域的內容必須依據ISO 3309的地址擴展機製所給出的規定。該機製規定協議域所填充的內容必須為奇數，也就是要求最低有效字節的最低有效位為“1”，最高有效字節的最低有效位為“0”。
如果當發送端發送的PPP數據幀的協議域字段不符合上述規定，接收端則會認為此數據幀是不可識別的。接收端向發送端發送一個Protocol-Reject報文，在該報文尾部將填充被拒絕報文的協議號。
表1-1 常見協議代碼
|
協議代碼 |
協議類型 |
|
0021 |
Internet Protocol |
|
002b |
Novell IPX |
|
002d |
Van Jacobson Compressed TCP/IP |
|
002f |
Van Jacobson Uncompressed TCP/IP |
|
8021 |
Internet Protocol Control Protocol |
|
802b |
Novell IPX Control Protocol |
|
8031 |
Bridging NC |
|
C021 |
Link Control Protocol |
|
C023 |
Password Authentication Protocol |
|
C223 |
Challenge Handshake Authentication Protocol |
· Information域
Information域最大長度是1500字節，其中包括填充域的內容。Information域的最大長度稱為最大接收單元MRU（Maximum Receive Unit）。MRU的缺省值為1500字節，在實際應用當中可根據實際需要進行MRU的協商。
如果Information域長度不足，可被填充，但不是必須的。如果填充則需通信雙方的兩端能辨認出填充信息和真正需要傳送的信息，方可正常通信。
· FCS域
FCS域的功能主要對PPP數據幀傳輸的正確性進行檢測。
在數據幀中引入了一些傳輸的保證機製，會引入更多的開銷，這樣可能會增加應用層交互的延遲。
LCP報文封裝格式請參見PPP報文封裝的幀格式
。
在鏈路建立階段，PPP協議通過LCP報文進行鏈路的建立和協商。此時LCP報文作為PPP的淨載荷被封裝在PPP數據幀的Information域中，PPP數據幀的協議域的值固定填充0xC021。
在鏈路建立階段的整個過程中信息域的內容是變化的，它包括很多種類型的報文，所以這些報文也要通過相應的字段來區分。
· Code域
Code域的長度為一個字節，主要是用來標識LCP數據報文的類型。
在鏈路建立階段，接收方接收到LCP數據報文。當其Code域的值無效時，就會向對端發送一個LCP的代碼拒絕報文（Code-Reject報文）。
表1-2 常見code值
|
code值 |
報文類型 |
|
0x01 |
Configure-Request |
|
0x02 |
Configure-Ack |
|
0x03 |
Configure-Nak |
|
0x04 |
Configure-Reject |
|
0x05 |
Terminate-Request |
|
0x06 |
Terminate-Ack |
|
0x07 |
Code-Reject |
|
0x08 |
Protocol-Reject |
|
0x09 |
Echo-Request |
|
0x0A |
Echo-Reply |
|
0x0B |
Discard-Request |
|
0x0C |
Reserved |
· Identifier域
Identifier域為1個字節，用來匹配請求和響應，當Identifier域值為非法時，該報文將被丟棄。
通常一個配置請求報文的ID是從0x01開始逐步加1的。當對端接收到該配置請求報文後，無論使用何種報文回應對方，但必須要求回應報文中的ID要與接收報文中的ID一致。
· Length域
Length域的值就是該LCP報文的總字節數據。它是Code域、Identifier域、Length域和Data域四個域長度的總和。
Length域所指示字節數之外的字節將被當作填充字節而忽略掉，而且該域的內容不能超過MRU的值。
· Data域
Data域所包含的是協商報文的內容，這個內容包含以下字段。
¡ Type為協商選項類型。
¡ Length為協商選項長度，它是指Data域的總長度，也就是包含Type、Length和Data。
¡ Data為協商選項的詳細信息。
表1-3 常見Type中的協商類型值
|
協商類型值 |
協商報文類型 |
|
0x01 |
Maximum-Receive-Unit |
|
0x02 |
Async-Control-Character-Map |
|
0x03 |
Authentication-Protocol |
|
0x04 |
Quality-Protocol |
|
0x05 |
Magic-Number |
|
0x06 |
RESERVED |
|
0x07 |
Protocol-Field-Compression |
|
0x08 |
Address-and-Control-Field-Compression |
PPP鏈路建立過程如圖1-3所示：
(1) PPP初始狀態為不活動（Dead）狀態，當物理層Up後，PPP會進入鏈路建立（Establish）階段。
(2) PPP在Establish階段主要進行LCP協商。LCP協商內容包括：Authentication-Protocol（認證協議類型）、MRU（Maximum-Receive-Unit，最大接收單元）、Magic-Number（魔術字）、PFC（Protocol-Field-Compression，協議字段壓縮）、ACFC（Address-and-Control-Field-Compression，地址控製字段壓縮）等選項。如果LCP協商失敗，LCP會上報Fail事件，PPP回到Dead狀態；如果LCP協商成功，LCP進入Opened狀態，LCP會上報Up事件，表示鏈路已經建立（此時對於網絡層而言PPP鏈路還未建立，還不能夠在上麵成功傳輸網絡層報文）。
(3) 如果配置了認證，則進入Authenticate階段，開始PAP、CHAP、MSCHAP或MSCHAPv2認證。如果認證失敗，LCP會上報Fail事件，進入Terminate階段，拆除鏈路，LCP狀態轉為Down，PPP回到Dead狀態；如果認證成功，LCP會上報Success事件。
(4) 如果配置了網絡層協議，則進入Network協商階段，進行NCP協商（如IPCP協商、IPv6CP協商）。如果NCP協商成功，鏈路就會UP，就可以開始承載協商指定的網絡層報文；如果NCP協商失敗，NCP會上報Down事件，進入Terminate階段。（對於IPCP協商，如果接口配置了IP地址，則進行IPCP協商，IPCP協商通過後，PPP才可以承載IP報文。IPCP協商內容包括：IP地址、DNS服務器地址等。）
(5) 到此，PPP鏈路將一直保持通信，直至有明確的LCP或NCP消息關閉這條鏈路，或發生了某些外部事件（例如用戶的幹預）。
圖1-3 PPP鏈路建立過程
Dead階段也稱為物理層不可用階段。PPP鏈路都需從這個階段開始和結束。
當通信雙方的兩端檢測到物理線路激活（通常是檢測到鏈路上有載波信號）時，就會從Dead階段進入Establish階段，即鏈路建立階段。
鏈路被斷開後也同樣會返回到鏈路不可用階段。
在Establish階段，PPP鏈路進行LCP協商。協商內容包括工作方式是SP（Single-link PPP）還是MP（Multilink PPP）、最大接收單元MRU、認證方式和魔術字（Magic-Number）等選項。當完成配置報文的交換後，則會繼續進入下一個階段。
鏈路建立完成後，可以根據鏈路兩端設備的配置，選擇下一個階段進入認證階段或網絡層協議階段。這個選擇取決於用戶在鏈路兩端設備進行的配置。
在Establish階段，LCP的狀態機會發生如下改變。
· 當鏈路處於不可用階段時，此時LCP的狀態機處於初始化Initial狀態或準備啟動Starting狀態。當檢測到鏈路可用時，則物理層會向鏈路層發送一個Up事件。鏈路層收到該事件後，會將LCP的狀態機從當前狀態改變為Request-Sent（請求發送）狀態，根據此時的狀態機LCP會進行相應的動作，也就是開始發送Configure-Request報文來配置數據鏈路。
· 如果本端設備先收到Configure-Ack報文，則LCP的狀態機從Request-Sent狀態改變為Ack-Received狀態，本端向對端發送Configure-Ack報文以後，LCP的狀態機從Ack-Received狀態改變為Open狀態。
· 如果本端設備先向對端發送Configure-Ack報文，則LCP的狀態機從Request-Sent狀態改變為Ack-Sent狀態，本端收到對端發送的Configure-Ack報文以後，LCP的狀態機從Ack-Sent狀態改變為Open狀態。
· LCP狀態機變為Open狀態以後就完成當前階段的協商，並繼續進入下一個階段。
缺省情況下，PPP鏈路不進行認證。如果要求認證，在鏈路建立階段必須指定認證協議。
PPP提供密碼認證協議PAP和質詢握手認證協議CHAP兩種認證方式。
PPP的認證方式可以分為單向認證和雙向認證：
· 單向認證是指一端作為認證方，另一端作為被認證方。
· 雙向認證是單向認證的簡單疊加，即兩端都是既作為認證方又作為被認證方。
PAP認證方式為兩次握手認證，采用簡單口令。
PAP認證的過程如圖1-4所示。
圖1-4 PAP認證過程
(3) 認證方根據本地用戶表查看是否有被認證方的用戶名
¡ 若有，則查看口令是否正確，
- 若口令正確，則認證通過；
- 若口令不正確，則認證失敗。
¡ 若沒有，則認證失敗。
PAP報文封裝在協議域為0xC023的PPP數據鏈路層幀的信息域中。PAP報文的幀格式如圖1-5所示。
PAP認證報文幀格式中各字段的含義如表1-4所示。
表1-4 PAP認證報文幀格式各字段解釋表
|
字段 |
長度（字節） |
|
Code |
1 |
|
Identifier |
1 |
|
Length |
2 |
|
Data |
0或者多個字節 |
CHAP認證方式為三次握手認證協議。它隻在網絡上傳輸用戶名，而並不傳輸用戶密碼，因此安全性要比PAP高。
CHAP的認證過程如圖1-6所示。
CHAP單向認證過程分為兩種情況：認證方配置了用戶名和認證方未配置用戶名。推薦使用認證方配置了用戶名的方式，這樣可以對認證方的用戶名進行確認。
· 認證方配置了用戶名的認證過程
a. 認證方主動發起認證請求，構造一個包含隨機數的報文，並同時附帶本端的用戶名發送給被認證方（Challenge）。
b. 被認證方接到認證方的認證請求後，先檢查本端接口上是否配置了CHAP密碼。
- 如果接口配置了CHAP密碼，則根據報文ID、CHAP密碼和報文中的隨機數，利用Hash算法計算Hash值，將所得Hash值和被認證方自己的用戶名發回認證方（Response）。
- 如果接口未配置CHAP密碼，則根據此報文中認證方的用戶名在本端的用戶表查找該用戶對應的密碼，根據報文ID、此用戶密碼和報文中的隨機數，利用Hash算法計算Hash值，將所得Hash值和被認證方自己的用戶名發回認證方（Response）。
c. 認證方先根據收到的報文中被認證方的用戶名在本端查找到該用戶對應的密碼，然後再根據報文ID、被認證方密碼和Challenge報文中的隨機數，利用Hash算法計算Hash值，並與Response報文中的Hash值進行比較，若比較結果一致，認證通過，若比較結果不一致，認證失敗。
· 認證方未配置用戶名的認證過程
d. 認證方主動發起認證請求，向被認證方發送一個包含隨機數的報文（Challenge）。
e. 被認證方接到認證方的認證請求後，根據報文ID、配置的CHAP密碼和報文中的隨機數，利用Hash算法計算Hash值，將所得Hash值和自己的用戶名發回認證方（Response）。
f. 認證方先根據收到的報文中被認證方的用戶名在本端查找到該用戶對應的密碼，然後再根據報文ID、被認證方密碼和報文中的隨機數，利用Hash算法計算Hash值，並與Response報文中的Hash值進行比較，若比較結果一致，認證通過，若比較結果不一致，認證失敗。
CHAP報文封裝在協議域為0xC223的PPP數據鏈路層幀的信息域中。CHAP報文的幀格式如圖所示。
CHAP認證報文幀格式中各字段的含義如表1-5所示。
表1-5 CHAP認證報文幀格式各字段解釋表
|
字段 |
長度（字節） |
|
Code |
1 |
|
Identifier |
1 |
|
Length |
2 |
|
Data |
0或者多個字節 |
CHAP與PAP認證存在如下差異：
· PAP認證中，在鏈路上發送簡單口令，完成PPP鏈路建立後，被認證方會不停地在鏈路上反複發送用戶名和口令，直到身份認證過程結束，所以安全性不高。當實際應用過程中，對安全性要求不高時，可以采用PAP認證建立PPP連接。
· CHAP認證中，認證協議為三次握手認證協議。它隻在網絡上傳輸用戶名，而並不傳輸用戶密碼，因此安全性比PAP認證高。當實際應用過程中，對安全性要求較高時，可以采用CHAP認證建立PPP連接。
PPP完成了前麵幾個階段，通過NCP協商來選擇和配置一個網絡層協議並進行網絡層參數協商。每個NCP協議可在任何時間打開和關閉，當一個NCP的狀態機變成Open狀態時，則PPP就可以開始在鏈路上承載網絡層數據傳輸。
PPP能在任何時候終止鏈路。當載波丟失、認證失敗或管理員人為關閉鏈路等情況均會導致鏈路終止。
PPP提供了在其鏈路上進行安全認證的手段，使得在PPP鏈路上實施AAA變的切實可行。將PPP與AAA結合，可在PPP鏈路上對對端用戶進行認證、計費。
PPP支持如下認證方式：PAP、CHAP、MSCHAP、MSCHAPv2。
PAP為兩次握手協議，它通過用戶名和密碼來對用戶進行認證。
PAP在網絡上以明文的方式傳遞用戶名和密碼，認證報文如果在傳輸過程中被截獲，便有可能對網絡安全造成威脅。因此，它適用於對網絡安全要求相對較低的環境。
CHAP為三次握手協議。
CHAP認證過程分為兩種方式：認證方配置了用戶名、認證方未配置用戶名。推薦使用認證方配置用戶名的方式，這樣被認證方可以對認證方的身份進行確認。
CHAP隻在網絡上傳輸用戶名，並不傳輸用戶密碼（準確的講，它不直接傳輸用戶密碼，傳輸的是用MD5算法將用戶密碼與一個隨機報文ID一起計算的結果），因此它的安全性要比PAP高。
MSCHAP為三次握手協議，認證過程與CHAP類似，MSCHAP與CHAP的不同之處在於：
· MSCHAP采用的加密算法是0x80。
· MSCHAP支持重傳機製。在被認證方認證失敗的情況下，如果認證方允許被認證方進行重傳，被認證方會將認證相關信息重新發回認證方，認證方根據此信息重新對被認證方進行認證。認證方最多允許被認證方重傳3次。
MSCHAPv2為三次握手協議，認證過程與CHAP類似，MSCHAPv2與CHAP的不同之處在於：
· MSCHAPv2采用的加密算法是0x81。
· MSCHAPv2通過報文捎帶的方式實現了認證方和被認證方的雙向認證。
· MSCHAPv2支持重傳機製。在被認證方認證失敗的情況下，如果認證方允許被認證方進行重傳，被認證方會將認證相關信息重新發回認證方，認證方根據此信息重新對被認證方進行認證。認證方最多允許被認證方重傳3次。
· MSCHAPv2支持修改密碼機製。被認證方由於密碼過期導致認證失敗時，被認證方會將用戶輸入的新密碼信息發回認證方，認證方根據新密碼信息重新進行認證。
在IPv4網絡中，PPP進行IPCP協商過程中可以進行IP地址、DNS服務器地址的協商。
PPP在進行IPCP協商的過程中可以進行IP地址的協商，即一端給另一端分配IP地址。
在PPP協商IP地址的過程中，設備可以分為兩種角色：
· Client端：若本端接口封裝的鏈路層協議為PPP但還未配置IP地址，而對端已有IP地址時，用戶可為本端接口配置IP地址可協商屬性，使本端接口作為Client端接受由對端（Server端）分配的IP地址。該方式主要用於設備在通過ISP訪問Internet時，由ISP分配IP地址。
· Server端：若設備作為Server端為Client端分配IP地址，則應先配置地址池（可以是PPP地址池或者DHCP地址池），然後在ISP域下關聯地址池，或者在接口下指定為Client端分配的IP地址或者地址池，最後再配置Server端的IP地址，開始進行IPCP協商。
當Client端配置了IP地址可協商屬性後，Server端根據AAA認證結果（關於AAA的介紹請參見“安全配置指導”中的“AAA”）和接口下的配置，按照如下順序給Client端分配IP地址：
· 如果AAA認證服務器為Client端設置了IP地址或者地址池信息，則Server端將采用此信息為Client端分配IP地址（這種情況下，為Client端分配的IP地址或者分配IP地址所采用的地址池信息是在AAA認證服務器上進行配置的，Server端不需要進行特殊配置）。
· 如果Client端認證時使用的ISP域下設置了為Client端分配IP地址的地址池，則Server端將采用此地址池為Client端分配IP地址。
· 如果Server端的接口下指定了為Client端分配的IP地址或者地址池，則Server端將采用此信息為Client端分配IP地址。
設備在進行IPCP協商的過程中可以進行DNS服務器地址協商。設備既可以作為Client端接收其它設備分配的DNS服務器地址，也可以作為Server端向其它設備提供DNS服務器地址。通常情況下：
· 當主機與設備通過PPP協議相連時，設備應配置為Server端，為對端主機指定DNS服務器地址，這樣主機就可以通過域名直接訪問Internet；
· 當設備通過PPP協議連接運營商的接入服務器時，設備應配置為Client端，被動接收或主動請求接入服務器指定DNS服務器地址，這樣設備就可以使用接入服務器分配的DNS來解析域名。
在IPv6網絡中，PPP進行IPv6CP協商過程中，隻協商出IPv6接口標識，不能協商出IPv6地址、IPv6 DNS服務器地址。
PPP進行IPv6CP協商過程中，隻協商出IPv6接口標識，不能直接協商出IPv6地址。
客戶端可以通過如下幾種方式分配到IPv6全球單播地址：
· NDRA方式：客戶端通過ND協議中的RA報文獲得IPv6地址前綴。客戶端采用RA報文中攜帶的前綴和IPv6CP協商的IPv6接口標識一起組合生成IPv6全球單播地址。RA報文中攜帶的IPv6地址前綴的來源有三種：AAA授權的IPv6前綴、接口下配置的RA前綴、接口下配置的IPv6全球單播地址的前綴。三種來源的優先級依次降低，AAA授權的優先級最高。關於ND協議的詳細介紹請參見“三層技術-IP業務配置指導”中的“IPv6基礎”。
· DHCPv6（IA_NA）方式：客戶端通過DHCPv6協議申請IPv6全球單播地址。在服務器端可以通過AAA授權為每個客戶端分配不同的地址池，當授權了地址池後，DHCPv6在分配IPv6地址時會從地址池中獲取IPv6地址分配給客戶端。如果AAA未授權地址池，DHCPv6會根據服務器端的IPv6地址查找匹配的地址池為客戶端分配地址。關於DHCPv6協議的詳細介紹請參見“三層技術-IP業務配置指導”中的“DHCPv6”。
· DHCPv6（IA_PD）方式：客戶端通過DHCPv6協議申請代理前綴，客戶端通過代理前綴為下麵的主機分配IPv6全球單播地址。代理前綴分配方式中地址池的選擇原則和通過DHCPv6協議分配IPv6全球單播地址方式中地址池的選擇原則一致。
根據組網不同，主機獲取IPv6地址的方式如下：
· 當主機通過橋設備或者直連接入設備時，設備可以采用上述的方式NDRA方式或IA_NA直接為主機分配IPv6全球單播地址。
· 當主機通過路由器接入設備時，設備可以采用IA_PD方式為路由器分配IPv6前綴，路由器把這些IPv6前綴分配給主機來生成IPv6全球單播地址。
· NDRA+IA_PD、IA_NA+IA_PD可以根據實際組網需求進行組合使用，以滿足多種地址分配方式的需求。
在IPv6網絡中，IPv6 DNS服務器地址的分配有如下兩種方式：
· AAA授權IPv6 DNS服務器地址，通過ND協議中的RA報文將此IPv6 DNS服務器地址分配給主機。
· DHCPv6客戶端向DHCPv6服務器申請IPv6 DNS服務器地址。
PPP配置任務如下：
(1) 配置虛擬模板接口
¡ 創建虛擬模板接口
在PPPoE和L2TP組網中，需要本配置。
¡ （可選）恢複當前虛擬模板接口的缺省配置
¡ （可選）配置處理虛擬模板接口流量的slot
(2) 配置PPP認證
請選擇以下一項任務進行配置：
¡ 配置PAP認證
在網絡安全要求較高的環境下，需要配置PPP認證。
(3) （可選）配置輪詢功能
(4) （可選）配置PPP協商參數
¡ 配置ACFC協商
¡ 配置PFC協商
(5) （可選）配置PPP IPHC壓縮功能
在低速鏈路上，每個語音報文中報文頭消耗大部分的帶寬。為了減少報文頭對帶寬的消耗，可以在PPP鏈路上使用IPHC壓縮功能，對報文頭進行壓縮。
(6) （可選）配置PPP用戶的nas-port-type屬性
(7) （可選）配置PPP計費統計功能
(8) （可選）配置PPP接入用戶日誌信息功能
VT（Virtual Template，虛擬模板）是用於配置一個VA（Virtual Access，虛擬訪問）接口的模板。在PPPoE、L2TP和MP應用中需要創建一個VA接口與對端交換數據。此時，係統將選擇一個VT，以便動態地創建一個VA接口。
在PPPoE和L2TP應用中可借助VT接口來實現PPP協議的相關功能。有關PPPoE和L2TP的相關介紹，請參見“二層技術-廣域網接入配置指導”中的“PPPoE”和和“VPN配置指導”中的“L2TP”。
(1) 進入係統視圖。
system-view
(2) 創建虛擬模板接口並進入虛擬模板接口視圖。
interface virtual-template number
(3) （可選）配置接口的描述信息。
description text
缺省情況下，接口的描述信息為“該接口的接口名 Interface”，比如：Virtual-Template1 Interface。
(4) （可選）配置接口的MTU值。
mtu size
缺省情況下，虛擬模板接口的MTU值為1500字節。
(5) （可選）配置接口的期望帶寬。
bandwidth bandwidth-value
缺省情況下，接口的期望帶寬＝接口的波特率÷1000（kbps）。
接口下的某些配置恢複到缺省情況後，會對設備上當前運行的業務產生影響。建議您在執行該命令前，完全了解其對網絡產生的影響。
您可以在執行default命令後通過display this命令確認執行效果。對於未能成功恢複缺省的配置，建議您查閱相關功能的命令手冊，手工執行恢複該配置缺省情況的命令。如果操作仍然不能成功，您可以通過設備的提示信息定位原因。
(1) 進入係統視圖。
system-view
(2) 進入虛擬模板接口視圖。
interface virtual-template number
(3) 恢複當前接口的缺省配置。
default
當要求同一個虛擬模板接口的流量必須在同一個slot上進行處理時，可以在虛擬模板接口下配置處理接口流量的slot。
為提高當前接口處理流量的可靠性，可以通過service命令和service standby命令為接口分別指定一個主用slot和一個備用slot進行流量處理。
接口上同時配置了主用slot和備用slot時，流量處理的機製如下：
· 當主用slot不可用時，流量由備用slot處理。之後，即使主用slot恢複可用，流量也繼續由備用slot處理；僅當備用slot不可用時，流量才切換到主用slot。
· 當主用slot和備用slot均不可用時，流量由接收報文的slot處理；之後，主用slot和備用slot誰先恢複可用，流量就由誰處理。
如果接口上未配置主用slot和備用slot，則業務處理在接收報文的slot上進行。
為避免不必要的流量切換，建議配置主用slot後，再配置備用slot。如果先配置備用slot，則流量由備用slot處理；在配置主用slot後，流量將會從備用slot切換到主用slot。
(1) 進入係統視圖。
system-view
(2) 進入虛擬模板接口視圖。
interface virtual-template number
(3) 配置處理接口流量的主用slot。
service slot slot-number
缺省情況下，未配置處理接口流量的主用slot。
(4) 配置處理接口流量的備用slot。
service standby slot slot-number
缺省情況下，未配置處理接口流量的備用slot。
PPP支持的認證方式包括：PAP、CHAP、MSCHAP、MSCHAPv2。用戶可以同時配置多種認證方式，在LCP協商過程中，認證方根據用戶配置的認證方式順序逐一與被認證方進行協商，直到協商通過。如果協商過程中，被認證方回應的協商報文中攜帶了建議使用的認證方式，認證方查找配置中存在該認證方式，則直接使用該認證方式進行認證。
在認證方上，若采用本地AAA認證，則認證方必須為被認證方配置本地用戶的用戶名和密碼，若采用遠程AAA認證，則遠程AAA服務器上需要配置被認證方的用戶名和密碼。
不論是在本地還是AAA服務器上為被認證方配置的用戶名和密碼必須與被認證方上通過ppp pap local-user命令配置的用戶名和密碼相同。
(1) 進入係統視圖。
system-view
(2) 進入接口視圖。
interface interface-type interface-number
(3) 配置本地認證對端的方式為PAP。
ppp authentication-mode pap [ [ call-in ] domain { isp-name | default enable isp-name } ]
缺省情況下，PPP協議不進行認證。
(4) 配置本地AAA認證或者遠程AAA認證。
具體配置請參見“安全配置指導”中的“AAA”。
(1) 進入係統視圖。
system-view
(2) 進入接口視圖。
interface interface-type interface-number
(3) 配置本地被對端以PAP方式認證時本地發送的PAP用戶名和密碼。
ppp pap local-user username password { cipher | simple } string
缺省情況下，被對端以PAP方式認證時，本地設備發送的用戶名和密碼均為空。
查看配置的密碼信息時，無論采用明文或密文加密，密碼都將按密文方式顯示。
在認證方上，若采用本地AAA認證，則認證方必須為被認證方配置本地用戶的用戶名和密碼，若采用遠程AAA認證，則遠程AAA服務器上需要配置被認證方的用戶名和密碼。
不論是在本地還是AAA服務器上為被認證方配置的用戶名和密碼必須滿足如下要求：
· 用戶名必須與被認證方上通過ppp chap user命令配置的被認證方的用戶名相同。
· 密碼必須與被認證方上為認證方配置的用戶名的密碼相同。
在被認證方上，若采用本地AAA認證，則被認證方必須為認證方配置本地用戶的用戶名和密碼，若采用遠程AAA認證，則遠程AAA服務器上需要配置認證方的用戶名和密碼。
不論是在本地還是AAA服務器上為認證方配置的用戶名和密碼必須滿足如下要求：
· 用戶名必須與認證方上通過ppp chap user命令配置的認證方的用戶名相同。
· 密碼必須與認證方上為被認證方配置的用戶名的密碼相同。
在被認證方上不能通過ppp chap password命令配置進行CHAP認證時采用的密碼，否則即使認證方配置了用戶名，CHAP仍將按照認證方未配置用戶名的情況進行認證。
(1) 進入係統視圖。
system-view
(2) 進入接口視圖。
interface interface-type interface-number
(3) 配置本地認證對端的方式為CHAP。
ppp authentication-mode chap [ [ call-in ] domain { isp-name | default enable isp-name } ]
缺省情況下，PPP協議不進行認證。
(4) 配置采用CHAP認證時認證方的用戶名。
ppp chap user username
缺省情況下，CHAP認證的用戶名為空。
(5) 配置本地AAA認證或者遠程AAA認證。
具體配置請參見“安全配置指導”中的“AAA”。
(1) 進入係統視圖。
system-view
(2) 進入接口視圖。
interface interface-type interface-number
(3) 配置采用CHAP認證時被認證方的用戶名。
ppp chap user username
缺省情況下，CHAP認證的用戶名為空。
(4) 配置本地AAA認證或者遠程AAA認證。
具體配置請參見“安全配置指導”中的“AAA”。
在認證方上，若采用本地AAA認證，則認證方必須為被認證方配置本地用戶的用戶名和密碼，若采用遠程AAA認證，則遠程AAA服務器上需要配置被認證方的用戶名和密碼。
不論是在本地還是AAA服務器上為被認證方配置的用戶名和密碼必須滿足如下要求：
· 用戶名必須與被認證方上通過ppp chap user命令配置的被認證方的用戶名相同。
· 密碼必須與被認證方上通過ppp chap password命令配置的密碼相同。
(1) 進入係統視圖。
system-view
(2) 進入接口視圖。
interface interface-type interface-number
(3) 配置本地認證對端的方式為CHAP。
ppp authentication-mode chap [ [ call-in ] domain { isp-name | default enable isp-name } ]
缺省情況下，PPP協議不進行認證。
(4) 配置本地AAA認證或者遠程AAA認證。
具體配置請參見“安全配置指導”中的“AAA”。
(1) 進入係統視圖。
system-view
(2) 進入接口視圖。
interface interface-type interface-number
(3) 配置采用CHAP認證時被認證方的用戶名。
ppp chap user username
缺省情況下，CHAP認證的用戶名為空。
(4) 設置CHAP認證密碼。
ppp chap password { cipher | simple } password
缺省情況下，未配置進行CHAP認證時采用的密碼。
查看配置的密碼信息時，無論采用明文或密文加密，密碼都將按密文方式顯示。
設備隻能作為MSCHAP和MSCHAPv2的認證方來對其它設備進行認證。
MSCHAPv2認證隻有在RADIUS認證的方式下，才能支持修改密碼機製。
MSCHAPv2認證時不支持為PPP用戶配置認證方式為none。
在認證方上，若采用本地AAA認證，則認證方必須為被認證方配置本地用戶的用戶名和密碼，若采用遠程AAA認證，則遠程AAA服務器上需要配置被認證方的用戶名和密碼。不論是在本地還是AAA服務器上為被認證方配置的用戶名和密碼必須與被認證方上的配置相同。
若認證方配置了用戶名，則在被認證方上為認證方配置的用戶名必須與認證方上ppp chap user命令配置的用戶名相同。
(1) 進入係統視圖。
system-view
(2) 進入接口視圖。
interface interface-type interface-number
(3) 配置本地認證對端的方式為MSCHAP或MSCHAPv2。
ppp authentication-mode { ms-chap | ms-chap-v2 } [ [ call-in ] domain { isp-name | default enable isp-name } ]
缺省情況下，PPP協議不進行認證。
(4) 配置采用MSCHAP或MSCHAPv2認證時認證方的用戶名。
ppp chap user username
(5) 配置本地AAA認證或者遠程AAA認證。
具體配置請參見“安全配置指導”中的“AAA”。
(1) 進入係統視圖。
system-view
(2) 進入接口視圖。
interface interface-type interface-number
(3) 配置本地認證對端的方式為MSCHAP或MSCHAPv2。
ppp authentication-mode { ms-chap | ms-chap-v2 } [ [ call-in ] domain { isp-name | default enable isp-name } ]
缺省情況下，PPP協議不進行認證。
(4) 配置本地AAA認證或者遠程AAA認證。
具體配置請參見“安全配置指導”中的“AAA”。
PPP協議使用輪詢機製來確認鏈路狀態是否正常。
當接口上封裝的鏈路層協議為PPP時，鏈路層會周期性地向對端發送keepalive報文（可以通過timer-hold命令修改keepalive報文的發送周期）。如果接口在retry個（可以通過timer-hold retry命令修改該個數）keepalive周期內沒有收到keepalive報文的應答，鏈路層會認為對端故障，上報鏈路層Down。
如果將keepalive報文的發送周期配置為0秒，則本端不主動發送keepalive報文；當本端收到對端主動發送過來的keepalive報文時，仍可以對該keepalive報文進行應答。
在速率非常低的鏈路上，keepalive周期和retry值不能配置過小。因為在低速鏈路上，大報文可能會需要很長的時間才能傳送完畢，這樣就會延遲keepalive報文的發送與接收。而接口如果在retry個keepalive周期內沒有收到keepalive報文的應答，它就會認為鏈路發生故障。如果keepalive報文被延遲的時間超過接口的這個限製，鏈路就會被認為發生故障而被關閉。
(1) 進入係統視圖。
system-view
(2) 進入接口視圖。
interface interface-type interface-number
(3) 配置接口發送keepalive報文的周期。
timer-hold seconds
缺省情況下，接口發送keepalive報文的周期為10秒。
(4) 配置接口在多少個keepalive周期內未收到keepalive報文的應答就拆除鏈路。
timer-hold retry retry
缺省情況下，接口在5個keepalive周期內未收到keepalive報文的應答就拆除鏈路。
在PPP協商過程中，如果協商超時時間間隔內未收到對端的應答報文，則PPP將會重發前一次發送的報文。
在PPP鏈路兩端設備對LCP協商報文的處理速度差異較大的情況下，為避免因一端無法及時處理對端發送的LCP協商報文而導致對端重傳，可在對協商報文處理速度較快的設備上配置LCP協商的延遲時間。配置LCP協商的延遲時間後，當接口物理層UP時PPP將在延遲時間超時後才會主動進行LCP協商；如果在延遲時間內本端設備收到對端設備發送的LCP協商報文，則本端設備將不再等待延遲時間超時，而是直接進行LCP協商。
(1) 進入係統視圖。
system-view
(2) 進入接口視圖。
interface interface-type interface-number
(3) 配置協商超時時間間隔。
ppp timer negotiate seconds
缺省情況下，協商超時時間間隔為3秒。
(4) （可選）配置LCP協商的延遲時間。
ppp lcp delay milliseconds
缺省情況下，接口物理層UP後，PPP立即進行LCP協商。
(1) 進入係統視圖。
system-view
(2) 進入接口視圖。
interface interface-type interface-number
(3) 為接口配置IP地址可協商屬性。
ip address ppp-negotiate
缺省情況下，接口未配置IP地址可協商屬性。
多次執行本命令和ip address命令，最後一次執行的命令生效。關於ip address命令的詳細介紹，請參見“三層技術-IP業務命令參考”中的“IP地址”。
目前Server端為Client端分配IP地址支持以下三種方式：
· 在接口下指定為Client端分配的IP地址。
· 從接口下指定的地址池（支持PPP地址池和DHCP地址池）中為Client端分配IP地址。
· 從ISP域下關聯的地址池（支持PPP地址池和DHCP地址池）中為Client端分配IP地址。
不需要進行PPP認證的PPP用戶可以使用在接口下指定為Client端分配的IP地址和從接口下指定的地址池中為Client端分配IP地址兩種地址分配方式。同時配置這兩種方式，最後一次的配置生效。
需要進行PPP認證的PPP用戶可以使用全部的三種方式。同時配置多種方式時，以ISP域下關聯的地址池優先，然後是接口下指定為Client端分配的IP地址或者地址池（接口下同時配置這兩種方式時，最後一次的配置生效）。
如果用戶配置了名稱相同的PPP地址池和DHCP地址池，並采用該名稱的地址池為對端分配IP地址，則係統隻會使用PPP地址池來分配IP地址。
當通過PPP地址池給用戶分配IP地址時，請確保PPP地址池中不包含該PPP地址池的網關地址。
(1) 進入係統視圖。
system-view
(2) 進入接口視圖。
interface interface-type interface-number
(3) 配置接口為Client端分配的IP地址。
remote address ip-address
缺省情況下，接口不為Client端分配IP地址。
(4) 配置Server端的IP地址。
ip address ip-address
缺省情況下，接口未配置IP地址。
(1) 進入係統視圖。
system-view
(2) 配置PPP地址池。
ip pool pool-name start-ip-address [ end-ip-address ] [ group group-name ]
(3) （可選）配置PPP地址池的網關地址。
ip pool pool-name gateway ip-address [ vpn-instance vpn-instance-name ]
缺省情況下，未為PPP地址池配置網關地址。
(4) （可選）配置PPP地址池路由。
ppp ip-pool route ip-address { mask-length | mask } [ vpn-instance vpn-instance-name ]
缺省情況下，未配置PPP地址池路由。
需要保證配置的PPP地址池路由網段覆蓋PPP地址池網段範圍。
(5) 進入接口視圖。
interface interface-type interface-number
(6) 使用PPP地址池為Client端分配IP地址。
remote address pool pool-name
缺省情況下，接口不為Client端分配IP地址。
(7) 配置Server端的IP地址。
ip address ip-address
缺省情況下，接口未配置IP地址。
(1) 進入係統視圖。
system-view
(2) 配置DHCP功能。
¡ 如果Server端同時作為DHCP服務器，則在Server端上配置DHCP服務器、DHCP地址池相關內容。
¡ 如果Server端作為DHCP中繼，則在Server端上配置DHCP中繼相關內容（必須配置DHCP中繼用戶地址表項記錄功能、DHCP中繼地址池），並在遠端DHCP服務器上配置DHCP地址池。
DHCP服務器和DHCP中繼的具體配置介紹請參見“三層技術-IP業務配置指導”中的“DHCP服務器”和“DHCP中繼”。
(3) 進入接口視圖。
interface interface-type interface-number
(4) 使用DHCP地址池為Client端分配IP地址。
remote address pool pool-name
缺省情況下，接口不為Client端分配IP地址。
(5) （可選）配置PPP用戶作為DHCP客戶端時使用的DHCP客戶端ID。
remote address dhcp client-identifier { callingnum | username }
缺省情況下，未配置PPP用戶作為DHCP客戶端時使用的DHCP客戶端ID。
當使用PPP用戶名作為DHCP客戶端ID時，請確保各個上線用戶分別使用不同的PPP用戶名上線。
(6) 配置Server端的IP地址。
ip address ip-address
缺省情況下，接口未配置IP地址。
(1) 進入係統視圖。
system-view
(2) 配置PPP地址池。
ip pool pool-name start-ip-address [ end-ip-address ] [ group group-name ]
缺省情況下，未配置PPP地址池。
(3) （可選）配置PPP地址池的網關地址。
ip pool pool-name gateway ip-address [ vpn-instance vpn-instance-name ]
缺省情況下，未為PPP地址池配置網關地址。
(4) （可選）配置PPP地址池路由。
ppp ip-pool route ip-address { mask-length | mask } [ vpn-instance vpn-instance-name ]
缺省情況下，未配置PPP地址池路由。
用戶需要保證配置的PPP地址池路由網段覆蓋PPP地址池網段範圍。
(5) 進入ISP域視圖。
domain isp-name
(6) 在ISP域下關聯PPP地址池為Client端分配IP地址。
authorization-attribute ip-pool pool-name
缺省情況下，ISP域下未關聯PPP地址池。
本命令的詳細介紹請參見“安全命令參考”中的“AAA”。
(7) 退回係統視圖。
quit
(8) 進入接口視圖。
interface interface-type interface-number
(9) 配置Server端的IP地址。
ip address ip-address
缺省情況下，接口未配置IP地址。
(1) 進入係統視圖。
system-view
(2) 配置DHCP功能。
¡ 如果Server端同時作為DHCP服務器，則在Server端上配置DHCP服務器、DHCP地址池相關內容。
¡ 如果Server端作為DHCP中繼，則在Server端上配置DHCP中繼相關內容（必須配置DHCP中繼用戶地址表項記錄功能、DHCP中繼地址池），並在遠端DHCP服務器上配置DHCP地址池。
DHCP服務器和DHCP中繼的具體配置介紹請參見“三層技術-IP業務配置指導”中的“DHCP服務器”和“DHCP中繼”。
(3) 進入ISP域視圖。
domain isp-name
(4) 在ISP域下關聯DHCP地址池或DHCP中繼地址池為Client端分配IP地址。
authorization-attribute ip-pool pool-name
缺省情況下，ISP域下未關聯DHCP地址池或DHCP中繼地址池。
本命令的詳細介紹請參見“安全命令參考”中的“AAA”。
(5) 退回係統視圖。
quit
(6) 進入接口視圖。
interface interface-type interface-number
(7) （可選）配置PPP用戶作為DHCP客戶端時使用的DHCP客戶端ID。
remote address dhcp client-identifier { callingnum | username }
缺省情況下，未配置PPP用戶作為DHCP客戶端時使用的DHCP客戶端ID。
當使用PPP用戶名作為DHCP客戶端ID時，請確保各個上線用戶分別使用不同的PPP用戶名上線。
(8) 配置Server端的IP地址。
ip address ip-address
缺省情況下，接口未配置IP地址。
開啟接口的IP網段檢查功能後，當IPCP協商時，本地會檢查對端的IP地址與本端接口的IP地址是否在同一網段，如果不在同一網段，則IPCP協商失敗。
如果接口的IP網段檢查功能處於關閉狀態，則在IPCP協商階段不進行接口IP網段檢查。
(1) 進入係統視圖。
system-view
(2) 進入接口視圖。
interface interface-type interface-number
(3) 開啟接口的IP網段檢查功能。
ppp ipcp remote-address match
缺省情況下，接口的IP網段檢查功能處於關閉狀態。
一般情況下，Client端配置了ppp ipcp dns request命令後，Server端才會為本端指定DNS服務器地址。有一些特殊的設備，Client端並未請求，Server端卻要強製為Client端指定DNS服務器地址，從而導致協商不通過，為了適應這種情況，Client端可以配置ppp ipcp dns admit-any命令以便可以被動地接收對端指定的DNS服務器地址。
(1) 進入係統視圖。
system-view
(2) 進入接口視圖。
interface interface-type interface-number
(3) 配置設備主動請求對端指定DNS服務器地址。
ppp ipcp dns request
缺省情況下，禁止設備主動向對端請求DNS服務器地址。
(4) 配置設備可以被動地接收對端指定的DNS服務器地址，即設備不發送DNS請求，也能接收對端設備分配的DNS服務器地址。
ppp ipcp dns admit-any
缺省情況下，設備不會被動地接收對端設備指定的DNS服務器的IP地址。
在配置了ppp ipcp dns request命令的情況下，可以不配置本命令。
(1) 進入係統視圖。
system-view
(2) 進入接口視圖。
interface interface-type interface-number
(3) 配置設備為對端設備指定DNS服務器地址。
ppp ipcp dns primary-dns-address [ secondary-dns-address ]
缺省情況下，設備不為對端設備指定DNS服務器的IP地址。
配置本命令後，Server端不會主動給Client端指定DNS的地址，隻有收到Client端的請求後，Server端才會為對端指定DNS服務器地址。
缺省情況下，PPP報文中的地址字段的值固定為0xFF，控製字段的值固定為0x03，既然這兩個字段的值是固定的，就可以對這兩個字段進行壓縮。
ACFC協商選項字段用來通知對端，本端可以接收地址和控製字段被壓縮的報文。
ACFC協商在LCP協商階段進行，對於LCP報文不進行地址字段和控製字段壓縮，以確保LCP協商過程順利進行。當LCP協商通過後，對於發送的非LCP報文將進行地址字段和控製字段壓縮，以增加鏈路的有效載荷。
建議在低速鏈路上配置本功能。
(1) 進入係統視圖。
system-view
(2) 進入接口視圖。
interface interface-type interface-number
(3) 配置本地發送ACFC協商請求，即LCP協商時本地發送的協商請求攜帶ACFC協商選項。
ppp acfc local-request
缺省情況下，LCP協商時本地發送的協商請求不攜帶ACFC協商選項。
(1) 進入係統視圖。
system-view
(2) 進入接口視圖。
interface interface-type interface-number
(3) 配置拒絕對端的ACFC協商請求，即LCP協商時拒絕對端攜帶的ACFC協商選項。
ppp acfc remote-reject
缺省情況下，接受對端的ACFC協商請求，即LCP協商時接受對端攜帶的ACFC協商選項，並且發送的報文進行地址控製字段壓縮。
缺省情況下，PPP報文中的協議字段長度為2字節，然而，目前典型的協議字段取值都小於256，所以可以壓縮成一個字節來區分協議類型。
PFC協商選項字段用來通知對端，本端可以接收協議字段被壓縮成一個字節的報文。
PFC協商在LCP協商階段進行，對於LCP報文不進行協議字段壓縮，以確保LCP協商過程順利進行。當LCP協商通過後，對於發送的非LCP報文將進行協議字段壓縮，如果協議字段的頭8比特為全零，則不添加此8比特，以增加鏈路的有效載荷。
建議在低速鏈路上配置本功能。
(1) 進入係統視圖。
system-view
(2) 進入接口視圖。
interface interface-type interface-number
(3) 配置本地發送PFC協商請求，即LCP協商時本地發送的協商請求攜帶PFC協商選項。
ppp pfc local-request
缺省情況下，LCP協商時本地發送的協商請求不攜帶PFC協商選項。
(1) 進入係統視圖。
system-view
(2) 進入接口視圖。
interface interface-type interface-number
(3) 配置拒絕對端的PFC協商請求，即LCP協商時拒絕對端攜帶的PFC協商選項。
ppp pfc remote-reject
缺省情況下，接受對端的PFC協商請求，即LCP協商時接受對端攜帶的PFC協商選項，並且發送的報文進行協議字段壓縮。
IPHC（IP Header Compression，IP報文頭壓縮）協議主要應用於低速鏈路上的語音通信。
在低速鏈路上，每個語音報文中報文頭消耗大部分的帶寬。為了減少報文頭對帶寬的消耗，可以在PPP鏈路上使用IPHC壓縮功能，對報文頭進行壓縮。
IPHC壓縮分為如下兩種：
· RTP頭壓縮：對報文中的RTP/UDP/IP頭（長度共40字節）進行壓縮。
· TCP頭壓縮：對報文中的TCP/IP頭（長度共40字節）進行壓縮。
用戶必須在鏈路的兩端同時開啟IPHC壓縮功能，該功能才生效。
在虛擬模板接口、Dialer接口上開啟/關閉IPHC壓縮功能時，配置不會立即生效，隻有對此接口或者其綁定的物理接口依次進行shutdown和undo shutdown操作後，配置才能生效。
隻有在開啟IPHC壓縮功能後，才能配置接口上允許進行RTP頭/TCP頭壓縮的最大連接數，並且需要對接口依次進行shutdown和undo shutdown操作後，配置才能生效。在關閉IPHC壓縮功能後，配置將被清除。
(1) 進入係統視圖。
system-view
(2) 進入接口視圖。
interface interface-type interface-number
(3) 開啟PPP IPHC壓縮功能。
ppp compression iphc enable [ nonstandard ]
缺省情況下，IPHC壓縮功能處於關閉狀態。
與非H3C設備互通時需要配置nonstandard參數。
配置nonstandard參數後，僅支持RTP頭壓縮，不支持TCP頭壓縮。
(4) 配置接口上允許進行RTP頭壓縮的最大連接數。
ppp compression iphc rtp-connections number
缺省情況下，接口上允許進行RTP頭壓縮的最大連接數為16。
(5) 配置接口上允許進行TCP頭壓縮的最大連接數。
ppp compression iphc tcp-connections number
缺省情況下，接口上允許進行TCP頭壓縮的最大連接數為16。
本特性用來配置RADIUS認證計費時所攜帶的nas-port-type屬性。關於nas-port-type屬性的詳細介紹請參見RFC 2865。
本特性配置後僅對新接入的用戶生效，對當前已經存在用戶無影響。
(1) 進入係統視圖。
system-view
(2) 進入虛擬模板接口視圖。
interface virtual-template number
(3) 配置接口的nas-port-type屬性。
nas-port-type { adsl-cap | adsl-dmt | async | cable | ethernet | g.3-fax | piafs | sdsl | sync | virtual | wireless-other | x.25 | x.75 | xdsl }
缺省情況下，nas-port-type屬性由PPP用戶的業務類型和承載鏈路類型決定：
¡ 如果是PPPoE業務，nas-port-type屬性為ethernet。
¡ 如果是L2TP業務，nas-port-type屬性為virtual。
PPP協議可以為每條PPP鏈路提供基於流量的計費統計功能，具體統計內容包括出入兩個方向上流經本鏈路的報文數和字節數。AAA可以獲取這些流量統計信息用於計費控製。關於AAA計費的詳細介紹請參見“安全配置指導”中的“AAA”。
(1) 進入係統視圖。
system-view
(2) 進入接口視圖。
interface interface-type interface-number
(3) 開啟PPP計費統計功能。
ppp account-statistics enable [ acl { acl-number | name acl-name } ]
缺省情況下，PPP計費統計功能處於關閉狀態。
PPP接入用戶日誌是為了滿足網絡管理員維護的需要，對用戶的上線、下線、上線失敗的信息進行記錄，包括用戶名、IP地址、接口名稱、兩層VLAN、MAC地址、上線失敗原因、下線原因等。設備生成的PPP日誌信息會交給信息中心模塊處理，信息中心模塊的配置將決定日誌信息的發送規則和發送方向。關於信息中心的詳細描述請參見“網絡管理和監控配置指導”中的“信息中心”。
為了防止設備輸出過多的PPP日誌信息，一般情況下建議不要開啟此功能。
(1) 進入係統視圖。
system-view
(2) 開啟PPP接入用戶日誌信息功能。
ppp access-user log enable [ abnormal-logout | failed-login | normal-logout | successful-login ] *
缺省情況下，PPP接入用戶日誌信息功能處於關閉狀態。
在完成上述配置後，在任意視圖下執行display命令可以顯示PPP配置後的運行情況，通過查看顯示信息驗證配置的效果。
在用戶視圖下執行reset命令可以清除相應接口的統計信息。
表1-6 PPP顯示和維護
|
操作 |
命令 |
|
顯示PPP接入用戶的信息 |
display ppp access-user { domain domain-name | interface interface-type interface-number [ count ] | ip-address ipv4-address | ipv6-address ipv6-address | username user-name | user-type { lac | lns | pppoe } [ count ] } |
|
顯示PPP的協商報文統計信息 |
display ppp packet statistics [ slot slot-number ] |
|
顯示PPP地址池的信息 |
display ip pool [ pool-name | group group-name ] |
|
顯示虛擬模板接口的相關信息 |
display interface [ virtual-template [ interface-number ] ] [ brief [ description | down ] ] |
|
顯示虛擬訪問接口的相關信息 |
display interface [ virtual-access [ interface-number ] ] [ brief [ description | down ] ] |
|
顯示IPHC壓縮的統計信息 |
display ppp compression iphc { rtp | tcp } [ interface interface-type interface-number ] |
|
清除VA接口的統計信息 |
reset counters interface [ virtual-access [ interface-number ] ] |
|
清除IPHC壓縮的統計信息 |
reset ppp compression iphc [ rtp | tcp ] [ interface interface-type interface-number ] |
|
強製PPP用戶下線 |
reset ppp access-user { ip-address ipv4-address [ vpn-instance ipv4-vpn-instance-name ] | ipv6-address ipv6-address [ vpn-instance ipv6-vpn-instance-name ] | username user-name } |
|
清除PPP的協商報文統計信息 |
reset ppp packet statistics [ slot slot-number ] |
PPPoE（Point-to-Point Protocol over Ethernet，在以太網上承載PPP協議）是對PPP協議的擴展，它在以太網上建立PPPoE會話，將PPP報文封裝在以太網幀之內，在以太網上提供點對點的連接，解決了PPP無法應用於以太網的問題。PPPoE還可以通過遠端接入設備對接入的每台主機實現控製、認證、計費功能。由於很好地結合了以太網的經濟性及PPP良好的可擴展性與管理控製功能，PPPoE被廣泛應用於小區接入組網等環境中。
PPPoE使用Client/Server模型。PPPoE Client向PPPoE Server發起連接請求，兩者之間會話協商通過後，就建立PPPoE會話，此後PPPoE Server向PPPoE Client提供接入控製、認證、計費等功能。
根據PPPoE會話的起點所在位置的不同，PPPoE分為Router-Initiated和Host-Initiated兩種組網結構。
如圖2-1所示，在Router-Initiated組網結構中，PPPoE會話是在兩台設備之間建立的，所有用戶終端設備均通過該PPPoE會話進行數據傳輸。在這種組網結構中，PPPoE Client位於企業內部網絡，PPPoE server則由運營商提供。用戶終端設備無需安裝PPPoE客戶端撥號軟件，通常一個企業使用一個共享賬號接入網絡。
如圖2-2所示，在Host-Initiated組網結構中，每台用戶終端設備都需要安裝PPPoE客戶端撥號軟件。這些設備作為PPPoE client，與運營商的PPPoE server單獨建立PPPoE會話。這樣做的好處在於能夠方便運營商對用戶進行有效的計費和管理控製。
圖2-2 Host-Initiated組網結構圖
PPPoE報文的格式就是在以太網幀中攜帶PPP報文。其報文封裝結構如圖2-3所示。
表2-1 PPPoE報文字段信息描述表
|
字段 |
含義 |
|
Destination_address |
一個以太網單播目的地址或者以太網廣播地址（0xffffffffffff）： · 對於Discovery階段來，該字段的值是單播或者廣播地址，PPPoEClient尋找PPPoEServer的過程使用廣播地址，確認PPPoEServer後使用單播地址 · 對於Session階段，該字段必須是Discovery階段已確定的通信對方的單播地址 |
|
Source_address |
源設備的以太網MAC地址 |
|
Ether_type |
設置為0x8863（Discovery階段）或者0x8864（Session階段） |
|
Ver |
4bits，PPPoE版本號，值為0x1 |
|
Type |
4bits，PPPoE類型，值為0x1 |
|
Code |
8bits，PPPoE報文類型： · Code取值為0x00，表示會話數據 · Code取值為0x09，表示PADI報文 · Code取值為0x07，表示PADO或PADT報文 · Code取值為0x19，表示PADR報文 · Code取值為0x65，表示PADS報文 |
|
Session_ID |
16bits，對於一個給定的PPP會話，該值是一個固定值，並且與以太網Source_address和Destination_address一起實際地定義了一個PPP會話。值0xffff為將來的使用保留，不允許使用 |
|
Length |
16bits，定義PPPoE的Payload長度。不包括以太網頭部和PPPoE頭部的長度 |
|
PPP Packet |
PPP報文結構請參見PPP的基本概念 PPP報文封裝的幀格式 |
PPPoE用戶上線過程要經過PPPoE協商和PPP協商兩個階段，其中PPP協商包括LCP協商、PAP/CHAP認證、NCP協商等階段。
PPPoE協商是Device為用戶分配PPPoE接入用的Session ID，用來唯一標識一條用戶與Device之間的PPPoE虛擬鏈路。PPPoE的協商過程如圖2-4所示。
(1) 用戶廣播一個PADI（PPPoE Active Discovery Initiation，PPPoE激活發現起始）報文，在此報文中包含用戶想要得到的服務類型信息。
(2) 以太網內的所有接入集中器（如圖中的Device）在收到這個初始化報文後，將其中請求的服務與自己能提供的服務進行比較，其中可以為此用戶提供此服務的Device回應PADO（PPPoE Active Discovery Offer，PPPoE激活發現服務）報文。
(3) 用戶可能會收到多個Device回應的PADO報文。用戶根據一定的條件從返回PADO報文的Device中選定符合條件的Device，並向它返回一個會話請求報文PADR（非廣播）（PPPoE Active Discovery Request，PPPoE激活發現請求），在PADR報文中封裝所需的服務信息。
(4) 被選定的Device在收到PADR報文後開始進入PPP會話階段。它會產生一個會話標識以唯一的標識它和主機的這段PPPoE會話。並把這個特定的會話標識包含在會話確認報文PADS（PPPoE Active Discovery Session-confirmation，PPPoE激活發現會話確認）中回應給用戶，如果沒有錯誤發生就進入到PPP會話階段，而用戶在收到會話確認報文後如果沒有錯誤發生也進入到PPP會話階段。
圖2-4 PPPoE協商過程
PPP協商包括LCP協商、PAP/CHAP認證、NCP協商等階段。
進入PPP協商階段後，首先開始LCP協商，LCP協商過程如圖2-5所示：
(1) 用戶與Device互相發送LCP Configure-Request報文。
(2) 雙方收到Configure-Request報文後，根據報文中協商選項支持情況做出適當的回應（請參見表2-2）。若兩端都回應了Configure-ACK，則標誌LCP鏈路建立成功，否則會繼續發送Request報文：
¡ 如果在設定的LCP協商間隔與協商次數內，對端回應了Configure-ACK，則LCP鏈路建立成功。
¡ 如果在超過了設定的LCP協商次數後，對端尚未回應Configure-ACK，則終止LCP協商。
(3) LCP鏈路建立成功後，Device會周期性的向用戶發送LCP Echo-Request報文，然後接收對端回應的Echo-Reply報文，來探測LCP鏈路是否正常，以維持LCP連接。
圖2-5 LCP協商的基本過程
|
回應報文類型 |
含義 |
|
Configure-ACK |
若完全支持對端的LCP選項，則回應Configure-ACK報文，報文中必須完全協帶對端Request報文中的選項 |
|
Configure-NAK |
若支持對端的協商選項，但不認可該項協商的內容，則回應Configure-NAK報文，在Configure-NAK的選項中填上本端期望的內容，如：對端MRU值為1500，而本端期望MRU值為1492，則在Configure-NAK報文中埴上1492 |
|
Configure-Reject |
若不能支持對端的協商選項，則回應Configure-Reject報文，報文中帶上不能支持的選項 |
LCP協商完成後，進入認證階段，分為PAP認證和CHAP認證兩種認證方式。
· PAP認證
PAP為兩次握手協議，它通過用戶名及密碼來對用戶進行認證，且以明文的方式傳遞用戶名及密碼，因此，適用於對網絡安全要求相對較低的環境。PAP認證過程如圖2-6所示：
a. 被認證方發送本端的用戶名及密碼到認證方。
b. 認證方根據本端的用戶表查看是否存在此用戶。
¡ 若存在，則認證密碼是否正確。
- 若密碼正確，則發送Authenticate-ACK報文到對端，通告對端已被允許進入下一階段協商。
- 若密碼不正確，則發送Authenticate-NAK報文到對端，通告對端認證失敗。
¡ 若不存在，則認證失敗。
認證失敗後，不會直接將鏈路關閉。隻有當認證不過次數達到一定值時，才會關閉鏈路。
圖2-6 PAP認證流程
· CHAP認證
CHAP為三次握手協議。隻在網絡上傳輸用戶名，並不傳輸用戶密碼，因此它的安全性要比PAP高。CHAP的認證如圖2-7所示。
c. 認證方主動發起認證請求，認證方向被認證方發送一些包含隨機數的報文（Challenge），並同時將本端的用戶名附帶上一起發送給被認證方。
d. 被認證方接到認證方的認證請求後，先檢查本端接口上是否配置了CHAP密碼。
- 若已配置CHAP密碼，則被認證方通過哈希算法對報文ID、配置的密碼和報文中的隨機數計算哈希值，將該哈希值和自己的用戶名發回認證方（Response）。
- 若未配置CHAP密碼，則根據此報文中認證方的用戶名在本端的用戶表查找該用戶對應的密碼，通過哈希算法對報文ID、此用戶的密碼和報文中的隨機數計算哈希值，將生成的哈希值和被認證方自己的用戶名發回認證方（Response）。
e. 認證方通過哈希算法對報文ID、自己保存的被認證方密碼和Challenge報文中的隨機數計算哈希值，並與Response報文中的哈希值進行比較，若比較結果一致，認證通過，若比較結果不一致，認證失敗。
圖2-7 CHAP認證流程
NCP協商主要功能是協商PPP報文的網絡層參數，如IPCP、IPv6CP等，其中最為常見的是IPCP協議。PPPoE用戶主要通過IPCP協議來獲取訪問網絡的IP地址或IP地址段。
如圖2-8所示，NCP流程與LCP流程類似，用戶與Device之間互相發送Configure-Request報文並且互相回應Configure-ACK報文後，標誌NCP協商成功，可以正常訪問網絡。
圖2-8 NCP的基本協商流程
下麵將介紹NCP協商中常見的IPCP協議及IPv6CP協議。
· IPCP
IPCP協商過程是基於PPP狀態機進行協商的。經過雙方協商，通過配置請求、配置確認、配置否認等報文交換配置信息，最終IPCP狀態由initial（或closed）狀態變為Opened狀態。IPCP狀態變為Opened的條件必須是發送方和接收方都發送和接收過確認報文。
IPCP協商過程中，協商報文可包含多個選項，即參數，如IP Address、網關、掩碼等。各個選項的拒絕或否認都不影響IPCP的協商成功，此外，IPCP還支持無選項協商。
· IPv6CP
IPv6控製協議（IPv6CP）是一種網絡控製協議。IPv6CP主要負責在點對點鏈路終端雙方上配置，可用及停用IPv6協議模塊，可協商的參數包括接口ID和IPv6壓縮協議。IPv6CP使用與鏈路控製協議（LCP）相同的包交換機製。但隻有在PPP達到網絡層協議階段時，IPv6CP包才可以被交換。在達到這種階段前接收的IPv6CP包需要被丟棄。
目前，IPv6CP協商的選項隻支持接口ID的協商，不支持IPv6壓縮協議的協商。
IPv6網絡中，PPP用戶與IPoE用戶都需要使用ND協議或DHCPv6協議完成全球單播地址和配置信息的分配，使用DHCPv6協議的IA_PD選項完成CPE路由模式下LAN口IPv6前綴的分配。
在PPPoE用戶上線交互過程中，會對接口MTU及MRU的值進行協商，然後進行雙方報文的發送及接收。其協商方式主要分為如下兩種。
PPPoE發現階段：
· 如果用戶報文中攜帶PPP-Max-Payload字段且該值大於1492，該值將和BAS接口下的MTU值減8進行比較，取較小值作為協商值，並命名為PPP_MRU_Max，該協商值不是最終MTU協商結果，是作為參考值之一。
· 如果用戶報文中攜帶的PPP-Max-Payload字段小於等於1492。則PPP_MRU_Max取缺省值1492，作為參考值之一。
· 如果用戶報文沒有攜帶PPP-Max-Payload字段，則取PPP_MRU_Max為0，不作為參考值之一。
LCP協商階段：
· 用戶如果在LCP階段的Config-Request報文中攜帶有MRU字段：
¡ 如果用戶報文中攜帶的MRU與PPPoE發現階段協商出的PPP_MRU_Max相等，將取用戶攜帶的MRU作為用戶的最終MTU。
¡ 如果用戶報文中攜帶的MRU與PPPoE發現階段協商出的PPP_MRU_Max不相等或者PPP_MRU_Max為0，用戶攜帶的MRU將會和VT下的MTU值減8進行比較，取最小值作為用戶的最終MTU。
· 用戶如果在LCP階段的Config-Request報文沒有攜帶MRU字段，則取1492和VT下的MTU值減8進行比較，取最小的值作為用戶最終的MTU。
PPPoE發現階段：
· 用戶報文中如果攜帶PPP-Max-Payload字段，該值與BAS口下的MTU的較小值作為協商值，命名為PPP_MRU_Max，該值不是最終MTU協商結果，是作為參考值之一。
· 用戶報文中如果沒有攜帶PPP-Max-Payload字段，則取PPP_MRU_Max為缺省值0，不作為參考值。
LCP協商階段：
· 用戶如果在LCP階段的Config-Request報文攜帶有MRU字段，該值將會和VT下的MTU比較，取最小值作為用戶的最終MTU。
· 用戶如果在LCP階段的Config-Request報文沒有攜帶MRU字段：
¡ 如果用戶在PPPoE發現階段沒有協商PPP_MRU_Max，則取VT下的MTU作為用戶最終的MTU。
¡ 如果在PPPoE發現階段協商了PPP_MRU_Max，則取VT下的MTU和PPP-Max-Payload的最小值作為用戶最終的MTU。
PPPoE會話有三種工作模式：永久在線模式、按需撥號模式、診斷模式。
· 永久在線模式：當物理線路up後，設備會立即發起PPPoE呼叫，建立PPPoE會話。除非用戶刪除PPPoE會話，否則此PPPoE會話將一直存在。
· 按需撥號模式：當物理線路up後，設備不會立即發起PPPoE呼叫，隻有當有數據需要傳送時，設備才會發起PPPoE呼叫，建立PPPoE會話。如果PPPoE鏈路的空閑時間超過用戶配置的值，設備會自動中止PPPoE會話。
· 診斷模式：設備在配置完成後立即發起PPPoE呼叫，建立PPPoE會話。每隔用戶配置的重建時間間隔，設備會自動斷開該會話、並重新發起呼叫建立會話。通過定期建立、刪除PPPoE會話，可以監控PPPoE鏈路是否處於正常工作狀態。
PPPoE會話的工作模式由對應的撥號接口的配置決定：
· 當Dialer接口的鏈路空閑時間（通過dialer timer idle命令配置）配置為0，且Dialer接口上未配置dialer diagnose命令時，PPPoE會話將工作在永久在線模式。
· 當Dialer接口的鏈路空閑時間（通過dialer timer idle命令配置）配置不為0，且Dialer接口上未配置dialer diagnose命令時，PPPoE會話將工作在按需撥號模式。
· 當Dialer接口上配置了dialer diagnose命令時，PPPoE會話將工作在診斷模式。
PPPoE Client配置任務如下：
(1) 配置撥號接口
(2) 配置PPPoE會話
(3) （可選）複位PPPoE會話
在配置PPPoE會話之前，需要先配置一個Dialer接口，並在接口上開啟共享DDR。每個PPPoE會話唯一對應一個Dialer bundle，而每個Dialer bundle又唯一對應一個Dialer接口。這樣就相當於通過一個Dialer接口可以創建一個PPPoE會話。
(1) 進入係統視圖。
system-view
(2) 創建撥號訪問組，並配置撥號控製規則。
dialer-group group-number rule { ip | ipv6 } { deny | permit | acl { acl-number | name acl-name } }
僅工作在按需撥號模式下需要配置本命令。
(3) 創建Dialer接口，並進入該Dialer接口視圖。
interface dialer number
(4) 配置接口IP地址。
ip address { address mask | ppp-negotiate }
缺省情況下，接口未配置IP地址。
(5) 開啟共享DDR。
dialer bundle enable
缺省情況下，接口上未開啟共享DDR。
(6) 配置該撥號接口關聯的撥號訪問組，將該接口與撥號控製規則關聯起來。
dialer-group group-number
缺省情況下，接口不與任何撥號訪問組相關聯。
僅工作在按需撥號模式下需要配置本命令。
(7) 配置鏈路空閑時間。
dialer timer idle idle [ in | in-out ]
缺省情況下，鏈路空閑時間為120秒。
未配置dialer diagnose時，當idle配置為0時，PPPoE會話工作在永久在線模式下，不為0時工作在按需撥號模式下。
(8) 配置DDR應用工作在診斷模式。
dialer diagnose [ interval interval ]
缺省情況下，工作在非診斷模式。
僅工作在診斷模式下需要配置本命令。
(9) （可選）配置DDR自動撥號的間隔時間。
dialer timer autodial autodial-interval
缺省情況下，DDR自動撥號的間隔時間為300秒。
當鏈路斷開後將啟動自動撥號定時器，等待自動撥號定時器超時後再重新發起呼叫。
為了在鏈路斷開時可以盡快自動重新撥號，建議將自動撥號的時間間隔配置的小一些。
(10) （可選）配置Dialer接口的MTU值。
mtu size
缺省情況下，Dialer接口的MTU值為1500字節。
對於PPPoE Client應用的Dialer接口，應修改其MTU值，保證分片後的報文加上2個字節的PPP頭和6個字節的PPPoE頭之後的總長度不超過對應PPPoE會話所在接口的MTU值。
(11) （可選）配置Dialer接口的TCP最大報文段長度。
tcp mss value
缺省情況下，未配置接口的TCP最大報文段長度。
一般情況下，TCP最大報文段長度等於出接口的IP MTU減40，對於PPPoE Client應用的Dialer接口，應修改其TCP MSS值為1452，保證分片後的報文加上2個字節的PPP頭和6個字節的PPPoE頭，再加上40個字節的IP頭之後的總長度不超過對應PPPoE會話所在接口的MTU值。
有關該命令的詳細介紹，請參見“三層技術-IP業務命令參考”中的“IP性能優化”。
當成功建立PPPoE會話後，係統將自動創建一個VA接口，用於和對端進行報文交互。VA接口支持通過display interface virtual-access命令查看接口相關信息，但不支持對該接口進行配置。
VA接口隨著PPPoE會話的建立，由係統自動創建，PPPoE會話拆除後，係統自動刪除。
(1) 進入係統視圖。
system-view
(2) 進入接口視圖。
interface interface-type interface-number
(3) 建立一個PPPoE會話，並且指定該會話所對應的Dialer bundle。
pppoe-client dial-bundle-number number [ no-hostuniq ]
該Dialer bundle的序號number需要與Dialer接口的編號相同。
當PPPoE會話工作在永久在線模式或診斷模式時，如果使用reset pppoe-client命令複位PPPoE會話，設備會在自動撥號定時器超時後自動重新建立PPPoE會話。
當PPPoE會話工作在按需撥號模式時，如果使用reset pppoe-client命令複位PPPoE會話，設備會在有數據需要傳送時，才重新建立PPPoE會話。
請在用戶視圖下執行本命令，複位PPPoE會話。
reset pppoe-client { all | dial-bundle-number number }
在完成上述配置後，在任意視圖下執行display命令可以顯示PPPoE Client配置後的運行情況，通過查看顯示信息驗證配置的效果。
在用戶視圖下執行reset命令可以清除PPPoE會話的協議報文統計信息。
表2-3 PPPoE Client顯示和維護
|
操作 |
命令 |
|
顯示PPPoE會話的概要信息 |
display pppoe-client session summary [ dial-bundle-number number ] |
|
顯示PPPoE會話的協議報文統計信息 |
display pppoe-client session packet [ dial-bundle-number number ] |
|
清除PPPoE會話的協議報文統計信息 |
reset pppoe-client session packet [ dial-bundle-number number ] |
不同款型規格的資料略有差異, 詳細信息請向具體銷售和400谘詢。H3C保留在沒有任何通知或提示的情況下對資料內容進行修改的權利!
支持
