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没有影响我上网使用。仅供参考。

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据