10G 网络升级(经验教训总结)

前年兼职搞的时候规模还没这么大,整个步骤也很顺利,基本做的就是些插拔网线的操作。这次规模较前年比,已经是翻了几番(30 组机架),不可能再由一人带一实习生这种套路来完成。增加人手首当其冲,所幸,这次升级的人手还是比较充裕的,我们这边包括我在内一个网络工程师,两个运维;我们的服务供应商驻守了两位网络工程师以及若干的布线人员;我们的托管商将驻场的值班工程师由原先的 1 位临时增加到了 5 位。

升级最终的结果当然是成功的,但是中间的过程确是崎岖无比,原本计划从 2 月 18 日 10:00pm 到 19 日 4:00am 6h 的 scheduled downtime 由于遇到了种种事先没有预想到的问被迫被延期到了 20 日的凌晨 3:00am,中间经历了难熬的 30h。

下面先写些"八卦"。
第一天晚上最大的失败就是在升级网络的时候连同服务器也一起带着升级了,其实这是两件事,完全可以独立开来做。最终导致内网任何一点之间的丢包高达 50%,处于完全瘫痪的状态。从拔第一跟网线的 11:00 pm 开始到最后一根网线插上,已经到了 19 日的 7:00am 多,在现场 debug 了 2h 多小时,基本确定是网卡 mode 的问题。
回去休息,感觉基本是锁定了问题所在,起床后在高度兴奋的状态下扫了若干的文档,有九成以上的把握是 bonding mode 的问题。
晚上吃完饭买完能量补给,跟我们的工程师再次亲临现场,花了一个多小时的时间,拿一组整机柜做了实验,100% 确认了是 bonding mode 造成的问题。接下来一直到 3:00am 的这段时间就是一人操作一人配合改完了所有服务器的 bonding mode 以及测试确认,现场还出现了一些人为操作的失误,多花了些时间去排查,如果细心点应该 2 点左右就能结束。
至此,整体框架已经升级完毕,剩下的一些诸如服务器无法启动、路由不通等问题这是后话。

下面逐条总结这次升级终于到的问题以及改进措施,我相信我说的这些绝大多数成长中的公司都应该会遇到,不管是基础网络、系统、上层服务以及面向客户的业务层面。
1. 太过于相信我们的服务供应商的工程师(暂且以 S 表示这个群体)或者说其他人的经验
之前得知 S 处理的项目的经验不少,基本北京这边几个巨头都是他们的客户。最初咨询他们建议使用哪种 bonding mode 时,心安理得没有任何思考以及查证的情况下就相信了他们说的话。而这最终的结论是从哪里来的了?根据 S 的陈述,他们其实也不大了解,转而咨询 A 公司(收购我们的那家)的驻场工程师。当时非常幼稚脑子烧掉的认为这么大的公司都按照这套路来,我们肯定也没问题了。于是我们就是照猫画虎,没理解里面的细节,连 A 那边最基本的环境都不了解,就屁颠屁颠的用上去了,结果可想而知。
不要迷信厂商,厂商里面很少有技术过硬强烈责任感的工程师,大部分的都是油腔滑调满嘴跑火车(Redhat 除外)。我们这次如此不顺利的升级也是过分的听信了厂商的满嘴跑火车。所以,不管什么时候,首先阅读官方文档,这上面的绝大多数内容都是正确的,再配合实际操作。

Continue reading

蹦极

原本以为自己年龄大了,不敢玩这些「刺激」的活动了,可是在自己一颗按耐不住热血沸腾的小心肝再加上同事怂恿的驱使下,我还是站在了 68m 高的跳台上,跟工作人员确认了几次安全带系牢,双腿已经有些软掉的情况下,双手抱头纵身一跃,被接上岸的时候双腿真的软掉了。事后想想,¥200 只包含一份最多赔偿 ¥40, 000 的保险,万一不小心挂了,真是太死得不其所了。

总之,人生又少了件不做后悔的事,接下来可能就是 skydiving 了。

耗时两天排查问题的小结

最近在线上遇到了一个比较棘手的 ops 问题,我花了两个工作日加上中间的一个晚上时段才最终发现了问题的根源,下面分享下我排查问题的思路以及步骤,先介绍下背景。
三个 IDC,BTC, DG, DL,其中 BTC, DG 是通过光纤直连,内网互通,DL 通过与 BTC 之间建立 OpenVPN tunnel 实现了三个 IDC 内网的打通。这三个 IDC 部分的 VLAN 网段信息分别如下:
BTC: 172.18.10.0/24,BTC 这台机器的 OpenVPN client IP 为 172.18.10.254
DG: 172.20.0.0/24, 172.20.100.0/24, 172.20.200.0/24 等等
DL: 192.168.1.0/24,192.168.1.24 这台 OpenVPN 作为 server 跟 BTC 的 172.18.10.254 建立起 tunnel
由于涉及到公司的商业信息,以上是我简化后的模型,实际的情况、涉及到的因素要比这个复杂的多。

某日下午我做完一个常规性的变更之后,收到反馈说从 DG 172.20.100.0/24 的机器无法访问位于 DL 192.168.1.26/24 的这台机器。
很自然的,我从 172.20.100.0/24 上挑选了 172.20.100.1 这台机器,登录上去,确认了下面的几件事:
1. 基本的网络连同性,ping 192.168.1.26,发现无法 ping 通。

2. 看 route 信息,通过 mtr 看路由信息:
$ sudo mtr 192.168.1.26 -n -r
HOST: host-1.umops.us             Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 172.20.100.249                 0.0%    10    0.5   2.0   0.5  10.4   3.3
  2. 172.16.1.254                  0.0%    10    3.8   2.1   0.7   7.4   2.3
  3. 172.18.10.254                  0.0%    10    0.3   0.4   0.3   0.4   0.0
  4. ???
可以很清楚的看到,到了 BTC 的 OpenVPN client 之后就断了,也就是没有路由指向了。

2. 基本的 networking,从 ifconfig 以及 /etc/sysconfig/network-scripts/ 来看,没有问题

3. 基本的 route:
jaseywang@host-1:~$ route  -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
172.20.100.0     0.0.0.0         255.255.255.0   U     0      0        0 bond0
0.0.0.0         172.20.100.254   0.0.0.0         UG    0      0        0 bond0
没有问题,默认 GW 直接上我们 Nexus 7000 的 HSRP VIP(172.20.100.254),上面看到的 172.20.100.249 是 RIP。

接着我把 172.20.100.0/24 的其他几台机器挨个试了一遍,发现现象跟上面一样。

接着,我登录到 DG 的其他网段比如 172.20.0.0/24 的机器上做同样的测试,可以发现完全没有问题:
$ sudo mtr 192.168.1.26 -n -r
HOST: host-2.umops.us               Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 172.20.0.248                  0.0%    10    0.7   0.5   0.4   0.7   0.1
  2. 172.16.1.254                  0.0%    10    5.7   2.3   0.6   8.6   2.8
  3. 172.18.10.254                  0.0%    10    0.3   0.3   0.3   0.4   0.0
  4. 192.168.4.1                   0.0%    10    6.9   5.6   2.6  24.5   6.8
  5. 192.168.1.26                  0.0%    10   17.6  10.2   2.9  36.2  10.5

当时第一想法是,是不是 DG 的 SW 配置有问题,是不是把 172.20.100.0/24 这个网段在某些关键的点上漏掉了,于是让我们的 ne 上去确认,反馈说没有问题。事后总结起来,其实从 mtr 上就能看到应该不是 SW 的问题,mtr 可以看到到了 hop 4 才中断,否则第一或者第二 hop 就断了。

并且诡异的是,DG 的其他网段的机器都没有问题,唯独 172.20.100.0/24 的有问题,我依然认为是整个从端到端的某个设备或者服务对 172.20.100.0/24 这个网段少做或者多做了一些变更,但是从端到端,期间涉及众多的机器,众多的不同同层的因素,从服务器到交换机再加上 VPN,确实需要考虑进去的因素比较多,暂时还没有很好的缩小问题的方式。

第一天晚上回去的时候想起来可以反向试试,于是从 192.168.1.26 这台机器 mtr 到 172.20.100.1,hop 如下:
$ mtr 172.20.100.1 -r -n
HOST: github-jaseywang-me            Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|– 192.168.1.24               0.0%    10    0.5   0.4   0.3   0.5   0.1
  2.|– ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
可以发现,IDGP 包到了 DL 的 OpenVPN server 就中止了。

至此,我基本可以将问题的范围缩小到连接 BTC 跟 DL 的两台对端的 OpenVPN 机器上,并且从 hops 信息来看,应该是 DL 的 OpenVPN server 有问题的概率更大。

晚上回去之后,我一边在 192.168.1.26 这台机器上 mtr 172.20.100.1,一边通过 tcpdump 抓包,可以发现只有 syn,没有任何的 ack。同样的,mtr 172.20.0.1 这类的机器却没有任何的问题,有 request/reply。这更加确定了我之前的想法,一定是这个端到端的跨越了 3 个 IDC 的某个子系统出了点问题,并且这个问题可以归结于,把 172.20.100.0/24 这个段给特殊对待了。

至于是哪台机器的哪个服务出现了问题,这个就是我那天晚上以及第二天上午做的工作。当天晚上,我又确认了下面的几件事:
1. 一一排查了这两台 OpenVPN 机器的 iptables,为了以防万一,我清空了 INPUT 做测试,现象依旧
2. 再三确定 SNAT 对 OpenVPN 影响很大的这个 chain 配置没有问题
3. selinux 关闭了,sysctl 里面也没有特殊的开关
4. 基础的系统配置,包括我最开始提到的 networking、route 等信息
5. 172.20.100.0/24 里面的机器跟其他比如 172.20.0.0/24 机器的差异,由于都是统一定制安装的,在基础的系统层面根本找不出差异
6. OpenVPN 的配置,把 client, server 的两个文件检查了好几遍,没有发现异常

第二天上午继续排查了两个多小时,能想到的可能会涉及到的方面都想到了,依然没有结论。转而向我们的总监求助,跟他描述了下问题的情况,跟我一样,一样觉得很诡异,同样的配置,其他 VLAN 的机器完全没问题,就这一个 VLAN 的有问题。要是整个 DG 的 VLAN 都不通,那还能说明些问题,现在仅仅这一个 VLAN 不通。
下午,我们又从下面几个方面入手逐一排查:
1. 依然怀疑是 route 层面有问题,并且是 DG 那台 OpenVPN server 本机的 route 有问题,于是直接上了 iproute2 来确定 route table 是否正确,我也临时熟悉了 iproute2 的一些基本概念。通过下面几条 cli 判断了几个不同类型的 routing table 的情况:
# ip rule list
# ip route get 172.20.100.1

2. tracapath 继续跟踪了番,现象依然是到了 DG 的 OpenVPN server 就断了

3. 通过 starce 查看系统的调用显示跟上面一样的现象

4. 由于这两台 OpenVPN 的机器都是跑在 Xen 上的 instance,怀疑可能是由于 VM 某些方面的问题导致的,但是考虑到使用的是 bridge 并且要排除 VM 导致可能性的的繁杂程度,暂时放弃深挖。

5. bonding 方面的影响,由于我们对 DG 的所有机器刚做完 10G 的升级,包括 172.20.100.1 这台机器都使用了 bonding,尽管没没有理由怀疑是 bonding 造成的,我们还是把这台机器的 bondin 给拆了,换成了普通的单网卡模式进行测试,结果很明显

6. 抓包,在两端的 OpenVPN 上抓包以及在上联的交换机做 mirror,得到的现象跟上面一样

7. 扩大 OpenVPN server 的 netmask,既然 172.20.100.0/24 这个跟其他的诸如 172.20.0.0/24 等地位一样,将原先的 /24 扩大到 /16 以包含所有的 IP,就没有理由不通了,这个是修改前的 route:
# route  -n

172.20.100.0     0.0.0.0         255.255.255.0   U     0      0        0 tun0
172.20.0.0       0.0.0.0         255.255.255.0   U     0      0        0 tun0

修改后的 route:
# route  -n

172.20..0       0.0.0.0         255.255.0.0   U     0      0        0 tun0

意外的是,依然不通

8. 在 DG 新启用了一个 172.20.150.0/24 gateway 为 172.20.150.254 的 VIP,在 DL 的 OpenVPN server 上添加到到这个 IP 的路由:
# route  add -net 172.20.150.0  netmask 255.255.255.0 tun0

在 192.168.1.26 的机器上测试,现象依旧:
$ mtr 172.20.150.254 -r -n
HOST: github-jaseywang-me            Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|– 192.168.1.24               0.0%    10    0.4   0.5   0.4   1.1   0.2
  2.|– ???                       100.0    10    0.0   0.0   0.0   0.0   0.0

把以上所有的现象以及测试结果综合起来看,几乎可以可以确定就是 OpenVPN server 的问题,但是哪里有问题,依然不清楚。 这时我们突然想到还有这台 OpenVPN server 的 log 没仔细检查一边,google 了下,通过 "verb 5" 提高了 debug 级别,这下就能很详细的看到 OpenVPN 打的 log。log 的格式比较奇怪,像下面这样的,但是这不重要,下面这么多的字符,好好看,能发现 "packet dropped" 的关键词:
wrWrWRwRwrWRwrWRwRwrWrWRwRFri Apr 18 17:05:02 2014 us=291047 btc/111.111.111.111:45721 MULTI: bad source address from client [111.111.111.111], packet dropped
RwRwRwrWRwRwRwRwRwRwrWRwrWRwrWrWRwrWRwRwrWRwrWrWRwRwrWrWrWRwrWRwRw
RwRwRwRFri Apr 18 17:05:10 2014 us=132323 btc/111.111.111.111:45721 MULTI: Learn: 10.8.0.38 -> btc/111.111.111.111:45721
RwrWRwRwRwrWrWrWRwRwrWrWRwrWRwRwRwrWrWrWRwRwrWrWRwrWRwRwRwrWrWR
i Apr 18 17:06:07 2014 us=891600 btc/111.111.111.111:45721 MULTI: Learn: 10.8.0.126 -> btc/111.111.111.111:45721
RwrWrWRwrWrWRwrWRwRFri Apr 18 17:06:29 2014 us=146563 btc/111.111.111.111:45721 MULTI: Learn: 10.8.0.26 -> btc/11
1.111.111.111:45721

Google 第一条就告诉了我们答案!原来 172.20.100.0/24 作为我们较新的网段,我忘记把 iroute 写到 ccd 文件里面了:
These errors occur because OpenVPN doesn't have an internal route for
192.168.100.249. Consequently, it doesn't know how to route the packet to this
machine, so it drops the packet.
Use client-config-dir and create a ccd file for your client containing the
iroute option to tell OpenVPN that the 192.168.100.0/24 network is available
behind this client.

"MULTI: bad source address from client [192.168.100.249], packet dropped" or
"GET INST BY VIRT: 192.168.100.249 [failed]"?

下面提几个跟 route 关系较大的指令(1, 2) ,以后 end-to-end, sub-to-sub 出现问题,不妨先考虑是不是这些方面造成的。
1. client end 的 route
;push "route 192.168.10.0 255.255.255.0"

2. client subnet 的 route
;client-config-dir ccd
;route 192.168.40.128 255.255.255.248
;route 10.9.0.0 255.255.255.252

最后总结一下,这是一次刺激的发现问题找到根源解决问题的过程,又一次验证了整个 *nix stack 里面最复杂的是 networking 这个问题,因为牵扯到层面太多。正所谓「山穷水尽疑无路,柳暗花明又一村」。不吹牛逼的说,做了这么多年,还真没有我解决不了的工程问题。

体验 Uber 打车

作为一名崇洋媚外,从业移动互联网,资深打车爱玩人士,Uber 在西朝鲜首都试运营当然要找机会去试试。
在那个阳光明媚,PM2.5 ~ 150 的中午,我在酒仙桥吃完午饭,拿起满是划痕的爱疯,打开了 Uber,看到周围不到 5 公里的地方停了辆奥迪 A6,满心窃喜,麻利的发起了 request,不到 15s,那头的师傅就跟我确认了我的方位,插句话,其实对方的位置都是实时的,司机能看到我当前的位置,我也能看到车的行动轨迹细微到掉头。

等了不到 10min,司机准确的停在了我等候的地方。上车,接下来就是跟预想的差不多了,说话语气,态度之类的的确一流,看上去师傅估计是会说点简单的洋文,不停的跟我说 OkeyOkey,这个在之前起步价 ¥14 的车子里面是从来没听到过的。车子宽敞,后座提供矿泉水,上车后师傅看我手机没电了还把充电线借我冲了会电。途中跟师傅随便扯,对他的印象就是一个靠拆迁富起来的土著早些年买了辆奥迪不怎么用再加上离休闲在家里没事做,人跟车都全了,于是就出来给 Uber 打工了;除此之外,司机的工资目前是按照天数发的,尤其试运营的这些天,从我观察的来看,其实活儿很少,据他说没活儿拉的时候就停在四环的宜家那边,很爽是不是。
全程大概 14 公里,中午不堵,开了不到 30min,到了目的地直接双方互评 5 颗星,全程无现金交易,通过预先绑定的信用卡结账。最后费用就是 14 的车子里面是从来没听到过的。车子宽敞,后座提供矿泉水,上车后师傅看我手机没电了还把充电线借我冲了会电。途中跟师傅随便扯,对他的印象就是一个靠拆迁富起来的土著早些年买了辆奥迪不怎么用再加上离休闲在家里没事做,人跟车都全了,于是就出来给 Uber 打工了;除此之外,司机的工资目前是按照天数发的,尤其试运营的这些天,从我观察的来看,其实活儿很少,据他说没活儿拉的时候就停在四环的宜家那边,很爽是不是。
全程大概 14 公里,中午不堵,开了不到 30min,到了目的地直接双方互评 5 颗星,全程无现金交易,通过预先绑定的信用卡结账。最后费用就是 ¥18 + ¥0.7/min + ¥3.85/km,最低 ¥30。回来收到了一封邮件,总结的不错。


总的来说,除了价格 double 之外,其他的没什么可以挑剔的。话说回来,Uber 的目标是不缺钱的商务人士,而非海淀区满空气电子化学气味的修电脑人士,我只是体验一下而已。

10G 网络升级(Nexus 752 其他技术细节)

trunk
默认情况下,trunk 端口会放行所有的 vlan 流量,这个我们之前也没有太在意,就使用的默认配置,如果放行所有,那么会造成 trunk 端口收到来自所有 vlan 的广播流量。所以让 trunk 链路只放行必要的 vlan,可以节约大量的链路带宽。因此有必要掌握下 switchport trunk allowed 的基本用法的。

VTP
VTP(feature vtp) 本意是好的,但是使用不当,尤其是网络规模大了之后,会造成灾难性的后果。开启这个特性之后,需要严格遵循制定的流程,变更时无比反复的确定细节。另外设置 vtp 密码之类的也能派上一些用场。我们最终评估下来决定取消这个协议,fex 的一个巨大的变革就是减少工程师的操作负担,直接在 Nexus 5000 上操作就可以,保守起见,还是不要开启这个特性。

checkpoint/rollback
checkpoint/rollback 的配置,这个还是蛮重要的,在做一些重要变更之前,先 checkpoint 一遍再执行接下来的操作。

ISSU
升级,通过数据平面跟控制平面的分离,可以做到无缝升级,即不需要重启。当其在处理数据平面的流量时,不会动用 CPU 资源,而是通过 ASIC 以硬件的方式做转发;而处理平面/控制平面则不同,这也是 CoPP 存在的意义。

VRF
这个技术在 IOS 的 12.x 版本就出现了,目前最新的 15.x 同样有(为什么跳过了 13 跟 14,自己猜)。跟三层相关的都需要用到这个了。在使用 sh ip int brie 查看的时候记得最后要加上 vrf management;同样的,如果要 ping 这个管理 ip,需要 ping ip vrf management。可以直接下面这个方式直接切换:
# routing-context vrf management

fex(fabric extender) 的连接方式
有 passthru 以及 crossover 两种。根据之前查阅的大量文档发现,使用 passthru 这种方式会加易于管理,另外,crossover 的方式在某些情况下会出现流量分配异常的情况。至于 fex 一些细节问题看官方的这个文档应该就能覆盖大部分的问题了。

pinning
对于一台普通的接入机器来说,4 个 10G 做一个上联,剩余的 48 个千兆做接入,其 oversubscription 达到了 48×1/10 = 4.8:1。如果每 12 个端口对应一个 10G 端口,这样 oversubscription 变会下降到 1.2:1,但是如果其中一条物理链路出现了问题,其对应的 12 个端口也就报废。对于 fex 来说,有 static pinning 以及 etherchannel 两种方式,其中前者就是上面那种使用物理链路的方式而后者则使用的虚拟链路。如果要使用 etherchannel 的方式,其 pinning max-links 则必须设置为 1一般情况下使用 etherchannel 会比 static 的方式更有优势

HSRP
关于 vPC 跟 HSRP 之间的配合以及可能会出现的问题,可以参见这个文档。官方建议在 vPC 的 primary 上配置 master HSRP 而在 secondary 上配置 standdy 的 HSRP。

其余的问题参见官方的两篇文档应该就差不多了,写的很详细。
Nexus 7000 Series Switches Using HSRP Configuration Example
Configuring HSRP

AAA
官方有一个 TACACS+ 以及 RADIUS 的比较,总的说来,还是使用 TACACS+ 更有优势。
如果要快速入门,学习 tacacs+ 的使用,可以看这个两个(1, 2)文档。
除了通过在 752 上做 ACL 来控制访问之外,还可以直接在 tacacs+ 上做源 IP 的访问控制
关于在 752 上的 AAA 配置,可以这里

上面是一些需要重点关注的特性,其他的比如 syslog, snmp, ntp 等篇管理方面的可以看这里