多機箱多重連結PPP(MMP)（第2部分）
目錄
簡介
本檔案將繼續說明在Cisco Systems的存取伺服器平台上，在「堆疊」或多機箱環境(有時稱為MMP，用於多機箱多重連結PPP)中支援多重連結PPP(MP)。
本文檔是兩部分文檔的第二部分。如需詳細資訊，請參閱本檔案的第一部分。
必要條件
本文的先決條件詳見本檔案第一部分。
範例
堆疊中的AS5200（使用撥號程式）
在物理介面上配置撥號器時，根本無需指定虛擬模板介面。虛擬接入介面充當被動介面，在撥號器介面與撥號器介面關聯的物理介面之間進行按鍵。
簡而言之，您只需定義所有堆疊成員的堆疊組名稱、通用密碼和堆疊組成員。未定義虛擬模板介面，如下例所示：
systema#config sgbp group stackq sgbp member systemb 1.1.1.2 sgbp member systemc 1.1.1.3 username stackq password therock int dialer 1 ip unnum e0 dialer map ..... encap ppp ppp authen chap dialer-group 1 ppp multilink controller T1 0 framing esf linecode b8zs pri-group timeslots 1-24 interface Serial0:23 no ip address encapsulation ppp dialer in-band dialer rotary 1 dialer-group 1
以下示例來自E1控制器：
controller E1 0 framing crc4 linecode hdb3 pri-group timeslots 1-31 interface Serial0:15 no ip address encapsulation ppp no ip route-cache ppp authentication chap ppp multilink
在建立捆綁包介面後，僅使用來自撥號器介面的PPP命令對其進行克隆。後續預計的PPP鏈路也會使用撥號器介面的PPP命令進行克隆。圖3顯示撥號器介面如何位於套件組合介面的頂端。請將其與圖2（其中沒有撥號器介面）進行比較。
PRI和BRI在預設情況下是撥號器介面；配置沒有顯式撥號程式的PRI(通過dialer rotary命令)仍是Serial0:23上的撥號程式介面，如下例所示：
圖3:堆疊組 — stackq，由systema、systemb和systemc組成。systema的鏈路是在撥號器介面上配置的。interface Serial0:23 ip unnum e0 dialer map ..... encap ppp ppp authen chap dialer-group 1 dialer rot 1 ppp multilink
使用解除安裝伺服器
systema被指定為解除安裝伺服器(使用sgbp seed-bid命令)。 所有其他堆疊組成員必須使用sgbp seed-bid default命令定義(或者，如果未定義sgbp seed-bid命令，則預設為此)。
圖4:system作為解除安裝伺服器。systema#config multilink virtual-template 1 sgbp group stackq sgbp member systemb 1.1.1.2 sgbp member systemc 1.1.1.3 sgbp seed-bid offload username stackq password therock interface virtual-template 1 ip unnumbered e0 : ppp authen chap ppp multilink
使用物理介面解除安裝伺服器
如果指定的解除安裝伺服器也具有物理介面（例如PRI），希望與其他堆疊成員使用同一telco尋線組，可以配置它，方法是：將本文檔中標題為「AS5200 in a Stack(With Dialers)」和「Using an Offload Server」部分中顯示的配置組合起來。
解除安裝的投影PPP鏈路及其捆綁介面依賴虛擬模板來獲取配置源。具有第一個鏈路的連線會到達連線到撥號器介面的物理裝置，而捆綁介面和後續所有投影PPP鏈路的配置來源是撥號器介面配置。因此，這些變化會共存，取決於第一個連結到達的堆疊成員。
由於撥號器和虛擬模板介面上所需的配置非常複雜，建議不要使用此配置。
非同步、串列和其他非撥號程式介面
雖然您可以將非同步和串列裝置配置為撥號器介面(在這種情況下，它會在堆疊（使用撥號器）中恢復為AS5200，如本文檔的該部分所示)，但您可以選擇支援多機箱MP，而無需為非同步、串列和其他非撥號器介面配置撥號器。然後，在虛擬模板介面中定義所有配置的源，如下所示。
#config multilink virtual-template 1 sgbp group stackq sgbp member systemb 1.1.1.2 sgbp member systemc 1.1.1.3 username stackq password therock interface virtual-template 1 ip unnumbered e0 : ppp authen chap ppp multilink int async 1 encap ppp ppp multilink ppp authen chap : line 1 login autoselect ppp autoselect during-login speed 38400 flow hardware
從多機箱撥出
目前，多機箱配置不支援撥出，因為第2層轉發(L2F)協定不支援撥出。
因此，解除安裝伺服器（其中路由被偽裝、在撥號程式設定檔上等）無法在同一堆疊群組的前端堆疊成員上啟動撥號。任何欺騙路由都必須安裝在前端堆疊成員上，因為這些路由具有實體撥號連線（例如PRI）。
以下是一些解決方法：
-
對前端堆疊成員發出sgbp ppp-forward命令時，這表示所有PPP和PPP多鏈路呼叫都會自動轉發到堆疊組競標協定(SGBP)中標者，例如解除安裝伺服器。
您必須依靠網路訪問伺服器(NAS)撥出，讓IP路由融合（僅用於IP）開始它的過程。例如，要撥打1.1.1.1，請將此地址放在NAS上的dialer map語句中，然後在NAS上放置靜態路由，如下所示：
ip route 1.1.1.1 255.255.255.255 serial0:23 int serial0:23 ip address 3.3.3.3 255.0.0.0 dialer map ip 1.1.1.1 howard 7771234
當撥號連線到遠端對等體時，在遠端對等體和解除安裝伺服器之間形成PPP連線。前端堆疊成員已完全繞過。然後，解除安裝伺服器上的PPP將主機路由安裝到對等體1.1.1.1。此時，IP路由協定會從到解除安裝伺服器上的主機路由，因為路由度量將路由引向那裡。
注意：路由收斂會導致延遲。
-
如果在前端堆疊成員上未定義sgbp ppp-forward命令，則意味著只有PPP多鏈路呼叫會自動轉發給SGBP中標者，例如解除安裝伺服器。因此，從前端堆疊成員到遠端對等體的撥號程式跨越前端和遠端對等體之間的PPP連線，其行為與NAS不屬於堆疊組時的情況相同。
注意：只要連線是直通PPP（而不是PPP多鏈路），就會發生這種情況。
撥號到多機箱
如果您在客戶端與最終獲得bid的堆疊成員（例如解除安裝伺服器）之間流有IP路由(如增強型內部網關路由協定(EIGRP)和開放最短路徑優先(OSPF))，請注意以下幾點：
阻止在客戶端安裝連線的路由
配置客戶端1.1.1.2，其中1.1.1.2是NAS（透明幀轉發器）的地址，如下所示。
int bri0 dialer map 1.1.1.2 ....
例如，如果您在客戶端和解除安裝伺服器之間運行EIGRP，則解除安裝伺服器上的路由表指示要到達1.1.1.2，路由應通過虛擬訪問介面。這是因為客戶端上的PPP IP控制協定(IPCP)將連線的路由1.1.1.2安裝到BRI介面。然後，EIGRP會通過PPP會話（通過L2F）將此路由通告給解除安裝伺服器。因此，解除安裝伺服器上的EIGRP表示要到達1.1.1.2，它應該路由到客戶端 — 客戶端的路由1.1.1.1是到虛擬訪問介面。
現在，您有目的地為客戶端1.1.1.1的資料包。IP路由將資料包傳送到虛擬訪問介面。虛擬訪問介面封裝IP/使用者資料協定(UDP)/L2F/PPP封裝並將資料包傳送到L2F NAS - 1.1.1.2。此時一切正常。然後，IP路由不會通過（例如）乙太網介面傳送資料包，而是會再次通過虛擬接入介面傳送資料包。這是因為路由表指示要到達NAS，它必須通過客戶端。這會建立路由環路並有效地禁用L2F隧道上的輸入和輸出。
為防止發生這種情況，請不要允許IPCP在客戶端安裝連線的路由。
注意：僅當在客戶端和思科家庭網關之間運行某些IP路由協定時，此選項才適用。
客戶端配置如下：
int bri0 no peer neighbor-route
使用者端上的撥號器對應
當客戶端撥號到多機箱環境時，請始終為多鏈路捆綁包的每個潛在贏家定義撥號程式。例如，如果多機箱堆疊中有四個解除安裝伺服器，則客戶端應定義四個撥號器對映。
例如：
client 1.1.1.1 int bri0 dialer map 1.1.1.3 ...
在本示例中，1.1.1.3隻是一台解除安裝伺服器。
目的地為1.1.1.2的資料包將路由到BRI，撥號器會撥打目的地，因為存在撥號器對映匹配。解除安裝伺服器1.1.1.4實際上贏得了投標，並且PPP會話被投影到那裡。EIGRP在客戶端和解除安裝伺服器之間交換。客戶端上的IP路由表中填充了到BRI0的路由1.1.1.4（解除安裝伺服器）。現在，在客戶端上，目的地為1.1.1.4的資料包被路由到BRI0。但是，撥號器無法進行撥號，因為沒有撥號器匹配。
注意：每當客戶端需要訪問解除安裝伺服器時，始終為客戶端上所有潛在的SGBP中標者定義撥號器對映。
配置和限制
-
多機箱MP需要企業j映像。
-
只能為每個訪問伺服器定義一個堆疊組。
-
堆疊成員之間的高延遲WAN鏈路（導致MP重組延遲）可能會導致多機箱MP效率低下。
-
PRI、[M]BRI、串列和非同步裝置支援介面。
-
不支援撥出。
按協定配置介面配置
出於實際考慮，請勿在虛擬模板上配置特定協定地址。
interface virtual-template 1 ip address 1.1.1.2 255.0.0.0 :
虛擬模板介面用作模板，任何數量的虛擬訪問介面都可從該模板進行動態克隆。不應為虛擬模板介面指定每個介面協定特定的地址。由於每個網路介面的IP地址必須是唯一的，因此在虛擬模板介面上指定唯一的IP地址是錯誤的。請改為執行以下操作：
interface virtual-template 1 ip unnum e0 :
全域性協定配置的配置
撥入單一存取路由器並預期存取伺服器具有唯一全域位址（例如DECnet）的使用者端，現在實際上撥入由多個存取伺服器組成的多機箱多重連結堆疊群組。在這種情況下，請在單一存取伺服器上明確終止堆疊群組。為此，請在指定的訪問伺服器上發出sgbp seed-bid offload命令（或指定最高的bid）。
疑難排解
如果發生問題，第一步是返回至單一堆疊成員，停用所有其他堆疊成員。然後測試PPP多鏈路連線，並檢查常規質詢握手身份驗證協定(CHAP)身份驗證和介面配置，找出配置中的錯誤等。滿意它運作後，啟用其他堆疊成員，然後按以下方式繼續：
-
確保SGBP已啟動並正在運行。
-
調試PPP多鏈路。
-
調試VPN和L2F。
確保SGBP正確啟動和運行
發出show sgbp命令，以確保所有成員國都處於活動狀態。否則，請留意IDLE、AUTHOK或ACTIVE狀態。如前所述，IDLE是故意處於非活動狀態的所有遠端堆疊成員的有效狀態。
如果發現如上所述的問題，請啟用debug sgbp hellos和debug sgbp error命令。兩個堆疊成員之間的驗證(例如systema和systemb之間的驗證)應如下所示(在systema上):
systema# debug sgdp hellos %SGBP-7-CHALLENGE: Send Hello Challenge to systemb group stackq %SGBP-7-CHALLENGED: Hello Challenge message from member systemb (1.1.1.2) %SGBP-7-RESPONSE: Send Hello Response to systemb group stackq %SGBP-7-CHALLENGE: Send Hello Challenge to systemb group stackq %SGBP-7-RESPONDED: Hello Response message from member systemb (1.1.1.2) %SGBP-7-AUTHOK: Send Hello Authentication OK to member systemb (1.1.1.2) %SGBP-7-INFO: Addr = 1.1.1.2 Reference = 0xC347DF7 %SGBP-5-ARRIVING: New peer event for member systemb
systema傳送CHAP樣式的質詢並從systemb接收響應。同樣，systemb會發出質詢並接收來自systema的響應。
如果驗證失敗，您將看到：
%SGBP-7-AUTHFAILED - Member systemb failed authentication
這表示用於stackq的遠端系統密碼與system上定義的密碼不匹配。
%SGBP-7-NORESP -Fail to respond to systemb group stackq, may not have password
這表示system並未在本地定義或透過TACACS+定義使用者名稱或密碼。
通常，為堆疊組stackq在所有堆疊成員之間定義一個通用密碼。您可以本地定義或透過TACACS+定義。
每個堆疊成員上定義的本地使用者名稱為：
username stackq password blah
此公共秘密是為了方便堆疊成員SGBP投標和仲裁。
請參閱本檔案的偵錯PPP多重連結一節，以取得對遠端使用者端撥入堆疊成員時PPP連結驗證的討論。
在佈線或路由問題中，一個常見錯誤是堆疊成員的源IP地址（在SGBP hello消息中實際接收）與同一堆疊成員的本地定義的IP地址不同。
systema#debug sgbp error %SGBP-7-DIFFERENT - systemb's addr 1.1.1.2 is different from hello's addr 3.3.4.5
這表示從systemb收到的SGBP hello的源IP地址與本地為systemb配置的IP地址不匹配(通過sgbp member命令)。 請轉到system並檢查多個介面，SGBP hello可以通過這些介面傳輸消息，從而更正此問題。
導致錯誤的另一個常見原因是：
%SGBP-7-MISCONF, Possible misconfigured member routerk (1.1.1.6)
這表示本地未定義systemk，但另一個堆疊成員定義。
調試PPP多鏈路
首先檢查的是使用者端和堆疊成員是否在PPP上正確通過驗證。
本示例演示了CHAP身份驗證，因為它更加複雜。我們熟悉的一個例子是，它將思科平台用作客戶端以及本地使用者名稱(也支援終端訪問控制器訪問控制系統Plus(TACACS+)，但此處未顯示)。
| 客戶端使用者 | stack stackq的每個成員 |
|---|---|
#config username stackq password blah |
#config username userx password blah |
不涉及撥號器介面
由於解除安裝伺服器上沒有撥號器介面，所以需要虛擬接入介面的另一個介面配置源。答案是虛擬模板介面。
-
首先確保已在每個堆疊成員上定義多重連結全域虛擬範本編號。
#config Multilink virtual-template 1
-
如果尚未為相關物理介面（如PRI、BRI、非同步和同步串列）配置任何撥號器介面，則可以定義：
interface virtual-template 1 ip unnumbered e0 ppp authen chap ppp Multilink
注意：您沒有在虛擬模板上定義特定IP地址。這是因為投影的虛擬訪問介面始終從虛擬模板介面克隆。如果隨後的PPP鏈路也投影到已克隆且活動了虛擬訪問介面的堆疊成員，則兩個虛擬介面具有相同的IP地址，從而導致它們之間的IP路由錯誤。
涉及的撥號器介面
在物理介面上配置撥號器時，無需指定虛擬模板介面，因為介面配置駐留在撥號器介面中。在這種情況下，虛擬訪問介面充當被動介面，在撥號器介面和與撥號器介面關聯的成員介面之間進行按鍵。
注意：撥號器介面Dialer 1在PPP多鏈路會話中顯示如下：
systema#show ppp Multilink Bundle userx 2 members, Master link is Virtual-Access4 Dialer interface is Dialer1 0 lost fragments, 0 reordered, 0 unassigned, 100/255 load 0 discarded, 0 lost received, sequence 40/66 rcvd/sent members 2 Serial0:4 systemb:Virtual-Access6 (1.1.1.1)
LCP和NCP
所有成員介面上的LCP狀態必須為UP。IPCP、ATCP和其他NCP應僅在捆綁包介面上啟用。
捆綁包介面Virtual-Access4 show int輸出應如下所示：
router#show int Virtual-Access4
Virtual-Access4 is up, line protocol is up
:
LCP Open, Multilink Open
Open: ipcp
:
所有其他成員介面應具有以下show int輸出：
router# show int Serial0:4
Serial0:4 is up, line protocol is up
:
LCP Open, Multilink Open
Closed: ipcp
調試VPN/L2F
開啟以下功能：
debug vpn event debug vpn error
當實體介面接受傳入呼叫且現在轉送到目標堆疊成員時，會顯示以下內容：
Serial0:21 VPN Forwarding Serial0:21 VPN vpn_forward_user userx is forwarded
在目標堆疊成員上，如果您看到以下內容：
Virtual-Access1 VPN PPP LCP not accepting rcv CONFACK Virtual-Access1 VPN PPP LCP not accepting sent CONFACK
然後檢查您的虛擬模板介面的定義。通常，虛擬模板介面必須與接受傳入呼叫的物理介面的PPP介面引數匹配。
記住最低配置（使用CHAP作為示例）：
#config multilink virtual template 4 int virtual-template 4 ip unnum e0 encap ppp ppp authen chap ppp Multilink
您可以看到以下內容：
Virtual-Access1 VPN PPP LCP accepted sent & rcv CONFACK
如果您看到以上訊息，則表示L2F已成功將PPP連結從首次進行傳入呼叫的堆疊成員投影到同一使用者端的套件組合介面所在的堆疊成員（或將會建立，如解除安裝情境）。
常見錯誤是無法定義通用堆疊名稱(stackq)的使用者名稱，或是無法在所有堆疊成員上比對堆疊密碼。
發出以下命令：
debug vpdn l2f-error
出現以下消息：
L2F Tunnel authentication failed for stackq
在這種情況下，請更正每個堆疊成員上的使用者名稱和密碼是否相符。
相關資訊
修訂記錄
| 修訂 | 發佈日期 | 意見 |
|---|---|---|
1.0 |
09-Sep-2005 |
初始版本 |
意見