运维开发网

【SDN】交换机MTU配置总结

运维开发网 https://www.qedev.com 2020-07-11 12:05 出处:网络 作者:运维开发网整理
本文主旨:好记性不如烂笔头,本文资料源自网络,主要目的为梳理终结,如有侵权,联系必删。   摘要:在使用基于 VXLAN 的 SDN 解决方案时,对物理网络的基本要求是修改 MTU,让其大于1600 (NSX),下面总结了几大厂商不同型号或版本交换机的配置,以后会不断更新,也请有过配置经验的同行帮忙补充。 配置简介:   一般配置 MTU 时,需要配置端到端沿途所有设备,如果源和目标在同一个网

  本文主旨:好记性不如烂笔头,本文资料源自网络,主要目的为梳理终结,如有侵权,联系必删。

  摘要:在使用基于 VXLAN 的 SDN 解决方案时,对物理网络的基本要求是修改 MTU,让其大于1600 (NSX),下面总结了几大厂商不同型号或版本交换机的配置,以后会不断更新,也请有过配置经验的同行帮忙补充。

配置简介:

  一般配置 MTU 时,需要配置端到端沿途所有设备,如果源和目标在同一个网段,则只需要配置沿途所有设备的二层接口MTU。一般按照设备不同,可能需要全局配置 MTU,或者在对应接口上配置MTU。

  如果源和目的在不同的网段内,除了配置沿途所有二层接口 MTU 外,还需配置两个网段网关接口(三层接口)的 MTU。

  一般配置方式是 interface vlan 100,mtu 1600

Cisco系列交换机

Nexus 系列交换机:

参考资料:https://www.cisco.com/c/en/us/support/docs/switches/nexus-9000-series-switches/118994-config-nexus-00.html

  三层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. 
0

精彩评论

暂无评论...
验证码 换一张
取 消