EtherChannel项目的总结

独家发表本人第一篇原创文章哈...!   

转载的话，希望加上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:

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啊,和捡破烂差不多...