CN101009692A - 硬件地址解析方法及通信处理设备及报文处理方法 - Google Patents
硬件地址解析方法及通信处理设备及报文处理方法 Download PDFInfo
- Publication number
- CN101009692A CN101009692A CNA2006100112816A CN200610011281A CN101009692A CN 101009692 A CN101009692 A CN 101009692A CN A2006100112816 A CNA2006100112816 A CN A2006100112816A CN 200610011281 A CN200610011281 A CN 200610011281A CN 101009692 A CN101009692 A CN 101009692A
- Authority
- CN
- China
- Prior art keywords
- ply
- hardware address
- protocol processes
- yarn drill
- network interface
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
本发明公开了一种硬件地址解析方法及通信处理设备及报文处理方法，其中该硬件地址解析方法用于通讯设备的内部用户面，由交换线卡的硬件地址解析模块根据协议处理线卡的IP地址和MAC地址集中生成所有协议处理线卡的硬件地址解析表项，并将所述硬件地址解析表项同步给所有协议处理线卡。本发明采用非广播的硬件地址解析方法，禁止了广播报文进入内部用户面，在内部用户面防止了广播风暴，同时，此地址解析方法在链路层实现了协议处理线卡上多个网口之间的负荷分担算法，适合于大流量的业务；本发明的方法实现安全可靠，在通讯设备的内部用户面中使用，能够稳定而正确地完成IP地址到MAC地址的转换工作，上层应用程序使用起来也非常方便。
Description
技术领域
本发明涉及网络通讯技术领域，尤其是一种可避免广播风暴，且支持负荷分担算法的硬件地址解析方法。
背景技术
对于通用服务器或客户端，在以太网中发送IP报文时，我们通常使用地址转换协议(ARP)获取报文中目的IP对应的以太网地址(MAC)，然后将其封装成以太网帧。ARP协议是基于广播方式来实现的，当主机向外发送报文时，首先查找缓存中是否存在目的IP对应的MAC地址，如果没有，则会广播一个ARP请求报文给子网内的所有主机。主机收到此ARP报文后，如发现请求报文中的目的IP是自己，则将自己的MAC地址回送给请求方。
这种解析MAC地址的方法的缺点是子网必须充许广播报文进入，当出现广播风暴时，必然会影响到主机的业务处理，无法满足用户的请求。
对于通讯设备而言，如图1所示，通常是由接口线卡、交换线卡、协议处理线卡及连接这些线卡的背板组成。交换线卡是二层以太网的交换中心，功能相当于一个二层交换机；接口线卡主要负责接收外部用户的请求，然后转给网元内的协议处理线卡进行处理；协议处理线卡有多种，分别处理不同类型的业务报文，如语音解码、实时数据传输等等。接口线卡响应外部用户请求的部分，我们称之为外部用户面，由接口线卡转给网元内的协议处理线卡处理的部分，我们称为内部用户面。对于外部用户面，由于与其相连的外部网络均采用标准的ARP地址解析协议，因此接口线卡的外部用户面只能通过ARP协议来解析IP对应的MAC地址。而在内部用户面，如果仍然使用ARP协议，那么广播报文必然会到达内部用户面的各个协议处理线卡，在出现广播风暴时，势必会阻塞内部用户面，因此在内部用户面，需要寻求一种防止内部用户面被大量的广播报文阻塞的方法。
另外，在网元的内部用户面，如果出现大流量的用户数据都发往协议处理线卡的某一个网口时，由于单个网口的带宽有限，因此会造成用户数据的丢失。因此在大流量用户数据的情况下，提供协议处理线卡的多个网口之间的负荷分担功能是很有必要的。但是目前的ARP协议只能提供简单的IP地址到MAC地址的转换功能，不能提供链路层的负荷分担功能，而必须由应用程序来实现。而由应用程序来实现多个网口之间的负荷分担，按照ARP协议，要求处理线卡的每个接口都有单独的IP和MAC，这样应用程序在发送报文时，就要不断地变换目的IP地址，实现起来很不方便。
发明内容
本发明的目的在于提供一种硬件地址解析方法及通信处理设备及报文处理方法，在通讯设备的内部用户面避免广播风暴，同时在协议处理线卡的多个网口之间实现负载均衡，充分利用协议处理线卡的有效带宽。
为了实现上述目的，本发明提供了一种硬件地址解析方法，用于通讯设备的内部用户面，其中，由交换线卡的硬件地址解析模块根据协议处理线卡的IP地址和MAC地址集中生成所有协议处理线卡的硬件地址解析表项，并将所述硬件地址解析表项同步给所有协议处理线卡。
上述的硬件地址解析方法，其中，所述协议处理线卡数目发生变化时，所述硬件地址解析模块更新所述硬件地址解析表项，并将更新后的所述硬件地址解析表项重新同步给所有协议处理线卡。
上述的硬件地址解析方法，其中，当所述协议处理线卡具有多个内部用户面以太网口时，所述硬件地址解析表项中还包括所述协议处理线卡的逻辑网口到实际可用的物理网口的映射关系和一当前发送网口的轮询标志，所述当前发送网口的轮询标志在所述协议处理线卡的多个逻辑网口中进行轮循。
上述的硬件地址解析方法，其中，所述协议处理线卡的实际可用物理网口发生变化时，所述硬件地址解析模块更新所述硬件地址解析表项，并将更新后的所述硬件地址解析表项重新同步给所有协议处理线卡。
为了更好的实现上述目的，本发明还提供了一种通信处理设备，包括接口线卡、交换线卡、协议处理线卡及连接所述线卡的背板，其中，所述交换线卡设置有一硬件地址解析模块，用于根据协议处理线卡的IP地址和MAC地址集中生成所有协议处理线卡的硬件地址解析表项，并将所述硬件地址解析表项同步给所有协议处理线卡。
上述的通信处理设备，其中，所述协议处理线卡数目发生变化时，所述硬件地址解析模块还用于更新所述硬件地址解析表项，并将更新后的所述硬件地址解析表项重新同步给所有协议处理线卡。
上述的通信处理设备，其中，当所述协议处理线卡具有多个内部用户面以太网口时，所述硬件地址解析表项中还包括所述协议处理线卡的逻辑网口到实际可用的物理网口的映射关系和一当前发送网口的轮询标志，所述当前发送网口的轮询标志在所述协议处理线卡的多个逻辑网口中进行轮循。
上述的通信处理设备，其中，所述协议处理线卡的实际可用物理网口发生变化时，所述硬件地址解析模块还用于更新所述硬件地址解析表项，并将更新后的所述硬件地址解析表项重新同步给所有协议处理线卡。
为了更好的实现上述目的，本发明还提供了一种报文处理方法，适用于包括接口线卡、交换线卡、协议处理线的通讯处理设备内部用户面，其中，协议处理线卡收到报文时，直接通过硬件地址解析表查找目的IP对应的MAC地址，并根据MAC地址进行报文发送，所述硬件地址解析表由交换线卡的硬件地址解析模块根据协议处理线卡的IP地址和MAC地址集中生成，并同步给所有的协议处理线卡。
上述的报文处理方法，其中，当所述协议处理线卡具有多个内部用户面以太网口时，所述硬件地址解析表项中还包括所述协议处理线卡的逻辑网口到实际可用的物理网口的映射关系和一当前发送网口的轮询标志，所述当前发送网口的轮询标志在所述协议处理线卡的多个逻辑网口中进行轮循，当发送一次报文时，查询一次硬件地址解析表项，并将表项中的当前发送网口的轮询标志偏移到下一个网口。
本发明的硬件地址解析方法及通信处理设备及报文处理方法采用非广播的硬件地址解析方法，禁止了广播报文进入内部用户面，在内部用户面防止了广播风暴，同时，此地址解析方法在链路层实现了协议处理线卡上多个网口之间的负荷分担算法，适合于大流量的业务；本发明的方法实现安全可靠，在通讯设备的内部用户面中使用，能够稳定而正确地完成IP地址到MAC地址的转换工作，上层应用程序使用起来也非常方便。
附图说明
图1为通信处理设备结构示意图；
图2为本发明的硬件地址解析方法的流程示意图；
图3为本发明的硬件地址解析方法中结合负荷分担的流程示意图；
图4为本发明的协议处理线卡的多个网口之间的负荷分担示意图。
具体实施方式
本发明的硬件地址解析方法和通信处理设备主要包括以下两方面：
在内部用户面通过非广播的方式实现硬件地址解析，建立IP地址到MAC地址的解析表；
在链路层实现了协议处理线卡上多个网口之间的负荷分担算法，适合于大流量的业务。
本发明的硬件地址解析方法和通信处理设备中，交换线卡上的硬件地址解析模块根据协议处理线卡的IP地址和MAC地址，集中生成所有的硬件地址解析表项，并通过组播消息将硬件地址解析表项同步给所有协议处理线卡，协议处理线卡收到组播消息后，生成一份地址解析表项，其与交换线卡上的硬件地址解析表项一致。
同时，当用户增加/删除协议处理线卡时，硬件地址解析模块会更新硬件地址解析表项，并通过组播消息将变化的硬件地址解析表项同步给各个协议处理线卡，由协议处理线卡修改地址解析表。
同时，对于具备多个内部用户面以太网口的协议处理线卡，本发明中，由硬件地址解析模块根据协议处理线卡实际可用的网口数，按照负荷分担的原则，生成各个协议处理线卡的逻辑网口到物理网口的映射关系，实现负荷分担。
同时，当硬件地址解析模块检测到协议处理线卡可用网口数量变化时，则重新生成逻辑网口与物理网口之间的映射关系，并通知协议处理线卡。
由于硬件地址解析模块屏蔽了可用物理网口数量的差异，使上层应用程序看到的是一个逻辑网口，使用负荷分担算法更方便。
本发明的硬件地址解析方法的具体实施流程图如图2所示，具体包括如下步骤：
步骤21，交换线卡上的硬件地址解析模块进行初始化，如为硬件地址解析表项分配内存等；
步骤22，硬件地址解析模块向所有协议处理线卡请求内部用户面IP地址和MAC地址，并接收所有协议处理线卡的应答；
步骤23，硬件地址解析模块提取一个协议处理线卡的IP地址和MAC地址信息，生成相应的硬件地址解析表项，并存入交换线卡的缓存中；在本步骤中，为提高用户查找MAC的效率，硬件地址解析模块取IP地址的后10位作为Hash值将硬件地址解析表项存入交换线卡的缓冲中；
步骤24，硬件地址解析模块判断是否所有的协议处理线卡都生成了相应的硬件地址解析表项，如果是进入步骤25，否则进入步骤23继续处理下一个协议处理线卡的硬件地址解析表项；
步骤25，框中所有的协议处理线卡均加入到硬件地址解析模块的组播组中，硬件地址解析模块将生成的地址解析表项组播给各协议处理线卡，由于组播消息不可靠，本步骤中，硬件地址解析模块可定时组播本框内的所有表项给各个协议处理线卡以保证可靠性，定时器的时长可设置为1分钟；
步骤26，协议处理线卡收到组播消息后，在协议处理线卡上生成一份硬件地址解析表，保持与交换线卡上的表项一致，当协议处理线卡发送报文时，直接通过硬件地址解析表项来查找目的IP对应的MAC地址。
同时，当用户增加/删除协议处理线卡时，交换线卡上的硬件地址解析模块收到用户操作的消息后，更新硬件地址解析表项，并通过组播消息将变化的表项通知给各个协议处理线卡。
本发明的硬件地址解析方法，完成的功能与ARP地址协议是一样的，主要的区别是：ARP协议是通过请求/应答的方式动态地获取目的IP对应MAC地址，而本发明提供的方法在一定程度上是通过集中的、静态的方式来完成机框内部用户面的硬件地址解析，并通过组播将硬件地址解析表项同步给框内的各个协议处理线卡，协议处理线卡发送报文时，直接通过硬件地址解析表来查找目的IP对应的MAC地址，而不用利用广播报文方式，阻止了广播风暴的形成。同时，本发明的硬件地址解析方法也支持动态更新内部用户面的硬件地址解析表项，由于内部用户面的协议处理线卡的IP地址都是私网地址，因此这种地址解析方法是适合于通讯设备的内部用户面。
本发明的硬件地址解析方法在避免广播风暴的同时，还通过硬件地址解析表为应用提供负荷分担，如图2和图3所示，为实现一个协议处理线卡上多个网口之间负荷分担算法，本发明中，为每个协议处理线卡只配置了一个内部用户面IP地址，其中，负荷分担算法包含在前面的地址解析表项中，即为一个协议处理线卡生成硬件地址解析表项的同时，也要完成此线卡上多个网口之间的负荷分担算法，具体通过以下步骤实现负荷分担：
步骤31，交换线卡上的硬件地址解析模块进行初始化，如为硬件地址解析表项分配内存等；
步骤32，硬件地址解析模块向所有协议处理线卡请求内部用户面IP地址和MAC地址，并接收所有协议处理线卡的应答；
步骤33，硬件地址解析模块提取一个协议处理线卡的IP地址和MAC地址信息，生成第一硬件地址解析表项，并存入交换线卡的缓存中；在本步骤中，为提高用户查找MAC的效率，硬件地址解析模块取IP地址的后10位作为Hash值将硬件地址解析表项存入交换线卡的缓冲中；
步骤34，硬件地址解析模块检测该协议处理线卡的网口状态，记录实际可用的网口；
步骤35，硬件地址解析模块依据该协议处理线卡的实际可用网口信息，形成逻辑网口到物理网口的映射关系；本步骤中，对于上层应用程序来说，它看到只是一个逻辑的网口，硬件地址解析模块屏蔽了协议处理线卡上可用物理网口的数量；
步骤36，硬件地址解析模块结合第一硬件地址解析表项和负荷分担算法，生成完整的硬件地址解析表项，该负荷分担根据协议处理线卡上可用物理网口的数量形成；
步骤37，硬件地址解析模块判断是否所有的协议处理线卡都生成了相应的完整硬件地址解析表项，如果是进入步骤38，否则返回步骤33继续处理下一个协议处理线卡的硬件地址解析表项；
步骤38，框中所有的协议处理线卡均加入到硬件地址解析模块的组播组中，硬件地址解析模块将生成的地址解析表组播给各协议处理线卡，由于组播消息不可靠，本步骤中，硬件地址解析模块可定时组播本框内的所有表项给各个协议处理线卡以保证可靠性，定时器的时长可设置为1分钟；
步骤39，协议处理线卡收到组播消息后，在协议处理线卡上生成一份硬件地址解析表，保持与交换线卡上的表项一致，当协议处理线卡发送报文时，直接通过硬件地址解析表项来查找目的IP对应的MAC地址。
本发明中，当用户重新配置协议处理线卡的可用网口数目时，交换线卡上硬件地址解析模块收到用户的消息后，根据可用网口数目的变化重新生成此协议处理线卡的负荷分担算法，并通过组播将变化信息通知给各协议处理线卡。
当交换线卡上硬件地址解析模块检测到某个协议处理线卡的网口出现故障，也要重新生成此协议处理线卡上各个网口之间的负荷分担算法，并通过组播将变化信息通知给框内的各个协议处理线卡。
步骤36中的负荷分担算法与协议处理线卡上可用物理网口的关系为：如果逻辑网口对应的物理网口是正常的，则逻辑网口与物理网口之间是一一对应关系；如果逻辑网口对应的物理网口是坏的，则会根据步骤34中检测到的可用网口信息，在这些可用的物理网口中搜索一个替换的网口，下面举例进行详细的说明。
假设用户为此协议处理配置的网口数目为4个，根据协议处理线卡上可用的网口信息形成的负荷分担算法有如下几种可能：
可用网口数目为0：由于物理网口均不可用，因此逻辑网口也都不可用，逻辑网口与物理网口的映射关系(PortIndex)为255，255，255，255；
可用网口数目为1：如物理网口1是好的，其余的2、3、4均为坏的，则逻辑网口1与物理网口1对应，而逻辑网口2、3和4均被映射到好的物理网口1上，PortIndex为1，1，1，1；
可用网口数目为2：如物理网口1、2是好，3和4为坏，则逻辑网口1和2与物理网口1和2一一对应，而逻辑网口3和4分别被映射到好的物理网口1和2，PortIndex为1，2，1，2，当然逻辑网口3和4也可以分别被映射到好的物理网口2和1，PortIndex为1，2，2，1；
可用网口数目为3：如物理网口1、2、3是好，4为坏，逻辑网口4被映射到好的物理网口1或2或3，PortIndex为1，2，3，1，或1，2，3，2，或1，2，3，3；
可用网口数目为4：物理网口均可用，逻辑网口与物理网口是一一对应的关系，PortIndex为1，2，3，4。
本发明中最后形成的硬件地址解析表项以下表所示举例说明，包括索引、IP地址、协议处理线卡的网口数目、各个网口的MAC地址(MAC[0]、MAC[1]、MAC[2]、MAC[3])、当前发送网口的轮询标志(CurrentPort)、逻辑网口与物理网口的映射关系(PortIndex)。
| Index(索引) | 257 |
| IP(IP地址) | 192.168.1.1 |
| PortNum(协议处理线卡的网口数目) | 4 |
| MAC[0] | 00-12-34-F1-43-09 |
| MAC[1] | 00-12-34-F1-43-0b |
| MAC[2] | 00-12-34-F1-43-0d |
| MAC[3] | 00-12-34-F1-43-0f |
| PortIndex(逻辑网口与物理网口的映射关系) | 1，2，3，4 |
| CurrentPort(当前发送网口的轮询标志) | 0 |
每一个硬件地址解析表项都维护了一个当前发送网口的轮询标志(CurrentPort)，此标志在协议处理线卡的多个网口中进行轮循，当发送一次报文时，查询一次硬件地址解析表项，并将表项中的当前发送网口的轮询标志偏移到下一个网口。
当多个业务报文的目的地址为同一协议处理线卡时，通讯设备内部用户面的报文处理过程如图4所示：第一个业务报文到达接口线卡时，接口线卡根据业务报文的目的IP地址查询地址解析表项，返回值即为当前发送网口的硬件地址，然后根据此硬件地址将报文封装成以太网帧发送出去，经过交换线卡转发后，到达相应的协议处理线卡。第二个业务报文到达时，根据目的IP查询硬件地址时，当前发送网口标志已经偏移到目的接口线卡的下一个逻辑网口。这样，经过地址解析模块，就实现了多个网口之间的负载均衡。
本发明中协议处理线卡上各个网口之间的负荷分担算法，是ARP地址转换协议不能实现的。这种负荷分担算法的实现可以让单个处理线卡的多个以太网口采用轮询的方式发送/接收报文，对于上层应用来说，是透明的，因为上层应用只能看到协议处理线卡的逻辑网口，而报文实际发送/接收的网口是由硬件地址解析表来做映射。从这种负荷分担算法实现的层次来看，是在以太网的链路层。对于大流量的业务，此发明提供的负荷分担算法可以最大程序地利用协议处理线卡提供的有效带宽。
当然，本发明还可有其它多种实施例，在不背离本发明精神及其实质的情况下，熟悉本领域的技术人员当可根据本发明作出各种相应的改变和变形，但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。
Claims (12)
1、一种硬件地址解析方法，用于通讯设备的内部用户面，其特征在于，由交换线卡的硬件地址解析模块根据协议处理线卡的IP地址和MAC地址集中生成所有协议处理线卡的硬件地址解析表项，并将所述硬件地址解析表项同步给所有协议处理线卡。
2、根据权利要求1所述的硬件地址解析方法，其特征在于，所述协议处理线卡数目发生变化时，所述硬件地址解析模块更新所述硬件地址解析表项，并将更新后的所述硬件地址解析表项重新同步给所有协议处理线卡。
3、根据权利要求1或2所述的硬件地址解析方法，其特征在于，当所述协议处理线卡具有多个内部用户面以太网口时，所述硬件地址解析表项中还包括所述协议处理线卡的逻辑网口到实际可用的物理网口的映射关系和一当前发送网口的轮询标志，所述当前发送网口的轮询标志在所述协议处理线卡的多个逻辑网口中进行轮循。
4、根据权利要求3所述的硬件地址解析方法，其特征在于，所述协议处理线卡的实际可用物理网口发生变化时，所述硬件地址解析模块更新所述硬件地址解析表项，并将更新后的所述硬件地址解析表项重新同步给所有协议处理线卡。
5、根据权利要求1、2或4所述的硬件地址解析方法，其特征在于，所述硬件地址解析模块通过组播消息将硬件地址解析表项同步给所有协议处理线卡。
6、根据权利要求5所述的硬件地址解析方法，其特征在于，所述硬件地址解析模块定时通过组播消息将硬件地址解析表项同步给所有协议处理线卡。
7、一种通信处理设备，包括接口线卡、交换线卡、协议处理线卡及连接所述线卡的背板，其特征在于，所述交换线卡设置有一硬件地址解析模块，用于根据协议处理线卡的IP地址和MAC地址集中生成所有协议处理线卡的硬件地址解析表项，并将所述硬件地址解析表项同步给所有协议处理线卡。
8、根据权利要求7所述的通信处理设备，其特征在于，所述协议处理线卡数目发生变化时，所述硬件地址解析模块还用于更新所述硬件地址解析表项，并将更新后的所述硬件地址解析表项重新同步给所有协议处理线卡。
9、根据权利要求7或8所述的通信处理设备，其特征在于，当所述协议处理线卡具有多个内部用户面以太网口时，所述硬件地址解析表项中还包括所述协议处理线卡的逻辑网口到实际可用的物理网口的映射关系和一当前发送网口的轮询标志，所述当前发送网口的轮询标志在所述协议处理线卡的多个逻辑网口中进行轮循。
10、根据权利要求9所述的通信处理设备，其特征在于，所述协议处理线卡的实际可用物理网口发生变化时，所述硬件地址解析模块还用于更新所述硬件地址解析表项，并将更新后的所述硬件地址解析表项重新同步给所有协议处理线卡。
11、一种报文处理方法，适用于包括接口线卡、交换线卡、协议处理线的通讯处理设备内部用户面，其特征在于，协议处理线卡收到报文时，直接通过硬件地址解析表查找目的IP对应的MAC地址，并根据MAC地址进行报文发送，所述硬件地址解析表由交换线卡的硬件地址解析模块根据协议处理线卡的IP地址和MAC地址集中生成，并同步给所有的协议处理线卡。
12、根据权利要求11所述的报文处理方法，其特征在于，当所述协议处理线卡具有多个内部用户面以太网口时，所述硬件地址解析表项中还包括所述协议处理线卡的逻辑网口到实际可用的物理网口的映射关系和一当前发送网口的轮询标志，所述当前发送网口的轮询标志在所述协议处理线卡的多个逻辑网口中进行轮循，当发送一次报文时，查询一次硬件地址解析表项，并将表项中的当前发送网口的轮询标志偏移到下一个网口。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNA2006100112816A CN101009692A (zh) | 2006-01-25 | 2006-01-25 | 硬件地址解析方法及通信处理设备及报文处理方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNA2006100112816A CN101009692A (zh) | 2006-01-25 | 2006-01-25 | 硬件地址解析方法及通信处理设备及报文处理方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN101009692A true CN101009692A (zh) | 2007-08-01 |
Family
ID=38697823
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNA2006100112816A Pending CN101009692A (zh) | 2006-01-25 | 2006-01-25 | 硬件地址解析方法及通信处理设备及报文处理方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101009692A (zh) |
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101997724A (zh) * | 2010-11-22 | 2011-03-30 | 中兴通讯股份有限公司 | 一种更新组播转发条目的方法及装置 |
| CN102136977A (zh) * | 2011-02-28 | 2011-07-27 | 中兴通讯股份有限公司 | 一种拨号设备以及根据用户需求实现虚拟拨号的方法 |
| CN101442493B (zh) * | 2008-12-26 | 2011-08-10 | 华为技术有限公司 | Ip报文分发方法、集群系统和负载均衡器 |
| WO2011147220A1 (zh) * | 2010-05-28 | 2011-12-01 | 中兴通讯股份有限公司 | 一种泛在网设备标识的管理系统及方法 |
| CN103312614A (zh) * | 2013-07-02 | 2013-09-18 | 福建星网锐捷网络有限公司 | 一种组播报文处理方法、线卡及通信设备 |
| CN107566316A (zh) * | 2016-06-30 | 2018-01-09 | 中兴通讯股份有限公司 | 一种报文解析方法、装置及网络处理器 |
| CN108848202A (zh) * | 2018-06-21 | 2018-11-20 | Oppo（重庆）智能科技有限公司 | 电子装置、数据传输方法及相关产品 |
| CN110460683A (zh) * | 2019-07-05 | 2019-11-15 | 锐捷网络股份有限公司 | 一种通过网关处理数据报文的方法和交换设备 |
| CN112887229A (zh) * | 2021-01-11 | 2021-06-01 | 杭州迪普科技股份有限公司 | 一种会话信息同步方法及装置 |
-
2006
- 2006-01-25 CN CNA2006100112816A patent/CN101009692A/zh active Pending
Cited By (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101442493B (zh) * | 2008-12-26 | 2011-08-10 | 华为技术有限公司 | Ip报文分发方法、集群系统和负载均衡器 |
| WO2011147220A1 (zh) * | 2010-05-28 | 2011-12-01 | 中兴通讯股份有限公司 | 一种泛在网设备标识的管理系统及方法 |
| CN101997724A (zh) * | 2010-11-22 | 2011-03-30 | 中兴通讯股份有限公司 | 一种更新组播转发条目的方法及装置 |
| CN102136977A (zh) * | 2011-02-28 | 2011-07-27 | 中兴通讯股份有限公司 | 一种拨号设备以及根据用户需求实现虚拟拨号的方法 |
| CN102136977B (zh) * | 2011-02-28 | 2015-04-01 | 中兴通讯股份有限公司 | 一种拨号设备以及根据用户需求实现虚拟拨号的方法 |
| CN103312614A (zh) * | 2013-07-02 | 2013-09-18 | 福建星网锐捷网络有限公司 | 一种组播报文处理方法、线卡及通信设备 |
| CN103312614B (zh) * | 2013-07-02 | 2016-08-24 | 福建星网锐捷网络有限公司 | 一种组播报文处理方法、线卡及通信设备 |
| CN107566316A (zh) * | 2016-06-30 | 2018-01-09 | 中兴通讯股份有限公司 | 一种报文解析方法、装置及网络处理器 |
| CN108848202A (zh) * | 2018-06-21 | 2018-11-20 | Oppo（重庆）智能科技有限公司 | 电子装置、数据传输方法及相关产品 |
| CN108848202B (zh) * | 2018-06-21 | 2021-05-04 | Oppo（重庆）智能科技有限公司 | 电子装置、数据传输方法及相关产品 |
| CN110460683A (zh) * | 2019-07-05 | 2019-11-15 | 锐捷网络股份有限公司 | 一种通过网关处理数据报文的方法和交换设备 |
| CN112887229A (zh) * | 2021-01-11 | 2021-06-01 | 杭州迪普科技股份有限公司 | 一种会话信息同步方法及装置 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101009692A (zh) | 硬件地址解析方法及通信处理设备及报文处理方法 | |
| US8767737B2 (en) | Data center network system and packet forwarding method thereof | |
| CA2190713C (en) | Address resolution method and asynchronous transfer mode network system | |
| CN102484639B (zh) | 用于多个nat64环境的方法和主机节点 | |
| CN101022394B (zh) | 一种实现虚拟局域网聚合的方法及汇聚交换机 | |
| CN101964799B (zh) | 点到网隧道方式下地址冲突的解决方法 | |
| CN101179603B (zh) | IPv6网络中用于控制用户网络接入的方法和装置 | |
| CN100525237C (zh) | 数据转发系统、方法以及网络转发设备 | |
| CN101330466B (zh) | 一种组播报文的转发方法及装置 | |
| CN110493366A (zh) | 一种接入点加入网络管理的方法及装置 | |
| CN100414936C (zh) | 平衡网络文件系统服务器多网卡间负载的方法 | |
| CN101964719B (zh) | 基于主控板倒换的数据处理方法、线卡及主控板 | |
| CN104168338A (zh) | 一种网络地址转换装置和方法 | |
| CN105635335B (zh) | 社会资源接入方法、装置及系统 | |
| CN106464745A (zh) | Dns的服务器、客户端及数据同步方法 | |
| CN102664811B (zh) | 报文转发方法和装置 | |
| CN101873235A (zh) | 设备网络联通的检测方法、网管系统及网络系统 | |
| CN103581361A (zh) | 一种域名解析代理方法、设备及系统 | |
| US7848258B2 (en) | Dynamically transitioning static network addresses | |
| CN103327129A (zh) | 针对多wan口网关设备的域名解析方法 | |
| CN102546364A (zh) | 网络数据分流方法及其装置 | |
| US20080247379A1 (en) | Method and Network for Managing an Interface for Session-Based Synchronization | |
| CN103856435A (zh) | 一种地址解析协议缓存及其缓存方法 | |
| CN104581977B (zh) | Wlan用户管理方法、装置及系统 | |
| CN104283984B (zh) | 一种实现异类地址网络互联的方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C12 | Rejection of a patent application after its publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20070801 |