Routing configuration verification method and device based on hybrid symbolization and electronic equipment

Abstract

The invention relates to the technical field of computer networks, in particular to a hybrid symbolization-based routing configuration verification method and device and electronic equipment, and the method comprises the steps: constructing a hybrid symbolization network model according to network configuration; reasoning a control plane behavior of the network in any environment by using the mixed symbolization network model, and reasoning a forwarding behavior of the network in any environment according to the control plane behavior; and judging whether the forwarding behavior of the network accords with the intention of the network administrator according to the forwarding result. Therefore, the problem that an existing routing configuration verification method cannot fully discover errors in routing configuration while meeting expandability is solved, forwarding behaviors of a network in any environment can be verified, and potential errors in configuration can be fully found.

Description

Technical Field

[0001] The present application relates to the field of computer network technology, and in particular to a routing configuration verification method, device and electronic device based on hybrid symbolization. Background Art

[0002] Distributed routing protocols play a vital role in guiding data forwarding within computer networks. Each router in the network executes one or more routing protocols and exchanges information with adjacent routers to determine the best path to each destination. These routing protocol instances and inter-protocol communication mechanisms together constitute the control plane of the network.

[0003] Configuring the control plane is a challenging task because router configuration languages ​​only provide low-level abstractions, and the configured network must meet the design intent of the network (for example, blocking certain flows and allowing other flows) when link or router states are unpredictable. Therefore, router configurations are prone to errors that can cause network outages.

[0004] Therefore, in actual production, it is usually necessary to verify the correctness of the configuration before deployment to check whether the network configuration to be deployed can meet the intention of the network administrator and whether it meets the security requirements. However, the configuration verification of routers faces many challenges: First, the scale of the actual application network is very large, each router has a lot of configuration commands, and the protocols running on it are very many and complex. It is difficult to accurately infer the forwarding behavior of the network based on the configuration. Second, the wide area network is a distributed system. Each router exchanges information with each other and eventually converges to form a routing table. Different routers affect each other. After changing a certain configuration, it is difficult to determine which routers' forwarding behaviors are affected. Third, the state space of the entire network is very large, and as the network environment (network link status, external route announcements received by the network) changes, the state of the network is constantly changing. Some errors will only be triggered under specific conditions and specific states.

[0005] At present, routing configuration verification methods can be divided into two categories: data plane verification. Many works create data plane models by analyzing snapshots of device forwarding tables. Since they only focus on verifying the current data plane, these tools lack the ability to actively evaluate whether the network still meets network properties when a link failure occurs or a specific external announcement is received; control plane verification: Existing control plane verification works can be divided into three categories: (1) Verification in a single environment: These methods take the network configuration and the specific environment as input, simulate the resulting network behavior, and generate the expected data plane. This results in them needing to re-simulate the control plane in each environment, resulting in poor scalability. (2) Verification in multiple environments: These methods construct formal network models or graph-based model tools so that multiple environments can be analyzed simultaneously. Although these tools are specifically designed to verify control plane behavior when encountering arbitrary link failures or receiving arbitrary announcements, they may face inefficiencies when checking reachability in arbitrary environments (such as environments containing all possible eBGP route announcements). Therefore, even if the configuration is successfully verified, there is still a possibility of undetected errors. (3) Arbitrary Environment Verification: This type of method provides a powerful capability to verify networks in arbitrary environments by encoding the network as a large logical formula and solving it. However, they have poor scalability because trying to solve this complex formula has proven to be impractical even using the most advanced SMT solvers.

[0006] Therefore, scalably validating configurations in arbitrary environments and fully discovering potential errors in configurations remains an open problem. Summary of the invention

[0007] The present application provides a routing configuration verification method, device and electronic device based on hybrid symbolization to solve the problem that the current routing configuration verification method cannot fully discover errors in the routing configuration while meeting scalability.

[0008] The first aspect of the present application provides a routing configuration verification method based on hybrid symbolization, comprising the following steps: constructing a hybrid symbolic network model according to the network configuration; using the hybrid symbolic network model to infer the control plane behavior of the network in any environment, and inferring the forwarding behavior of the network in any environment based on the control plane behavior; judging whether the forwarding behavior of the network is in line with the intention of the network administrator based on the forwarding result.

[0009] Optionally, the construction of a hybrid symbolic network model includes: determining the protocol running in the network and the corresponding protocol routing; dividing the corresponding attribute equivalence classes according to the protocol routing attributes and the corresponding network configuration; and constructing a hybrid symbolic network model for the network according to the attribute equivalence classes and the network configuration.

[0010] Optionally, the use of a hybrid symbolic network model to infer the control plane behavior of a network in any environment includes: constructing corresponding hybrid symbolic protocol routing based on symbolic routing declaration conditions and routing topology conditions in combination with protocol routing attributes represented by equivalence classes; and obtaining the control plane behavior of the network in any environment through hybrid symbolic simulation.

[0011] Optionally, inferring the forwarding behavior of the network in any environment based on the control plane behavior includes: performing mixed symbolic data packet forwarding based on the control plane behavior of the network in any environment, inferring the data plane forwarding behavior of the network in any environment, and obtaining the data packets received in any environment at each router.

[0012] Optionally, judging whether the forwarding behavior of the network complies with the intention of the network administrator based on the forwarding result further includes: extracting attribute-related data packets corresponding to the data packets according to the attributes to be verified, and judging whether the forwarding behavior of the network complies with the intention of the network administrator under any environment based on the attribute-related data packets; if the attribute-related data packets do not comply with the intention of the network administrator, then returning all erroneous forwarding behaviors that caused the intention of the network administrator to be violated, so that the network administrator can correct the erroneous configuration.

[0013] The second aspect of the present application provides a routing configuration verification device based on hybrid symbolization, including: a construction module, used to construct a hybrid symbolic network model according to the network configuration; an inference module, used to use the hybrid symbolic network model to infer the control plane behavior of the network in any environment, and infer the forwarding behavior of the network in any environment based on the control plane behavior; a verification module, used to determine whether the forwarding behavior of the network is in line with the intention of the network administrator based on the forwarding result.

[0014] Optionally, the construction module is also used to: determine the protocol running in the network and the corresponding protocol routing; divide the corresponding attribute equivalence classes according to the protocol routing attributes and the corresponding network configuration; and construct the hybrid symbolic network model according to the attribute equivalence classes and the network configuration.

[0015] Optionally, the reasoning module is also used to: construct corresponding hybrid symbolic protocol routing based on symbolic routing declaration conditions and routing topology conditions, combined with protocol routing attributes represented by equivalence classes; and obtain the control plane behavior of the network in any environment through hybrid symbolic simulation.

[0016] Optionally, the inference module is further used to: perform mixed symbolic data packet forwarding according to the control plane behavior of the network in any environment, infer the data plane forwarding behavior of the network in any environment, and obtain the data packets received in any environment at each router.

[0017] Optionally, the verification module is also used to: extract attribute-related data packets corresponding to the data packet according to the attribute to be verified, and determine whether the forwarding behavior of the network is in line with the intention of the network administrator under any environment based on the attribute-related data packets; if the attribute-related data packets do not meet the intention of the network administrator, then return all erroneous forwarding behaviors that caused the network administrator's intention to be violated, so that the network administrator can correct the erroneous configuration.

[0018] The third aspect of the present application provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the hybrid symbolization-based routing configuration verification method as described in the above embodiment.

[0019] The fourth aspect of the present application provides a computer program product on which a computer program is stored. The program is executed by a processor to implement the hybrid symbolization-based routing configuration verification method as described in the above embodiment.

[0020] In the above implementation, a hybrid symbolic network model is constructed according to the network configuration; the control plane behavior of the network in any environment is inferred using the hybrid symbolic network model, and the forwarding behavior of the network in any environment is inferred based on the control plane behavior, and whether the forwarding behavior of the network meets the intention of the network administrator is determined based on the forwarding result. Thus, the problem that the current routing configuration verification method cannot fully discover errors in the routing configuration while meeting scalability is solved, and the forwarding behavior of the network in any environment can be verified, and potential errors in the configuration can be fully discovered.

[0021] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through the practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:

[0023] Figure 1 A flowchart of a routing configuration verification method based on hybrid symbolization provided according to an embodiment of the present application;

[0024] Figure 2 A schematic diagram of the ConVer verifier system architecture according to an embodiment of the present application;

[0025] Figure 3 A schematic diagram of prefix equivalence class division according to an embodiment of the present application;

[0026] Figure 4A schematic diagram of a group attribute configuration fragment according to an embodiment of the present application;

[0027] Figure 5 A schematic diagram of hybrid symbolic routing calculation and data packet forwarding according to an embodiment of the present application;

[0028] Figure 6 is a schematic diagram of a synthetic network data set according to an embodiment of the present application;

[0029] Figure 7 A schematic diagram of the reachability attribute verification time under different conditions according to an embodiment of the present application;

[0030] Figure 8 A schematic diagram of verification time in different link failure scenarios according to an embodiment of the present application;

[0031] Fig. 9 A schematic diagram of verification time variation under different network scales according to an embodiment of the present application;

[0032] Fig.10 A schematic diagram of reachability verification time under different types of errors according to an embodiment of the present application;

[0033] Fig.11 This is an example diagram of a routing configuration verification device based on hybrid symbolization according to an embodiment of the present application;

[0034] Fig.12 Schematic diagram of the structure of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0035] Embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, and should not be construed as limiting the present application.

[0036] The following describes the hybrid symbolized routing configuration verification method, device, and electronic device of the embodiments of the present application with reference to the accompanying drawings. In view of the problem mentioned in the above background technology that the current routing configuration verification method cannot fully discover errors in the routing configuration while meeting scalability, the present application provides a hybrid symbolized routing configuration verification method, in which a hybrid symbolized network model is constructed according to the network configuration, and the control plane behavior of the network in any environment is inferred using the hybrid symbolized network model, and the forwarding behavior of the network in any environment is inferred based on the control plane behavior; and whether the forwarding behavior of the network meets the intention of the network administrator is judged based on the forwarding result. Thus, the problem that the current routing configuration verification method cannot fully discover errors in the routing configuration while meeting scalability is solved, and the configuration can be verified scalably in any environment to fully discover potential errors in the configuration.

[0037] Specifically, Figure 1 A flowchart of a routing configuration verification method based on hybrid symbolization provided in an embodiment of the present application.

[0038] like Figure 1 As shown, the routing configuration verification method based on hybrid symbolization includes the following steps:

[0039] In step S101, a hybrid symbolic network model is constructed according to the network configuration.

[0040] In step S102, the control plane behavior of the network in any environment is inferred using the hybrid symbolic network model, and the forwarding behavior of the network in any environment is inferred based on the control plane behavior.

[0041] Optionally, in some embodiments, constructing a hybrid symbolic network model includes: determining the protocol running in the network and the corresponding protocol routing; dividing the corresponding attribute equivalence classes according to the protocol routing attributes and the corresponding network configuration; and constructing the hybrid symbolic network model according to the attribute equivalence classes and the network configuration.

[0042] Optionally, in some embodiments, a hybrid symbolic network model is used to infer the control plane behavior of the network in any environment, including: constructing corresponding hybrid symbolic protocol routing based on symbolic routing declaration conditions and routing topology conditions in combination with protocol routing attributes represented by equivalence classes; and obtaining the control plane behavior of the network in any environment through hybrid symbolic simulation.

[0043] The embodiment of the present application proposes a hybrid symbolic routing configuration verification method ConVer, which can scalably verify the configuration in any environment where the network is located, thereby discovering all potential errors in the configuration. The embodiment of the present application specifically includes two parts: (1) constructing a hybrid symbolic network model and performing hybrid symbolic routing calculation; (2) exploring the hybrid symbolic model to verify whether the network forwarding behavior in any environment meets the intention of the network administrator, such as Figure 2 shown.

[0044] When constructing a hybrid symbolic network model, it is necessary to divide each routing attribute in the network into attribute equivalence classes.

[0045] The attribute equivalence class captures the value set of each routing attribute. For each attribute value in the value set, the routing policy will process the route announcement in the same way. The formal definition is as follows.

[0046] Define an Attribute Equivalence Class (AEC): For a given set of routing policies P, a set of routing declarations R, a routing attribute A, and a possible value v of A, let r(A,v) denote the routing declaration obtained by updating the value of attribute A of routing declaration r to v, and let operation p (r) represents the operation of routing policy p on route r. Two possible values ​​v1 and v2 of routing attribute A belong to an attribute equivalence class AEC if and only if the following conditions are met:

[0047]

[0048] Since external route announcements are usually propagated through the BGP protocol, and some attributes are not propagated with route announcements, we only need to perform AEC division on several attributes of the BGP protocol. The following uses prefix and community as examples to explain how to perform AEC division on different types of route attributes.

[0049] Attribute equivalence classes include prefix equivalence classes and community attribute equivalence classes.

[0050] Among them, the Prefix Equivalence Class (PEC) is different from other attributes. The prefix contains two components: the IP address and the mask length, which together represent the destination prefix. Therefore, PEC is stored as a set of prefix tuples in the form of (IP, ML). For IPv4 (IPv6), IP is a 32-bit (128-bit) symbolic variable that represents all possible IP addresses in the prefix. And ML (mask length) is a 32-bit (128-bit) unsigned integer value, where each bit of 1 represents a possible length. For example, a PEC with a prefix (192.0.0.0 / 2,2) can be represented as (p1p2,2 1 ), where p1p2 represents the symbolic variables of the first and second digits of IP, and 2 1 Indicates that only the second bit of the mask length is set to 1. A PEC containing an arbitrary prefix can be represented as a tuple set where IP is set to the symbolic value True and each bit of ML is set to 1.

[0051] Prefix tuple AND operation: For two given prefix tuples t1(IP1,ML1) and t2(IP2,ML2), the tuple AND operation is defined as follows: AND tuple (t1,t2)={(IP1∧IP2,ML1&ML2)}

[0052] Prefix tuple NOT operation: For a given prefix tuple t(IP,ML), the tuple NOT operation is defined as follows:

[0053] PEC AND operation: For two given PECs: PEC1 and PEC2, the PEC AND operation is defined as follows: AND PEC (PEC1,PEC2) = {AND tuple (t1,t2)|t1∈PEC1,t2∈PEC2}

[0054] PEC NOT Operation: For a given PEC: PEC, the PEC NOT operation is defined as follows: NOT PEC (PEC) = ∩ t∈ PEC NOT tuple (t)

[0055] The AND and NOT operations of PECs are used to divide the entire prefix space into disjoint PECs, such as Figure 3The algorithm is shown. First, extract all prefixes from the configuration (line 1), including any prefixes that are announced (explicitly or automatically announced), prefixes that appear in routing policies, prefixes in static routes, etc. Then convert them into initial PECs of the above form (line 2). Next, build a final PEC set to store the divided PECs results and add the PEC containing any prefix to it (line 3). Then add each PEC of the initial PECs to the final PEC set in turn (lines 4 to 16). When the initial PEC: PEC init When added to the final PEC set, it will be added to the PEC init and each PEC in the final set: PEC final A PEC AND operation is performed between (line 6). If the result is not empty (line 7), PEC final Will be cut into two PECs: (i) AND PEC (PEC final ,PEC init ); (ii) AND PEC (PEC final ,NOT PEC (PEC init )). They will be added back into the final PEC set. In addition, PEC init Will be updated to AND PEC (PEC final ,NOT PEC (PEC init )) and is processed continuously with the next PEC (line 10). Otherwise, PEC init will be processed directly with the next PEC in the final set. Finally, if PEC init is not empty, it will be added to the final PEC set (lines 13 to 15). This process is repeated until all PECs are processed, and finally, PEC final Contains all disjoint PECs in the network.

[0056] To classify CEC, we first extract all community attribute labels that appear in the routing policy from the configuration. Then we assign a symbolic variable v to each community attribute label c. c , where v c =1(True) / 0(False) indicates whether c exists in the current community attribute set. Therefore, any community attribute set can be expressed as a symbolic formula composed of the above symbolic variables. For example, for Figure 4 The configuration snippet in , assigns symbolic variables v1 and v2 with 1:1 and 2:2 respectively.

[0057] Further, the actual symbolic community attribute set of each policy action is identified. The routing policy consists of a series of Match-Action rules with different priorities, where each Match-Action rule is considered as an action. Only when the high-priority action is not matched, the low-priority action will be executed. Therefore, the actual symbolic community attribute set matched by the low-priority action is the negation of the community attribute set it matches and the community attribute set matched by the high-priority action. For example, for Figure 4 In the configuration fragment, the actual symbolic community attribute set matched by the first operation of routing policy P1 can be expressed as v1, while the symbolic community attribute set matched by the second operation can be expressed as In this way, for each routing policy, a set C of actual symbolic community attribute sets can be derived, which includes the actual symbolic community attribute set matched by each operation in the policy.

[0058] Then, the entire community attribute set space is divided into disjoint equivalence classes according to the set C of each routing strategy derived above. Specifically, a CEC set S is constructed and an initial CEC is added to it, with a Boolean value of True, representing all possible community attribute sets. Then, the set C of each routing strategy is traversed, and each symbolized community attribute set c in the set C is concatenated with each CEC: cec in S. If the result is not False, cec is further divided into two new equivalence classes: (i) cec∧c; And replace cec with these two equivalent classes. In addition, update c to c And do the above operation with the next CEC in S. Otherwise, directly process the next CEC in S. As a result, if c is not False, add c as a CEC to S. We repeat this process until all routing policies are processed. In the end, S will be the final set of all disjoint CECs partitioned by the configuration. For example, for Figure 4 Configuration snippet in v1 and The conjunction of is False, and the final CEC set S divided from the configuration includes: and for Figure 5 For the network shown, the community attribute set space will be divided into two CECs: CEC1 contains a single label 1:1 community attribute set, and CEC2 contains all other possible community attribute sets.

[0059] Before introducing the route announcement conditions, we first define the route announcement existence variables. Each route announcement existence variable a n is a Boolean variable, where a n=1(True) / 0(False) indicates whether the network receives external routing announcements n In the embodiment of the present application, a route announcement existence variable is allocated to each external route announcement. For example, Figure 5 In a, a1 is the variable assigned to the external route announcement e1 from neighbor E. In addition, for route announcements originating from the internal network, we directly assign a Boolean value True to them, indicating that they are always announced. The route announcement condition ac is determined by the existence of the route announcement variable a n The symbolic formula composed of represents the situation in which the network receives external route announcement combinations. Each route r is associated with an ac, which indicates the situation in which the route r is selected when receiving external route announcements. For example, in Figure 4 In the symbolic routing information base of router C shown in a, route r3 will become the best route only when router C does not receive the external route announcement e1 from the external neighbor E.

[0060] The routing topology condition tc is a link state variable l x The symbolic formula composed of x = 1 (True) / 0 (False) indicates whether link x is available. tc associated with each route r indicates under what failure conditions route r is selected. For example, Figure 5 In the symbolic RIB of router B shown in a, the topological condition of route r9 from router A is l AB , where l AB It is the link state variable of link AB, indicating that as long as link AB is available, route r9 will be selected.

[0061] Next, all possible external route announcements are modeled by constructing hybrid symbolic BGP routes. Hybrid symbolic routes for other protocols (such as ISIS and OSPF) can also be constructed in a similar manner.

[0062] A hybrid symbolic BGP route is defined as a tuple (Preifx, AD, ASPath, Nexthop, LP, MED, Community, ExternalASPathSize, AC∩TC). Preifx, MED, and Community are represented as corresponding AECs, representing various possible values ​​of these attributes in external route announcements. In addition, AC (administrative distance) and LP (local preference) are modeled as concrete values ​​because they are the default values ​​in all possible external route announcements. In addition, since Nexthop is always determined by the neighbor receiving the route, it is also modeled as a concrete value. ASPath is modeled as a set of AS numbers. ExternalASPathsi is a new attribute introduced by ConVer, represented as a range value with an integer lower and upper bound, which is used to represent the possible length of the external AS path that the route traverses. AC∩TC is a combination of the route announcement condition and the topology condition.

[0063] All possible external route announcements can then be modeled as a set of hybrid symbolic routes. In each hybrid symbolic route, preifx, MED, and Community are initialized with the corresponding AEC combination. ExternalASPathSize is set to a range (0,∞), indicating that the route announcement may traverse an external AS path of any length. The AC of each external route announcement is initialized with the corresponding route announcement existence variable assigned to it. TC is set to True. Other attributes are set to default values, for example, the LP of an external route announcement is always set to the default value of 100. For example, in Figure 5 In the network shown in a, each route is modeled as a tuple (Preifx, Community, ASPath, LP, ExternalASPathSize, AC∩TC). There are three PECs and two CECs in the example network. Therefore, all possible external route announcements can be modeled as six hybrid symbolic routes. Without loss of generality, only the hybrid symbolic routes derived from PEC1 and PEC2 are shown, denoted by e1 to e4 (e5 to e8), respectively. The AC of each external route announcement (e1 to e8) is initialized using the corresponding route announcement existence variables (a1 to a8), and the attribute values ​​of the hybrid symbolic routes from the internal network can be determined by configuration.

[0064] Next, ConVer computes hybrid symbolic routes by simulating the hybrid symbolic control plane model. ConVer first imports all routes from the internal network and all possible external route announcements received from external neighbors, which are represented as hybrid symbolic routes. Then, ConVer repeats the following three steps on each router until the hybrid symbolic RIB no longer changes: (1) import routes from neighbor routers; (2) sort all routes and update their propagation conditions; (3) export routes with updated propagation conditions to neighbor routers.

[0065] Encoding routing policy: First, encode the routing policy involving prefix and community attributes using the corresponding attribute equivalence class (AEC). Figure 5 As shown in a, routing policy P1 is encoded to match PEC1 and PEC2, while routing policies P2 and P3 are encoded to match CEC1.

[0066] Importing routes: In the process of calculating hybrid symbolic routes, each router first imports hybrid symbolic routes from its neighbor routers. During this process, each router filters or modifies the routes according to the inbound or egress routing policy. For example, in Figure 5 In a, e2 and e4 will be filtered out by the routing policy on port 2 of router C, because the policy only allows routes carrying CEC1. In addition, the propagation conditions remain unchanged during this process.

[0067] Sorting routes: When a router receives multiple routes with the same prefix equivalence class (PEC), it sorts them by comparing their attributes and updates its route announcement conditions and topology conditions. For attributes represented as specific values, their sizes can be directly compared. For attributes represented as attribute equivalence classes (AECs), since different equivalence classes are disjoint, their priority relationships can be easily determined. In addition, only the MED equivalence class will participate in route sorting. Suppose there are two MED equivalence classes: MEC1(0,49) and MEC2(50,∞). Obviously, MEC1(0,49) has a higher priority than MEC2(50,∞). The comparison of ExternalASPathSize will be described in Appendix C.

[0068] After priority sorting, suppose there are n routes r1, r2, …, r n , and the priority decreases in turn. The routing announcement condition and topology condition of the kth route are denoted as r k .(AC∩TC) is updated by combining the negation of the corresponding conditions of all higher priority routes, expressed as That is, only when all higher priority routes do not meet their route announcement conditions and topology conditions, r kwill be selected. For example, Figure 5 In a, assume that route B receives a new route with PEC2, whose local preference value is 350, and the route announcement condition and topology condition are r.(AC∩TC)=a9l AB . r has a higher priority than r9 due to its higher local priority.

[0069] Therefore, Router B updates

[0070] Exporting routes: Each router exports routes whose propagation conditions are not False to its neighbor routers. In this process, similar to importing routes, each router filters or modifies these routes according to the corresponding export routing policy. In addition, for each route r exported from router R to router N, r.(AC∩TC) will be updated to r.(AC∩TC)∩l RN , where l RN is the link survival variable of the link between R and N.

[0071] Model generalization: When there are multiple protocols (such as ISIS, OSPF), ConVer first sorts the routes according to the administrative distance of different protocols. After that, ConVer considers the protocol-specific properties. ConVer can also be easily extended to support route redistribution, route aggregation, and route dependencies of different protocols.

[0072] Optionally, in some embodiments, the forwarding behavior of the network in any environment is inferred based on the control plane behavior, including: performing mixed symbolic data packet forwarding based on the control plane behavior of the network in any environment, inferring the data plane forwarding behavior of the network in any environment, and obtaining the data packets received in any environment at each router.

[0073] Furthermore, the embodiments of the present application will illustrate how to perform hybrid symbolic packet forwarding to infer the forwarding behavior of all packets, and how to use the forwarding results for attribute verification.

[0074] In the forwarding phase, the entire destination IP address space needs to be modeled first to explore the forwarding behavior of all data packets. A simple approach is to model each bit of the IP address as a symbolic variable, which will result in 128 variables in IPv6, and the use of symbolic formulas for prefix matching is inefficient. Therefore, the embodiment of the present application introduces a hybrid symbolic IP address that uses PEC (packet equivalence class) to directly model the entire IP address space. When the forwarding behavior of all data packets carrying a prefix within a PEC is the same, the PEC can be used directly to represent the corresponding IP address space. However, some sub-PECs contain prefixes that are another PEC: PEC A A subset of prefixes, which affects PECA The forwarding behavior of packets with the prefix is ​​determined by the IP address space. To this end, the entire IP address space is modeled as an n-bit integer, called mixed-symbol IP, where n represents the number of all PECs and each bit corresponds to a PEC. For example, in Figure 5 In the mixed symbol IP, it can be represented as a 3-bit integer, with the nth bit corresponding to PEC n+1 Then, the mixed-symbol IP address space guided by a PEC can be represented as an n-bit integer with the bits corresponding to the PEC and its sub-PECs set to 1 and the remaining bits set to 0. And any IP can be represented as an n-bit integer with every bit set to 1. For example, in Figure 5 In b, the mixed-symbol IP address space directed by PEC1 is represented as 001. Since PEC1 is a child PEC of PEC2, the mixed-symbol IP address space directed by PEC2 is represented as 011, which means that PEC2 can direct the forwarding of IP packets with its own prefix and the prefix of PEC1. Therefore, prefix matching can be completed by bit operations of integers.

[0075] The basic mixed-sign packet is defined as a two-tuple (concolicIP, AC∩TC), where the mixed-sign IP is the n-bit integer defined above, representing the destination IP, and AC∩TC is a symbolic formula that captures the routing announcements and topological conditions under which the packet is forwarded. Other attributes, such as port and source IP, can be added to this two-tuple as specific values ​​to obtain the data plane by forwarding the mixed-sign packet in the network.

[0076] To further generate the hybrid symbol FIB, first generate a FIB (forwarding table) for each router, which is a list of forwarding rules. Each forwarding rule is a triple (PEC, AC∩TC, port), where AC∩TC comes from the route that generates the rule. For example, in Figure 5 In b, there are three rules in the initial FIB of router B ( arrive ). Then, the FIB is simplified by merging multiple forwarding rules with the same PEC and port into one rule, whose AC∩TC is the disjunction of the AC∩TC of all the rules to be merged. The PEC is then converted into a mixed-symbol IP address space guided by it, called the forwarding representation of the PEC (FPEC). In this way, each rule is converted into a triple (FPEC, PC, port). Figure 5 As shown, the rules is from However, due to the longest prefix matching mechanism, this FIB cannot be directly used to guide the forwarding of mixed symbol packets. Figure 5 As shown in b, only When it becomes invalid, the mixed symbolic IP packet represented as binary 001 will be This is because PEC1 (192.0.0.0 / 2,3-32) contains the sub-prefix of PEC2 (192.0.0.0 / 2,2), and the data packet with the destination IP such as 192.0.0.1 will be forwarded according to the rule with the longest prefix. In the mixed-symbol FIB, this is represented by the FPEC of the rules containing the same bit, for example, the zeroth bit of FPEC1 and FPEC2 are both 1. Therefore, before the packet is forwarded, the "effective" FIB is calculated first: for both rules f A (FPEC A ,PC A ,port A ) and f B (FPEC B ,PC B ,port B ), where FPEC A and FPEC B have the same position and f A Priority over f B , f B Will be updated to two rules: and rule2((~FPEC A )&FPEC B ,PC B ,port B ).like Figure 5 As shown in b, Updated to and Indicates that the mixed symbol IP represents a packet of 001 only It will be forwarded to port1 only when it is not feasible. Indicates that the packet has a PEC2 prefix but is not under the PEC1 prefix. As long as link AB is connected and will still be forwarded to port1. Therefore, when the mixed-symbol packet pkt arrives, we can determine which part of the packet can be forwarded by each rule by performing a bitwise AND operation on the mixed-symbol IP of the packet and the FPEC of the rule, and then performing a logical AND operation on their AC and TC. In addition, the embodiment of the present application further simplifies the "effective" FIB by merging multiple forwarding rules with the same FPEC and port into one rule, generating the final mixed-symbol FIB, such as Figure 5 b The final mixed symbol FIB of B is shown.

[0077] Further forwarding of mixed symbol packets: First construct a mixed symbol packet with the destination IP set to any mixed symbol IP (each bit is set to 1), the routing announcement condition and the topology condition set to True, and inject it into each router. When the router receives the mixed symbol packet, it first performs a bitwise AND operation on the mixed symbol IP of the packet and the FPEC of each rule. If the result is not zero, it then performs a logical AND operation on their routing announcement conditions and topology conditions. If the result of the logical operation is not False, the packet will be forwarded through the corresponding port. This process will continue until the mixed symbol IP is zero or the routing announcement condition and the topology condition of the packet are False. Eventually, on each router, there will be a set of received mixed symbol packets, containing information about the scenarios in which they can reach the router. For example, on Figure 5 c, when the mixed-sign packet pkt(111,True) arrives at router B, it will be forwarded to each forwarding rule ( arrive ) to perform intersection operation. Finally, and will be forwarded to port2. and pkt2(010,l AB ) will be forwarded to port1.

[0078] In step S103, it is determined whether the forwarding behavior of the network meets the intention of the network administrator according to the forwarding result.

[0079] Optionally, in some embodiments, judging whether the forwarding behavior of the network complies with the intention of the network administrator based on the forwarding result also includes: extracting attribute-related data packets corresponding to the data packets based on the attributes to be verified, and judging whether the forwarding behavior of the network complies with the intention of the network administrator under any environment based on the attribute-related data packets; if the attribute-related data packets do not comply with the intention of the network administrator, all erroneous forwarding behaviors that caused the intention of the network administrator to be violated are returned so that the network administrator can correct the erroneous configuration.

[0080] Specifically, attribute-related packets are extracted: First, Packets(s, d, p) are extracted, which represents the mixed symbolic packets with prefix p sent from s to d. Specifically, the embodiment of the present application uses the corresponding PEC to convert prefix p into its corresponding mixed symbolic IP, represented as CIP p Extract all packets P received by node d with source IP address s. Finally, return those packets in P that are related to CIP p packets with non-zero intersection. For example, Figure 5In c, since the mixed symbolic data packets are only injected into router B, Packets (B, A, 192.0.0.0 / 2) is a set containing pkt1 and pkt2.

[0081] Generate scenario predicate: Before validating the property, precompute the scenariopredicate for validation, which is a symbolic formula that represents the external advertisement and failure scenarios that need to satisfy the property. For example, in Figure 5 In the network in c, if the operator wants to verify the property under various external announcement scenarios without link failure, the scenario predicate sp can be set to l AB l BC ∧Ture.

[0082] Verification properties: ConVer can mainly verify the following four properties. The verification of other properties is similar: (i) Reachability (s, d, p): packets from prefix p under s can reach d; (ii) Isolation (s, d, p): packets from prefix p under s can never reach d; (iii) Waypointing (s, d, w, p): packets from prefix p under s can reach d through router w; (iv) Neighbor Preference (s, n1, n2, p): router s always prefers to reach prefix p through external neighbor n1 rather than n2.

[0083] The embodiment of the present application mainly demonstrates how to perform reachability verification. The verification is divided into two steps: (1) verifying whether the data packets that can reach d meet the constraints of the scenario; (2) verifying whether there are data packets that cannot reach d under prefix p. In the first step, for each data packet in Packets(s, d, p), its advertisement and topological conditions are concatenated with sp. If the result is equal to sp, the data packet meets the reachability property in the corresponding scenario. Otherwise, the data packet is returned as a counterexample. For example, in Figure 5 c, if the operator verifies the reachability between router B and router A using the scenario predicate sp calculated above. Then the result of pkt1.(ac∧tc)∧sp is equal to This means that pkt1 can reach router A only when the network receives a specific external route announcement, so it violates this property. In the second step, if the mixed symbolic IP space of prefix p is equal to the result of the bitwise OR operation of all mixed symbolic IPs in the packet, then all packets sent by s belonging to prefix p can successfully reach d. Otherwise, the missing IP space is calculated by comparing the IP space of p with the IP space of the packet, and the result is returned as a counterexample. For example, in Figure 5In c, if router B only receives pkt2, it means that the data packet from C with the IP address with the PEC2 prefix cannot successfully reach B.

[0084] The embodiment of the present application implements ConVer using Java, using BDDs in the JDD library to operate symbolic variables and formulas. Currently, ConVer supports BGP, ISIS, static routing, and simplified EVPN. All evaluations were run on a Linux server equipped with an AMD EPYC7402 24-core processor and 128G memory.

[0085] During the application of the embodiment, the embodiment of the present application has been running ConVer on FITI for two years. FITI is a national science and technology Internet infrastructure project consisting of 240 routers. FITI uses protocols such as BGP, ISIS and EVPN to divide the entire underlying network into 4096 different virtual overlay networks, and each virtual network is called a slice. The routers in FITI have two main roles: border routers and core routers. The former has about 130,000 lines of configuration each, and the latter has more than 1,000 lines of commands each.

[0086] Over the past two years, ConVer has found 51 violations of properties in FITI, including 25 violations of reachability, 5 violations of heading location, and 21 violations of new properties. Most of the reachability and waypoint violations were caused by external route announcements. For example, FITI's border routers were not initially configured with an inbound routing policy to filter external route announcements with FITI subprefixes, causing traffic in FITI to be directed to external networks. ConVer found violations of new properties including

[0087] Slice Isolation: In FITI, users connected to different slices should not be able to connect to each other. ConVer verifies this property by importing all possible external route announcements at the slice access point of the border router. During the verification process, ConVer found two violations: (1) Users in slice A can reach user 1 who accesses slice B through border router R, while users entering slice B from different border routers can also reach user 1. (2) Users in slice A can reach user 1 who connects to slice B through border router R, while users entering slice B from different border routers cannot reach user 1. ConVer returned all packets with incorrect forwarding behavior and corresponding scenario information as counterexamples. Based on the feedback information, the FITI operator successfully identified the errors in the configuration: (1) There was an error in the specific prefix filtering policy for slice A on router R, which resulted in the incorrect import of routes belonging to slice B into slice A; (2) The second violation was caused by the incorrect configuration of router R, where the vpn-target of slice B was incorrectly set to the vpn-target of slice A. This incorrect configuration prevented other users in slice B from accessing user 1.

[0088] Community attribute privacy: In FITI, the isolation between slices and the enforcement of many routing policies are achieved through the use of (extended) community attributes. Therefore, FITI strives to protect specific community attribute values ​​from being propagated to external neighbors, as these values ​​may leak sensitive information. ConVer verified this property by checking the route announcements that FITI publishes to external neighbors. During the verification process, ConVer discovered an error: the border router A propagated route announcements containing the sensitive community attribute c to its external neighbors. In addition, these route announcements always specified prefix p as the destination. Through feedback, the operator discovered that there was a routing policy associated with prefix p on router A, but it lacked the configuration command to discard the community attribute value c, which was the root cause of the error.

[0089] The scalability of ConVer is evaluated on a set of synthetic WANs of varying sizes and with varying degrees of routing strategy complexity. In addition, it is evaluated on a set of synthetic fat-tree networks, such as Figure 6 shown.

[0090] Verification performance under different external route announcement scenarios: ConVer's ability to check full-pair reachability under various external advertisement scenarios was first evaluated on a synthetic wide area network, and the embodiments of the present application compared it with Minesweeper (Minesweeper is the only verifier with this capability).

[0091] The running time of ConVer when verifying networks with different numbers of external neighbors is analyzed in detail. Figure 7 As shown in Figure 1, each WAN connects n external neighbors (ranging from 1 to 5), and ConVer is always 100 times faster than Minesweeper. As the number of external neighbors increases, the running time of ConVer increases slightly. This is because the experimental WAN does not configure an inbound routing policy for external route announcements, and each external neighbor has the potential to hijack the traffic of the internal network. ConVer looks for all violations caused by all possible external route announcements and returns them as counterexamples to help fix the errors. Therefore, the more external neighbors there are, the larger the exploration space of ConVer is and the longer the running time is. Minesweeper's running time remains stable because it stops immediately once a violation is found. When verifying the above WAN, Minesweeper usually only considers the impact of one external neighbor possibly hijacking traffic and returns a corresponding counterexample. But this also means that when network operators want to find all errors, they must fix the current errors and then re-run Minesweeper for further verification. However, using ConVer does not require such a repeated process.

[0092] Then, the performance of ConVer was evaluated when verifying networks with routing policies of different complexity. Routing policies include internal routing policies and external neighbor policies. The WAN is connected to three external neighbors, and different inbound routing policies of different complexity are configured for each external neighbor, so that the border router can filter different proportions (ranging from 10% to 90%) of external route announcements carrying internal network sub-prefixes. Figure 7 As shown in (b), the running time of ConVer decreases as the percentage increases, and it is still 100 times faster than Minesweeper.

[0093] In addition, the performance of ConVer and Minesweeper in discovering network-specific errors is compared. To this end, each WAN is connected to three external neighbors and configured with different numbers of specific errors (ranging from 1 to 5) that are triggered by specific external route announcements, such as route announcements with specific prefix and community attributes. Figure 7 As shown in (c), ConVer consistently outperforms Minesweeper by a factor of 100, and the running time of ConVer does not increase significantly as the number of specific errors increases.

[0094] Verification performance under different link failure scenarios: ConVer is evaluated against other state-of-the-art open source verifiers by examining full-pair reachability under failure conditions on synthetic WAN and fat-tree networks, such as Figure 8As shown in Figure 2, ConVer is consistently 10 times faster than other validators in wide area networks. In fat tree networks, ConVer outperforms Tiramisu and is 100 times faster than Minesweeper and Batfish. In addition, ConVer’s performance is evaluated when validating large networks, such as Fig. 9 As shown, ConVer can complete the verification of a network with 180 nodes in 1000 seconds with at most one link failure.

[0095] Performance of finding faults: We evaluate the performance of ConVer and Minesweeper in finding faults caused by specific external route announcements and link failures. Each network is connected to three external neighbors and configured with five faults that can only cause unreachability if it simultaneously receives specific external route announcements and suffers k link failures. We then use ConVer and Minesweeper to check the reachability of all network pairs and find these faults. Fig.10 As shown in Figure 1, when k is 0 / 1, ConVer is 100 times faster than Minesweeper. When k is 2 / 3, ConVer is 10 times faster than Minesweeper. However, as k increases, ConVer's runtime decreases further (halved when k=4), while Minesweeper's runtime remains relatively stable. This is because as k increases, our optimizations (routing and prefix pruning) become more and more effective, thus reducing runtime.

[0096] In the embodiment of the present application, by proposing hybrid symbolic routing and using it for hybrid symbolic simulation, the impact of any external routing declaration and any link status on the network is effectively explored, thereby effectively reflecting all potential errors in the network configuration; in the process of hybrid symbolic simulation, the impact of the data plane ACL, sub-prefix routing and longest prefix matching on the data plane forwarding is considered; in the actual verification process of the FITI network, several types of network attribute information that have not been discovered before are discovered and proposed, and these attribute information are successfully verified.

[0097] According to the hybrid symbolized routing configuration verification method proposed in the embodiment of the present application, a hybrid symbolized network model is constructed according to the network configuration, the control plane behavior of the network in any environment is inferred using the hybrid symbolized network model, and the forwarding behavior of the network in any environment is inferred based on the control plane behavior, and whether the forwarding behavior of the network meets the intention of the network administrator is judged based on the forwarding result. Thus, the problem that the current routing configuration verification method cannot fully discover errors in the routing configuration while meeting scalability is solved, and the forwarding behavior of the network in any environment can be verified, and potential errors in the configuration can be fully discovered.

[0098] Next, a routing configuration verification device based on hybrid symbolization proposed according to an embodiment of the present application is described with reference to the accompanying drawings.

[0099] Fig.11 It is a block diagram of a routing configuration verification device based on hybrid symbolization according to an embodiment of the present application.

[0100] like Fig.11 As shown, the routing configuration verification device 10 based on hybrid symbolization includes: a construction module 100, a reasoning module 200 and a verification module 300.

[0101] Among them, the construction module 100 is used to construct a hybrid symbolic network model according to the network configuration; the reasoning module 200 is used to use the hybrid symbolic network model to infer the control plane behavior of the network in any environment, and to infer the forwarding behavior of the network in any environment based on the control plane behavior; the verification module 300 is used to determine whether the forwarding behavior of the network is in line with the intention of the network administrator based on the forwarding result.

[0102] Optionally, in some embodiments, the construction module 100 is further used to: determine the protocol running in the network and the corresponding protocol routing; divide the corresponding attribute equivalence classes according to the protocol routing attributes and the corresponding network configuration; and construct a hybrid symbolic network model according to the attribute equivalence classes and the network configuration.

[0103] Optionally, in some embodiments, the reasoning module 200 is also used to: construct corresponding hybrid symbolic protocol routing based on symbolic routing declaration conditions and routing topology conditions, combined with protocol routing attributes represented by equivalence classes; and obtain the control plane behavior of the network in any environment through hybrid symbolic simulation.

[0104] Optionally, in some embodiments, the inference module 200 is also used to: perform mixed symbolic data packet forwarding according to the control plane behavior of the network in any environment, infer the data plane forwarding behavior of the network in any environment, and obtain the data packets received in any environment at each router.

[0105] Optionally, in some embodiments, the verification module 300 is further used to: extract attribute-related data packets corresponding to the data packets according to the attributes to be verified, and determine whether the forwarding behavior of the network complies with the intention of the network administrator under any environment based on the attribute-related data packets; if the attribute-related data packets do not comply with the intention of the network administrator, then return all erroneous forwarding behaviors that caused the intention of the network administrator to be violated, so that the network administrator can correct the erroneous configuration.

[0106] It should be noted that the aforementioned explanation of the embodiment of the route configuration verification method based on hybrid symbolization is also applicable to the route configuration verification device based on hybrid symbolization of this embodiment, and will not be repeated here.

[0107] According to the hybrid symbolized routing configuration verification device proposed in the embodiment of the present application, a hybrid symbolized network model is constructed according to the network configuration, and the control plane behavior of the network in any environment is inferred using the hybrid symbolized network model, and the forwarding behavior of the network in any environment is inferred based on the control plane behavior; and whether the forwarding behavior of the network meets the intention of the network administrator is judged based on the forwarding result. Thus, the problem that the current routing configuration verification method cannot fully discover errors in the routing configuration while meeting scalability is solved, and the forwarding behavior of the network in any environment can be verified, and potential errors in the configuration can be fully discovered.

[0108] Fig.12 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. The electronic device may include:

[0109] A memory 1201 , a processor 1202 , and a computer program stored in the memory 1201 and executable on the processor 1202 .

[0110] When the processor 1202 executes the program, the routing configuration verification method based on hybrid symbolization provided in the above embodiment is implemented.

[0111] Furthermore, the electronic device further comprises:

[0112] The communication interface 1203 is used for communication between the memory 1201 and the processor 1202 .

[0113] The memory 1201 is used to store computer programs that can be executed on the processor 1202 .

[0114] The memory 1201 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory.

[0115] If the memory 1201, the processor 1202 and the communication interface 1203 are implemented independently, the communication interface 1203, the memory 1201 and the processor 1202 can be connected to each other through a bus and communicate with each other. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig.12 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0116] Optionally, in a specific implementation, if the memory 1201, the processor 1202 and the communication interface 1203 are integrated on a chip, the memory 1201, the processor 1202 and the communication interface 1203 can communicate with each other through an internal interface.

[0117] The processor 1202 may be a central processing unit (CPU), or an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application.

[0118] The embodiment of the present application also provides a computer program product, on which a computer program is stored, and when the program is executed by a processor, the above-mentioned hybrid symbolization-based routing configuration verification method is implemented.

[0119] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or N embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, without contradiction.

[0120] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of the features. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise clearly and specifically defined.

[0121] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, fragment or portion of code comprising one or more executable instructions for implementing the steps of a custom logical function or process, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in reverse order depending on the functions involved, which should be understood by technicians in the technical field to which the embodiments of the present application belong.

[0122] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing logical functions, and can be embodied in any computer program product for use with an instruction execution system, device or apparatus (such as a computer-based system, a system including a processor, or other system that can fetch instructions from an instruction execution system, device or apparatus and execute instructions), or in combination with these instruction execution systems, devices or apparatuses. For the purposes of this specification, a "computer program product" can be any device that can contain, store, communicate, propagate or transmit a program for use with an instruction execution system, device or apparatus, or in combination with these instruction execution systems, devices or apparatuses. More specific examples of computer program products (a non-exhaustive list) include the following: an electrical connection with one or N wirings (electronic device), a portable computer disk case (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable and programmable read-only memory (EPROM or flash memory), a fiber optic device, and a portable compact disk read-only memory (CDROM). Furthermore, the computer program product may even be paper or other suitable medium on which the program is printed, since the program may be obtained electronically, for example by optically scanning the paper or other medium and then editing, interpreting or, if necessary, processing in another suitable manner, and then storing it in a computer memory.

[0123] It should be understood that the various parts of the present application can be implemented by hardware, software, firmware or a combination thereof. In the above-mentioned embodiment, the N steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function for a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0124] A person skilled in the art may understand that all or part of the steps in the method for implementing the above-mentioned embodiment may be completed by instructing related hardware through a program, and the program may be stored in a computer program product, which, when executed, includes one or a combination of the steps of the method embodiment.

[0125] In addition, each functional unit in each embodiment of the present application may be integrated into a processing module, or each unit may exist physically separately, or two or more units may be integrated into one module. The above-mentioned integrated module may be implemented in the form of hardware or in the form of a software functional module. If the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it may also be stored in a computer program product.

[0126] The computer program product mentioned above may be a read-only memory, a disk or an optical disk, etc. Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and cannot be understood as limiting the present application. A person of ordinary skill in the art may change, modify, replace and modify the above embodiments within the scope of the present application.

Claims

1. A routing configuration verification method based on hybrid symbolization, characterized in that: The following steps are involved: Construct a hybrid symbolic network model based on the network configuration; Inferring the control plane behavior of the network in any environment using the hybrid symbolic network model, and inferring the forwarding behavior of the network in any environment based on the control plane behavior; It is determined whether the forwarding behavior of the network is consistent with the intention of the network administrator based on the forwarding result.

2. The method according to claim 1, characterized in that The construction of the hybrid symbolic network model includes: Determine the protocols running in the network and the corresponding protocol routes; According to the protocol routing attributes and the corresponding network configuration, the corresponding attribute equivalence classes are divided; The hybrid symbolic network model is constructed according to the attribute equivalence class and the network configuration.

3. The method according to claim 1, characterized in that The use of a hybrid symbolic network model to infer the control plane behavior of a network in any environment includes: According to the symbolic routing announcement conditions and routing topology conditions, combined with the protocol routing attributes represented by the equivalence class, the corresponding hybrid symbolic protocol routing is constructed; The control plane behavior of the network in any environment is obtained through hybrid symbolic simulation.

4. The method according to claim 1, characterized in that: The inference of the forwarding behavior of the network in any environment based on the control plane behavior includes: According to the control plane behavior of the network in any environment, hybrid symbolic data packet forwarding is performed, the data plane forwarding behavior of the network in any environment is inferred, and the data packets received in any environment are obtained at each router.

5. The method according to claim 4, characterized in that The determining, according to the forwarding result, whether the forwarding behavior of the network complies with the intention of the network administrator further includes: Extracting attribute-related data packets corresponding to the data packets according to the attributes to be verified, and judging whether the forwarding behavior of the network meets the intention of the network administrator under any environment according to the attribute-related data packets; If the attribute-related data packet does not conform to the intention of the network administrator, all erroneous forwarding behaviors that cause the intention of the network administrator to be violated are returned so that the network administrator can correct the erroneous configuration.

6. A routing configuration verification device based on hybrid symbolization, characterized in that: include A construction module, used to construct a hybrid symbolic network model according to the network configuration; An inference module, used to infer the control plane behavior of the network in any environment using the hybrid symbolic network model, and to infer the forwarding behavior of the network in any environment based on the control plane behavior; The verification module is used to determine whether the forwarding behavior of the network is consistent with the intention of the network administrator based on the forwarding result.

7. The device according to claim 6, characterized in that The building blocks are also used to: Determine the protocols running in the network and the corresponding protocol routes; According to the protocol routing attributes and the corresponding network configuration, the corresponding attribute equivalence classes are divided; Construct a hybrid symbolic network model for a network based on attribute equivalence classes and network configurations.

8. The device according to claim 6, characterized in that The reasoning module is further used for: According to the symbolic routing announcement conditions and routing topology conditions, combined with the protocol routing attributes represented by the equivalence class, the corresponding hybrid symbolic protocol routing is constructed; The control plane behavior of the network in any environment is obtained through hybrid symbolic simulation.

9. The device according to claim 6, characterized in that The reasoning module is further used for: According to the control plane behavior of the network in any environment, hybrid symbolic data packet forwarding is performed, the data plane forwarding behavior of the network in any environment is inferred, and the data packets received in any environment are obtained at each router.

10. The device according to claim 9, characterized in that The verification module is further used for: Extracting attribute-related data packets corresponding to the data packets according to the attributes to be verified, and judging whether the forwarding behavior of the network meets the intention of the network administrator under any environment according to the attribute-related data packets; If the attribute-related data packet does not conform to the intention of the network administrator, all erroneous forwarding behaviors that cause the intention of the network administrator to be violated are returned so that the network administrator can correct the erroneous configuration.

11. An electronic device, characterized in that: include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the hybrid symbolization-based routing configuration verification method according to any one of claims 1 to 5.

Images