语音VLAN异常流量分析
2015-08-16 16:20
363 查看
现象描述:有线网络里,接入层交换机上,凡是被划入语音vlan的端口,都会呈现出相同的流量表现,而且瞬间流量都很大,30 - 40 MB级别,对有线网络的稳定性有很大的影响。
设备型号:
IP 电话:Avaya多种型号,以1608居多,call server型号不详,因为不是我负责call server。
接入层交换机:Cisco Catalyst-2960-48TT-L,IOS版本12.2(52)SE
从cacti的图上很明显的看到,所有被划入语音vlan的端口,只要它加了电,不管你终端连的是电话还是电脑,还是只连了电脑,没连电话,只要你划入了语音vlan,只要这个口up了,他就会收到一大堆包。
![](https://images0.cnblogs.com/blog2015/416492/201508/161617082855687.png)
这使得当这种现象发生的时候,大量工位的有线网拥塞特别大,丢包严重,同时交换机CPU负载增高,进而还有一定程度的影响其他VLAN的正常运行。
抓包:
附件里是 .pcapng格式的抓包,可以看到大量的从10.19.90.30 或 10.19.90.35 发来的,去往10.19.107.x , 也就是去往某台电话的流量H.225重传流量,他的目的mac地址是特定的,所以不是广播,但是每台都会收到,这一点让我很疑惑。
需要解决的问题
1) 为什么每个划入语音VLAN的口上的设备都收到这样相同的包。
我自己的猜测是,Avaya的keep alive机制导致的,从附件里的Avaya文档的第4章4.1 里的 Keepalive Mechanisms 来看,如果使用TCP保活,那么CLAN发往phone的包里,源tcp port 是1720, 目的tcp port是随机的,这一点跟抓包内容相符。第二点,保活H.225的内容是empty,这点也是和抓包相符的。如图, 抓包和文档是符合的。
![](https://images0.cnblogs.com/blog2015/416492/201508/161618150829680.png)
![](https://images0.cnblogs.com/blog2015/416492/201508/161618289735069.png)
![](https://images0.cnblogs.com/blog2015/416492/201508/161618510982010.png)
2) 如果第一种猜测成立的话,如何处理保活包堆积的情况,能不能减小窗口时间,对于不回复keep alive的电话,能不能快速踢出,然后让它强制重新注册,以减少重传的次数。
附上抓到的包:
第一次抓到的包,链接: http://pan.baidu.com/s/1qWuW2uS 密码: g15e
第二次抓到的包,链接: http://pan.baidu.com/s/1kTmZlUv 密码: 24gv
最终也没得到Avaya工程师的回复,但是听IT组的人说,Avaya的工程师做了一些操作,但是具体做的啥他们也不知道,这帮不专业的!
附上参考的Avaya官方文档:
https://downloads.avaya.com/css/P8/documents/100017348
主要在里面搜索看 “Keepalive Mechanisms”这一节就好了,讲保活机制的。
设备型号:
IP 电话:Avaya多种型号,以1608居多,call server型号不详,因为不是我负责call server。
接入层交换机:Cisco Catalyst-2960-48TT-L,IOS版本12.2(52)SE
从cacti的图上很明显的看到,所有被划入语音vlan的端口,只要它加了电,不管你终端连的是电话还是电脑,还是只连了电脑,没连电话,只要你划入了语音vlan,只要这个口up了,他就会收到一大堆包。
![](https://images0.cnblogs.com/blog2015/416492/201508/161617082855687.png)
这使得当这种现象发生的时候,大量工位的有线网拥塞特别大,丢包严重,同时交换机CPU负载增高,进而还有一定程度的影响其他VLAN的正常运行。
抓包:
附件里是 .pcapng格式的抓包,可以看到大量的从10.19.90.30 或 10.19.90.35 发来的,去往10.19.107.x , 也就是去往某台电话的流量H.225重传流量,他的目的mac地址是特定的,所以不是广播,但是每台都会收到,这一点让我很疑惑。
需要解决的问题
1) 为什么每个划入语音VLAN的口上的设备都收到这样相同的包。
我自己的猜测是,Avaya的keep alive机制导致的,从附件里的Avaya文档的第4章4.1 里的 Keepalive Mechanisms 来看,如果使用TCP保活,那么CLAN发往phone的包里,源tcp port 是1720, 目的tcp port是随机的,这一点跟抓包内容相符。第二点,保活H.225的内容是empty,这点也是和抓包相符的。如图, 抓包和文档是符合的。
![](https://images0.cnblogs.com/blog2015/416492/201508/161618150829680.png)
![](https://images0.cnblogs.com/blog2015/416492/201508/161618289735069.png)
![](https://images0.cnblogs.com/blog2015/416492/201508/161618510982010.png)
2) 如果第一种猜测成立的话,如何处理保活包堆积的情况,能不能减小窗口时间,对于不回复keep alive的电话,能不能快速踢出,然后让它强制重新注册,以减少重传的次数。
附上抓到的包:
第一次抓到的包,链接: http://pan.baidu.com/s/1qWuW2uS 密码: g15e
第二次抓到的包,链接: http://pan.baidu.com/s/1kTmZlUv 密码: 24gv
最终也没得到Avaya工程师的回复,但是听IT组的人说,Avaya的工程师做了一些操作,但是具体做的啥他们也不知道,这帮不专业的!
附上参考的Avaya官方文档:
https://downloads.avaya.com/css/P8/documents/100017348
主要在里面搜索看 “Keepalive Mechanisms”这一节就好了,讲保活机制的。
相关文章推荐
- Qt中如何用指针返回参数
- Java 中使用内存映射文件需要考虑的 10 个问题
- codeVS第二次月赛 C
- leveldb学习:Versionedit和Versionset
- HDU 1754 I Hate It // 线段树
- 02---CSS整理
- Android使用Universal-ImageLoader在ListView中加载网络图片简单示例
- 基础知识---计算机各层网络协议 (图)
- UVa 1583 - Digit Generator
- SQL数据库的分离附加,导出脚本,备份和还原
- 转:DataTable的Compute方法的应用
- 论文摘要: Multi-view Face Detection Using Deep Convolutional Neural Networks
- C++ 实现单例模式
- oracle 安装问题解决办法大全
- Android 开源框架Universal-Image-Loader完全解析(三)
- hibernate一对一,一对多,多对一,多对多配置
- UVA 193 Graph Coloring
- 1090. Highest Price in Supply Chain (25)
- Android ADB工具-管理设备 app(二)
- Java基础 笔记(2)