多机箱多链路PPP (MMP) (第2部分)

简介

本文档继续介绍在Cisco Systems的接入服务器平台上在“堆栈”或多机箱环境(有时称为MMP，用于多机箱多链路PPP)中支持多链路PPP(MP)。

本文档是两部分文档的第二部分。有关详细信息，请参阅本文档的第一部分。

先决条件

本文档的前提条件在本文档的第一部分中提供。

Examples

堆栈（带拨号程序）中的 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进行比较，图2中没有拨号器接口。

默认情况下，PRI和BRI是拨号器接口；如以下示例所示，在没有显式拨号器(通过dialer rotary命令)的情况下配置的PRI仍是Serial0:23上的拨号器接口：

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命令(或者，如果未定义thesgbp seed-bid命令，则默认为此命令)定义所有其他堆栈组成员。

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），则可以通过将本文档标题为AS5200（带拨号程序）的部分和使用卸载服务器的配置进行配置。

已分流的预计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上的拨号器映射语句中，并在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多链路），就会发生这种情况。

向多底盘拨号

如果客户端和最终赢得投标的堆叠成员之间有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-image。

• 每个接入服务器只能定义一个堆栈组。

• 堆叠成员之间的高延迟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命令（或指定最高出价）。

故障排除

如果您有问题，首先要返回到单个堆叠成员，禁用所有其他堆叠成员。然后测试PPP多链路连接，并通过常规质询握手身份验证协议(CHAP)身份验证和接口配置查找配置错误等。当您满意它工作时，请启用其他堆叠成员，然后继续如下操作：

1. 确保SGBP已启动并运行。

2. 调试PPP多链路。

3. 调试VPN和L2F。

确保 SGBP 已启动并正常运行

发出show sgbp命令，确保所有成员国都处于活动状态。否则，请留意IDLE、AUTHOK或ACTIVE状态。如前所述，IDLE是有意处于非活动状态的所有远程堆叠成员的有效状态。

如果您发现上述问题，请打开debug sgbp hellos和debug sgbp error命令。两个堆叠成员(例如系统和系统之间)之间的身份验证应如下（在系统上）：

  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的远程系统mb密码与系统上定义的密码不匹配。

  %SGBP-7-NORESP -Fail to respond to systemb group stackq, may not have password

这意味着systema没有在本地或通过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

这意味着从systemmb接收的SGBP hello的源IP地址与本地为systemb配置的IP地址(通过sgbp member 命令)不匹配。 请通过转到systemb并检查SGBP hello可以通过多个接口传输消息来更正此问题。

错误的另一个常见原因是：

  %SGBP-7-MISCONF, Possible misconfigured member routerk (1.1.1.6)

这意味着您没有在本地定义systemk，但另一个堆栈成员定义了。

调试 PPP 多链路

首先要检查的是客户端和堆栈成员是否在PPP上正确进行了身份验证。

本示例演示了CHAP身份验证，因为它涉及的更多。例如，它使用思科平台作为客户端，同时使用本地用户名(也支持终端访问控制器访问控制系统Plus(TACACS+)，但此处未显示)。

#config

username stackq password blah

#config

username userx password blah

不涉及拨号器接口

由于卸载服务器上没有拨号器接口，因此需要有虚拟接入接口的接口配置的另一个源。答案是虚拟模板接口。

1. 首先确保在每个堆栈成员上定义多链路全局虚拟模板编号。

     #config
     Multilink virtual-template 1
   

2. 如果尚未为相关物理接口（如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部分
• Cisco IOS软件中的虚拟访问PPP功能
• 了解 VPDN
• 技术支持 - Cisco Systems