独家发表本人第一篇原创文章哈...!  谄媚 
转载的话，希望加上ipwireless.blog.sohu.com连接哈... 大笑
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
EtherChannel 项目的总结
--By OOZE
 
1.项目需求：
由于网络发展的需要，原有BGP Peering的数量不断的增加，原用于BGP Peering的带宽为100M(瓶颈为Peering Router连接 Transit SW1的FE链路)不足以满足新的Peer的需要。
经过流量的监控，发现Peering Router到L2 Switch的100M链路使用率比较低，于是决定将Peering Router的两条FE链路合并为一条EtherChannel使用，增大其利用率，同时也暂时解决BGP Peering带宽的不足。
 
2.参考拓扑图
Before:
Before
After:
3.项目实施:
 
其实这个项目是很简单的。只需要将原来连接Peering Router和Transit SW1的链路切断，然后分别连接到L2 SWitch上面，再在新链路上做EtherChannel就可以了。
可以参考上面的两张拓扑图。
PS: Distribute Router1和Router2是连接到骨干网络的路由器。
 
4.实际问题：
 
由于在做配置的时候忽略了一下问题，在实际实施当中，碰到了很多的意外。
 
1.3500的EtherChannel：
在尝试使用命令：
interface f0/1
channel-group 10 mode on
发现3500是不支持这个命令的，因为很少做这么旧的设备了，所以在实施当中才发现有这个问题。
开始以为3500是不支持EtherChannel的，后来查了一下Cisco.com，发现3500是支持的，不过命令却不是这个，而是
interface f0/1
 port group 10
没有模式的选择，默认就是on
这样，Peering Router和L2 Switch之间的EtherChannel总算搞定了。
 
2.线缆问题：
在EtherChannel做好了，在L2 Switch上面show cdp neighber，所有的端口都能看到对方了，OK，那就在在Peering Router的EtherChannel下面做子接口，并将原有的所有BGP配置都弄好。
但是所有的BGP邻居都没有起来，一直是Active。这种情况，大概是由于TCP连接不上。由于BGP的邻居在中间的Transit交换机都是通过VLAN来跑的。由于原来的BGP Transit不通过L2 Switch，于是推断在L2 Switch
上面没有这个VLAN。Console到L2 Switch上面，果然，由于原来使用的是VTP Tansparent模式，于是手工加上了该Transit VLAN。这回好了，做好以后，一部分的EBGP邻居起来了，IBGP和另外一部分EBGP却还是
Active状态。这个问题就比较奇怪了！由于是EBGP是
使用直连地址来进行peer的。这部分EBGP如果没有起来的话，肯定链路的问题了。至于IBGP没有起来，估计是IGP方面的问题。
好，先搞EBGP。
由于之前在L2 Switch上面show过CDP neighber，所以就没有检查物理层的问题，直接就检查二层和三层的问题。但是一只都检查不出原因。没有办法，反正找不出原因，就顺便把物理层也检查一遍吧。于是就开始从
Peering Router上面检查。在Peering Router上面show CDP neighbor，发现问题了，只有一个端口上有CDP neighbor，另外一个没有！推断，应该是线缆的问题。没有显示CDP neighbor的那条线缆有问题！但是从
L2 Switch却能看到2个neighbor。原因应该是没有看到邻居的那条UTP Cable中使用的4条铜线，其中从L2 Switch到Peering Router的Tx出问题，但是Rx却没有问题。于是，L2 Switch能看到Peering Router，
Peering Router却看不到L2 Switch。同时，由于是使用了EtherChannel，这样流量会在其中进行负载均衡，所以部分使用那条好的UTP线缆的流量就没有问题，EBGP也起来；但是使用了损坏的UTP线缆的流量就一直不
能通过，EBGP也就一直起不了了把Cable换了，EBGP立马全部起来。
跟着就是IBGP了。
由于IGP和IBGP的密切关系，所以首先检查一下OSPF。果然邻居没有起来。反正现在这些设备是在Downtime，而且production的流量也断了，就直接开debug了。呵呵，立马发现问题：MTU不匹配。看一下相邻的端口的
配置，发现确实MTU确实不一样，修改！好了，这次IBGP也都滴滴答答的起来了。
现在貌似整个项目的骨干配置可以顺利运行了...
该来点修饰了...
 
原来在F2/0/0的FE口上面做了CB-Marking的。人家原来有的衣服，要给人家穿上才行。
class-map match-all INGRESS-DSCP-CLASS
  match input-interface FastEthernet2/0/0
!
!
policy-map INGRESS-DSCP-MAP
  class INGRESS-DSCP-CLASS
   set ip dscp ef
 
将其修改为
class-map match-all INGRESS-DSCP-CLASS
 match input-interface Port-channel10.1
!         
policy-map INGRESS-DSCP-MAP
 class INGRESS-DSCP-CLASS
  set ip dscp ef
就往Peering Router上面塞。这回好了，命令是上去了，但是show run一看：
class-map match-all INGRESS-DSCP-CLASS
  match input-interface Port-channel10
!
!
policy-map INGRESS-DSCP-MAP
  class INGRESS-DSCP-CLASS
   set ip dscp ef
看来是不支持子接口了。没办法，多点就多点吧，整个EtherChannel的流量都抓吧。
然后在子接口上面apply，没有问题。
show policy-map interface
一看，没有traffic被mark！
赶紧到救世主Cisco.com上面查。这一查不要紧啊，才发现7500是不支持在EtherChannel上面set dscp的。硬件的不支持，看来不能在这个陈年设备上面打主意了。
由于原来这个CB-Marking的目的是将所有BGP过来的流量的DSCP设置为ef，大家应该一下就看出，这个Peering Router是个典型的单臂路由的拓扑，所以，如果进出都要通过这个EtherChannel。看来在这个Router上
面真的是没有办法了。鉴于整个链路上面还有其他的Traffic，所以第一个解决方案是想在peering-SW这个3750上面一直做COS，然后在中间的Transit上面都做Trust DSCP一直将其传递到Distribute Router上面再转
换为QoS。但是，由于这种做法，影响到的设备比较多，同时，还是由于那个7500上面的EtherChannel，就取消了这个想法了。下面有COS和QoS的转换配置，存档备用哈。好东西来的。一个QoS高手写的。
class-map l2-to-l3-high
 match cos 4 5
class-map l2-to-l3-med
 match cos 2 3
class-map l2-to-l3-low
 match cos 0 1
!
policy-map input-l2-to-l3
 class l2-to-l3-high
      set ip dscp AF31
 class l2-to-l3-med
      set ip dscp AF21
 class l2-to-l3-low
      set ip dscp AF11
鉴于在这个拓扑中，其他的流量相对来说是很少的，最后就采用了一个比较简单的解决方法。估计大家都能想到，直接就在两个Distribute Router上面抓进来的流量进行Marking算了。
 
终于搞定。真的没有想到一个EtherChannel搞得这么麻烦。老设备真的是不好搞啊。还要前段时间补了一下CatOS，不然估计在这个东西上面还要浪费更多的时间。
 
唉...搞什么也不要搞support啊,和捡破烂差不多...