|
|
 |
|
|
| 1. 不知是否是6509的bug？ |
  |
|
 |
|
HP : 0 / 169
MP : 26 / 2553
EXP : 77%
|
|
江湖游侠
成员等级: 7
发表总数: 78
金币总数: 118
所属组别: 普通成员
注册日期: 2003/11/12
|
近日有1台6509好象不太对劲（SUP720，版本12.2(14)SX1）
interface Vlan10
ip address 10.10.10.1 255.255.255.248
no ip redirects
ip route-cache same-interface
end
该vlan下有1个pc可能受到了udp包的攻击，但是奇怪的是这些udp居然被6509送到了所有该vlan的pc机上，导致其他电脑也因处理不过来而网速不正常。
show arp | in Vlan10
Internet 10.10.10.3 4 00d0.f8fb.f7d7 ARPA Vlan10
Internet 10.10.10.1 - 000d.661f.2000 ARPA Vlan10
Internet 10.10.10.6 4 0004.23b9.14f3 ARPA Vlan10
show mac add 0004.23b9.14f3
* 10 0004.23b9.14f3 dynamic Yes 0 Gi1/3
show mac add 00d0.f8fb.f7d7
* 10 00d0.f8fb.f7d7 dynamic Yes 0 Gi1/4
遭攻击的是10.10.10.6，可是10.10.10.3(其他地址也是)上抓包居然也有，都是目的IP为10.10.10.6目的端口为1025或1109的UDP包。
现在先不管攻击的事，我的疑问是：按理6509应该只往Gi1/3送这种单播包啊，为何变成在vlan10的所有端口泛洪了呢？难道是流量太大，还是UDP包本来就是这样处理，或是6509该版本的BUG？
请高手帮忙解答，不胜感激。 |
|
|
|
| 2. Re:不知是否是6509的bug？ |
|
|
|
|
|
HP : 0 / 169
MP : 26 / 2553
EXP : 77%
|
|
江湖游侠
成员等级: 7
发表总数: 78
金币总数: 118
所属组别: 普通成员
注册日期: 2003/11/12
|
目前我的临时解决办法：
mac-address-table static 0004.23b9.14f3 vlan 10 int gi1/3 |
|
|
|
| 3. Re:不知是否是6509的bug？ |
|
|
 |
|
HP : 250 / 1254
MP : 1625 / 21993
EXP : 16%
|
|
迟则生变
成员等级: 51
发表总数: 4877
金币总数: 308
所属组别: 管理员
注册日期: 2003/01/9
|
能不能把你观察到的UDP数据包用sniffer捕捉并传上来？
没有谁能像一座孤岛/在大海里独踞/每个人都像一块小小的泥土/连接成整个陆地/如果一块泥土被海水冲去/欧洲将缺其一隅/这如同一座山岬/也如同你的朋友和你自己/无论谁死了/都是自己的一部分在死去/因为我包含在人类这个概念里/因此我从不问丧钟为谁而鸣/它为我，也为你
No man is an Island, entire of itself; every man is a piece of the Continent, a part of the main; if a clod be washed away by the sea, Europe is the less, as well as if a promontory were, as well as if a man or of thy friends or of thine own were; any man's death diminishes me, because I am involved in Mankind; And therefore never send to know for whom the bell tolls; It tolls for thee.
|
|
|
|
| 4. Re: Re:不知是否是6509的bug？ |
|
|
|
|
|
HP : 0 / 169
MP : 26 / 2553
EXP : 77%
|
|
江湖游侠
成员等级: 7
发表总数: 78
金币总数: 118
所属组别: 普通成员
注册日期: 2003/11/12
|
见附件。
另外要说明的是：由于不想公开企业的IP地址段，因此在上面的描述和附件的抓包中都对目的IP进行了修改，原本都是公网的IP。其他如源IP、MAC等都没变，因此抓包分析中可能会提示数据被破坏，但实际上是因为我替换了目的IP导致的，不影响大家的分析。
请见谅。
谢谢麦子。
 |
下载附件 |
| Snif1.cap ( 下载次数: 41 ) |
|
|
|
|
| 5. Re:不知是否是6509的bug？ |
|
|
|
|
|
HP : 250 / 1254
MP : 1625 / 21993
EXP : 16%
|
|
迟则生变
成员等级: 51
发表总数: 4877
金币总数: 308
所属组别: 管理员
注册日期: 2003/01/9
|
从数据包来看没有什么理由在整个VLAN中泛洪，除非目标地址所对应的端口无法确定，所以请检查一下源和目标MAC地址所属的设备、端口是否正常？有没有可能交换机学不到MAC地址或者MAC地址超出交换机的容纳范围或者MAC地址漂移不定的情况？
没有谁能像一座孤岛/在大海里独踞/每个人都像一块小小的泥土/连接成整个陆地/如果一块泥土被海水冲去/欧洲将缺其一隅/这如同一座山岬/也如同你的朋友和你自己/无论谁死了/都是自己的一部分在死去/因为我包含在人类这个概念里/因此我从不问丧钟为谁而鸣/它为我，也为你
No man is an Island, entire of itself; every man is a piece of the Continent, a part of the main; if a clod be washed away by the sea, Europe is the less, as well as if a promontory were, as well as if a man or of thy friends or of thine own were; any man's death diminishes me, because I am involved in Mankind; And therefore never send to know for whom the bell tolls; It tolls for thee.
|
|
|
|
| 6. Re:不知是否是6509的bug？ |
|
|
|
|
|
HP : 0 / 169
MP : 26 / 2553
EXP : 77%
|
|
江湖游侠
成员等级: 7
发表总数: 78
金币总数: 118
所属组别: 普通成员
注册日期: 2003/11/12
|
你说的这些都已经检查了，所以才怀疑是6509本身的问题。 |
|
|
|
| 7. Re:不知是否是6509的bug？ |
|
|
|
|
|
HP : 250 / 1254
MP : 1625 / 21993
EXP : 16%
|
|
迟则生变
成员等级: 51
发表总数: 4877
金币总数: 308
所属组别: 管理员
注册日期: 2003/01/9
|
如果你去掉命令：mac-address-table static 0004.23b9.14f3 vlan 10 int gi1/3
那么show mac-address-table address 0004.23b9.14f3 指向哪一个端口？多次执行命令输出稳定吗？ g1/3下面接的PC MAC地址确实是0004.23b9.14f3吗 ？
没有谁能像一座孤岛/在大海里独踞/每个人都像一块小小的泥土/连接成整个陆地/如果一块泥土被海水冲去/欧洲将缺其一隅/这如同一座山岬/也如同你的朋友和你自己/无论谁死了/都是自己的一部分在死去/因为我包含在人类这个概念里/因此我从不问丧钟为谁而鸣/它为我，也为你
No man is an Island, entire of itself; every man is a piece of the Continent, a part of the main; if a clod be washed away by the sea, Europe is the less, as well as if a promontory were, as well as if a man or of thy friends or of thine own were; any man's death diminishes me, because I am involved in Mankind; And therefore never send to know for whom the bell tolls; It tolls for thee.
|
|
|
|
| 8. Re:不知是否是6509的bug？ |
|
|
|
|
|
HP : 0 / 169
MP : 26 / 2553
EXP : 77%
|
|
江湖游侠
成员等级: 7
发表总数: 78
金币总数: 118
所属组别: 普通成员
注册日期: 2003/11/12
|
去掉后观察：
show mac add 0004.23b9.14f3
* 10 0004.23b9.14f3 dynamic Yes 0 Gi1/3
好象不太稳定，我不停的运行sh mac命令，好象每次隔那么10s左右就没有该mac了，但马上再运行又有了，而1/3口对接的6509上观察却是稳定的。
按道理没到300s不会自动删除mac表项吧？
#sh mac aging-time
Vlan Aging Time
---- ----------
Global 300
no vlan age other than global age configured
不知道要用什么debug命令来看6509的mac地址学习过程，好象没有3550上类似debug mac-manager的命令。
还请麦子多多指教，谢谢。
|
|
|
|
| 9. Re:不知是否是6509的bug？ |
|
|
 |
|
HP : 0 / 393
MP : 107 / 6434
EXP : 74%
|
|
名动江湖
成员等级: 16
发表总数: 321
金币总数: 576
所属组别: 中级成员
注册日期: 2003/06/7
|
看看你的IOS,我们前一段时间叫CISCO给查的一下也是同样问题(我们用的是7603和6503).
我们发现设了AGING TIME为28800(8小时),但MAC还是在一段时间(远远小于28800)被删出掉了,导致大约有20-30MB的BROADCAST流量.后来CISCO给我们的解释是:ROUTER在判断在一段时间内如果没有到那个MAC的流量,它就会删除MAC,现在的IOS新版本把这个功能给删了,我们升级了IOS后也就没有问题了.
另外,我们还发现SUMMIT SW也有同样问题,到现在还没有个我们一个很好的答复. |
|
|
|
| 10. Re:不知是否是6509的bug？ |
|
|
|
|
|
HP : 250 / 1254
MP : 1625 / 21993
EXP : 16%
|
|
迟则生变
成员等级: 51
发表总数: 4877
金币总数: 308
所属组别: 管理员
注册日期: 2003/01/9
|
softmap:
zl99用的版本上面有：SUP720，版本12.2(14)SX1(好老啊，由于sup720出来的时间还不算长，版本应该多升级)
你碰到的问题是哪个版本下的？ 后来Cisco 让你们升级到哪个版本解决了问题？
没有谁能像一座孤岛/在大海里独踞/每个人都像一块小小的泥土/连接成整个陆地/如果一块泥土被海水冲去/欧洲将缺其一隅/这如同一座山岬/也如同你的朋友和你自己/无论谁死了/都是自己的一部分在死去/因为我包含在人类这个概念里/因此我从不问丧钟为谁而鸣/它为我，也为你
No man is an Island, entire of itself; every man is a piece of the Continent, a part of the main; if a clod be washed away by the sea, Europe is the less, as well as if a promontory were, as well as if a man or of thy friends or of thine own were; any man's death diminishes me, because I am involved in Mankind; And therefore never send to know for whom the bell tolls; It tolls for thee.
|
|
|
|
| 11. Re:不知是否是6509的bug？ |
|
|
|
|
|
HP : 0 / 169
MP : 26 / 2553
EXP : 77%
|
|
江湖游侠
成员等级: 7
发表总数: 78
金币总数: 118
所属组别: 普通成员
注册日期: 2003/11/12
|
看样子要找代理商开case了。
谢谢2位。
另外6509上到底用什么debug命令来看mac地址学习过程啊？
|
|
|
|
| 12. Re: Re:不知是否是6509的bug？ |
|
|
|
|
|
HP : 0 / 393
MP : 107 / 6434
EXP : 74%
|
|
名动江湖
成员等级: 16
发表总数: 321
金币总数: 576
所属组别: 中级成员
注册日期: 2003/06/7
|
这个和IOS BUG有关
CSCef66632 Bug Details
Headline Demand Aging clearing entries every 4 seconds, without contention
Product cat6000
Component cat6000-hw-fwding
First Found-in Version 12.2(17D)SXB02
First Fixed-in Version 12.2(18)SXE, 12.2(17d)SXB09
Release Notes
In specific casses, Sup2/MSFC2 running 12.2(17D)SXB ages entries too fast.
Problem appears to be related to demand againg, as in this case the demand aging timer was set
to 4 seconds, and this was the period entries were being flushed. There is no table contention
during this time.
Currently there is no workaround, execpt to globally disable aging.
可以看看我们的流量图
附带图片
|
|
|
|
| 13. Re: Re: Re:不知是否是6509的bug？ |
|
|
|
|
|
HP : 0 / 393
MP : 107 / 6434
EXP : 74%
|
|
名动江湖
成员等级: 16
发表总数: 321
金币总数: 576
所属组别: 中级成员
注册日期: 2003/06/7
|
我们还在SUMMIT SW上发现同样问题,还没有最后解决
附带图片
|
|
|
|
| 14. Re:不知是否是6509的bug？ |
|
|
|
|
|
HP : 0 / 169
MP : 26 / 2553
EXP : 77%
|
|
江湖游侠
成员等级: 7
发表总数: 78
金币总数: 118
所属组别: 普通成员
注册日期: 2003/11/12
|
原来如此啊，就是说age-time根本没起作用啊。
十分感激。。。 |
|
|
|
| 15. RE: 不知是否是6509的bug？ |
|
|
|
|
|
HP : 0 / 393
MP : 107 / 6434
EXP : 74%
|
|
名动江湖
成员等级: 16
发表总数: 321
金币总数: 576
所属组别: 中级成员
注册日期: 2003/06/7
|
| QUOTE | 原来如此啊，就是说age-time根本没起作用啊。
十分感激。。。 |
也不是说没有起作用,可能是因为开发人员认为,如果一段时间都没有向那个MAC方向的流量,把那个MAC删了,可以节约MEMORY啊,但实际的运用和理论总是有出入的...... |
|
|
|
| 16. Re:不知是否是6509的bug？ |
|
|
 |
|
HP : 0 / 482
MP : 160 / 7281
EXP : 31%
|
|
名动江湖
成员等级: 20
发表总数: 482
金币总数: 786
所属组别: 中级成员
注册日期: 2003/11/12
|
受教受教
有一天，我想象到了自己以后的生活：娶一个姿色平庸但有市户口和固定工作的女人。恩爱个一年半载之后彼此厌倦，她摔碟子我砸碗，她整日以泪洗面怨自己命苦遇人不淑，我每天借酒消愁叹怀才不遇人生苦短。墙角坐着一个屁大的孩子涕泗横流仰天长嚎―――天知道是谁家的孩子？
|
|
|
|
|
|
|
|
HP : 0 / 393
MP : 107 / 6434
EXP : 74%
|
|
名动江湖
成员等级: 16
发表总数: 321
金币总数: 576
所属组别: 中级成员
注册日期: 2003/06/7
|
| QUOTE | | 我们还在SUMMIT SW上发现同样问题,还没有最后解决 |
Extreme通过代理跟我们联系了,是BUG,将在 Extreme Ware 7.3.3的时候解决(估计9月底release),我们用的是7.2.0(b33)
>
>FDB
>If you configure fdb aging time high, about 100,000 seconds, the
>FDB entries no longer disappear earlier
>(PD3-24451351, PD2-248579601). |
17. RE: 不知是否是6509的bug？