盼盼

如今内部人员给公司的安全造成的威胁非同小可。近来的一些报告指出，内部人员对公司的损害在所有的危害事件中已从80%上升为86%,而且超过半数发生在雇员的终端。

如何采取行之有效的措施防范ARP病毒，已成为近期网络安全工作的重中之重。本文介绍如何采用VLAN技术对局域网进行优化改造，从而有效防范ARP病毒的攻击。

路由配置不合理




 

问题描述：简化的网络拓扑如上图所示,在用户上网的高峰期，在出口链路上出现大量的丢包，而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的对应关系存在另外一张表中。






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三元组关联。

设备端口不匹配




 

问题描述：在用户的上网高峰期，出现速度慢、严重丢包等现象。

问题解释：经过查看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，问题得到彻底解决。

备注：当然，其他厂家设备的软件升级我方最好不做，以免承担过多的责任，建议客户自己升级。不过，在有充分把握的情况下，客户自己升级有困难（得不到最新的软件、不会升级），我方也可以替客户排忧解难――包办，有利于工程的顺利进展 [/img]..

问题描述：Flex16i与u1光口互连，u1下连用户出现严重丢包。由于现场没有光功率计，未能直接测试光纤的传输质量。于是更换Flex16i、u1来定位故障点，更换设备后问题依旧。最终将焦点集中在传输链路上。

 

问题解释：从Flex16i到下连的u1，中间经过Flex16i －光纤跳线－传输光纤链路－光纤跳线－u1，由于缺少光纤线路测试仪器而未能确认传输链路是否有问题，因此通过更换设备来协助判断是有效的方法。既然Flex16i、u1的设备更换后问题仍然存在（更换设备前，最好先确认新替换的设备不存在问题），那么传输链路就是最大的嫌..

“网络丢包现象是常见的网络故障，但引起丢包的原因却多种多样、千奇百怪。因此对于此类故障的解决，要求处理人员洞悉网络基础理论、了解不同厂家产品特性，有耐心、深入地进行分析定位。”－－－《网络丢包现象分析处理指导书》摘录

 

从今天开始，本人(ipdata)将陆续发布系列网络丢包问题分析处理的技术文章。该系列文章来源于《网络丢包现象分析处理指导书》，主要分成三大部分：

第一部分：讲解从产生网络丢包问题的原因来看，网络丢包问题大致可以分为六大类因素，1、网络设备软、硬件问题；2、线路传输质量差引..

sniffer简明教程

sniffer是由NAI公司提供的强大的协议分析仪，完整的sniffer系统，除了我们经常使用的以太网模块外，还具有广域网模块，广域网模块需要专用的硬件支持。比如E1/FR/POS/ATM等，均需要硬件模块配合。这里再强调一点，以太网模块的sniffer，NAI也提供了专用的网卡，专用网卡是针对sniffer软件做了优化，在捕获报文的性能上要强于普通网卡。我们通过sniffer捕获报文做故障分析时，千万要记住，大流量的链路假如用普通网卡捕获报文可能出现部分报文漏捕获情况，这对分析丢包问题是极为不利的，所以往往我们多捕获几份报..