设备端口不匹配
 
问题描述：在用户的上网高峰期，出现速度慢、严重丢包等现象。
问题解释：经过查看cisco2621的上行端口（与光电收发器连接的端口），发现输入报文出现大量的CRC校验错，由此可以确定为路由器的物理端口或上行链路问题。进一步查看上联交换机catalyst，发现其下连端口工作于自协商状态，而协商结果为100M半双工。光电收发器一般不具有自协商功能，工作于100M全双工状态。由于上连设备端口状态不一致，因此整条链路出现大量报文出错。
问题解决：保证互连设备的端口的工作方式一致，问题解决。
备注：
1、两网络设备之间互连，要确认两端端口的工作状态一致；如果设备之间通过光电收发器做转接，需要确认如图三所以的四个端口的状态一致，只要其中一个端口状态跟其他端口不一样，则整条链路均受影响。另外，要求理解端口自协商的工作机制。
2、100BSAE-TX/10BASE-T端口的协商机制：目前，多数网络设备的以太网口都支持自协商。支持自协商的以太网口对接，可以采用一种标准的物理层信号FLP（对于FAST ETHERNET）或NLP（对于ETHERNET），通过一种协商机制，将双方的工作模式设置为双方都能支持的最高速率。例如，双方都支持自协商，并且两端的最高速率都是100M全双工，协商结果应是100M全双工；如果双方都支持自协商，一端的最高速率是100M全双工，另一端是100M半双工，协商结果应是100M半双工；10M全/半双工的情况可依此类推。通过自协商机制可以保证双方的速率和双工模式一致并且达到双方都支持的最高速率，从而保证传输的效率。但是如果一个支持自协商的网口与一个不支持自协商的网口对接，则可能出现问题。支持自协商的网口通过接收的信号可以判断出对方的速率是100M还是10M，但因为没有携带足够信息的FLP或NLP，无法判断出对方的全/半双工模式，所以通常只能根据对端的速率将自己设为100M半双工或10M半双工。例如：一个支持自协商的网口与一个固定100M半双工网口对接，自协商网口通常会将自己的模式设为100M半双工，两端模式一致，可正常通讯；但是如果一个支持自协商的网口与1个固定100M全双工网口对接，自协商网口通常会将自己的模式设为100M半双工，这样一端半双工一端全双工，通讯时链路上会出现碰撞，导致丢包错包。所以我们设置网口模式的一个基本原则是：互连的2个设备的对应网口工作模式设置一致。必须杜绝将一端设置为自协商，一端设置为全双工的方式；如果一端网络设备不支持自协商，应该也禁止对端的自协商功能，强制将两端的速率和全/半双工模式设成一致。
 
问题描述：网络拓扑见下图，在用户上网高峰期，在big400上ping外网出现严重丢包，内网通信正常。
问题解释：设备之间一边工作自协商，一边工作100M全双工，当自协商的一边没有收到对端完整的端口协商信号时(FLP)时，将自己设为100M，半双工，造成两边端口状态不一致，报文在链路中产生冲突、错误。
问题解决：将互连设备两边端口设为一致，则问题解决。
备注：做工程时，要求检查与我司设备互连的设备的端口的工作状态，并要求配置一致。牵涉到其他厂家设备时，客户有时不大愿意让你去操作其设备或者自认为配置没问题而不需要查看其他厂家设备，这时需要我们灵活处理，其实很多时候只要你把排障意图跟客户讲清楚，客户觉得你有道理，还是能到达你希望的目的的。比如，濮阳油田的这次故障，客户很肯定的说其NetScreen的trust端口的双工方式是固定全双工的，不需要确认。但是，通过跟他们分析端口之间的协商原理后，客户意识到设备之间端口的工作状态一致的重要性，同意检查NetScreen的情况，甚至到后来让我们自己操作，帮助他们查看NetScreen的配置是否合理。
 
问题描述：cisco3640与Big800互连，cisco3640作为出口路由器，在上网高峰期，Big800下连用户出现上网速度慢，ping外网大量丢包。Cisco3640一侧采用10M端口，Big800一侧采用100/10M端口，出现故障时看到cisco3640的端口有大量CRC错误。
问题解释：cisco3640的早期IOS v12.0版本对10M端口的双工方式不提供配置命令，默认工作状态就是10M half；Big800一侧端口工作于10M full，两边不匹配导致丢包。
问题解决：将Big800的端口配置成10M half可以解决问题，但是我们知道cisco3640与Big800在物理上是点到点的连接，建议最好让双方都工作在Full状态。通过升级cisco3640新的IOS，问题得到彻底解决。
备注：当然，其他厂家设备的软件升级我方最好不做，以免承担过多的责任，建议客户自己升级。不过，在有充分把握的情况下，客户自己升级有困难（得不到最新的软件、不会升级），我方也可以替客户排忧解难――包办，有利于工程的顺利进展
路由配置不合理
 
问题描述：简化的网络拓扑如上图所示,在用户上网的高峰期，在出口链路上出现大量的丢包，而Big400内部用户的通信却正常。
问题解释：
Big400作为全网的核心交换，上面存在全网路由信息，包含：
172.16.0.0/24——172.16.31.0/24直连路由，默认缺省路由，下一跳指向NS100。
NS100作为出口设备，包含路由信息：
172.16.0.0/16(汇聚路由)，下一跳指向big400，默认缺省路由，下一跳指向internet。
从上面两设备的路由配置，可以发现，当big400下连用户发wins报文（目的IP为172.16.255.255）或进行主机扫描（目的IP为172.16.32.0－－－172.16.255.255 ）时，Big400根据路由表(ip route 0.0.0.0/0 172.16.1.1)将报文转发给NS100,而NS100又根据路由表（ip route 172.16.0.0/16 172.16.1.2）将报文转发给Big400，这样造成报文在big400和NS100之间循环转发，直到TTL为0才将报文丢弃！因此，大量的垃圾报文拥塞big400与Netscreen之间的链路，而且NetScreen需要为这些报文做会话连接，加重了NetScreen的负载。
问题解决：以上Big400和NS100路由存在的问题，可以在Big400上添加一条汇聚路由172.16.0.0/16指向一个空接口来解决。因为，根据路由最长匹配原则，172.16.0.0/16网段中包含的具体路由如果在Big400上不存在，则会匹配到该汇聚路由，从而将相应报文丢弃，不再往NS100转发。消除了非法报文循环转发的隐患。
注意：由于Big/Flex目前不存在黑洞路由功能，因此，建议用如下方式替代，在Big/Flex上创建一个汇聚路由，下一跳指向一个不存在的IP（直连网段的ip），为了避免交换机对不存在IP进行ARP解析，在交换机上针对该IP创建永久的arp条目和FDB条目。
如本例例可以配置如下，
Ip route 172.16.0.0/16 172.16.1.100
create fdbentry 00053b999999   vlan v1 0:1
config arp 172.16.1.100  00053b999999
备注：该故障具有典型的意义，像大部分的企业网、驻地网都采用类似的网络结构，在路由规划时要特别小心，除了考虑正常报文的路由外，还要防止异常报文不正常的路由。
 
网络设计不合理：存在环路
问题描述：校方要求H3100的端口之间实现二层隔离。故障现象当有多个学生上网时出现速度慢，有严重丢包现象。
问题解释：由于校方对用户进行端口隔离，学生宿舍之间无法互相通信，于是学生自己将宿舍之间的hub互连起来。在网络的末端形成了环路，幸好H3100实现端口隔离避免了广播风暴的形成，但是将产生如下影响：
1、多个学生宿舍的数据流可能压到某个H3100端口上，造成某个端口负载过重，而且具有随机性，从H3100的一个端口上可能发现有几十个MAC地址；
2、router往下发出的arp广播报文会在H3100的接入端的环路走一遍，因此H3100的FDB表的用户端口会出现router 的MAC条目，造成用户报文的转发异常，即丢包 。
问题解决：问题的解决需要防止环路的产生：1、拆除学生宿舍之间的连线，H3100不启用端口隔离。该方案校方未同意，而且学生宿舍之间的网络互连不好管理。2、在H3100上启用stp，虽然stp能够防止环路的产生，但是必将阻塞多个产生环路的H3100端口，只留一个转发端口，所以该方案也不能解决单端口承受大流量的压力。3、H3100上关闭各个端口的学习功能，实现MAC和port的静态绑定，将router、学生pc的MAC绑定在各自的端口上。该方案实现起来比较麻烦，但是对该网络来说是最有效的。
 
FDB表结构问题
 
 
问题描述：Catalyst4003和u24上分别存在两个vlan（vlan 1、vlan2），两台设备的每个vlan各有一物理连线。Pc1、pc2 ping网关出现间断性丢包，pc3同样出现严重丢包，当拆除两根物理连线中的一根时，则存在连接的vlan用户上网正常。
问题解释：我们知道Catalyst4003是L3交换机，不同的路由接口采用同一个MAC地址（这一点不同router，router的一个以太网口占用一个MAC地址），而u24的FDB表结构是mac－port关联二元组，不与vid关联，vid与port的对应关系存在另外一张表中。
首先假设vlan1的用户pc1与catalyst4003建立通信，则u24的fdb结构如下：
此时，vlan2有一个用户pc3开始与catalyst4003进行通信，pc3首先向网关发arp request(广播报文)，catalyst4003向pc3回arp reply报文，则u24的fdb此时的状态如下：
若此时，pc1需要与catalyst4003通信，由于pc1已建立起catalyst4003的arp表项，因此，向catalyst4003发单播报文，该单播报文到达u24后，u24查找fdb表，则会将报文往port 24转发，Catalyst4003在vlan2接收到该报文即刻丢弃。在Pc1体现为丢包。只有当vlan1的新用户（未得到catalyst4003的Mac地址的pc）发起与catalyst4003的通信时，pc1的通信才恢复正常。 比如，vlan1的pc2发arp request(广播)解析catalyst4003的MAC地址，catalyst4003回应arp reply,u24的fdb表又发生如下变化：
 
Pc1发给catalyst4003的单播报文u24能够正确地往port23转发。
问题解决：该故障跟L2交换机的FDB结构相关，要解决此问题，可以采用Flex24、u3550替代u24。因为Flex24、u3550的FDB表的结构是mac－port－vid三元组关联。
 
问题描述：该网络出口路由器cisco7204下连端口采用Trunk封装承载多个vlan信息，HW2403的端口分为两个vlan，分别接到H3100上。网络出现的故障与上例类似，vlan v1或v2的用户上网出现间断性的丢包，只要将一个vlan的用户暂停上网，另外一个vlan的用户上网则正常。
问题解释：H3100采用U24的交换芯片，所以其fdb结构及算法跟u24相同。H3100的两个上行端口连接到cisco7204（用户网关）的同一个物理接口上，因此cisco7204的MAC地址会在H3100的两个上连端口摆动，导致下连用户出现丢包现象。
问题解决：可以考虑HW2403采用两条物理链路连接到cisco7204的两个物理端口上，router的一个端口采用一个独立的MAC地址。因此不会出现用户网关的MAC地址在H3100的多个端口上摆动。
备注：Hammer系列交换机中，H3100、u24、u2的FDB表结构是一样的，u1024、u1016、u1008也有类似的硬件FDB表结构。在实际的应用中，我们要根据产品特点合理地设计网络。
 
 
问题描述：该网络通过一台u24将Firewall地DMZ与untrust区域分隔开，之所以不让untrust端口直接与router互连是因为untrust区域还需要接入其他的设备，只能借助u24的多个端口来连接。
网络故障与上面两例类似。内网用户和Server Cluster上网出现丢包、甚至上不了网。
问题解释：事实上，有些厂家的Firewall的untrust、trust、DMZ接口共享一个MAC地址，此时我们不妨把Firewall当成一台L3交换机，u24的两条链路接入到同一个设备的两个物理端口，但是，两个物理端口的采用同一个MAC地址，因此，该MAC地址会在u24的FDB的两个端口摆动。造成用户上网出现间歇性中断。
问题解决：将u24替换成u3550或者改变网络结构，增加一台交换机来作为Untrust区域的接入。
备注：遇到类似的网络拓扑时，请查看Firewall的物理接口是否共享一个MAC地址，如果采用同一个MAC地址，网络设计时要注意交换机的选型。
 
出口设备负载过大
问题描述：小区用户采用私网地址，出口路由器cisco2621提供NAT转换服务，出口100M带宽，一开始未对用户带宽做任何限制，。在上网高峰期该小区在线用户达到200多个，而且部分用户在上面长期下载软件。网络出口出现丢包、速度慢等现象。
问题解释：
通过检查cisco2621的cpu使用情况，有时达到80％的利用率，出口链路的利用率也较高。
由于cisco的路由器NAT转换均由cpu处理，所以大流量、较多的会话连接对cpu的压力很大。
该故障就是cisco2621的处理能力有限导致用户报文被丢弃的。
 
问题解决：
1、首先在Flex24上对用户做带宽控制，避免个别用户大量占用带宽。但是，网络的故障未能消除。
2、采用NetHammer2651替代cisco2621，丢包现象消失。NetHammer2621的NAT功能采用缓存机制，大大减少cpu资源的消耗，比cisco同一档次的路由器高出2－3倍的处理能力。