CN107819648A - 网络配置netconf连接检测方法和装置 - Google Patents

网络配置netconf连接检测方法和装置 Download PDF

Info

Publication number
CN107819648A
CN107819648A CN201711121926.6A CN201711121926A CN107819648A CN 107819648 A CN107819648 A CN 107819648A CN 201711121926 A CN201711121926 A CN 201711121926A CN 107819648 A CN107819648 A CN 107819648A
Authority
CN
China
Prior art keywords
netconf
message
connections
service end
keep
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.)
Granted
Application number
CN201711121926.6A
Other languages
English (en)
Other versions
CN107819648B (zh
Inventor
王汉
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
New H3C Technologies Co Ltd
Original Assignee
New H3C Technologies Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by New H3C Technologies Co Ltd filed Critical New H3C Technologies Co Ltd
Priority to CN201711121926.6A priority Critical patent/CN107819648B/zh
Publication of CN107819648A publication Critical patent/CN107819648A/zh
Application granted granted Critical
Publication of CN107819648B publication Critical patent/CN107819648B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0811—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking connectivity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/16—Threshold monitoring

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Computer And Data Communications (AREA)
  • Debugging And Monitoring (AREA)

Abstract

网络配置NETCONF连接检测方法和装置。本申请提供了NETCONF连接检测方法和装置。本申请中，通过NETCONF客户端检测出本客户端在指定时间内未通过NETCONF连接收到来自服务端发送的任何一个消息来触发检测本客户端与服务端之间已建立的NETCONF连接，实现了NETCONF连接的检测。

Description

网络配置NETCONF连接检测方法和装置
技术领域
本申请涉及网络通信技术，特别涉及网络配置(NETCONF)连接检测方法和装置。
背景技术
NETCONF是一种基于可扩展标记语言(XML)的配置协议。在NETCONF客户端和服务端之间建立NETCONF连接后，NETCONF客户端通过NETCONF连接向服务端下发网络配置，这实现了更为灵活和方便的网络配置。在应用中，NETCONF客户端可为控制器，服务端为交换设备。
但是，因为链路故障、服务端的网络配置错误等原因，NETCONF客户端和服务端之间的NETCONF连接并不总是正常(可用)的，为方便NETCONF客户端及时感知其与服务端之间的NETCONF连接异常(不可用)，亟待需要一种可靠的检测方式来检测NETCONF客户端与服务端之间的NETCONF连接。
发明内容
本申请提供了网络配置NETCONF连接检测方法和装置，以检测NETCONF客户端与服务端之间NETCONF连接。
本申请提供的技术方案包括：
在第一方面，本申请提供了一种NETCONF连接检测方法，该方法应用于NETCONF客户端，包括：
在本客户端与服务端协商建立NETCONF连接后，若检测出本客户端在指定时间内未收到来自所述服务端发送的任何一个消息，则，
通过所述NETCONF连接向所述服务端发送用于检测所述NETCONF连接的保活消息；
依据在发出所述保活消息之后的指定时间内是否通过所述NETCONF连接接收到来自所述服务端发送的消息确定所述NETCONF连接是否正常。
结合第一方面，在第一种可能的实现方式中，所述依据在发出保活消息之后的指定时间内是否通过所述NETCONF连接接收到来自所述服务端发送的消息确定所述NETCONF连接是否正常，包括：
若在发出所述保活消息之后的指定时间内通过所述NETCONF连接接收到所述服务端发送的消息，则确定所述NETCONF连接正常；
若在发出所述保活消息之后的指定时间内未通过所述NETCONF连接接收到所述服务端发送的任何一个消息，则确定所述NETCONF连接异常。
结合第一方面的第一种可能的实现方式，在第二种可能的实现方式中，所述确定NETCONF连接正常之后，进一步包括：检查本地预设的连接检测数是否为零，若否，将本地预设的连接检测数置为零；
所述若在发出所述保活消息之后的指定时间内未通过所述NETCONF连接接收到所述服务端发送的任何一个消息，且在确定所述NETCONF连接异常之前，进一步包括：将本地预设的连接检测数增加设定值，检查增加设定值后的所述连接检测数是否不小于预设阈值，如果否，则再次向所述服务端发送用于检测所述NETCONF连接的保活消息；如果是，则将所述连接检测数清零。
结合第一方面的第一种、第二种可能的实现方式，在第三种可能的实现方式中，所述保活消息为非NETCONF消息，在所述NETCONF连接的任一时间发送。
结合第一方面的第三种可能的实现方式，在第四种可能的实现方式中，所述保活消息携带响应回复标识，所述响应回复标识用于指示收到所述保活消息的所述服务端返回所述保活消息的响应消息。
在第二方面，本申请提供了一种NETCONF连接检测装置，该装置应用于NETCONF客户端，包括：
检测单元，用于在本客户端与服务端协商建立NETCONF连接后，检测本客户端在指定时间内是否收到来自所述服务端发送的任何一个消息；
发送单元，用于若所述检测单元检测出本客户端在指定时间内未收到来自所述服务端发送的任何一个消息，则通过所述NETCONF连接向所述服务端发送用于检测所述NETCONF连接的保活消息；
确定单元，用于依据在发出所述保活消息之后的指定时间内是否通过所述NETCONF连接接收到来自所述服务端发送的消息确定所述NETCONF连接是否正常。
结合第二方面的，在第一种可能的实现方式中，所述确定单元依据在发出保活消息之后的所述指定时间内是否通过所述NETCONF连接接收到来自所述服务端发送的消息确定所述NETCONF连接是否正常包括：
若在发出所述保活消息之后的指定时间内通过所述NETCONF连接接收到所述服务端发送的消息，则确定所述NETCONF连接正常；
若在发出所述保活消息之后的指定时间内未通过所述NETCONF连接接收到所述服务端发送的任何一个消息，则确定所述NETCONF连接异常。
结合第二方面的第一种可能的实现方式，在第二种可能的实现方式中，所述装置进一步包括：第一设置单元，用于检查本地预设的连接检测数是否为零，若否，将本地预设的连接检测数置为零；
所述装置进一步包括：第二设置单元，用于将本地预设的连接检测数增加设定值，检查增加了设定值后的所述连接检测数是否不小于预设阈值，如果否，则再次触发所述发送单元向所述服务端发送用于检测所述NETCONF连接的保活消息；如果是，则将所述连接检测数清零。
结合第二方面的第一种、第二种可能的实现方式，在第三种可能的实现方式中，所述保活消息为非NETCONF消息，在所述NETCONF连接的任一时间发送。
结合第二方面的第三种可能的实现方式，在第四种可能的实现方式中，所述保活消息携带响应回复标识，所述响应回复标识用于指示收到所述保活消息的所述服务端返回所述保活消息的响应消息。
由以上技术方案可以看出，在本申请中，NETCONF客户端检测出在指定时间内未通过NETCONF连接收到来自服务端发送的任何一个消息来触发检测本NETCONF客户端与服务端之间已建立的NETCONF连接，实现了NETCONF连接的检测；
进一步地，在本申请中，NETCONF客户端与服务端之间已建立的NETCONF连接的检测并非定期触发，而是基于NETCONF连接上的消息状态(NETCONF客户端在指定时间内未通过NETCONF连接收到来自服务端发送的任何一个消息)触发的，是不会对业务有影响的，原因为：在NETCONF连接上有很多消息比如业务消息时，因为此时NETCONF客户端会不断地通过NETCONF连接收到服务端返回的消息，不会出现诸如“NETCONF客户端在指定时间内没有通过NETCONF连接收到服务端发送的消息”的情况，因此，NETCONF客户端是不会通过NETCONF连接发送保活消息的；而当出现NETCONF客户端在指定时间内没有通过NETCONF连接收到服务端发送的消息时，说明此时NETCONF连接并不繁忙(没有或者有很少的业务消息)，这时NETCONF客户端通过NETCONF连接发送保活消息是不会对业务有什么影响。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。
图1为本申请提供的方法流程图；
图2为本申请实施例提供的步骤102实现流程图；
图3为本申请实施例提供的步骤102另一实现流程图；
图4为本申请提供的Global Request消息结构示意图；
图5为本申请提供的装置结构图；
图6为本申请提供的装置硬件结构图。
具体实施方式
在应用中，NETCONF客户端与服务端之间的NETCONF连接是基于安全外壳(英文：Secure Shell，简称：SSH)协议的NETCONF连接，简称NETCONF over SSH连接。在本申请中，作为一个实施例，NETCONF客户端可为控制器，服务端为交换设备。
为了方便NETCONF客户端及时感知其与服务端之间的NETCONF over SSH连接异常，常用的一种NETCONF连接检测方案具体为：
NETCONF客户端定期通过NETCONF over SSH连接发送任意的一个用于指定作为检测NETCONF over SSH连接的NETCONF消息(简称指定NETCONF消息)来确认是否能和NETCONFover SSH连接对端的服务端正常连通；
当NETCONF客户端在发送指定NETCONF消息之后的设定时长内通过NETCONF overSSH连接接收到服务端返回的回应时，确定NETCONF over SSH连接是正常的。此时，NETCONF客户端可将NETCONF over SSH连接正常的消息通知给上层业务管理设备，以便上层业务管理设备通过NETCONF客户端与服务端之间正常的NETCONF over SSH连接发送NETCONF配置消息给服务端来对服务端进行业务管理。
当NETCONF客户端在发送指定NETCONF消息之后的设定时长内未接收到服务端返回的回应时，则确定NETCONF over SSH连接是异常的。此时，NETCONF客户端可将NETCONFover SSH连接异常的消息通知给上层业务管理设备，并尝试重新与服务端建立NETCONFover SSH连接。
通过上面描述可以看出，NETCONF客户端定期通过NETCONF over SSH连接发送指定NETCONF消息能够检测出NETCONF over SSH连接的异常。
但是，在上面描述的NETCONF over SSH连接检测方案中，NETCONF客户端是定期通过NETCONF over SSH连接发送指定NETCONF消息来检测NETCONF over SSH连接是否异常，其并不关心NETCONF over SSH连接当前的消息状态，即使NETCONF over SSH连接当前有很多业务消息交互，已明确指示NETCONF over SSH连接正常，但是假若NETCONF客户端发现检测NETCONF over SSH连接的时间到达，其也会通过NETCONF over SSH连接发送指定NETCONF消息来检测NETCONF over SSH连接是否异常，这导致一些完全没有必要执行的NETCONF over SSH连接检测，也会导致同一时间内NETCONF over SSH连接上有很多消息(包括业务消息、指定NETCONF消息)发送，有可能延迟业务消息交互。
为了避免上述问题，本申请提供了一种可靠的且依赖于NETCONF over SSH连接本身的消息状态的检测方法，以实现检测NETCONF客户端与服务端之间的NETCONF连接(比如NETCONF over SSH连接)。
参见图1，图1为本申请提供的方法流程图。该流程应用于NETCONF客户端。
如图1所示，该流程可包括以下步骤：
步骤101，NETCONF客户端在与服务端协商建立NETCONF连接后，若检测出本NETCONF客户端在指定时间内未收到来自所述服务端发送的任何一个消息，则向所述服务端发送用于检测所述NETCONF连接的保活消息。
作为一个实施例，在本申请中，NETCONF客户端与服务端协商建立NETCONF连接的方法类似现有NETCONF连接建立方式，这里仅简单做一下描述：NETCONF客户端向服务器端发起建立NETCONF连接(比如上述的NETCONF over SSH连接)的请求，以与服务端协商建立NETCONF连接(比如上述的NETCONF over SSH连接)，具体建立过程此处省略描述。
当NETCONF连接建立成功后，则NETCONF客户端可通知上层业务管理设备，以便上层业务管理设备通过NETCONF客户端与服务端之间的NETCONF连接(比如上述的NETCONFover SSH连接)发送NETCONF配置消息给服务端来对服务端进行业务管理。当NETCONF连接建立失败的情况，不属于本申请涉及的范围，此处不再描述。
当NETCONF客户端与服务端协商建立NETCONF连接后，为便于NETCONF客户端及时感知其与服务端之间的NETCONF连接异常，则本申请中，如步骤101描述的，NETCONF客户端会在检测出本NETCONF客户端在指定时间内未收到来自所述服务端发送的任何一个消息，则向所述服务端发送用于检测所述NETCONF连接的保活消息。以NETCONF连接为NETCONFover SSH连接为例，这里所述的来自所述服务端发送的任何一个消息是指来自所述服务端发送的任一SSH消息。这里的任一SSH消息其可为NETCONF消息，也可为非NETCONF消息。
步骤102，NETCONF客户端依据在发出保活消息之后的指定时间内是否通过所述NETCONF连接收到来自所述服务端发送的消息确定所述NETCONF连接是否正常。
作为一个实施例，这里的指定时间可根据实际情况设置，比如设置为10秒(S)。
作为一个实施例，本步骤102确定NETCONF连接是否正常可包括图2或图3所示的流程。这里暂不赘述。
至此，完成图1所示流程。
通过图1所示流程可以看出，在本申请中，NETCONF客户端检测出在指定时间内未通过NETCONF连接收到来自服务端发送的任何一个消息来触发检测本NETCONF客户端与服务端之间已建立的NETCONF连接，实现了NETCONF连接的检测；
进一步地，在本申请中，NETCONF客户端与服务端之间已建立的NETCONF连接的检测并非定期触发，而是基于NETCONF连接上的消息状态(NETCONF客户端在指定时间内未通过NETCONF连接收到来自服务端发送的任何一个消息)触发的，是不会对业务有影响的，原因为：在NETCONF连接上有很多消息比如业务消息时，因为此时NETCONF客户端会不断地通过NETCONF连接收到服务端返回的消息，不会出现诸如“NETCONF客户端在指定时间内没有通过NETCONF连接收到服务端发送的消息”的情况，因此，NETCONF客户端是不会通过NETCONF连接发送保活消息的；而当出现NETCONF客户端在指定时间内没有通过NETCONF连接收到服务端发送的消息时，说明此时NETCONF连接并不繁忙(没有或者有很少的业务消息)，这时NETCONF客户端通过NETCONF连接发送保活消息是不会对业务有什么影响，不会出现上面描述的定期检测NETCONF over SSH连接所出现的各种问题。
参见图2，图2为本申请提供的步骤102实现流程图。如图2所示，该流程可包括以下步骤：
步骤201，NETCONF客户端在发出所述保活消息之后的指定时间内若通过NETCONF连接接收到服务端发送的消息，则执行步骤202，NETCONF客户端在发出所述保活消息之后的指定时间内若未通过NETCONF连接接收到服务端发送的任何一个消息，则执行步骤203。
步骤202，确定所述NETCONF连接正常。
本步骤202是NETCONF客户端在发出所述保活消息之后的指定时间内通过NETCONF连接接收到服务端发送的任何一个消息的前提下执行的。当NETCONF客户端在发出所述保活消息之后的指定时间内通过NETCONF连接接收到服务端发送的任何一个消息，则意味着此时NETCONF客户端与服务端之间已建立的NETCONF连接是正常(可用)的。以NETCONF连接为NETCONF over SSH连接为例，这里所述的来自所述服务端发送的任何一个消息是指来自所述服务端发送的保活消息的响应信息(属于SSH消息)或者其他任一SSH消息(比如NETCONF消息、非NETCONF消息等)。
步骤203，确定所述NETCONF连接异常。
本步骤203是NETCONF客户端在发出所述保活消息之后的指定时间内未通过NETCONF连接接收到服务端发送的任何一个消息的前提下执行的。当NETCONF客户端在发出所述保活消息之后的指定时间内未通过NETCONF连接接收到服务端发送的任何一个消息，则意味着此时NETCONF客户端与服务端之间已建立的NETCONF连接也意味着是异常(不可用)的。
至此，完成图2所示流程。
通过图2所示流程最终实现了NETCONF连接的检测。
参见图3，图3为本申请提供的步骤102另一实现流程图。如图3所示，该流程可包括以下步骤：
步骤301，NETCONF客户端在发出所述保活消息之后的指定时间内若通过NETCONF连接接收到服务端发送的消息，则执行步骤302，NETCONF客户端在发出所述保活消息之后的指定时间内若未通过NETCONF连接接收到服务端发送的任何一个消息，则执行步骤303。
步骤302，确定NETCONF连接正常，并检查本地预设的连接检测数是否为零，若否，将本地预设的连接检测数置为零。
在本步骤302中，若检查出本地预设的连接检测数为零，则不针对连接检测数执行任何处理，即，维持本地预设的连接检测数为零。
这里，连接检测数其可预先设置在NETCONF客户端本地，具体实现时可为计数器，用于记录连续检测NETCONF连接的次数。在本申请中，之所以在NETCONF客户端本地设置连接检测数，其目的是实现在连接检测数指示的连续检测NETCONF连接的次数不小于预设阈值时才确定NETCONF连接，并非如图2所示流程仅基于一次NETCONF连接检测就可确定NETCONF连接异常，提高NETCONF连接检测的可靠性。
步骤303，将本地预设的连接检测数增加设定值，检查增加了设定值后的所述连接检测数是否大于或等于预设阈值，如果否，则再次向所述服务端发送用于检测所述NETCONF连接的保活消息；如果是，则将本地预设的连接检测数清零，并确定所述NETCONF连接异常。
作为一个实施例，这里的设定值可为1。
在一个例子中，步骤303中的预设阈值可根据NETCONF客户端本身性能和实际需求自定义设置，比如设置为3。
至此，完成图3所示流程的描述。
通过图3所示流程最终实现了NETCONF连接的检测。
进一步地，相比于图2所示流程，图3所示流程在发出所述保活消息之后的指定时间内检查出未通过NETCONF连接接收到服务端发送的任何一个消息时，并不立即确定NETCONF连接异常，而是依赖于本地预设的用于记录连续检测NETCONF连接次数的连接检测数确定NETCONF连接异常，在连接检测数指示的连续检测NETCONF连接的次数不小于预设阈值时确定NETCONF连接，这相比于图2所示的流程，NETCONF连接检测的可靠性高，检测出的NETCONF连接是否正常的结果也更准确。
在本申请中，作为一个实施例，NETCONF客户端向服务端发送的用于检测NETCONF连接的保活消息，是要求服务端回复响应消息的。在一个例子中，NETCONF客户端向服务端发送的用于检测NETCONF连接的保活消息可携带响应回复标识，所述响应回复标识用于指示收到所述保活消息的服务端返回所述保活消息的响应消息。这里的响应消息不限响应消息的内容是成功响应消息(比如SSH-MSG-REQUEST-SUCCESS)还是失败响应消息(比如SSH-MSG-REQUEST-FAILURE)。
在本申请中，保活消息、保活消息的响应消息为非NETCONF消息，不要求在所述NETCONF连接上串行发送，可在任意时间发送。
基于上面对保活消息的描述，则作为一个实施例，本申请中的保活消息可优选为RFC 4254定义的全局请求(Global Request)消息。Global Request消息不为NETCONF消息，不要求在NETCONF连接上串行发送。图4示出了Global Request消息的格式。
作为一个实施例，在本申请中，当保活消息为RFC 4254定义的Global Request消息时，上述的响应回复标识可为Global Request消息新增加的一个字段携带的标识。
作为另一个实施例，在本申请中，当保活消息为RFC 4254定义的Global Request消息时，上述的响应回复标识也可为承载于所述Global Request消息的需要回复(wantreply)字段的一个标识。如图4所示，Global Request消息中有一个want reply字段，当want reply字段为响应回复标识比如True时意味着收到Global Request消息的设备必须回应成功响应消息(比如SSH-MSG-REQUEST-SUCCESS)或者失败响应消息(比如SSH-MSG-REQUEST-FAILURE)。其中，当收到Global Request消息的设备不支持Global Request消息的消息类型时，可直接回应失败响应消息(比如SSH-MSG-REQUEST-FAILURE)。
下面以保活消息为Global Request消息、NETCONF连接为NETCONF over SSH连接为例对本申请提供的方法进行描述：
当NETCONF客户端与服务端协商成功建立NETCONF over SSH连接后，NETCONF客户端会启动对NETCONF over SSH连接的如下检测：
NETCONF客户端在指定时间(比如10s)没有通过NETCONF over SSH连接接收到服务端发来的任何一个消息，则主动通过本NETCONF客户端与服务端之间已建立的NETCONFover SSH连接发送一个Global Request消息，以试探一下本NETCONF客户端与服务端之间已建立的NETCONF over SSH连接是否正常。如上针对Global Request消息的描述，服务端收到Global Request消息后会回应响应消息，但是也有可能出现以下情况：服务端当前比较繁忙正处理业务消息，服务端向NETCONF客户端发送业务消息先于回应响应消息。
但是，不管NETCONF客户端在发送Global Request消息之后的指定时间(比如10s)内是通过本NETCONF客户端与服务端之间已建立的NETCONF over SSH连接收到GlobalRequest消息的响应消息，还是其他SSH消息，只要NETCONF客户端通过本NETCONF客户端与服务端之间已建立的NETCONF over SSH连接收到，则意味着本NETCONF客户端与服务端之间已建立的NETCONF over SSH连接是正常可用的。
反之，NETCONF客户端在发送Global Request消息之后的指定时间(比如10s)内未通过本NETCONF客户端与服务端之间已建立的NETCONF over SSH连接收到任何一个消息，则结合图3所示流程，NETCONF客户端会将本地预设的连接检测数增加1，检查增加了1后的连接检测数是否大于或等于预设阈值，如果否，再次通过本NETCONF客户端与服务端之间已建立的NETCONF over SSH连接发送一个Global Request消息，如果是，则确定NETCONF连接异常。
需要说明的是，在本申请中，一旦NETCONF客户端检测出本NETCONF客户端与服务端之间建立的NETCONF连接比如NETCONF over SSH连接异常，则NETCONF客户端会关闭承载于该异常NETCONF连接的所有会话比如SSH会话，将关闭会话的消息通知上层业务管理设备，并开始尝试重新与服务端协商建立NETCONF连接，当重新建立NETCONF连接后，返回图1所示流程。
以上对本申请提供的实施例进行了描述。
下面对本申请提供的装置进行描述：
参见图5，图5为本申请提供的装置结构图。该装置应用于NETCONF客户端，如图5所示，该装置包括：
检测单元501，用于在本客户端与服务端协商建立NETCONF连接后，检测本客户端在指定时间内是否收到来自所述服务端发送的任何一个消息；
发送单元502，用于若检测单元501检测出本客户端在指定时间内未收到来自所述服务端发送的任何一个消息，则通过所述NETCONF连接向所述服务端发送用于检测所述NETCONF连接的保活消息；
确定单元503，用于依据在发出所述保活消息之后的指定时间内是否通过所述NETCONF连接接收到来自所述服务端发送的消息确定所述NETCONF连接是否正常。
作为一个实施例，所述确定单元503依据在发出保活消息之后的所述指定时间内是否通过所述NETCONF连接收到来自所述服务端发送的消息确定所述NETCONF连接是否正常包括：
若在发出所述保活消息之后的指定时间内通过所述NETCONF连接接收到所述服务端发送的消息，则确定所述NETCONF连接正常；
若在发出所述保活消息之后的指定时间内未通过所述NETCONF连接接收到所述服务端发送的任何一个消息，则确定所述NETCONF连接异常。
作为一个实施例，所述装置进一步包括：
第一设置单元504，用于检查本地预设的连接检测数是否为零，若否，将本地预设的连接检测数置为零；
第二设置单元505，用于将本地预设的连接检测数增加设定值，检查增加了设定值后的所述连接检测数是否不小于预设阈值，如果否，则再次触发发送单元502向所述服务端发送用于检测所述NETCONF连接的保活消息；如果是，则将所述连接检测数清零。
作为一个实施例，所述保活消息为非NETCONF消息，在所述NETCONF连接的任一时间发送。
作为一个实施例，所述保活消息携带响应回复标识，所述响应回复标识用于指示收到所述保活消息的所述服务端返回所述保活消息的响应消息。
至此，完成图5所示装置的描述。
对应地，本申请还提供了图5所示装置的硬件结构图。如图6所示，该硬件结构包括：
可包括处理器601、存储有机器可执行指令的机器可读存储介质602。处理器601与机器可读存储介质602可经由系统总线603通信。并且，通过读取并执行机器可读存储介质602中与NETCONF会话状态检测逻辑对应的机器可执行指令，处理器601可执行上文描述的NETCONF连接检测方法。
本文中提到的机器可读存储介质602可以是任何电子、磁性、光学或其它物理存储装置，可以包含或存储信息，如可执行指令、数据，等等。例如，机器可读存储介质可以是：随机存取存储器(英文：Radom Access Memory，简称：RAM)、易失存储器、非易失性存储器、闪存、存储驱动器(如硬盘驱动器)、固态硬盘、任何类型的存储盘(如光盘、dvd等)，或者类似的存储介质，或者它们的组合。
至此，完成图6所示的硬件结构描述。
在本申请中，还提供了一种包括机器可执行指令的机器可读存储介质，例如图6中的机器可读存储介质602，所述机器可执行指令可由NETCONF连接检测装置中的处理器601执行以实现以上描述的NETCONF连接检测方法。
具体地，通过调用并执行机器可读存储介质中与NETCONF连接检测逻辑对应的机器可执行指令，处理器601可执行以上NETCONF连接检测方法中的操作。
以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (10)

1.一种NETCONF连接检测方法，其特征在于，该方法应用于NETCONF客户端，包括：
在本客户端与服务端协商建立NETCONF连接后，若检测出本客户端在指定时间内未收到来自所述服务端发送的任何一个消息，则，
通过所述NETCONF连接向所述服务端发送用于检测所述NETCONF连接的保活消息；
依据在发出所述保活消息之后的指定时间内是否通过所述NETCONF连接接收到来自所述服务端发送的消息确定所述NETCONF连接是否正常。
2.根据权利要求1所述的方法，其特征在于，所述依据在发出保活消息之后的指定时间内是否通过所述NETCONF连接接收到来自所述服务端发送的消息确定所述NETCONF连接是否正常，包括：
若在发出所述保活消息之后的指定时间内通过所述NETCONF连接接收到所述服务端发送的消息，则确定所述NETCONF连接正常；
若在发出所述保活消息之后的指定时间内未通过所述NETCONF连接接收到所述服务端发送的任何一个消息，则确定所述NETCONF连接异常。
3.根据权利要求2所述的方法，其特征在于，所述确定NETCONF连接正常之后，进一步包括：检查本地预设的连接检测数是否为零，若否，将本地预设的连接检测数置为零；
所述若在发出所述保活消息之后的指定时间内未通过所述NETCONF连接接收到所述服务端发送的任何一个消息，且在确定所述NETCONF连接异常之前，进一步包括：将本地预设的连接检测数增加设定值，检查增加设定值后的所述连接检测数是否不小于预设阈值，如果否，则再次向所述服务端发送用于检测所述NETCONF连接的保活消息；如果是，则将所述连接检测数清零。
4.根据权利要求1至3任一所述的方法，其特征在于，所述保活消息为非NETCONF消息，在所述NETCONF连接的任一时间发送。
5.根据权利要求4所述的方法，其特征在于，所述保活消息携带响应回复标识，所述响应回复标识用于指示收到所述保活消息的所述服务端返回所述保活消息的响应消息。
6.一种NETCONF连接检测装置，其特征在于，该装置应用于NETCONF客户端，包括：
检测单元，用于在本客户端与服务端协商建立NETCONF连接后，检测本客户端在指定时间内是否收到来自所述服务端发送的任何一个消息；
发送单元，用于若所述检测单元检测出本客户端在指定时间内未收到来自所述服务端发送的任何一个消息，则通过所述NETCONF连接向所述服务端发送用于检测所述NETCONF连接的保活消息；
确定单元，用于依据在发出所述保活消息之后的指定时间内是否通过所述NETCONF连接接收到来自所述服务端发送的消息确定所述NETCONF连接是否正常。
7.根据权利要求6所述的装置，其特征在于，所述确定单元依据在发出保活消息之后的所述指定时间内是否通过所述NETCONF连接接收到来自所述服务端发送的消息确定所述NETCONF连接是否正常包括：
若在发出所述保活消息之后的指定时间内通过所述NETCONF连接接收到所述服务端发送的消息，则确定所述NETCONF连接正常；
若在发出所述保活消息之后的指定时间内未通过所述NETCONF连接接收到所述服务端发送的任何一个消息，则确定所述NETCONF连接异常。
8.根据权利要求7所述的装置，其特征在于，所述装置进一步包括：第一设置单元，用于检查本地预设的连接检测数是否为零，若否，将本地预设的连接检测数置为零；
所述装置进一步包括：第二设置单元，用于将本地预设的连接检测数增加设定值，检查增加了设定值后的所述连接检测数是否不小于预设阈值，如果否，则再次触发所述发送单元向所述服务端发送用于检测所述NETCONF连接的保活消息；如果是，则将所述连接检测数清零。
9.根据权利要求6至8任一所述的装置，其特征在于，所述保活消息为非NETCONF消息，在所述NETCONF连接的任一时间发送。
10.根据权利要求9所述的装置，其特征在于，所述保活消息携带响应回复标识，所述响应回复标识用于指示收到所述保活消息的所述服务端返回所述保活消息的响应消息。
CN201711121926.6A 2017-11-14 2017-11-14 网络配置netconf连接检测方法和装置 Active CN107819648B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201711121926.6A CN107819648B (zh) 2017-11-14 2017-11-14 网络配置netconf连接检测方法和装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201711121926.6A CN107819648B (zh) 2017-11-14 2017-11-14 网络配置netconf连接检测方法和装置

Publications (2)

Publication Number Publication Date
CN107819648A true CN107819648A (zh) 2018-03-20
CN107819648B CN107819648B (zh) 2020-08-04

Family

ID=61609295

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201711121926.6A Active CN107819648B (zh) 2017-11-14 2017-11-14 网络配置netconf连接检测方法和装置

Country Status (1)

Country Link
CN (1) CN107819648B (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112671711A (zh) * 2020-11-26 2021-04-16 新华三技术有限公司 一种网络设备的管理方法及装置

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1568046A (zh) * 2003-07-03 2005-01-19 中国移动通信集团公司 一种移动网络中业务链路的检测维护方法
CN1874272A (zh) * 2005-06-03 2006-12-06 华为技术有限公司 识别网络故障节点的方法
CN102624584A (zh) * 2012-03-01 2012-08-01 中兴通讯股份有限公司 链路检测方法及装置
CN103716323A (zh) * 2013-12-31 2014-04-09 厦门悦讯信息科技有限公司 一种发送心跳包维持长连接的方法
CN104703295A (zh) * 2015-03-30 2015-06-10 小米科技有限责任公司 网络接入方法及装置
KR101655966B1 (ko) * 2015-09-11 2016-09-08 동아대학교 산학협력단 Ｎｅｔｃｏｎｆ 프로토콜의 ｒｐｃ 계층 개선을 위한 장치 및 방법
CN106301993A (zh) * 2015-06-12 2017-01-04 中兴通讯股份有限公司 一种测试路由器的方法和装置
CN106411627A (zh) * 2015-07-31 2017-02-15 博雅网络游戏开发（深圳）有限公司 网络连接检测方法和装置
CN106856609A (zh) * 2017-02-28 2017-06-16 苏州福瑞思信息科技有限公司 一种网络配置方法及装置
CN106912064A (zh) * 2015-12-23 2017-06-30 北京奇虎科技有限公司 无线网络的网络配置检测修复方法及装置

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1568046A (zh) * 2003-07-03 2005-01-19 中国移动通信集团公司 一种移动网络中业务链路的检测维护方法
CN1874272A (zh) * 2005-06-03 2006-12-06 华为技术有限公司 识别网络故障节点的方法
CN102624584A (zh) * 2012-03-01 2012-08-01 中兴通讯股份有限公司 链路检测方法及装置
CN103716323A (zh) * 2013-12-31 2014-04-09 厦门悦讯信息科技有限公司 一种发送心跳包维持长连接的方法
CN104703295A (zh) * 2015-03-30 2015-06-10 小米科技有限责任公司 网络接入方法及装置
CN106301993A (zh) * 2015-06-12 2017-01-04 中兴通讯股份有限公司 一种测试路由器的方法和装置
CN106411627A (zh) * 2015-07-31 2017-02-15 博雅网络游戏开发（深圳）有限公司 网络连接检测方法和装置
KR101655966B1 (ko) * 2015-09-11 2016-09-08 동아대학교 산학협력단 Ｎｅｔｃｏｎｆ 프로토콜의 ｒｐｃ 계층 개선을 위한 장치 및 방법
CN106912064A (zh) * 2015-12-23 2017-06-30 北京奇虎科技有限公司 无线网络的网络配置检测修复方法及装置
CN106856609A (zh) * 2017-02-28 2017-06-16 苏州福瑞思信息科技有限公司 一种网络配置方法及装置

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112671711A (zh) * 2020-11-26 2021-04-16 新华三技术有限公司 一种网络设备的管理方法及装置

Also Published As

Publication number Publication date
CN107819648B (zh) 2020-08-04

Similar Documents

Publication Publication Date Title
US10419273B2 (en) Stand-by controller assisted failover
CN107332726B (zh) 一种通信链路的检测方法及装置
US20070041327A1 (en) Multicast heartbeat signaling
US7983175B2 (en) System and method for detecting a network failure
EP1926259A1 (en) Control of communication ports of computing devices using policy-based decisions
WO2009052765A1 (fr) Procédé et dispositif de détection et de traitement de défaillance de nœud dans un réseau poste à poste
CN104429037A (zh) 用于连接到通信设备的方法、设备及系统
CN102143018B (zh) 消息循环的检测方法、路由代理设备及组网系统
US20060221815A1 (en) Failure-monitoring program and load-balancing device
CN108199914A (zh) 服务端状态检测方法和装置
CN107171885A (zh) 一种检测服务器运行状态的方法、装置和系统
CN103580894A (zh) 操作、管理和维护oam配置的方法、设备及系统
CN108134713A (zh) 一种通信方法及装置
US20070130346A1 (en) Method for maintaining telnet session, telnet agency and computer network system
US9509777B2 (en) Connection method and management server
CN111726328B (zh) 用于对第一设备进行远程访问的方法、系统以及相关设备
CN108449276A (zh) 路由收敛方法及装置
CN107819648A (zh) 网络配置netconf连接检测方法和装置
JP2007110302A (ja) 緊急通報システム、およびそのプログラム
CN110018677A (zh) 一种物联网设备管理系统及方法
CN102868616B (zh) 网络中虚mac地址表项建立的方法、路由器及系统
CN113824595B (zh) 链路切换控制方法、装置和网关设备
CN102761430B (zh) 一种获取告警信息的方法及系统
CN106878113B (zh) 一种链路连通性检测方法及装置
CN107342887B (zh) 一种网络设备的管理方法和云端服务器

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant