本文主旨：好记性不如烂笔头，本文资料源自网络，主要目的为梳理终结，如有侵权，联系必删。
摘要：在使用基于 VXLAN 的 SDN 解决方案时，对物理网络的基本要求是修改 MTU，让其大于1600 (NSX)，下面总结了几大厂商不同型号或版本交换机的配置，以后会不断更新，也请有过配置经验的同行帮忙补充。
配置简介：
一般配置 MTU 时，需要配置端到端沿途所有设备，如果源和目标在同一个网段，则只需要配置沿途所有设备的二层接口MTU。一般按照设备不同，可能需要全局配置 MTU，或者在对应接口上配置MTU。
如果源和目的在不同的网段内，除了配置沿途所有二层接口 MTU 外，还需配置两个网段网关接口(三层接口)的 MTU。
一般配置方式是 interface vlan 100，mtu 1600
Cisco系列交换机
Nexus 系列交换机：
三层MTU
#SVI 接口配置： Switch(config)#interface vlan 1 Switch(config-if)#mtu 9216 #三层物理接口配置： Switch(config)#interface ethernet 1/1 Switch(config-if)#no switchport Switch(config-if)#mtu 9216
二层MTU
二层MTU可以通过Qos或者基于端口进行配置。目前只有 Nexus 7000, 7700, 9300, 和 9500 支持端口配置 MTU。 Nexus 3048, 3064, 3100, 3500, 5000, 5500, 及 6000 配置方式 此配置会对所有接口生效；
policy-map type network-qos jumbo
class type network-qos class-default
mtu 9216
system qos
service-policy type network-qos jumbo
Nexus 7000, 7700, 9300, 及 9500 配置方式
以下为基于接口的配置方式：
Switch(config)#interface ethernet 1/1 Switch(config-if)#mtu 9216
Nexus 2000 配置
注意：Nexus 2000 MTU 配置需要在其父 FEX 交换机上进行配置，如果父交换机支持接口下配置MTU，则在对应接口下配置，如果不支持，则需要使用network-qos。
需要注意，使用 FEX 时，Fabric Port Channel (FPC) ，也就是连接 FEX 的端口聚合组也需要配置 MTU
interface port-channel136 switchport mode fex-fabric fex associate 136 vpc 136 mtu 9216
注意: 在 6.2 版本以后，Nexus 7000 不支持给 Fabric Port Channel 接口直接配置MTU，必须创建一个 QoS 策略来全局调整 MTU。
policy-map type network-qos jumbo
class type network-qos class-default
mtu 9216
system qos
service-policy type network-qos jumbo
MTU值验证：
三层MTU
#所有 Nexus 系列交换机都可以通过show interface eth x/y命令来查看接口 MTU： Nexus#show interface ethernet 1/19 Ethernet1/19 is up Dedicated Interface Hardware: 100/1000/10000 Ethernet, address: 547f.ee5d.413c (bia 547f.ee5d.40fa) MTU 9216 bytes, BW 1000000 Kbit, DLY 10 usec #使用 show interface vlan X命令查看 SVI 接口MTU： Leaf3#show interface vlan 1 Vlan1 is down (Non-routable VDC mode), line protocol is down Hardware is EtherSVI, address is 547f.eed8.ec7c Internet Address is 1.1.1.1/23 MTU 9216 bytes, BW 1000000 Kbit, DLY 10 usec
二层MTU
#Nexus 3100, 3500, 5000, 5500, 及 6000
Nexus#show queuing interface ethernet 1/1
Ethernet1/1 queuing information:
TX Queuing
qos-group sched-type oper-bandwidth
0 WRR 100
RX Queuing
qos-group 0
q-size: 469760, HW MTU: 9216 (9216 configured)
#Nexus 3000, 7000, 7700, 及 9000
Nexus#show interface ethernet 1/12
Ethernet1/12 is up
admin state is up, Dedicated Interface
Hardware: 1000/10000 Ethernet, address: 7c0e.ceca.f183 (bia 7c0e.ceca.f183)
MTU 9216 bytes, BW 10000000 Kbit, DLY 10 usec
#Nexus 5000, 6000, 及 7000 的 FEX 接口
Nexus#show queuing interface ethernet 136/1/1
if_slot 68, ifidx 0x1f870000
Ethernet136/1/1 queuing information:
Input buffer allocation:
Qos-group: 0
frh: 3
drop-type: drop
cos: 0 1 2 3 4 5 6 7
xon xoff buffer-size
---------+---------+-----------
19200 78080 90880
Queueing:
queue qos-group cos priority bandwidth mtu
--------+------------+--------------------+---------+----------------+--------
3 0 0 1 2 3 4 5 6 WRR 100 9280
#**Nexus 9000 的FEX 接口 **
9396-B#show interface ethernet 104/1/1
Ethernet104/1/1 is up
admin state is up,
Hardware: 100/1000 Ethernet, address: 5475.d0e0.e5c2 (bia 5475.d0e0.e5c2)
MTU 9216 bytes, BW 1000000 Kbit, DLY 10 usec
导致交换机接口出现（err-disable）的常见原因：
- EtherChannel misconfiguration（端口链路聚合协议（PAgP振荡））
- Duplex mismatch（双工不匹配）
- BPDU port guard
- UDLD（单向链路检测）
- Link-flap error（链路振荡）
- Loopback error
- Port security violation
- DHCP侦听限速
err-disable的原因分析：
1、EtherChannel misconfiguration：以太网信道（EC）的错误配置：
如果要让EC能够正常工作，参与到EC绑定的端口的配置，必须是一致的，比如处于同一个VLAN，trunk模式相同，速率双工模式都匹配等等。如果一端配置了EC，而另一端没有配置EC，STP将关闭配置了EC一方的参与到EC中的端口。并且荡PAgP的模式是处于on模式的时候，交换机是不会向外发送PAgP信息去协商的。这种情况下STP判定出现环路问题，因此将端口设置为err-disable状态
解决办法：把FEC的模式配置为channel-group 1 mode desirable non-silent这个意思是只有当双方的FEC协商成功后才建立channel，否则接口还处于正常状态。
2、Duplex mismatch：双工模式不匹配。
一端配置为half-duplex后，他会检测对端是否在传输数据，只有对端停止传输数据，他才会发送类似于ack的包来让链路up，但对端却配置成了full-duplex，他才不管链路是否是空闲的，他只会不停的发送让链路up的请求，这样下去，链路状态就变成err-disable了。
3、BPDU port guard：BPDU导致
也就是和portfast和BPDU guard有关。如果一个接口配置了portfast，那也就是说这个接口应该和一个pc连接，pc是不会发送spanning-tree的BPDU帧的，因此这个口也接收BPDU来生成spanning-tree，管理员也是出于好心在同一接口上配置了BPDU guard来防止未知的BPDU帧以增强安全性，但他恰恰不小心把一个交换机接到这个同时配置了portfast和BPDU guard接口上，于是这个接口接到了BPDU帧，因为配置了BPDU guard，这个接口自然要进入到err-disable状态。
解决办法：no spanning-tree portfast bpduguard default，或者直接把portfast关了。
4、UDLD：单向链路检测
UDLD是cisco的私有2层协议，用于检测链路的单向问题。有的时候物理层是up的，但链路层就是down，这时候就需要UDLD去检测链路是否是真的up的。当AB两端都配置好UDLD后，A给B发送一个包含自己port id的UDLD帧，B收到后会返回一个UDLD帧，并在其中包含了收到的A的port id，当A接收到这个帧并发现自己的port id也在其中后，认为这链路是好的。反之就变成err-disable状态了。假设A配置了UDLD，而B没有配置UDLD：A给B发送一个包含自己port id的帧，B收到后并不知道这个帧是什么，也就不会返回一个包含A的port id的UDLD帧，那么这时候A就认为这条链路是一个单向链路，自然也就变成err-disable状态了。
5、Link-flap error：链路抖动错误。
当链路在10秒内反复up、down五次，那么就进入err-disable状态。
6、Loopback error：回环错误
当keepalive信息从交换机的出站端口被发送出去之后，又从该接口收到该信息，就会发生回环错误。交换机默认情况下会从所有端口向外发送keepalive信息。但由于STP没能阻塞某些端口，导致这些信息可能会被转发回去形成逻辑环路。端口会因此进入err-disable状态
7、port security:违反端口安全策略
端口安全特性提供了根据MAC地址，动态的对交换机端口进行保护的特性。违反该策略将导致端口进入err-disable状态。由于配置了port-security violation shutdown
err-disable的手动恢复方式：
进入到交换机全局配置模式，执行errdisable recovery cause ?，会看到如下信息：
Switch(config)#errdisable recovery cause ?
all Enable timer to recover from all causes
bpduguard Enable timer to recover from BPDU Guard error disable state
channel-misconfig Enable timer to recover from channel misconfig disable state
dhcp-rate-limit Enable timer to recover from dhcp-rate-limit error disable state
dtp-flap Enable timer to recover from dtp-flap error disable state
gbic-invalid Enable timer to recover from invalid GBIC error disable state
l2ptguard Enable timer to recover from l2protocol-tunnel error disable state link-flap Enable timer to recover from link-flap error disable state loopback Enable timer to recover from loopback detected disable state pagp-flap Enable timer to recover from pagp-flap error disable state psecure-violation Enable timer to recover from psecure violation disable state security-violation Enable timer to recover from 802.1x violation disable state udld Enable timer to recover from udld error disable state unicast-flood Enable timer to recover from unicast flood disable state vmps Enable timer to recover from vmps shutdown error disable state
从列出的选项中，我们可以看出，有非常多的原因会引起端口被置于错误状态，假设导致err-disable的原因未环路，可以直接键入命令：
Switch(config)#errdisable recovery cause loopback #显示被置于错误状态端口的恢复情况
Switch# show errdisable recovery
ErrDisable Reason Timer Status
----------------- --------------
udld Disabled
bpduguard Disabled
security-violatio Disabled
channel-misconfig Disabled
vmps Disabled
pagp-flap Disabled
dtp-flap Disabled link-flap Disabled gbic-invalid Disabled l2ptguard Disabled psecure-violation Disabled gbic-invalid Disabled dhcp-rate-limit Disabled unicast-flood Disabled loopback Enabled Timer interval: 300 seconds Interfaces that will be enabled at the next timeout: Interface Errdisable reason Time left(sec) --------- ----------------- -------------- Fa0/8 loopback 276 Fa0/17 loopback 267 Fa0/20 loopback 250 #从以上显示的信息可以看出，这台交换机有三个端口（Fa0/8、Fa0/17、Fa0/20）会分别在276、267、250秒之后恢复为正常的状态，实际情况也是这样，等了几分钟以后，我们找了一台笔记本电脑，分别接到这几个端口上试了一下，端口都可以正常工作了。这下总算在不重交换机的情况下，将几个处于“假死”状态的端口“拯救”了回来。
通过配置errdisable recovery cause ？恢复err-disable，IOS在一段时间后试图恢复被置为err-disable的接口，这段时间缺省为300秒。 但是，如果引起err-disable的源没有根治，在恢复工作后，接口会再次被置为err-disable。 调整err-disable的超时时间，可以使用以下命令：
w1(config)#errdisable recovery interval ?
<30-86400> timer-interval(sec)
可以调整在30－86400秒，缺省是300秒。
如果产生err-disable的原因是udld，下面有一条命令非常管用：
sw1#udld reset
No ports are disabled by UDLD.