10G 网络升级(整体架构 & vPC)

上篇介绍了升级过程中涉及到的业务层面的内容,接下来两篇会着重总结一些技术上的实现细节。在主持此次升级之前,把《Network Warrior》上面的一部分内容过了一遍,除了介绍 752 之外,其他的章节总结的也很到位,尤其是最后的几章节,很多问题都是一针见血,强烈推荐各位看看,上面的总结只有经历过的人才会有共鸣。下面的内容也有部分是出自这本书。

Nexus 7000 使用的是 midplane 架构,跟之前的 backplane 不同,因此需要重新考虑散热问题。比如 7004 使用的是 side-rear 的方式,7018 则是 side-side 的方式。 Nexus 5000/2000 的则是从前到后或者从后到前谁前谁后,这个务必要理解清楚,否则跑了一半机器就烧了歇火了。因此需要考虑 IDC 里面的 hot/cold aisle。这里有两篇(1, 2)  比较早期的文档,专门探讨 752 的散热问题(不仅仅 752 存在这个问题,4948E 也有类似的问题),解决的办法也比较简单,花钱买套 "Nexus Airflow Extension Sleeve"。
上面谈到的是散热问题,7K 的电源模块可能会存在一些问题,默认使用的 250V,16A 的电源线,一般的插线板可能无法插入;另外功耗问题也需要考虑进去,一般的测试环境是无法满足这么大的功耗问题的,所以不管是测试还是正式上架,务必确认这些问题。

Nexus 5000 基本跟 7000 看齐,除了 U 位小些,没有冗余 supervisor 以及 VDC 这类高端功能罢了,其他的差异我认为不是很大。

Nexux 2000 严格来说,并不是交换机,只是一个 fabric extender,他有两类端口,一种叫主机端口,就是连接服务器的,默认激活了 STP BUDU Guard,一旦连上服务器便会 error-disable;另一种是 fabric 端口,用来连接 N5K/N7K,所有的 fabric 端口都是 10G 端口。

说完整体再总结几个 nexus 改进最大的地方,也就是最像 *nix 的地方(1, 2, 3)。
几乎所有的协议都已模块化的方式加载:
# show feature

所有的接口均已 Ethernet 开头,不再分 FastEthernet、GigabitEthnet,这样比较方便操作。

可以使用 tab 补全,类似 shell;除此之外多了很多 pipe,多了 grep 等过滤的工具。

管理平面、控制平面以及数据平面隔离。比如 ssh 产生的为管理流量,并不会影响数据转发的流量。管理平面挂了对生产环境并没有致命的威胁。

默认情况下,nexus 7000 所有的接口都是三层的,因此,要变成 trunk,记得加 switchport。

VDC 这个是 nexus 最大的一个卖点。本次我们没有采用 VDC 这种看上去逼格很高的技术,仔细想想,根本不适合我们的业务场景,线上全是生产环境,第一并不需要流量隔离,第二毕竟是一个虚拟技术,对整体的性能多少还是有些影响的,这个可以类比 *nix 下各种 VM 的实现,其优缺点很明显。根据业务需求选择对应的技术,而不是为了用技术而用技术,技术最终都是为业务服务的,脱离了他技术没有任何意义。

接下来会着重总结 vPC 这个比较创新的技术。在开始之前还是还有必要过一下这个 quick start 的 《Virtual PortChannel Quick Configuration Guide
vPC 这个在 752 的架构中用的很多,主要是为了增加上联的带宽减小收敛比,其次冗余也是一方面,并且他可以做到跨机箱,比传统 port-channel 要好的多。官方有两个文档,一个是《Configuring Virtual Port Channels》,另外一个是《vpc best practices design guide》  可以没事翻阅看看,都是经验总结,看完了可以少走不少弯路。

使用 vPC 最重要的是注意 consistency 的问题,这篇文档描述了这个问题。 show vpc consistency-parameters 是一个非常 handy 的命令,出了问题先通过他查看查看,很可能会发现问题的原因。如果这条命令解决不了,那就按照这个操作一步一步来吧。 《Troubleshooting Virtual Port Channel Issues

vPC 的 domain 编号跟 port channel 的编号一致,否则以后出了问题有的你受了,这是减轻你的痛苦也是减轻后来维护人员的痛苦。 另外,由于 vPC 受众多因素的影响,一点点小的改动都可能导致出现 type 1 的完全中断或者 type 2 的部分中断,因此操作包含 vPC 的机器时,需要格外小心。vPC Domain ID 问题需要注意的是,7K 上的 domain ID 不能跟 5K 上的一样,否则 port channel 会一直处于 suspend 的状态而导致 vPC 无法连接,原因可以看这里

需要注意的是,不管是 port channel 还是 vPC,都无法实现每条物理链路流量的均分。比如我们之前在 stacking 过的 3750X 上做 cross-stack,实现 port-channel。很明显的可以看到,两条物理链路的流量并不均等。


上面这个是两条 1G 的绑定,理论上,要实现流量的均分,必须是 2 条、4 条或者 8 条的绑定,但是实事情况是,即使是两条,也会出现流量不均等的情况。 默认情况下,port channel 会通过目的 mac 的方式做 LB,由此可以看到,当数据包要发往的目的地比较多的时候,才能体现 port channel 的价值。如果,发往的 mac 地址很单一,就会造成流量很集中在某一条物理链路上,后果是,即使这一条物理链路出现过载,交换机也不会自动的将一部分的流量切分到其他的空闲物理链路上。因此,是选择根据源 mac 方式还是目的 mac 亦或是其他更复杂的方式,还是需要根据业务类型来定。

要做 vPC 就离不开 Peer-Keepalive。其最重要的就是 internal 以及 timeout 的时间。前者有 400ms 到 10s 可选,默认 1s 的应该足够了。后者有 3 到 20s 可选,默认 5s。 Peer-keepalive 可以使用 management VRF 或者 default VFR。官方推荐使用前者, 也就是使用 mgmt0 的 ip 作为 src/dst 的地址;如果使用 default VFR,还要建立 SVI,没有必要。另外,两台 peer 的配置最好一样,详细情况可以看这里

接下来就是 Peer-Link,这这两有先后顺序,不要弄反,只有在对端 peer 挂了情况下,Peer-Keepalive 才会启动侦测。

最后,熟悉我们前年升级的应该会知道(1, 2, 3, 4),我们会涉及到跨机房的通信的问题。 之前是在两台 3750X 上起的 port channel,现在一方升级另一方不变,vPC 依然可以很好的胜任,对端 port channel 不变,要升级的这端起 vPC 就可以了。