本文主要是介绍2个区域网络互联后，客户业务中断——排障，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
免责声明
本文旨在提供信息和解决问题的建议，观点和建议可能不适用于个人情况，仅供参考！！！
文章中所有敏感信息已经修改，对于因本文中提供的信息而导致的任何直接或间接损失或损害不承担责任。
使用本文中的信息和建议，即表示您已阅读、理解并接受本免责声明的条款和条件。
场景说明
故障承接上回ACL实现固定时间访问资源——项目，客户2个区域的网络，本来是分开的，现在需要区域1的PC可以访问区域2的server。上篇文章已经说明了，根据客户需求PC在指定时间段可以访问server，在真机环境下测试，可以实现这个功能。现将配置导入现网环境，接上互联线路。
故障情况
将SW1和SW2互联后，客户立刻反馈，区域2下vlan200的PC无法上网；区域1下用户也有用户反馈，内网网站登不上。
网络拓扑
排查过程
客户反馈无法上网后，立刻中断SW1和SW2的互联线路，保证用户业务恢复。中断后，1分钟内，业务恢复正常
初步猜想是否为STP收敛，产生的网络中断。
现网环境
区域1 在G0/0/1上开启了STP disable。
区域2 接入交换机变动频繁，为了防止变动新交换机，产生STP收敛（影响业务），SW2核心以及汇聚交换机上，均将STP关闭了（这样有接入变动，只影响该接入交换机的用户），仅接入和次级接入交换机开启了STP。
该情况导致，每台接入交换机都是根桥，端口状态为指定状态
由于有大量vlan200下的用户上不了网， 且无法通过查看STP信息，查看各接入STP的具体情况。所以，这边我想通过查看日志，看看有没有端口状态迁移，有的话就说明，sw1和sw2互联了，引起了stp收敛。（这边迁移的端口是连PC的端口，当时没注意，认为就是stp引起的网络重新收敛）
从这开始，方向错了，不过还可以接着看，学下思路
因为区域2的核心与汇聚stp全局和接口下都是关闭的，所以当时以为是SW1发送的BPDU透传到接入上，引起的收敛。
后来发现SW1的G0/0/1接口的stp是关闭的，接口STP关闭，交换机不会往外发送BPDU报文，理论上互联也不会接入交换机重新收敛。
所以我在SW2的G0/0/1上抓包查看收到对端传来的STP报文，并在SW1的g0/0/1上开启关闭stp去观察报文接收情况。
抓包发现，不是互联后STP重新收敛了。BPDU都没过去，所以上不了网和STP没关系
（那之前，那个端口状态迁移是啥情况)
重新回去看了一下日志，他确实是MSTP set 端口状态迁移，不过是由于终端的开机关机导致的，是终端的端口状态迁移。
这边查了一下，发现开启了边缘端口，终端的开机关机会报端口状态迁移这个日志。
没开边缘端口，终端的开机关机的日志是up down。（涨知识了）
至此，毫无头绪，断网是啥情况，于是等到晚上，业务系统不再使用的时候，去现网复现这个问题
分割线
复现前准备工作
我们在各网段找了台主机，长ping 网关和baidu.com
（部分网络禁ping ，ping不了百度，这里我们采用telnet baidu.com 443 端口看是否能通）
（这里仅贴出区域2下的PC状态截图)
区域1 区域2 互联前，VLAN200下PC ping 网关可通，ping baidu.com 可解析出域名
互联后，VLAN200下主机断网，ping 网关可通 ， ping 百度找不主机
找不主机，即域名解析失败，是dns的问题。
更换114.114.114.114通用的DNS后，发现可以正常上网。（这里已经确定是某条与DNS有关的策略的问题）
后来，排查发现，SW2有一条策略路由，针对区域2 PC使用的DNS，将下一跳重定向到SW1上去了，PC的流量无法从自己SW2的出口正常出去；从SW1走，也没有路由能从SW1的出口出去，故上不了网。
删除这条策略，网络恢复正常。
原区域1内，有用户反馈，内网网站登不上，后经过排查发现，是巧合情况,实际并不是本次互联导致的。特殊情况，加大了排障范围
这篇关于2个区域网络互联后，客户业务中断——排障的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
