售前工程师必备的能力和素质.docx

上传人:b****5 文档编号:11883311 上传时间:2023-04-08 格式:DOCX 页数:18 大小:33.96KB
下载 相关 举报
售前工程师必备的能力和素质.docx_第1页
第1页 / 共18页
售前工程师必备的能力和素质.docx_第2页
第2页 / 共18页
售前工程师必备的能力和素质.docx_第3页
第3页 / 共18页
售前工程师必备的能力和素质.docx_第4页
第4页 / 共18页
售前工程师必备的能力和素质.docx_第5页
第5页 / 共18页
点击查看更多>>
下载资源
资源描述

售前工程师必备的能力和素质.docx

《售前工程师必备的能力和素质.docx》由会员分享,可在线阅读,更多相关《售前工程师必备的能力和素质.docx(18页珍藏版)》请在冰豆网上搜索。

售前工程师必备的能力和素质.docx

售前工程师必备的能力和素质

售前工程师必备的能力和素质

在中国IT业界,有这么一群技术人员,往往辛苦地工作在第一线,任劳任怨,没有多少时间来交流,但他们确是最具备交流能力的一群人,他们没有象那些开发者一样在公司中那么显眼,但他们确是本应该在公司中最露脸的人物,这就是售前工程师,或者说技术顾问,更加可叹的是,我们的专家在绞尽脑汁地分析和争议为什么会出现一万元的ERP?

为什么这个项目本该100万中标的却只有20万?

这些为什么,做为一个售前人员是最清楚的了。

正当他们谈论恶意竞争的时候和感叹法规不完善的时候,一个真正的售前人员可以很轻易的分析究竟是什么导致了这些情况的发生!

如果大家还对售前这个职务没有概念的话,请看江月先生发表的文章:

售前工程师的来世今生

今天,笔者只是一个普通的售前人员,没有必要讨论那些宏观的事情,只是抱着为了售前这个职务有一个更好的发展这个良好的想法,同时真正为我们的客户着想,拨开那些层层的迷雾,让我们的项目做的更加顺利,为IT业尽一份力,同时也响应IT应用服务网那句话:

“这里不需要豪言壮语,不需要喧哗的概念,我们只要切实行动,从小做起,一切为客户着想”,

笔者思考良久,还是采用随笔的方式,简简单单,从一个售前必须具备的能力和素质的角度,进而也顺带讲解一些IT业界在竞标中出现的一些情况和分析。

笔者希望本文的读者:

那些可敬的工作在第一线的售前工程师、想从事售前的工程师,那些公司的经理CEO、CTO,还有我们的用户,以及对这个职务好奇或关心这个职务的人。

前言

在现在的项目运做中,随着客户个性化需求的提出,以及各类技术的涌现,一个良好的售前工程师要具备什么样的能力和素质呢,那些素质最重要呢,要回答这些问题,我们就要抓住几点,售前的目的是做什么,售前的核心目的:

是把公司的产品或解决方案让用户充分肯定并更进一步,使用户在众多可选项目中选种你的产品和方案。

我们不防想象一下,在竟标的现场,是最激动人心的场面了,你可能是公司老总,你可能是CTO,你可能是公司售前技术顾问,那么在用户的面前你其实就是一个普通的售前工程师,用户和专家把他们各自关心的细节准备好了,为的是向你提问,另外对你每一句陈词,甚至某个字眼都有可能成为攻击你的目标,解释的好,可能成为你标书的亮点,解释不好,成为你标书的“暗点”。

一旦成为你的“暗点”,这些日子,你们公司售前组花了几个通宵的精力打造的一本漂亮的标书就成了几页废纸,抱憾终生。

如果有人说招标是走过场的形式,可以不必在意,关于这个问题,我会在以后的文章里专门探讨,所谓无论是走什么过场,都逃离不了“囚徒困境”的博弈,终究要回到“你的这些问题终究要决定的结果,什么样的花结什么样的果”这一伟大立场上来。

为了避免这些问题,我就非常有必要回到我们的正题:

究竟一个售前要具备什么样的能力和素质呢?

下面是一个非常容易接受的命题逻辑,在这个逻辑上我们再细细探讨:

(1)用户不可能比你了解你公司和你公司产品技术

(2)用户不一定了解用户的所有需求,你不一定了解用户的所有需求

(3)用户不能够自己解决自己的问题

第1个命题很简单,如果他要是比你还了解你公司的话,他自己就能提出你公司的解决方案了,要不要你,不在于你,完全在于他了。

第2个命题也不难,用户要是知道他所有的需求的话,那就太好了,你的开发经理就不必搞什么需求调研了,开发好的项目直接就可以上线了,万事大吉,实际上往往不是这样,用户并不一定了解,他不了解的话,你就更不一定了解了。

第3个命题也很简单,用户通常是没有能力去解决自己的问题,或者是不必要自己去解决自己的问题,所以你才有去拿这些项目的机会,前提是你要有这个实力。

所以针对第1个命题,一个售前必须具备呈现(presentationcapability)方面的能力,有了这个能力才可以充分展现你公司的实力,和你公司的解决方案,以及对他所有问题的响应程度。

所以针对第2、3个命题,一个售前必须清楚用户要解决什么问题,和知道如何去解决这些问题,这样你就必须具备发现问题和解决问题的能力,这个能力最终是落实到技术层面上来的,一个售前必须具备另一种能力:

过硬的技术(TechnicalSkills)

这就是为什么说:

“售前嘛,能说会做,能写会练”所以说做售前不容易就在于此。

其实以上这两个能力是用户非常关心的,但是要把售前工作做好,把项目作好,从售前本身出发还要自身的个人品质方面的素质,想象一下,一个技术非常厉害的售前,如果在标书里面经常放一些非常低级的错误,如:

项目名称都弄错,报价少了一个零等等。

恐怕对用户也不好交代哦。

笔者根据自身多年的投标和售前工作经验,针对售前提出如下3个层面的素质或能力要求。

呈现方面

(1)沟通能力

(2)卓越的演讲能力,(3)睿智的答辩能力,(4)精湛的写作能力,

技术方面

(1)业务专家,

(2)需求分析专家;(3)产品专家;(4)技术专家;

个人品质方面

(1)细心;

(2)耐心;(3)信心;(4)虚心;(5)勤奋;

一个售前的能力和素质如下图所示:

 

为了把这么多内容解释清楚,委实不易,但我们可以用验证法,其中有一个很有效的方法是关键验证法,俗话说:

“管他白猫黑猫,抓到老鼠就是好猫”,“到了关键的时候才能正确的评价一个人”,那么投标的时候也能评价一个售前;有一次评标结束,我们正要上台演讲,前面出来上一家公司的两个人在小声埋怨,“你是怎么搞的,页眉页角怎么弄错了呢?

”你看,专家可以通过你的呈现发现人性非常底层的属性-不太细心,如果那位专家往下一想:

这家公司,做事马虎,不够严谨,恐怕难以胜任这种项目啊,这就不好了。

呈现能力

大家回到这张图上来,你要是出了纰漏,用户和专家是很容易发现的,为什么,下面详细介绍:

其实这个时候决定你的成败就在于你的呈现,这里的呈现包括:

标书技术方案的好坏,商务报价的高低,服务与实施等等,但这些东西是从你嘴巴讲出来,和标书里写出来的。

有时候,专家是不能够面面俱到去看你的标书,因为这里有一个原则:

一个好的标书,你很容易讲好,你不太容易讲坏;一个不好的标书,你不容易讲好,你很容易讲坏;不妨再想象一下,一个口才一般的售前,讲标的售前你肯定要熟悉你的标书,你标书要是写的很好,你照着约定的PPT讲,效果不好也不坏,但至少没有什么漏洞和把柄让用户抓住,至少达到让用户认可你了(这是售前的最初目的:

肯定你),如果你标书本身就没有吃透用户的需求,设计也很马虎,你口才一般,按照约定的PPT讲,没有什么发挥,效果也就恰恰反映了你标书的情况----糟糕,用户和专家就必然对你提出很多疑点,甚至刁难。

所以呈现要好的话,标书必定要写好,这也就是专家可以泰然听你演讲而并不看你标书的原因了。

如果你标书写的好,呈现能力强的情况会怎么样了?

答案是太妙了,锦上添花啊,如何才能锦上添花呢,这才是一个关键,所谓艺高人胆大,过犹而不及,一个人往往讲的兴奋了,就可能天花乱坠,本来不应该把有些技术讲的太深的,而他偏偏一时高兴,越来越深,如脱缰野马,拉不回来了,会出现两难境地,1)容易跑题,用户专家不满,耽误时间;2)言多必失,若此时出现技术纠缠,就坏事了。

第一位:

沟通能力

没有了解,就没有发言权,相信大家在投标过程中,对用户都有一定的了解,而了解不是去参观用户,而是与用户去沟通,而沟通无处不在,投标前要沟通,投标中要沟通(在讲标过程中察言观色,调整自己的思路),投标后也要沟通,大家很少看见一个事先与用户没有任何接触,却突然中标的事情吧。

在这里,笔者妄自把沟通能力放在首位,所谓不打无准备的战,沟通是一种语言和行为的交流,在作战之前讲标人一定要了解前因后果,一定是要参与标书的人,通过这种沟通,在真正的战场上,你面对你的受众(用户,专家),你就知道哪些应该是你强调的,哪些是你应该规避的,你的发言框架就大致确定了,发挥起来就有的放矢。

在这里笔者要指出的是,很多公司,派出去的讲标人并不是参与标书的人去讲标,比如销售经理,技术经理,甚至总经理,他们无外呼基于如下考虑:

这些职务形象比较专注,或技术比较好,领导重视,但是如果他们没有清楚整个标书的细节,会出现前面所说的:

天花乱坠,跑题;讲的和标书承诺的不一致;技术实现与用户需求脱节等细节错误;等这些技术要售前工程师来答疑澄清的时候,已经失去先机,这些情况发生的不在少数。

所以专业的公司宁愿培养一名优秀的售前工程师来担此重任,比如:

有些公司通过录象和培养演讲水平等方式来提高售前呈现能力就是一个很好的例子。

第二位:

卓越的演讲能力

我们售前工程师面对客户的时候,客户第一印象就是,哦,这是某某公司的技术顾问来了,这个时候售前工程师无形中就代表了公司的形象,所以在这个售前的能力图中,在一个讲标的过程中,如果一个售前面对多名专家,气定神闲,风度翩翩而温和谦虚会是一种什么样的感觉?

如果我是专家,我一定会非常欣赏,人往往会认同一个人,既而认同他的思想,所谓爱屋及乌,这是人性的弱点,正是这个可爱的弱点,许多不可思议的情况发生了。

这里笔者同样要贸然指出:

在进行你精彩演讲之前,千万要参与了整个售前项目,把细节处理到位,做到名副其实。

然而现实情况中,还是有许多标书做的很好,讲解的时候结结巴巴,吞吞吐吐,让用户听不清楚,甚至曲解你的意思,导致效果大打折扣。

在这里提醒,所谓卓越的演讲,千万不要弄成大话空话,这样让人生厌。

第三位:

睿智的答辩能力

在一般的标书呈现过程中,答辩是比不可少的,一般的需要答辩的问题是你标书现有的情况,用户或专家一时并不理解,要你阐述一下,还有的情况是,提出某些具体的功能,考核你是如何实现的,对于前一种情况,大部分售前都能处理好,后一种情况,往往很有争议,为什么呢?

因为用户或专家心理也有一种实现方法,所以在阐述你的观点的同时,千万不要太过于肯定,我经常听到用户在这个时候说:

“呵呵,你说的这个方法,还没有讲到点子上”其实呢,用户也不一定有好的方法,可能是各自的理解不同而已,如果你一时激动,与用户争持,往往得不到好的结果,所以对于这些问题的处理,就要小心了,一般可以在回答之前,一定要说方法有很多种,时间关系先说其中的一种,说完以后呢,一定要补充一句:

“其实,这位专家您这个问题问得非常好,您肯定还有其他方法,我们可以继续探讨”,专家也有思维定势,他有可能就透露他的想法,这个时候,你要是业务熟悉,技术熟悉的话,就可以接过来,继续发挥:

“哦,对了,你这个想法与我们第2种方式比较类似……”这样至少不会出现让你冷场的话。

关于如何处理这些答辩,笔者准备了很多案例,将在未来的文章中发表,这里不做深入讨论。

第四位:

精湛的写作能力

大家不要忘记,呈现分两种,一是语言的呈现,二是标书和演讲稿的呈现,一个好的标书,行文要流畅,用语要规范,意思要明了,现实中很多标书都是相互引用(COPY)的,引用太多会导致标书整体质量下降,比如:

出现一些低级错误:

文字啊,名称啊,最可怕的是出现其他业务背景的东西,我不反对引用,但是一定要有针对性的,对一些功能和实现手段一定要量身定做,对需求一定要分析透彻,由于标书不一定是由一个人写的,每个人的文笔不同,术语也不同,容易造成标书行文不流畅,当然这里也有长时间配合的问题。

在这里写关于写作,话题实在太广泛,我在这里强调的是精湛文笔会对标书起到非常好的作用,在日益频繁的投标竞争中,从比较优势来讲,你会超越竞争对手的。

售前技术能力

在用户面前,售前就是一个专家,特别是投标过程中,用户最想看到的是作为一个公司技术人员的代表,是什么水平,而刚才说了,所有的技术能力,都在呈现中去发挥,问题是,你一定要有技术,你才能去发挥啊,这里就开始讲,一个售前需要具备那些技术相关的背景。

第一位:

业务专家

在IT项目中,行业越来越细分了,如果你对ERP熟悉,你是做不了移动BOSS项目的,隔行如隔山,很难想象一个对用户业务一点背景都没有的人,通过技术能打动用户的心,所以作为一个技术售前,业务要放在第一位,近年来,很多曾经是甲方的用户,或多或少到乙方去做顾问去了,为什么,乙方需要熟悉业务的人啊,笔者接触过许多医生在IT公司做医务系统的顾问,还发现很多业务专家成了公司的CTO,往往地矿专业的学生能够比计算机专业的学生更能够在GIS系统中发挥作用。

第二位:

需求分析专家

需求分析在许多IT公司和系统集成公司不够重视,这要归咎中国作坊试的软件企业和不成熟软件公司的遗传所至,关于这个问题,请大家看看我前面写的一篇文章:

关于售前题目

(一)的答案。

很难想象一个不知道用户到底要做什么的公司,能给用户交付一个项目。

一个售前也要分析用户的需求的,只有分析了需求,才可能在方案里按照需求来设计他要的功能,而这些功能将直接影响到产品选型和报价。

如果一个连需求都没有概念的售前工程师你招聘他试试看,哪些在某些项目中报出天价或跳楼价的往往是连需求都没有把握的公司所至,如果用户要是采纳了这些公司的方案,你可以想象一下出来的系统会是一个什么系统。

这是对用户不负责,对自己也不负责的行为。

我在这里就可以顺带回答那些为什么20万也可以做100万的项目了,有两种可能,售前(或者是公司领导)曲解用户的需求,采用一些本不合适产品来实现那些功能,大大低估了开发量,本来是几十万的ORACLE做双机的,他采用免费的MYSQL,本来是量身定制的软件,他用现成的开发完毕的产品上线,反正用户也不明白需求,这样一个超低价格就产生了,另外就是你根本就不知道需求,在这个行业里一点背景都没有,根据自己的情况,胡乱报一个价,抱着只要销售能够搞定,其他都是次要的,加上恶意破坏这个行业的企图(反正他也没有在这个行业长期做的打算)超低价格就这样出现了。

第三位:

技术专家

用户的需求,还是要通过技术手段来实现,就象一道菜有多少种做法,给你20元钱,你如何去做,采用什么样的构架,做成什么样,没有技术,你是不可能去做这道菜的,甚至技术好的,你可以花比别人少的钱,做的比别人的好。

对一个软件项目你知道是采用J2EE好呢,还是.NET好,对这个级别的存储,是采用SAN呢,还是NAS,对这个网络是采用MPLS实现VPN呢,还是采用2层的VPN技术,对于他提出的安全隐患,你是如何解决的,采用什么样的防火墙,和入侵检测系统。

等等,这些都是售前可能要面对的,当然,一个售前不太可能面面俱到,这就需要多个领域的售前了,关于多个售前如何组织标书的,我会在未来的文章中阐述。

第四位:

产品专家

一个售前了解了用户的业务,分析了需求,确定了功能,选好了技术,那么总要某种原料来做这道菜吧,所谓巧妇难为无米之炊,技术路线选好了,数据库有SQL,ORACLE,SYBASE,应用服务器中间件有TOMCAT,WEBLOGIC,WEBSPHERE,商业智能工具有BO、BRIO、MicroStrategy等等,价格不一样,功能不一样,应用范围不一样,开发难度不一样,做为售前的你,如果不了解,你如何实现一道20元钱物美价廉的菜呢,何况,专家冷不丁地问道:

“你为什么要用ORACLE企业版啊?

”,如果你对产品熟悉的话,你一定知道在这种功能和需求下,那是非ORACLE莫属了。

个人品质

很多人会说,一个好的售前非常难得,能说会做,能写会练,别忘了,售前本身是一个细致活,而且投标是一个艰巨的任务,如果一个售前什么都好,但他很马虎,他很懒,他不一定把投标这道菜做好,曾经A省招标中,有一本标书,出现了B省的业务现状描述,用户哗然,在开标现场大发牢骚,导致那家公司无法正常把标书讲下去……。

这样痛苦的经历不得不提醒笔者,在个人品质中,细心程度是第一位的,在这里笔者必须强调:

是个人品质属性,不是品德,我相信没有一个人愿意故意去犯这种错误。

第一位:

细心

前面说了,在呈现的时候,能发现售前的技术能力,同时也发现售前个人品质属性的东西,在这里,没有必要更进一步解释大家都明白的东西,如果你做售前不细心,你就等着厄运吧。

第二位:

耐心

一个没有耐心的售前,除了需求做的不完善以外,还可能在答标现场发生与用户争持的情况,你所有的呈现,不由自主的反映你的内心世界,纵有演讲的天赋,一个不自主的恼怒,都会前功尽弃,推荐一部售前可以看的电影:

《肖申克的赎罪》,表面木纳的他在寂寞中花了15年的时间成功越狱。

第三位:

信心

很难想象一个在用户面前很紧张的人,能把交流做好,能把标书讲好,具备一定的信心,把心态放稳,是一个售前必须具备的个人品质。

第四位:

虚心

如果你认同前面的哪个命题:

“用户不一定了解用户的所有需求,你不一定了解用户的所有需求”,那用户提出任何异议的话,你最好站在用户的这一边,来提出一个好的建议,除非你有无穷的智慧,无与伦比的口才;谦虚一点,会海阔天空,毕竟你是要按用户的习惯做设计的。

第五位:

勤奋

一个懒惰的售前,不太可能把标书做漂亮了,敷衍了事的标书,一定会有漏洞的,不要忘记,每当投标,工作量是非常大的,有授权,有应答,有价格的经常变动,一个好的售前是要保持跟踪的。

网络售前工程师必须懂的专业术语

路由器问题:

  1、什么时候使用多路由协议?

  当两种不同的路由协议要交换路由信息时,就要用到多路由协议。

当然,路由再分配也可以交换路由信息。

下列情况不必使用多路由协议:

  从老版本的内部网关协议(InteriorGatewayProtocol,IGP)升级到新版本的IGP。

  你想使用另一种路由协议但又必须保留原来的协议。

  你想终止内部路由,以免受到其他没有严格过滤监管功能的路由器的干扰。

  你在一个由多个厂家的路由器构成的环境下。

  什么是距离向量路由协议?

  距离向量路由协议是为小型网络环境设计的。

在大型网络环境下,这类协议在学习路由及保持路由将产生较大的流量,占用过多的带宽。

如果在90秒内没有收到相邻站点发送的路由选择表更新,它才认为相邻站点不可达。

每隔30秒,距离向量路由协议就要向相邻站点发送整个路由选择表,使相邻站点的路由选择表得到更新。

这样,它就能从别的站点(直接相连的或其他方式连接的)收集一个网络的列表,以便进行路由选择。

距离向量路由协议使用跳数作为度量值,来计算到达目的地要经过的路由器数。

  例如,RIP使用Bellman-Ford算法确定最短路径,即只要经过最小的跳数就可到达目的地的线路。

最大允许的跳数通常定为15。

那些必须经过15个以上的路由器的终端被认为是不可到达的。

  距离向量路由协议有如下几种:

IPRIP、IPXRIP、AppleTalkRTMP和IGRP。

  什么是链接状态路由协议?

  链接状态路由协议更适合大型网络,但由于它的复杂性,使得路由器需要更多的CPU资源。

它能够在更短的时间内发现已经断了的链路或新连接的路由器,使得协议的会聚时间比距离向量路由协议更短。

通常,在10秒钟之内没有收到邻站的HELLO报文,它就认为邻站已不可达。

一个链接状态路由器向它的邻站发送更新报文,通知它所知道的所有链路。

它确定最优路径的度量值是一个数值代价,这个代价的值一般由链路的带宽决定。

具有最小代价的链路被认为是最优的。

在最短路径优先算法中,最大可能代价的值几乎可以是无限的。

  如果网络没有发生任何变化,路由器只要周期性地将没有更新的路由选择表进行刷新就可以了(周期的长短可以从30分钟到2个小时)。

  链接状态路由协议有如下几种:

IPOSPF、IPXNLSP和IS-IS。

  一个路由器可以既使用距离向量路由协议,又使用链接状态路由协议吗?

  可以。

每一个接口都可以配置为使用不同的路由协议;但是它们必须能够通过再分配路由来交换路由信息。

(路由的再分配将在本章的后面进行讨论。

  2、什么是访问表?

  访问表是管理者加入的一系列控制数据包在路由器中输入、输出的规则。

它不是由路由器自己产生的。

访问表能够允许或禁止数据包进入或输出到目的地。

访问表的表项是顺序执行的,即数据包到来时,首先看它是否是受第一条表项约束的,若不是,再顺序向下执行;如果它与第一条表项匹配,无论是被允许还是被禁止,都不必再执行下面表项的检查了。

  每一个接口的每一种协议只能有一个访问表。

  支持哪些类型的访问表?

  一个访问表可以由它的编号来确定。

具体的协议及其对应的访问表编号如下:

  ◎IP标准访问表编号:

1~99

  ◎IP扩展访问表编号:

100~199

  ◎IPX标准访问表编号:

800~899

  ◎IPX扩展访问表编号:

1000~1099

  ◎AppleTalk访问表编号:

600~699

  提示在CiscoIOSRelease11.2或以上版本中,可以用有名访问表确定编号在1~199的访问表。

  如何创建IP标准访问表?

  一个IP标准访问表的创建可以由如下命令来完成:

Access-listaccesslistnumber{permit|deny}source

  在这条命令中:

  ◎accesslistnumber:

确定这个入口属于哪个访问表。

它是从1到99的数字。

  ◎permit|deny:

表明这个入口是允许还是阻塞从特定地址来的信息流量。

  ◎source:

确定源IP地址。

  ◎source-mask:

确定地址中的哪些比特是用来进行匹配的。

如果某个比特是"1",表明地址中该位比特不用管,如果是"0"的话,表明地址中该位比特将被用来进行匹配。

可以使用通配符。

  以下是一个路由器配置文件中的访问表例子:

  Router#showaccess-lists

  StandardIPaccesslist1

  deny204.59.144.0,wildcardbits0.0.0.255

  permitany

3、什么时候使用路由再分配?

  路由再分配通常在那些负责从一个自治系统学习路由,然后向另一个自治系统广播的路由器上进行配置。

如果你在使用IGRP或EIGRP,路由再分配通常是自动执行的。

  4、什么是管理距离?

  管理距离是指一种路由协议的路由可信度。

每一种路由协议按可靠性从高到低,依次分配一个信任等级,这个信任等级就叫管理距离。

对于两种不同的路由协议到一个目的地的路由信息,路由器首先根据管理距离决定相信哪一个协议。

  在进行路由再分配之前,你必须首先:

  1)决定在哪儿添加新的协议。

  2)确定自治系统边界路由器(ASBR)。

  3)决定哪个协议在核心,哪个在边界。

  4)决定进行路由再分配的方向。

  可以使用以下命令再分配路由更新(这个例子是针对OSPF的):

  router(config-router)#redistributeprotocol

  在这个命令中:

  ◎protocol:

指明路由器要进行路由再分配的源路由协议。

  主要的值有:

bgp、eqp、igrp、isis、ospf、static、connected和rip。

  ◎process-id:

指明OSPF的进程ID。

  ◎metric:

是一个可选的参数,用来指明再分配的路由的度量值。

缺省的度量值是0。

  7、为什么确定毗邻路由器很重要?

  在一个小型网络中确定毗邻路由器并不是一个主要问题。

因为当一个路由器发生故障时,别的路由器能够在一个可接受的时间内收敛。

但在大型网络中,发现一个故障路由器的时延可能很大。

知道毗邻路由器可以加速收敛,因为路由器能够更快地知道故障路由器,因为hello报文的间隔比路由器交换信息的间隔时间短。

  使用距离向量路由协议的路由器在毗邻路由器没有发送路由更新信息时,才能发现毗邻路由器已不可达,这个时间一般为10~90秒。

而使用链接状态路由协议的路由器没有收到hello报文就可发现毗邻路由器不可达,这个间隔时间一般为1

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 高等教育 > 医学

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1