了解 debug ppp negotiation 输出

简介

在拨号相关应用程序中，PPP 是最常用的封装类型。PPP 允许点对点通信链路上的两台机器协商用于身份验证、压缩和第 3 层 (L3) 协议（例如 IP）的各种参数。如果两台路由器之间发生 PPP 协商故障，则会导致连接失败。

通过 debug ppp negotiation 命令，可以查看 PPP 协商事务，确定发生错误时的问题或阶段并制定解决方法。不过，您必须先了解 debug ppp negotiation 命令输出。本文提供一套综合方法，帮助您解读 debug ppp negotiation 命令输出。

先决条件

要求

本文读者须符合以下条件：

• 必须在两台路由器的接口上都启用 PPP。发出 encapsulation ppp 命令可实现此目的。

• 发出以下命令，在路由器上启用毫秒时间戳：

  Router(config)# service timestamp debug datetime msec
  

  有关 debug 命令的详细信息，请参阅有关 Debug 命令的重要信息。

注意：除非PPP功能完美下的下层（ISDN、物理接口、拨号线路等），否则两个对等体之间的PPP协商无法启动。例如，如果要在 ISDN 上运行 PPP，则所有 ISDN 层都必须启动；否则 PPP 不会启动。

使用的组件

本文档不限于特定的软件和硬件版本。

规则

有关文件规则的更多信息请参见“ Cisco技术提示规则”。

PPP 协商的各个阶段

链路在 PPP 协商过程中会经历多个阶段，如下表所示。最终结果是 PPP 启动或关闭。

*Mar  3 23:32:50.296: BR0:1 PPP: Phase is DOWN

*Mar  3 23:32:06.884: BR0:1 PPP: Phase is ESTABLISHING

*Mar 3 23:32:06.952: BR0:1 PPP: Phase is AUTHENTICATING

*Mar  3 23:42:53.412: BR0:1 PPP: Phase is UP

*Mar  3 23:43:23.256: BR0:1 PPP: Phase is TERMINATING

^{1. LCP =链路控制协议}

^{2. CHAP =质询握手身份验证协议}

^{3. PAP =密码身份验证协议}

^{4. NCP =网络控制协议}

下图显示了 PPP 阶段转换过程：

PPP 协商数据包：说明

下表对 LCP 和 NCP 协商中所用 PPP 协商数据包进行说明：

^{1. NAK =否定确认}

^{2.确认=确认}

注意：每个对等体都可以发送CONFREQ，其中包含它希望对等体支持的选项或值。这可能会导致在各个方向协商的选项有所不同。例如，一方可能希望对对等体进行身份验证，而另一方可能不希望这样做。

LCP、身份验证和 NCP 阶段

在上述某些 PPP 阶段中，PPP 也会进入如 LCP 协商、身份验证和 NCP 协商等特定阶段。有关详细信息，请参阅 RFC 1548 和 RFC 1661 。

LCP（必经阶段）

LCP 是协商用于建立、配置和测试数据链路连接的参数的阶段。LCP 状态“打开”表示 LCP 成功完成，而 LCP 状态“关闭”表示 LCP 失败。

下图显示了 LCP 握手的概念视图：

LCP 协商还使用一个名为 MagicNumber 的参数，该参数用于确定链路是否环回。检测环回时，将在链路上发送一个随机字符串，如果返回相同的值，则路由器因此确定链路是环回的。

身份验证（默认为可选阶段）

在此阶段，将利用在 LCP 协商中同意使用的身份验证协议（CHAP 或 PAP）执行身份验证。有关 PAP 的信息，请参阅 PPP 口令身份验证协议 (PAP) 的配置与故障排除。

有关 CHAP 的信息，请参阅了解和配置 PPP CHAP 身份验证。

注意：身份验证是可选的，PPP仅在需要进行身份验证时才进入此阶段。

NCP（必经阶段）

此阶段用于建立和配置不同的网络层协议。最常用的 L3 协商协议就是 IP。路由器会交换 IP 控制协议 (IPCP) 消息以协商协议（在此例中为 IP）特定的选项。

RFC 1332 指出 IPCP 将协商两个选项： 压缩和 IP 地址分配。不过，IPCP 也用于传递网络相关信息，例如主和备份 Windows 名称服务 (WINS) 及域名系统 (DNS) 服务器。

协商利用 CONF 消息进行，如本文 PPP 协商数据包：说明部分所述。

利用 debug ppp negotiation 输出进行故障排除

当您查看 debug ppp negotiation 命令输出以进行故障排除时，请遵循以下说明：

1. 确定 debug 命令输出中的阶段转换。确定连接所到达的最远阶段，例如 UP 或 AUTHENTICATING。这可帮助您确定在连接失败时所处的阶段。有关阶段的详细信息，请参阅 PPP 协商阶段部分。

2. 对于出现故障的阶段，请查找指出 LCP、身份验证或 NCP（根据需要）成功的消息：

   • LCP 状态应为打开。也可以查看最后一条传入和传出 CONFACK 消息以验证是否已协商所需的参数。

   • 身份验证应成功进行。如果使用双向身份验证，则每个事务都必须成功。有关对 PPP 身份验证进行故障排除的详细信息，请参阅 PPP（CHAP 或 PAP）身份验证故障排除。

   • IPCP 状态应为打开。验证编址是否正确，以及是否已安装到对等体的路由。

解读 debug ppp negotiation 输出

debug ppp negotiation 命令输出中的大部分行都具有如下特征：

1. 时间戳 — 毫秒时间戳十分有用。有关详细信息，请参阅本文前提条件部分。

2. 接口和接口编号 — 当 debug 连接使用多个连接或者连接通过多个接口转换时，此字段十分有用。例如，某些连接（例如多链路呼叫）最初由物理接口控制，但后来由拨号程序接口或虚拟访问接口控制。

3. PPP 消息类型 — 此字段指示线路是常规 PPP、LCP、CHAP、PAP 还是 IPCP 消息。

4. 消息方向 — I 表示传入数据包，O 表示传出数据包。此字段可用于确定消息是否通过路由器生成或接收。

5. 消息 — 此字段包括正在协商的特定事务。

6. ID — 此字段用于将请求消息与相应响应消息匹配和协调。可以使用 ID 字段使响应消息与传入消息相关联。当 debug 输出中的传入消息和响应相隔较远时，此选项尤为有用。

7. 长度 — 长度字段定义信息字段的长度。此字段对一般故障排除并不重要。

注意：字段4到7可能不会显示在所有PPP消息中，具体取决于消息的用途。

注：此示例说明了字段：

debug ppp negotiation 输出示例

下面对 debug ppp negotiation 命令输出进行了注解说明：

maui-soho-01#debug ppp negotiation
PPP protocol negotiation debugging is on
maui-soho-01#
*Mar  1 00:06:36.645: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up

!--- The Physical Layer (BRI Interface) is up. Only now can PPP !--- negotiation begin.

*Mar  1 00:06:36.661: BR0:1 PPP: Treating connection as a callin
*Mar  1 00:06:36.665: BR0:1 PPP: Phase is ESTABLISHING, Passive Open 
[0 sess, 0 load]

!--- The PPP Phase is ESTABLISHING. LCP negotiation now occurs.

*Mar  1 00:06:36.669: BR0:1 LCP: State is Listen
*Mar  1 00:06:37.034: BR0:1 LCP: I CONFREQ [Listen] id 7 len 17

!--- This is the incoming CONFREQ. The ID field is 7.

*Mar  1 00:06:37.038: BR0:1 LCP:    AuthProto PAP (0x0304C023)
*Mar  1 00:06:37.042: BR0:1 LCP:    MagicNumber 0x507A214D (0x0506507A214D)
*Mar  1 00:06:37.046: BR0:1 LCP:    Callback 0  (0x0D0300)

!--- The peer has requested: !--- Option: Authentication Protocol, Value: PAP !--- Option: MagicNumber (This is used to detect loopbacks and is always sent.) !--- Option: Callback, Value: 0 (This is for PPP Callback; MS Callback uses 6.)

*Mar  1 00:06:37.054: BR0:1 LCP: O CONFREQ [Listen] id 4 len 15

!--- This is an outgoing CONFREQ, with parameters for the peer to implement. !--- Note that the ID Field is 4, so this is not related to the previous !--- CONFREQ message.

*Mar  1 00:06:37.058: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:06:37.062: BR0:1 LCP:    MagicNumber 0x1081E7E1 (0x05061081E7E1)

!--- This router requests: !--- Option: Authentication Protocol, Value: CHAP !--- Option: MagicNumber (This is used to detect loopbacks and is always sent.)

*Mar  1 00:06:37.066: BR0:1 LCP: O CONFREJ [Listen] id 7 len 7

!--- This is an outgoing CONFREJ for message with Field ID 7. !--- This is the response to the CONFREQ received first.

*Mar  1 00:06:37.070: BR0:1 LCP:    Callback 0  (0x0D0300)

!--- The option that this router rejects is Callback. !--- If the router wanted to do MS Callback rather than PPP Callback, it !--- would have sent a CONFNAK message instead.

*Mar  1 00:06:37.098: BR0:1 LCP: I CONFACK [REQsent] id 4 len 15

!--- This is an incoming CONFACK for a message with Field ID 4.

*Mar  1 00:06:37.102: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:06:37.106: BR0:1 LCP:    MagicNumber 0x1081E7E1 (0x05061081E7E1)

!--- The peer can support all requested parameters.

*Mar  1 00:06:37.114: BR0:1 LCP: I CONFREQ [ACKrcvd] id 8 len 14

!--- This is an incoming CONFREQ message; the ID field is 8. !--- This is a new CONFREQ message from the peer in response to the CONFREJ id:7.

*Mar  1 00:06:37.117: BR0:1 LCP:    AuthProto PAP (0x0304C023)
*Mar  1 00:06:37.121: BR0:1 LCP:    MagicNumber 0x507A214D (0x0506507A214D)

!--- The peer has requested: !--- Option: Authentication Protocol, Value: PAP !--- Option: MagicNumber (This is used to detect loopbacks and is always sent.)

*Mar  1 00:06:37.125: BR0:1 LCP: O CONFNAK [ACKrcvd] id 8 len 9

!--- This is an outgoing CONFNACK for a message with Field ID 8.

*Mar  1 00:06:37.129: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)

!--- This router recognizes the option Authentication Protocol, !--- but does not accept the value PAP. In the CONFNAK message, !--- it suggests CHAP instead.

*Mar  1 00:06:37.165: BR0:1 LCP: I CONFREQ [ACKrcvd] id 9 len 15

!--- This is an incoming CONFREQ message with Field ID 9.

*Mar  1 00:06:37.169: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:06:37.173: BR0:1 LCP:    MagicNumber 0x507A214D (0x0506507A214D)

!--- CHAP authentication is requested.

*Mar  1 00:06:37.177: BR0:1 LCP: O CONFACK [ACKrcvd] id 9 len 15

!--- This is an outgoing CONFACK for a message with Field ID 9.

*Mar  1 00:06:37.181: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:06:37.185: BR0:1 LCP:    MagicNumber 0x507A214D (0x0506507A214D)
*Mar  1 00:06:37.189: BR0:1 LCP: State is Open

!--- This indicates that the LCP state is Open.

*Mar  1 00:06:37.193: BR0:1 PPP: Phase is AUTHENTICATING, by both [0 sess, 0 load]

!--- The PPP Phase is AUTHENTICATING. PPP Authentication occurs now. !--- Two-way authentication is now performed (indicated by the both keyword).

*Mar  1 00:06:37.201: BR0:1 CHAP: O CHALLENGE id 4 len 33 from "maui-soho-01"

!--- This is the outgoing CHAP Challenge. !--- In LCP the routers had agreed upon CHAP as the authentication protocol.

*Mar  1 00:06:37.225: BR0:1 CHAP: I CHALLENGE id 3 len 33 from "maui-soho-03"

!--- This is an incoming Challenge message from the peer.

*Mar  1 00:06:37.229: BR0:1 CHAP: Waiting for peer to authenticate first
*Mar  1 00:06:37.237: BR0:1 CHAP: I RESPONSE id 4 len 33 from "maui-soho-03"

!--- This is an incoming response from the peer.

*Mar  1 00:06:37.244: BR0:1 CHAP: O SUCCESS id 4 len 4

!--- This router has successfully authenticated the peer.

*Mar  1 00:06:37.248: BR0:1 CHAP: Processing saved Challenge, id 3
*Mar  1 00:06:37.260: BR0:1 CHAP: O RESPONSE id 3 len 33 from "maui-soho-01"
*Mar  1 00:06:37.292: BR0:1 CHAP: I SUCCESS id 3 len 4

!--- This is an incoming Success message. Each side has !--- successfully authenticated the other.

*Mar  1 00:06:37.296: BR0:1 PPP: Phase is UP [0 sess, 0 load]

!--- The PPP status is now UP. NCP (IPCP) negotiation begins.

*Mar  1 00:06:37.304: BR0:1 IPCP: O CONFREQ [Closed] id 4 len 10
*Mar  1 00:06:37.308: BR0:1 IPCP:    Address 172.22.1.1 (0x0306AC160101)

!--- This is an outgoing CONFREQ message. It indicates that !--- the local machine address is 172.22.1.1.

*Mar  1 00:06:37.312: BR0:1 CDPCP: O CONFREQ [Closed] id 4 len 4
*Mar  1 00:06:37.320: BR0:1 CDPCP: I CONFREQ [REQsent] id 4 len 4
*Mar  1 00:06:37.324: BR0:1 CDPCP: O CONFACK [REQsent] id 4 len 4

!--- These messages are for CDP Control Protocol (CDPCP).

*Mar  1 00:06:37.332: BR0:1 IPCP: I CONFREQ [REQsent] id 4 len 10
*Mar  1 00:06:37.336: BR0:1 IPCP:    Address 172.22.1.2 (0x0306AC160102)

!--- This is an incoming CONFREQ message that indicates that the peer !--- address is 172.22.1.2. An address of 0.0.0.0 indicates that the peer !--- does not have an address and requests the local router to provide it !--- with an address in IPCP negotiation.

*Mar  1 00:06:37.344: BR0:1 IPCP: O CONFACK [REQsent] id 4 len 10
*Mar  1 00:06:37.348: BR0:1 IPCP:    Address 172.22.1.2 (0x0306AC160102)
*Mar  1 00:06:37.356: BR0:1 IPCP: I CONFACK [ACKsent] id 4 len 10
*Mar  1 00:06:37.360: BR0:1 IPCP:    Address 172.22.1.1 (0x0306AC160101)
*Mar  1 00:06:37.363: BR0:1 IPCP: State is Open

!--- The IPCP state is Open. Note that in the IPCP negotiation, each side !--- accepted the IP address of the peer, and one was assigned to the peer.

*Mar  1 00:06:37.371: BR0:1 CDPCP: I CONFACK [ACKsent] id 4 len 4
*Mar  1 00:06:37.375: BR0:1 CDPCP: State is Open

!--- This indicates that the CDPCP state is Open.

*Mar  1 00:06:37.387: BR0 IPCP: Install route to 172.22.1.2

!--- A route to the peer is installed.

*Mar  1 00:06:38.288: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,
 changed state to up
*Mar  1 00:06:42.609: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to
 maui-soho-03

术语表和常见消息

常规

CONFREQ (Configure-Request)：

当较低层变为可用（启动）时，将会发送 CONFREQ 以启动第一个 PPP 阶段（LCP 阶段）。 该消息在 LCP 和 NCP 阶段中用于尝试配置连接。为打开与对等体的连接，设备将传送此消息，同时传送发送者希望对等体支持的配置选项和值。所有选项和值同时进行协商。如果对等体以 CONFREJ 或 CONFNAK 消息进行响应，则路由器会发送带有另一组选项或值的另一个 CONFREQ。

CONFACK (Configure-Acknowledge)：

如果 CONFREQ 消息中的所有选项钧可识别，且所有值钧可接受，则路由器传送 CONFACK 消息。

CONFREJ (Configure Reject)：

如果在 CONFREQ 中收到的某配置选项不可接受或不可识别，则路由器以 CONFREJ 消息进行响应。不可接受的选项（来自 CONFREQ 消息）包含在 CONFREJ 消息中。

CONFNAK (Configure Negative Acknowledge)：

如果收到的配置选项可识别且可接受，但某个值不可接受，则路由器传送 CONFNAK 消息。路由器会在 CONFNAK 消息中附加它能接受的选项和值，以便对等体在下一个 CONFREQ 消息中包含该选项。

ECHOREQ (Echo Request) 和 ECHOREP (Echo Reply)：

为保持连接的完整性，PPP 会使用 Keepalive。这些 Keepalive 是发送给远程 PPP 对等体的 ECHOREQ 帧，远程 PPP 对等体在收到 ECHOREQ 帧后应以 ECHOREP 帧进行响应。默认情况下，如果路由器错过五个 ECHOREP 帧，就会将链路视为关闭，并且 PPP 会断开。

TERMREQ (Termination Request)：

此帧指示发送此帧的 PPP 对等体终止 PPP 连接。

TERMACK (Termination Acknowledge)：

此消息在对 TERMREQ 消息的响应中传送。这会关闭 PPP 连接。

终止

此消息指示 PPP 连接已断开。在以下情况下可切断 LCP 或 NCP 连接：

• 在人为关闭时（仅限 LCP）。

• 在较低层（拨号线路、ISDN 等）停止服务时。

• 在协商失败时。

• 在线路环路检测时。

LCP

ACCM (Asynchronous Control Character Map)：

这是 CONFREQ 帧中 LCP 协商的选项之一。ACCM 用于设置字符转义序列。ACCM 指示端口忽略数据流内的指定控制字符。如果连接另一端的路由器不支持 ACCM 协商，将强制端口使用 FFFFFFFF。在这种情况下，会发出以下命令：

ppp accm match 000a000

ACFC (Address and Control Field Compression)：

ACFC 是一个 LCP 选项，它使终点可以更高效地来回发送信息。

AuthProto (Authentication Protocol)：

AuthProto 是两个 PPP 连接对等体之间在 CONFREQ 帧中协商的身份验证协议类型，供身份验证阶段使用。如果未配置 PPP 身份验证，则不会在 CONFREQ 帧协商的参数中看到此输出。可能值有 CHAP 或 PAP。

回叫“#”：

此消息指示正在协商回拨选项。Callback 语法后面的数字指示协商哪个回拨选项。数字 0 表示正常 PPP 回拨，数字 6 表示 Microsoft 回拨选项（在 Cisco IOS® 软件版本 11.3(2)T 或更高版本中自动可用）。

CHAP (Challenge Handshake Authentication Protocol)：

此消息指示正在协商的身份验证协议是 CHAP。

EndpointDisc (End Point Discriminator)：

这是用于标识 PPP 多链路连接中的 PPP 对等体的 LCP 选项。有关详细信息，请参阅多链路 PPP 捆绑命名标准。

LCP:State is Open

此消息指示 LCP 协商已成功完成。

LQM (Link Quality Monitoring)

LQM 可用于运行 PPP 的所有串行接口。LQM 用于监控链路质量，并在质量降至低于配置的百分比时中断链路。该百分比将针对传入和传出双方向进行计算。传出质量的计算方法是：将发送的数据包和字节总数与对等体收到的数据包和字节总数进行比较。传入质量的计算方法是：将收到的数据包和字节总数与对等体发送的数据包和字节总数进行比较。

启用 LQM 后，将在每个 keepalive 期间发送链路质量报告 (LQR)。发送的 LQR 会代替 keepalive。所有传入 keepalive 都相应得到响应。如果未配置 LQM，则在每个 Keepalive 期间发送 keepalive，并通过 LQR 对所有传入 keepalive 进行响应。

幻数

幻数支持可用于所有串行接口。PPP 总是尝试协商幻数，以用于检测环回网络。检测环回时，将在链路上发送一个随机字符串，如果返回相同的值，则路由器因此确定链路是环回的。

在环回检测时可能会也可能不会中断链路；这取决于是否使用了 down-when-looped 命令。

PAP (Password Authentication Protocol)

此消息指示供 PPP 对等体使用的正在协商的身份验证协议是 PAP。有关 PAP 的详细信息，请参阅 PPP 口令身份验证协议 (PAP) 的配置与故障排除。

PFC (Protocol Field Compression)

此选项打开或关闭协议字段压缩。

MRRU (Max Receive Reconstructed Unit)

这是在 PPP 多链路 LCP 设置过程中协商的 LCP 选项。此选项确定可构成帧的最大字节数。如果未在 LCP 中协商 MRRU，则不能在链路上运行多链路 PPP (MPPP)。

MRU (Maximum Received Unit)

MRU 是在 CONFREQ 帧中协商的 LCP 选项，用于协商所交换数据包的大小。

身份验证

AUTH-REQ (Authentication Request)

此帧从本地 PPP 对等体（在其中启用了身份验证）发送给远程对等体。它要求远程对等体发送一个有效的用户名和口令来进行 PPP 连接身份验证。此帧仅适用于 PAP。

AUTH-ACK (Authentication Acknowledge)

此帧从接受身份验证的 PPP 对等体发送给执行身份验证的 PPP 对等体。此帧携带有效的用户名和口令对。仅当使用 PAP 进行 PPP 连接身份验证时，才使用此帧。

AUTH-NAK 或 FAILURE

当执行身份验证的 PPP 对等体上的身份验证失败时，将从执行身份验证的 PPP 对等体发出此帧。

挑战

这是从执行身份验证的 PPP 对等体发送给接受身份验证的 PPP 对等体的 CHAP 质询帧。该质询帧包括一个 ID，一个随机数，以及本地通信服务器的主机名或远程设备上的用户的名称。仅当使用 CHAP 进行 PPP 连接身份验证时，才使用此帧。

回复

此帧是从接受身份验证的 PPP 对等体发送给执行身份验证的 PPP 对等体的 CHAP 响应。

所需响应包括两部分：

• 共享密钥的 MD5 散列输出。

• 远程设备的主机名或远程设备上的用户的名称。

仅当使用 CHAP 进行 PPP 连接身份验证时，才使用此帧。

NCP

Address a.b.c.d

• 在传出 CONFREQ 消息中，此值指示本地路由器希望使用的 IP 地址。如果包含的地址是 0.0.0.0，则本地机器请求对等体向其提供它可以使用的 IP 地址。

• 在传入 CONFREQ 消息中，此值指示对等体希望使用的 IP 地址。如果包含的地址是 0.0.0.0，则对等体请求本地机器向其提供它可以使用的 IP 地址。

• 在传出 CONFNAK 消息中，此值指示对等体应使用的 IP 地址，而不是对等体在 CONFREQ 消息中建议的 IP 地址。

• 在传入 CONFNAK 消息中，此值指示本地机器应该使用的 IP 地址，而不是它在上一个 CONFREQ 消息中建议的 IP 地址。

• 在传出 CONFACK 消息中，此值指示对等体请求的 IP 地址是本地设备可接受的。

• 在传入 CONFACK 消息中，此值指示本地机器所请求的 IP 地址可由对等体接受。

CCP (Compression Control Protocol)

此消息指示正在两个 PPP 对等体之间协商压缩协议。Cisco IOS 软件支持在 PPP 连接上协商以下压缩协议：

• MS 点对点压缩 (MS-PPC)

• 堆栈

• 预测

CDPCP (Cisco Discovery Protocol Control Protocol)

此消息指示在 NCP 阶段进行 CDP 协商。要在路由器上关闭 CDP，请发出 no cdp run 命令。

CODEREJ (Code Reject)

当从远程 PPP 对等体收到无法解释的数据包时，将发送 CODEREJ 数据包。

Install route to a.b.c.d

路由器在完成 IPCP（IP L3 协议的 NCP 阶段）以后，须在路由表中安装到远程 PPP 对等体的给定 IP 地址，并将该地址视为路由表中的已连接路由。如果未看到此消息，请验证是否未配置 no peer neighbor-route 命令。

IPCP (IP Control Protocol)

此值指示 IP 是 NCP 阶段中正在协商的网络层。

IPCP State is Open

此消息指示 IPCP（IP L3 协议的 NCP 阶段）已成功完成。

PROTREJ (Protocol Reject)

PPP 对等体在收到包含未知协议字段的 PPP 数据包以后，将使用 PROTREJ 消息指示该对等体已尝试使用不支持的协议。PPP 设备在收到 PROTREJ 消息后，必须尽早停止发送指定协议的数据包。

相关信息

• PPP 口令认证协议 (PAP) 的配置与故障排除
• 使用 ppp chap hostname 和 ppp authentication chap callin 命令的 PPP 认证
• 了解和配置 PPP CHAP 认证
• PPP（CHAP 或 PAP）认证故障排除
• 拨号技术支持页
• 技术支持 - Cisco Systems