一直以来在一个典型的交换三角网络内，存在这样的一个问题：一台没有接入任何一台服务器二层交换机的两个uplink口的RX方向上竟然存在很大的流量。通过在此交换机上抓这两个uplink口的数据包，发现存在很多unicast的包。而从三层交换机上面通过查找arp表和mac表后证明这些数据包不应该会下发到此交换机上。此问题查找了很久都没有找到原因。今天在某朋友的提示下，查看了block-unicast的命令解释。

Understanding How Unicast Flood Blocking Works

You can enable unicast flood blocking on any Ethernet port on a per-port basis. Unicast flood blocking provides you the option to drop the unicast flood packets on an Ethernet port that has only one host that is connected to the port. All the Ethernet ports on a switch are configured to allow unicast flooding; unicast flood blocking allows you to drop the unicast flood packets before they reach the port.

Caution You must have a static CAM entry that is associated with the Ethernet port before you enable unicast flood blocking. If you do not have a static CAM entry that is associated with the port, you will lose network connectivity if you enable unicast flood blocking. You can verify that a static CAM entry exists by entering the show cam static command.

---摘自http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/catos/8.x/configuration/guide/uniflood.html

反正此二层交换机下面没有接服务器，于是便在三层交换机的下联此二层交换机的端口上启用了命令：switch block unicast。然后查看二层交换机的端口速率变化，发现很快速率就降到了300K左右，效果非常明显。呵呵，虽然没有从根本上解决上面描述的流量异常转发现象。

然后我通过在此二层交换机下面接入一台服务器（ip=1.1.1.1）来测试启用block-unicast特性的效果。

1，在没有启用block-unicast特性时，在远端长ping 1.1.1.1，然后在三层交换机上面清除此服务器的mac表项，发现根本没有任何丢包；

2，在启用了block-unicast特性后，在远端长ping 1.1.1.1，然后在三层交换机上面清除此服务器的mac表项，发现time-out了，大概丢包15个。

下面来分析一下原因，也即block-unicast特性的处理机制：在端口A上启用了此特性后，所有发给端口A的数据包都要查看一下端口A的相关mac表项，如果此表项有数据包的目的mac地址，就进行转发；否则丢弃。直到此mac相关的arp表项超时，进行arp洪泛后，交换机学习此mac入mac表，才能通信。

总结：在生产网络上，需要谨慎使用此特性，一般不启用，默认也是不启用。当然在二层交换机的access模式端口可以结合端口安全sticky特性来启用block-unicast。

记得在上一家公司时，出现过交换机突然重启了，配置文件也消失了，所以导致一系列问题等。后来通过查问同事找到了原因，是因为交换机的MODE键抵住了机架，导致重启。而通过按住交换机前面板的MODE键10s后交换机会将配置文件清除，然后重启，也就是说恢复到出厂状态。后来通过查找cisco文档发现有一条命令可以解决这个问题。

全局模式命令：no setup express
解释：
When Express Setup is enabled on a new (unconfigured) switch, pressing the Mode button for 3 seconds
activates Express Setup. You can access the switch through an Ethernet port by using the IP address
10.0.0.1 and then can configure the switch with the web-based Express Setup program or the CLI-based
setup program.
When you press the Mode button for 3 seconds on a configured switch, the mode LEDs start flashing. If
you press the Mode button for a total of 10 seconds, the switch configuration is deleted, and the switch
reboots. The switch can then be configured like a new switch, either through the web-based Express
Setup program or the CLI-based setup program.
......
The primary purpose of the no setup express command is to prevent someone from deleting the switch
configuration by pressing the Mode button for 10 seconds.
    ------摘自http://www.cisco.com/univercd/cc/td/doc/product/lan/cat2940/12113ay/2940cr/cli2.pdf

不过同时想到了另外一个问题：交换机做密码恢复时需要使用到这个MODE键，如果在交换机上面配置“no setup express”后，会不会导致不能进行密码恢复了呢？于是我今天针对这个问题做了一个实验，答案是使用“no setup express”命令与交换机密码恢复不冲突。

下面介绍一下交换机密码恢复过程：

1，按住MODE键（大概10s）同时启动电源，在发现SYST灯经过一段时间闪动后，突然变成黄色，然后马上就变成绿色不闪烁，这个时候松开MODE键；

2，终端上面会出现如下界面：

3，输入“flash_init”命令，初始化后再输入“dir flash:”命令，显示如下：

4，输入“rename flash:/config.text flash:/config.text.renamed”，结果如下：

需要注意的是：有可能当你输入上述命令后，系统会提示错误信息，重新输入就可以了。这个问题我碰到过很多次。

5，然后重启交换机，命令：boot
注意：这个模式下可以通过“help”命令来查看命令。

6，重启后进入系统，这是show run命令查看出来的是初始化配置，所以需要重命名flash:/config.text.renamed文件，命令：rename flash:config.text.renamed flash:config.text；

7，将flash:config.text拷贝到内存中，命令：copy flash:config.text system:running-config；

8，这个时候就可以修改密码了，然后保存就行了。

总结：为了解决交换机通过mode重启导致配置丢失的问题，可以在交换机上面配置"no setup express"命令，这个命令与交换机密码恢复没有冲突。

    这篇文章确实不错，完整仔细地记录了IOS升级碰到的几个问题，值得我学习，所以转载了下来。本文摘自：http://net.yesky.com/94/2534594.shtml

      各公司的网络管理员在选购网络设备的时候都是精挑细选，在同等级别的不同厂商之间反复研究，多次比较后选出最佳性价比的产品来。不过有一点可能很多网络管理员都忽略了，那就是网络产品的未来，一个产品不可能一直使用肯定会有出问题的时候，出问题后厂家的服务就显得尤为重要了。同样网络技术是在不断发展前进的，网络产品也要有一定的可升级可扩展性。最近笔者就遇到升级核心设备的问题，现记录如下:

　　一，升级环境:

　　事情的原因是这样的，公司下属部门申请到一定的经费用于网络升级，因此该部门前几天新买了一台思科的Catalyst6509交换机，并且配备了WS-X6548-GE-TX这个思科在去年四月才新推出的10M、100M、1000M自适应的48口RJ-45交换模块。6509一共有9个插槽，所以可以插上9个模块，为核心设备升级添加模块是习以为常的事情了。不过由于思科的软件推出总是滞后于硬件，所以拿到手的Catalyst6509交换机标准配置的12.2(14)SX1版本的IOS并不能支持该模块。这就涉及到了升级问题，需要升级6509交换机的IOS。于是我和子部门网络管理员从CISCO官方网站找来支持WS-X6548-GE-TX模块的新版本的IOS准备升级。没有想到，这次简单的升级工作却弄得我们两个“准高手”麻烦连连，问题接二连三地出现。

　　二，没有RJ-45接口

　　对于本次采用的这个WS-X6548-GE-TX模块一共有48个RJ-45端口，然而6509交换机又没有配其他的带RJ-45接口的模块。这可怎么办呢?毕竟用思科的TFTP Server升级IOS就必须得将交换机和网络上的一台装有TFTP Server的PC相连。经过一番寻找，终于发现超级引擎720上面有一个RJ-45模样的接口，旁边写着Link的字样，结果拿来网线插上一试，发现指示灯都不亮。本来我们两个以为有了希望，然而指示灯不亮就说明该接口无法使用，不过因为这个接口是惟一的希望，否则只能用xmodem方式传输41MB的IOS，传输时间恐怕让我望而却步。

　　小提示:

　　使用XMODEM传输IOS速度上是非常让人头疼的，笔者曾经用XMODEM方式传过一个2950交换机的IOS，总容量也就2MB左右，足足用了两个钟头。按照这个速度来说41MB最快也得30几个小时。

　　既然使用XMODEM方式传输IOS不太现实，那么还要从超级引擎720上面那个RJ-45模样的接口入手。从网上搜索到相关资料，原来超级引擎720上的port2 有两种模式:一种是RJ-45接口，还有一种是SFP(a small form-factor pluggable)接口。而默认的设置是SFP，要使用RJ-45接口就必须更改设置。输入以下命令进行修改——

　　Router(config)#interface gigabitethemet 5/2

　　//进入该接口进行设置

　　Router(config-if)#media-type rj45

　　//修改模式为RJ45，默认是SFP

　　Router(config-if)#no shutdown

　　//启用该接口

　　执行命令后发现橘红色的指示灯终于变成了绿色，接下来就可以使用传统的TFTP方法将升级所需的IOS文件传到到交换机中。本来以为接下来的事情就应该很轻松，谁知道拦路虎并没有就此罢休。

三，TFTP传输协议不支持32兆

　　接下来给接口配上管理地址，再把原来的IOS备份出来。在超级终端全局模式下输入命令:

　　Router#copy sup-rootflash: s72033-pk9sv-mz.122-14.SX1.bin tftp://192.168.1.1

　　TFTP Server 出现一连串#字号，开始传输数据，本来以为一切OK。谁知道眼看着就要传完的时候，系统提示:“timeout! Write error!”。

　　根据系统提示的信息我查询了网线是否断了，磁盘空间是否不足，答案都是否定的。再次执行传输命令故障依旧。到6509上查看传输完毕的IOS大小为32MB，比完整的IOS32.1MB稍微小一点。为什么多出的0.1MB就无法传送呢?

　　开始以为是TFTP的软件有问题，版本过低造成的。从网上下载了一个第三方的TFTP server一试，结果还是这样。又找来3Com的TFTP Server，这次效果更差，传到16MB的时候就断开了，系统提示还是超时和写入错误。仔细分析，终于发现了问题关键所在。两次传输，一次正好32MB，一次正好16MB，连字节数都不差，肯定不是传输线路问题。找来资料一查，原来TFTP(Trivial File Transfer Protocol)普通文件传输协议最大就支持传输32MB的文件。于是又找来思科文档，一番查询，找出了第2种解决方法，用FTP就行了。于是在PC上建好FTP服务，键入如下命令:

　　Router# configure terminal

　　//进入交换机配置模式

　　Router(config)# ip ftp username username

　　//设置FTP的访问用户名

　　Router(config)# ip ftp password password

　　//设置登录FTP的密码

　　Touter(config)# end

　　//结束，退出

　　Router#copy sup-bootflash:s72033-pk9sv-mz.122-14.SX1.bin ftp:[//[username[:password]@]192.168.1.1]

　　//执行FTP传输命令将原有bin文件上传到FTP，传输文件为s72033-pk9sv-mz.122-14.SX1.bin，FTP服务器地址为192.168.1.1。

　　使用FTP传输更新IOS后文件复制非常正常，等待了几分钟，系统提示“successful!”。看来FTP比TFTP就是强大灵活，限制也少很多。

四，协议错误

　　将IOS成功备份到FTP上后就轮到将新的用于升级的IOS进行上传了。进入6509配置模式使用如下命令进行操作:

　　Router# configure terminal

　　//进入配置模式

　　Router(config)#ip ftp username username

　　//设置登录FTP的用户名

　　Router(config)#ip ftp password password

　　//设置登录FTP的密码

　　Router(config)#end

　　//退出设置

　　Router#　copy　ftp:[[//[username[:password]@192.168.1.1] / s72033-jk9o3sv-mz.122-17a.SX.bin] sup-bootflash:

　　//复制s72033-jk9o3sv-mz.122-17a.SX.bin新版IOS到本交换机。

　　本来以为轻轻松松完成的，结果系统这次提示“Protocol error!”。协议错误?重试一次，下载没有问题的，上传还是提示协议错误。经过笔者分析怀疑问题可能出在FTP Server上，我的FTP Server是用Server-U这个第三方软件做的，会不会是兼容性问题造成的呢?于是换成微软Windows2000自带IIS中的FTP组件建立FTP服务器。再次尝试下载与上传都没有任何问题了，不再提示协议错误。屏幕显示Loading…。几秒钟后又出现提示信息:“Flash空间不足”。

　　五，Flash空间不足

　　出现FLASH空间不足信息后我特别查询了6509核心设备的硬件配置，默认6509标准配置的Flash为64MB，标配IOS大小为32.1MB，要升级的12.2(17a)SX 版本IOS大小为40.6MB，这样看来空间不足再所难免。但是这个问题还是相对好解决的，将Flash里原来的IOS删除了然后再上传。于是输入命令:

　　Router#delete sup-bootflash:s72033-pk9sv-mz.122-14.SX1.bin

　　然后再传。提示信息还是空间不足!这个时候交换机的IOS已经被我删除了，要是不小心掉电或者重起的话，交换机就起不来了。在管理界面中用show命令看，IOS文件已经没有了，但是空间还是剩余30多兆，就是说flash没有被清空。这时候想起以前删除vlan.dat文件后要重启交换机才能生效，可是现在重启是万万不行的。怎么办?上思科网站查找有利用价值的信息，终于找到一条命令squeeze，该命令是将已经删除的文件彻底清空，就好比清空回收站一样。运行:

　　Router#squeeze sup-bootflash:后再用SHOW命令查看，发现Flash已经被彻底清空，可用空间为64MB。这时候再用FTP上传，几分钟以后就会看见屏幕上提示的成功信息。Reload一下，用show flash命令看IOS版本已经变成了12 .2(17a)SX。插上新模块WS-X6548-GE-TX一试，一切OK，新模块可以正常运行了。

　　经验总结:

　　本来以为轻松完成的工作却是一波三折，看来高端产品升级也是非常复杂的，很多原来没有重视的环节都会出现这样或那样的问题。本次故障排除使我也明白了一个道理，技术没有尽头，遇到问题到官方网站查询是最好的办法。还有就是做事情之前一定要三思，如果删除FLASH后想当然的执行了RELOAD的话，交换机就无法启动了，那样的后果将会非常严重。操作前请停手思考30秒往往可以减少很多不必要的损失.

                                                                                     ------转载于：http://net.yesky.com/94/2534594.shtml

今天拿来了一台3750-24TS，查看了一下版本，发现还是使用的ipbase的，所以想升级一下ios。
结果连续几次都出现问题：刚开始传输还比较顺畅，只是有点慢，后来就干脆丢包，然后就是失败。
然后查看了一下flash(Command: dir)，发现原来是空间不够了。
所以只好是覆盖当前的ios了。

使用命令：
Switch#archive download-sw /overwrite tftp://a.b.c.d/c3750.****.tar

回车后现象如下：
1，文件上传；
2，examining image；
3，删除old image；
4，然后就是extracting tar里面的文件了；
5，完成。

可以通过dir命令检查一下flash情况，确保image文件没错，就可以重启了。

最近发现核心交换机有几个下联二层交换机的端口出现了很多丢包，从监控平台上显示如下：

 
显示为7609的receive discards，登陆上交换机查看端口如下：
 
从上图中看到有很多数据包overrun（2294627），说明此端口的buffer已经耗尽，其将此buffer里的数据送往PFC的速度慢于此端口的接收数据报的速度，因此这些数据报就会丢弃，如上图Input queue有2289265 drops。overrun的官方解释如下：

Q. What are overruns on a serial interface?

A. Overruns appear in the output of the show interface Serial 0 command when the serial receiver hardware is unable to hand received data to a hardware buffer because the input rate exceeds the receiver's ability to handle the data.

This occurs due to a limitation of the hardware. Overruns occur when the internal First In, First Out (FIFO) buffer of the chip is full, but is still tries to handle incoming traffic. The serial controller chip has limited internal FIFO.

Some chips, for example, have only 256 bytes of buffer space. Data from the network is received into the buffer, whereupon the chip attempts to move the data from the buffer to the router's shared memory for the CPU to process. If the chip is not able to move the data from its internal FIFO buffer into shared memory faster than the rate at which data is received on the interface, then the internal FIFO buffer is full, incoming data is dropped, and the overrun counter is incremented.

------------摘自http://www.cisco.com/en/US/tech/tk801/tk36/technologies_q_and_a_item09186a008014f919.shtml

而同时由上图可以看出此端口没有启用flow-control特性，flow-control的官方解释如下：

因此启用flow-control特性可以避免overrun的现象。但是从根本上来考虑此端口为GE端口速率为1000Mbps，且为full-duplex。而且当时此端口的input速率为22.8Mbps，远没有达到GE的上限。而从硬件架构来看，也远没有达到瓶颈。下为硬件参数显示信息：

 
查看了一下此板卡WS-X6548-GE-TX的结构图，表示每连续8个GE端口共享1G，而且此8GE端口共享16KB的RX BUFFER和1M的TX/RX BUFFER。所以从结构上来看，应该没有达到性能瓶颈的。

补充：

本周通过与cisco case中心交涉，提交几个show命令显示结果给case中心，然后在case中心的协助下：完成以下2种测试：

1，disable head of line blocking which will utilize the interface buffers instead of the
shared buffers.  This will result in only the single over utilized port having drops。查看了一下cisco网站，意思就是说启用head of line blocking使得此8个一组端口的每个端口都启用自己的32kb buffer，而不使用共享的1Mb buffer，这样就能看出到底是哪个端口overrun比较多。详见http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00801751d7.shtml
配置命令如下：
6500(config)#service internal       //此命令表示可以启用内部命令，注意内部命令TAB或者？都无效，直接敲入就是了。
6500(config)#interface gigabit 1/1
6500(config-if)#hol-blocking disable
%HOL Blocking is Disabled on: Gi1/1 Gi1/2 Gi1/3 Gi1/4 Gi1/5 Gi1/6 Gi1/7 Gi1/8
这样可以找出来到底是哪一个端口过多overrun，然后将此端口挪到另外一组去。

2，try to config "hold queue 4096 in" to raise the hold queue. please refer to :
http://www.cisco.com/en/US/docs/ios/12_3/interface/command/reference/int_d1g.html#wp1142192
在软件队列处理上通过“hold queue 4096 in”将端口的hold queue调高，看看是否有效果。实际上没有多大效果，依然有很大的丢包。

综合以上测试，case中心给出答复如下：
丢包现象为WS-X6548-GE-TX板卡性能瓶颈所致，即WS-X6548-GE-TX的端口buffer太小，请换成6148A或者6748板卡。下面比较一下此三个板卡的硬件架构：
1），X6548-GE：每8个端口（1-8，9-16，17-24...）共享16KB RX buffer和1MB的RX/TX buffer，并且每8个端口共享1GE带宽，此板卡为fabric-enabled，可以与引擎通过一个8GE的CrossBar或者32GE的系统共享Bus相连；
2），X6148A-GE：每8个端口共享160KB RX buffer，每一个端口独享5.2MB的TX buffer，并且每8个端口共享1GE带宽，但是此板卡为nonfabric-enabled，只能通过32GE的系统共享Bus相连；
3），X6748-GE：每个端口独享166KB的RX buffer和1.164MB的TX buffer，并且此板卡为fabric-enabled，可以与引擎通过每24个端口（1-24，25-48）共享20GE的CrossBar相连或者48GE端口共享32GE的系统共享Bus相连。

在文章Catalyst 6000 family Architecture提到过SFM(switch fabric module)，这里具体讲述软操作方面的知识。

在一个安装了SFM的交换机上，有如下三种switch modes：
1，compact mode---这种模式用于处理仅仅安装了fabric-enabled modules的交换机（没有安装nonfabric-enabled modules）上fabric-enabled modules之间的数据转发，只需要在switch fabric channel上传输DBus header；

2，truncated mode---这种模式用于处理同时安装了fabric-enabled modules和nonfabric-enabled modules的交换机上的fabric-enabled modules之间的数据转发，只需要在switch fabric channel上传输the first 64 bytes of the frame；
3，bus mode---这种模式用于处理fabric-enabled modules和nonfabric-enabled modules之间以及nonfabric-enabled modules之间的数据转发，在switch fabric channel上传输整个数据帧。

配置命令如下：

Router(config)# [no] fabric switching-mode allow {bus-mode | {truncated [{threshold [number]}]}
此命令注意点：
When you enter the ‘no fabric switching-mode allow bus-mode’ command, power is removed from any
nonfabric-enabled modules installed in the switch.
即‘no fabric switching-mode allow bus-mode’ 命令会导致所有nonfabric-enabled modules掉电，所以请慎用！！！

Router(config)# fabric required
此命令注意点：
If you enter the ‘fabric required’ command on a switch that does not have a Switch Fabric Module
installed, all modules except the supervisor engine turn off.
即‘fabric required’命令会导致在没有SFM或者SFM失效的交换机上除了引擎板卡外，其它板卡全部掉电，所以请慎用！！！

监控命令如下：show fabric ? 即可以查看很多信息。

1，首先回顾一下TCP协议：

TCP数据包中有六个标志位(Code Bits)：6 位标志域。表示为：紧急标志、有意义的应答标志、推、重置连接标志、同步序列号标志、完成发送数据标志。按照顺序排列是：URG、ACK、PSH、RST、SYN、FIN。在整个TCP数据传输过程中ACK位除了在第一次握手的时候置位为0外，其他任何时候都置位为1。
三次握手过程：

在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。

第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；

第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；

第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

2，再次拿一个ACL来举例说明（摘自TCP/IP路由技术 第一卷 第556页）：

假设你实现了一个访问列表可以阻止外部发起的TCP会话进入到你的网络中，但是你又想让内部发起的TCP会话的响应通过，那应该怎么办？通过检查TCP段头内的ACK和RST标记，关键字established可以实现这一点。如果这两个标记都没有被设置，表明源点正在向目标建立TCP连接，那么匹配不会发生。最终报文将会在访问列表中的后继行中被拒绝。示例如下：

access-list 110 permit tcp any 172.22.0.0 0.0.255.255 established

access-list 110 permit tcp any host 172.22.15.83 eq 25

access-list 110 permit tcp 10.0.0.0 0.255.255.255 172.22.114.0 0.0.255 eq 23

第1行：如果链接是从网络172.22.0.0发起的，那么允许从热和原电到该网络的TCP报文通过；

第2行：允许来自任意源点，且目标端口号是主机172.22.16.83的端口25的TCP报文通过；

第3行：允许来自网络10.0.0.0，去向网络172.22.114.0/24且目标端口为23的TCP报文通过。

通过上面的ACL，大家有没有注意过，一个从any到172.22.15.83的25端口的连接，TCP的三次握手，第一次握手肯定是需要匹配第2行ACL，因为此报文的标志位ACK置位为0，不能匹配第1行ACL。但是此会话的后面的所有数据报文都会匹配第1行了，因为此报文的标志ACK已经置位为1了。这里是否有问题，请相关牛人鉴定！

3，ACL对分片包的处理（摘自一英文技术宝典，经我翻译如下）：

当一IP包被分片时，仅在第一个分片中包含所有三层与四层信息，而后续分片则只包含三层信息，四层信息丢失。

ACL的处理机制：

对于permit ACEs：当第一分片被匹配上后，后续分片也会匹配上（不检查四层信息）；

对于deny ACEs：所有分片都要检查三、四层信息。实际上，对于deny ACEs，当第一分片被匹配上后被丢弃，而后续分片由于无四层信息则不能匹配该deny ACEs，可能在后面检查时允许通过，则传到目标地后，由于不能进行重组而被丢弃。但这样占用了带宽及目标主机的CPU。

综合以上，根据3，是否可以判定ACL的处理机制有点smart，它可以根据每条ACE条目记录某一个时段的匹配内容，匹配内容主要包括源和目标IP地址，甚至端口号（tcp条目），从而不会将流量报文匹配错。也就是说根据2说的同一会话的后续报文不会去匹配第1行ACL，而根据ACL的记录内容去匹配第2行ACL。

以上纯粹是我个人针对ACL的分析，有任何不对或者有争议之处，还请牛人指正，不胜感激！！！

关于在vlan的接口上使用ACL配置的方向问题，在几个专业论坛里面看到经常有人提起。在这里我总结一下。还是举例说明吧。

1，拓扑图如：

Host_A(1.1.1.1) <------> (1.1.1.2)E1:SW:E2(2.2.2.2) <------> (2.2.2.1)Host_B

需求（由于是说明ACL放置接口的方向问题，所以需求简单一点）：

只允许Host_A访问Host_B，其他访问Host_B的拒绝。

所以在SW上面可以配置如下：

ip access-list extended to_host_b

permit ip host 1.1.1.1 host 2.2.2.1

int e2

ip access-group to_host_b out

这里可以明显的看出方向使用out方向，我知道ACL用在硬接口上面大家都很容易理解，一般都不会弄错。下面说明怎么理解ACL配置在vlan接口上。

2，拓扑图如：

Host_A(1.1.1.1) <------> (1.1.1.2)vlan1:SW:vlan2(2.2.2.2) <------> (2.2.2.1)Host_B

需求（由于是说明ACL放置接口的方向问题，所以需求简单一点）：

只允许Host_A访问Host_B，其他访问Host_B的拒绝。

所以在SW上面可以配置如下：

ip access-list extended to_host_b

permit ip host 1.1.1.1 host 2.2.2.1

int vlan2

ip access-group to_host_b out

依然是out方向，其实很简单，大家只要将vlan的虚接口看作是硬接口就行了，不要想得太复杂。但是如果要放在vlan1的IN方向，ACL该怎么写呢？可以如下：

需求（由于是说明ACL放置接口的方向问题，所以需求简单一点）：

只允许Host_A访问Host_B，其他访问Host_B的拒绝。

所以在SW上面可以配置如下：

ip access-list extended to_host_b

permit ip host 1.1.1.1 host 2.2.2.1

deny ip any host 2.2.2.1

per ip any any

int e1

ip access-group to_host_b in

其实很简单，有一个规律可以增加些理解：

针对某个vlan接口应用acl的方向问题，大家可以看看acl的源和目标地址段。当源地址段为应用vlan接口的ip段时，就是用in方向；当目的地址段为应用vlan接口的ip段时，就是用out方向。反正有一点需要注意，应用在vlan的ACL为out方向时，其目的地址肯定是此vlan的ip网段内地址或者在acl中用any来匹配，但是用其他具体网段来匹配的话是匹配不上的；应用在vlan的ACL为in方向时，其源地址肯定是此vlan的ip网段内地址或者在acl中用any来匹配，但是用其他具体网段来匹配的话同样是匹配不上的。

大概一个月前我下线了我们网络中的一台CAT2960交换机，然后今天将其上线，结果发现snmp取值有问题。对照了一些其他同类型同服务功能的交换机，发现配置没有变化。一个月前还是可以的，这就奇怪了。

当时的配置如下：

ASW-B7-C2960#sh run | inc snmp

snmp-server group ipneter v3 noauth access 99
snmp-server community passwd RO 99
ASW-B7-C2960#

这些配置跟其他交换机的一样。

而后，查看了一下这个命令：

ASW-B7-C2960#sh snmp user 后没有任何输出结果。

通过snmpwalk的linux取值命令如下：

snmpwalk -v 3 -u haha -a MD5 -A wulitou -l authNoPriv a.b.c.d

通过查看同类型同服务功能交换机配置都没有看到haha这个user。

通过在交换机上面添加如下命令：

snmp-server user haha ipneter v3 auth md5 wulitou access 99

问题得到解决。

然后执行如下命令查看配置：

ASW-B7-C2960#sh run | inc snmp
snmp-server group ipneter v3 noauth access 99
snmp-server community passwd RO 99

依然没有看到命令snmp-server user haha ipneter v3 auth md5 wulitou access 99。看来这条命令是一个隐含命令了，通过show是查看不到的。不知道cisco为什么要这么做。

前几天，在公司的出口路由器上面实施了ACL控制，效果是达到了，但是查看了一下ACL的匹配数，发现好像不准确。大家做ACL有没有注意过匹配数，请看下面的ACL如下：

Extended IP access list ext_in_prted
    10 permit ospf any any (68585 matches)
  

20 permit icmp any any (139 matches)
    30 permit tcp any any established (6614 matches)
    40 permit udp any eq domain any
    50 permit tcp any 1.1.1.0 0.0.0.255 eq www (20 matches)
    60 deny tcp any 1.1.1.192 0.0.0.63 eq 443
    70 permit tcp any 1.1.1.0 0.0.0.255 eq 443 (26 matches)

根据本公司的实际流量情况可以很明显的看出第50条和第70条匹配数绝对不止这么一些。所以这几天很是研究ACL了一把。觉得一定要清楚cisco的ACL的处理机制原理才能弄明白。

今天又查看了一些文档，终于知道上面的ACL:ext_in_prted那些匹配数是设备软件处理的匹配数，硬件匹配数是用show ip access-lists命令显示不出来的。摘自原文如下：

When you enter the show ip access-list command, the match count displayed does not include
packets processed in hardware.

但是查看了好久，也没有找到在CISCO7609上面使用什么命令查看ACL的硬件匹配数。看来还有待进一步研究看看。

有任何不对或者有争议之处，还请牛人指正，不胜感激！！！

追加于2008-5-8：

今天阅读CAT6500 switch architecture文章时，发现了查看ACL硬件匹配数的命令：

show tcam int te7/1 acl in ip

但是发现两个问题：

1，不知道为什么在一台交换机上面竟然没有看到你个匹配数，而另一台交换机上面却有很多匹配数；

2，而且这条命令看出来的ACL与"show ip access-lists"看出来的ACL竟然有不同。

看来还有待进一步研究啦，不断学习中......

在一个由2台cisco7609的核心交换机和多台二层交换机组成的三角形网络中出现了流量异常转发问题，下面具体描述该问题。 
网络环境描述：
网络拓扑图如右，2台核心交换机上面配置了vlan198、vlan200以及vlan254，每个vlan的HSRP的active和STP的root都分别强制配置在一起。例如vlan198和vlan254的hsrp-active和stp-root在CSW-A上，而vlan200的hsrp-active和stp-root在CSW-B上。

问题描述：
172.17.200.30到172.17.254.30的数据包不知道为什么在ASW-2的上联端口能够抓到。查看了CSW上面的HSRP和STP以及ARP表和MAC地址表都没有问题，都显示不应该转发到ASW-2上面。如果说是ARP表和MAC地址表的aging-time不通，导致有可能当mac地址没有条目后广播产生流量，但是这样的话也不可能有这么大这么久的流量持续啊。

今天终于针对这个问题找到原因了，原来是由于v2和v5的hsrp-active不在一起导致的，也就是存在非对称路由。默认情况下，arp的存活时间为4小时，mac存活时间为5分钟。这就会造成当某服务器A的arp表没有超时，但是mac表超时后，交换机就会洪泛到A的数据流。需要注意的是数据流经过一跳时就会将数据包的mac地址段包括源和目的mac地址都需要重写。下面依据上面拓扑图来分析一下：

1），Ser1(1.1.2.30)往Ser2(1.1.5.30)发数据包，Ser1将数据包发往默认网关，也即CW-A的V2网关：

目的mac地址	源mac地址	源ip地址	目的ip地址
M_V2_GW	M_Ser1	1.1.2.30	1.1.5.30

2），CW-A接收到数据包进行解包过程，查找路由表（CEF），查找arp表，能找到1.1.5.30的arp表项，依据arp表进行mac地址的重写，然后查找1.1.5.30的mac表项，发现没有此表项即找不到从哪个端口发包（这里假设mac表已经老化），于是进行洪泛到所有v5的端口进行二层转发，数据包为：

目的mac地址	源mac地址	源ip地址	目的ip地址
M_Ser2	M_V2_GW	1.1.2.30	1.1.5.30

3），CW-B接收到洪泛包，解包后发现目的mac地址为M_Ser2（事实上CW-B永远从数据包的mac地址段看不到M_Ser1的mac地址，因为M_Ser1相关的数据包到了CW-A上面会进行mac地址的重写，将源mac改写成M_V2_GW。除非对Ser1进行arp请求，这是CW-B能从arp的数据报文中读取Ser1的mac地址，更新mac地址表），根据对应的端口直接转发数据包。

目的mac地址	源mac地址	源ip地址	目的ip地址
M_Ser2	M_V5_GW	1.1.2.30	1.1.5.30

4），Ser2接收到数据包进行回应，这里不敷衍了。

这里需要重点注意的是：
数据包到了相应的网关后，网关会根据arp表进行mac地址字段的rewrite。所以网关从mac字段是看不到非本网关网段内主机的mac地址的，只能从arp的影响报文的数据段内找到mac地址。然而arp表的老化时间默认为4小时，mac表的老化时间为5分钟，在不同vlan的hsrp-active布置在不同交换机的情况下，最长就有3小时55分钟相应的mac地址表为空，也就是说在这段时间内相关数据流就会洪泛。

解决方法：

1），将所有vlan的网关布置在同一台交换机上面，这样就没有了负载优势，所有vlan的数据流都由同一台设备进行处理；

2），将arp表和mac表的老化时间调至一致，或者mac地址大于arp老化时间。mac表不老化，从理论上来讲应该就只是占用了tcam条目，应该不会有其他问题，做的时候最好针对各个vlan同时进行arp和mac的clear；

3），静态绑定mac地址或者启用port-security mac sticky特性，甚至与disable-unicast特性结合一起使用，但是未知的意外现象不好估量；

4），服务器上配置脚本每隔4分钟ping一下网关。

在一个典型的冗余互备的交换网络内部，由于vlan的三层和二层关系，可能会导致数据流比较难以分析。我最近在考虑这个问题，想具体从数据包结构来分析一下交换机对数据流的处理过程。

网络环境描述（如图）：

1，两台CW上面都存在vlan2和vlan5；
2，两台CW之间通过Gi9/1的trunk端口跑HSRP协议，交换环路有STP阻隔；
3，vlan2的HSRP的active和STP的root强制在SW-A上；
4，vlan5的HSRP的active和STP的root强制在SW-B上；
5，1.1.2.30处于vlan2；
6，1.1.5.30处于vlan5。

依据1.1.2.30与1.1.5.30之间的数据交互来进行交换机处理机制分析：
1，服务器Ser1（1.1.2.30）发数据包给Ser2（1.1.5.30），此时数据包为：

2，CW-A接收到数据包，发现目标MAC为自己，于是一层层解包到IP层到目标IP为5.30，于是查找5.30的路由表（CEF表）发现5.30直连在vlan5，于是通过ARP表查找vlan5的网关MAC，然后查找MAC表得知vlan5的网关MAC是通过Gi9/1到CW-B。于是保持IP层数据不变，封装MAC层如下：

3，CW-B接收到数据包，类似于CW-A的处理过程，封装数据报如下：

4，Ser2接收到数据包后，一层层解包直到将数据传给相关的应用处理后，回应数据报如下：

5，CW-B接收到数据包后类似于上面的过程处理数据，这里就不敷衍了。

CAT6000家族中包含了CAT6000和CAT6500系列交换机。CAT6500系列能扩展支持到256Gbps背板和200million pps包处理能力。

Switching Fabric

65系列背板从Switch Bus发展到今天的CrossBar，已经完全解决了背板交换的瓶颈问题。CAT6000系列使用一条32Gbps的switch bus，而Cat6500系列则提供32Gbps Switch Bus和256Gbps的Switch Fabric Module（SFM）。SFM只能插在Slot5（主）和Slot6（备）用来提供高速率路径。需要注意的是CAT6000系列不支持SFM。

Switch Bus是一条总线，所以所有连接在此上面的线卡都能“听到”经过这条总线的数据包，然后根据R-Bus提供的信息来决定是否对这一数据包进行转发或者丢弃。

而SFM则是一个crossbar（交叉矩阵）结构，有多条的channal水平和垂直交错而成，每条channel提供8Gbps交换能力（supervisor720提供每channel 20Gpbs）。Crossbar交换网的扩展能力非常强，交换容量可以做的很大，基本不受硬件条件限制，目前单颗芯片交换容量在256G－700G之间，多颗芯片可以构建T级乃至几T容量的大型交换网络，足以满足当前和未来几年网络对交换容量的需求，并且随着硬件集成技术的进步，单颗Crossbar芯片支持的容量会更大。

CAT6500和SFM提供256Gbps交换能力和100million的包转发能力。720以下引擎每channel提供8Gbps带宽（即RX 8Gbps和TX 8Gbps）。Fabric-enabled模块连接CrossBar中一个channel，支持8Gbps带宽，同时也连接在32Gbps的switch bus上；Fabric-only模块连接CrossBar中2个channel，提供16Gbps带宽。连接线卡本地交换bus和SFM或main 32-Gbps switching bus的关键点叫做medusa，其实是一块ASIC芯片，用来处理双方的数据传输。如下图：

交叉矩阵交换，和它的名字一样，结构像是一个横竖交叉的矩阵，只不过横线（输入端）和竖线（输出端）并不直接相连，而是透过一个场效电晶体 （FET）将每一个横线与竖线连接。如此，只要控制场效电晶体的开关，便可以决定那个输入和那个输出（或那些输出）可以进行交换。矩阵交换的最大优点是允许多个相互不冲突的交换同时进行，并支持点对多点（Multicast）的交换。

Line card

由于有Switch Bus和CrossBar之分，所以配置的线卡也有Fabric-enabled和Non Fabric-enabled。Fabric-enabled说明此线卡能连接到SFM（Switch Fabric Module）上，提供CrossBar的高容量。下表列出了不同线卡与相应交换机的兼容：

Switch Bus Architecture

CAT6000系列交换机由32Gbps串联，所有连接在此Bus上面的端口都能接收到在此Bus上数据帧。Switch Bus包含D-bus（Data bus）、C-bus（Control bus）和R-bus（results bus）。D-bus负责端口之间的数据传输，带宽为32Gbps；C-bus负责端口ASIC和NMP（Network Management Processor）之间信息传递；R-bus负责将引擎上的逻辑信息（比如mac地址，acl匹配和CEF信息等）传递到交换机各个端口。

CrossBar Switching Fabric

CAT6500和SFM提供256Gbps交换能力和100million的包转发能力。720以下引擎每channel提供8Gbps带宽（即RX 8Gbps和TX 8Gbps）。Fabric-enabled模块连接CrossBar中一个channel，支持8Gbps带宽，同时也连接在32Gbps的switch bus上；Fabric-only模块连接CrossBar中2个channel，提供16Gbps带宽。连接线卡本地交换bus和SFM或main 32-Gbps switching bus的关键点叫做medusa，其实是一块ASIC芯片，用来处理双方的数据传输。

Switching Implemtation

Switching Implemtation只要控制平面和数据转发平面两个关键处理功能。控制平面主要维护路由、flow初始化和ACL等。MSFC就是一个控制平面卡，而线卡（包括DFC）主要负责数据转发功能。

Multilayer Switch Feature Card (MSFC)

MSFC是引擎上面的一块子卡，处理所有的控制平面功能，其维护一张路由表。在1代引擎，当数据流的第一个包没有匹配到硬件转发表时就发送给MSFC做路由匹配后转发出去，然后相关硬件会自动学习到此数据流的flow-entry。而2代引擎不直接做数据转发，而是根据路由表建立一张CEF表。CEF表包含详细路由表使用一种最长匹配的高优先级的规则匹配路由表。MSFC将CEF表上载到硬件并保持实时更新，所以所有的数据包都是有相应的硬件来转发而非MSFC。

Policy Feature Card (PFC)

PFC是引擎上面的第二块关键子卡，其集成了几块ASIC交换芯片能提供15million pps的包转发速率。

PFC是一个交换系统的心脏，其通过三个ASIC芯片实现了交换转发的三个重要功能。一是2层MAC转发，一是3层路由转发，另外一个是策略（包括ACL或者QoS）匹配。当实现转发后，系统使用一个flow-cache机制，可以实现数据流的快速硬件转发。Flow-cache可以包含源和目的IP地址，甚至源和目的四层端口等信息。

二代引擎做了一些改动，包含了CEF表，如下图：

注意以下不同之处：

Ø 2层引擎和ACL引擎综合到一起；

Ø 不再使用flow-cache用于数据交换，而用于数据流状态记录；

Ø MSFC将CEF表上载到L3引擎用于数据转发。

Distributed Forwarding Card (DFC)

DFC是显卡上面的一块子卡，用于将PFC上面的信息下载到本地并保持实时更新。有了这些信息，线卡就可以自己直接进行数据匹配转发，而不需要传递到PFC进行操作。如下图为DFC的架构图，类似于PFC架构。

Buffering and Congestion Management for the 10/100 and Gigabit Ethernet Line Cards

缓存和拥塞管理也是交换结构的一个重要因素，拥塞管理有ASIC芯片来实现。针对GE类型和10/100M类型端口，存在2种不同的ASIC。

GE端口涉及到Pinnacle ASIC，一个Pinnacle ASIC控制4个GE端口，并为每个端口维护一个512K的buffer。为了避免头端阻塞（head-of-line blocking）现象，512K buffer设计成TX:RX=7:1，即其中448KB用于TX，而只有64KB用于RX。如下图：

10/100M端口使用另外一种机制来管理拥塞。其使用Coil ASIC和Pinnacle ASIC一起来管理，每个Coil支持12个10/100端口，而每个Pinnacle支持4个Coil。每个端口提供128KB buffer，同样以7:1的比率分担TX和RX。图例如下：

ACS的安装这里不讲了，网上google一下就有很多。这里主要讲一下ACS的基本配置，以便于远程管理访问。

ACS正确安装后应该可以通过http://ip:2002/远程访问，当然要确保中间是否有防火墙等策略。然后就是通过正确的帐号和密码进行登录管理。下面是建立ACS管理帐户的图示。

a，本地登录ACS界面，点击左边的“Administration Control”按钮，进入下一个界面；

b，点击“Add Administrator”，进入配置界面；

c，根据提示填写，一般选择全部权限，方便管理，当然如果有特殊管理帐户，可以分给不同权限，比如说只能管理某些group等；

d，然后“Submit”，就可以通过这个账户进行远程管理了。

2, ACS访问原理

ACS主要是应用于运行Cisco IOS软件的思科网络设备，当然，ACS也全部或部分地适用于不运行Cisco IOS软件的各种其他思科网络设备。这其中包括：

· Cisco Catalyst交换机（运行Cisco Catalyst操作系统[CatOS]）

· Cisco PIX防火墙

· Cisco VPN 3000系列集中器

不运行Cisco IOS软件的思科设备（如运行CatOS的Cisco Catalyst交换机、运行Cisco PIX操作系统的Cisco PIX防火墙或Cisco VPN 3000集中器）可能也支持启用特权、TACACS＋（验证、授权和记帐[AAA]）命令授权或以上两者。随着对集中管理控制和审计的需求的增加，本文作者预计目前不支持TACACS＋命令授权的其他思科网络设备将得以改进，支持TACACS＋命令授权。为最快了解思科设备的支持水平，请查看有关设备的最新文档。

运行Cisco IOS软件的思科设备提供了两个网络设备管理解决方案：

· 启用权利(Enable priviledges)

· AAA命令授权

Cisco IOS软件有16个特权级别，即0到15（其他思科设备可能支持数目更少的特权级别；例如，Cisco VPN 3000集中器支持两个级别）。在缺省配置下，初次连接到设备命令行后，用户的特权级别就设置为1。为改变缺省特权级别，您必须运行启用命令，提供用户的启用口令和请求的新特权级别。如果口令正确，即可授予新特权级别。请注意可能会针对设备上每个权利级别而执行的命令被本地存储于那一设备配置中。表1为思科供货时Cisco IOS设备的缺省特权级别。这些等级缺省是有命令集的，比如说等级1只有一些基本的show命令等，而等级15是全部命令的集合。其他诸于2~14共13个等级的命令集是要用户自己在认证设备本地定义的。

表1 缺省级别

可修改这些级别并定义新级别，如图1所示。

图1 启用命令特权级别示例

每个设备上都有静态本地口令与特权级别相关联，这样有一个重要的内在缺陷：每个用户的启用口令必须在用户需访问的每个设备上进行配置。

为缓解这种情况提出的管理可扩展性问题，TACACS＋可从中央位置提供特权级别授权控制。TACACS＋服务器通常允许各用户有自己的启用口令并获得特定特权级别。这样即可从单一中央位置禁用用户或改变其特权级别，而不会影响其他管理员。

因为特权级别需在网络中每个设备上正确配置，以便管理员能在其管理的设备上有一致的体验，这就引发了另一个主要的问题。而不幸的是，使用TACACS＋实现的启用特权级别控制的集中化，并不能解决这一规模管理可扩展性问题。为解决此问题，可在TACACS＋服务器中定位命令授权。凭借此设置，设备上键入的任意命令都首先会针对当前特权级别进行检查，如果检查通过，它就会提交给TACACS＋服务器进一步检查。图2为此设备用来判断是否用户得到执行命令行授权的逻辑。注意图中的红框标注，标明先要经过本地的登记命令认证，然后再通过ACS的认证。下面授权部分还会具体讲到。

图2 设备逻辑，用户被TACACS＋验证；失败；用户登出；壳式授权…；用户输入Cisco IOS命令行；命令是否允许…；下一命令；授权命令行…；设备执行命令行。

作为通用T＋壳式服务授权（priv-lvl=）的一部分，TACACS＋能在用户登录设备时预定义用户获得的初始特权。这使管理员能在连接至设备时就能立即获得特权级别15。

3, 认证配置

3.1, 添加AAA客户端

a，点击左边“Network Configuration”，进入分组管理后，点击“Add Entry”，进入如下界面，按提示输入。这里要主要的是“key”，这个必须与客户端配置一致，才能进行通信。然后点击“Submit+Restart”即可。

b，客户端上面配置如下即可：

3.2, 添加用户组

ACS可以通过设置分组，来管理同一权限等级以及可管理设备等。其他配置可以都为缺省，但是TACACS+ Settings那一栏里面需要选中红框标注部分，等级可以按照自己定义。然后点击下面的“Submit+Restart”即可。可以看到图示中接下来有一个Shell Command Authorization Set，下面会具体讲到这一块功能。

3.3, 添加用户成员

a，点击“User Setup”，添加用户名，点击“Add/Edit”，进入下一个界面；

b，输入密码，选择正确的用户组，点击“Submit”即可。

3.4, 客户端配置

4, 授权配置

这里主要讲一下命令集设置。

a，点击左边“Shared Profile Components”，继续点击“Shell Command Authorization Sets”，进入下一个界面；

b，Add一个set后，出现如下界面：

注解如下：当选中“Deny”时表示不匹配框中命令的全部拒绝，后面勾选“Permit Unmatched Args”表示不匹配框中命令的全部允许。然后这个框中的命令格式为permit/deny ***。比如说要允许show run这个命令，须点选Deny，然后在框中add命令show，然后在右框中输入permit run或者勾选“Permit Unmatched Args”。需要注意的是左边框中的命令必须在AAA客户端本地有命令集，也就是应证了ACS的授权处理过程：先匹配本地命令集，再匹配ACS的命令集。

c，将这个命令集绑定到用户组或者用户，如下图，点击“Submit+Restart”即可。

d，客户端配置

对命令的注解：

l aaa authorization console这是个隐藏！！表示对从console口登陆的用户也用AAA服务器进行授权。如果不配置这条命令，无论你是否在line console 0 配置 authorization exec default或者 authorization command 15 default 等等，交换机都不会对console用户输入的任何命令发到AAA服务器进行授权的检查！也就是说，根本不能对console用户进行任何命令的限制，只要用户名和密码正确，在console口就可以作任何事。基本上在IOS 12.0(9)之前的版本里，没有这个命令。

l aaa authorization config-commands 这个命令表示对 (config)# 全局模式下输入的命令也进行授权检查。否则，只会对“>”用户模式和“#”特权模式下的命令进行授权的检查。如果是这样，只要你允许某个用户在特权模式下运行 “config t”，那么他就可以在全局模式下运行任何命令。显然，很多时候我们需要允许用户进入全局模式下进行配置，但是又只能允许他运行某些命令。这就必须要在交换机上配置这条命令。

l 配置中的“default”是关键字，默认系统的认证，授权，计费都是用“default”列表。当然你可以配置其他的名字，如aaa authorization exec TELNET group tacacs+ none…然后在你想要应用的端口应用他们：

line vty 0 15

login authentication TELNET

l Privilege命令是指在本地建立等级10的命令集，有了这些才可能在ACS上面做相应的配置。

5, 记账配置

记账配置比较简单，如下：

命令注解：

Exec表示执行config后的命令都记录；

Command 10的表示针对这个级别进行记录；

Network表示网络上面的协议进行记录；

System表示系统的记录。

在ACS上面的体现如下：点击左边的“Reports and Activity”，然后点击Reports里面的选项会看到如下的记录等。

That’s all,thanks.

当然这只是一个简单文档，详细配置还需要进一步研究测试，但是弄好了上面的配置就很能满足分权限集中管理的需求了。

6, 权限等级应用实例

网络管理员角色需求：

Ø 定义一个只读权限帐号，等级为level5；

Ø 定义一个能修改interface的权限帐号，等级为level10.

根据上面阐述，权限等级2~14等级必须在IOS上面配置必要的命令集配置，所以在交换机配置命令集如下：

//AAA配置

//权限等级命令集配置

ACS上面进行如下配置：

上面这个图表示这个权限的用户不能执行int g0/1和int g0/2的命令，但可以执行int g0/3等。

其他配置请参考上面阐述。

1，测试拓扑图：

测试网络拓扑原始状态：
图中所有Cisco交换机原始都是用RSTP模式；
STP：vlan10和vlan20的root都在3750g-A5，vlan99的root在3750g-A6，图中红线为forwarding链路，黑虚线为blocking链路；
HSRP：vlan10和vlan20的active在3750g-A5，vlan99的root在3750g-A6。

2，测试方式：
A：从ServerA ping ServerB，看丢包个数；
B：从ServerA ping ServerC，看丢包个数；

3，测试过程：

4，总结
从上面测试结果可以看出以下几点：
Ø 从RSTP迁移到PVST，丢包不超过30个；
Ø 从PVST迁移到RSTP，丢包非常小。涉及到vlan的root切换时候丢包30个；
Ø 在某一个二层交换机做迁移时，不会影响到其他二层交换机；
Ø 在某一核心交换机上做迁移时，可能会影响面比较大；
Ø 二层交换机PVST到RSTP收敛时影响到通过本交换机的数据流丢包2个，不会影响到其他交换机；
Ø 其他经验性总结，请看上面报告。

对线上交换机进行配置修改,出现交换机暂时断网.原有情况:
  2台交换机通过2对光纤连接,分别作上port-channel,并将交换机的相应端口绑定在po上,启用trunk模式.交换机上原有几个vlan,但是在这个Po上只允许vlan21通过.如:
  上联交换机A部分配置:
  interface Port-channel1
   switchport trunk encapsulation dot1q
   switchport trunk allowed vlan 21
   switchport mode trunk
   !
  interface GigabitEthernet1/0/3
   description to-YH06050001_g1/0/25
   switchport trunk encapsulation dot1q
   switchport trunk allowed vlan 21
   switchport mode trunk
   channel-group 1 mode on
  !
  interface GigabitEthernet1/0/4
   description to-YH06050001_g1/0/26
   switchport trunk encapsulation dot1q
   switchport trunk allowed vlan 21
   switchport mode trunk
   channel-group 1 mode on
  !
  下联交换机B部分配置:
  interface Port-channel1
   switchport trunk encapsulation dot1q
   switchport trunk allowed vlan 21
   switchport mode trunk
  !
  interface GigabitEthernet1/0/25
   description to-CN_3523_g1/0/3
   switchport trunk encapsulation dot1q
   switchport trunk allowed vlan 21
   switchport mode trunk
   udld port
   channel-group 1 mode on
  !
  interface GigabitEthernet1/0/26
   description to-CN_3523_g1/0/4
   switchport trunk encapsulation dot1q
   switchport trunk allowed vlan 21
   switchport mode trunk
   channel-group 1 mode on
  !
  现在在这2个交换机上分别新建一个vlan254,并且需要在它们之间互通vlan254.于是在分别建立vlan254后,在A上作如下配置:
  int port-channel 1
   switchport trunk allow vlan add 254
  int range g1/0/3 -4
   switchport trunk allow vlan add 254
  然后在交换机B上作如下配置:
  int range g1/0/25 -26
   switchport trunk allow vlan add 254
  此时出现交换机B立即断网,于是马上进机房察看交换机这2个端口的状态灯发现显示沉黄色.console登陆,删除这一配置,端口才up.查看log发现:vlan mask is not matching.因为po上还没有进行配置.然后进行如下配置:
  int port-channel 1
   switchport trunk allow vlan add 254
  此时sh run,发现
  int range g1/0/25 -26
   switchport trunk allow vlan add 254
  这2个端口竟然自动配置上了vlan254.
  于是另外再做实验,对于没有做po的端口,可以直接加类似 switchport trunk allow vlan add 254 这样的配置.

经验总结:
  对trunk链路进行添加vlan配置时:
  1,对于物理trunk端口绑定在逻辑端口port-channel的情况,需要先对逻辑端口进行配置,这样的配置可以自动配置到物理链路上.(扩充:是否所有对于物理链路的配置都可以先在逻辑链路上配置,且自动配置在相应的物理链路上呢?)
  2,对于直接物理链路(没有绑定在逻辑链路上)的情况,可以直接对物理链路进行 switchport trunk allow vlan add 254 类似配置.

测试环境：
1，使用笔记本配置临时ip并插在ASW-A3-C2960的Gi0/3口，然后连续ping www.163.com ；
2，端口现有配置：
interface GigabitEthernet0/3
      switchport access vlan 200
      switchport mode access
end

测试步骤：
1，   在连续ping www.163.com 没有问题后一段时间，许仙拔掉笔记本的网口，此时ping timeout；
2，   插上笔记本网口，并计时。结果从插上网口那一刻到ping包正常一共30s；
3，   连续ping一分钟后，配置Gi0/3 如下：
    interface GigabitEthernet0/3
      switchport access vlan 200
      switchport mode access
      spanning-tree portfast
      spanning-tree bpduguard enable
end
检查结果：ping包正常，没有丢包；
4，   连续ping一分钟后，全局配置：errdisable recovery cause all；检查结果：有一个ping包timeout；
5，   连续ping一分钟后，全局配置：udld enable；检查结果：ping包正常，没有丢包；
6，   连续ping两分钟，ping包正常，没有丢包；

注释：
errdisable recovery cause all 这条命令是启用交换机的自动恢复功能。有时交换机在检测到一些错误信息后，导致端口errdisable（相当于down状态），这个时候需要人为地去up（no shutdown）这个端口，或者等err信息超时。配置了这条命令，交换机就会在错误信息消失后的第一时间自动启动这个端口。
udld enable 这条命令是启用交换机每个端口链路的上行和下行的检测机制，但是必须在互联的交换机上面一起配置。

总结：
在生产网络中配置portfast、bpduguard、errdisable recovery cause all以及udld enable，不会对网络造成影响。

1，试验拓扑：
两台7609做核心交换，配置上N个vlan，其中vlan199的HSRP active在7609-A上，vlan208的HSRP active在7609-B上。
访问控制的需求：
1..其他网段可以访问vlan208的任何端口
2..vlan208不能访问 250 254等管理网段的任何端口
3..vlan208可以访问其他服务网段的服务端口 如80 8080 443 7001 5200 1521
4..vlan208 可以访问vlan201 的 TCP/UDP 32768--65535 udp/tcp 111 udp/tcp 2049 这些端口组成了nfs的服务

2，配置如下：
ip access-list extended tov208
permit tcp any 192.168.208.0 0.0.0.255 reflect remain timeout 120
permit udp any 192.168.208.0 0.0.0.255 reflect remain
permit ip any any
ip access-list extended fromv208
permit icmp any any
evaluate remain   
deny tcp any 192.168.250.0 0.0.0.255
deny udp any 192.168.250.0 0.0.0.255
deny tcp any 192.168.254.0 0.0.0.255
deny udp any 192.168.254.0 0.0.0.255
permit tcp any any eq www
permit tcp any any eq 8080
permit tcp any any eq 443
permit tcp any any eq 7001
permit tcp any any eq 5200
permit tcp any any eq 1521
permit tcp any 192.168.201.0 0.0.0.255 eq 111
permit udp any 192.168.201.0 0.0.0.255 eq 111
permit tcp any 192.168.201.0 0.0.0.255 eq 2049
permit udp any 192.168.201.0 0.0.0.255 eq 2049
permit tcp any 192.168.201.0 0.0.0.255 gt 32767
permit udp any 192.168.201.0 0.0.0.255 gt 32767
permit ip any host 224.0.0.2
int vlan 208
ip access-group fromv208 in
ip access-group tov208 out
no ip unreachables
3，结果分析
测试成功。但是同时出现了新问题：
vlan199访问不了vlan208(在vlan199端设备上telnet 192.168.208.4 8080)
分析原因：
在7609-A上vlan199为active，vlan208为standby，所以在7609-A上，数据从vlan199到vlan208的数据匹配tov208后产生一条自反acl。但是这条acl不会同步到7609-B上去，所以回来的数据流到达vlan208后匹配不到acl，所以也就丢弃了。请注意路由器严格按照路由表来执行路由查找工作。

其实，像这样的需求可以直接用扩展ACL的established特性来解决。
ip access-list extended fromv208
permit icmp any any
permit ip any host 224.0.0.2
permit tcp any any eq 80 8080 443 7001 5200 1521
permit tcp any 192.168.201.0 0.0.0.255 eq 111 2049
permit udp any 192.168.201.0 0.0.0.255 eq 111 2049
permit tcp any 192.168.201.0 0.0.0.255 gt 32767
permit udp any 192.168.201.0 0.0.0.255 gt 32767
permit tcp any any established
deny ip any 192.168.250.0 0.0.0.255
deny ip any 192.168.254.0 0.0.0.255
!
interface Vlan208
ip access-group fromv208 in
end

注释：establishted特性通过检查TCP段头内的ACK和RST标记，如果这两个标记都没有被设置，表明源点正在向目标建立TCP连接，那么匹配不会发生。

有一次在6509-A上show ip arp summary 发现有10000多个10.0.0.0/8的条目，都是通过办公网络的6509-B对接的G1/7口学到，而且6509-A的CPU达到了30%，当时判断是有人在扫描公司的10网段，导致BR-3通过6509-B的G3/9的arp代理学到了这么多的ARP。随后把G3/9的arp代理关闭后，竟然导致公司访问机房的服务器网段session中断。这种情况在一个全三层网络环境下是非常奇怪的。

最后找到了原因：
在6509-A上配置到office的路由是这样的：
ip route 10.0.0.0 255.248.0.0 GigabitEthernet1/7     
而不是通过指下一跳的IP，而是只指了接口，这样就会导致数据包到达G1/7口的时候，通过发ARP广播的方式查找10段的IP，而不是正常情况下把数据包转发给办公网络的6509-B进行处理，这种情况在办公网络的交换机的G3/9的ARP代理没有关闭的情况下，是可以通信的，一旦把G3/9的arp代理关闭，6509-A的G1/7无法通过ARP学到10段的mac，就会导致中断。

经验总结：
任何时候在做静态路由的时候，不要光指接口，还要跟上下一跳的IP地址。