windecember

CCNP授课的附带总结（原创.连载）PART1-交换部分
誉天金牌资深CCIE讲师董老师 CCNP交换部分授课总结
转自誉天董老师博客，誉天IT小吴搜集整理，转帖请注明出处
谢谢大家对誉天CISCO教学组的支持。更多精彩内容亲刚恢复支持可见。

引用:

誉天董老师CCNP路由部分授课总结http://www.51chongdian.net/bbs/viewthread.php?tid=15562

誉天董老师CCNP交换部分授课总结2008新版
http://www.51chongdian.net/bbs/viewthread.php?tid=15563

1）关于TRUNK链路无法建立起来的总结。
     静态配置的TRUNK：
      1。 链路两边的接口是否都被配置为TRUNK模式
      2。 链路两边接口的封装类型是否一致 ：ISL / DOT1Q  
      3。 链路两端交换机的NATIVE-VLAN是否一致，默认都是VLAN1 。如果修改，一定要一致。
      注： C1900系列交换机只支持ISL类型封装 ； C2900XL/C3500XL支持两种类型的封装 ，接口默认为STATIC-ACCESS模式 ，  如果没有指定TRUNK的封装类型，那么默认为ISL；C2950系列只支持DOT1Q的封装；C3550/C3560支持两种类型的封装 ，接口默认为DYNAMIC-DESIRABLE模式，支持动态协商成为TRUNK的机制。

本帖隐藏的内容需要回复才可以浏览

动态配置的TRUNK：
      1。 注意链路两端接口的模式是否满足DTP的规则 （例如：ACCESS - TRUNK ； AUTO - AUTO ； ACCESS - DESIRABLE 肯定不行）
      2。 注意动态协商的TRUNK链路两端交换机的VTP-management-domain-name需要一致。 不然，动态TRUNK无法建立。

1）与DTP相关的4种交换机接口模式和1个选项

现在的新式CATALYST交换机的接口默认都采取动态的模式（C2950/C2960/C3550/C3560），不象原来的C1900/C2900XL/C3500XL采取static access为默认的模式。具体有：
   ACCESS （用于连接终端设备，对于DTP包地处理方式：“不收不发”）

Not send
not receive （not support DTP）
   TRUNK （定义为主干链路，用于承载多个VLAN的信息，
对于DTP包地处理方式：“只发不收”）

send
but
not receive
（support DTP）
   DYNAMIC DESIRABLE （动态模式接口
，比较主动，希望通过DTP机制协商成为TRUNK接口， DTP包地处理方式：“既收也发”）

send
and
receive
（support DTP）
   DYNAMIC AUTO （动态模式接口
，比较被动，希望通过DTP机制协商成为TRUNK接口， DTP包地处理方式：“只收不发”）

not send
but receive
（support DTP）
   NON-NEGOTIATE  (在TRUNK模式下加入此选项使接口不参与协商机制，不发DTP报文)

not send ， negotiation is off
（optional）
zishen

windecember

) 关于VTP裁剪功能实现的思考。

    在思科的交换机中，TRUNK接口默认是用来承载所有VLAN的信息的，换句话说TRUNK接口默认属于所有的VLAN（HUAWEI的TRUNK接口默认不转发任何VLAN信息，必须通过命令指定），因此来至任何VLAN的组播/广播流量将被泛洪到整个交换区域中。LAN的范围越大，TRUNK链路越多，泛洪造成的无谓带宽消耗就越多。 于是通过VTP裁减的功能，交换机只会将组播/广播泛洪到连接有相应VLAN用户的交换机对应的TRUNK接口上，从而减少了无谓流量的传递。
    但是，PRUNING的功能是如何实现的呢？

    个人推论（未找到任何文献证明）。当开启了PRUNING功能后，交换机在洪泛之前要多做一件事情，就是检查MAC-ADDRESS-TABLE，并且只会洪泛到学习到相应VLAN MAC地址的TRUNK接口。对于那些没有学习到关于此VLAN的任何MAC地址的接口，就被裁减了。
    这里的MAC地址条目是通过交换机“原MAC地址自动学习”的功能实现的。是：VLAN - MAC - inboundINF 的3元映射 。




4) 关于VTP多个版本间的区别与VLAN间的关系

    在时下的交换机中（C3550/C3560）有3种VLAN的类型（VLAN-ID：1~4094）：

    1> 标准VLAN    （ standard vlan , vlan-id的范围在1~1005 ）
    其中VLAN1是catalyst交换机的默认VLAN，默认情况下所有的以太接口都属于VLAN1。vlan1也是TRUNK链路默认的NATIVE-VLAN。  VLAN1的ID为1，NAME为default.此信息是无法修改的
    VLAN1002~1005也是默认就有的VLAN，主要是用来提供给TOKEN-RING和FDDI的链路使用的。由于这两种LAN链路技术已经逐渐被淘汰，因此我们很少会使用到这几个VLAN。此信息也是无法被修改的。
    我们可以用来创建/删除和修改的VLAN-ID的范围是：2~1001（定义VLAN名等无聊的事情）

   2> 扩展VLAN    （ extended vlan , vlan-id的范围在1006~4094 ）
扩展范围的VLAN不被VTPv1/v2所支持。可用“SH VLAN SUMM”命令来查看。

   3> 内部VLAN    （ internal vlan ）
既然叫内部，那么内部VLAN是交换机系统自己生成的，不是由我们静态配置的。如何生成呢？当在多层交换机的接口模式下通过“NO SW”命令开启接口的3层功能，系统就会自动地生成internal vlan，默认的VLAN-ID是从1025开始的（被分配出去了的VLAN-ID除外），依次延后。例如：交换机的F0/1 ，F0/11两个接口开启了3层功能。那么，在没有与扩展VLAN-ID冲突的情况下，会自动生成1025，1026两个内部VLAN。

   最近查阅资料的时候发现VTPv1和v2的区别在于，V2能够支持令牌环VLAN的TRUNK学习。VTPv2和VTPv3的区别在于V3能支持扩展VLAN。
   因此对于目前普遍的交换机而言，默认加载的是VTP V1/V2，都不支持EXTENDED VLAN。要新建扩展VLAN就需要不受到VTP的影响，于是可以通过将VTP模式设置为TRANSPARENT来实现。如果使用了最新的IOS，支持V3。那么大可痛快地直接新建。



5) 以太交换机处理帧的4种方式：

     1。泛洪 （  flood  ）

         Unsupported  multicast / broadcast  frame        or        Unknown   unicast  frame   

         以太交换机有3个主要的功能： 1。源MAC地址学习    2。以太帧的转发和过滤   3。通过STP来避免二层的环路   其中的“源MAC地址学习”指的是交换机自动地将接收到以太帧的源MAC地址与接收到帧的入接口绑定形成MAC地址条目，存储到MAC地址表中的过程。注意，通常情况任何设备产生的以太帧的源MAC地址都代表自身这个单一的设备或是单一的某个接口，所以源MAC地址一定是单播地址。因此，交换机也只能动态的学习到单播的MAC条目存储到MAC地址表中。MAC地址表中也不会有组播/广播MAC条目。交换机收到组播/广播帧的处理方式与收到在MAC地址表中没有对应条目的单播帧的处理方式一样，都是泛洪到除入接口之外的所以其他forwarding状态的接口。

     2。过滤   （  filter ）

         Recognized  frame  those  source  port  is  also  the destination  port  should  be  forwarded  to  

         当接收到以太帧的入接口与这个帧通过在MAC地址表中查询得到的出接口是同一个接口的时候，交换机不会转发这个帧，而会将这个帧丢弃，我们称之为“ 以太帧的过滤 ”。这样做的目的很显然是为了避免2层的环路。
         当然，这里所说的是默认情况。应用MAC-ACL ， port-secure , VLAN也可以实现过滤。

    3。 接收   （  receive ）

         Recognized  frame   sent  to  me

         交换机是二层的设备，当它接收到比特流将其解封装到二层格式帧时，如果发现是发给自身或自身所在的范围，也是会欣然接受的。一些交换机开启了CGMP/IGMP-snooping功能，就具备了能力识别和接收一些组播帧，形成一些组播MAC地址条目，而不是一味地将其洪泛。
         例如： 1 . 单播帧发给交换机的SVI  

                    2 . 组播帧发向 01-00-0C-CC-CC-CC ，所有支持CDP/VTP的设备都会侦听和接收这样的报文 。 开启VTP的交换机TRUNK接口和开启CDP的以太口都有能力接收这样的组播帧而进一步解封装到IEEE802。2LLC/SNAP查找OUI和PID来分析具体是什么上层数据。当OUI是00-00-0C，PID是0X2000，代表的是思科CDP的协议帧。注意：在主干链路上传输的VTP帧会被交换机所接收，而在主干链路上被DOT1Q/ISL封装得到的帧会被交换机所转发。这里都是在主干链路上传递的帧，区别在于前者是发送给交换机的，后者是需要交换机帮助转发，而不修改其内容的。

                      3 . 组播帧发向 01-00-0C-DD-DD-DD ，开启CGMP的思科交换机有能力监听这个地址并识别其内容，从而学习或修改组播MAC地址条目。

                    4 . 组播帧发向 01-80-C2-**-**-** ，这个地址是IEEE802.3X（ FlowControl）中定义的“暂停帧”所使用的地址范围。支持并使用“ flow receive on/desired "接口命令的交换机有能力识别这样的报文，并做出相应的处理。

     4 。 转发     （  forward  ）   

           Recognized  frame  not   sent   to  me

           交换机MAC地址表中存在的条目对应的流量都可被识别并转发，无论是单播，组播还是广播，除了发送给交换机自身的。      
      

windecember

6) 交换机中的3种过滤方法：vlan access-map/  Router-ACL/ Port-ACL

   1。vlan access-map

在switch上应用vlan access-map来做过滤（将filter引用到vlan1上），分别针对router的e0/0接口主地址（10.1.1.1）和第二地址（10.1.1.2）。我们观察到来至主地址的流量（10.1.1.1->20.1.1.254）被成功转发（forward）；而来至第二地址的流量（10.1.1.2->20.1.1.254）就被过滤了(drop)。
    "datagram=118."其实是echo报文的默认100byte在以太链路上封装了附加的18byte的header和trailer信息。"2 matches"证明（10.1.1.1->20.1.1.254）的ping包匹配了filter1这个access-map中引用的acl10。

VLAN-ACCESSMAP-0.jpg


VLAN-ACCESSMAP-1.jpg


VLAN-ACCESSMAP-2.jpg


VLAN-ACCESSMAP-3.jpg


VLAN-ACCESSMAP-4.jpg



continue。。。

     在交换机的vlan access-map中添加了一个序号为“1”会被优先处理的option，希望通过mac-acl来实现过滤（仅允许来至aaa.bbb.ccc的以太帧访问）。将路由器的MAC修改为"aaa.bbb.ccc"，而IP地址保持不变。此时重新测试，发现来至主地址(10.1.1.1)和第二地址(10.1.1.2)的流量都能成功访问switch了，因为这些echo报文虽然源IP地址不同，但是都使用相同的源mac地址“aaa.bbb.ccc”, 符合vlan access-map "filter1"定义的规则。

VLAN-ACCESSMAP-5.jpg


VLAN-ACCESSMAP-6.jpg


VLAN-ACCESSMAP-7.jpg

windecember

2。Router-ACL（layer3）3层接口过滤
在switch的SVI vlan1接口上引用ip_acl 30，只允许来至10.1.1.2的流量而阻塞其他所有流量。我们观察到router上的现象，从主地址(10.1.1.1)发出的流量产生"U.U.U"的应答，"U"其实是因为switch上的3层ip_acl 30的阻塞流量而产生应答源的unreachable（type=3,code=13,代表"destination unreachable , administratively prohibited"）报文。 而从第二地址发出的echo报文则被正确转发了。

注意：cisco设备上的3层接口（ 包括：路由器的普通3层接口，交换机上开启3层功能的物理接口以及交换机的SVI），只支持IP_ACL，不能支持MAC_ACL。对IP_ACL同时支持IN/OUT两个方向的过滤。如果在switch上同时引用vlan access-map和在其3层接口上引用IP_ACL，则交换机优先考虑3层接口上引用的IP_ACL，即Router-ACL。

route-acl-filter(layer3)-1.jpg




route-acl-filter(layer3)-2.jpg

wangjia316

谢谢您了~~~~~~~~~~~~~~~~~~~~

Darren-2008

我学学学学学学学

zhangyb526

upupupupupupupupupupupupupupupupupupupupupupupup

pcboy58

绝对要支持的好东西

xzy8088

学习学习！