交换网络内的流量异常转发问题

简介:
在一个由2台cisco7609的核心交换机和多台二层交换机组成的三角形网络中出现了流量异常转发问题,下面具体描述该问题。 image  
网络环境描述: 
网络拓扑图如右,2台核心交换机上面配置了vlan198、vlan200以及vlan254,每个vlan的HSRP的active和STP的root都分别强制配置在一起。例如vlan198和vlan254的hsrp-active和stp-root在CSW-A上,而vlan200的hsrp-active和stp-root在CSW-B上。
问题描述: 
172.17.200.30到172.17.254.30的数据包不知道为什么在ASW-2的上联端口能够抓到。查看了CSW上面的HSRP和STP以及ARP表和MAC地址表都没有问题,都显示不应该转发到ASW-2上面。如果说是ARP表和MAC地址表的aging-time不通,导致有可能当mac地址没有条目后广播产生流量,但是这样的话也不可能有这么大这么久的流量持续啊。
今天终于针对这个问题找到原因了,原来是由于v2和v5的hsrp-active不在一起导致的,也就是存在非对称路由。默认情况下,arp的存活时间为4小时,mac存活时间为5分钟。这就会造成当某服务器A的arp表没有超时,但是mac表超时后,交换机就会洪泛到A的数据流。需要注意的是数据流经过一跳时就会将数据包的mac地址段包括源和目的mac地址都需要重写。下面依据上面拓扑图来分析一下:
1),Ser1(1.1.2.30)往Ser2(1.1.5.30)发数据包,Ser1将数据包发往默认网关,也即CW-A的V2网关:
目的mac地址 源mac地址 源ip地址 目的ip地址
M_V2_GW M_Ser1 1.1.2.30 1.1.5.30
2),CW-A接收到数据包进行解包过程,查找路由表(CEF),查找arp表,能找到1.1.5.30的arp表项,依据arp表进行mac地址的重写,然后查找1.1.5.30的mac表项,发现没有此表项即找不到从哪个端口发包(这里假设mac表已经老化),于是进行洪泛到所有v5的端口进行二层转发,数据包为:
目的mac地址 源mac地址 源ip地址 目的ip地址
M_Ser2 M_V2_GW 1.1.2.30 1.1.5.30
3),CW-B接收到洪泛包,解包后发现目的mac地址为M_Ser2(事实上CW-B永远从 数据包的mac地址段看不到M_Ser1的mac地址,因为M_Ser1相关的数据包到了CW-A上面会进行mac地址的重写,将源mac改写成M_V2_GW。除非对Ser1进行arp请求,这是CW-B能从arp的数据报文中读取Ser1的mac地址,更新mac地址表),根据对应的端口直接转发数据包。
目的mac地址 源mac地址 源ip地址 目的ip地址
M_Ser2 M_V5_GW 1.1.2.30 1.1.5.30
4),Ser2接收到数据包进行回应,这里不敷衍了。
这里需要重点注意的是:
数据包到了相应的网关后,网关会根据arp表进行mac地址字段的rewrite。所以网关从mac字段是看不到非本网关网段内主机的mac地址的,只能从arp的影响报文的数据段内找到mac地址。然而arp表的老化时间默认为4小时,mac表的老化时间为5分钟,在不同vlan的hsrp-active布置在不同交换机的情况下,最长就有3小时55分钟相应的mac地址表为空,也就是说在这段时间内相关数据流就会洪泛。
解决方法:
1),将所有vlan的网关布置在同一台交换机上面,这样就没有了负载优势,所有vlan的数据流都由同一台设备进行处理;
2),将arp表和mac表的老化时间调至一致,或者mac地址大于arp老化时间。mac表不老化,从理论上来讲应该就只是占用了tcam条目,应该不会有其他问题,做的时候最好针对各个vlan同时进行arp和mac的clear;
3),静态绑定mac地址或者启用port-security mac sticky特性,甚至与disable-unicast特性结合一起使用,但是未知的意外现象不好估量;
4),服务器上配置脚本每隔4分钟ping一下网关。









本文转自 chris_lee 51CTO博客,原文链接:http://blog.51cto.com/ipneter/92250,如需转载请自行联系原作者

目录
相关文章
|
1月前
|
缓存 人工智能 API
API接口调用中的网络异常及解决方案
淘宝API是淘宝开放平台提供的接口集合,支持商品、交易、用户、营销等数据交互。开发者需注册获取App Key,通过签名认证调用API,结合沙箱测试、OAuth授权与安全策略,实现订单管理、数据监控等应用,提升电商自动化与数据分析能力。
|
5月前
|
Docker 容器
Docker网关冲突导致容器启动网络异常解决方案
当执行`docker-compose up`命令时,服务器网络可能因Docker创建新网桥导致IP段冲突而中断。原因是Docker默认的docker0网卡(172.17.0.1/16)与宿主机网络地址段重叠,引发路由异常。解决方法为修改docker0地址段,通过配置`/etc/docker/daemon.json`调整为非冲突段(如192.168.200.1/24),并重启服务。同时,在`docker-compose.yml`中指定网络模式为`bridge`,最后通过检查docker0地址、网络接口列表及测试容器启动验证修复效果。
1016 39
|
7月前
|
运维 监控 安全
如何高效进行网络质量劣化分析与流量回溯分析?-AnaTraf
在数字化时代,网络质量分析与流量回溯对保障业务运行至关重要。网络拥塞、丢包等问题可能导致业务中断、安全隐患及成本上升。传统工具常缺乏细粒度数据,难以溯源问题。流量回溯分析可还原现场,助力精准排障。AnaTraf网络流量分析仪作为专业工具,能高效定位问题,提升团队响应力,降低运营风险。
如何高效进行网络质量劣化分析与流量回溯分析?-AnaTraf
|
10月前
|
运维 监控 网络协议
面对全球化的泼天流量,出海企业观测多地域网络质量
网络监控与分析在保证网络可靠性、优化用户体验和提升运营效率方面发挥着不可或缺的作用,对于出海企业应对复杂的网络环境和满足用户需求具有重要意义,为出海企业顺利承接泼天流量保驾护航。
478 229
|
6月前
|
人工智能 运维 算法
AI加持下的网络流量管理:智能调度还是流量黑洞?
AI加持下的网络流量管理:智能调度还是流量黑洞?
262 8
|
6月前
|
存储 监控 网络协议
了解流量探针,助你更好地优化网络
流量探针是现代网络运维中不可或缺的工具,用于实时监测网络数据包,提供一手数据。它通过镜像方式采集、过滤、分析流量,支持从二层到七层协议解码,助力网络瓶颈排查、业务性能优化及安全威胁检测。合理部署流量探针可实现精细化网络管理,提升性能与安全性。
|
安全 物联网 物联网安全
量子通信网络:安全信息交换的新平台
【10月更文挑战第6天】量子通信网络作为一种全新的安全信息交换平台,正逐步展现出其独特的优势和巨大的潜力。通过深入研究和不断探索,我们有理由相信,量子通信网络将成为未来信息安全领域的重要支柱,为构建更加安全、高效、可靠的信息社会贡献力量。让我们共同期待量子通信网络在未来的广泛应用和美好前景!
|
11月前
|
运维 监控 安全
公司监控软件:SAS 数据分析引擎驱动网络异常精准检测
在数字化商业环境中,企业网络系统面临复杂威胁。SAS 数据分析引擎凭借高效处理能力,成为网络异常检测的关键技术。通过统计分析、时间序列分析等方法,SAS 帮助企业及时发现并处理异常流量,确保网络安全和业务连续性。
191 11
|
11月前
|
XML JSON 网络协议
【网络原理】——拥塞控制,延时/捎带应答,面向字节流,异常情况
拥塞控制,延时应答,捎带应答,面向字节流(粘包问题),异常情况(心跳包)

热门文章

最新文章