目前， 随着通信技术的飞速发展和广泛应用使得网络 规模日益庞大， 系统的复杂性和异构性更加突出， 网络上需要传送的数据信息量也大大增 加。 而对于路由器来说， 需要为大量报文提供寻径、 转发功能。

传统的路由方法是使用路由表， 根据目的地址进行报文的转发。 但是 用该传统的路由方法， 在路由转发过程中， 一旦路由转发表生成就不能进 行任意修改。 这样， 当网络上流量增大或路由器的相关出接口出现 故障时， 路由器的负载能力和性能会受到路由转发表的 限制， 而此时通过路由的手 段去改变流量的转发路径或部分流量的转发路 径非常困难， 也难以实现各 种流量在各个接口的均衡负载。

为了解决这个问题， 现有技术中大多釆用灵活性更强的策略路由方 式， 其允许数据信息按照指定的策略进行转发。 例如图 1 所示的网络架构中， 用户需要经过 C运营商和 A运营商访问互联网。 C运营商的路由器有 3个 接口接入 A运营商的网络。 C运营商在 C运营商的路由器上部署策略路由： 把入流量从接入 A运营商网络的 3个接口负载分担出去； 当 3个接口中有 接口异常后， 将通过该异常接口的流量分担到其他正常的接 口中； 当异常 的接口又正常后， 流量又重新进行负载分担。 但是， 此种策略路由的方式 只能在同一路由器的一组接口中进行负载分担 ， 不能在如图 2 所示的多个 路由器的多组接口中负载分担并切换， 且此种策略路由只根据下一跳接口 的物理状态的正常 /异常进行路径切换和负载分担， 其无法根据到达目的地 的整条路径是否可达进行路径切换。 发明内容 本发明实施例提供一种策略路由方法及装置， 能够选择任意接口进行 负载分担， 增强了数据传输的可靠性。 一方面， 一种策略路由方法， 包括： 将路由器的接口设置为多个重定向组， 所述重定向组之间按优先级顺 序排序； 检测所述重定向组中接口的接口状态； 根据所述重定向组中接口 的接口状态， 在多个重定向组之间进行流量的切换。 另一方面， 一种策略路由装置， 包括： 设置单元、 检测单元和切换单 元； 其中， 所述设置单元用于将路由器的接口设置为多个 重定向组， 所述重定向 组之间按优先级顺序排序； 所述检测单元用于检测所述设置单元设置的重 定向组中接口的接口状态， 并将检测结果通知给所述切换单元； 所述切换 单元用于接收所述检测单元的检测结果， 并根据所述结果中的接口状态在 多个重定向组之间进行流量切换。 可以看出， 釆用本发明实施例的方法及装置， 通过将路由器的接口设 置为多个彼此间具有优先级关系的重定向组， 利用所述重定向组中接口的 接口状态来完成流量的切换， 以此完成多级策略路由的部署， 即可实现可 选择性的优选通过其他运营商的路径， 节约运营成本； 并且通过配置多级 策略路由， 增强了数据传输的可靠性， 也使运营商的组网更灵活性。 附图说明 为了更清楚地说明本发明实施例或现有技术中 的技术方案， 下面将对 实施例或现有技术描述中所需要使用的附图作 简单地介绍， 显而易见地， 下面描述中的附图仅仅是本发明的一些实施例 ， 对于本领域普通技术人员 来讲， 在不付出创造性劳动的前提下， 还可以根据这些附图获得其他的附 图。 图 1是现有技术中釆用策略路由的网络架构示意� �； 图 2是包含多个运营商网络的网络架构示意图； 图 3是本发明实施例一策略路由方法示意图； 图 4是本发明实施例中应用策略路由方法的网络� �构示意图； 图 5是如图 4网络架构中应用策略路由的方法示意图； 图 6是如图 4网络架构中应用策略路由的另一方法示意图� � 图 7是本发明实施例二策略路由装置结构示意图� � 具体实施方式 下面将结合本发明实施例中的附图， 对本发明实施例中的技术方案进 行清楚地描述； 显然， 所描述的实施例仅仅是本发明一部分实施例， 而不 是全部的实施例。 基于本发明中的实施例， 本领域普通技术人员在没有做 出创造性劳动前提下所获得的所有其他实施例 , 都属于本发明保护的范围。 本发明实施例一提供了一种策略路由方法， 如图 3所示， 该方法包括：

310: 将路由器的接口设置为多个重定向组， 所述重定向组之间按优先 级顺序排序； 需要说明的是， 在本实施例中可以将网络中的多个路由器的所 有接口 设置为多个重定向组， 其中每个重定向组中可以包含不同路由器的接 口。 当然， 也可以将网络中的每个路由器的所有接口设置 为一个重定向组， 则 针对多个路由器即可设置多个重定向组， 其中每个重定向组只包含了一个 路由器的所有接口。 除此之外， 还可以将单一路由器的所有接口设置为多 个重定向组， 其中每个重定向组中皆包含了该路由器的部分 接口。 可选地， 所述重定向组中还可以不包括物理接口，只将 至少一个网络协议 IP( Internet Protocol )地址设置为重定向组， 具体本文不再赘述。 但是， 需要说明的是， 不论多个重定向组如何设置， 所述多个重定向组之间的优先级不同， 并且 在本实施例中所述重定向组的优先级可以根据 运营商网络状况或其他条件 进行设置和调整。 此外， 在本实施例中， 如果所述每个重定向组内配置多个接口， 则可 将所述重定向组内的多个接口配置为优先级关 系， 或是将所述重定向组内 的多个接口配置为负载分担关系。 其中， 所述负载分担关系为： 如果多个 接口中有部分接口状态异常， 将通过所述状态异常的接口的流量分担到其 他状态正常的接口中； 当状态异常的接口又正常后， 流量又重新在所有状 态正常的接口之间进行负载分担。

320: 检测每个重定向组中接口的接口状态； 需要说明的是， 本实施例中的接口状态并不仅仅是指接口的物 理开关 状态， 而是基于指定的接口和目的地址进行检测， 即检测指定的接口到目 的地之间路径的连通性； 如果从所述指定接口到目的地之间的路径为可 达， 则确定该接口为正常， 否则确定该接口为异常。

其中， 本实施例检测接口状态可通过多种方式实现， 如 NQA ( Network Quality Analyzer, 网络质量分析）检测， 或 BFD ( Bidirectional Forwarding Detection, 双向转发检测）， 或 DNS ( Domain Name System, 域名系统）检 测， 或 ICMP ( Internet Control Message Protocol, Internet控制才艮文协议 )检 测或 ping命令等。 但不论釆用何种方式检测， 本实施例中的检测内容皆包 含但不局限于： 检测对象、 检测的出接口、 检测时间。 例如， 釆用 NQA方 式进行检测， 其检测对象是美国的 DNS根服务器的 IP地址 198.41.0.4, 检 测的出接口是以太 1/0/0, 检测时间是 10秒； 其中， 每 10秒通过以太 1/0/0 发一个检测报文到美国的 DNS根服务器 198.41.0.4, 如果该路径可达， 则 在 10秒内会收到可达回应报文， 如此即可判断该接口的以太 1/0/0的状态 为正常。

此外， 本实施例中在检测到所述接口状态后存储该接 口状态， 待下次 有数据流量经过该接口时， 重新检测该接口状态， 如果该接口状态改变， 则根据新的接口状态执行策略路由， 即根据所述新的接口状态执行 330。 值得注意的是， 本实施例在检测接口状态时还可以设置该检测 过程的 属性： 如果从指定接口到目的地之间的所有路径全部 连通可达， 则确定该 接口状态为正常， 否则认定该接口状态为异常； 或者， 如果从指定接口到 目的地之间存在至少一条路径可达， 则确定该接口状态为正常， 如果所有 路径皆不可达， 则确定该接口状态异常； 当然， 本领域普通技术人员很容 易了解， 还可将所述检测过程设置为其他属性， 本发明实施例并不作具体 限定， 在此不再赘述。

330: 根据所述重定向组中接口的接口状态， 在多个重定向组之间进行 流量的切换。 其中， 当部分重定向组中的接口状态全部异常时， 按照优先级顺序查 找其他重定向组， 将经过所述异常接口的流量切换到其他存在状 态正常接 口的优先级最高的重定向组的状态正常接口； 而当所述状态为异常的接口 重新恢复正常后， 再将所述流量切换回该接口； 具体的， 当所述重定向组中的接口状态全部为异常后， 选择优先级最 高的重定向组， 查找该重定向组内所有状态正常的接口， 如果该重定向组 内所有的接口状态都是异常， 则继续选择优先级次之的重定向组， 并查找 该重定向组内所有状态正常的接口， 如果该重定向组内仍没有状态正常的 接口， 则再次选择优先级再次之的重定向组， 直至找到存在状态接口正常 的重定向组为止； 然后将所述经过状态异常接口的流量切换到该 状态正常 的接口。

值得注意的是， 如果存在状态正常接口的重定向组内的接口被 设置为 优先级关系， 则将所述流量切换到所述优先级最高的状态正 常接口； 如果 存在状态正常接口的重定向组内的接口被设置 为负载分担关系， 则将所述 流量切换到所有状态正常的接口。

除此之外， 需要说明的是， 上述步骤中只涉及了所述重定向组中的接 口全部异常的处理方式， 而对于所述重定向组中的部分接口异常的处理 方 式还可以釆用现有方式； 例如， 当所述重定向组中的部分接口异常后， 将 经过该接口的流量切换到其他正常接口； 而当所述部分异常的接口重新正 常后， 将所述流量切换回所述重新正常的接口， 具体本文不再赘述。 下面以具体的如图 4所示的网络架构为例对上述实施例的方法进� �详 细说明，用户需要访问互联网，则其需要通过 C运营商和 A运营商的网络、 或者通过 C运营商和 B运营商的网络； 而其中， C运营商基于一些因素考 虑需要把用户的流量优选从接入 A运营商的 1号和 2号接口进行负载分担， 备选从接入 B运营商的 3号和 4号接口进行负载分担； 则， 如图 5所示， 该策略路由方法包括：

S410: 将 1号和 2号接口配置为重定向组 A, 将 3号和 4号接口配置 为重定向组 B; 所述重定向组 A的优先级高于所述重定向组 B的优先级； 可选地， 配置重定向组 A内各接口的属性为负载分担； 配置重定向组 B内 各接口的属性为负载分担；

S420: 检测所述重定向组 A内的 1号和 2号接口、 以及所述重定向组 内的 3号和 4号接口的接口状态； 其中， 可利用所述 NQA方式进行检测： 配置 NQA的检测对象是美国的 DNS根服务器 198.41.0.4,检测的出接口是 1号接口，检测时间是 10秒； 每 10秒通过 1号接口发一个检测报文到美国 的 DNS根服务器 198.41.0.4, 如果所述报文可达， 则在 10秒钟内会收到可 达回应 4艮文， 由此即可确定该 1号接口为正常； 否则， 可确定该 1号接口 为异常；

S430: 当所述重定向组 A内的 1号和 2号接口全部异常后， 查找所述 重定向组 B内的 3号和 4号接口是否正常， 如果是， 则将经过所述 1号和 2号接口的流量切换到所述 3号和 4号接口； 当所述 1号和 /或 2号接口重 新正常后， 再将所述流量切换回重新正常的接口。 此外， 如图 4所示， 如果 C运营商基于一些因素考虑需要把用户的流 量优选从接入 A运营商的 1号和 2号接口进行主备保护， 备选从接入 B运 营商的 3号和 4号接口进行主备保护； 则， 如图 6所示， 该策略路由方法 包括：

S510: 将 1号和 2号接口配置为重定向组 A, 将 3号和 4号接口配置 为重定向组 B; 所述重定向组 A的优先级高于所述重定向组 B的优先级； 其中， 配置重定向组 A内各接口和重定向组 B内各接口的属性分别为主备 属性， 即所述 1号接口的优先级高于 2号接口的优先级、 所述 3号接口的 优先级高于所述 4号接口的优先级；

S520: 检测所述重定向组 A内的 1号和 2号接口、 以及所述重定向组 内的 3号和 4号接口的接口状态； 其中， 具体的检测方式与现有技术及上 述实施例中的方式类似， 不再赘述；

S530: 当所述重定向组 A内的 1号和 2号接口全部异常后， 查找所述 重定向组 B内的 3号和 4号接口是否正常， 如果是， 则将经过所述 1号和 2号接口的流量切换到所述优先级高的 3号接口； 当所述 1号和 /或 2号接 口重新正常后， 再将所述流量切换回重新正常的接口。 可以看出， 利用上述各实施例的方法， 通过将路由器的接口设置为多 个彼此间具有优先级关系的重定向组， 利用所述重定向组中接口的接口状 态来完成流量的切换， 以此完成了多级策略路由的部署， 即可实现可选择 性的优选通过其他运营商的路径， 节约运营成本； 并且通过配置多级策略 路由， 增强了业务的可靠性， 也使运营商的组网更灵活性。

对应上述方法实施例， 本发明实施例二又提出了一种策略路由装置， 如图 7所示， 该策略路由装置 500包括： 设置单元 510、 检测单元 520和切 换单元 530; 其中， 所述设置单元 510用于将路由器的接口设置为多个重定向组， 所述重 定向组之间按优先级顺序排序； 其中， 所述设置单元 510还可用于将所述 重定向组内的多个接口配置为彼此间具有优先 级关系或负载分担关系属 性；

所述检测单元 520用于检测所述设置单元 510设置的每个重定向组中 接口的接口状态， 并将检测结果通知给所述切换单元 530; 需要说明的是， 所述检测单元 520检测的接口状态至少包括指定接口到目的地 之间路径的 连通性； 所述切换单元 530用于接收所述检测单元 520的检测结果， 并根据所 述结果中的接口状态在多个重定向组之间进行 流量切换。

此外， 所述检测单元 520还可包括（图中未示出 )·· 测试模块和第一处 理模块； 其中

所述测试模块用于测试从指定接口到目的地之 间的所有路径是否连通 可达， 并将测试结果通知所述第一处理模块； 所述第一处理模块用于接收所述测试模块的测 试结果， 并当所有路径 全部连通可达时， 确定该接口状态为正常， 否则认定该接口状态为异常； 或者， 当存在至少一条路径可达时， 确定该接口状态为正常， 否则确定该 接口状态异常。 除此之外， 所述切换单元 530还可包括（图中未示出）： 查找模块， 用于当所述重定向组的接口状态全部异常时， 按照优先级 顺序查找其他重定向组， 并将查找结果通知第二处理模块； 第二处理模块， 用于接收所述查找模块的查找结果， 将经过所述状态 异常的接口的流量切换到其他存在状态正常接 口的优先级最高的重定向组 的所述状态正常接口； 当所述状态异常的接口重新正常后， 再将所述流量 切换回该接口。 本领域普通技术人员还可以进一步应能意识到 ， 结合本文中所公开的 实施例描述的各示例的单元及算法步骤， 能够以电子硬件、 计算机软件或 者二者的结合来实现， 为了清楚地说明硬件和软件的可互换性， 在上述说 明中已经按照功能一般性地描述了各示例的组 成及步骤。 这些功能究竟以 硬件还是软件方式来执行， 取决于技术方案的特定应用和设计约束条件。 专业技术人员可以对每个特定的应用来使用不 同方法来实现所描述的功 能， 但是这种实现不应认为超出本发明实施例的范 围。 结合本文中所公开的实施例描述的方法或算法 的步骤可以直接用硬 件、 处理器执行的软件模块， 或者二者的结合来实施。 对所公开的实施例的上述说明， 使本领域专业技术人员能够实现或使 用本发明实施例。 对这些实施例的多种修改对本领域的专业技术 人员来说 将是显而易见的， 本文中所定义的一般原理可以在不脱离本发明 实施例的 精神或范围的情况下， 在其它实施例中实现。 因此， 本发明实施例将不会 被限制于本文所示的这些实施例， 而是要符合与本文所公开的原理和新颖 特点相一致的最宽的范围。

实施例， 凡在本发明实施例的精神和原则之内， 所作的任何修改、 等同替 换、 改进等， 均应包含在本发明实施例的保护范围之内。