N7K替换65引发的意外

下载选项

  • PDF     (241.4 KB)
    在各种设备上使用 Adobe Reader 查看
  • ePub     (95.1 KB)
    在 iPhone、iPad、Android、Sony Reader 或 Windows Phone 上使用各种应用查看
  • Mobi (Kindle)     (95.5 KB)
    在 Kindle 设备上查看或在多个设备上使用 Kindle 应用查看
已更新: 2012 年 10 月 18 日

非歧视性语言

此产品的文档集力求使用非歧视性语言。在本文档集中，非歧视性语言是指不隐含针对年龄、残障、性别、种族身份、族群身份、性取向、社会经济地位和交叉性的歧视的语言。由于产品软件的用户界面中使用的硬编码语言、基于 RFP 文档使用的语言或引用的第三方产品使用的语言，文档中可能无法确保完全使用非歧视性语言。 深入了解思科如何使用包容性语言。

当地语言翻译版本说明

思科可能会在某些地方提供本内容的当地语言翻译版本。请注意，翻译版本仅供参考，如有任何不一致之处，以本内容的英文版本为准。

目录

硬件平台

N7K， 6509

软件版本

N7K: 5.2(5)

6509：122-33.SXH5

故障发生前的网络状况：

 

  1. 内部网络分为2个VLAN，分别是办公网（VLAN502）和业务网（VLAN503）；
  2. 网络中所有的4506和2960交换机只提供2层连接）；
  3. 办公网（VLAN502）的网关在办公网防火墙上，由办公网防火墙做NAT地址转换后转为业务网地址（VLAN503）传出，办公网防火墙的网关指向6509(升级后为N7K)的VLAN 503；
  4. 业务网（VLAN503）的主机网关直接指向6509(升级后为N7K)的VLAN503；
  5. 6509(升级后为N7K)上通过默认路由将流量由VLAN503引向外网防火墙。

6509和N7K上interface vlan 503的配置如下：

N7k: 

Ip route 0.0.0.0 0.0.0.0 211.151.203.222(外网防火墙地址) 
interface Vlan503
  description business
  no shutdown
  ip address 211.151.203.194/27
  ip ospf passive-interface
  ip router ospf 1 area 0.0.0.0
  hsrp version 2
  hsrp 503 
    preempt 
    ip 211.151.203.193

6509：

（接口相关的OSPF的配置与N7K上完全一致，此处省略） 

interface Vlan503
  description business
  ip address 211.151.203.194 255.255.255.224
  standby  ip 211.151.203.193 
  
    Ip route 0.0.0.0 0.0.0.0 211.151.203.222(外网防火墙地址)

故障的触发原因：

将6509升级为N7K，所有配置做相应命令格式的转换后从6509完整移植到N7K。

设备升级后的故障现象：

  1. VLAN502上的主机到外网数据传输丢包严重；
  2. VLAN 503上所有主机到外网数据完全中断。

临时解决方案：

  1. 将内网防火墙的网关从N7K转到外网防火墙（如下图）上以后，VLAN502的丢包情况消除。

  2. 检查VLAN503内服务器的配置，发现所有服务器的IP地址都是24位掩码而N7K上VLAN503的地址为27位掩码，将server上的地址掩码改为27位后，VLAN503的数据传输恢复正常。

问题：

  1. 为什么办公网防火墙的网关指向N7K时办公网VLAN502的数据会丢包而业务网VLAN503没有这个问题？
  2. 如果VLAN503里的主机因为某些历史原因IP地址的掩码与网关不一致，为什么用6509做网关就没有问题但用N7K就不行？

诊断：

针对问题1：

  1. 在N7K上用ethanalyzer抓包，发现VLAN503中有大量数据上到CPU，如： 
。。。。
Frame 2 (70 bytes on wire, 70 bytes captured)
  Arrival Time: Jul 19, 2012 02:14:39.862858000
  [Time delta from previous captured frame: 0.000011000 seconds]
  [Time delta from previous displayed frame: 0.000011000 seconds]
  [Time since reference or first frame: 0.000011000 seconds]
  Frame Number: 2
  Frame Length: 70 bytes
  Capture Length: 70 bytes
  [Frame is marked: False]
  [Protocols in frame: eth:ip:icmp:ip:tcp]
Ethernet II, Src: 64:a0:e7:3f:60:c1 (64:a0:e7:3f:60:c1), Dst: 00:10:db:ff:40:90 (00:10:db:ff:40:90)
  Destination: 00:10:db:ff:40:90 (00:10:db:ff:40:90)
    Address: 00:10:db:ff:40:90 (00:10:db:ff:40:90)
    .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
  Source: 64:a0:e7:3f:60:c1 (64:a0:e7:3f:60:c1)
    Address: 64:a0:e7:3f:60:c1 (64:a0:e7:3f:60:c1)
    .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
  Type: IP (0x0800)
Internet Protocol, Src: 211.151.230.194 (211.151.230.194), Dst: 211.151.230.201 (211.151.230.201)
  Version: 4
  Header length: 20 bytes
  Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    0000 00.. = Differentiated Services Codepoint: Default (0x00)
    .... ..0. = ECN-Capable Transport (ECT): 0
    .... ...0 = ECN-CE: 0
  Total Length: 56
  Identification: 0x31a4 (12708)
  Flags: 0x02 (Don't Fragment)
    0.. = Reserved bit: Not Set
    .1. = Don't fragment: Set
    ..0 = More fragments: Not Set
  Fragment offset: 0
  Time to live: 255
  Protocol: ICMP (0x01)
  Header checksum: 0xd564 [correct]
    [Good: True]
    [Bad : False]
  Source: 211.151.230.194 (211.151.230.194)
  Destination: 211.151.230.201 (211.151.230.201)
Internet Control Message Protocol
  Type: 5 (Redirect)
  Code: 1 (Redirect for host)
  Checksum: 0x1261 [correct]
  Gateway address: 211.151.230.222 (211.151.230.222)
  Internet Protocol, Src: 211.151.230.201 (211.151.230.201), Dst: 23.48.17.134 (23.48.17.134)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 40
    Identification: 0x31a4 (12708)
    Flags: 0x02 (Don't Fragment)
        0.. = Reserved bit: Not Set
        .1. = Don't fragment: Set
        ..0 = More fragments: Not Set
    Fragment offset: 0
    Time to live: 125
    Protocol: TCP (0x06)
    Header checksum: 0xe914 [correct]
        [Good: True]
        [Bad : False]
    Source: 211.151.230.201 (211.151.230.201)
    Destination: 23.48.17.134 (23.48.17.134)
  Transmission Control Protocol, Src Port: 3916 (3916), Dst Port: www (80)
    Source port: 3916 (3916)
    Destination port: www (80)
    Sequence number: 383780779
  1. 查看这些数据包，发现它们上CPU的原因是为了在CPU上触发ICMP的重定向消息；
  1. 这些数据包都是从内网防火墙上送过来的，VLAN503里的server没有送数据包到N7K的CPU。

以上三点解释了VLAN502中数据丢包的原因，因为N7K上的COPP会丢弃超限的CPU流量，而这些流量全部都是VLAN502做地址转换后发出的数据包。

* 为什么VLAN503的数据不需要上CPU触发重定向？

到VLAN503的主机（windows系统）上查看相关路由表项，发现这些主机上不仅有默认路由，还有很多到外网的32位主机路由，下一跳指向外网防火墙。很显然，这些32位的路由是windows系统的主机依据N7K发出的ICMP 重定向消息添加的。这些主机在第一次将数据发往自己的网关N7K并收到N7K的重定向消息后就修改了自己的路由表，以后的数据直接交给外网防火墙处理而不再以N7K为网关。

所以问题1的答案是：windows主机会依据ICMP重定向消息修改自己的路由表项而防火墙不会这么做，所以VLAN503的数据只需由N7K的CPU处理一次，而VLAN502的数据则被内网防火墙源源不断地送往N7K的CPU去触发重定向，这些包有很大一部分被N7K依据COPP策略无情地丢弃了。

针对问题2：

问题2的答案其实非常明显，就是代理ARP。ARP-proxy在65的端口上的默认启动而N7K端口上默认关闭，所以即便65上interface VLAN503的IP地址和VLAN503里主机的IP地址掩码不同，它仍然会不辞劳苦地默默为主机提供服务。但在N7K上，在默认关闭proxy-ARP的前提下，N7K因为大家掩码不同而对所有VLAN503内的主机的请求都只是冷眼旁观，失去网关支持的VLAN503中的数据万念俱灰，于是。。。

此文档是否有帮助?

Feedback反馈

联系我们

本文档适用于以下产品