交换机互联不同vlan及不同网段通信问题总结

交换机互联不同vlan及不同网段通信问题总结作者：北京--慕容第一节前言这几天群里常聊到关于交换机打tag以及两台二层交换机互联不同vlan是否能通的问题，也因此引发了很多讨论，我个人也私底下拿真机充分的做了实验，觉得挺有意思对底层知识也是个考验，但由于情况有好几种，一两句话恐怕说不清楚，正好群里朋友也希望写个总结，所以才诞生这份文档。而文档只有一个目的，就是希望能够让大家一起讨论一起学习，共同进步。不过有个前提是必须先说一下的：我不敢保证文档里所有结果和原理描述都是百分百正确的，毕竟不同产商甚至不同ios版本结果也有可能会稍不一样。换句话说，如果群里任何朋友有任何任何不同的意见和看法，我们热烈欢迎一起讨论，一起更正，一起完善。还是那句话，大家一起进步！在此首先不得不提到的一点是非常感谢尾巴兄弟的辛劳付出，建立56上专属咱们的板块，为我们的共同交流和学习又提供了一个更方便更完善的平台和空间。除了尾巴兄弟当然还有很多其他群里的朋友经常上传文档资料供大家共享，感激的真是无以复加！我也希望我自己在进步的同时也为群里多做出自己的贡献。另外老大文档里提到的技术壁垒我个人也很不喜欢，相信群里很多朋友也很不喜欢，所以，不管别的地方别的群别的圈子有没有，我衷心希望红盟群，咱们，一定不要存在这种现象！大家都是自己人，要是就是敞开心扉的沟通，不计利害的共享，共同进步共同成长！我们是一个团体，就要有团体该有的凝聚力，对技术，我们无比热爱，对朋友，我们肝胆相照，对未来，我们无所畏惧！第二节提出问题这一节的意思是先提出问题和各种情况的拓扑图，也让自己在看整个文档前心里有个数，如果这些问题都能毫不犹豫的回答出来，那基本可以不用往下看，当然，即便这样也希望你能继续看下去，说不定下面有很多问题需要你的指正。不能全部答出来的，可以好好看看下面写的了，有任何意见，想法，都欢迎和我或者在群里一起讨论交流。声明：下面交换机都是二层交换机，接的是PC，只不过图标是路由器。一、两台交换机互联以及一台交换机上不同vlan的情况1、PC1和PC2能不能通？（还要分两种情况，两台PC相同网段和不同网段）2、能不能通？（相同网段和不同网段）3、能不能通？（相同网段和不同网段）4、能不能通？（相同网段和不同网段）5、能不能通？（相同网段毋庸置疑，不同网段怎么通？有几种办法？）6、能不能通？（相同网段和不同网段分别怎么通。--注：是二层交换机）二、下面是两台PC互联以及两台路由器互联几种网段情况1、能不能通？（把20换成21呢？）2、能不能通？3、默认显然不通，有什么办法通？4、把上面的PC换成真的路由器，同样是以上几种网段情况，通的情况又如何？第三节答案（不一定是百分百的标准答案，大家多提意见）一、先说第一部分：首先我谈一下我个人对交换机转发报文最基本原理的理解（当然，这里只说偏低端普通交换机，那些cisco6500，华三9500等等高端交换机可能由于引擎等硬件和软件原因导致报文转发原理和一般交换机会有不同，但那又是另一个层面的问题，在此不讨论）。交换机收到一个报文后（当然，这里还有先成帧，检查CRC等过程就先忽略），会先学习MAC，放入自己的MAC地址表里，然后给报文打上tag（vlan-id），接着查看目的MAC，根据自己的MAC地址表找到此报文的输出接口，如果输出接口是access接口就先把tag去掉再发出去。如果输出接口是trunk，则会保留tag发出去。（即便是二层设备，也可能因为组播，qos等因素会有更多更复杂的过程，在此也忽略。而三层交换机是会去查看三层信息再转发的，在此也不讨论。）所以，其实交换机内部有一个自己打tag的过程，只是普通抓包看不见，有的产商管这叫虚标（当然是和trunk上的tag—实标对应）。当然，这并没有影响我们最常见的认知，即access链路上的报文是没有tag的，而trunk链路上非nativevlan的报文是有tag的。而这一点足以解决第一个图的问题。1、图1：在这里，也要简单说一下ping通信的基本过程。(PS:这个很多面试都会考到，记得当时外包在华为工作时面试官就问了我这么一个题，说三台路由器相连，最左边路由器ping最右边路由器的整个过程，知道多详细就说多详细。那次幸好提前有准备，把每个报文里面的比特位字段的数字都跟他们讲了，就差到操作系统层面了。当然那是运气好，如果问别的底层问题我很可能答不上来，所以，底层真的很重要。)打出ping命令时，操作系统会占用资源调用ping进程封装报文从网卡发出去，但封装报文里面有一个特别重要的字段就是目的MAC。如果目的ip和自己一个网段（网段是自己的ip和mask做与运算出来的结果），接着会直接发送ARP广播请求目的ip的MAC，交换机收到会从同vlan的其他端口发出去，PC收到了回复的MAC，再封装到ping报文里发出去。接下来就是交换机的处理过程，前面已讲。而当目的地收到时，会一级级的往上看，如果目的MAC是自己，就看二层协议字段，根据二层协议字段值交给相应进程比如ip协议，如果目的ip也是自己，会根据三层协议字段交给相应进程比如ICMP协议，以此继续下去。如果不是一个网段，必须有默认网关，接着发送ARP广播请求网关的MAC，所以以后自己发出的任何上层协议报文目的MAC都是网关的MAC，不是目的地的MAC。在图1里，相同网段：PC1发出ARP广播请求PC2的MAC，交换机1在和交换机2互联的链路上发出去的报文是没有tag的，所以交换机2收到后，打上vlan3的tag，然后从所有属于vlan3的接口发出去（当然出去之前除掉tag）。回来也是一样。请求到了MAC，其他通信自然就没问题。不同网段：不同网段必须得有网关。在这里无非也就两种选择，一是PC1和PC2把网关分别设为交换机1和交换机2对应vlan的地址。这种办法我们来看，PC1肯定能请求到vlan2地址的MAC，能发出ping包，到了交换机1以后，先看二层信息，而目的MAC就是自己接口，会去查看三层目的ip，但目的ip不是自己，又没有那个网段的路由，ping包转发不出去。这种方法不行。接下来就是第二种办法，互指网关。PC1得知网关是PC2的地址时，不会管究竟是不是和自己一个网段（在这里和路由器有本质的区别，在第二部分会详细说明）。而是直接请求网关地址的MAC，而交换机1收到ARP广播包只会从其他端口广播（和上面不同的是，第一种办法PC先是请求vlan2地址的MAC，交换机看到ARP报文的targetip是自己接口地址才会回复MAC，而这里，targetip是PC2的地址，所以才会广播）。就这样交换机2接受此广播包，因为targetip也不是自己，发向PC2，PC2看到targetip正是自己，才会回复MAC。当然这里还有一点是，不管是交换机还是PC2，不管targetip是不是自己，首先是已经把ARP广播请求报文里面的senderip和MAC的对应关系加到了自己的ARP表项里了的。所以，当PC2回包的时候是已经有PC1的MAC了的，不需要再发ARP广播请求。这也是我们平时经常见到的第一次ping时五个叹号第一个叹号往往超时，而不是前两个叹号超时的原因。这样PC1知道了网关（也就是PC2地址）的MAC，就会发ping包到网关，目的MAC用网关的MAC封装。而巧合的是，这里的目的MAC和目的ip都是PC2，本来一般情况下，PC1把ping包交给网关，网关再交给目的地。这里，既然都重合了，正好不用转弯了，PC2直接就回复了。（在这里个人觉得是这样，其实PC也好，网络设备也好，都是按程序办事，不会真那么智能，所以PC2收到了报文，看到目的MAC是自己，就拆了看三层目的ip，也是自己，然后看协议类型，是ICMP，交给ICMP进程，继续看ICMP报文的内容，类型为0x8，即回显请求（echorequest），很自然的，自己就会发ICMP回复echoreply）（PS：正因为协议和设备都只是按程序操作，所以能挖出协议程序漏洞的人就可以很容易做破坏式的攻击，相信安全好的朋友势必深谙此道!）有曾经想过第二种办法：分别为vlan2和vlan3设置secondary地址，而且正是对方vlan的地址。这样相当于一个vlan接口有两个地址，以为给交换机加了条直连路由，两个网段就能通。实验证明不行。Ping包到了交换机1vlan接口的时候，根本不会往另外一个网段发，到不了交换机2。而一旦开启三层功能立马就能通。所以，二层交换机即便是一个接口的不同网段也互相通不了。给图1做个小总结：因为access链路上的报文没有tag，所以不管交换机之间accessvlan有多不一样，或者后面再串多少交换机（在这里，交换机2还可以继续接很多），只要保证终端的vlan和交换机上要出去的接口vlan也就是这里的accessvlan一样，相同网段下是可以通信的。要保证这个要一样，是因为默认情况下，二层交换机隔离广播域，拿到一个vlan的数据不管单播组播广播，是不会给其他vlan的。而不同网段的情况，由于必须要有网关，所以得有特别操作才行。而其中一种特别操作是PC间互指网关。2、图2：图3：图4：这三个一起说，因为真的基本就是一回事。先说图2，默认情况trunk下nativevlan就是vlan1（这里默认封装方式为dot1q，如果为思科私有的ISL就没有nativevlan的说法，那种没意思也很少用，不讨论）。然后从交换机1出去的报文打上了vlan2的tag，交换机2收到后显然不会发往属于vlan3的PC2。所以图2肯定是不通的。再说图3，既然由于nativevlan为vlan1导致其他vlan的报文都打了tag，那就修改本地vlan，因为如果修改本地vlan为vlan2，那从vlan2来的报文在trunk链路上是没有tag的。按照这种想法，分别修改交换机1和2的本地vlan，分别为vlan2和vlan3。按理说，现在trunk上的vlan2和vlan3的报文都是没有tag的，相同网段情况下，是可以通信的。但实验做出来是不通的。然后我查了权威资料，原因在于：stp的阻挠。话说，stp协议如果检测到trunk链路两边nativevlan不一样，会将端口置于PVID不一致（inconsistent）状态，而且实验的时候在控制台上也能看到报错。相应的vlan接口物理是up，但协议都是down的。此时此刻它无法转发正常流量，所以连基本的ARP广播请求报文都过不去，更别谈其他通信。然后，显然，需要关闭stp，如果关闭所有vlan的stp，ping完9个包第10个包就开始通（好几次都是这个结果）。当然，为了弄清楚究竟是哪个vlan的stp在阻挠，我又继续按排除法开启vlan，结果是，nativevlan的stp在阻挠，开启vlan1的stp是没有影响的。但一旦开启nativevlan的stp，很快开始报错，通信不正常。所以结论是：如果两边都修改nativevlan（很显然，只修改一边的更不行），必须关闭nativevlan的stp才能正常通信。（至于是不是必须两边都要关，反正我做实验的结果是关闭一边就可以了，但我建议最好两边都关）。声明：这也只是我分别拿两台cisco3560和3750做出来的结果，高端交换机或者华三，华为的交换机是否结果一样，我也不清楚。有设备的朋友可以多试试。通过这个实验我们至少要纠正两种错误观念：一种是很理所当然的觉得既然两边都修改了nativevlan，trunk上这两个vlan都没有tag，肯定能通信；还一种是很简单的认为trunk上nativevlan就得一致，不一致就一定不能通信，但说不出具体是什么东西在阻扰或者索性觉得就是交换机内部机制不用探讨。（PS：任何问题都有理由，总觉得搞清楚了睡觉都踏实些\(^o^)/~）不同网段的情况，跟图1特别类似，办法：互指网关。详细情况就不说了。图4：和图3很类似，方法结果都一样。必须关掉交换机1的nativevlan的stp，关了就能通。不关通不了。3、图5：同一台交换机相同vlan不同网段其实讨论了前面不同网段的情况，图