标签归档：pap

网络生活-技术及随笔

PPPOE ON CISCO ISR 871W 以及DEBUG输出分析

留下评论

周末的时候翻出来了一台Cisco 871W 路由器，为了榨干闲置设备的每一份能力，我用这个设备替代了家里的一台家用级小路由器实现了PPPoE 接IPv4 + Tunnel Broker方式接入 IPv6 + 多SSID WiFi。

本文记录的是这个小方案的第一部分，实现PPPoE拨号（以及对PPPoE过程的一些研究），后续几天空闲时再继续写后面的部分。

871W是一台相对老的路由器（已经停售），但是本文中用的软件是相对比较新的IOS15.1，配置命令对其他使用IOS15的ISR路由器可以作为参照。

➡  *本文(以及本blog中其他正文部分文字)涉及内容仅代表个人，与公司及日常工作完全无关。

总体想要达到的目标

  • PPPoE拨号连接到Internet （本文）
  • 保证IPv4 到互联网的连通 (对内网做DHCP，在出口做NAT) （已实现，待续）
  • 多SSID 提供WiFi接入，以便将家里的实验设备和日常设备分开 （已实现，待续）
  • 通过tunnel broker实现IPv6接入， 包括WiFi也要有IPv6支持 （已实现，待续）
  • 对IPv6 提供基本的安全保护，禁止外界访问内部的IPv6地址 （已实现，待续）
  • 其他企业级设备能支持但是家用级设备不支持的功能…… （待开发……）

使用的设备

Cisco ISR 871W 路由器，软件版本Cisco IOS Software 15.1(4)M8

拓扑及连线

非常简单，就不画图了，871W上的Fa4 (WAN口)连接 ONU的一个以太口，Fa0口连接家里的PC。

设备配置

用ISR路由器实现PPPoE拨号

注意：我用的ISP服务是包月的，因此完全没有考虑“不用时”自动断线的问题。

参考Configuring PPP over Ethernet with NAT，但是由于我使用的IOS是15.1版，因此命令有些细微却别，比如我完全没有做vpdn-group那部分。

配置如下，Fa4口为WAN口连光猫(ONU)：

interface FastEthernet4
 no ip address
 duplex auto
 speed auto
 pppoe-client dial-pool-number 1 dial-on-demand
 no cdp enable
!

interface Dialer0
 ip address negotiated
 ip mtu 1492
 encapsulation ppp
 dialer pool 1
 dialer-group 1
 ppp pap sent-username <username> password 0 <mypassword>
 no cdp enable
!

上面配置是通过pap方式发送PPPoE的用户名密码，实测北京联通的光纤接入可用。用chap方式倒是不行，推测应与ISP那端的设置有关（后面通过debug命令得到了证实）。

接通之后执行”show interface dialer 0″可以up/up状态，并能看到获取的IP。

jsr#show int dialer 0
Dialer0 is up, line protocol is up (spoofing)
 Hardware is Unknown
 Internet address is <some ip>/32
……

对PPPoE更多的一些探索及debug命令

如果好奇PPP的认证过程，可以试试看”debug ppp authentication“命令，想看看PPP的协商过程可以用”debug ppp negotiation”。

注意：生产网慎用debug命令，自己自学（折腾）就多看看debug命令的输出吧…… LCP和NCP (IPCP)到底都做了些什么，在debug的输出里面看的很清楚。

有两篇文档可以作为辅助，以便更容易的读懂debug的输出：

  1. Troubleshooting PPP (CHAP or PAP) Authentication
  2. Understanding debug ppp negotiation Output

执行”clear ppp all”命令可以强制打断并重建PPPoE连接。

首先想看看研究一下为啥chap失败，执行debug ppp negotitation之后再执行”clear ppp all”得到了一堆的输出，摘录一段在这里：

.May 6 16:21:06.558: PPP: Alloc Context [851CAE40]
.May 6 16:21:06.558: ppp96 PPP: Phase is ESTABLISHING
.May 6 16:21:06.558: Vi1 PPP: Using dialer call direction
.May 6 16:21:06.558: Vi1 PPP: Treating connection as a callout
.May 6 16:21:06.558: Vi1 PPP: Session handle[FE000022] Session id[96]
.May 6 16:21:06.558: Vi1 LCP: Event[OPEN] State[Initial to Starting]
.May 6 16:21:06.558: Vi1 LCP: O CONFREQ [Starting] id 1 len 15
.May 6 16:21:06.558: Vi1 LCP: AuthProto CHAP (0x0305C22305)
.May 6 16:21:06.558: Vi1 LCP: MagicNumber 0x2C9EB206 (0x05062C9EB206)
.May 6 16:21:06.562: Vi1 LCP: Event[UP] State[Starting to REQsent]
.May 6 16:21:06.586: Vi1 LCP: I CONFREQ [REQsent] id 1 len 10
.May 6 16:21:06.586: Vi1 LCP: MagicNumber 0xB43B2631 (0x0506B43B2631)
.May 6 16:21:06.586: Vi1 LCP: O CONFACK [REQsent] id 1 len 10
.May 6 16:21:06.586: Vi1 LCP: MagicNumber 0xB43B2631 (0x0506B43B2631)
.May 6 16:21:06.586: Vi1 LCP: Event[Receive ConfReq+] State[REQsent to ACKsent]
.May 6 16:21:06.586: Vi1 LCP: I CONFREJ [ACKsent] id 1 len 9
.May 6 16:21:06.586: Vi1 LCP: AuthProto CHAP (0x0305C22305)
.May 6 16:21:06.586: Vi1 LCP: O CONFREQ [ACKsent] id 2 len 15
.May 6 16:21:06.586: Vi1 LCP: AuthProto CHAP (0x0305C22305)
.May 6 16:21:06.586: Vi1 LCP: MagicNumber 0x2C9EB206 (0x05062C9EB206)
.May 6 16:21:06.586: Vi1 LCP: Event[Receive ConfNak/Rej] State[ACKsent to ACKsent]
.May 6 16:21:06.586: Vi1 LCP: I TERMREQ [ACKsent] id 4 len 4
.May 6 16:21:06.586: Vi1 LCP: O TERMACK [ACKsent] id 4 len 4
.May 6 16:21:06.590: Vi1 LCP: Event[Receive TermReq] State[ACKsent to REQsent]
.May 6 16:21:06.590: %DIALER-6-UNBIND: Interface Vi1 unbound from profile Di0
.May 6 16:21:06.590: Vi1 PPP: Block vaccess from being freed [0x10]
.May 6 16:21:06.594: Vi1 PPP DISC: PPP Renegotiating
.May 6 16:21:06.594: PPP: NET STOP send to AAA.
.May 6 16:21:06.594: Vi1 LCP: Event[DOWN] State[REQsent to Starting]
.May 6 16:21:06.594: Vi1 PPP: Unlocked by [0x10] Still Locked by [0x0]
.May 6 16:21:06.594: Vi1 PPP: Free previously blocked vaccess
.May 6 16:21:06.594: Vi1 PPP: Phase is DOWN

参考Understanding debug ppp negotiation Output这里可以知道PPP的协商过程是如下图所示：

PPP phase transitions
PPP phase transitions

上面debug输出的就是Establishing到Down的这段，原因其实就是LCP协商失败。

上面输出比较重要的两段单独拿出来看看：

.May 6 16:30:48.539: Vi1 LCP: I CONFREQ [ACKrcvd] id 2 len 18
.May 6 16:30:48.539: Vi1 LCP: MRU 1492 (0x010405D4)
.May 6 16:30:48.539: Vi1 LCP: AuthProto PAP (0x0304C023)
.May 6 16:30:48.539: Vi1 LCP: MagicNumber 0xF5FD2887 (0x0506F5FD2887)
.May 6 16:30:48.539: Vi1 LCP: O CONFNAK [ACKrcvd] id 2 len 13
.May 6 16:30:48.539: Vi1 LCP: MRU 1500 (0x010405DC)
.May 6 16:30:48.539: Vi1 LCP: AuthProto CHAP (0x0305C22305)

” I CONFREQ”是ISP那边送来的，大概意思就是说我要用PAP方式做验证好不好？MTU是1492。”O CONFNAK”是我的router在说”我要用CHAP做验证，MTU 1500″。而且这个过程在不断重复，这要是在现实生活中估计俩人早就该打起来了……好在对”Magic Number”两边还是能好好的协商的……

在经过多次之后失败后（我这里看到的是15次）debug输出中会出现这样一句：

.May 6 16:31:12.759: Vi1 LCP: Sent too many CONFNAKs. Switch to CONFREJ
.May 6 16:31:12.759: Vi1 LCP: O CONFREJ [ACKrcvd] id 7 len 12
.May 6 16:31:12.759: Vi1 LCP: MRU 1492 (0x010405D4)
.May 6 16:31:12.759: Vi1 LCP: AuthProto PAP (0x0304C023)

如果说”CNFNAKs”是路由器“稍显含蓄”的表达对部分协商的内容拒绝且我同意的方式是下面的，你看看如何；那”CONFREJ”表示路由器“真急了”，直接说对下面这些你说的我不同意。

根据上面看到的结果，乖乖的把验证方式修改成pap，然后再看看debug的输出：

.May 6 17:11:44.174: Vi1 LCP: Event[Receive ConfAck] State[REQsent to ACKrcvd]
.May 6 17:11:46.159: Vi1 LCP: O CONFREQ [ACKrcvd] id 3 len 10
.May 6 17:11:46.159: Vi1 LCP: MagicNumber 0x2CCCFF0F (0x05062CCCFF0F)
.May 6 17:11:46.159: Vi1 LCP: Event[Timeout+] State[ACKrcvd to REQsent]
.May 6 17:11:46.159: Vi1 LCP: I CONFACK [REQsent] id 3 len 10
.May 6 17:11:46.159: Vi1 LCP: MagicNumber 0x2CCCFF0F (0x05062CCCFF0F)
.May 6 17:11:46.159: Vi1 LCP: Event[Receive ConfAck] State[REQsent to ACKrcvd]
.May 6 17:11:47.115: Vi1 LCP: I CONFREQ [ACKrcvd] id 2 len 18
.May 6 17:11:47.115: Vi1 LCP: MRU 1492 (0x010405D4)
.May 6 17:11:47.115: Vi1 LCP: AuthProto PAP (0x0304C023)
.May 6 17:11:47.115: Vi1 LCP: MagicNumber 0xF9D28078 (0x0506F9D28078)
.May 6 17:11:47.115: Vi1 LCP: O CONFNAK [ACKrcvd] id 2 len 8
.May 6 17:11:47.115: Vi1 LCP: MRU 1500 (0x010405DC)
.May 6 17:11:47.115: Vi1 LCP: Event[Receive ConfReq-] State[ACKrcvd to ACKrcvd]
.May 6 17:11:47.119: Vi1 LCP: I CONFREQ [ACKrcvd] id 3 len 18
.May 6 17:11:47.119: Vi1 LCP: MRU 1500 (0x010405DC)
.May 6 17:11:47.123: Vi1 LCP: AuthProto PAP (0x0304C023)
.May 6 17:11:47.123: Vi1 LCP: MagicNumber 0xAD3A4DCE (0x0506AD3A4DCE)
.May 6 17:11:47.123: Vi1 LCP: O CONFACK [ACKrcvd] id 3 len 18
.May 6 17:11:47.123: Vi1 LCP: MRU 1500 (0x010405DC)
.May 6 17:11:47.123: Vi1 LCP: AuthProto PAP (0x0304C023)
.May 6 17:11:47.123: Vi1 LCP: MagicNumber 0xAD3A4DCE (0x0506AD3A4DCE)
.May 6 17:11:47.123: Vi1 LCP: Event[Receive ConfReq+] State[ACKrcvd to Open]
.May 6 17:11:47.151: Vi1 PPP: No authorization without authentication
.May 6 17:11:47.151: Vi1 PPP: Phase is AUTHENTICATING, by the peer
.May 6 17:11:47.151: Vi1 PAP: Using hostname from interface PAP
.May 6 17:11:47.151: Vi1 PAP: Using password from interface PAP
.May 6 17:11:47.151: Vi1 PAP: O AUTH-REQ id 1 len 19 from "<username>"
.May 6 17:11:47.151: Vi1 LCP: State is Open
.May 6 17:11:47.163: Vi1 PAP: I AUTH-ACK id 1 len 36 msg is "Authentication success,Welcome!"
.May 6 17:11:47.167: Vi1 PPP: Queue IPCP code[1] id[1]
.May 6 17:11:47.171: Vi1 PPP: Phase is ESTABLISHING, Finish LCP
.May 6 17:11:47.171: Vi1 PPP: Phase is UP

这回协商的过程就客气多了，先是两边统一好了magic number（部分debug输出过程省略），之后的“对话过程如下”：

  1. ISP那边的设备说“MRU 1492， PAP验证 magic number是…”
  2. 我这边的路由器回答“部分不同意(CONFNAK)，MRU 1500如何？”
  3. ISP那边的设备说”MRU 1500， PAP验证，magic number是…”
  4. 我这边的路由器确认方案（CONFACK)并复述了一遍方案

再之后进入了进入”AUTHENTICATING”状态，使用配置好的用户名密码做了身份验证，收到确认后就进入到了”UP”状态了。

再往后就是NCP （IPCP）协商阶段，从ISP那边拿到IP地址等参数了。

对配置的进一步的小改进-调整MTU

如果想要在LCP协商过程中直接接受ISP那边提出的MRU，那么可以在dailer接口下设置 “ppp mtu adaptive”，那么LCP协商阶段就会减少一次“讨价还价”，直接按ISP那边提供的MRU 1492。debug输出如下（完全没有协商使用1500的过程）：

.May 6 18:19:44.429: Vi1 LCP: I CONFREQ [ACKrcvd] id 2 len 18
.May 6 18:19:44.429: Vi1 LCP: MRU 1492 (0x010405D4)
.May 6 18:19:44.429: Vi1 LCP: AuthProto PAP (0x0304C023)
.May 6 18:19:44.429: Vi1 LCP: MagicNumber 0x8816C41F (0x05068816C41F)
.May 6 18:19:44.429: Vi1 LCP: O CONFACK [ACKrcvd] id 2 len 18
.May 6 18:19:44.429: Vi1 LCP: MRU 1492 (0x010405D4)
.May 6 18:19:44.429: Vi1 LCP: AuthProto PAP (0x0304C023)
.May 6 18:19:44.429: Vi1 LCP: MagicNumber 0x8816C41F (0x05068816C41F)

然后Dialer接口 上设置ip mtu 1492 （前面其实已经设置了），对内的接口上设置“ip tcp adjust-mss 1452”，具体原因可以参考这里：Cisco IOS IP Application Services Command Reference

实际测试时，我使用的北京联通的网络看似是接受1500的，不修改成1492没有影响我上网使用。仅供参考。