CN111918306A - 一种在ip不可达场景下实现网元通信的方法及系统 - Google Patents

Abstract

本发明公开了一种在IP不可达场景下实现网元通信的方法及系统，涉及网元管理技术领域，本发明提出的网元通信的方法与系统，不仅在IP不可达场景下实现网元通信，而且安全可靠性高，同时也为设备故障提供了一种诊断通道，步骤简单、操作方便，极大提高了工程开通维护效率，提升用户感知。本发明无需应用层网关进行桥接，应用层不需感知L4隧道，且无应用层协议限制，可以很好地支持NetConf、CLI等等南向接口协议。

Description

一种在IP不可达场景下实现网元通信的方法及系统

技术领域

本发明涉及网元管理技术领域，具体涉及一种在IP不可达场景下实现网元通信的方法及系统。

背景技术

随着5G网络的快速发展，运营商对传输网管(控制器)集中化、云化的部署的的需求越来越强烈，集中化、云化网管不断可以方便设备维护，同时也可以节省服务器资源降低运营成本，通常集中化、云化网管一般都部署在省中心机房，各地市不再部署网管服务器，这样各地市设备就不能直接接入网管，中间需要通过外部DCN连接再上省中心网管，为了传输网络的安全，参见图1所示，一般传输设备网络都不会与外部DCN互通路由，这样就导致通常只有接入DCN的网关网元(首站)站点能直接与网管或者控制器通信，非网关网元站点就不能直接与网管或者控制器通信，通常为了达到网管(控制器)与非网关网元直接通信的目的，需要采用各种隧道技术或者添加静态路由来达到目的，尤其是在工程开通初期这些配置都需要下站处理，即便有时候配置下发到位了，也可能因为其他的其他原因导致还是无法通信，如果没有其他通信手段，问题定位与诊断也是极其不方便的，这样给设备的维护带来麻烦，问题定位效率低下，同时网管集中化管理，也带来异厂家互通问题。

因此，亟需一种能够在网管与网元IP不可达场景下实现网管与目的网元的通信，并且可以对目的网元进行配置和管理的技术方案。

发明内容

针对现有技术中存在的缺陷，本发明的目的在于提供一种在IP不可达场景下实现网元通信的方法及系统，提高了设备维护的便利性，用户感知更佳。

为达到以上目的，本发明采取的技术方案是：一种在IP不可达场景下实现网元通信的方法，包括以下步骤：

网关网元通过LLDP协议获取非网关网元的管理IP、MAC及设备名称，并发送至网管；

网管向网关网元申请SSH转发隧道，网关网元收到网管发来的转发隧道的申请时，解析出目的IP及目的端口，向非网关网元发起TCP连接；

网管通过SSH转发隧道向网关网元下发配置数据，网关网元通过TCP连接转发至非网关网元，非网关网元收到配置数据后从目的端口返回处理结果。

在上述技术方案的基础上，网关网元通过LLDP协议获取非网关网元的管理IP、MAC及设备名称，并发送至网管，具体包括以下步骤：

网关网元、非网关网元启动后分别创建管理接口；

网关网元、非网关网元分别在管理接口上使能LLDP协议；

非网关网元通过LLDP协议向网关网元发送自身的管理IP、MAC及设备名称；

网关网元通过LLDP协议收到非网关网元的管理IP、MAC及设备名称；

网关网元将收到的非网关网元的管理IP及MAC地址，与之前通过LLDP收到的其他相邻网元的管理IP及MAC地址进行比较，若MAC是新增的或对应的IP不一致，则更新相邻网元管理IP及MAC对应表；并将该管理IP及MAC、设备名称推送给网管。

在上述技术方案的基础上，网管向网关网元申请SSH转发隧道，网关网元收到网管发来的转发隧道的申请时，解析出目的IP及目的端口，向非网关网元发起TCP连接，具体包括以下步骤：

网管向网关网元发起用户认证；

网管向网关网元申请SSH转发隧道，该转发隧道的目的IP为非网关网元的管理IP，目的端口为非网关网元的APP应用的端口；

网关网元收到网管发来的转发隧道的申请时，解析出目的IP及目的端口，向非网关网元发起TCP连接，该TCP连接的目的IP即为非网关网元管理IP，目的端口即为非网关网元的APP应用的端口。

在上述技术方案的基础上，网管通过SSH转发隧道向网关网元下发配置数据，网关网元通过TCP连接转发至非网关网元，非网关网元收到配置数据后从目的端口返回处理结果，具体包括以下步骤：

网管配置某一闲置的本地端口用于接收配置数据，并对该本地端口建立监听；

网管根据收到的非网关网元的设备名称，选择匹配的YANG模型配置，向该本地端口发送YANG模型配置；

网管监听到该本地端口收到YANG模型配置时，通过已经建立的SSH转发隧道将YANG模型配置发至网关网元；

网关网元收到SSH转发隧道的数据时，通过TCP连接至非网关网元管理IP的目的端口并发送至非网关网元；

非网关网元从目的端口收到YANG模型配置，进行配置处理，处理完后从目的端口返回处理结果；

网关网元的收到处理结果时，将处理结果通过SSH转发隧道发送到网管。

在上述技术方案的基础上，所述APP应用包括NetConf、OpenFlow、XMPP、OF-Config和CLI协议。

在上述技术方案的基础上，所述APP应用为NetConf时，所述目的端口为830。

本发明还提供一种在IP不可达场景下实现网元通信的系统，包括网管、网关网元和非网关网元：

网关网元，其用于：通过LLDP协议获取非网关网元的管理IP、MAC及设备名称，并发送至网管；收到网管发来的转发隧道的申请时，解析出目的IP及目的端口，向非网关网元发起TCP连接；收到网管通过SSH转发隧道发来的配置数据时，通过TCP连接转发至非网关网元；

网管，其用于：向网关网元申请SSH转发隧道；网管通过SSH转发隧道向网关网元下发配置数据；

非网关网元，其用于：向网关网元发送自身的管理IP、MAC及设备名称；收到配置数据后从目的端口返回处理结果。

在上述技术方案的基础上，所述网关网元具体用于：

启动后创建管理接口；

在管理接口上使能LLDP协议；

通过LLDP协议收到非网关网元的管理IP、MAC及设备名称；

将收到的非网关网元的管理IP及MAC地址，与之前通过LLDP收到的其他相邻网元的管理IP及MAC地址进行比较，若MAC是新增的或对应的IP不一致，则更新相邻网元管理IP及MAC对应表；并将该管理IP及MAC、设备名称推送给网管；

收到网管发来的转发隧道的申请时，解析出目的IP及目的端口，向非网关网元发起TCP连接，该TCP连接的目的IP即为非网关网元管理IP，目的端口即为非网关网元的APP应用的端口；

收到SSH转发隧道的数据时，通过TCP连接至非网关网元管理IP的目的端口并发送至非网关网元。

在上述技术方案的基础上，所述网管具体用于：

向网关网元申请SSH转发隧道；

配置某一闲置的本地端口用于接收配置数据，并对该本地端口建立监听；

根据收到的非网关网元的设备名称，选择匹配的YANG模型配置，向该本地端口发送YANG模型配置；

监听到该本地端口收到YANG模型配置时，通过已经建立的SSH转发隧道将YANG模型配置发至网关网元。

在上述技术方案的基础上，所述非网关网元具体用于：

通过LLDP协议向网关网元发送自身的管理IP、MAC及设备名称；

从自身的目的端口收到YANG模型配置时，进行配置处理，处理完后从目的端口返回处理结果。

与现有技术相比，本发明的优点在于：

本发明提出的网元通信的方法与系统，不仅在IP不可达场景下实现网元通信，而且安全可靠性高，同时也为设备故障提供了一种诊断通道，步骤简单、操作方便，极大提高了工程开通维护效率，提升用户感知。同时，本发明无需应用层网关进行桥接，应用层不需感知L4隧道，且无应用层协议限制，可以很好地支持NetConf、CLI等等南向接口协议。

附图说明

图1为背景技术的网管与网元连接场景示意图；

图2为本发明实施例的网管与网元通信示意图

图3为本发明实施例的网管获取网元B的管理IP及设备名称流程示意图；

图4为本发明实施例的SSH转发隧道及TCP连接建立流程示意图；

图5为本发明实施例的网管通过SSH转发隧道及TCP连接下发配置数据流程示意图。

具体实施方式

以下结合附图对本发明的实施例作进一步详细说明。

本发明实施例提供一种在IP不可达场景下实现网元通信的方法，包括以下步骤：

网关网元通过LLDP协议获取非网关网元的管理IP、MAC及设备名称，并发送至网管；

网管向网关网元申请SSH转发隧道，网关网元收到网管发来的转发隧道的申请时，解析出目的IP及目的端口，向非网关网元发起TCP连接；

网管通过SSH转发隧道向网关网元下发配置数据，网关网元通过TCP连接转发至非网关网元，非网关网元收到配置数据后从目的端口返回处理结果。

本发明实施例不仅在IP不可达场景下实现网元通信，而且安全可靠性高，同时也为设备故障提供了一种诊断通道，步骤简单、操作方便，极大提高了工程开通维护效率，提升用户感知。本发明无需应用层网关进行桥接，应用层不需感知L4隧道，且无应用层协议限制，可以很好地支持NetConf、OpenFlow、XMPP、OF-Config和CLI协议等南向接口协议，即TCP承载的南向接口协议都可以支持。也可以支持UDP承载的南向接口，在网元A与网元B之间换成UDP通信即可支持UDP承载的南向接口协议。

且可自动识别设备选择匹配的配置模型，可以很好地实现异厂家互通互联，比如采用本发明方案的网管服务器可以监控、配置友商的设备。

参见图2所示，本发明实施例的在IP不可达场景下实现网元通信的方法，具体包括以下步骤：

步骤A：在网元A，网元B使能LLDP协议，网元A通过LLDP协议收集到网元B的管理IP，以及设备名称及描述，网元A再通过netconf notification消息通道主动上送网元B的管理IP及设备名称到网管服务器；

步骤B：网管通过ssh client向网元A的ssh server发起认证，认证通过后网管通过ssh client向网元A的ssh server申请SSH转发隧道，该转发隧道的目的IP为网元B的管理IP，目的端口为830(此处为应用APP的使用端口，因图2中的示例应用APP为NetConf，故端口为830；如实际应用APP为其他协议或端口，则需根据相应的协议或端口进行端口设置)；

网元A的ssh server收到网管服务器发过来的转发隧道的申请后，解析出目的IP即为网元B的管理IP及目的端口即为830，然后网元A的ssh server自动向网元B发起TCP的连接，该tcp连接的目的IP即为网元B管理IP，目的端口830，至此网管服务器与网元B之间的转发隧道建立完成。

网管建立tcp server监听本地端口127.0.0.1:7001(本地端口号不限于7001，只要不冲突，其他端口号也行)，监测到127.0.0.1:7001端口数据后，自动通过ssh client建立的SSH转发隧道发生出去；至此网管服务器向本地端口127.0.0.1:7001发送NetConf的YANG模型配置，即是向网元B的830端口发送YANG模型配置，可理解为将网元B的830端口映射到本地；

步骤C：网管根据收到的网元B的设备名称后，根据设备名称选择匹配的YANG模型配置(因为不同厂家设备YANG模型有差异)，然后再通过netconf client向本地端口127.0.0.1:7001发送YANG模型配置，tcp server监听到127.0.0.1:7001的数据，自动通过ssh client已经建立的SSH转发隧道发送出去，网元A的ssh server收到隧道数据后，再自动向网元B管理IP的830端口发送出去，网元B的NetConf server从830端口收到YANG模型配置，进行相关的处理，处理完后从830端口返回处理结果，网元A的ssh server收到后，再将处理结果通过ssh隧道发送到网管的ssh client侧，网管ssh client侧收到隧道来的数据，立即返回给tcp server，tcp server再转给netconf client，至此完成网管到网元B配置的下发与回应处理。同样如果是网管其他的APP应用程序也可以利用此通道完成对网元B的通信与处理，仅仅只需要按照APP应用的端口调整一下参数即可完成，实施起来很方便、简单，在传输领域有比较好的应用前景。

参见图3所示，网管获取网元B的管理IP、MAC及设备名称流程：

步骤101：网元A、网元B启动后分别创建管理接口；

步骤102：网元A、网元B分别在管理接口上使能LLDP协议；

步骤103：网元B通过LLDP协议向外发送自身管理IP、MAC及设备名称；

步骤104：网元A通过LLDP协议收到网元B的管理IP、MAC及设备名称；

步骤105：网元A将收到的网元B管理IP及MAC地址，与之前通过LLDP收到的其他相邻网元的管理IP及MAC地址进行比较，若MAC是新增的或者对应的IP不一致，则认为是新增网元或者网元管理IP发生变化，更新相邻网元管理IP及MAC对应表；

步骤106：若在步骤105中判断为新增网元或者网管管理IP发生变化，则将该管理IP及MAC、设备名称，通过netconf server模块的netconf notification消息通道，主动推送给网管，流程结束。

步骤107：若在步骤105中判断网元IP及MAC对应关系已存在，则流程结束。

参见图4所示，SSH转发隧道及TCP连接建立流程：

步骤201：网管通过ssh client向网元A的ssh server发起用户认证；

步骤202：ssh认证是否通过，若是，进入步骤203；若否，返回步骤201；

步骤203：网管通过ssh client向网元A的ssh server申请SSH转发隧道，该转发隧道的目的IP为网元B的管理IP，目的端口为830(此处为应用APP的使用端口，因图2中应用APP为NetConf，故端口为830)；

步骤204：网元A的ssh server收到网管服务器发过来的转发隧道的申请后，解析出目的IP即为网元B的管理IP及目的端口即为830，然后网元A的ssh server自动向网元B发起TCP的连接，该tcp连接的目的IP即为网元B管理IP，目的端口830，至此网管服务器与网元B之间的转发隧道建立完成；

步骤205：网管建立tcp server监听本地端口127.0.0.1:7001(本地端口号不限于7001，只要不冲突，其他端口号也行)，监测到127.0.0.1:7001端口数据后，立即通过sshClient建立的SSH转发隧道发送出去。

至此网管服务器向本地端口127.0.0.1:7001发送NetConf的YANG模型配置，即是向网元B的830端口发送YANG模型配置，可理解为将网元B的830端口映射到本地。

参见图5所示，网管通过SSH转发隧道及TCP连接下发配置数据流程：

步骤301：网管根据收到的网元B的设备名称，选择匹配的YANG模型配置，因为不同厂家设备YANG模型有差异的；

步骤302：然后再通过netconf client向本地端口127.0.0.1:7001发送YANG模型配置；

步骤303：tcp server监听到127.0.0.1:7001的数据，自动转发至ssh client的已经建立的SSH转发隧道发送出去；

步骤304：网元A的ssh server收到隧道数据后，再自动tcp connect到网元B管理IP的830端口并发送出去；

步骤305：网元B的NetConfserver从830端口收到YANG模型配置，进行相关的处理，处理完后从830端口返回处理结果，返之亦然，网元A的ssh server收到后，再将处理结果通过ssh隧道发送到网管的ssh client侧，网管ssh client侧收到隧道来的数据，立即返回给tcp server，tcp server再转给netconf client，至此完成网管到网元B配置的下发与回应处理。同样如果是网管其他的APP应用程序也可以利用此通道完成对网元B的通信与处理，仅仅只需要按照APP应用的端口调整一下参数即可完成，实施起来很方便、简单，在传输领域有比较好的应用前景。

本发明实施例还提供一种在IP不可达场景下实现网元通信的系统，包括网管、网关网元和非网关网元：

网关网元，其用于：获取非网关网元的管理IP、MAC及设备名称，并发送至网管；收到网管发来的转发隧道的申请时，解析出目的IP及目的端口，向非网关网元发起TCP连接；收到网管通过SSH转发隧道发来的配置数据时，通过TCP连接转发至非网关网元；

网管，其用于：向网关网元申请SSH转发隧道；网管通过SSH转发隧道向网关网元下发配置数据；

非网关网元，其用于：向网关网元发送自身的管理IP、MAC及设备名称；收到配置数据后从目的端口返回处理结果。

作为优选的实施方式，所述网关网元具体用于：

启动后创建管理接口；

在管理接口上使能LLDP协议；

通过LLDP协议收到非网关网元的管理IP、MAC及设备名称；

将收到的非网关网元的管理IP及MAC地址，与之前通过LLDP收到的其他相邻网元的管理IP及MAC地址进行比较，若MAC是新增的或对应的IP不一致，则更新相邻网元管理IP及MAC对应表；并将该管理IP及MAC、设备名称推送给网管；

收到网管发来的转发隧道的申请时，解析出目的IP及目的端口，向非网关网元发起TCP连接，该TCP连接的目的IP即为非网关网元管理IP，目的端口即为非网关网元的APP应用的端口；

收到SSH转发隧道的数据时，通过TCP连接至非网关网元管理IP的目的端口并发送至非网关网元。

作为优选的实施方式，所述网管具体用于：

向网关网元申请SSH转发隧道；

配置某一闲置的本地端口用于接收配置数据，并对该本地端口建立监听；

根据收到的非网关网元的设备名称，选择匹配的YANG模型配置，向该本地端口发送YANG模型配置；

监听到该本地端口收到YANG模型配置时，通过已经建立的SSH转发隧道将YANG模型配置发至网关网元。

作为优选的实施方式，所述非网关网元具体用于。

通过LLDP协议向网关网元发送自身的管理IP、MAC及设备名称；

从自身的目的端口收到YANG模型配置时，进行配置处理，处理完后从目的端口返回处理结果。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (10)

1.一种在IP不可达场景下实现网元通信的方法，其特征在于，包括以下步骤：

网关网元通过LLDP协议获取非网关网元的管理IP、MAC及设备名称，并发送至网管；

网管向网关网元申请SSH转发隧道，网关网元收到网管发来的转发隧道的申请时，解析出目的IP及目的端口，向非网关网元发起TCP连接；

网管通过SSH转发隧道向网关网元下发配置数据，网关网元通过TCP连接转发至非网关网元，非网关网元收到配置数据后从目的端口返回处理结果。

2.如权利要求1所述的方法，其特征在于，网关网元通过LLDP协议获取非网关网元的管理IP、MAC及设备名称，并发送至网管，具体包括以下步骤：

网关网元、非网关网元启动后分别创建管理接口；

网关网元、非网关网元分别在管理接口上使能LLDP协议；

非网关网元通过LLDP协议向网关网元发送自身的管理IP、MAC及设备名称；

网关网元通过LLDP协议收到非网关网元的管理IP、MAC及设备名称；

网关网元将收到的非网关网元的管理IP及MAC地址，与之前通过LLDP收到的其他相邻网元的管理IP及MAC地址进行比较，若MAC是新增的或对应的IP不一致，则更新相邻网元管理IP及MAC对应表；并将该管理IP及MAC、设备名称推送给网管。

3.如权利要求1所述的方法，其特征在于，网管向网关网元申请SSH转发隧道，网关网元收到网管发来的转发隧道的申请时，解析出目的IP及目的端口，向非网关网元发起TCP连接，具体包括以下步骤：

网管向网关网元发起用户认证；

网管向网关网元申请SSH转发隧道，该转发隧道的目的IP为非网关网元的管理IP，目的端口为非网关网元的APP应用的端口；

网关网元收到网管发来的转发隧道的申请时，解析出目的IP及目的端口，向非网关网元发起TCP连接，该TCP连接的目的IP即为非网关网元管理IP，目的端口即为非网关网元的APP应用的端口。

4.如权利要求3所述的方法，其特征在于，网管通过SSH转发隧道向网关网元下发配置数据，网关网元通过TCP连接转发至非网关网元，非网关网元收到配置数据后从目的端口返回处理结果，具体包括以下步骤：

网管配置某一闲置的本地端口用于接收配置数据，并对该本地端口建立监听；

网管根据收到的非网关网元的设备名称，选择匹配的YANG模型配置，向该本地端口发送YANG模型配置；

网管监听到该本地端口收到YANG模型配置时，通过已经建立的SSH转发隧道将YANG模型配置发至网关网元；

网关网元收到SSH转发隧道的数据时，通过TCP连接至非网关网元管理IP的目的端口并发送至非网关网元；

非网关网元从目的端口收到YANG模型配置，进行配置处理，处理完后从目的端口返回处理结果；

网关网元的收到处理结果时，将处理结果通过SSH转发隧道发送到网管。

5.如权利要求3所述的方法，其特征在于，所述APP应用包括NetConf、OpenFlow、XMPP、OF-Config和CLI协议。

6.如权利要求5所述的方法，其特征在于，所述APP应用为NetConf时，所述目的端口为830。

7.一种在IP不可达场景下实现网元通信的系统，其特征在于，包括网管、网关网元和非网关网元：

网关网元，其用于：通过LLDP协议获取非网关网元的管理IP、MAC及设备名称，并发送至网管；收到网管发来的转发隧道的申请时，解析出目的IP及目的端口，向非网关网元发起TCP连接；收到网管通过SSH转发隧道发来的配置数据时，通过TCP连接转发至非网关网元；

网管，其用于：向网关网元申请SSH转发隧道；网管通过SSH转发隧道向网关网元下发配置数据；

非网关网元，其用于：向网关网元发送自身的管理IP、MAC及设备名称；收到配置数据后从目的端口返回处理结果。

8.如权利要求7所述的系统，其特征在于，所述网关网元具体用于：

启动后创建管理接口；

在管理接口上使能LLDP协议；

通过LLDP协议收到非网关网元的管理IP、MAC及设备名称；

将收到的非网关网元的管理IP及MAC地址，与之前通过LLDP收到的其他相邻网元的管理IP及MAC地址进行比较，若MAC是新增的或对应的IP不一致，则更新相邻网元管理IP及MAC对应表；并将该管理IP及MAC、设备名称推送给网管；

收到网管发来的转发隧道的申请时，解析出目的IP及目的端口，向非网关网元发起TCP连接，该TCP连接的目的IP即为非网关网元管理IP，目的端口即为非网关网元的APP应用的端口；

收到SSH转发隧道的数据时，通过TCP连接至非网关网元管理IP的目的端口并发送至非网关网元。

9.如权利要求7所述的系统，其特征在于，所述网管具体用于：

向网关网元申请SSH转发隧道；

配置某一闲置的本地端口用于接收配置数据，并对该本地端口建立监听；

根据收到的非网关网元的设备名称，选择匹配的YANG模型配置，向该本地端口发送YANG模型配置；

监听到该本地端口收到YANG模型配置时，通过已经建立的SSH转发隧道将YANG模型配置发至网关网元。

10.如权利要求7所述的系统，其特征在于，所述非网关网元具体用于：

通过LLDP协议向网关网元发送自身的管理IP、MAC及设备名称；

从自身的目的端口收到YANG模型配置时，进行配置处理，处理完后从目的端口返回处理结果。

Images