CN117675673A

CN117675673A - Network path determination method, device, equipment and computer readable storage medium

Info

Publication number: CN117675673A
Application number: CN202311718131.9A
Authority: CN
Inventors: 程宇; 祁肖贺; 黄山; 高国青; 陈一帆
Original assignee: China Mobile Communications Group Co Ltd; China Mobile Information Technology Co Ltd
Current assignee: China Mobile Communications Group Co Ltd; China Mobile Information Technology Co Ltd
Priority date: 2023-12-13
Filing date: 2023-12-13
Publication date: 2024-03-08

Abstract

The invention discloses a network path determining method, device and equipment and a computer readable storage medium, and belongs to the technical field of cloud computing. The method comprises the following steps: when the target address corresponding to the next hop cannot be identified, a boundary design table and/or a virtual routing table are obtained; when the target address exists in the boundary design table, determining a target cloud based on the boundary design table, and initiating path continuous checking in the target cloud; or when the target address exists in the virtual routing table, initiating path continuous checking based on path information associated with the target address recorded in the virtual routing table; and generating a network path according to the path continuous checking result. The invention aims to realize the effective calculation of the network path through the boundary design table and/or the virtual routing table.

Description

Network path determination method, device, equipment and computer readable storage medium

Technical Field

The present invention relates to the field of cloud computing technologies, and in particular, to a network path determining method, apparatus, device, and computer readable storage medium.

Background

The cloud network is composed of data center resource pools distributed in different regions, the service system is deployed inside each data center resource pool, and network access of the service system across the resource pools is realized by accessing an intercommunication network, such as a backbone network, a private line, a private network and the like, at the boundary between each resource pool.

When a problem occurs in the cross-cloud service, an access path of the related network flow needs to be analyzed to be consistent with expectations or not so as to find out faults. In the related art, a network path can be traversed hop by hop based on a Time To Live (TTL), a gateway device where a source address is located is logged in, a TTL message is sent hop by hop through commands such as route tracking, a response address when each hop returns a TTL timeout message is traversed, and the address is spliced into a network access path after completion.

However, for network path dead spots, i.e., unidentified unknown nodes traversed from source address to destination address, the way the network path is traversed hop-by-hop based on the time-to-live value may fail. This is because the time-to-live value needs to be calculated according to messages such as internet control message protocol (Internet Control Message Protocol, ICMP), transmission control protocol (Transmission Control Protocol, TCP), user datagram protocol (User Datagram Protocol, UDP), etc., but blind spots in the path may reject the messages based on network security policies of the actual production environment, so that the TTL value cannot be calculated, and thus the network path cannot be accurately determined.

Disclosure of Invention

The invention mainly aims to provide a network path determining method, a device, equipment and a computer readable storage medium, which aim to solve the technical problem that a network path computing mode is invalid when a network path blind spot is encountered.

To achieve the above object, the present invention provides a network path determining method, including the steps of:

when the target address corresponding to the next hop cannot be identified, a boundary design table and/or a virtual routing table are obtained;

when the target address exists in the boundary design table, determining a target cloud based on the boundary design table, and initiating path continuous checking in the target cloud; or alternatively

When the target address exists in the virtual routing table, initiating path continuous checking based on path information associated with the target address recorded in the virtual routing table;

and generating a network path according to the path continuous checking result.

Optionally, the boundary design table includes an access address and a cloud network identifier, and when the target address exists in the boundary design table, determining a target cloud based on the boundary design table, and initiating a path review in the target cloud includes:

If the entrance address in the boundary design table is matched with the target address, determining a target cloud according to the cloud network identification in the boundary design table, and initiating path continuous checking in the target cloud;

the step of determining a target cloud based on the boundary design table when the target address exists in the boundary design table and after the step of initiating the path review in the target cloud comprises the steps of:

and if the access address in the boundary design table is not matched with the target address, judging whether the target address exists in the virtual routing table.

Optionally, the virtual routing table includes a plurality of routing entries, where each routing entry includes an entry address, a next-hop address, and path information, and when the target address exists in the virtual routing table, the step of initiating a path continuation check based on the path information associated with the target address recorded in the virtual routing table includes:

screening out target route entries, of which the current address is matched with the entrance address and the target address is matched with the next-hop address, from all the route entries;

And initiating a path follow-up check according to the path information of the target routing entry.

Optionally, the step of initiating a path review according to the path information of the target routing entry includes:

if the number of the target route entries is multiple, traversing from the first target route entry;

if the current state of the target route item is idle, initiating a path follow-up check according to the path information of the current target route item;

and if the current state of the target route entry is busy, querying the state again after a preset period of time, and jumping to execute the step of initiating path follow-up according to the path information of the current target route entry if the current state of the target route entry is idle.

Optionally, after the step of initiating a path continuation check based on the path information associated with the target address recorded in the virtual routing table when the target address exists in the virtual routing table, the method includes:

and when the target address does not exist in the boundary design table and the virtual routing table, judging that the path is interrupted and the path searching fails.

Optionally, before the step of obtaining the boundary design table and/or the virtual routing table when the destination address corresponding to the next hop cannot be identified, the method includes:

Determining the gateway address of each cloud network according to the network segment characteristics of the address of each cloud network;

determining cloud network identifications of the cloud networks according to the attribution resource pools of the cloud networks;

and summarizing the gateway address and the cloud network identifier to generate the boundary design table.

Optionally, after the step of summarizing the gateway address and the cloud network identifier to generate the boundary design table, the method includes:

removing the boundary design table from the address set which cannot be identified by the current cloud network to obtain an internal blind point address set of the current cloud network;

acquiring a port address information table, an address resolution protocol information table and a routing information table of addresses corresponding to the internal blind spot address set;

traversing the next hop addresses of all route entries in the route information table, and determining the route entry corresponding to the next hop address as a route entry to be processed if the next hop address does not exist in the port address information table;

determining an output port and an input port of the routing entry to be processed according to the target subnet of the routing entry to be processed and in combination with a probe machine and an address of the target subnet in the address resolution protocol information table;

And generating the virtual routing table according to the next hop address of the routing entry to be processed, the target subnet, the output port and the input port.

In addition, to achieve the above object, the present invention also provides a network path determining apparatus, including:

the acquisition module is used for acquiring a boundary design table and/or a virtual routing table when the target address corresponding to the next hop cannot be identified;

the first path continuous checking module is used for determining a target cloud based on the boundary design table when the target address exists in the boundary design table, and initiating path continuous checking in the target cloud; or alternatively

The second path continuous checking module is used for initiating path continuous checking based on path information associated with the target address recorded in the virtual routing table when the target address exists in the virtual routing table;

and the generating module is used for generating a network path according to the path continuous checking result.

In addition, in order to achieve the above object, the present invention also provides a network path determining apparatus including: the network path determination device comprises a memory, a processor and a network path determination program stored on the memory and capable of running on the processor, wherein the network path determination program is configured to realize the steps of the network path determination method.

In addition, in order to achieve the above object, the present invention also provides a computer-readable storage medium having stored thereon a network path determination program which, when executed by a processor, implements the steps of the network path determination method.

In the technical scheme provided by the application, when the target address corresponding to the next hop cannot be identified, the route is automatically found through the boundary design table and/or the virtual routing table, and a complete network access path is formed, so that the automatic calculation of the network path crossing the blind point is realized. In the whole process, only simple operations such as table lookup, confirmation and the like are needed, and a message is not needed to be transmitted, so that the failure risk brought by a network security policy is reduced. In addition, the whole process does not need manual intervention, the original 15-2-minute process is shortened to the second level, and the network design, engineering construction, operation maintenance and cross-resource pool collaboration efficiency is greatly improved.

Drawings

FIG. 1 is a schematic diagram of the steps of a network path determination method according to the present invention;

FIG. 2 is a flowchart of a network path determination method according to a first embodiment of the present invention;

fig. 3 is a detailed flowchart of step S12 in the first embodiment of the network path determining method of the present invention;

Fig. 4 is a detailed flowchart of step S13 in the first embodiment of the network path determining method of the present invention;

FIG. 5 is a flowchart of a second embodiment of a network path determination method according to the present invention;

FIG. 6 is a flowchart of a third embodiment of a network path determination method according to the present invention;

FIG. 7 is a schematic diagram illustrating steps for generating a virtual routing registry in a third embodiment of a network path determination method according to the present invention;

FIG. 8 is an example of a scenario within a network path determination method resource pool of the present invention;

FIG. 9 is an example of a scenario among resource pools of the network path determination method of the present invention;

fig. 10 is a schematic structural diagram of a network path determining device of a hardware running environment according to an embodiment of the present invention.

The achievement of the objects, functional features and advantages of the present invention will be further described with reference to the accompanying drawings, in conjunction with the embodiments.

Detailed Description

It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the invention.

In the process of realizing the network access of a service system across resource pools, network problems are easy to generate in the stage of service architecture design, deployment and maintenance, the processing of the network problems depends on whether the actual network access path among services accords with the expected design, the path calculation process depends on the technical experience of network design, engineering construction and operation maintenance personnel, related network nodes are logged in, next hop forwarding list items are queried, manual splicing and recombination are carried out to obtain the network access path, the process is time-consuming and labor-consuming, and serious experience dependence exists, and path calculation is generally carried out by the following three methods:

1. Traversing the network path hop by hop based on the TTL value: the gateway equipment where the login source address (IP) is located sends TTL messages hop by hop through commands such as route tracking and the like, traverses response addresses when each hop returns TTL supertime messages, and splices the addresses into network access paths after the completion.

2. Manually traversing the next hop address of each node: the network equipment where the login source address is located traverses the next hop IP address in the forwarding table item through a query command such as a show IP routing-table [ target IP ], and the like, and the address is spliced into a network access path after completion.

3. Network path discovery based on streaming: according to the technical experience of network design, engineering construction and operation maintenance personnel, each network node through which a source IP and target IP access path possibly passes issues a flow statistics strategy, and according to a flow result, the network node hitting the source and target IP address is traversed and spliced into a network access path.

However, the above method has the following problems:

1. traversing the network path hop by hop based on the TTL value: blind points in the path may reject the message based on the network security policy of the actual production environment, so that the TTL value cannot be calculated; in actual production, the nodes in the path are generally point-to-point interconnection addresses and are not issued to the outside, so that the node response message cannot be sent to the source end.

2. Manually traversing the next hop address of each node: the method has high experience requirements on maintenance personnel and is time-consuming, the calculation of a single-pair source-destination IP path generally needs 10-15 minutes, and each network device in the path needs to be logged in, so that additional management risks are brought.

3. Network path discovery based on streaming: compared with the former two methods, the method has higher and more time-consuming experience requirements on maintenance personnel in the aspects of architecture design, equipment operation, command issuing and the like, the single-pair source-destination IP path calculation generally needs 1-2 hours, and simultaneously each network equipment in the path needs to be logged in to issue a new statistical command, so that additional risks are brought to network security and production security.

Correspondingly, the application provides a path confirmation method, when a network path blind spot is encountered, the path is searched according to the boundary design table and/or the virtual routing table, so that the effective calculation of the network path is realized, a message is not required to be sent, and manual access is not required.

In order to better understand the above technical solution, exemplary embodiments of the present application will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

Communication in the cloud network is divided into two scenes, namely, in a resource pool and among the resource pools according to whether a requested flow path spans the resource pools:

first, in the resource pool: network devices through which the forwarding paths flow are all inside the current cloud network, but interruption of the IP forwarding paths is caused by, for example, incapability of managing all network devices, occurrence of data crossing centers, incapability of collecting related routing data and the like, so that network path blind spots are generated, and complete paths cannot be formed.

Second, resource pools: the network equipment through which the forwarding path flows relates to a plurality of cloud networks, when the current cloud network searching process encounters an edge equipment connected with a multi-cloud network and encounters non-current cloud network equipment, related routing data are lack, a network path blind point is generated, and a complete path cannot be formed.

In view of the above scenario, the present disclosure proposes a network path determining method, and the brief steps are shown in fig. 1.

And introducing a boundary design table and a route registration table into the operation and maintenance platform based on the basic principle of routing, and when the process of inquiring the IP forwarding path encounters a network path blind spot, initiating cross-cloud path continuous check through the boundary design table and initiating cloud internal blind spot path continuous check through the route registration table to form a complete IP forwarding path. In the fault intelligent diagnosis of the intelligent operation and maintenance platform, operation and maintenance personnel perform subsequent fault troubleshooting root cause positioning based on the formed complete IP forwarding path, each hop of equipment and link through which each pair of IP access flows of the whole network pass is troubleshooted, when the platform finds faults, the root cause network elements can be automatically positioned based on the common nodes through which the abnormal IP access flows flow and the fault positioning model, and the efficiency of the operation and maintenance personnel in path inquiry, index analysis and problem communication is greatly improved.

An embodiment of the present invention provides a network path determining method, and referring to fig. 2, fig. 2 is a flowchart of a first embodiment of a network path determining method according to the present invention.

In this embodiment, the network path determining method includes:

step S11: when the target address corresponding to the next hop cannot be identified, a boundary design table and/or a virtual routing table are obtained;

the forward process of the data flow is that, starting from the source address, taking the target address as the end point, inquiring hop by hop according to the routing table, recording the network equipment and the access port through which each hop passes, and finally reaching the target address. If the next hop address is encountered in the process and cannot be identified, namely a network path blind spot appears, analysis is interrupted.

It may be understood that the network path blind point (Network Path Blind Spot, NPBS) refers to that the service system is distributed in a plurality of resource pools, and when an internal component of the service system needs to be accessed in the resource pool or across the resource pools, one or more unidentified unknown nodes exist in the network nodes through which the source IP passes to the target IP, and these unknown nodes are collectively referred to as the network path blind point; a boundary design table (External IP Table, EIT) for registering a boundary of a resource pool for routing across the resource pool; the virtual routing table (Virtual Route Table, VRT) refers to a routing register table item formed by automatically registering blind spot areas of network path through destination address detection of a plurality of network segments, and is used for routing in a resource pool.

First, data preparation is performed, that is, an EIT table and a VRT table are established.

Then, route searching is carried out, namely IP forwarding path inquiry is initiated, hop-by-hop route searching is carried out from a source address according to a route strategy, under normal conditions, a router can find a route entry which is most matched with a target network address according to information in a route table, and a next hop address is determined until the target address is reached. However, when all network devices cannot be managed, a data center crossing occurs, and the like, a situation that a target address corresponding to a next hop cannot be identified, namely a network path blind spot, may occur.

Alternatively, if it has been found that the target has been reached, the seek is ended.

Optionally, when the destination address (Next Hop IP, NHIP) corresponding to the Next Hop cannot be identified, a boundary design table and/or a virtual routing table is required to form a complete IP forwarding path.

Wherein, the boundary design table and/or the virtual routing table can be obtained by querying historical data in the database.

Step S12: when the target address exists in the boundary design table, determining a target cloud based on the boundary design table, and initiating path continuous checking in the target cloud; or alternatively

It can be understood that the EIT is an address for identifying an entrance and exit between cloud networks in a multi-cloud network environment, specifically including an entrance and exit address, a cloud network identifier, an internal address, etc., and when the routing process finds that the next hop address NHIP belongs to the EIT, the path is continuously searched in the cloud network to which the NHIP belongs, so as to solve the NPBS problem in cross-cloud path searching in the multi-cloud environment.

Optionally, when the target address exists in the boundary design table, it is indicated that the target address corresponding to the next hop does not belong to the current cloud network, so that the target cloud where the target address is located needs to be further determined based on the boundary design table, further, the path is continuously searched in the target cloud, and the steps of performing the hop-by-hop path searching according to the routing policy, identifying the target address corresponding to the next hop, and the like are repeatedly performed.

Among them, a non-class inter-domain route matching algorithm (Classless InterDomain Routing, CIDR) may be employed to determine whether the target address exists in the boundary design table. CIDR is a standard method for representing ranges of IP addresses, each CIDR representing a subnet mask consisting of an IP address and a numerical representation followed by a slash, e.g., 192.168.0.0/24 representing a range containing all IP addresses between 192.168.0.0 and 192.168.0.255. Thus, the target address may be compared to the CIDR representation of each internal address in the boundary design table, and if the target address is within any CIDR range, then it is determined that the target address is present in the boundary design table.

Alternatively, referring to fig. 3, the boundary design table includes an ingress and egress address and a cloud network identifier, and the step S12 includes:

step S121: if the entrance address in the boundary design table is matched with the target address, determining a target cloud according to the cloud network identification in the boundary design table, and initiating path continuous checking in the target cloud;

it may be understood that the gateway address of the cloud network refers to an IP address used for accessing and using an accessed service, where the outlet address refers to an IP address used by a cloud service of an opposite party to receive an access request, and the inlet address refers to an IP address used by a cloud service of the present application to receive an access request, and in terms of a correspondence relationship, one cloud service may provide access services for a plurality of other cloud services at the same time in one cloud network, where one inlet address needs to be configured for each cloud service.

When the next hop points to other cloud networks, the gateway address of the other cloud networks is generally used as the destination address corresponding to the next hop, so as to reduce the matching range and improve the matching efficiency.

Optionally, all the gateway addresses in the EIT are directly matched with the target addresses, and specific matching modes include subnet mask matching, prefix matching, fuzzy matching and the like.

Illustratively, prefix matching is adopted, that is, the prefixes of the gateway address and the target address are compared, and if they are the same, the matching degree is 100%. For example, if the gateway address is 192.168.1.0/24 and the target address is 192.168.1.10, their prefixes are identical, and the matching degree is 100%.

And selecting a target gateway address with highest matching degree, then determining a cloud network identifier associated with the target gateway address in the EIT, and determining a target cloud, namely a cloud network where a target address corresponding to the next hop is located, according to the cloud network identifier. After entering the target cloud, the current address is the gateway address of the target cloud, and the gateway address is used as a new source address to continue to perform hop-by-hop route searching according to the routing strategy.

After step S12, it includes:

step S122: and if the access address in the boundary design table is not matched with the target address, judging whether the target address exists in the virtual routing table.

Optionally, a mismatch condition is preset, for example, the matching degree is lower than 50%, and when all the entrance addresses and the target addresses in the boundary design table are not matched, that is, the matching degree is lower than 50%, it is indicated that the target addresses are not in EIT, that is, are not in other cloud networks.

At this time, it may be further determined whether the target address exists in the VRT, i.e., whether it is in the current cloud network.

Compared with the mode of judging by only adopting a single table, the method of combining two tables can provide more accurate matching results, and the single table may not cover all matching conditions, and the two tables can more comprehensively consider different matching conditions, so that the matching accuracy is improved. In addition, the matching process is decomposed into a plurality of steps by combining and judging the two tables, so that the matching efficiency can be improved.

Step S13: when the target address exists in the virtual routing table, initiating path continuous checking based on path information associated with the target address recorded in the virtual routing table;

it will be appreciated that the VRT is used to record the routing entries (Virtual Route Item, VRI) of the network path blind spot NPBS, requiring routine maintenance updates on a daily basis, including specifically the ingress address, NPBS name, subnet, next hop device name, next hop port name, next hop address NHIP, etc.

Further, when the target address exists in the virtual routing table, it is indicated that the target address corresponding to the next hop belongs to the current cloud network, so that the steps of performing hop-by-hop route searching, identifying the target address corresponding to the next hop and the like according to the routing policy can be repeatedly executed by directly initiating route continuous searching according to other path information recorded in the virtual routing table, such as the next hop device name, the next hop port name and the like.

The specific principle of determining whether the target address exists in the virtual routing table by adopting the CIDR algorithm is the same as the above, and will not be described herein.

Or, referring to fig. 4, the virtual routing table includes a plurality of routing entries, where each routing entry includes an entry address, a next hop address, and path information, and step S13 includes:

step S131: screening out target route entries, of which the current address is matched with the entrance address and the target address is matched with the next-hop address, from all the route entries;

step S132: and initiating a path follow-up check according to the path information of the target routing entry.

It can be understood that, for the same entry address, a single VRI or a plurality of VRIs can be configured, and the VRT can be regarded as a black box routing center, and the routes needed to be relied on in the routing process are registered and put in a warehouse in a routing format by an entry and an exit, so as to assist the downward recursion of the routing process, and the route entries VRI in the VRT actually correspond to the data flows routed in a plurality of devices.

Optionally, acquiring the current address, matching the current address with the entry addresses of all route entries, screening out candidate route entries meeting the matching condition, and setting the route entry with the matching degree reaching 80% as the candidate route entry; and matching the target address with the next hop addresses of all the candidate route entries, screening out target route entries meeting the matching condition, and setting the candidate route entries with the matching degree reaching 80% as target route entries again.

Further, according to the path information of the target route entry, the next hop device name, the next hop port name and the like, the path continuous check is initiated.

It is noted that if there are multiple destination route entries, i.e. there are multiple routes from the current address to the destination address corresponding to the next hop, traversal may begin with the first entry destination route entry.

Optionally, if the state of the current target route item is idle, initiating a path follow-up according to the path information of the current target route item; otherwise, if the state of the current target route entry is busy, waiting for a preset period of time and querying the state again until the state becomes idle, and initiating path continuous query. And similarly, completing the path continuous check of all the target routing entries.

The scheme decides whether to initiate the path continuous check according to the current state of the target route entry so as to ensure that each entry target route entry finally initiates the path continuous check, and the arrangement is beneficial to improving the reliability and the comprehensiveness of the path searching process and the result.

It should be noted that the order of step S12 and step S13 is not limited, and may be either EIT first, VRT second, or EIT first, and the embodiment is not particularly limited.

Step S14: and generating a network path according to the path continuous checking result.

Optionally, a complete IP forwarding network path is formed through the path continuous checking result of the boundary design table or the virtual routing table.

It should be noted that if the destination address does not exist in EIT or VRT, it indicates that the existing table data cannot query the related information of the blind point of the network path, that is, the path does not belong to the destination path to be determined, so that the path interruption is directly determined, and an incomplete interruption path is formed due to the data registration.

When the NPBS appears in the network path, if the VRT and EIT data are matched, a complete IP forwarding path can be formed, and the part of the NPBS in the path is marked and displayed, and the relevant routing data cannot be acquired, so that the internal details cannot be displayed, and if the corresponding VRT and EIT are not available, the network path is directly interrupted after the network path encounters the NPBS, and the whole path cannot be displayed on the last nano-tube device in the network path.

In the technical scheme provided by the embodiment, when the target address corresponding to the next hop cannot be identified, the route is automatically found through the boundary design table and/or the virtual routing table to form a complete network access path, so that the automatic calculation of the network path crossing the blind point is realized. In the whole process, only simple operations such as table lookup, confirmation and the like are needed, and a message is not needed to be transmitted, so that the failure risk brought by a network security policy is reduced. In addition, the whole process does not need manual intervention, the original 15-2-minute process is shortened to the second level, and the network design, engineering construction, operation maintenance and cross-resource pool collaboration efficiency is greatly improved.

Further, referring to fig. 5, a second embodiment of the network path determining method of the present invention is presented. Based on the embodiment shown in fig. 2, before the step of obtaining the boundary design table and/or the virtual routing table when the destination address corresponding to the next hop cannot be identified, the method includes:

step S21: determining the gateway address of each cloud network according to the network segment characteristics of the address of each cloud network;

it is understood that a segment feature refers to a range of IP addresses used in a cloud network, with a segment feature typically represented by an IP address and a subnet mask. The gateway address refers to an IP address used to access a network in a cloud network. Typically, the ingress and egress addresses are the first available address and the last available address of the network.

Optionally, the number of bits of the network address is determined according to the subnet mask in the network segment feature of the address of the cloud network, 1 is added to the last bit of the network address as the first available address of the cloud network, i.e. the exit address, and the last bit of the network address is subtracted by 1 as the last available address of the cloud network, i.e. the entry address.

Illustratively, the segment features 192.168.0.0/24,/24 indicates that the first 24 bits are network addresses and the last 8 bits are host addresses. The last bit of the network address is incremented by 1, i.e., 192.168.0.1, as the exit address and the last bit of the network address is decremented by 1, i.e., 192.168.0.254, as the entry address.

Step S22: determining cloud network identifications of the cloud networks according to the attribution resource pools of the cloud networks;

step S23: and summarizing the gateway address and the cloud network identifier to generate the boundary design table.

Optionally, the home resource pool of the cloud network is checked, a naming rule of the cloud network identifier is obtained, and then a unique identifier is generated for the cloud network according to the naming rule, if the name of the resource pool is "Production", the cloud network identifier may be "P1".

Further, the gateway address of each cloud network is associated with the cloud network identifier, and then the associated data of all cloud networks are summarized to generate a boundary design table.

In one technical scheme provided by the embodiment, an access address is determined according to network segment characteristics of the address, a cloud network identifier is determined according to a home resource pool, and then a boundary design table is obtained through summarization. Compared with the direct query mode from the database, the EIT table is generated according to the boundary definition between the resource pools, has stronger expandability and flexibility, can flexibly allocate the access address and the cloud network identifier according to different requirements and scenes, improves the overall flexibility and adaptability, and can automatically determine the access address and the cloud network identifier by determining the network segment characteristics and the attribution resource pools when the cloud network is newly added or the existing cloud network is modified, thereby avoiding the complexity and the error of manual adjustment.

Further, referring to fig. 6, a third embodiment of the network path determining method of the present invention is presented. Based on the embodiment shown in fig. 5, after the step of summarizing the gateway address and the cloud network identifier to generate the boundary design table, the method includes:

step S31: removing the boundary design table from the address set which cannot be identified by the current cloud network to obtain an internal blind point address set of the current cloud network;

it will be appreciated that VRT data is automatically generated in advance by a background process, periodically refreshed, as shown in fig. 7, to generate a brief step diagram of the virtual routing registry.

Optionally, extracting an address set which cannot be identified in the current cloud network through the next hop address NHIP data of the acquired routing data, and removing EIT data on the basis, so that the address data IP address set is left as a blind point address set in the cloud network.

Step S32: acquiring a port address information table, an address resolution protocol information table and a routing information table of addresses corresponding to the internal blind spot address set;

optionally, the data ingress port address set, device set, port set may be identified by initiating path test data on the device set of nanotubes on both sides of the blind spot region.

Illustratively, the devices are connected by a simple network management protocol (Simple Network Management Protocol, SNMP) and the port address information table and address resolution protocol information table (Address Resolution Protocol, ARP) of the devices are collected in bulk; the devices are connected by Secure Shell (SSH) protocol and the routing information table of the devices is collected in batches.

Step S33: traversing the next hop addresses of all route entries in the route information table, and determining the route entry corresponding to the next hop address as a route entry to be processed if the next hop address does not exist in the port address information table;

optionally, traversing the next hop addresses of all the route entries in the route information table, and for each next hop address, checking whether a corresponding port address exists in the port address information table. If the next hop address does not exist, the next hop address cannot be directly accessed or cannot be forwarded through a known port, so that a routing entry corresponding to the next hop address needs to be determined as a routing entry to be processed, and the routing entry is further processed so as to be added into a routing information table, and connectivity and correctness of a route are ensured.

Step S34: determining an output port and an input port of the routing entry to be processed according to the target subnet of the routing entry to be processed and in combination with a probe machine and an address of the target subnet in the address resolution protocol information table;

step S35: and generating the virtual routing table according to the next hop address of the routing entry to be processed, the target subnet, the output port and the input port.

Optionally, determining a target subnet of the routing entry to be processed, determining a blind spot source address and a blind spot target address of the target subnet according to the IP address belonging to the target subnet in the ARP table, and further generating a blind spot source destination address task.

Further, through the probe machine arranged in the area, on one hand, from the blind point source address to the target address, the target subnet is reached by automatic routing, and an outlet port of the route entry to be processed is obtained; on the other hand, from the target address to the blind point source address, the target subnet is automatically reached by routing, and the entry port of the route entry to be processed is obtained.

And finally, automatically generating a virtual routing table by the next hop address, the target subnet, the output port and the input port of the routing entry to be processed.

In one technical scheme provided by the embodiment, a virtual routing table is generated by automatically detecting in the background and performing forward and reverse calculation on a path from a set probe to an address automatically selected from the routing table. Compared with the method of directly inquiring from the database, the method can acquire the port address, the ARP information and the routing information of the equipment in real time, and does not need to depend on stored data. Thus, the real-time performance of the network topological graph and the routing table can be ensured, and the change of the network environment can be reflected in time.

Referring to fig. 8, for an example of a scenario of NPBS in a resource pool, when NPBS occurs in the resource pool, a complete path may be formed by automatically continuing to find a path using a VRT table automatically generated in the background.

Referring to fig. 9, for an example of a scenario of NPBS between resource pools, when a path is found across cloud networks, a next hop address is an address of another cloud network, which is already defined in EIT, and after the current cloud network is found, a path is continuously found to the other cloud network, so that a complete path can be formed.

The embodiment of the invention provides a network path determining device, which comprises:

Since the embodiments of the apparatus portion and the embodiments of the method portion correspond to each other, the embodiments of the apparatus portion are referred to the description of the embodiments of the method portion, and are not repeated herein.

Referring to fig. 10, fig. 10 is a schematic diagram of a network path determining device of a hardware running environment according to an embodiment of the present invention.

As shown in fig. 10, the network path determining apparatus may include: a processor 1001, such as a central processing unit (Central Processing Unit, CPU), a communication bus 1002, a user interface 1003, a network interface 1004, a memory 1005. Wherein the communication bus 1002 is used to enable connected communication between these components. The user interface 1003 may include a Display, an input unit such as a Keyboard (Keyboard), and the optional user interface 1003 may further include a standard wired interface, a wireless interface. The network interface 1004 may optionally include a standard wired interface, a WIreless interface (e.g., a WIreless-FIdelity (WI-FI) interface). The Memory 1005 may be a high-speed random access Memory (Random Access Memory, RAM) Memory or a stable nonvolatile Memory (NVM), such as a disk Memory. The memory 1005 may also optionally be a storage device separate from the processor 1001 described above.

It will be appreciated by those skilled in the art that the structure shown in fig. 10 does not constitute a limitation of the network path determination device, and may include more or fewer components than shown, or may combine certain components, or a different arrangement of components.

As shown in fig. 10, an operating system, a data storage module, a network communication module, a user interface module, and a network path determination program may be included in the memory 1005 as one type of storage medium.

In the network path determining apparatus shown in fig. 10, the network interface 1004 is mainly used for data communication with other apparatuses; the user interface 1003 is mainly used for data interaction with a user; the processor 1001 and the memory 1005 in the network path determination apparatus of the present invention may be provided in the network path determination apparatus, which invokes the network path determination program stored in the memory 1005 through the processor 1001 and performs the network path determination method provided by the embodiment of the present invention.

Embodiments of the present invention provide a computer readable storage medium having stored thereon a computer program which when executed by a processor performs the steps of any of the embodiments of the network path determination method described above.

Since the embodiments of the computer readable storage medium portion and the embodiments of the method portion correspond to each other, the embodiments of the computer readable storage medium portion are referred to the description of the embodiments of the method portion, and are not repeated herein.

It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or system. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or system that comprises the element.

The foregoing embodiment numbers of the present invention are merely for the purpose of description, and do not represent the advantages or disadvantages of the embodiments.

From the above description of the embodiments, it will be clear to those skilled in the art that the above-described embodiment method may be implemented by means of software plus a necessary general hardware platform, but of course may also be implemented by means of hardware, but in many cases the former is a preferred embodiment. Based on such understanding, the technical solution of the present invention may be embodied essentially or in a part contributing to the prior art in the form of a software product stored in a storage medium (e.g. ROM/RAM, magnetic disk, optical disk) as described above, comprising instructions for causing a terminal device (which may be a mobile phone, a computer, a server, or a network device, etc.) to perform the method according to the embodiments of the present invention.

The foregoing description is only of the preferred embodiments of the present invention, and is not intended to limit the scope of the invention, but rather is intended to cover any equivalents of the structures or equivalent processes disclosed herein or in the alternative, which may be employed directly or indirectly in other related arts.

Claims

1. A network path determination method, characterized in that the network path determination method comprises the steps of:

and generating a network path according to the path continuous checking result.

2. The network path determination method of claim 1, wherein the boundary design table includes an ingress and egress address and a cloud network identification, wherein the step of determining a target cloud based on the boundary design table when the target address exists in the boundary design table, and initiating a path continuation in the target cloud comprises:

3. The network path determination method of claim 1, wherein the virtual routing table includes a plurality of routing entries, wherein each of the routing entries includes an ingress address, a next hop address, and path information, and wherein the step of initiating a path continuation check based on the path information associated with the destination address recorded in the virtual routing table when the destination address exists in the virtual routing table comprises:

4. The network path determination method of claim 3, wherein the step of initiating a path review from the path information of the target routing entry comprises:

5. The network path determining method according to claim 1, wherein the step of initiating a path subsequent check based on path information associated with the target address recorded in the virtual routing table when the target address exists in the virtual routing table, comprises:

6. The network path determining method according to claim 1, wherein before the step of acquiring the boundary design table and/or the virtual routing table when the destination address corresponding to the next hop cannot be identified, the method comprises:

7. The network path determination method according to claim 6, wherein after the step of generating the boundary design table by summarizing the gateway address and the cloud network identification, the method comprises:

8. A network path determination apparatus, the apparatus comprising:

9. A network path determination device, characterized in that the network path determination device comprises: a memory, a processor and a network path determination program stored on the memory and executable on the processor, the network path determination program being configured to implement the steps of the network path determination method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that the computer-readable storage medium has stored thereon a network path determination program which, when executed by a processor, implements the steps of the network path determination method according to any one of claims 1 to 7.