关于在链路聚合下做smart，monitor link的转发测试
这次又要开始瞎折腾了。没事找事了。毕竟我还是很无聊的；
这个实验主要要涉及到以下几个方面：
1、gvrp的应用：
2、Smart Link与Monitor Link的配置；
3、链路聚合；
GVRP（GARP VLAN Registration Protocol) GARP VLAN注册协议
GARP(Generic Attribute Registration Protocol 通用属性注册协议
可以让交换机之间能够相互交换VLAN配置信息，动态创建和管理VLAN，用于只需要对少数交换机进行VLAN配置即可动态的传播VLAN信息；
手工配置的VLAN成为静态VLAN。通过GVRP协议创建的VLAN称为动态VLAN；
GVRP的三种注册模式：
Nomal模式：允许接口动态注册，注销vlan，传播静态vlan信息；
fixed模式：禁止接口动态注册，注销vlan，只传播静态vlan信息；
forbidden模式：禁止该接口动态注册、注销VLAN。不传任何VLAN1以外的任何VLAN信息。
为了提高网络可靠性，通常采用双归属上方式进行组网、
网络中两条上行链路在正常情况下，只有一条处于联通状态。而另一条处于阻塞状态 ，从而防止环路问题。当主用链路发生故障的时候，流量会在毫秒级的时间迅速切换到备用链路，当原主链路回复时候，将维持在阻塞状态，不进行抢占，从而保持了网络的稳定，
monitor link是用于扩展smart link的链路备份的范围
通过监控上游设备的上行链路，而对下行链路进行同步设置。达到上游设备的上行链路故障迅速传达给下行设备，从而触发下游设备的smart link
的主备链路切换，防止长时间因上行链路故障而出现网络故障；
1负载分担；
2提高可靠性，当某个成员接口出故障的时候，流量会切换到其可用的链路上
3增加带宽。总带宽是各成员接口带宽之和
Eth-Trunk工作模式可以分成两种
1。手工负载分担模式：需要手动创建链路聚合组合，并配置多个借口加入到所创建的 Eth-Trunk中
2。静态LACP模式：该模式通过LACP协议协商Eth-Trunk参数后自主选择活动接口；
首先呢，这个是我们这次实验的基本图，这个图就不设置很多套路了。（比如说不会设置vlan），在这个图中呢，预计打算在LSW1和LSW2和LSW3之间设置链路聚合；之后我们在使用gvrp配置下接口状态；（虽然我喜欢手动配置，不过看来还是又要加vlan了）然后在LSW4上设置Smart Link，使其能够快速切换；然后在LSW2和LSW3上设置相应的 Monitor Link，做一个检测作用，当下行链路出现问题时候，使其能够通知上行链路迅速切换；
在这里先补张图，就是我所理解的smart link和monitor link的原理；到时候我们就这么配置；、
（在这里我们不讨论关于生成树的问题，因为默认为我都掌握）
第一步：我们先进行链路聚合：
在我们进行链路聚合前、先用PC1pingPC3。看下报文传播的路径好了；
当我们进行一个简单的抓包之后，就会发现数据报传输的链路；从LSW1->LSW2->LSW3，但是在没有进行链路聚合之前，我们发现：这三条路，会根据生成树协议选择没有阻塞的端口发出，至于什么生成树就不过多解释；
不过我发现一个比较有意思的事情：
在我没有对LSW1做任何手脚的时候：
它的stp是这样的；
1、当我选择把LSW1的e0/0/5端口shutdown，（这个端口是转发数据的端口），数据只会经过很短暂时间的超时：然后马上恢复正常；
（估计1秒都要不到）
这个时候的LSW1已经没有eth0/0/5，而是马上（重点是马上！）根端口变成了eth0/0/6；
2、然后我再次把刚刚shutdown的链路（LSW2的e0/0/2端口）恢复正常后*（undo shutdown），他居然不转发报文了！有点高冷；
3、然后我马上，速度很快很快很快的查看了下stp brief（生成树协议情况），发现eth0/0/5马上出现了。然后又再次变成了根端口，没有毛病啊，依旧处于转发状态啊；但是报文就是一直超时啊。就是ping不通啊；作者表示很尴尬；
4、到现在，都过了3,4分钟了。Pc1还是超时状态；我想了想，貌似也超过stp定时器的delay时间了啊。所以也不应该是生成树重新计算时候导致的链路阻塞；不过就在我准备放弃的时候，尼玛啊，它又通了。打我脸啊、（但是讲真，这个时间真的太久了。）
和前面的做法一模一样，先shutdown交换机LSW1转发数据的端口，这时候报文没有在E5上跑。而是在新晋根端口E6上面跑；
我们可以发现，我们shutdown端口E5之后，报文在E6上跑的很欢！
在这个时候，我再次把e0/0/5打开（undo shutdown）
我们发现，这时候这俩个都动了！都没有任何的数据包从这里转发；这个时候发送的全都是stp的配置信息；但是对于生成树协议来说，没有任何问题；然而他就是不转发；
于是我们抓包：交换机和主机之间的链路：
有从pc1发到pc3的ping请求的报文；但是没有任何应答；
所以，我还是没有发现那里有问题：先把问题丢在这，我很难过！
不过我发现，只要重启下pc1的ping，就又能ping通；
**************************************************
好了，先写会DSP压（he）压（he）惊（da）；
**************************************************
第一步：先进行链路聚合：
[LSW1]interface Eth-Trunk 1 在LSW1上建立eth-trunk1接口 [LSW1-Eth-Trunk1]mode manual load-balance 设置为手工负载分担模式 [LSW1-Ethernet0/0/1]eth-trunk 1 将三个端口添加到eth-trunk1接口 [LSW1-Ethernet0/0/5]eth-trunk 1[LSW1-Ethernet0/0/6]eth-trunk 1[LSW1]display eth-trunk 1 用这个命令可以查询eth-trunk接口下的端口 [LSW1]display interface Eth-Trunk 1 查看s1和s2的eth-Trunk接口的信息
以下两张图是使用这两条命令对相应信息的查看：
[LSW1]display eth-trunk 1
[LSW1]display interface Eth-Trunk 1
将LSW1和LSW2和LSW3之间的链路都进行聚合；
如果只聚合一端的话，将无法通信，会返回：
将所有的链路都进行了聚合：如下图：
现在有一个小问题：如果链路聚合之后，数据包会怎么在聚合链路上转发呢？
在目前看来，当进行了链路聚合之后，报文也只是在E0/0/5上跑。并没有达到均衡负载；
不过当我shutdown E5，然后在undo shutdown E5的时候，PC1pingPC3时候的恢复速度比之前没有做链路聚合的时候恢复的更快；大概是15S的样子；
因为从上面的图看到：只经过了一个延时，说明只可能是RSTP或者是MSTP，不可能是stp，因为STP从去能到转发需要经过2倍的FWDLY；而rstp和mstp只需要经过1倍fwdly；
第二步：发现数据如何在作了链路聚合的隧道上发送
当我们使用PC1pingPC3的时候，我们通过抓包发现：
我们发现：
【1】LSW1和LSW2之间，LSW2和LSW3之间都作了链路聚合，但是发现，在LSW1和LSW2之间报文request和reply报文发送的链路是不同的，但是在LSW1和LSW2之间报文request和reply报文发送链路却是相同的；所以作了链路聚合之后，出现了链路流量分配不均匀；
百度到的答案：负载分担是基于一定特征带哈希选路的，默认是基于SIP、DIP，只有数据流多的时候，才能看出负载分担的效果，一条流肯定就只选一条路了
所以链路聚合之后并不会按照stp生成树的端口来发送数据，而是根据一种算法，先放过这个，先把后面的做完了再说
第三步：配置LACP链路聚合：
因为之前配置了手动模式，如果需要转换状态，就需要全部取消才行；
所以就直接使用了新的拓扑图；
两条链路其中一条链路出现了问题，另外一条备用的链路马上顶替出问题的链路工作，保证是两条链路工作如何实现呢？
开启所有的链路：
[LSW1-Eth-Trunk1]mode lacp---GigabitEthernet0//]eth-trunk --trunk --Eth-Trunk1]max active-linknumber -GigabitEthernet0//]lacp priority -GigabitEthernet0//]lacp priority 设置两个优先级为100的链路，目的是为了确定这两个链路成为活动状态
通过设置。g0/0/1和g0/0/2成为活动状态，。而G0/0/5成为备份链路，当现在的活动链路出现问题时候，g0/0/5成为活动链路但是g0/0/1如果断开在连接，则不会恢复为活跃状态；
当接口数量超出了最大负载阈值时，剩余接口不会转发流量的
第四步：配置Smart Link
Smart link 要注意的地方是：需要关闭stp；
为了提高网络可靠性，通常采用双归属上方式进行组网、
Smart link网络中两条上行链路在正常情况下，只有一条处于联通状态。而另一条处于阻塞状态 ，从而防止环路问题。当主用链路发生故障的时候，流量会在毫秒级的时间迅速切换到备用链路，当原主链路回复时候，将维持在阻塞状态，不进行抢占，从而保持了网络的稳定，
monitor link是用于扩展smart link的链路备份的范围
通过监控上游设备的上行链路，而对下行链路进行同步设置。达到上游设备的上行链路故障迅速传达给下行设备，从而触发下游设备的smart link
的主备链路切换，防止长时间因上行链路故障而出现网络故障；
【1】先取消掉stp：
[LSW1]undo stp enable [LSW1]stp disable
这种时候就会出现路由环路。当我用pc1pingpc3的时候，抓包任意一条链路，都会发现里面的报文成倍的疯长；并且不能ping通；
【2】然后再设置smart link；
[LSW1]smart-link group 1 在LSW1上创建只能链路组 [LSW1-smlk-group1]smart-link enable 开启智能链路
突然发现并不能添加端口进去，提示的是：该端口已经运行在stp下。所以在LSW上关闭stp没啥用啊，还是要进入到每个端口中，停止stp协议；
1 2 3 4 5 6 7 | [LSW1-Eth-Trunk1]stp disable [LSW1-smlk-group1]port Eth-Trunk 1 master 设置eth-trunk为主[LSW1-smlk-group1]port Ethernet 0/0/2 slave 设置Eth0/0/2为辅[LSW1]display smart-link group 1 查看smart-link的主备状态 |
【3】配置回切功能
当主接口出现问题，备份接口变城active状态，当原主接口恢复，主接口不自动回切到active；
需要手工配置回切功能
[LSW1-smlk-group1]restore enable （当主接口恢复的时候自动变成active）
第五步：配置Monitor Link，是用于扩展smart link的链路备份的范围
[LSW2]monitor-link group 1 创建monitor-link分组1 [LSW2-mtlk-group1]port Eth-Trunk 1 uplink 设置上行链路 [LSW2-mtlk-group1]port Eth-Trunk 2 downlink 设置下行链路；
然后ping通。发现超时！但是感觉配置没有问题，于是抓个包看看：
按照这个架势，莫非我中了传说中的广播风暴之毒？~
于是乎，我百度了下，发现了问题所在：
我配置的都是LSW2的本地接口，明显是错误的。
应该配置上行端口或者下行端口，就是对端的端口!
所以重新再做一遍，虽然我LSW2上做的配置都取消掉了。但是任然ping不同， 因为链路上还存在着广播风暴。所以我索性关机，重启，然后整个人都爽了；
但是我发现呢：应该不是上述问题造成的，因为是做了链路聚合的，所以我吧本端和远端都设置为一样的名字；所以问题不是这里的；
可能的原因：
1、之前我没有对LSW3进行相同的配置；导致出现链路风暴；
2、在我对我的LSW2配置之后，广播风暴就已经存在在环路中了。所以有可能是环路风暴导致报文不能正确到达目的地，而我也只是单方面的认为是配置的问题；
3、有可能是我这个地方改错了：
这里我用×××的线标注的地方；我之前手贱就把后面那个1去掉了。但是去掉之后就不能成功ping通。而且正确配置之后还是有这个1；所以我觉得最后一个可能比较大，说明以后还是不能手贱；
最后一步：配置gvrp
又要配置vlan了。表示很不爽；
首先呢：还是给主机和交换机之间的接口设置端口类型为access；并都设VLAN10
交换机和交换机之间的接口设置端口类型为trunk；设置为全通过；
如何配置就不写了；
【1】在出口（就是连接到外界主机的交换机）的LSW1和LSW4配置到如下图所示：
【2】将交换机之间所互联的接口全部设置为trunk并设置为全部通过
【3】在所有交换机上面开启GVRP功能，并在所有交换机两两互联的接口下也开启GVRP功能。
gvrp注册默认模式为Normal模式；
[LSW1]gvrp 在交换机上设置gvrp [LSW1-Eth-Trunk1]gvrp 在聚合链路（trunk）上设置gvrp [LSW1-GigabitEthernet0/0/2]gvrp 在普通端口（trunk）上设置gvrp 【错】[LSW1-Ethernet0/0/3]gvrp 尝试在access端口上设置gvrp 【报错】Info: Not a trunk port; can't specify gvrp!
但是因为我设置的是很简单vlan。所以并不能看出来很好的效果，毕竟这个图主要是为了链路聚合所产生的；
不过最后还是能够ping通的；
【感觉】但是个人感觉这个GVRP并没有很实在的作用的。GVRP是动态祖册，也许是因为我的拓扑图太小；但是总感觉使用动态注册这个模式，花费了很多时间去适应做动态配置所需要的达到的要求；目前感觉并没有很方便；也许我学的不够还没有掌握到精髓吧；
2017.3.15 by：tea
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
