2.3 L2F故障排除
VPN故障诊断与排除
要快速、高效地排除L2F故障，必须对L2F协议的工作原理、L2F配置和PPP有深入的了解。另外，如果远程接入客户拨号到NAS，还必须深入了解有关ISDN和异步调制解调器的知识。本节介绍如何将端到端故障排除方法应用于L2F。
图2.26所示的流程图描述了L2F故障排除过程。读者可以根据该流程图，快速地找到与发生的网络问题相关的章节。
警告：
应慎用debug命令。如果在负载非常重的路由器上执行debug命令，可能严重影响路由器运行，甚至导致路由器崩溃或挂起。要查看路由器CPU的使用率，可使用命令show process cpu。
介绍故障排除之前，有必要复习一下L2F的隧道建立模型以及可能出现的问题。
图2.27说明了隧道建立过程。
图2.27中的各个步骤如下：
1．如果远程接入客户使用的是异步拨号，L2F隧道建立的第一步为NAS接收呼叫。
ISDN呼叫建立消息通过ISDN Q.931协议达到PRI。
然后，NAS将远程接入客户的呼叫交换到内部的数字（MICA）调制解调器。
2．自动检测到PPP后，NAS和远程接入客户进行LCP协商。这包括协商诸如验证协议、回拨和异步控制字符映射表（ACCM）等参数。
3．LCP协商完成后，将进行部分验证。如果使用的是CHAP验证，NAS将向远程接入客户发送一个挑战。
客户用一条CHAP应答消息进行应答。
4．NAS对应答消息中的名称字段进行分析，看其中是否包含一个对应于一条L2F隧道的域名。
另外，也可以根据DNIS或完整的用户名（基于用户的VPDN）将客户同L2F隧道关联起来。
5．如果没有现成的隧道，NAS和终点网关将开始建立L2F隧道。
在隧道建立阶段，终点网关检查是否配置了这样的VPDN组：它能够端接从NAS出发的L2F隧道，同时确认是否有足够的可用资源。
在此阶段，NAS和终点网关还彼此验证对方。
6．建立隧道后，开始建立客户会话。在此阶段，NAS将来自客户的CHAP应答及其他LCP参数转发给终点网关。
7．将虚拟模板的配置克隆（复制）给一个虚拟接入接口。
8．至此，终点网关便完成了LCP协商和PPP验证。
9．完成LCP协商和PPP验证后，终点网关和远程接入客户便进行NCP（如IPCP）协商。
10．如果NCP协商成功，便开始转发协商好的协议（如IP）分组。
正如读者可能猜到的，可能出现问题的地方有很多。图2.28和表2.4说明了一些可能出现的问题。
L2F的隧道建立模型的第一部分是远程接入客户发起PPP连接，表2.4列出了一些可能出现的问题。
如果是Microsoft客户，可能出现的问题包括调制解调器驱动程序不正确、客户和调制解调器之间的电缆出现了问题、拨号网络配置不正确等。
本书并不想详细介绍如何排除客户端操作系统和硬件故障，而将重点放在如何排除NAS和终点网关发生的故障。
接下来介绍L2F隧道故障排除过程，首先从NAS上的呼叫接收开始。
2.3.1 NAS上的呼叫接收
首先要确认的是，NAS是否像预期的那样接收呼叫。本节假设远程客户使用的是异步调制解调器，NAS通过其ISDN PRI接收呼叫。
图2.29说明了NAS上的呼叫接收。
首先要确认ISDN接口处于活动状态以及呼叫被接收。show isdn status是一个很不错的命令，可以提供有关ISDN接口的快照。
程序清单2-12是ISDN接口正常时该命令的输出。
加黑的第1行列出了以全局方式配置的ISDN交换机类型（primary-net5）；加黑的第2行显示了应用于串行接口0/0:15的ISDN交换机类型（也是primary-net5）。
接下来加黑的三行显示了第1～3层的状态。第1层的状态为ACTIVE，这表明已经建立了物理连接性。
来看第2层，正如读者看到的，其状态为MULTIPLE_FRAME_ESTABLISHED。这表明PRI已经与服务提供商的ISDN交换机建立了通信关系。接下来是第3层的状态，从中可知，接口上有一个活动的呼叫。
看过正常时的输出后，来看看不正常时的输出，如程序清单2-13所示。
从程序清单2-15中加黑的第1行可知，E1 0/0现在处于正常状态（up），加黑的第2行表明，没有检测到警告。
现在使用命令show isdn status检查ISDN的状态，如程序清单2-16所示。
从输出中加黑的内容可知，现在第1层处于ACTIVE状态，第2层处于MULTIPLE_FRAME_ESTABLISHED状态。问题解决了。
E1/T1控制器的大部分问题都是由于帧格式、线路编码或时钟源配置不正确引起的。请务必按服务提供商的建议配置它们。另外，确保ISDN交换机类型和封装类型被正确设置。
确定路由器正确地与ISDN交换机通信后，接下来需要检查呼叫建立是否运行正确。ISDN使用Q.931协议来发送呼叫建立信号，因此需要使用命令debug isdn q931来验证呼叫建立，如程序清单2-17所示。
在程序清单12-7中，加黑的第1行表明，在D信道（serial0/0:15）上收到（RX）了一条呼叫建立消息。
如果接着往下看，将看到主叫方（远程接入客户）的号码为1111，被叫方（NAS）的号码为7777。
在加黑的第4行中，NAS发送（TX）了一条CONNECT消息，这表明已经接受了PRI上的呼叫。
接着往下看，您将看到消息Interface Serial0/0:0 is now connected to 1111，这表明已经成功地完成了呼叫建立。如果呼叫建立失败，应检查ISDN交换机类型以及远程接入客户为接入NAS而呼叫的号码。
在串行接口0/0:0（B信道之一）上成功地收到呼叫后，呼叫将路由到内部MICA调制解调器。要查看调制解调器是否成功地收到了呼叫，可使用命令debug modem，如程序清单2-18所示。
加黑的第1行表明，调制解调器MICA 1/1（插槽1中的调制解调器1）处于呼叫建立状态（Modem 1/1 Mica: in modem state CALL_SETUP）；加黑的第2行表明，该调制解调器的发送和接收（Tx/Rx）速度分别为49333和28800bit/s。
在加黑的第3和4行之间完成了自动选择过程，在该线路上收到了多个由数据组成的样本（sample）。根据这些样本，NAS知道使用的是PPP，并自动将该线路配置为使用PPP封装类型。然而在该线路上触发了PPP协商。最后，在加黑的第5行，异步接口34的状态变成up。
如果执行命令debug modem时没有看到任何输出，请确保在ISDN D信道上配置了命令isdn incoming voice-modem，同时确保在调制解调器线路上配置了命令modem InOut。
调试调制解调器时，另一个很有用的命令是debug modem csm。该命令提供了有关（内部数字调制解调器的）呼叫交换模块的详细调试信息。至此，确认了能够成功地完成呼叫建立。
2.3.2 排除NAS的PPP故障
确认远程接入客户的呼叫被成功收到后，接下来需要在NAS上检查PPP协商。在NAS上，PPP协商过程由两个阶段组成：LCP协商和部分验证。
别忘了，NAS并不协商网络控制协议（NCP），这种协商是在客户和终点网关之间完成的。
1．远程客户和NAS之间的LCP协商失败
如果NAS和远程客户不能成功地完成LCP协商，可使用命令debug ppp negotiation来检查哪里出了问题。
图2.30说明了NAS和远程客户之间的LCP协商。
加黑的第1行表明，串行接口0/0:0（B信道之一）处于连接状态。
在加黑的第2行中，异步接口36的状态变为up。
然后，PPP进入ESTABLISHING阶段（参见加黑的第3行），这意味着PPP协商即将开始。
PPP协商从NAS将一条配置请求（CONFREQ）消息发送给远程接入客户开始，如程序清单2-20所示。
程序清单2-20中加黑的行表明，NAS发送（O）了一条配置请求（CONFREQ）消息，该消息用于将NAS想使用的LCP选项告诉远程接入客户。
该CONFREQ中包含的LCP选项有异步控制字符映射表（ACCM）、验证协议、魔幻数字（Magic Number）、协议字段压缩（PFC）以及地址和控制字段压缩（ACFC）。
ACCM用于控制如何对链路上的数据进行转义。对数据进行转义可避免调制解调器将通过链路发送的数据错误地解释为命令。
括号中为原始数据。在ACCM 0x000A0000(0x0206000A0000)中，0x02为LCP选项编号（ACCM本身），0x06为选项长度，0x000A0000是4字节的映射表，定义了如何对字符进行转义。
需要指出的是，PPP选项通常由选项编号、选项长度和选项值组成。
接下来的一个LCP选项是验证协议（0x03）。在这个例子中，指定的验证协议是标准的MD5 CHAP（0xC22305）。
第三个选项是魔幻数字（0x05）。NAS指定的魔幻数字为0x115342A4。魔幻数字用于环路检测。
接下来指定的选项是PFC（0x07）。NAS使用该选项来告诉客户，它能够接收经过压缩的PPP协议字段。
最后一个选项是ACFC（0x08）。该选项用于指出NAS能够接收没有HDLC地址和控制字段的PPP帧。
然后，客户使用一条配置确认（CONFACK）消息来确认NAS的CONFREQ，如程序清单2-21所示。注意，该CONFACK的ID（6）与前面的CONFREQ（参见程序清单2-20）相同。
该CONFACK中的所有选项都与程序清单2-20中CONFREQ的相同。
接下来，NAS从远程客户那里收到第一个入站（I）CONFREQ，如程序清单2-22所示。
该CONFREQ中的大部分选项都与NAS的CONFREQ指定的相同，但新增了一个选项：客户指定了回拨（0x0D）选项。客户使用该选项来请求NAS在验证和回拨后拆除链路。
注意，在客户会话建立期间，NAS将以L2F_OPEN子选项L2F_REQ_LCP0的方式将来自客户的第一个CONFREQ转发给终点网关。
程序清单2-26中的CONFREQ包含的选项与前两个CONFREQ相同。
来自客户的最后一个CONFACK对第三个CONFREQ进行确认，如程序清单2-27所示。
程序清单2-27 从客户那里收到的最后一个CONFACK
程序清单2-32是LCP协商失败时，命令debug ppp negotiation的输出。注意，这里只列出了相关的输出部分。
在加黑的第1行，NAS将一个LCP CONFREQ发送给客户。指定的验证协议（AuthProto）为CHAP（标准MD5 CHAP）。在加黑的第2行，客户用一个CONFACK进行应答，指定使用MS-CHAP（Microsoft CHAP）。
加黑的第3行表明，NAS同其对等体（客户）的协商以失败告终；在加黑的第4行，NAS发送一条TERMREQ以终止连接。
接下来在加黑的第5和第6行中，串行接口0/0:0与1111断开，异步接口36的状态变为down。NAS和客户无法就验证协议达成一致，因此客户被断开。
为解决这种问题，可将NAS配置为接受使用MS-CHAP，或者将客户配置为接受使用MD5 CHAP。这里重新配置客户，使之接受使用标准MD5 CHAP。客户重新连接时，将成功完成LCP协商。这可以使用命令show user和show caller user来验证。
程序清单2-33是命令show user的输出。
从中可知，用户joebloggs@（mjlnet.com）与异步接口37相连。有关客户连接的更详细信息，可使用命令show caller user来获悉。
程序清单2-34是命令show caller user的输出。
从加黑的第1行可知，用户joebloggs@mjlnet.com与线路37相连；加黑的第2行表明，该线路上运行的是PPP；加黑的第3行表明，成功地完成了LCP协商（状态为OPEN），使用的验证协议为MD5 CHAP。
2．在NAS上PPP部分验证失败
成功地完成LCP协商，LCP处于OPEN状态后，将进入PPP验证。
图2.31说明了NAS和远程接入客户之间的部分验证。
程序清单2-35是验证成功时命令debug ppp negotiation的输出。注意，这里只列出了相关的输出部分。
命令debug ppp authentication也可用于排除PPP验证故障。
在加黑的第1行，LCP状态变为OPEN。这表明LCP协商成功，PPP进入AUTHENTICATING阶段（加黑的第2行），验证即将开始。
首先，NAS将一个出站（O）CHAP挑战发送给远程接入客户（加黑的第3行）。注意，您看不到来自客户的入站（I）CHAP挑战。在加黑的第4行，客户使用一条响应消息进行应答。
NAS没有发送CHAP成功/失败消息给客户。咋一看，有一些奇怪，因为在常规的PPP协商过程中，NAS将这样做。
在这里，PPP协商过程是不同的。NAS根本不查看CHAP响应消息中的值字段（包含在响应数据中），而是对用户名或DNIS进行分析，并查找对应于域名或DNIS的L2F隧道。找到对应的L2F隧道（必要时建立一条到终点网关的隧道）后，NAS将客户的CHAP响应和其他信息一并发送给终点网关。
在这个例子中，客户的响应提供的用户名为joebloggs@mjlnet.com。NAS将域名mjlnet.com同一条L2F隧道关联起来。
另外需要注意的是，在程序清单2-35中加黑的第3和第4行之间，从客户那里收到了两个LCP标识选项。它们都是厂商特定的选项（0x00），用于告诉NAS：客户使用的是Microsoft RAS第4版，计算机名称为ORCH1。注意，这不是客户的用户名。
看过在NAS上成功完成验证时debug ppp negotiation的输出后，来看看验证不成功时该命令的输出，如程序清单2-36所示。
在加黑的第1行，LCP状态变为OPEN，这表明已成功完成LCP协商。然而，PPP进入AUTHENTICATING阶段（加黑的第2行），开始PPP验证。在加黑的第3行，NAS发送一个出站（O）挑战给客户；在加黑的第4行，客户使用一条响应消息来应答NAS的挑战。
同样，NAS对用户名（joebloggs@mjlnet.com）进行分析，并查找与域名mjlnet.com对应的L2F隧道。未能找到对应的隧道后，NAS尝试对客户本身进行验证，但未能成功（如加黑的第5行所示），因此它发送一条CHAP失败消息给客户（如加黑的第6行所示），然后进入PPP TERMINATING阶段（如加黑的第7行所示）。
接下来，客户和NAS交换终止请求（TERMREQ）和终止确认（TERMACK），如加黑的第8～11行所示。顾名思义，TERMREQ消息用于请求拆除连接，而TERMACK用于确认拆除请求。
在加黑的第12行，串行接口0/0:0被断开，然后在加黑的第13行，异步接口38的状态变为down。
PPP验证以失败告终，客户连接被拆除。NAS无法找到与域名mjlnet.com对应的L2F隧道。接下来需要检查VPDN配置，找出问题所在。
程序清单2-37是在NAS上执行命令show running-config得到的输出。注意，这里只列出了相关的输出部分。
正如读者看到的，VPDN组的域名被错误地配置为disco.com。为修正这种错误，可使用程序清单2-38所示的配置。
加黑的第1行表明，建立了一条隧道和一个会话。在加黑的第2～4行，显示了终点网关的名称（PERRIS_HGW）、CLID（15）和IP地址（172.16.2.2）。
2.3.3 排除L2F隧道建立故障
完成LCP协商和部分验证，并找到与域名或DNIS匹配的VPDN组后，NAS便开始建立到终点网关的隧道。
图2.32说明了NAS和终点网关之间的隧道初始化和建立。
讨论L2F隧道建立失败的情况之前，有必要使用命令debug vpdn l2x-events来查看一下隧道建立成功的情况。
程序清单2-40～2-42列出了命令debug vpdn l2x-events的输出。
在程序清单2-40中加黑的第1行，串行接口0/0:0（B信道之一）被连接到远程接入客户（1111）。
终点网关通过了NAS的验证，L2F隧道被建立。
可以使用命令show vpdn tunnel all来核实L2F隧道是否被建立，如程序清单2-43所示。
加黑的第1行表明，建立了一条L2F隧道和一个L2F会话。加黑的第2～4行显示了NAS的名称（LODI_NAS1）、CLID（32）和IP地址（172.16.1.1）；加黑的第5～7行显示了终点网关的名称（PERRIS_HGW1）、CLID（21）和IP地址（172.16.2.2）；加黑的第8行显示了隧道的状态（OPEN）；最后，加黑的第9～12行显示了通过该隧道发送和接收的分组数和字节数。
导致隧道建立失败的原因很多，包括：
没有到终点网关的IP（和L2F）连接性。要检查IP连接性，可使用ping命令。另外，还应确保没有访问列表阻断L2F。L2F使用UDP端口1701。
NAS上配置的终点网关IP地址不正确。要检查NAS上配置的终点网关IP地址是否正确，可查看NAS中为VPDN组配置的命令initiate-to ipHome_Gateway_address，或者查看RADIUS服务器上隧道定义中指定的IP地址。
终点网关不能识别NAS。检查终点网关是否正确地配置为端接从NAS出发的隧道：确保在VPDN组的配置中，用命令terminate-from hostnameNAS_name指定了NAS的名称。
NAS和终点网关的VPND协议不匹配。
隧道验证失败。
本小节将深入探讨如何排除VPDN协议不匹配和隧道验证失败故障。
如果隧道定义存储在AAA服务器中，请参阅2.4.1小节“在AAA服务器上错误地配置了L2F隧道定义”的内容。
1．VPDN协议不匹配
如果NAS和终点网关的VPDN协议不匹配，隧道建立将失败。
要排除VPDN协议不匹配故障，可使用命令debug vpdn l2x-events，如程序清单2-44～2-46所示。
程序清单2-44中加黑的第1和第2行表明，串行接口0/0:0连接到了远程客户1111，异步接口34的状态变成了up。此时，远程接入客户已经连接到了NAS。
在加黑的第3行，NAS打开一条到终点网关的UDP（L2F）连接。NAS发送了一条L2F_CONF消息，虽然在程序清单2-44中没有显示出来。
终点网关没有对NAS的L2F_CONF做出应答，因此NAS再次发送L2F_CONF，如程序清单2-45中加黑的第1行所示。
接下来，NAS发送一条L2F_CLOSE，请求关闭隧道，如程序清单2-46所示。
在程序清单2-46中加黑的第1行，NAS发送一条L2F_CLOSE消息，告诉终点网关自己想终止隧道建立。
在加黑的第2和第3行，异步接口38的状态变为down，串行接口0/0:0与1111（远程接入客户）断开。隧道初始化以失败告终。注意，命令debug vpdn l2x-errors也能显示这种故障。
客户重新连接时，成功地建立了隧道。命令show vpdn tunnel的输出证明了这一点，如程序清单2-49所示。
加黑的第1行表明，建立了一条隧道和一个会话。加黑的第2～5行显示了终点网关的名称（PERRIS_HGW1）、CLID（30）和IP地址（172.16.2.2）。
2．隧道验证失败
在2.1节中指出过，要建立L2F隧道，NAS和终点网关必须通过对方的验证。如果隧道验证失败，将不能成功地建立隧道。
图2.33说明了NAS和终点网关之间的隧道验证。
讨论隧道验证失败的情况之前，有必要再来看一下隧道验证成功时的隧道建立过程。要查看隧道建立过程，可使用命令debug vpdn l2x-events。
程序清单2-50和2-51说明L2F隧道建立过程。
从程序清单2-50中加黑的第1行可知，NAS打开了一个连接到172.16.2.2（终点网关）的UDP端口（1701）。一条L2F_CONF消息被发送到终点网关，虽然程序清单2-50中没有显示出来。
有必要再次重申的是，该L2F_CONF消息包含一个32位的随机数挑战以及其他信息。
从加黑的第2行可知，NAS收到了一条L2F_CONF消息。该消息中也包含一个32位的随机数挑战。
在程序清单2-51中加黑的第1行，NAS发送一条L2F_OPEN消息给终点网关。该消息包含一个散列值，后者是根据从终点网关收到的L2F_CONF（参见程序清单2-50中加黑的第2行）中的随机数以及NAS中配置的隧道密码计算得到的。
在加黑的第2行，NAS从终点网关那里收到了一条L2F_OPEN消息。该消息很重要，其功能有两个。首先，它表明终点网关根据收到的散列值成功地验证了NAS；其次，它包含终点网关根据NAS发送的随机数（包含在程序清单2-50中加黑的第1行的L2F_CONF中）和终点网关上配置的隧道密码计算得到的散列值。此时，NAS通过了终点网关的验证，但NAS还没有对终点网关进行验证。
在加黑的第3行，NAS报告会话状态已经从关闭（closed）切换到正在打开（opening）。这意味着终点网关已经通过了NAS的验证，隧道已经建立。
如果读者感到有些迷惑，请复习一下2.1.2小节的内容。
至此，读者知道了L2F隧道验证成功时的情况，但验证失败时情况将如何呢？同样，在这种情况下，也可以使用命令debug vpdn l2x-events来查看隧道建立过程。
程序清单2-52～2-54是隧道验证失败时命令debug vpdn l2x-events的输出。
在程序清单2-52中加黑的第1和第2行，串行接口0/0:0已连接到1111，异步接口36的状态变为up。这表明远程接入客户已连接到NAS。
加黑的第3行表明，打开了一个连接到终点网关的UDP套接字，并向终点网关发送了一条L2F_CONF消息。
NAS向终点网关发送一条L2F_OPEN消息（程序清单2-53中加黑的第1行）。该消息包含对终点网关通过L2F_CONF（程序清单2-52中加黑的第4行）发送的挑战的应答（MD5散列值）。
从加黑的第2行可知，NAS发送了一条L2F_OPEN消息给终点网关。终点网关本应用L2F_OPNE进行应答，但NAS什么也没有收到。
NAS终止隧道建立过程，如程序清单2-54所示。
NAS发送一条L2F_CLOSE消息给终点网关（程序清单2-54中加黑的第1行），该消息指出NAS要终止隧道建立过程。
最后，在加黑的第2和第3行，串行接口0/0:0与1111断开，异步接口36的状态变为down。隧道建立以失败告终。
下面来看看NAS再次试图建立隧道时，终点网关上发生的情况。
要查看隧道建立错误，可使用命令debug vpdn l2x-error。
程序清单2-55是NAS再次试图建立隧道时命令debug vpdn l2x-error的输出。
在加黑的第1行，终点网关指出它收到了一个L2F分组，其中包含一个伪造的验证密钥。这个分组是来自NAS的L2F_OPEN。
在加黑的第2行，终点网关再次向NAS发送一条L2F_CONF消息。这表明对于终点网关的挑战，NAS的验证响应不正确。这意味着只有一种可能：NAS和终点网关上配置的隧道密码肯定不一致。
在NAS和终点网关上都配置了命令service password-encryption，因此无法确定那里的隧道密码配置得是否正确。所以，只能在NAS和终点网关上重新配置隧道密码，如程序清单2-56所示。
客户重新连接时，将成功建立L2F隧道。这可以使用命令show vpdn tunnel all来证明。
程序清单2-57是命令show vpdn tunnel all的输出。
加黑的第1行表明，已经建立了一条隧道和一个会话；加黑的第2～4行显示了终点网关的名称（PERRIS_HGW1）、CLID（31）和IP地址（172.16.2.2）。
2.3.4 排除L2F会话建立故障
建立隧道后，便开始建立会话，如图2.34所示。
介绍L2F会话建立失败时的情况之前，先使用命令debug vpdn l2x-events来看一下成功建立会话时的情况。
程序清单2-58是成功建立L2F会话时debug vpdn l2x-evnets的输出。注意，这里只列出了相关的部分。
在程序清单2-58中加黑的第1行，NAS发送一条L2F_OPEN消息来发起会话建立。终点网关用一条L2F_OPEN消息进行应答（加黑的第2行），会话状态从正在打开（opening）变成打开（open），如加黑的第3行所示。至此，客户会话便建立了。
消息L2F: MID synced NAS/HG Clid=35/24 Mid=23（加黑的第4行）表明，NAS和终点网关分别将隧道的CLID指定为35和24，该会话的MID为23。现在，NAS可以通过隧道在终点网关和客户之间转换PPP帧了。
也可以使用命令show vpdn session来核实是否成功地建立了L2F会话，如程序清单2-59所示。
加黑的第1行显示了CLID、MID、与会话相关联的用户名、客户连接到的接口以及会话状态。
导致会话建立失败的最常见原因是配置了会话数限制或VPDN软关闭（softshut）功能。本小节将讨论这种问题。要排除这种故障，首先应执行命令debug vpdn l2x-errors。
程序清单2-60～2-62是命令debug vpdn l2x-errors的输出。
异步接口38的状态变为down（程序清单2-62中加黑的第1行），串行接口0/0:0与1111断开。L2F会话建立以失败告终，客户被断开。
程序清单2-61中加黑的第1行指出了会话建立失败的原因。输出WHY: 0x2000, STR:表明，加黑的第1行中的L2F_CLOSE包含子选项L2F_CLOSE_WHY和L2F_CLOSE_STR（参见表2.2）。
L2F_CLOSE_WHY包含会话关闭的原因编码，这里为0x2000。从表2.3可知，该编码表示已达到会话数限制或配置了VPDN软关闭功能。
L2F_CLOSE_STR是隧道或会话被关闭的原因的ASCII描述，这里没有ASCII描述。
确定会话关闭的原因后，通过查看终点网关的配置可找出问题的根源，如程序清单2-63所示。
从加黑的第1行可知，建立了一条隧道，更重要的是，现在建立了两个会话。加黑的第2～4行显示了终点网关的名称、CLID和IP地址。问题得到了圆满解决。
正如前面指出的，命令vpdn softshut也可能导致会话建立失败。网络管理员可以使用命令vpdn softshut来禁止新建到终点网关的会话，同时允许已有的会话继续运行，直到被正常关闭（如客户拆除连接）为止。这样可以妥善地关闭隧道。删除命令vpdn softshut（使用no vpdn softshut）后，便允许建立新的会话。
2.3.5 终点网关/远程接入客户PPP协商失败
建立L2F隧道和会话后，接下来需要在终点网关完成PPP协商。具体地说，必须进行LCP协商、PPP验证和NCP协商。
终点网关要完成PPP协商，必须根据虚拟模板克隆一个虚拟接入接口。该虚拟接口用于端接从远程客户出发的客户PPP连接。
因此，在终点网关上排除PPP协商故障之前，首先需要确定虚拟模板的配置被正确地克隆给虚拟接入接口。
图2.35说明了将虚拟模板的配置克隆给虚拟接入接口。
要核实虚拟模板的配置是否被正确地克隆给虚拟接入接口，可使用命令debug vtemplate，如程序清单2-66所示。
加黑的第1行表明，虚拟模板的配置将被克隆给虚拟接入接口1。加黑的第2～7行表明，配置被准确地克隆给该虚拟接入接口。然后，该虚拟接入接口的状态变为up（加黑的第8行）。最后，在加黑的第9行，虚拟接入接口的线路协议状态变为up。配置被成功地克隆给虚拟接入接口。
如果未能将任何配置克隆给虚拟接入接口，可使用命令show running-config来核实在VPND组配置中是否正确地指定了虚拟模板，如程序清单2-67所示。
在这个例子中，在VPDN组配置中正确地指定了虚拟模板。
如果将用户特定的配置存储在AAA服务器中，排除PPP协商故障时一定要确保该配置正确且被下载到终点网关中。确定用户特定的配置是否被下载时，一个很有用的命令是debug aaa per-user。
1．LCP协商或PPP验证失败
将虚拟模板的配置克隆给虚拟接入接口后，终点网关将尝试与远程客户进行LCP协商和PPP验证。
图2.36说明了客户和终点网关之间的LCP协商和PPP验证阶段。
要查看PPP协商过程（包括LCP协商和PPP验证），可在终点网关上执行命令debug ppp negotiation。
介绍LCP协商或PPP验证失败时的情况之前，有必要看一下LCP协商和PPP验证成功时的情况（参见程序清单2-68～程序清单2-71）。
在程序清单2-70中加黑的第1行，终点网关处理入站的FORCED CONFACK。同样，这也不是直接从客户那里收到的，而是在L2F会话建立期间，NAS转发的一个CONFACK（L2F_ACK_LCP2）。这是与远程客户协商LCP期间，NAS发送的LCP CONFACK。
LCP协商到此结束，开始PPP验证，如程序清单2-71所示。
在程序清单2-71中加黑的第1行，进入PPP AUTHENTICATING阶段，表明PPP验证即将开始。在加黑的第2行，终点网关向客户发送一个CHAP挑战。客户以一条响应消息应答（加黑的第3行）。在加黑的第4行，终点网关向客户发送一条成功消息。终点网关上的LCP协商和PPP验证获得成功。
在加黑的第1行，PPP切换到TERMINATING阶段，即将开始拆除PPP连接。在加黑的第2～5行，终点网关和客户交换TERMREQ和TERMACK消息；在加黑的第6行，PPP切换到DOWN阶段。最后，在加黑的第7行，虚拟接入接口的状态变为down。
PPP验证失败，客户的连接被拆除。这表明在终点网关或客户端配置的客户的用户名或密码不正确。在这个例子中，客户确定其使用的用户名和密码是正确的，因此在终点网关上，用户名和密码中肯定有一个配置得不正确。
在终点网关上，重新配置客户的用户名和密码，如程序清单2-74所示。
加黑的第1行表明，用户joebloggs@mjlnet.com与虚拟接入接口1相连，该接口在通过L2F运行PPP服务。
从加黑的第2行可知，与远程接入客户协商了LCP、CHAP和IPCP。注意，没有同客户协商多链路PPP（MP），因此它处于关闭（closed）状态。至此，问题得到了圆满解决。
注意，也可以使用命令debug ppp authentication来查看PPP验证情况。
在终点网关上核实PPP验证时，需要检查的另一项内容是，客户是否试图验证终点网关。如果使用的是CHAP验证，应检查是否有从客户那里收到的入站（I）CHAP挑战消息。如果收到了CHAP挑战消息，应重新配置客户，使之不验证终点网关。
另外，如果使用了AAA服务器，请参阅2.4.1小节有关“对远程接入客户的远程AAA（RADIUS）验证失败”和“对远程接入客户的远程AAA（RADIUS）授权失败”的内容。
最后，需要指出的是，如果终点网关没有接受NAS传递给它的LCP消息（L2F_REQ_LCP0和L2F_ACK_LCP2）中的选项（参见程序清单2-69和2-70），您将看到一条类似于这样的消息：PPP LCP not accepting rcv CONFACK，这表明LCP协商失败。在这种情况下，一种解决方案是，在VPDN组配置中使用命令lcp renegotiation {always |on-mismatch}，让终点网关同远程客户重新协商LCP。
2．NCP协商失败
终点网关完成与远程接入客户的LCP协商和PPP验证后，便开始NCP协商。如果在虚拟模板接口上网络层配置不正确，NCP协商可能失败。
图2.37说明了客户和终点网关之间的NCP协商。
介绍NCP协商失败时的情况之前，有必要看一下终点网关和客户之间成功完成NCP协商的过程。要查看终点网关和客户之间的NCP协商过程，可使用命令debug ppp negotiation。
程序清单2-76～2-88是NCP协商成功时命令debug ppp negotiation的输出，这里只列出了相关的输出部分。
程序清单2-80中来自客户的IPCP CONFREQ请求Van Jacobson压缩（选项0x02）、一个IP地址（选项0x03）以及主和辅助DNS和WINS服务器的地址（选项分别为0x81、0x82、0x83和0x84）。
接下来，终点网关在响应客户的请求时从地址池中获得了一个IP地址，如程序清单2-81所示。
接下来，终点网关用一条CONFACK消息确认客户的IP地址和主DNS服务器的地址，如程序清单2-87所示。
程序清单2-87 终点网关确认客户的IP地址和主DNS服务器的地址
NCP协商成功完成。
注意，在这个例子中，IP是终点网关和客户端配置的惟一一种网络层协议。如果还配置了其他网络层协议，如IPX，将分别协商它们的NCP。
看了终点网关和客户之间成功地完成NCP协商的过程后，下面看一下NCP协商失败时的情况。
这里也使用命令debug ppp negotiation来查看NCP协商过程。程序清单2-89～2-94是命令debug ppp negotiation的输出，注意，其中只列出了相关的输出部分。
终点网关拒绝使用IPCP配置后，形势便急转直下。
在程序清单2-94中，远程接入客户的连接被拆除。
在程序清单2-94中加黑的第1行，虚拟接入接口的状态变为down；在加黑的第2行，PPP切换到TERMINATING阶段，这表明终点网关要拆除客户的连接。最后，在加黑的第3行，PPP切换到DOWN阶段。客户连接被拆除。问题出在哪里呢？
答案在程序清单2-93中。在NCP协商过程的这个位置，终点网关拒绝使用IPCP配置。终点网关拒绝使用IPCP配置的原因只有一个：没有在虚拟模板接口上配置IP地址。
下面使用命令show running-config查看虚拟模板的配置，如程序清单2-95所示。注意，这里只列出了相关的输出部分。
加黑的第1行表明，用户joebloggs@mjlnet.com连接到了虚拟接入接口1，该接口通过L2F运行PPP服务。
加黑的第2行表明，成功地同客户协商了LCP、CHAP和IPCP。另外请注意，没有协商多链路PPP（MP），因此它处于关闭（Closed）状态。问题解决了。
需要指出的另一点是，仅仅因为未能成功地协商IPCP，客户（包括Cisco路由器）并不一定会终止连接。要查看连接的状态，可使用命令show caller user或show interface virtual-access。