处理网络故障三则

sherryliu

1、组播问题
    用户打电话说局域网内某一个汇聚区域的组播不好用，是在同一个三层交换机下面的。以前给那台汇聚的4507R交换机升级过版本，升级后支持组播了，我以为没有问题了。
    到现场后，看配置没什么问题，在交换机上show ip mroute也是可以看到组播路由的。问用户，说是要在局域网内上一套基于组播的应用，厂家工程师来测试，不好用（因为当时还没有升级交换机），就走了，临走时留下一套小程序和测试说明，只要测试通过，就ok了。打开程序，原来是wsend和wlisten，考IE做实验时用过，设置很简单。测试说明文档中，让组播地址设置成224.0.0.10，端口是8000，进行测试。
    用户打开wsend，我在另一个vlan中打开wlisten，一运行，确实收不到组播包。但是在一个vlan中好用，看似确实跨vlan组播不通，而且show ip mroute能看到239.开头的，没有看到224.的，怪事！
    突然想起来224.0.0.1~255是保留的组播地址，晕！立刻换成239.1.1.1测试，立马通过！该死，怎么把这个给忘了！224.0.0.10应该是RIP2的组播地址吧，交换机收到这个包，因为本机没有起RIP，肯定丢弃了！看来这家做软件的工程师也是个二把刀，怎么留这么个地址涮人。

2、CPU问题
    刚搞定组播，发现4507R交换机的CPU利用率高达99％（这要是股票该多好啊，火箭发射），看进程，又是“老朋友”Cat4k Mgmt LoPri这个进程惹的祸，为什么4000系列的交换机总是出现这种问题呢？一般是因为有网络环路，或者病毒、广播特别多引起的。show interface | in broadcast看到有一个端口的广播特多，而且不断增长，clear count后，还是增长。把那个端口shutdown后，CPU立刻大跌至8％（咋在交换机上设置涨停板啊？），原来就是它！
    把端口up后，限制端口的广播到10％，还是火箭发射，那限制到0，还是热涨！show interface看到广播还在涨，后面有（multicast）的值也在涨，原来是组播太多，不是广播！！！在全局模式下，把组播当成广播来限制，cpu立刻象没燃料的火箭一样下来了。看来就是这样了！

3、访问控制列表问题
    用户反应从其它汇聚区域连SQL服务器没有问题，但是从A区域不行，但是可以ping通。登陆到A区域6509交换机上，发现上面设置了访问控制列表，有1434端口在内。但是用户vlan、上联vlan，核心交换机上的下联vlan都没有加上，为什么？清空acl的计数器，用客户端访问SQL服务器，不通，发现acl计数在增长，显然是受到了acl的限制！这个交换机上联两台6509，上联vlan20、vlan21都没有加acl，用户vlan300，也没加acl。邪了！
    观察路由表，发现原来应该是OSPF默认路由，被修改成静态默认路由，而且是通过管理vlan2的IP地址指定的（管理vlan是和上联交换机管理vlan在二层上是通的），而管理vlan2是加上acl的，看来在这里！把管理vlan2的acl去掉，果然通了！一直以为数据流量是走vlan20、vlan21的，没想到是走vlan2，虽然物理路径是没有走错，但是逻辑路径走错了，所以导致acl把流量限制了。
   


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/4716/showart_201587.html