有一些不可网管的交换机也支持流控功能,这个流控有什么作用呢?在交换机发生拥挤的情况下,可以发送特定的信息,让对端交换机减慢发送数据的频率,用以保证数据传输的效率;下面是我摘取H3C的一些定义:
当本端和对端交换机都开启了流量控制功能后,如果本端交换机发生拥塞,它将向对端交换机发送消息,通知对端交换机暂时停止发送报文;而对端交换机在接收到该消息后将暂时停止向本端发送报文;反之亦然。从而避免了报文丢失现象的发生。默认是关闭的;
为老婆打工
有一些不可网管的交换机也支持流控功能,这个流控有什么作用呢?在交换机发生拥挤的情况下,可以发送特定的信息,让对端交换机减慢发送数据的频率,用以保证数据传输的效率;下面是我摘取H3C的一些定义:
当本端和对端交换机都开启了流量控制功能后,如果本端交换机发生拥塞,它将向对端交换机发送消息,通知对端交换机暂时停止发送报文;而对端交换机在接收到该消息后将暂时停止向本端发送报文;反之亦然。从而避免了报文丢失现象的发生。默认是关闭的;
M$这霸王龙又出来咬人了,在windows2008上提出来SSTP VPN技术出来,号称可以完全取代原有的pptp l2tp技术,更安全,更简单;先不谈他的技术有多NX,只是总有一种君临天下的优越感,看看那些托的文章吧,把原有的技术说得一文不值,其实没几个论据是靠得住的,不过这种也不算是什么新事物吧,我没深入了解其他厂家的SSL VPN技术,不知道之前有没有人提出来过,按道理是很容易想到的.先贴一下M$托的文章:
http://www.windowsecurity.com/articles/Secure-Socket-Tunneling-Protocol.html
分析一下:所谓SSTPVPN技术就是把all datas over ssl ,只使用443 port来传输数据及其trunnel的建立,这样防火墙穿透NAT问题,都可以一次性解决了,因为没有人会封掉https;对比之前的pptp l2tp,sstp的确应用起来很简单,认真分析此文,尚未提到site-to-site的是如何使用sstp的,可能也是一种remote access的技术,那就是摆明就是要拆SSL VPN的场子;对这种新兴的技术,有一点我尚未找到相关的文档,就是全通道(SSL VPN)的方式,是不是也是通过pptp来透传数据,还是说所有的数据都只会使用443 port来传输呢?如果sstp vpn不存在全通道的说法,tunnel建立成功是不是就像ipsec一样直接使用对端资源(当然可以设置相关的安全规则),那要是这样设计的话,是要比现行的各种remote access vpn方案来得高明一些,学习中...
61.144.238.145
61.144.238.146
61.144.238.156
202.104.129.251
202.104.129.254
202.104.129.252
202.104.129.253
61.141.194.203
202.96.170.166
218.18.95.221
219.133.45.15
61.141.194.224
202.96.170.164
218.17.209.23
218.18.95.153
61.141.194.227
218.18.95.171
218.17.209.42
219.133.63.142
QOS应用,8021p,针对企业网络的特点,我总结一些常用的设置方法:
level 6 voip
level 5 视频会议
level 4 企业ERP(VPN)特定公司使用的应用
Level 3 企业领导流量
level 0 普通员工的流量
level 1 用户软件类的升级数据,也就是背景流量。不占用其他流量。
7和2一般很少用到,就不管了了,7是设备流量如vtp 路由协议;
流量整型cir pir
在针对内网的数据进行设计的时候,建议使用802.1p来设计QOS。就是优先级,DSCP的技术,类思科的金/银/铜的配置类似。
网络边缘QOS设计思路:
高要求网络,可考虑使用CDN,广域网加速方案辅助QOS;
这一块的QOS是最复杂的,包括队列算法,带宽管理,拥塞避免,拥塞管理。
我的经验是这样,队列算法一定要选择好,个人认为加权WFQ是比较合适,具体问题具体分析。
带宽管理,可以像TC工具一样的思想吧,对不同的带宽进行分类,形成一个树形结构,如果要求不是非常精确,可以启用借用带宽。
注意:在网络边缘产品,一般有分是上传还是下载的速率。
最近在研究一下openldap的schema,同时也去学习了一下exchange2007,发现,开源界和windows的差距真的是越来越明显了. 这windows的发展方向明显有很大的野心啊,产品基本把企业的信息体系,方方面面都做到这么完美,从SPS到现在的IG,太令人信服了.完美得让人压抑,可能是我想太多,过于天真喽,哈哈.windows向来习惯把所有底层都隐藏起来,显在我们面前的是一个漂亮的界面,简单的配置,有时也玩玩新花样,搞搞新名词,时不时来个面目全飞脚,是逼还是发展的需要,总之硬件是要不断升级,这次exchange2007干脆来个支持64位,NB啊强啊,好了不聊了.
schema可以自己定义,这种结构很像snmp的oid,snmp的oid就算是自己定义出来也要去自己编代码,让snmp代理来读取相关的信息.而openldap schema自己定义出来的OID是不是也是要这样呢? 正在找资料论证中,直觉告诉我是不用的,因为LDAP是直接查询管理员已存储好的信息,而SNMP则是动态的去查询设备的相关状态,简单来说就是LDAP所获取的是静态的信息,SNMP是动态的信息.从这个层面上来看,LDAP只是一种查询服务,一种更高级优化过的服务,树型结构被无数证明这是多么伟大的一种结构,spandtree,ospf spandtree,都是tree啊.
|
OID |
Assignment |
| 1.1 | Organization’s OID |
| 1.1.1 | SNMP Elements |
| 1.1.2 | LDAP Elements |
| 1.1.2.1 | AttributeTypes |
| 1.1.2.1.1 | myAttribute |
| 1.1.2.2 | ObjectClasses |
| 1.1.2.2.1 | myObjectClass |
在微软新产品Windows server 2008中,相比以前版本的服务器操作系统,又融入了十项强大的新技术,不敢说这些技术是否真的能让用户得到更好的服务,但就微软而言体现了其对服务器系统要求尽善尽美的态度。
第十位:自修复NTFS文件系统。自从DOS时代开始,如果文件系统中发生文件出差问题就意味着磁盘需要脱机进行修复。而在Windows Server 2008中,在后台运行的服务能够检测到文件系统的错误并在发现文件出差的情况下启动一个修复进程,而期间并不需要关闭服务器。
第九位:并行会话创建。在Windows Server 2008之前的系统中,会话创建是一个串行操作。而在终端服务系统中,串行初始化会话会导致系统出现瓶颈。而这个在Vista和Windows Server 2008中提供的新会话模型至少能够同时对四个会话进行初始化,而且如果服务器的处理器多于四个时还能够同时初始化更多的会话。
第八位:干净的关闭服务。Windows中一个历史性遗留问题是系统关机的过程问题。在XP中,一旦关闭过程开始,系统就会启动一个历时20秒的计数器。当计数开始后,系统就会向用户发出信号询问是否用户自己中止应用程序。对于Windows Server来说,相同的20秒机制变成了应用程序的存活时间。
在Windows Server 2008中这个20秒倒数的机制已经被一个新的服务取代,这个服务会控制应用程序不断的发送程序需要关闭的信号,只要程序不断保持发送信号那么程序最终会关闭。某些开发人员可能会顾虑这个新服务会让应用程序耗掉太多资源,但从实际情况看来,性能方面的牺牲物有所值。
第七位:内核业务管理器。开发人员可以好好利用这个功能,它能够极大的减少最容易导致系统注册表和文件系统崩溃的发生次数:这是由于有多个线程同时访问某个资源引起。
在正式的数据库中,修改过的指令集按顺序先保存在内存中,跟着作为一个业务一次性提交。这种情况下,用户并不能获得数据库被修改过程中的快照,这些修改看起来是同时进行的。而这一功能最终在Vista和Windows Server 2008的系统注册表中被利用
第六位:SMB2网络文件系统。很久很久以前,SMB就被用作Windows的网络文件系统。而现在,SMB在灵活性、高性能方面已经力不从心,因此SMB2取而代之。根据内部测试结果显示,在媒体服务器上SMB2的性能是Windows Server 2003的30到40倍之多。
第五位:地址空间随机加载(ASLR)。自从它在Vista露面以来,可能这个功能是所有新增功能中最受争议的功能了。ASLR确保同一时间,在内存中同一区域没有两个相同的操作系统实例被加载。
第四位:Windows硬件错误架构(WHEA)。微软最终对硬件错误信息进行了标准化,利用这些面向硬件统一使用相同套接字接口报告的错误信息,第三方的软件能够方便的迁移并管理问题。
第三位:Windows Server虚拟化。微软的Windows Server 2008中将会集成虚拟化功能。
第二位:PowerShell。这两年以来,关于PowerShell一直传闻不断,现在最终确定了它是作为操作系统的一部分提供。它是一个命令行工具,但实际上能够完全取代图形界面的管理工具。
第一位:Server Core。从Windows Server 2008开始,系统中那些不是每个用户都用到的功能将会变成可选安装包,取而代之的是预先定义好的系统角色。
135端口
在许多“网管”眼里,135端口是最让人捉摸不透的端口,因为他们中的大多数都无法明确地了解到135端口的真正作用,也不清楚该端口到底会有哪些潜在的危险。直到一种名为“IEen”的专业远程控制工具出现,人们才清楚135端口究竟会有什么样的潜在安全威胁。
IEen工具能够借助135端口轻松连接到Internet上的其他工作站,并远程控制该工作站的IE浏览器。例如,在浏览器中执行的任何操作,包括浏览页面内容、输入帐号密码、输入搜索关键字等,都会被IEen工具监控到。甚至在网上银行中输入的各种密码信息,都能被IEen工具清楚地获得。除了可以对远程工作站上的IE浏览器进行操作、控制外,IEen工具通过135端口几乎可以对所有的借助DCOM开发技术设计出来的应用程序进行远程控制,例如IEen工具也能轻松进入到正在运行Excel的计算机中,直接对Excel进行各种编辑操作。
怎么样?135端口对外开放是不是很危险呀?当然,这种危险毕竟是理论上的,要想真正地通过135端口入侵其他系统,还必须提前知道对方计算机的IP地址、系统登录名和密码等。只要你严格保密好这些信息,你的计算机被IEen工具攻击的可能性几乎不存在。
为什么IEen工具能利用135端口攻击其他计算机呢?原来该工具采用了一种DCOM技术,可以直接对其他工作站的DCOM程序进行远程控制。DCOM技术与对方计算机进行通信时,会自动调用目标主机中的RPC服务,而RPC服务将自动询问目标主机中的135端口,当前有哪些端口可以被用来通信。如此一来,目标主机就会提供一个可用的服务端口作为数据传输通道使用。在这一通信过程中,135端口的作用其实就是为RPC通信提供一种服务端口的映射功能。说简单一点,135端口就是RPC通信中的桥梁。
137端口
137端口的主要作用是在局域网中提供计算机的名字或IP地址查询服务,一般安装了NetBIOS协议后,该端口会自动处于开放状态。
要是非法入侵者知道目标主机的IP地址,并向该地址的137端口发送一个连接请求时,就可能获得目标主机的相关名称信息。例如目标主机的计算机名称,注册该目标主机的用户信息,目标主机本次开机、关机时间等。此外非法入侵者还能知道目标主机是否是作为文件服务器或主域控制器来使用。
138端口
137、138端口都属于UDP端口,它们在局域网中相互传输文件信息时,就会发生作用。而138端口的主要作用就是提供NetBIOS环境下的计算机名浏览功能。
非法入侵者要是与目标主机的138端口建立连接请求的话,就能轻松获得目标主机所处的局域网网络名称以及目标主机的计算机名称。有了计算机名称,其对应的IP地址也就能轻松获得。如此一来,就为黑客进一步攻击系统带来了便利。
139端口
139端口是一种TCP端口,该端口在你通过网上邻居访问局域网中的共享文件或共享打印机时就能发挥作用。
139端口一旦被Internet上的某个攻击者利用的话,就能成为一个危害极大的安全漏洞。因为黑客要是与目标主机的139端口建立连接的话,就很有可能浏览到指定网段内所有工作站中的全部共享信息,甚至可以对目标主机中的共享文件夹进行各种编辑、删除操作,倘若攻击者还知道目标主机的IP地址和登录帐号的话,还能轻而易举地查看到目标主机中的隐藏共享信息。
445端口
445端口也是一种TCP端口,该端口在Windows 2000 Server或Windows Server 2003系统中发挥的作用与139端口是完全相同的。具体地说,它也是提供局域网中文件或打印机共享服务。不过该端口是基于CIFS协议(通用因特网文件系统协议)工作的,而139端口是基于SMB协议(服务器协议族)对外提供共享服务。同样地,攻击者与445端口建立请求连接,也能获得指定局域网内的各种共享信息。
到了这里,相信你对各端口开放时存在的安全威胁早已是恐慌不已了。毕竟,对这些端口放任不管的话,随时都可能引来“飞来横祸”。别急,下面本文特意为你提供了一些安全防范措施,让你根据实际需要,有选择、有针对性地关闭服务端口,以切断外来入侵途径。
看到一个相当精彩的ospf lsa的总结,写的真是太完美了.如果有一天,我也有这样的文笔,做梦都会笑啊.下面为转贴:
NSSA原理简介
众所周知,OSPF路由协议是目前因特网中应用最为广泛一种IGP,而NSSA则是在该协议发展过程中产生的一种新的属性,她的英文全称是”not-so-stubby” area,一个充满了幽默味道的名字。要想了解该属性的特征,我们先从路由协议的发展历程讲起。
1.2 从D-V算法到链路状态算法
RIP作为最古老的动态路由协议,使用D-V算法来计算路由。由于当时的网络环境非常简单,所以RIP协议的设计思想也是简洁为本,只求完成最基本的功能。这样在RIP应用于大型拓扑复杂的网络时,就会出现效率不高、收敛慢、路由自环等问题。其中尤以路由自环的危害最大。此时必须有新的路由协议来适应日益复杂的网络,而且新的路由协议必须要解决RIP遇到的所有问题。由于D-V算法对网络的理解是基于“平面的”——在运行RIP协议的路由器眼中,网络仅仅是由一个个直连的邻居和一条条由邻居通告的路由组成。这样在网络拓扑变化时难免会导致计算错误,产生自环。为了彻底解决这个问题,一种全新的算法——链路状态算法应运而生。该算法从“立体”的角度来看待网络,每一台路由器都理解全局网络的拓扑结构,并依据此来计算路由,由于每台路由器对网络的整体情况“一切尽在掌握”,所以自环的问题被这彻底的解决。
1.3 OSPF协议与区域
基于链路状态算法的OSPF协议虽然彻底的解决了路由自环问题,但这种算法本身也有很多固有的缺陷:
耗费更多内存资源:每台路由器都必须保存整个网络的拓扑结构(以LSDB的形态)
耗费更多CPU资源:该算法的路由计算使用SPF算法,较D-V算法要复杂的多。
计算更为频繁:只要网络中有任何一台路由器的拓扑方生变化,会导致网络中所有的路由器进行SPF计算,而且每台路由器都是将SPF算法重新执行一遍,以便找出变化的路由。
而且,无论是D-V算法还是链路状态的路由协议都存在如下缺陷:
没有从协议本身反映出网络的层次结构。因为实际应用中的一个网络是由各种级别的路由器组成的,有核心层的骨干路由器、汇聚层的高端路由器、接入层的低端路由器。这些路由器承担的任务不同,处理性能也不一样。但在路由协议中,所有的路由器都要完成几乎是相同的工作:发送已知的路由给邻居路由器,根据从邻居路由器获得的路由信息计算本地路由表。虽然每台路由器的接口数量不同,但最终计算得来的路由表的规模基本是一样的。
为了彻底解决上述问题,OSPF提出了区域的概念(AREA),区域是将所有运行OSPF 的路由器人为的分成不同的组,以区域id来标示。在区域内路由计算的方法不变,由于划分区域之后,每个区域内的路由器不会很多,所有上述缺陷表现得并不严重,带来的后果可以忽略不计。而在区域之间计算路由时采用D-V算法,这样三个缺点就被成功的规避了。实际上区域概念的提出意义远不只这些,在划分为区域之后:
网络的拓扑结构就与路由协议之间存在了一种对应关系,核心和高端的路由器由于处理能力强,可以规划在骨干区域之中。因为骨干区域的路由器要承担更多的路由计算任务。
每个单独的区域实际上就是一个独立于网络中其他区域的系统,可以在不同的区域中试行不同的路由策略,使组网规划更为灵活方便。
实际上OSPF 协议在当今的网络中广为流行,不是因为她使用了无环路的链路状态算法,而是因为她提出了区域的概念!
1.4 STUB区域
STUB区域就是一个对区域概念的最典型的应用。STUB区域的设计思想在于:在划分了区域之后,非骨干区域中的路由器对于区域外的路由,一定要通过ABR(区域边界路由器)来转发,或者说对于区域内的路由器来说ABR是一个通往外部世界的必经之路。既然如此,对于区域内的路由器来说,就没有必要知道通往外部世界的详细的路由了,代之以由ABR向该区域发布一条缺省路由来指导报文的发送。这样在区域内的路由器中就只有为数不多的区域内路由和一条指向ABR的缺省路由。而且无论区域外的路由如何变化,都不会影响到区域内路由器的路由表。由于区域内的路由器通常是由一些处理能力有限的低端路由器组成,所以处于STUB区域内的这些低端设备既不需要保存庞大的路由表,也不需要经常性的进行路由计算。有了STUB属性之后,网络的规划更符合实际的设备特点。
以上描述的只是STUB区域的设计思想,在协议文本中,对STUB区域的精确定义是:STUB区域一定是非骨干区域和非转换区域(可以配置虚连接的区域),并且在该区域中不可传递Type 5类型的LSA。 因为协议的设计者认为路由表中的绝大部分路由均是来自自治系统外部的引入的路由。(由于OSPF是链路状态算法的路由协议,LSA就是用来描述网络拓扑结构的一种数据结构。在OSPF 中将LSA分为5类:type1、2两种用来描述区域内的路由信息;type3用来描述区域间的路由信息;type4、5用来描述自治系统外部的路由信息。)
需要注意的是定义中对于过滤TYPE5类型的LSA使用的描述语言是“不可传递”,这就意味着不仅区域外的ASE(自治系统外部)路由无法传递到STUB 区域中,同时STUB区域内部的ASE路由也无法传递到本区域之外。换一句更通俗的话来描述:STUB区域内的路由器都不可引入任何外部的路由(包括静态路由)。
这样的定义未免太过严厉了。因为在实际的组网中,并不是所有的设备都会运行OSPF协议。例如:用户拨号上网时使用的接入服务器就需要连接路由器上因特网,但通常接入服务器上并不支持(也不需要)OSPF协议,而是通过配置静态路由实现路由功能。很多时候ISP为了保密或易于管理的需要,在连接用户侧的路由器时使用静态路由。总之:在一个网络中所有的路由器上都配置OSPF,而不使用静态路由的情况几乎是不存在的。——也就是说STUB区域的适用条件也是不存在的。
1.5 NSSA区域
STUB区域虽然为合理的规划网络描绘了美好的前景,但她在实际的组网中又不具备可操作性,未免遗憾。但此时的OSPF协议已经基本成型,不可能再做大的修改。为了弥补缺陷,协议设计者提出了一种新的概念NSSA,并且作为OSPF协议的一种扩展属性单独在RFC 1587中描述。
NSSA需要完成如下任务:
自治系统外的ASE路由不可以进入到NSSA区域中,但是NSSA区域内的路由器引入的ASE路由可以在NSSA中传播并发送到区域之外。即:取消了STUB关于ASE的双向传播的限制(区域外的进不来,区域里的也出不去),改为单向限制(区域外的进不来,区域里的能出去)。
由于是作为OSPF标准协议的一种扩展属性,应尽量减少与不支持该属性的路由器协调工作时的冲突和兼容性问题。
为了解决ASE单向传递的问题,NSSA中重新定义了一种LSA——Type 7类型的LSA,作为区域内的路由器引入外部路由时使用,该类型的LSA除了类型标识与Type 5不相同之外,其它内容基本一样。这样区域内的路由器就可以通过LSA的类型来判断是否该路由来自本区域内。但由于Type 7类的LSA是新定义的,对于不支持NSSA属性的路由器无法识别,所以协议规定:在NSSA的ABR上将NSSA内部产生的Type 7类型的LSA转化为Type 5类型的LSA再发布出去,并同时更改LSA的发布者为ABR自己。这样NSSA区域外的路由器就可以完全不用支持该属性。
从上述描述可以看出:在NSSA区域内的所有路由器必须支持该属性(包括NSSA的ABR),而自治系统中的其他路由器则不需要。
由于NSSA是由STUB区域的概念改进得来,所以她的名字叫做: “not-so-stubby” area ,本意是:不是那么STUB的区域。
第2章 NSSA相关配置
NSSA的原理不复杂,配置更简单,相关命令只有一条:
[Router-ospf]
area area-id nssa [ default-route-advertise ] [ no-import-route ] [ no-summary ]
area-id:是需要配置成NSSA的区域的区域号。“[]”内的参数只有在该路由器是ABR时才会生效。
关键字default-route-advertise用来产生缺省的Type-7 LSA,应用了该参数后,在ABR上无论路由表中是否存在缺省路由0.0.0.0,都会产生Type-7 LSA缺省路由;而在ASBR上当路由表中存在缺省路由0.0.0.0,才会产生Type-7 LSA缺省路由。
关键字no-import-route用在ASBR上,使得OSPF通过import-route命令引入的路由不被通告到NSSA区域。如果NSSA的路由器既是ASBR也是ABR,一般选用该参数选项。
为了进一步减少发送到NSSA区域中的链路状态发布(LSA)的数量,可以在ABR上配置no-summary属性,禁止ABR向NSSA区域内发送summary_net LSAs(Type-3 LSA)。配置该参数后,ABR会将Type3类型的LSA也过滤掉,即:NSSA区域中也不会出现区域间路由,路由表进一步精简。既然有缺省路由,那么其他指向区域外的具体路由都是没有必要的了。该参数推荐配置。
即:如果路由器只是一台区域内路由器,只需配置area area-id nssa即可。如果是ABR,根据实际需要,选择添加三个可选参数
为什么cisco在中国这么受欢迎,但是从来没看到什么所谓的中文版的cisco工具呢??真是不爽,摆明看不起中国人!!一个ACS,一个简单的vpn工具,都没有相应的简体版,这不是说会不会用的问题,而是一个态度问题.以后有机会用cisco的,一定要换成华为的,靠.
radius服务器在windows不要钱的太难找了,但是用来做实验而已的话,那倒还是有的.如winradius.
下载:http://www.onlinedown.net/soft/2752.htm
国外也有个,不过不是很好用.
http://www.loriotpro.com/Products/RadiusServer/FreeRadiusServer_EN.php
推荐生产环境用openradius.
以前为做个PDF文件还到处找软件,Adobe Pagemaker像这种大家伙,真的玩不起.好不容易找个破解的,还对中文支持不好.晕倒.呵,知道WPS有直接输出PDF功能.但让我意外的是,金山公司推出了只有20M的精简版,不用一分钟下载,还不用一分钱.不错的啊.支持.马上下载换下office,反正我也用不了那么多高级功能,只是简单编下文档.
为金山公司这次行为叫好.