1.本技术是有关于一种电子装置及管理方法，且特别是有关于一种通信装置及网络管理方法
背景技术：
：：2.以太交换机(ethernetswitch)在传递封包(packet)过程，会因为服务质量原则(qospolicy)或是转发机制的配置，导致封包被丢弃。在此情况下，网管人员需要根据网络拓扑，在每个交换机的管理信息库(managementinformationbase)所记录的计数器分析以得到封包被丢弃的原因。然而，当管理信息库被传输给中央网络管理层时，由于网络传输量庞大，网管人员查看到的问题及其发生时间点不一定实时，并且管理信息库也可能在网络中被丢失，导致无法追朔封包被丢弃的时间和原因。3.网络遥测技术(networktelemetry)是另一种实现网管的方法。然而，网络遥测技术仅能查看原始封包的内容，没有封包的经历路径和服务质量状态。若想得到封包的经历路径和服务质量状态，则需要额外设置硬件以将需要的数据放入原始封包。然而，这样的方法花费额外的硬件成本及网络带宽，并且在原始封包嵌入数据的文件头格式并没有统一标准。4.因此，如何得到封包被丢弃时的时间和原因以及具体的封包内容，是本领域技术人员想要解决的技术问题。技术实现要素：5.
发明内容旨在提供本公开内容的简化摘要，以使阅读者对本技术内容具备基本的理解。本
发明内容并不是本公开内容的完整概述，且其目的并不是指出本技术实施例的重要/关键组件或界定本技术的范围。6.根据本技术的一实施例，公开了一种通信装置，经配置以接收一数据流，该通信装置包括一监控端口以及一封包处理器。监控端口经配置以接收该数据流的封包。封包处理器耦合在该监控端口，其中该封包处理器经配置以计算该封包的一摘要值，以及该封包处理器根据该封包的该摘要值计算出该封包的一标识符，在一查找表中查找关联该标识符的一状态值，以判断是否已记录关联该数据流的该丢弃事件。7.根据另一实施例，公开一种网络管理方法，经配置以分析一数据流，该网络管理方法包括以下步骤：接收该数据流的一封包；计算该封包的一摘要值；以及根据该封包的该摘要值计算出该封包的一标识符，在一查找表中查找关联该标识符的一状态值，以判断是否已记录关联该数据流的丢弃事件。附图说明8.结合附图阅读以下详细描述时，将有利于更好地理解本公开文件的内容。应注意，为了说明的目的，附图中各特征并不一定按比例绘制。实际上，出于说明清楚的目的，可能任意增加或减小各特征的尺寸。9.图1显示根据本技术一些实施例中通信装置的配置示意图。10.图2显示根据本技术一些实施例中一种通信装置的模块示意图。11.图3显示根据本技术一些实施例中一种网络管理方法的流程示意图。12.图4a-4d显示根据本技术一些实施例中的哈希算法的示意图。13.图5a-5c显示根据本技术一些实施例中的查找表的示意图。具体实施方式14.以下公开内容提供许多不同实施例，以便实施本技术的不同特征。下文描述组件及排列的实施例以简化本技术。当然，这些实施例仅为示例性且并不是限制性的。举例而言，本技术中使用“第一”、“第二”等用语描述组件，仅是用于区别相同或相似的组件或操作，该用语并非用于限定本技术的技术组件，也不是用于限定操作的次序或顺序。另外，本技术可在各实施例中重复组件符号和/或字母，并且在各实施例中，相同的技术用语可使用相同和/或相应的组件符号。这种重复是出于简明和清楚的目的，且并不指示所讨论的各实施例和/或配置之间的关系。15.图1显示根据本技术一些实施例中通信装置的配置示意图。通信装置pe1中储存目的端口转发表tb。如图1所示，客户端c1欲传送数据流df至客户端c2。在正常情况下，通信装置pe1应该透过端口p1将数据流转送至客户端c2。转发路径应为通信装置ce1、pe1、pe3、pe4、ce2。然而，通信装置pe1可能设定错误或其他原因而将数据流的封包丢弃，例如输出端口的虚拟局域网过滤器(egressvlanfilter)的设定错误，使得封包被误判为不符合通过端口p1而被丢弃。16.为了监控这些封包被丢弃的原因，通信装置pe1上可开启事件监控程序。17.在一些实施例中，如图1所示，通信装置pe1被设置一监控端口p2。例如，当封包被输出端口的虚拟局域网过滤器所丢弃时，封包会被重新导向至监控端口p2。此时，封包的头部被扩增修改后，会被传送至监控中心m1，使得网络管理者可统筹这些被丢弃的封包信息，以进行丢弃封包事件的监控。18.在另一些实施例中，通信装置pe1可设定一监控端口(如图1中目的端口转发表tb的cpuport)，在封包被判定为应该被丢弃时，用以接收被丢弃封包，以进行后续的诊断(diagnostic)。19.请参照图2，其显示根据本技术一些实施例中一种通信装置200的模块示意图。如图2所示，通信装置200包括封包处理器210、数据端口220、监控端口230以及内存240。封包处理器210耦合在数据端口220、监控端口230以及内存240。数据端口220经配置以执行一般的数据封包接收/转送。通信装置200可以有多个数据端口220，为简化说明书内容，在此以一个数据端口220作为示例。举例而言，通信装置200透过数据端口220接收一数据流的封包。若通信装置200判断此封包应该被丢弃，则会被重新导向至监控端口230。监控端口230可以是图1的监控端口p2或是监控端口cpuport。20.为进一步说明本技术的通信装置200，请一并参照图3。图3显示根据本技术一些实施例中一种网络管理方法的流程示意图。21.在步骤s305，通过数据端口220接收一数据流的封包。在一些实施例中，同一个数据流的封包，具有相同的特征。因此，通信装置200可通过封包的特征来取得封包所属的数据流。22.在步骤s310，判断该封包是否符合一丢弃事件。丢弃事件可以为但不限于封包携带不匹配或错误的信息导致无法找到正确的目的端口、非法或疑似入侵封包、因为通信装置200的内存空间不足而导致封包无法被执行储存转发(storeandforward)、查找表未命中(lookuptablemiss)等事件，而导致封包被判定应被丢弃。23.在一些实施例中，若封包被判断不符合一丢弃事件，则在步骤s355，执行后续的数据转发，此封包将被传送至目的地位置。24.当封包被判断符合丢弃事件，则在步骤s315，封包会被重新导向至监控端口230。在一些实施例中，封包会透过监控端口230被储存在内存240。内存240包括复数个队列，各队列具有不同的优先权。根据封包的性质及其优先程度，当封包被封包重新导向后，此些封包会被分配到不同优先权的队列。封包处理器210会依据优先权来读取队列中的封包，以执行后续的诊断程序(例如高优先权的队列中的封包会被优先诊断)。25.在一些情况下，若突发的大量监控封包被重新导向至监控端口230，即相同类型的数据流的多个封包被储存在内存240，将使得通信装置200需要大量处理相同类型的封包诊断，这会造成浪费运算资源的问题。为避免此问题，在一些实施例中，通信装置200会执行抑制过滤(suppressionfilter)程序。在抑制过滤程序中，仅同一个数据流中被通信装置200收到的第一个封包会被重新导向至监控端口230。若同一个数据流已有封包被完成诊断，则后续若此数据流的封包发生丢弃事件，此封包也不会被重新导向至监控端口230。如此，封包处理器210仅需要处理同一个数据流的一个封包即可，而不需要浪费时间及储存空间在相同数据流的丢弃事件上。抑制过滤流程说明如下。26.首先，通信装置200对数据流进行分类。在步骤s320，通过封包处理器210使用封包的特征值及丢弃事件来计算封包的摘要值(digestvalue)。封包的特征值可以为但不限于封包中记录的目的媒体访问控制地址、来源媒体访问控制地址、目的因特网协议地址、源因特网协议地址、以太网络类型、虚拟局域网识别符、第四层目的端口、第四层源端口、封包标头、封包流识别符。27.在一些实施例中，摘要值是根据哈希算法、封包的特征值及丢弃事件被计算得到。举例而言，封包内容为长度32位的二进制数值。图4a-4d显示根据本技术一些实施例中的哈希算法的示意图。28.在一些实施例中，如图4a所示，哈希算法可以为对原始封包400进行反转，将原始封包400的最高有效位(mostsignificantbit)反转为最低有效位(leastsignificantbit)，以得到封包401。接着，对原始封包400及封包401进行互斥或运算，运算结果为封包400的第一摘要值。29.在一些实施例中，如图4b所示，哈希算法可以为反转原始封包400，而得到两个经过反转的封包403及封包404。接着，对封包403及封包404进行互斥或运算，运算结果为封包400的第二摘要值。30.在一些实施例中，如图4c所示，哈希算法可以为将原始封包400分割为两段并对调此两段的次序后，得到封包405。接着，对封包405与原始封包400进行互斥或运算，运算结果为封包400的第三摘要值。31.在一些实施例中，如图4d所示，哈希算法可以为取两个封包405进行互斥或运算，运算结果为封包400的第四摘要值。值得一提的是，图4a至图4d为实施例说明，本技术不限制此些哈希算法。32.在步骤s325，根据封包的摘要值来计算出封包的标识符。举例而言，摘要值的长度为32位。通信装置200可分配232的大小的查找表来记录此摘要值是否已被记录过。然而，为节省内存空间，本技术在步骤s325中，会压缩摘要值的长度，以缩小查找表的大小。查找表是用于记录关联于摘要值的状态值。33.在一些实施例中，标识符的长度小于摘要值的长度。举例而言，摘要值的长度，例如32位，被压缩为例如14位，被压缩长度的摘要值称为标识符。举例而言，32位长度的摘要值被分割成三段长度为14位的数据(其中最后一段仅4位有数据，其余字段补零)。通过对此三段数据例如互斥或运算而得到长度14位的标识符。此标识符对应至查找表的地址(例如地址0至地址214-1)。查找表的地址所指向的内容为状态值，代表摘要值对应的封包是否已经被接收过(下文将进行详细说明)。因此，只需要配置214的大小的查找表即可记录长度为32位的摘要值的状态值。在另一些实施例中，标识符的长度也可以等于摘要值的长度，本技术不限制摘要值被压缩之后的长度。34.在步骤s330，在一查找表中查找关联于标识符的状态值。在一些实施例中，由于使用哈希算法来计算哈希值，存在一些机率可能会使得数据流虽不同但却会计算得到相同的摘要值(哈希值)，而发生碰撞(collision)。因此，本技术计算同一个封包的多个哈希值，以避免碰撞问题。本技术的实施例中以四个哈希算法及四个查找表来分别记录对应于各数据流的摘要值的状态值。但是，本技术并不限制查找表的个数，使用两个以上的查找表来记录状态值均属本技术的范畴。35.请参照图5a-5c，其显示根据本技术一些实施例中的查找表的示意图。摘要值被压缩后产生的标识符，其分别透过第一哈希算法501、第二哈希算法502、第三哈希算法503及第四哈希算法504被计算，而产生第一哈希值、第二哈希值、第三哈希值及第四哈希值。另一方面，第一查找表511对应于第一哈希算法501，用以在第一哈希值的地址所指向的内容记录第一状态值。相似地，第二查找表512对应于第二哈希算法502，用以在第二哈希值的地址所指向的内容记录第二状态值。第三查找表513对应于第三哈希算法503，用以在第三哈希值的地址所指向的内容记录第三状态值。第四查找表514对应于第四哈希算法504，用以在第四哈希值的地址所指向的内容记录第四状态值。封包处理器210可根据此四个状态值来判断是否有接收过此数据流。举例而言，状态值为0，代表通信装置200没有处理过此数据流的丢弃事件。状态值为1，则代表此数据流的丢弃事件有被处理过。36.在步骤s335，判断状态值是否等于一操作值。在一些实施例中，状态值用来判断数据流的封包是否被分析过。值得一提的是，状态值可以是一或多个位，本技术不限制状态值的位数，可依实际的状态数量来设计相应的位数，例如状态值可以是2个位的数值，以用来表示四种不同的状态。在此实施例中，状态值是1个位。当状态值是1时，代表通信装置200已分析过此数据流的封包，反之，当状态值是0时，代表通信装置200尚未分析此数据流的封包。为简化本技术说明书的说明，以操作值为1的实施例来说明封包是否被分析过，通常知识者可依据实际应用来设计不同情况的状态及其数值。37.如图5a所示，此四个地址所指向的内容，即状态值，分别为0、0、0、0。换言之，通信装置200没有分析过此数据流的封包。因此，在步骤s340，在监控事件中记录该封包的内容。举例而言，封包会被进行诊断，诊断结果被记录在监控事件中，以供网络管理人员参考。在一些实施例中，封包的内容包括封包被接收时的时间戳、关联于封包的丢弃事件、封包的输入端口及输出端口。38.在步骤s345，状态值被修改为操作值(例如，1)。如图5b所示，第一查找表至第四查找表中该标识符对应的状态值均被修改为1，如步骤s350，代表此数据流发生过丢弃封包的情况已被记录过。39.在一些实施例中，执行步骤s305～步骤s330，监控端口230接收到一数据流的封包，并且，此封包对应的状态值被对应地计算。在步骤s335中，若判断第一查找表至第四查找表中状态值均为1，如图5b所示，代表此数据流发生过丢弃封包的情况已被记录过，则丢弃此封包。此封包将不会被执行诊断流程(例如被转发至监控中心或被记录到监控事件)。40.值得一提的是，若在步骤s335中判断只有部分的查找表的状态值为1(例如第一查找表的状态值为1，其第二至第四查找表的状态值为0)，如图5c所示，则代表有碰撞发生，通信装置200仍会处理数据流的丢弃事件。举例而言，第一个数据流的第一封包通过第一哈希算法计算出哈希值3173，并且地址3173的内容已在先前的丢弃事件中被修改为1。然而，第二个数据流的第二封包通过第一哈希算法也计算出哈希值3173。由第二个数据流的第二哈希算法至第四哈希算法计算出的哈希值对应的状态值均为0的情况来看，第一封包与第二封包的哈希值发生碰撞。实际上，通信装置200没有处理过第二数据流。此时，通信装置200仍会处理第二数据流的丢弃事件。如此一来，多个哈希算法可以减少误判数据流是否被处理过的机率。41.在一些实施例中，通信装置200对数据流的摘要值设定一时效值(aging)。举例而言，若数据流的摘要值的时效值超过一阈值(例如时效值递增计数至阈值255)或者低于一阈值(例如时效值递减计数至阈值0)，则清除查找表中的状态值。如此，内存空间可被空出来记录新的数据流的状态值。举另一例来说，通信装置200会周期地清除查找表中的所有状态值(例如每天)。如此，查找表可随着数据流的周期性来记录状态值，提升使用效率。42.综上所述，本技术的通信装置及网络管理方法不需要设置额外的硬件成本来对封包嵌入需要的管理信息(降低芯片成本)，网络管理人员只需要在通信装置上修改设定，将封包转发至处理器或特定端口，即可监控被丢弃的封包。此外，在封包发生丢弃事件的当下，通信装置在记录管理信息库和统计计数器的同时，也会存储这些发生问题的封包、原因及时间戳，并且只需要记录一次(降低处理器的负担)，以产生分析报告供网管人员进一步查测，以减少除错流程的时间。43.上述内容概述若干实施例的特征，使得本领域技术人员可以更好地理解本技术。本领域技术人员应当理解，在不脱离本技术的精神和范围的情况下，可容易地使用上述内容作为设计或修改为其他变体的基础，以便实施本技术所介绍的实施例的相同目的和/或实现相同优势。上述内容应当被理解为本技术的举例，其保护范围应以权利要求为准。44.[附图标记说明][0045]c1、c2:客户端[0046]df:数据流[0047]ce1、ce2:通信装置[0048]pe1、pe2、pe3、pe4:通信装置[0049]m1:监控中心[0050]tb:目的端口转发表[0051]p0、p1、p2、cpuport:端口[0052]200:通信装置[0053]210:封包处理器[0054]220:数据端口[0055]230:监控端口[0056]240:内存[0057]400:原始封包[0058]401～405:封包[0059]501～504:哈希算法[0060]511～514:查找表[0061]s305～s355:步骤当前第1页12当前第1页12
背景技术：
：：2.以太交换机(ethernetswitch)在传递封包(packet)过程，会因为服务质量原则(qospolicy)或是转发机制的配置，导致封包被丢弃。在此情况下，网管人员需要根据网络拓扑，在每个交换机的管理信息库(managementinformationbase)所记录的计数器分析以得到封包被丢弃的原因。然而，当管理信息库被传输给中央网络管理层时，由于网络传输量庞大，网管人员查看到的问题及其发生时间点不一定实时，并且管理信息库也可能在网络中被丢失，导致无法追朔封包被丢弃的时间和原因。3.网络遥测技术(networktelemetry)是另一种实现网管的方法。然而，网络遥测技术仅能查看原始封包的内容，没有封包的经历路径和服务质量状态。若想得到封包的经历路径和服务质量状态，则需要额外设置硬件以将需要的数据放入原始封包。然而，这样的方法花费额外的硬件成本及网络带宽，并且在原始封包嵌入数据的文件头格式并没有统一标准。4.因此，如何得到封包被丢弃时的时间和原因以及具体的封包内容，是本领域技术人员想要解决的技术问题。技术实现要素：5.
发明内容旨在提供本公开内容的简化摘要，以使阅读者对本技术内容具备基本的理解。本
发明内容并不是本公开内容的完整概述，且其目的并不是指出本技术实施例的重要/关键组件或界定本技术的范围。6.根据本技术的一实施例，公开了一种通信装置，经配置以接收一数据流，该通信装置包括一监控端口以及一封包处理器。监控端口经配置以接收该数据流的封包。封包处理器耦合在该监控端口，其中该封包处理器经配置以计算该封包的一摘要值，以及该封包处理器根据该封包的该摘要值计算出该封包的一标识符，在一查找表中查找关联该标识符的一状态值，以判断是否已记录关联该数据流的该丢弃事件。7.根据另一实施例，公开一种网络管理方法，经配置以分析一数据流，该网络管理方法包括以下步骤：接收该数据流的一封包；计算该封包的一摘要值；以及根据该封包的该摘要值计算出该封包的一标识符，在一查找表中查找关联该标识符的一状态值，以判断是否已记录关联该数据流的丢弃事件。附图说明8.结合附图阅读以下详细描述时，将有利于更好地理解本公开文件的内容。应注意，为了说明的目的，附图中各特征并不一定按比例绘制。实际上，出于说明清楚的目的，可能任意增加或减小各特征的尺寸。9.图1显示根据本技术一些实施例中通信装置的配置示意图。10.图2显示根据本技术一些实施例中一种通信装置的模块示意图。11.图3显示根据本技术一些实施例中一种网络管理方法的流程示意图。12.图4a-4d显示根据本技术一些实施例中的哈希算法的示意图。13.图5a-5c显示根据本技术一些实施例中的查找表的示意图。具体实施方式14.以下公开内容提供许多不同实施例，以便实施本技术的不同特征。下文描述组件及排列的实施例以简化本技术。当然，这些实施例仅为示例性且并不是限制性的。举例而言，本技术中使用“第一”、“第二”等用语描述组件，仅是用于区别相同或相似的组件或操作，该用语并非用于限定本技术的技术组件，也不是用于限定操作的次序或顺序。另外，本技术可在各实施例中重复组件符号和/或字母，并且在各实施例中，相同的技术用语可使用相同和/或相应的组件符号。这种重复是出于简明和清楚的目的，且并不指示所讨论的各实施例和/或配置之间的关系。15.图1显示根据本技术一些实施例中通信装置的配置示意图。通信装置pe1中储存目的端口转发表tb。如图1所示，客户端c1欲传送数据流df至客户端c2。在正常情况下，通信装置pe1应该透过端口p1将数据流转送至客户端c2。转发路径应为通信装置ce1、pe1、pe3、pe4、ce2。然而，通信装置pe1可能设定错误或其他原因而将数据流的封包丢弃，例如输出端口的虚拟局域网过滤器(egressvlanfilter)的设定错误，使得封包被误判为不符合通过端口p1而被丢弃。16.为了监控这些封包被丢弃的原因，通信装置pe1上可开启事件监控程序。17.在一些实施例中，如图1所示，通信装置pe1被设置一监控端口p2。例如，当封包被输出端口的虚拟局域网过滤器所丢弃时，封包会被重新导向至监控端口p2。此时，封包的头部被扩增修改后，会被传送至监控中心m1，使得网络管理者可统筹这些被丢弃的封包信息，以进行丢弃封包事件的监控。18.在另一些实施例中，通信装置pe1可设定一监控端口(如图1中目的端口转发表tb的cpuport)，在封包被判定为应该被丢弃时，用以接收被丢弃封包，以进行后续的诊断(diagnostic)。19.请参照图2，其显示根据本技术一些实施例中一种通信装置200的模块示意图。如图2所示，通信装置200包括封包处理器210、数据端口220、监控端口230以及内存240。封包处理器210耦合在数据端口220、监控端口230以及内存240。数据端口220经配置以执行一般的数据封包接收/转送。通信装置200可以有多个数据端口220，为简化说明书内容，在此以一个数据端口220作为示例。举例而言，通信装置200透过数据端口220接收一数据流的封包。若通信装置200判断此封包应该被丢弃，则会被重新导向至监控端口230。监控端口230可以是图1的监控端口p2或是监控端口cpuport。20.为进一步说明本技术的通信装置200，请一并参照图3。图3显示根据本技术一些实施例中一种网络管理方法的流程示意图。21.在步骤s305，通过数据端口220接收一数据流的封包。在一些实施例中，同一个数据流的封包，具有相同的特征。因此，通信装置200可通过封包的特征来取得封包所属的数据流。22.在步骤s310，判断该封包是否符合一丢弃事件。丢弃事件可以为但不限于封包携带不匹配或错误的信息导致无法找到正确的目的端口、非法或疑似入侵封包、因为通信装置200的内存空间不足而导致封包无法被执行储存转发(storeandforward)、查找表未命中(lookuptablemiss)等事件，而导致封包被判定应被丢弃。23.在一些实施例中，若封包被判断不符合一丢弃事件，则在步骤s355，执行后续的数据转发，此封包将被传送至目的地位置。24.当封包被判断符合丢弃事件，则在步骤s315，封包会被重新导向至监控端口230。在一些实施例中，封包会透过监控端口230被储存在内存240。内存240包括复数个队列，各队列具有不同的优先权。根据封包的性质及其优先程度，当封包被封包重新导向后，此些封包会被分配到不同优先权的队列。封包处理器210会依据优先权来读取队列中的封包，以执行后续的诊断程序(例如高优先权的队列中的封包会被优先诊断)。25.在一些情况下，若突发的大量监控封包被重新导向至监控端口230，即相同类型的数据流的多个封包被储存在内存240，将使得通信装置200需要大量处理相同类型的封包诊断，这会造成浪费运算资源的问题。为避免此问题，在一些实施例中，通信装置200会执行抑制过滤(suppressionfilter)程序。在抑制过滤程序中，仅同一个数据流中被通信装置200收到的第一个封包会被重新导向至监控端口230。若同一个数据流已有封包被完成诊断，则后续若此数据流的封包发生丢弃事件，此封包也不会被重新导向至监控端口230。如此，封包处理器210仅需要处理同一个数据流的一个封包即可，而不需要浪费时间及储存空间在相同数据流的丢弃事件上。抑制过滤流程说明如下。26.首先，通信装置200对数据流进行分类。在步骤s320，通过封包处理器210使用封包的特征值及丢弃事件来计算封包的摘要值(digestvalue)。封包的特征值可以为但不限于封包中记录的目的媒体访问控制地址、来源媒体访问控制地址、目的因特网协议地址、源因特网协议地址、以太网络类型、虚拟局域网识别符、第四层目的端口、第四层源端口、封包标头、封包流识别符。27.在一些实施例中，摘要值是根据哈希算法、封包的特征值及丢弃事件被计算得到。举例而言，封包内容为长度32位的二进制数值。图4a-4d显示根据本技术一些实施例中的哈希算法的示意图。28.在一些实施例中，如图4a所示，哈希算法可以为对原始封包400进行反转，将原始封包400的最高有效位(mostsignificantbit)反转为最低有效位(leastsignificantbit)，以得到封包401。接着，对原始封包400及封包401进行互斥或运算，运算结果为封包400的第一摘要值。29.在一些实施例中，如图4b所示，哈希算法可以为反转原始封包400，而得到两个经过反转的封包403及封包404。接着，对封包403及封包404进行互斥或运算，运算结果为封包400的第二摘要值。30.在一些实施例中，如图4c所示，哈希算法可以为将原始封包400分割为两段并对调此两段的次序后，得到封包405。接着，对封包405与原始封包400进行互斥或运算，运算结果为封包400的第三摘要值。31.在一些实施例中，如图4d所示，哈希算法可以为取两个封包405进行互斥或运算，运算结果为封包400的第四摘要值。值得一提的是，图4a至图4d为实施例说明，本技术不限制此些哈希算法。32.在步骤s325，根据封包的摘要值来计算出封包的标识符。举例而言，摘要值的长度为32位。通信装置200可分配232的大小的查找表来记录此摘要值是否已被记录过。然而，为节省内存空间，本技术在步骤s325中，会压缩摘要值的长度，以缩小查找表的大小。查找表是用于记录关联于摘要值的状态值。33.在一些实施例中，标识符的长度小于摘要值的长度。举例而言，摘要值的长度，例如32位，被压缩为例如14位，被压缩长度的摘要值称为标识符。举例而言，32位长度的摘要值被分割成三段长度为14位的数据(其中最后一段仅4位有数据，其余字段补零)。通过对此三段数据例如互斥或运算而得到长度14位的标识符。此标识符对应至查找表的地址(例如地址0至地址214-1)。查找表的地址所指向的内容为状态值，代表摘要值对应的封包是否已经被接收过(下文将进行详细说明)。因此，只需要配置214的大小的查找表即可记录长度为32位的摘要值的状态值。在另一些实施例中，标识符的长度也可以等于摘要值的长度，本技术不限制摘要值被压缩之后的长度。34.在步骤s330，在一查找表中查找关联于标识符的状态值。在一些实施例中，由于使用哈希算法来计算哈希值，存在一些机率可能会使得数据流虽不同但却会计算得到相同的摘要值(哈希值)，而发生碰撞(collision)。因此，本技术计算同一个封包的多个哈希值，以避免碰撞问题。本技术的实施例中以四个哈希算法及四个查找表来分别记录对应于各数据流的摘要值的状态值。但是，本技术并不限制查找表的个数，使用两个以上的查找表来记录状态值均属本技术的范畴。35.请参照图5a-5c，其显示根据本技术一些实施例中的查找表的示意图。摘要值被压缩后产生的标识符，其分别透过第一哈希算法501、第二哈希算法502、第三哈希算法503及第四哈希算法504被计算，而产生第一哈希值、第二哈希值、第三哈希值及第四哈希值。另一方面，第一查找表511对应于第一哈希算法501，用以在第一哈希值的地址所指向的内容记录第一状态值。相似地，第二查找表512对应于第二哈希算法502，用以在第二哈希值的地址所指向的内容记录第二状态值。第三查找表513对应于第三哈希算法503，用以在第三哈希值的地址所指向的内容记录第三状态值。第四查找表514对应于第四哈希算法504，用以在第四哈希值的地址所指向的内容记录第四状态值。封包处理器210可根据此四个状态值来判断是否有接收过此数据流。举例而言，状态值为0，代表通信装置200没有处理过此数据流的丢弃事件。状态值为1，则代表此数据流的丢弃事件有被处理过。36.在步骤s335，判断状态值是否等于一操作值。在一些实施例中，状态值用来判断数据流的封包是否被分析过。值得一提的是，状态值可以是一或多个位，本技术不限制状态值的位数，可依实际的状态数量来设计相应的位数，例如状态值可以是2个位的数值，以用来表示四种不同的状态。在此实施例中，状态值是1个位。当状态值是1时，代表通信装置200已分析过此数据流的封包，反之，当状态值是0时，代表通信装置200尚未分析此数据流的封包。为简化本技术说明书的说明，以操作值为1的实施例来说明封包是否被分析过，通常知识者可依据实际应用来设计不同情况的状态及其数值。37.如图5a所示，此四个地址所指向的内容，即状态值，分别为0、0、0、0。换言之，通信装置200没有分析过此数据流的封包。因此，在步骤s340，在监控事件中记录该封包的内容。举例而言，封包会被进行诊断，诊断结果被记录在监控事件中，以供网络管理人员参考。在一些实施例中，封包的内容包括封包被接收时的时间戳、关联于封包的丢弃事件、封包的输入端口及输出端口。38.在步骤s345，状态值被修改为操作值(例如，1)。如图5b所示，第一查找表至第四查找表中该标识符对应的状态值均被修改为1，如步骤s350，代表此数据流发生过丢弃封包的情况已被记录过。39.在一些实施例中，执行步骤s305～步骤s330，监控端口230接收到一数据流的封包，并且，此封包对应的状态值被对应地计算。在步骤s335中，若判断第一查找表至第四查找表中状态值均为1，如图5b所示，代表此数据流发生过丢弃封包的情况已被记录过，则丢弃此封包。此封包将不会被执行诊断流程(例如被转发至监控中心或被记录到监控事件)。40.值得一提的是，若在步骤s335中判断只有部分的查找表的状态值为1(例如第一查找表的状态值为1，其第二至第四查找表的状态值为0)，如图5c所示，则代表有碰撞发生，通信装置200仍会处理数据流的丢弃事件。举例而言，第一个数据流的第一封包通过第一哈希算法计算出哈希值3173，并且地址3173的内容已在先前的丢弃事件中被修改为1。然而，第二个数据流的第二封包通过第一哈希算法也计算出哈希值3173。由第二个数据流的第二哈希算法至第四哈希算法计算出的哈希值对应的状态值均为0的情况来看，第一封包与第二封包的哈希值发生碰撞。实际上，通信装置200没有处理过第二数据流。此时，通信装置200仍会处理第二数据流的丢弃事件。如此一来，多个哈希算法可以减少误判数据流是否被处理过的机率。41.在一些实施例中，通信装置200对数据流的摘要值设定一时效值(aging)。举例而言，若数据流的摘要值的时效值超过一阈值(例如时效值递增计数至阈值255)或者低于一阈值(例如时效值递减计数至阈值0)，则清除查找表中的状态值。如此，内存空间可被空出来记录新的数据流的状态值。举另一例来说，通信装置200会周期地清除查找表中的所有状态值(例如每天)。如此，查找表可随着数据流的周期性来记录状态值，提升使用效率。42.综上所述，本技术的通信装置及网络管理方法不需要设置额外的硬件成本来对封包嵌入需要的管理信息(降低芯片成本)，网络管理人员只需要在通信装置上修改设定，将封包转发至处理器或特定端口，即可监控被丢弃的封包。此外，在封包发生丢弃事件的当下，通信装置在记录管理信息库和统计计数器的同时，也会存储这些发生问题的封包、原因及时间戳，并且只需要记录一次(降低处理器的负担)，以产生分析报告供网管人员进一步查测，以减少除错流程的时间。43.上述内容概述若干实施例的特征，使得本领域技术人员可以更好地理解本技术。本领域技术人员应当理解，在不脱离本技术的精神和范围的情况下，可容易地使用上述内容作为设计或修改为其他变体的基础，以便实施本技术所介绍的实施例的相同目的和/或实现相同优势。上述内容应当被理解为本技术的举例，其保护范围应以权利要求为准。44.[附图标记说明][0045]c1、c2:客户端[0046]df:数据流[0047]ce1、ce2:通信装置[0048]pe1、pe2、pe3、pe4:通信装置[0049]m1:监控中心[0050]tb:目的端口转发表[0051]p0、p1、p2、cpuport:端口[0052]200:通信装置[0053]210:封包处理器[0054]220:数据端口[0055]230:监控端口[0056]240:内存[0057]400:原始封包[0058]401～405:封包[0059]501～504:哈希算法[0060]511～514:查找表[0061]s305～s355:步骤当前第1页12当前第1页12
再多了解一些
本文用于企业家、创业者技术爱好者查询，结果仅供参考。
