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 等篇管理方面的可以看这里

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 就可以了。

Cisco 三层交换参数

12 年写的一篇文档,14 年 2 月看来,不少东西还是适用的。


上一篇简单的总结了下 Cisco 交换产品的型号配置。对于 IDC 来说,二层设备还是很简单的,基本就是下面几个型号。
WS-C2960S-48TD-L
48 Ethernet 10/100/1000 ports
2 10 Gigabit Ethernet or 2 1 Gigabit Ethernet SFP+ uplink ports
Optional Cisco FlexStack stacking support
LAN Base image

WS-C2960S-24TD-L
24 Ethernet 10/100/1000 ports
2 10 Gigabit Ethernet or 2 1 Gigabit Ethernet SFP+ uplink ports
Optional Cisco FlexStack stacking support
LAN Base image

WS-C2960S-48TS-L
48 Ethernet 10/100/1000 ports
2 1 Gigabit Ethernet SFP uplink ports
Optional Cisco FlexStack stacking support
LAN Base image

WS-C2960S-24TS-L
24 Ethernet 10/100/1000 ports
2 1 Gigabit Ethernet SFP uplink ports
Optional Cisco FlexStack stacking support
LAN Base image

其中 TD 两款是有 10G uplink 的,而下面两款基本等同于之前的 WS-C2960G-48TC-L 型号。如果只需要 Lan Lite 的,对应的则是:
WS-C2960S-24TS-S
WS-C2960S-48TS-S
TD 对应的两款没有 Lan Lite。
Continue reading

目前网络架构的缺陷

去年(12 年)我设计的方案在我们某一个机房跑了快一年,目前出现了很严重的性能问题。简单的讲就是交换机撑不住了,下面服务器流量稍微大点就开始丢包。当初为了节约成本的苦头终于吃到了。
我虽然不是专业搞网络的,但是一些基本的理论概念还是很清楚的,至于实践问题,看看文档,在正式上线之前把步骤都理清楚了,自然不会出什么大问题。我之前写了一个小系列的博客,纪录我们的那次升级,可以看看这里(1, 2, 3, 4) 。另外,该机房主要是用来跑 hadoop 的,数据量有多大可想而知。
说说目前存在的问题。
先说优点,当初设计的一个原则就是坚决走二层(核心、接入)的方案,而非传统的三层(核心、汇聚、接入)的方案,这个现在证明完全是正确的。首先都是内网,安全性问题可以放在后面考虑,二层扁平结构最明显的特点就是更小的收敛比,这个对于有大量数据传输的机房是很重要的;相比之下,传统的三层由于收敛比比较高,性能会收到一定的影响,比较时候园区等办公环境而不适合机房尤其是跑 hadoop 的环境。
接着是重点,缺点。目前是一台 2960S 下面挂 10 台 1G(没有做 bonding)的服务器,接入跟核心做的是 2G 的 channel。写到这里应该已经看出来了,这个收敛比还是比较大的,5:1。这个在初期还不是很明显,起初机器数量少,流量也少。但是随着机器数量的增加,情况就不一样了,每台服务器实际是跑不到 1G 的,以我们统计的图表来看,下图,平均一台 200M 左右,但是峰值基本都在 600M 左右,最终计算收敛比的话,还是以 600M 的峰值计算,最好的情况是 600M x 10 = 6G ,但是上面只有 2G 的可用带宽,不行,一种看上去行得通的办法是将 channel 进一步扩大,扩大到 6G,那就意味着一台 2960G 需要额外的 6 个端口来跟 3750X 上联,3750X 也需要由原先的 2 台扩展到 6 台。这也只能满足目前的需求,如果服务器的带宽进一步的往上跑,单台 3750X 的负载也需要进一步的加大,基本就没戏。上面这种方案并不能根本的解决问题。

所以比较根本的解决方案是直接上 N7K,下面可以考虑直接挂 N2K,或者通过先通过一层 N5K 再走 N2K,不管哪种方式,都能达到比较好的效果,收敛比达到 1:1 不在话下,并且应该能满足今后两年的需求。


要发现上面这些问题,除了通过在服务器上的监控数据采集得到的结果做分析之外,最简单的还是在上层的交换机上直接 show:

# show interfaces GigabitEthernet1/0/2
GigabitEthernet1/0/2 is up, line protocol is up (connected)

     reliability 255/255, txload 114/255, rxload 183/255

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 2696237866

# show interfaces summary
 *: interface is up
 IHQ: pkts in input hold queue     IQD: pkts dropped from input queue
 OHQ: pkts in output hold queue    OQD: pkts dropped from output queue
 RXBS: rx rate (bits/sec)          RXPS: rx rate (pkts/sec)
 TXBS: tx rate (bits/sec)          TXPS: tx rate (pkts/sec)
 TRTL: throttle count

  Interface               IHQ   IQD  OHQ   OQD  RXBS RXPS  TXBS TXPS TRTL
————————————————————————-
* GigabitEthernet1/0/2     0     0    0 2696238164 724931000  83002 441240000  65852    0  

很明显的可以看到,Gi1/0/2 不管是 txload 还是 rxload 都已经很高的,OQD 也高的惊人。

Cisco Nexus 5000/7000 概览

Cisco 原厂前段时间送了两台 N5K 的拿过来测试,加上之前幸见到了 N7K 的真身,抽空测试过一段时间,再加上本身比较喜欢玩玩新玩具,于是对 Nexus(主要集中在 5K/7K) 系列做了个大致的了解,供参考。
具体的零部件参数就不在这里展开列举了,官方的比如 Nexus 7000 Series Switches Data Sheet 等都能看到。有几个重要的模块提一下,主要包括:
* chassis
* fabric modules, fabric-2 modules
* supervisor module, second-gen supervisor, supervisor 2E
* I/O module(M/F), F1-F3, M1-2
* power
* fan

印象比较深的是,4 槽的可用性不是很大,除非你的 rack 少的可怜,但是服务器的网卡流量又不小(千兆的平均每台在 300Mbps 以上),更多的是 9、10 槽的型号。包的转发速率已经是以 b(billion)来计的了,所以,性能几乎不是问题。
另外,10 槽的还可以 air filter,这一个 filter 的价格就超过 honeywell 的高端型号了。

每个型号的功耗都不小,10 槽的最大会消耗 7.5KW 左右,这个一般的机柜都没有这么大的电流。因此这个是必须要考虑的一个问题,不然放到 rack 上会悲剧。所幸的是,官方列举的都是最大的功耗,根据之前的经验,实际的按照 2/5-3/5 的最大功耗算就足够了,前提是你的机器不是顶配。

最明显的变化是硬件架构的变化,Intel Xeon 的处理器,内存以条数计算,跟机架式服务器有那么点类似,可以进行增减操作,所以从这种角度来看,更像一台多网卡的服务器。
另外,OS 也彻底的换成了基于 Linux 的 NexusOS,进去之后感觉是那么的亲切,可以看最后的几张截图。

要使用某项功能或者说某个协议,更之前的 IOS 完全不一样,在使用之前需要先激活其对应的进程,然后才可以使用,这是不是借鉴了 Linux 下类似 chkconfig 的做法,不用的就关闭需要使用的就开启。既然能做到开启关闭也就能做到进程的重启,比如 OSPF 的重启等等。

此外,安全性也得到了很大的提升。比如默认开启了 SSHv2,而关闭了老掉牙的 telnet。 RBAC 跟 AAA 协同,提供了更细粒度的访问控制。

最后,新出了一个叫 CMP 的功能,有点类似服务器上的管理卡,使用专用的处理器、内存等,相当于一个独立的 OS,使用他就能实现所有包括电源在内的所有系统组件的重启等操作。是不是很方便。

至于软件上的创新,我认为最大的出彩的地方就是 VDC(Virtual Device Contexts),其实就是把一台物理机划分成了最多 4 个 VM(VDC),他们之间可以划分 port、vlan、portchannel 之类的东西。好处不用多说了,资源的隔离,HA 等等。

虽然 Nexus 早在 08 年最推出了,但是也就近一两年(12, 13)才在大陆市场推广开来,而像 N7700 系列从我最早(01/2013)开始关注到现在(08/2013),大陆还未正式发行。不过真的大规模的使用起来,不知道又要甩 huawei  几条街了。

最近几年炒的特别的火的大数据也确实诞生了不少的新技术,比如像 OpenFlow, SDN 等等,N7K 对其的支持都确实不错。

Continue reading

是否需要端口自动协商(Autonegotiation)

对于服务器或者交换机来说,是否需要开启端口的自动协商(autoneg)?
答案很明确,必须要。除非你的设备是 10 年之前的老古董,这个对于目前托管在 IDC 的机器来说基本不存在这个问题。并且,越是新的设备越是需要支持自动协商。由于目前所有的主流设备出厂默认设置即为自动协商,因此,对于工程师来说,没有任何的工作量可言,何乐而不为。
为什么要这样?请看这里(1,2 )。

随便挑台交换机看看:
#show interfaces Gi0/25 capabilities
GigabitEthernet0/25
  Model:                 WS-C2960G-48TC-L
  Type:                  10/100/1000BaseTX
  Speed:                 10,100,1000,auto
  Duplex:                half,full,auto

对于服务器来说,不管是 1G 的还是 10G 的,默认都是 auto:
# ethtool  eth0
Settings for eth0:
    Supported ports: [ TP ]
    Supported link modes:   10baseT/Half 10baseT/Full
                            100baseT/Half 100baseT/Full
                            1000baseT/Full
    Supported pause frame use: Symmetric
    Supports auto-negotiation: Yes
    Advertised link modes:  10baseT/Half 10baseT/Full
                            100baseT/Half 100baseT/Full
                            1000baseT/Full
    Advertised pause frame use: Symmetric
    Advertised auto-negotiation: Yes
    Speed: 100Mb/s
    Duplex: Full
    Port: Twisted Pair
    PHYAD: 1
    Transceiver: internal
    Auto-negotiation: on

# ethtool  eth2
Settings for eth2:
    Supported ports: [ FIBRE ]
    Supported link modes:   1000baseT/Full
                            10000baseT/Full
    Supported pause frame use: No
    Supports auto-negotiation: Yes
    Advertised link modes:  1000baseT/Full
                            10000baseT/Full
    Advertised pause frame use: No
    Advertised auto-negotiation: Yes
    Speed: 10000Mb/s
    Duplex: Full
    Port: FIBRE
    PHYAD: 0
    Transceiver: external
    Auto-negotiation: on

Continue reading