网络丢包现象分析处理指导书四
路由配置不合理
问题描述：简化的网络拓扑如上图所示,在用户上网的高峰期，在出口链路上出现大量的丢包，而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条目。
注意：由于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的对应关系存在另外一张表中。
|
Mac
|
Port
|
|
Mac_1
|
1
|
|
Mac_2
|
2
|
首先假设vlan1的用户pc1与catalyst4003建立通信，则u24的fdb结构如下：
|
Mac
|
Port
|
|
Mac_1（pc1）
|
1
|
|
Mac_c(catalyst4003)
|
23
|
此时，vlan2有一个用户pc3开始与catalyst4003进行通信，pc3首先向网关发arp request(广播报文)，catalyst4003向pc3回arp reply报文，则u24的fdb此时的状态如下：
|
Mac
|
Port
|
|
Mac_1（pc1）
|
1
|
|
Mac_c(catalyst4003)
|
24
|
|
Mac_3 (pc3)
|
3
|
若此时，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表又发生如下变化：
|
Mac
|
Port
|
|
Mac_1（pc1）
|
1
|
|
Mac_c(catalyst4003)
|
23
|
|
Mac_3(pc3)
|
3
|
|
Mac_2(pc2)
|
2
|
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倍的处理能力。
备注：NetHammer系列路由器的NAT处理能力
|
项目
|
NetHammer1760
|
NetHammer2651
|
NetHammer3680
|
|
启用NAT的转发速率
|
8KPPS
|
28KPPS
|
40KPPS
|
|
NAT会话能力（最大连接个数）
|
1k
|
2k
|
4k
|
| 欢迎访问最专业的网吧论坛,无盘论坛,网吧经营,网咖管理,网吧专业论坛
https://bbs.txwb.com
关注天下网吧微信/下载天下网吧APP/天下网吧小程序，一起来超精彩
|
本文来源：广东网吧联盟 作者：佚名
天下网吧·网吧天下
闽公网安备35010202000238号