10年CCIE纪念,反思及展望

CCIE 10 years

CCIE #17564 Kang Liu

前几天考完了CCIE的笔试做重认证,今天登陆CCIE portal看到可以使用这个可以给“老人”用的新的logo了。是啊,已经10年了……

又读了一遍10多年前写的那一系列文章:

从2005年开始定了目标,2006-2007年一共考了2个笔试,4次lab,最终拿到了2个CCIE认证。那时候除了每天的日常工作和网络改造项目可以作为实践准备之外,又花了上千小时的时间去学习和做实验。

看着那些文章,回忆起来10年前的那一段学习和考试的经历就好像一段梦一样,那时候可以很专注的学习、练习,即使中途遇到了失败和挫折也能很快爬起来继续努力。

拿到CCIE认证只是努力之后结果,10年之后再回忆起来,我真的很享受那个学习和准备的过程,有谁不愿意能专注的去完成好一件自己喜欢去做的而且自己又觉得有意思的事情呢?

10年之后的我,工作和10年前几乎完全不同了。现在的工作是产品经理,产品经理更多的要解决的是人的问题。相对于人的问题,技术问题通常更容易解决吧!不过不可否认,技术背景对我现在的工作还是非常有帮助的——能理解客户和研发讲的那些技术术语,能更清楚的了解并沟通客户的需求(只要时间足够并且目标已经达到了,想谈产品就谈产品,想谈技术就谈技术,我才不绕圈呢),甚至偶尔还可以给研发讲讲某个技术到底是怎么回事(其实除了“老技术”之外,很多新技术我也是被问到了才现学的,但是有了之前的知识储备,我理解的就能比你快,而且也有信心给你讲明白,嘿嘿)。

嘚瑟和纪念的话就写这么多,再写下一些反思和展望。

以前在准备CCIE的时候,曾经在NetPro论坛上看到过这样的一段话,也写下了 Be a real CCIE这个帖子

In most situations, when someone obtain a CCIE, it tells me that person is willing to go through the pain and sacrifice to obtain this achievement and therefore, deserve a lot of my respect

10年前的我,也许没有完全理解这段话,或多或少的只关注到了那些技术和所谓pain and sacrifice。

现在再反思一下10年前的那段经历,除去学习知识之外,更多的是自己主动的走出了所谓的”舒适区/comfort zone”,去挑战自我并创造了更多更大的机会。

10年之前的我想不到10年之后现在自己做的这份工作。再过10年的我呢? CCIE 10年只是个开始,写篇文章小小的记录和庆祝一下,再出发吧!

用vba批量调整word文件的字体

其实是年前遇到的破事,现在终于有时间记录一下是怎么解决的了。

遇到的问题:一大堆的.docx文件用了莫名其妙的中文字体,造成所有中文字都挤在一起,根本没法看。

处理方法:设定文件字体为宋体,并且将字体嵌入到文件中。顺便调整一下章节前后的空白。

由于文件数量比较多,实在是懒得一个一个去手工处理,于是想起了很多年前玩过的“宏/macro”。以下是代码,如果有需要随意拿走用。这段宏代码会处理目录下所有的文件,将正文、页眉页脚字体都设置为宋体,并且去掉段落前后的空白。

 

 

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):

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

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

对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”得到了一堆的输出,摘录一段在这里:

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

PPP phase transitions
PPP phase transitions

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

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

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

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

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

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

这回协商的过程就客气多了,先是两边统一好了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的过程):

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

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

【BASH SCRIPT】在树莓派上用HC-SR501红外感应器触发USB摄像头拍照

5-1假期闲的没事继续折腾树莓派。这次是尝试模拟一个防盗报警器,用HC-SR501 被动红外动作感应器 (Passive Infrared/PIR motion sensor)来触发USB camera拍照。大概的思路就是如果被动红外动作感应器被触发时,则调用USB摄像头连续拍照N次。

使用的设备:

  • 树莓派
  • HC-SR501 被动红外动作感应模块 (工作电压5V,信号输出未触发0V ,触发时3.3V)
  • USB摄像头 (我使用的是Logitech C920,其实完全不用这么高端的……)
  • LED x1
  • 470Ω 电阻 (与LED串联作为保护)
  • 杜邦线
  • 面包板

物理连线

连线之前的考虑:

  1. 许多传感器都没有电源接反的保护,接之前请务必再三确认正确再连接。
  2. 不同设备的数据输出不一定是3.3V的,有些有可能用5V表示1。我是先用万用表又验证了HC-SR501的数据输出是3.3V才敢连接树莓派的GPIO接口的。如果电压不匹配还非要去连接,则行为很可能异常,甚至损坏硬件。

线路连接:

rpi-HC-SR501-300x249
HC-SR501连接树莓派 接线示意图
gpio2_cb
HC-SR501连接树莓派 电路图
  • HC-SR501的电源连接树莓派5V输出,GND连接树莓派的GND,中间的data连接树莓派的GPIO接口,我使用的是11口 (GPIO 17)。
  • USB摄像头连接树莓派的USB接口 (我是实际是连接到USB hub上了)
  • 根据需要有可能要调整HC-SR501上的电位器来调节触发距离和延时
  • 根据需要有可能要调整HC-SR501上的跳线位置来设置允许多次重复触发

检查连线:

目视确认面包线连接正确并且牢固,使用lsusb查看系统是否识别出了USB摄像头,使用 ls /dev/video*  检验USB摄像头的编号。

实现所用的bash脚本

下面脚本其实是通过轮询的方式每间隔1秒(可调)通过sysfs方式查询一下sensor的状态,然后复制sensor状态到另外一个GPIO接口;如果sensor是被触发,则调用fswebcam来实现拍照。

脚本中我尽量将不同功能拆成函数了,尽管这样效率并不是最高的。在init_led和init_sensor函数中,尽管只有1个报警用的LED和1个sensor,我还是用循环的方式去做初始化,这也不是最优的方法。这样做主要是为了以后做多个sensor和多个LED故意预留的。

HC-SR501传感器是通过3.3V输出来表示被触发时的“1”,这个电压驱动LED也足够,我实际测试了,即使不没有树莓派,1个LED连接到HC-SR501的data输出已经可以实现灯光告警,但是在这个时候LED的光线不够亮,而且不连接树莓派也没法去调用USB摄像头拍照了 😕  ……

实验后考虑的改进

  1. 如果不想在屏幕上看到每次拍照时执行的细节,可以考虑为fswebcam加上-q参数,将脚本中的fswebcam命令修改成如下:
  2. 树莓派的SD卡空间有限,图片的贮存位置在脚本中默认写的是/tmp目录,当然通过Linux挂载NFS/Samba (NT Folder)/云端等等对这段脚本而言,都仅仅是在系统中的某个目录。因此这里就没有特别去在图片存储方面再多考虑了,利用Linux系统本身的能力即可实现将存储“网络化/云端化”。
  3. 本文是用bash脚本方式实现功能的,上面代码只是做功能演示,效率并不高。如果用C去写一段代码,当传感器被触发后,用中断的方式触发告警动作可能会是比轮询更好的选择。留待以后有时间再去琢磨。
  4. 这次我使用的HC-SR501 传感器并不足够敏感。做完所有测试之后,我故意试了试从远处以很慢的速度接近传感器,其实只要足够慢是可以不触发报警的……如果真的要用来做防盗报警器,估计还需要用更灵敏的传感器,甚至将不同种类的传感器进行结合使用。总体而言,这其实是一个非常非常简单的实验。这个实验中使用的传感器也应该是几乎最简单最入门的了,只有0(未触发)和1(触发)两个状态。写这个脚本仅是利用树莓派将传感器告警与后续动作连接起来。至于后续动作是亮个LED灯,还是拍照,甚至是打出去电话、记录日志、发短信、带动继电器做通/断电动作等都是可以实现的。等日后有更实际些的应用再看怎么做了。

对比用SHELL SCRIPT和C语言API操作RASPBERRY PI GPIO的速度

对Raspberry Pi的GPIO在shell script里面可以直接用sysfs的方式进行操作,也可以调用gpio命令来进行操作,还可以用API来进行操作。今天做了个实验对比sysfs方式、第三方gpio命令以及C语言API操作对效率的影响。

昨天写的文章里面提到了用GPIO来控制LED灯的显示,今天其实是突发奇想,想看看用第三方gpio命令来操作和直接操作sysfs的效率到底有多大的区别。

物理连线

连线和昨天写的文章里面的连线方法基本一样,只是在GPIO管脚和GND之间跨接了一个可以测频率的万用表(UNI-T UT136D)。

Shell Script 响应速度测试

测试脚本

方法1:直接调用sysfs控制通断

脚本中默认没有注释掉的就是方法1,相当于用下面命令来操作gpio实现让电路通断:

实测频率在1.1kHz左右。目测LED基本感觉不到闪烁。

测试结果照片如下,最后两位数字在不断跳动。

万用表测试GPIO接口频率 (Shell Script)

方法2:用shell脚本中的函数调用sysfs控制通断

相当于用下面命令来通过自定义函数gpio_ben操作gpio,实现电路通断: