交换机中网络环路常见问题详解
以太网中的交换机之间存在不恰当的端口相连会造成网络环路，如果相关的交换机没有打开STP功能，这种环路会引发数据包的无休止重复转发，形成广播风暴，从而造成网络故障。
一天，我们在校园网的网络运行性能监控平台上发现某栋搂的VLAN有问题——其接入交换机与校园网的连接中断。检查放置在网络中心的汇聚交换机，测得与之相连的100BASE－FX端口有大量的入流量，而出流量却非常少，显得很不正常。然而这台汇聚交换机的性能似乎还行，感觉不到有什么问题。于是，我们在这台汇聚交换机上镜像这个异常端口，用协议分析工具Sniffer来抓包，最多时每秒钟居然能抓到10万多个。对这些数据包进行简单分析，我们发现其中一些共同特征。
当时，我们急于尽快抢修网络，没去深究这些数据包的特征，只看到第1点就以为网络受到不明来历的Syn Flood攻击，估计是由一种新网络病毒引起，马上把这台汇聚交换机上该端口禁用掉，以免造成网络性能的下降。
故障排除
为了能在现场测试网络的连通性，在网络中心，我们把连接那栋大楼接入交换机的多模尾纤经光电转换器用双绞线连到一台PC上，并将其模拟成那个问题 VLAN的网关。然后，到现场找来大楼网管员，想让他协助我们尽快把感染了未知病毒的主机查到并隔离。据大楼网管员反映，昨天网络还算正常，不过，当时本大楼某部门正在做网络调整，今天上班就发现网络不行了，不知跟他们有没有关系。我们认为调整网络应该跟感染病毒关系不大。在大楼主配线间，我们把该接入交换机上的网线都拔掉，接上手提电脑，能连通网络中心的测试主机。我们确认链路没问题后，每次将剩余网线数量的一半插回该交换机，经测试没问题则如是继续下去，否则换插另一半，逐渐缩小怀疑有问题网线的数量。我们最终找到一条会引起问题的网线，只要插上这根网线，该大楼网络就会与模拟网关中断连接。经大楼网管员辨认，这条网线是连接昨天在做网络调整的那个部门的。他还说以前该部们拉了一主一备两条网线，应该还有一条，并亲自在那台交换机上把另一条找了出来。随意插上这两条网线中的一条，网络没问题，但只要同时插上，就有问题，哪有在一台交换机上同时插上两条网
线才会激活网络病毒的SYN Flood攻击的？这时我们倒是觉得这种现象更像是网络中有环路。我们到了那个部门发现有三台非管理型交换机，都是串在一起的，然而其中两台又分别通过那两条网线与接入交换机相连，从而导致了网络环路。显然是施工人员对网络拓扑不清楚，当时大楼网管员有事外出，就自以为是地把线接错了，从而造成了这起网络事故。原因找到就好办了，只需拔掉其中一条上联网线即可恢复网络连通。 经过一番周折，网络恢复了正常，但我们还一直在想，是什么干扰了我们的判断呢？
故障分析
一起典型的网络环路故障，用协议分析工具Sniffer抓了这么多的数据包，经过一番分析却没看出问题来。显然，第一眼看到大量的SYN包让我们产生了错觉，想当然地就以为是SYN Flood攻击。事后，我们就这起网络环路故障排除过程做了检讨，重新仔细地分析抓回来的这些数据包，据此解释一下前面提到这些数据包所具有的5个共同特征，以便今后遇到同类问题时能及时作出正确的反应。先看前4个特征：汇聚交换机是网络层设备，该大楼所属VLAN的网络层接口就设置在这台汇聚交换机上，出于实施网络管理策略的需要，对已注册或没注册的 IP地址都进行了MAC地址的绑定。TCP连接要经过3次握手才能建立起来，在这里发起连接的SYN包长度为28个字节，加上14个字节的以太帧头部和 20个字节的IP报头，由Sniffer捕获到的帧长度共为62个字节（不包含4字节的差错检测FCS域）。恰巧当时访问该VLAN的单播帧是来自外网的 TCP请求包，根据以太网桥的转发机制，通过CRC正确性检测后，因已做静态ARP配置，这台汇聚交换机会将该单播帧的源MAC地址转换成本机的MAC地址，其目的MAC地址依据绑定参数来更换，并重新计算CRC值，更新FCS域，经过这样重新封装后，再转发到那栋楼的接入交换机。
再看最后1个特征：网桥是一种存储转发设备，用来连接相似的局域网。这些网桥在所有端口上监听着传送过来的每一个数据帧，利用桥接表作为该数据帧的转发依据。桥接表是MAC地址和用于到达该地址的端口号的一个“MAC地址－端口号”列表，它利用数据帧的源MAC地址和接收该帧的端口号来刷新。网桥是这样来使用桥接表的：当网桥从一个端口接收到一个数据帧时，会先刷新桥接表，再在其桥接表中查找该帧的目的MAC地址。如果找到，就会从对应这个MAC地址的端口转发该帧（如果这个转发端口与接收端口是相同，就会丢弃该帧）。
如果找不到，就会向除了接收端口以外的其他端口转发该帧，即广播该帧。这里假定在整个转发过程中，网桥A、B、C和D都在其桥接表中查找不到该数据帧的目的MAC地址，即这些网桥都不知道应该从哪个端口转发该帧。当网桥A从上联端口接收到一个来自上游网络的单播帧时，会广播该帧，网桥B、C收到后也会广播该帧，网桥D收到分别来自网桥B、C的这个单播帧，并分别经网桥C、B传送回网桥 A，到此网桥A收到了该单播帧的两个副本。在这样的循环转发过程中，网桥A不停地在不同端口（这时已经不涉及上联端口了）接收到相同的帧，由于接收端口在改变，桥接表也在改变“源MAC－端口号”的列表内容。前面已经假定网桥的桥接表中没有该帧的目的MAC地址，网桥A在分别收到这两个单播帧后，都只能再次向除了接收端口以外的其他端口广播该帧，故该帧也会向上联端口转发。
就每个单播帧而言，网桥A重复前面提到的过程，理论上，广播一次会收到21个帧，广播两次就会收到22个帧，…，广播到第n次就会收到2n个帧。总之，网桥A照这样转发下去，很快就会形成广播风暴，这个单播帧的副本最终会消耗完100BASE-X端口带宽。尽管在这期间上联端口会有许多数据帧在相互碰撞而变的不完整，令Sniffer捕获不到，但可以想象得到这个单播帧的重复出现次数仍然会非常多。我们再次检查那些抓回来的数据包，几乎都发现有当时没有注意到的重复标志。按64字节包长来计算，以太网交换机的100BASE-FX端口转发线速可达144000pps。在这种网络环路状态下， Sniffer完全有可能每秒抓到10万多个包长为66字节的数据包。
基于上述理由，由于当时那4台交换机的桥接表中都没有该包的目的MAC地址，处于上游网络的这台汇聚交换机向该大楼发送了一个TCP请求包后，就会不断地收到由该大楼接入交换机转发回来的该TCP包的副本，而且数量非常地多（形成大流量），然而，它并不会把接收到的这些包重发回去；Internet 的网络应用是基于请求/应答模式的，只有发送/接收两条信道都畅通，才能进行端到端的通信。一旦本次网络应用中有一条信道被堵塞了，就会使得该应用因无法进行而结束。网络应用结束后，一般来说，发起请求一方不会就本次应用再次自动发出请求包。于是，在网络环路状态中普遍会有一条信道有大流量，另一条信道几乎没有流量的现象。因为VLAN有隔离广播域的功能，这些大流量不会穿越网络层，所以不会对汇聚交换机造成很大压力。事实上，由于这种网络环路是数据链路层上的故障，只涉及到源MAC地址和目的MAC地址，不管高层封装的是什么类型的包都有可能引起广播风暴。也就是说，当时用Sniffer抓到各种各样的数据包都是有可能的。
故障预防
校园网的接入层是面向用户的网络界面，有许多不可控的成分，情况很复杂，应由专人管理，也应在设备上给予可靠性保证。本搂接入交换机是可管理型的，有STP功能，其他交换机都是非管理型交换机，没有STP功能。本来事先在该接入交换机上配置了STP功能，这起网络事故是完全可以避免的，但不知何故没有这样做，事后再做只能权当“亡羊补牢”了。由此可见，即使接入交换机打开了STP功能，下游网络也会因某种原因构成环路，产生广播风暴，造成对上游网络本VLAN的冲击，故该接入交换机还应有广播包抑制功能，以便能将影响限制在局部范围内。对于下游网络的交换机同样有这些需求，只是成本问题而已。一句话，在网络故障排除时，技术和经验固然重要，但在平时就要注意维护网络的规范连接、落实基本的防范措施更为重要。
绛旓細浜ゆ崲鏈寮曡捣鐨勮矾鐢辩幆璺晠闅滅牬瑙 鍦ㄥ皬鍨嬬綉缁滀腑锛屽湪缁存姢璺敱琛ㄤ俊鎭殑鏃跺欙紝濡傛灉鍦ㄦ嫇鎵戝彂鐢熸敼鍙樺悗锛岀綉缁滄敹鏁涚紦鎱骇鐢熶簡涓嶅崗璋冩垨鑰呯煕鐩剧殑璺敱閫夋嫨鏉＄洰锛屽氨浼氬彂鐢熻矾鐢鐜矾鐨勯棶棰锛岃繖绉嶆潯浠朵笅锛岃矾鐢卞櫒瀵规棤娉曞埌杈鐨勭綉缁璺敱涓嶄簣鐞嗙潿锛屽鑷寸敤鎴风殑鏁版嵁鍖呬笉鍋滃湪缃戠粶涓婂惊鐜彂閫侊紝鏈缁堥犳垚缃戠粶璧勬簮鐨勪弗閲嶆氮璐广傚浣曡В鍐宠矾鐢...
绛旓細杩欎釜鏃跺欙紝浣犲彲浠ワ細1銆乻hutdown 杩欎釜鎺ュ彛 2銆佸疄鏂介鏆存帶鍒 3銆乻panning-tree host 鍏ㄥ眬妯″紡寮鍚 BGDUGARD 浠ヤ笂涓夌鏂瑰紡浣犲彲浠ラ夋嫨 褰撶劧锛屼綘鐨勫眬鍩熺綉涓鐨勭綉缁璁惧閮借鏄疌isco鐨勶紝鍏朵粬璁惧鐨勬娴嬫柟娉曞彲鑳戒笉涓鏍凤紝浣嗘槸鎬濊矾鏄樊涓嶅鐨勩傜湅浜“鎬濈cisco浜ゆ崲鏈鏌ユ壘鐜矾鍙婅В鍐崇殑鏂规硶”杩樻兂鐪嬶細1. ...
绛旓細缃戠粶鐜矾銆佺數婧闂銆佸唴閮ㄦ晠闅滅瓑銆1銆佺綉缁滅幆璺細缃戠粶涓瓨鍦ㄧ幆璺紝浜ゆ崲鏈哄彲鑳戒細闄峰叆骞挎挱椋庢毚锛屽鑷存墍鏈夌鍙ｇ殑鐏兘浜捣銆備細涓ラ噸褰卞搷缃戠粶鎬ц兘鍜岄氫俊銆2銆佺數婧愰棶棰橈細浜ゆ崲鏈虹殑鐢垫簮绾胯矾瀛樺湪鎺ヨЕ涓嶈壇鎴栦緵鐢电數鍘嬭秴鍑鸿寖鍥寸殑闂銆傚鑷翠氦鎹㈡満宸ヤ綔寮傚父锛岀伅鍏ㄤ寒鏄叾涓竴绉嶈〃鐜般3銆佸唴閮ㄦ晠闅滐細浜ゆ崲鏈烘湰韬瓨鍦ㄦ晠闅滐紝渚嬪閮ㄥ垎...
绛旓細鎺掓煡娴佺▼姣旇緝楹荤儲锛岃屼笖灏辩畻鏌ュ嚭鏉ヤ簡锛屼互鍚庝篃鍙兘浼氬嚭鍚屾牱鐨勯棶棰銆傚缓璁綘鏌ュ嚭鐜矾缃戠嚎鍚庡湪浜ゆ崲鏈轰笂鍋歋TP閰嶇疆鏉ラ伩鍏嶇幆璺傚鏋滀竴瀹氳鎺掓煡鍙牴鎹綉缁滄嫇鎵戠粨鏋勪粠涓婂眰寮濮嬫帓鏌 1.鏌ュ嚭鐜矾鍖哄煙銆傚彲浠ヤ粠涓婂眰鍚戜笅鐢╬ing鍖呭姣旂殑鏂瑰紡鏌ュ嚭寤惰繜杈冮暱鐨勫尯鍩 锛堜竴鑸儏鍐典笅鏈缃戠粶鐜矾浜ゆ崲鏈杞彂閫熷害浼氫笅闄嶏級銆2.鍦ㄥ欢杩熻緝闀...
绛旓細鍌荤摐鍨缃戠粶鐜涓鐨勭幆璺鎺掓煡绛栫暐 鍦ㄥ偦鐡滃瀷缃戠粶鐜涓紝鐜矾闂鏃犵枒瀵硅繍缁翠汉鍛樻瀯鎴愪簡鎸戞垬锛屼絾瑙ｅ喅鏂规硶骞堕潪鏃犺抗鍙銆傝繖绫荤綉缁滅敱浜庝富瑕佽繘琛屼簩灞傝浆鍙戯紝缂轰箯鐜矾妫娴嬪拰棰勯槻閰嶇疆锛岀幆璺棶棰樻洿瀹规槗鍑虹幇銆傝澶勭悊杩欎釜闂锛岄鍏堥渶瑕佺悊瑙ｇ幆璺殑鎴愬洜銆佺被鍨嬩互鍙婂浣曞彂鐜板拰澶勭悊銆浜ゆ崲鏈虹幆璺殑褰㈡垚鎵璋撲氦鎹㈡満鐜矾锛屽疄璐ㄤ笂鏄...
绛旓細鍏跺疄 涓嶆槸杩欎釜闂銆傝繖涓笉鏄彨鐜矾锛岀幆璺殑褰㈡垚鏄敱浜庨摼璺啑浣欏憖浠涔堝鏄撻犳垚銆備綘杩欎釜涓浜涚數鑴戣佷細鎺夌嚎 杩欎釜鏄繀鐒剁殑锛屼竴鍙浜ゆ崲鏈瀵逛簬浣犲瘽瀹ら偅绉嶅偦鐡滃紡鐨勮岃█涓鍙板彧鑳芥槸涓涓綉娈电殑銆傝屼綘杩炵殑澶氫釜涓嶄竴鏍鐨勭綉缁銆備竴涓數淇′竴涓牎鍥綉銆傚綋涓鍙拌繛鎺ョ數淇＄殑鍦ㄤ笂缃戞椂鐢ㄧ殑鏄數淇＄殑鑰屽彟涓鍙版牎鍥綉涔熷湪涓婅繖鏃...
绛旓細鍚﹀垯浼氫骇涓や釜涓ラ噸鍚庢灉锛(1)浜х敓骞挎挱椋庢毚锛岄犳垚缃戠粶鍫靛銆(2)鍏嬮殕甯т細鍦ㄥ悇涓彛鍑虹幇锛岄犳垚鍦板潃瀛︿範(璁板綍甯ф簮鍦板潃)娣蜂贡銆傝В鍐鐜矾闂鏂规:(1)缃戠粶鍦ㄨ璁℃椂锛屼汉涓虹殑閬垮厤浜х敓鐜矾銆(2)浣跨敤鐢熸垚鏍慡TP(Spanning Tree Protocol)鍔熻兘锛屽皢鏈夌幆鐨勭綉缁鍓垚鏃犵幆缃戠粶銆係TP琚獻EEE802瑙勮寖涓802.1d鏍囧噯銆
绛旓細鍚敤浜浜ゆ崲鏈虹殑缃戠粶鐜洖鐩戞祴鍔熻兘鍚庯紝鎴戜滑璇ュ浣曞埄鐢ㄧ洃娴嬬粨鏋滐紝蹇熻В鍐崇敱缃戠粶鐜矾寮曡捣鐨勭綉缁滃牭濉炴晠闅滅幇璞″憿?鍏跺疄锛屽浜庝笉鍚岄摼璺被鍨嬬殑浜ゆ崲绔彛锛屼氦鎹㈡満浼氶噰鐢ㄤ笉鍚岀殑鏂瑰紡鏉ヨВ鍐崇綉缁滅幆璺晠闅滅幇璞°備緥濡傦紝瑕佹槸鎸囧畾浠ュお缃戠鍙ｇ殑閾捐矾绫诲瀷涓篐ybrid绔彛鍜孴runk绔彛锛岄偅涔堣绔彛鏃ュ悗涓鏃﹀瓨鍦ㄧ綉缁滅幆璺幇璞℃椂锛屼氦鎹㈡満绯荤粺...
绛旓細缃戠粶鐜矾锛氫氦鎹㈡満涓庤矾鐢卞櫒鐨勨滅敓姝昏冮獙鈥濇兂璞′竴涓嬶紝浜ゆ崲鏈猴紙浜氬綋锛変笌浜ゆ崲鏈猴紙澶忓▋锛夊崄鎸囩浉鎵ｏ紝褰㈡垚涓涓墿鐞嗙幆璺紝灏卞儚浜氬綋澶忓▋鐨勬墜鎸囦氦缁囧湪涓璧枫傚綋涓ゅ彴浜ゆ崲鏈洪氳繃涓ゆ潯缃戠嚎绱у瘑鐩歌繛锛屽氨鍙兘寮曞彂缃戠粶涓殑涓涓毦棰樷斺旂墿鐞嗙幆璺傝瑙ｅ喅杩欎釜闂锛屽氨鍍忚浜氬綋鍜屽濞冩澗寮涓鍙墜锛屼絾杩欏湪鐜板疄涓鐨勪氦鎹㈡満涓栫晫閲...
绛旓細鍒濆鑰呭缃戝挅涓撶敤浜ゆ崲鏈涓嶇啛涔,鎴栬鍥犱负鍚勭被缃戝挅涓撶敤浜ゆ崲鏈鸿澶囩悍姝ф牱,绠＄悊鍛樺線寰鍦ㄨ澶囩綉鍜栦笓鐢ㄤ氦鎹㈡満鏃朵細鍛堢幇瑁呭閿欒銆傛瘮鏂筕LAN鍒掑垎涓嶅噯纭嫑鑷寸綉璺瑺浜,鍩犺閿欒鍦板皝闂,缃戝挅涓撶敤浜ゆ崲鏈哄拰缃戠粶鍗＄殑褰㈠紡瑁呭涓嶅尮閰嶇瓑缂樼敱銆傝繖绫绘瘺鐥呮湁鏃跺緢闅惧彂鐜,闇姹傚繀鐒剁殑缁忓巻绉仛銆傚亣濡備笉鍙互纭繚浣跨敤鑰呯殑瑁呭鏈闂,璇峰厛鎭㈠鍑哄巶榛樿...
