接入层交换机（精选3篇）
接入层交换机 篇1
随着医院信息化的发展,医院的基础网络架构变得越来越复杂,新网老网并存,内外外网并存,医院网络带宽需求也越来越大,网络故障的频率越来越高,而且,一些少见的比较隐性的、怪异的故障,解决起来费时费力,接入层交换机,作为网络中的重要一环,一般情况下,只要是主流的品牌交换,性能还是比较稳定的,不过,这并不意味着交换机设备不会发生故障,随着工作时间的推移,工作使用环境的变化,交换机内部的元器件也会发生老化现象,由于出厂时间较早,交换机本身的操作系统不够成熟,当某个网络事件发生时,容易触发交换机工作性能下降,此时交换机发生故障的机率就比较高了。该文下面的一则网络故障,就是由于交换机操作系统版本较低,使得在某一网络环境下性能急剧下降,导致部分局域网出现无法上网的故障!由于该故障少有发生,解决起来比较棘手,为此笔者就将该故障的详细排查经过还原出来,与各位朋友共同交流![1]
1 故障现象
1.1 网络环境
发生故障的区域是我院的体检中心,其网络环境见原拓扑图,体检中心共有26个终端工作站,用两台24口的华三S3100百兆交换机,通过又胶线级联后再用多模光纤上联至华三S7506E核心交换机,二层纯内网架构,两台级联的交换机单独划分在一个VLANVLAN里,使用时间也就两年多。
1.2故障表现
某天下午突然接到体检中心电话说收费电脑的网不通了,工作站进不了,当信息科工作人打开威盾内网安全管理软件查看时,发现该科室有多处工作站不通,随到现场排查,发现Ping主服务器不通,但约二三分钟后又都自动通了,通了后全天都正常,接下来的几天,都是早上七点四十到八点刚上班那段时间,也总是出现类似故障,偶尔下午也会发生一两次,开始时,一周只有一两天发生,后来几呼天天早上都会发生,早上体检人多时,严重影响正常医疗工作。故障模拟如下:
部分PC(PC-1,PC-4) PING HIS服务器通畅,PC-2、PC-3 Ping主服务器不通畅;此时,交换机V30,V36的CPU使用率瞬时达到65%以上后立即又恢复正常;PC-1 ping PC-2通畅,PC-1 ping PC-3不通畅,ping HIS服务器不通畅。
2 分析与检修
出现断网后:1) 通过TELNET能够远程登录到两台交换机,说明从核心到该接入层交换机是通的,查看了交换机的CPU使用率、日志及STP状态,除了个别端口反复UP或DOWN外,均未发现异常,怀疑是个别电脑跳线接触不良引起的,于是,更换了端口反复UP或DOWN的那两台工作站电脑跳线、网卡及墙上的超五类模块,交换机出错日志如下:
%Aug 13 07:21:57:763 2014 TJcenter_Vlan IFNET/3/LINK_UPDOWN: Ethernet1/0/10 link status is UP.
%Aug 13 07:21:55:860 2014 TJcenter_Vlan IFNET/3/LINK_UPDOWN: Ethernet1/0/10 link status is DOWN.
%Aug 13 07:21:37:657 2014 TJcenter_Vlan IFNET/3/LINK_UPDOWN: Ethernet1/0/24 link status is UP.
%Aug 13 07:21:37:655 2014 TJcenter_Vlan IFNET/3/LINK_UPDOWN: Ethernet1/0/11 link status is UP.
%Aug 13 07:21:37:654 2014 TJcenter_Vlan IFNET/3/LINK_UPDOWN: Ethernet1/0/10 link status is UP.
%Aug 13 07:21:35:317 2014 TJcenter_Vlan IFNET/3/LINK_UPDOWN: Ethernet1/0/24 link status is DOWN.
%Aug 13 07:21:35:315 2014 TJcenter_Vlan IFNET/3/LINK_UPDOWN: Ethernet1/0/11 link status is DOWN.
%Aug 13 07:21:35:314 2014 TJcenter_Vlan IFNET/3/LINK_UPDOWN: Ethernet1/0/10 link status is DOWN.
%Aug 13 07:21:33:238 2014 TJcenter_Vlan IFNET/3/LINK_UPDOWN: Ethernet1/0/21 link status is UP.
2) 通过上面的排查处理后,故障还是存在,重启交换机能好一会儿,但第二天还是有类似故障发生,只是交换的端口没有上面的出错日志了,日志发给交换机厂商分析说机器没有问题,于是再自行排查,将原先两台做级联的交换机,增加了一条链路,两交换机都用光纤连到核心交换机上,如上图中的现拓扑。
3) 采用不同链路以后,故障还是存在,于是又做了如下排查:
将一台同型号的备用新24口交换机更换了其中一台;怀疑电压不稳,又给两台交换机配上了UPS后备电源;咨询了几家网络公司,为防止STP波动,启用了交换机的边缘端口,甚至将STP协议滤过掉,故障还是会发生;怀疑是体检中心某台设备引起的,信息科人员早上去蹲点,一台一台帮他们开机,还是没发现问题所在。
4) 怀疑有病毒或网络风暴,请网络公司过来测试流量也没发现问题,考虑到总是在早上发生,当所有PC同时启动时,交换机CPU使用率有个一过性的急速上升,数据处理能力下降,导致部分数据不能从交换机(V30)传输出去,由此怀疑交换机处理能力不足导致,于是,使用高性能24口千兆交换机H3C S5120 SI替换V30(h3c s3100)百兆交换机,进行测试,结果,接在千兆交换机上的电脑,故障消除,接在百兆交换机上的电脑,故障依然存在。
5) 两台百兆交换机才用两年,难道会同时老化,处理性能下降了,何况换了一个新的同型号的备用交换机也不行,难道真的都要用千兆的吗?经多方咨询怀疑是交换机系统版本太低引起的,虽然不能确认上述故障就是由交换机后台系统的版本太低引起的,但是,我们知道最新版本的后台系统存在的BUG会更少,运行起来自然也就更稳定,于是,先将故障交换机通过搭建FTP服务器对交换机的操作系统进行升级,从低版本操作系统Release 5103P01升级到新版本Release R5203P07。[2] 结果,连接在千兆和百兆交换机上的电脑一切正常。
6) 将另一台原先的百兆交换的操作系统也升级到最新版本,换回那台千兆的交换机。升级后,两台原来的百兆交换机,除了交换机的内存使用率比原来高些,达到50%,其它情况一切正常,各终端工作站的应用也都能正常使用。
3 讨论
交换机故障问题大致包括物理层故障、端口协商以及自环问题、Vlan问题、设备兼容问题等,从上面的故障排除过程来看,当出现网络故障时通常按以下步骤检查排除:(1)根据故障信息分析故障类型,尽量按照先易后难的顺序,如:是硬件故障还是软件引起的故障;(2)确定故障范围;(3)进行故障隔离,对故障范围内的网络基础设备,在排查故障时尽可能地按照“终端工作站-连接线缆-端口模块-网络跳线-交换机”这样的顺序依次逐一进行排查[3]。当然,网络故障原因复杂、多变,还存在一些用常规方法无法排查的疑难故障,比如网络病毒、网络拓扑缺陷、个别元器件老化等,这些故障没有特有规律可寻,不妨静下心来多想想自己平时很少注意到的一些细节因素,依靠自身的经验积累和借助一些网络工具来分析解决。另外,我们在购买交换机组建局域网的时候,应该去选用那些质量可靠、品牌过硬、内存容量较大的交换机设备,毕竟这样的设备自身有较强的抗干扰能力。
接入层交换机 篇2
这一现象在Slammer和冲击波事件中早已屡见不鲜，宽带接入交换机究竟面临哪些安全风险?怎样才能化解这些风险?接下来我们将逐一揭示，
宽带接入交换机的风险
利用抓包工具，笔者经常捕获到大流量的异常报文，它们一方面消耗网络带宽，另一方面消耗网络设备的资源，影响网络的正常运行。单播类异常报文：单播流量大多数是发送给网关，网关设备根据路由表对这些报文做出转发或丢弃处理。对私有IP地址，公网三层交换机或路由器会自动丢弃单播流量。如果用户已经获得一个公网IP地址，这些单播流量就会被转发出去，进而影响更大范围的网络。以冲击波病毒为例，中毒主机只要监测到网络可用，就会启动一个攻击传播线程，不断随机生成攻击地址进行攻击。在冲击波发作严重的阶段，网络速度明显变慢，一些接入层交换机和一些小型路由器甚至崩溃，宽带接入交换机的CPU利用率达到100%，运营商不得不采取屏蔽ICMP报文的办法加以应对。
广播类异常报文：广播是实现某些协议的必要方式。广播报文会发送给特定网段内的所有主机，每台主机都会对收到的报文进行处理，做出回应或丢弃的决定，其结果是既消耗网络带宽又影响主机性能。利用端口隔离技术，用户可以限制广播报文只发往上行端口，这样可以减小对本网段链路和主机的影响，但无法解决对汇聚层和核心层设备造成的影响。如果在汇聚或核心设备上将多个小区划在一个VLAN内，广播类流量就会通过上层设备返回到其他小区，进而继续占用这些小区的链路带宽并影响主机性能，这种配置方法在当前宽带网络中广泛存在。
组播类异常报文：组播类信息本来只服务于网络内的部分用户，其目的地址是网络内申请加入组播组的主机。一些主机并没有申请加入组播组，这些组播报文本不应该转发给这些主机，但是事实上这些主机还是收到了组播信息。是什么原因导致组播报文转发给没有申请加入的主机呢?原来，为了实现组播，二层交换机使用GMRP组播注册协议或IGMPSnooping协议来维护一个动态组播表，然后把组播报文转发给与该组播组成员相关的端口，以实现在VLAN内的二层组播，如果没有运行IGMPSnooping，组播报文将在二层广播，这就是导致组播泛滥的原因，
随着宽带网络的进一步普及以及视频应用的逐渐增加，组播技术将会得到更广泛地应用，那时组播类异常流量不仅会出现在网络的第二层，而且还会路由到整个组播树。加上视频类信息流量较大，很难区分正常流量和不正常流量。因而对组播进行控制也就更加困难了。
总之，局域网内的应用存在被病毒利用的可能性，如果不有效限制异常流量，就会对网络带宽以及网络设备造成资源消耗。因此，为面向用户的二层交换机增加智能，把问题隔离在最小的范围内，就显得尤为重要。
化解风险的对策
利用宽带接入交换机的流量控制功能，我们能够把流经端口的异常流量限制在一定的范围内。例如，Cisco交换机具有基于端口的流量控制功能，能够实现风暴控制、端口保护和端口安全。风暴控制能够缓解单播、广播或组播包导致的网络变慢，通过对不同种类流量设定一个阈值，宽带接入交换机在端口流量达到设定值时启动流量控制功能甚至将端口宕掉。端口保护类似于端口隔离，设置了端口保护功能的端口之间不交换任何流量。端口安全是对未经许可的地址进行端口级的访问限制。无独有偶，华为交换机提供流量控制和广播风暴抑制比等端口控制功能。流量控制功能用于交换机与宽带接入交换机之间在发生拥塞时通知对方暂时停止发送数据包，以避免报文丢失。广播风暴抑制可以限制广播流量的大小，对超过设定值的广播流量进行丢弃处理。
不过，宽带接入交换机的流量控制功能只能对经过端口的各类流量进行简单的速率限制，将广播、组播的异常流量限制在一定的范围内，而无法区分哪些是正常流量，哪些是异常流量。同时，如何设定一个合适的阈值也比较困难。如果需要对报文做更进一步的控制用户可以采用ACL(访问控制列表)。ACL利用IP地址、TCP/UDP端口等对进出交换机的报文进行过滤，根据预设条件，对报文做出允许转发或阻塞的决定。Cisco和华为的交换机均支持IPACL和MACACL，每种ACL分别支持标准格式和扩展格式。标准格式的ACL根据源地址和上层协议类型进行过滤，扩展格式的ACL根据源地址、目的地址以及上层协议类型进行过滤。
接入层交换机 篇3
当前网络运营商不断提出各种宽带用户终端接入数量的限制, 本文主要从技术的角度来研究局域网用户接入数量的分析和研究, 以CISCO3560交换机为例, 研究和分析基于MAC地址的主机访问控制。
如果交换机端口下连接的是一台主机时的端口安全设置方法, 即只有指定的主机才能访问网络, 其它的主机 (以MAC地址为唯一标识) 是无法通过CIS-CO的这个端口访问网络。
3560#conf t
Enter configuration commands one per line.End with CNTL/Z.
3560 (config) #inter fa0/10
3560 (config-if) #switchport port-security
3560 (config-if) #switchport port-security maximum 1
3560 (config-if) #switchport port-security mac-address 3232.3251.2326
这种措施虽然有效, 可以准确的对相应MAC地址的主机进行访问控制, 但是却有一定的局限性, 具体表现为CISCO3560交换机的很多端口下面是连接有交换机, 而且还是普通的二层交换机, 这也就相当于一个端口下面有多台主机通过, 针对这种情况如何实现只有指定的MAC地址的主机才能通过呢。我主要尝试了两种办法。
1、通过限制连接主机的数量, 还是通过端口安全的相关命令来实现, 但是发现效果不理想, 只是实现了限制连接主机数量的操作, 我通过一系列的实验终于得到了一个结论, 多数情况下CISCO3560的端口下面连接了二层交换机, 以前我们使用采用的端口安全措施就不怎么有效了, 无法实现只有指定的主机的MAC地址才能通过, 最多只能限制端口中通过的MAC地址数量的上限, 比如我们最大允许10台主机通过CISCO3560交换机的第10端口, 操作步骤如下:
查看端口10的当前配置如下
这样的设置也是属于端口安全的一种, 只不过以上的操作是通过限制通过的主机数量来保护端口的带宽, 这在我们的工作实际中倒是也是这样的需要, 比如我们开通了一个单位的互联网用户, 采用包月制, 这样就需要限制这个单位同时上网的主机数量, 比如不能超过25台, 就可以通过设置这样设置“maximum”的值为“25”来实现。这种措施是有效的, 但是距离我们的要求还有一定的距离, 我们还是想实现即使是CISCO3560端口下面连接了一台普遍的二层交换机, 也可以达到只有指定的MAC地址的主机 (若干台主机) 才可以访问网络的目的。
2、基于MAC地址的ACL来实现
为了实现第一种方法中存在的问题这种目标, 我们转换了思路, 探索通过基于MAC地址的ACL (访问控制列表) , 结果发现这种方法是行之有效的。通过这种方式, 网络结构是相同的, 只不过思想更换为通过ACL来实现, 我们以前设置的ACL多是基于IP地址, 对于基于MAC的ACL设置较少, 其实这两类ACL的设置思路是一致的, 步骤如下。
(一) 定义一个MAC地址访问控制列表并且命名该列表名为mac0605
#Switch (config) mac access-list extended mac0605
(二) 定义MAC地址为3232.3251.2326的主机可以访问任意主机
#Switch (config) permit host 3232.3251.2326 any
#Switch (config) permit any host 3232.3251.2326
(三) 进入配置具体端口模式
#Switch (config) interface fa0/10
(四) 在该端口上应用名为mac0605的访问列表
#Switch (config) mac access-group mac0605 in
(五) 显示配置结果
以上方法当中在进行实际测试时发现了一个很有趣的现象, 仔细对这个现象进行分析, 也进一步加深了我对CISCO交换机工作原理的理解。我们写好了基于MAC的ACL, 如何来做测试, 有两套方案, 一套是将cisco3560交换机第十端口上连接一台主机, 将其MAC地址修改为3232.3251.2326, 该主机可以正常访问网络 (利用带t参数的ping命令来测试) , 更改为主机的MAC地址为其它值后ping命令显示的结果马上就中断了, 说明基于MAC的ACL是有效的。但是我们还通过另外一套方案进行了测试, 即保持主机的MAC地址不变, 通过修改ACL中permit的MAC的值来测试 (如先no掉permit host 3232.3251.2326 any, 再写入一条permit host 3232.3251.2326 any) , 这时就不是马上不通了, 而是会是一个10分钟左右的时延。
为什么会出现这个现象, 因为交换机中MAC表有一个老化时间, 由于我们这次是采取的在ACL中修改MAC值来指定, 那么ACL中的值与实际交换机检测到端口所连接的主机MAC地址不一致有一个时间差, 在这个时间差之内那台主机还是可以访问网络的, 过了这个时间, 就无法访问网络了。
参考文献
[1]张文婷.局域网常见问题的处理及优化[J].电子制作.2013 (20)
[2]穆尼拉.塔西买买提.浅析医院局域网管理与维护[J].河南科技.2010 (10)
[3]陈远燕.浅谈如何保证计算机局域网的管理与安全[J].中国科教创新导刊.2009 (14)