A method, apparatus, and electronic device for route configuration verification based on hybrid symbolization

Abstract

This application relates to the field of computer network technology, and in particular to a method, apparatus, and electronic device for verifying routing configurations based on hybrid symbolic representation. The method includes: constructing a hybrid symbolic network model based on 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; and determining whether the network's forwarding behavior conforms to the network administrator's intentions based on the forwarding results. This solves the problem that current routing configuration verification methods cannot fully detect errors in routing configurations while maintaining scalability, and can verify the forwarding behavior of the network in any environment, fully discovering potential errors in the configuration.

Description

Technical Field

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

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

[0003] Configuring the control plane is a challenging task because router configuration languages ​​provide only low-level abstractions, and the configured network must meet its design intent (e.g., blocking certain flows and allowing others) even when link or router states are unpredictable. Therefore, router configuration is prone to errors that can lead to 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 network administrator's intentions and security requirements. However, router configuration verification faces many challenges: First, the scale of actual application networks is very large, each router has many configuration commands, and the protocols running on them are numerous and complex, making it difficult to accurately infer the network's forwarding behavior based on the configuration. Second, a wide area network is a distributed system where each router exchanges information with each other and eventually converges to form a routing table. Different routers influence each other, and it is difficult to determine which routers' forwarding behavior is specifically affected after changing a configuration. Third, the state space of the entire network is very large, and the network state is constantly changing with the changes in the network environment (network link state, external route advertisements received by the network). Some errors are only triggered under specific conditions and under specific states.

[0005] Currently, route configuration verification methods are mainly divided into two categories: data plane verification and control plane verification. Existing control plane verification work can be divided into three categories: (1) Single-environment verification: These methods take network configuration and specific environment as input, simulate the resulting network behavior, and generate the expected data plane. This requires them to re-simulate the control plane in each environment, resulting in poor scalability. (2) Multi-environment verification: These methods build formal network models or graph-based models, which can analyze multiple environments simultaneously. Although these tools are specially 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 (e.g., environments containing all possible eBGP route announcements). Therefore, even if the configuration passes verification, there is still a possibility of undetected errors. (3) Arbitrary Environment Validation: This type of method provides a powerful ability to validate networks in any environment by encoding the network into a large logical formula and solving it. However, they have poor scalability because attempting to solve this complex formula, even with the most advanced SMT solvers, has proven impractical.

[0006] Therefore, scalably validating configurations and fully discovering potential errors in configurations in any environment remains an open question. Summary of the Invention

[0007] This application provides a routing configuration verification method, apparatus, and electronic device based on hybrid symbolization to solve the problem that current routing configuration verification methods cannot fully detect errors in routing configuration while satisfying scalability.

[0008] The first aspect of this application provides a routing configuration verification method based on hybrid symbolization, comprising the following steps: constructing a hybrid symbolized network model according to network configuration; using the hybrid symbolized 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; and determining whether the forwarding behavior of the network conforms to the intention of the network administrator based on the forwarding results.

[0009] Optionally, constructing the hybrid symbolic network model includes: determining the protocols running in the network and their corresponding protocol routes; dividing the network into corresponding attribute equivalence classes based on the protocol route attributes and the corresponding network configuration; and constructing the hybrid symbolic network model for the network based on the attribute equivalence classes and the network configuration.

[0010] Optionally, the step of using a hybrid symbolic network model to infer the control plane behavior of the network in any environment includes: constructing a corresponding hybrid symbolic protocol route based on symbolic route declaration conditions and route topology conditions, combined 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, the step of inferring the forwarding behavior of the network in any environment based on the control plane behavior includes: performing hybrid 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, the step of determining whether the forwarding behavior of the network conforms to the network administrator's intent based on the forwarding result further includes: extracting attribute-related data packets corresponding to the data packets based on the attributes to be verified, and determining whether the forwarding behavior of the network conforms to the network administrator's intent in any environment based on the attribute-related data packets; if the attribute-related data packets do not conform to the network administrator's intent, then returning all erroneous forwarding behaviors that caused the network administrator's intent to be violated, so that the network administrator can correct the misconfiguration.

[0013] A second aspect of this application provides a routing configuration verification device based on hybrid symbolization, comprising: a construction module for constructing a hybrid symbolized network model according to network configuration; an inference module for inferring the control plane behavior of the network in any environment using the hybrid symbolized network model, and inferring the forwarding behavior of the network in any environment based on the control plane behavior; and a verification module for determining whether the forwarding behavior of the network conforms to the intention of the network administrator based on the forwarding results.

[0014] Optionally, the construction module is further configured to: determine the protocols running in the network and the corresponding protocol routes; divide the corresponding attribute equivalence classes according to the protocol route 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 further configured to: construct a corresponding hybrid symbolic protocol route based on the symbolic route declaration conditions and route topology conditions, combined with the protocol route 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 configured to: perform hybrid symbolic data packet forwarding based on 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 further configured to: extract attribute-related data packets corresponding to the data packets based on the attributes to be verified, and determine whether the forwarding behavior of the network conforms to the network administrator's intent in any environment based on the attribute-related data packets; if the attribute-related data packets do not conform to the network administrator's intent, then return all erroneous forwarding behaviors that cause the network administrator's intent to be violated, so that the network administrator can correct the misconfiguration.

[0018] A third aspect of this 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 embodiments.

[0019] A fourth aspect of this application provides a computer program product having a computer program stored thereon, which is executed by a processor to implement the hybrid symbolization-based routing configuration verification method as described in the above embodiments.

[0020] In the above implementation, a hybrid symbolic network model is constructed based on the network configuration. This model is then used to infer the network's control plane behavior in any environment, and the forwarding behavior is inferred from the control plane behavior. Finally, the forwarding results are used to determine whether the network's forwarding behavior aligns with the network administrator's intentions. This solves the problem that current route configuration verification methods cannot adequately detect errors in route configuration while maintaining scalability. It enables the verification of network forwarding behavior in any environment and fully identifies potential errors in the configuration.

[0021] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

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

[0023] Figure 1 This is a flowchart of a route configuration verification method based on hybrid symbolization provided in an embodiment of this application;

[0024] Figure 2 This is a schematic diagram of the ConVer verifier system architecture according to an embodiment of this application;

[0025] Figure 3 This is a schematic diagram of prefix equivalence class partitioning according to an embodiment of this application;

[0026] Figure 4This is a schematic diagram of a group attribute configuration segment according to one embodiment of this application;

[0027] Figure 5 This is a schematic diagram of hybrid symbolic routing calculation and packet forwarding according to an embodiment of this application;

[0028] Figure 6 This is a schematic diagram of a synthetic network dataset according to an embodiment of this application;

[0029] Figure 7 This is a schematic diagram illustrating the accessibility attribute verification time under different conditions according to an embodiment of this application;

[0030] Figure 8 This is a schematic diagram illustrating the verification time under different link failure scenarios according to an embodiment of this application;

[0031] Figure 9 This is a schematic diagram illustrating the variation of verification time under different network sizes according to an embodiment of this application;

[0032] Figure 10 This is a schematic diagram illustrating the reachability verification time under different types of errors according to an embodiment of this application;

[0033] Figure 11 This is an example diagram of a route configuration verification device based on hybrid symbolization according to an embodiment of this application;

[0034] Figure 12 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

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

[0036] The following description, with reference to the accompanying drawings, describes a routing configuration verification method, apparatus, and electronic device based on hybrid symbolization according to embodiments of this application. Addressing the problem mentioned in the background art that current routing configuration verification methods cannot adequately detect errors in routing configuration while maintaining scalability, this application provides a routing configuration verification method based on hybrid symbolization. In this method, a hybrid symbolized network model is constructed based on the network configuration. The hybrid symbolized network model is used to infer the control plane behavior of the network in any environment, and the forwarding behavior of the network in any environment is inferred based on the control plane behavior. The forwarding results are used to determine whether the network's forwarding behavior conforms to the network administrator's intentions. Therefore, this solves the problem that current routing configuration verification methods cannot adequately detect errors in routing configuration while maintaining scalability, enabling scalable verification of configurations in any environment and fully detecting potential errors in the configuration.

[0037] Specifically, Figure 1 This is a flowchart illustrating a route configuration verification method based on hybrid symbolization provided in an embodiment of this application.

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

[0039] In step S101, a hybrid symbolic network model is constructed based on 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 protocols running in the network and their corresponding protocol routes; dividing the network into corresponding attribute equivalence classes based on the protocol route attributes and the corresponding network configuration; and constructing the hybrid symbolic network model based on the attribute equivalence classes and the network configuration.

[0042] Optionally, in some embodiments, the control plane behavior of the network in any environment is inferred using a hybrid symbolic network model, including: constructing a corresponding hybrid symbolic protocol route based on symbolic route declaration conditions and route topology conditions, combined 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] This application proposes a hybrid symbolic routing configuration verification method, ConVer, which can scalably verify configurations in any network environment, thereby discovering all potential errors in the configuration. This application specifically includes two parts: (1) constructing a hybrid symbolic network model and performing hybrid symbolic routing calculations; (2) exploring the hybrid symbolic model and verifying whether the network's forwarding behavior in any environment conforms to the network administrator's intentions, such as... Figure 2 As shown.

[0044] When constructing a hybrid symbolic network model, it is necessary to perform attribute equivalence class partitioning for each routing attribute in the network.

[0045] The attribute equivalence class captures the value set of each route attribute. For each route declaration carrying an attribute value from this value set, the routing policy will process it in the same way, as defined below.

[0046] Define an Attribute Equivalence Class (AEC) for a given set of routing policies P, a set of route advertisements R, a route attribute A, and a possible value v for A. Let r(A,v) represent the route advertisement obtained by updating the value of attribute A of route advertisement r to v. 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 condition is satisfied:

[0047]

[0048] Since external route advertisements are typically propagated via the BGP protocol, and some attributes are not propagated with route advertisements, we only need to perform AEC partitioning on a few BGP attributes. The following uses prefix and community as examples to illustrate how to perform AEC partitioning on different categories of route attributes.

[0049] Property equivalence classes include prefix equivalence classes and community property equivalence classes.

[0050] The Prefix Equivalence Class (PEC) differs from other attributes in that a prefix comprises two components: the IP address and the mask length, which together represent the destination prefix. Therefore, the PEC is stored as a set of prefix tuples in the form (IP, ML). For IPv4 (IPv6), IP is a 32-bit (128-bit) signed variable representing all possible IP addresses in the prefix. ML (mask length) is a 32-bit (128-bit) unsigned integer value, where each 1 indicates a possible length. For example, a PEC with the prefix (192.0.0.0 / 2, 2) can be represented as (p1p2, 2). 1 ), where p1p2 represents the first and second sign variables of IP, and 2 1 This indicates that only the second bit of the mask length is set to 1. A PEC containing any prefix can be represented as a set of tuples, where IP is set to the symbol value True, and every 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 entire prefix space is divided into disjoint PECs using the AND and NOT operations of PEC, such as... Figure 3The algorithm is shown below. First, all prefixes are extracted from the configuration (line 1), including any advertised (explicit or automatic) prefixes, prefixes appearing in routing policies, prefixes in static routes, etc. Then, they are converted into initial PECs of the form described above (line 2). Next, a final PEC set is constructed to store the partitioned PECs, and PECs containing arbitrary prefixes are added to it (line 3). Then, each PEC from the initial PECs is added to the final PEC set in turn (lines 4 to 16). When initial PEC: PEC init When added to the final PEC collection, it will be in the PEC init And each PEC in the final set: PEC final Perform a PEC AND operation between them (line 6). If the result is not empty (line 7), PEC... final It 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 to the final PEC set. Furthermore, PEC... init Will be updated to AND PEC (PEC final NOT PEC (PEC init The result of )) is processed consecutively with the next PEC (line 10). Otherwise, PEC init It will be processed directly along with the next PEC in the final set. Finally, if the PEC... init If it is not empty, it will be added to the final PEC set (lines 13-15). This process will repeat until all PECs have been processed. Finally, the PEC set will be complete. final It includes all disjoint PECs in the network.

[0056] To partition the Community Equivalence Class (CEC), we first extract all community attribute tags appearing in the routing policies from the configuration. Then, we assign a symbolic variable v to each community attribute tag 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 represented as a symbolic formula composed of the above symbolic variables. For example, for Figure 4 The configuration fragments in the file allocate symbolic variables v1 and v2 in a 1:1 and 2:2 ratio, respectively.

[0057] Furthermore, the actual symbolic community attribute set for each policy operation is identified. A routing policy consists of a series of Match-Action rules with different priorities, where each Match-Action rule is considered an operation. A low-priority operation is executed only if a high-priority operation does not match. Therefore, the actual symbolic community attribute set matched by a low-priority operation is the conjunction of the negation of its matched community attribute set and the community attribute set matched by the high-priority operation. For example, for Figure 4 In the configuration snippet, the actual symbolic community attribute set matched by the first operation of routing policy P1 can be represented as v1, while the symbolic community attribute set matched by the second operation can be represented as v1. In this way, for each routing policy, a set C of actual symbolic community attributes can be derived, which includes the actual symbolic community attribute set matched by each operation in the policy.

[0058] Then, based on the set C of each routing policy derived above, the entire community attribute set space is partitioned into disjoint equivalence classes. Specifically, a CEC set S is constructed and an initial CEC with a boolean value of True is added to it, representing all possible community attribute sets. Then, the set C of each routing policy is traversed, and each symbolized community attribute set c in set C is joined with each CEC: cec in S. If the result is not False, cec is further partitioned into two new equivalence classes: (i) cec∧c; Replace `cec` with these two equivalent classes. Additionally, update `c` to `c`. Then perform 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 have been processed. Finally, S will be the final set of all disjoint CECs partitioned by the configuration. For example, for Figure 4 The configuration snippet in the v1 and If the conjunction of is False, the final CEC set S derived from the configuration includes: and for Figure 5 The network shown will divide the community attribute set space 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 advertisement conditions, we first define the route advertisement existence variable. Each route advertisement existence variable is 'a'. n It is a Boolean variable, where a n=1 (True) / 0 (False) indicates whether the network has received an external routing advertisement. n In this application embodiment, a route advertisement existence variable is assigned to each external route advertisement. For example, in... Figure 5 In variable 'a', a1 is a variable assigned to the external route advertisement e1 from neighbor E. Furthermore, for route advertisements originating from the internal network, we directly assign them a boolean value True, indicating that they are always advertised. The route advertisement condition ac is determined by the existence of the route advertisement variable 'a'. n The symbolic formula represents the combinations of external route advertisements received by the network. Each route r is associated with an ac, indicating the scenario under which route r is selected. For example, in Figure 5 In the symbolic routing information database of router C shown in Figure a, route r3 will only become the best route if router C does not receive an external route advertisement e1 from its external neighbor E.

[0060] The routing topology condition tc is a condition determined by the link state variable l x The symbolic formula composed of l x =1 (True) / 0 (False) indicates whether link x is available. The tc associated with each route r indicates the failure condition under which route r is selected. For example, in... Figure 5 In the symbolic RIB of router B shown in diagram a, the topology condition for 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 advertisements 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 represent the corresponding AECs, indicating the various possible values ​​of these attributes in external route advertisements. Furthermore, AC (Administrative Distance) and LP (Local Priority) are modeled as concrete values ​​because they are the default values ​​in all possible external route advertisements. Additionally, Nexthop is also modeled as a concrete value because it is always determined by the receiving neighbor. ASPath is modeled as a set of AS numbers. ExternalASPathSize, a new attribute introduced by ConVer, is represented as a range of integer lower and upper bounds indicating the possible length of the external AS path traversed by the route. AC∩TC is a combination of route advertisement conditions and topology conditions.

[0063] Then, all possible external route advertisements can be modeled as a set of hybrid symbolic routes. In each hybrid symbolic route, preifx, MED, and Community are initialized using the corresponding AEC combination. ExternalASPathSize is set to a range (0, ∞), representing the length of the external AS path the route advertisement might traverse. The AC for each external route advertisement is initialized using the corresponding route advertisement existence variable assigned to it. TC is set to True. Other properties are set to default values; for example, the LP for external route advertisements is always set to the default value of 100. For example, in... Figure 5 In the network shown in example 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 advertisements 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 as e1 to e4 (e5 to e8) respectively. The AC for each external route advertisement (e1 to e8) is initialized using the corresponding route advertisement existence variables (a1 to a8), and the attribute values ​​of the hybrid symbolic routes from the internal network can be determined through configuration.

[0064] Next, ConVer computes hybrid symbolic routes by simulating a hybrid symbolic control plane model. ConVer first imports all routes from the internal network and all possible external route advertisements received from external neighbors, all of 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 neighboring routers; (2) sort all routes and update their propagation conditions; (3) export routes with updated propagation conditions to neighboring routers.

[0065] Encoding routing strategies: First, routing strategies involving prefix and community attributes are encoded using the corresponding Attribute Equivalence Class (AEC). For example, ... Figure 5 As shown in Figure a, routing policy P1 is encoded to match PEC1 and PEC2. Routing policies P2 and P3 are encoded to match CEC1.

[0066] Importing routes: During the computation of hybrid symbolic routes, each router first imports hybrid symbolic routes from its neighboring routers. In this process, each router filters or modifies routes according to inbound or outbound routing policies. For example, in... Figure 5 In step a, e2 and e4 will be filtered out by the routing policy on port2 of router C, because this policy only allows routes carrying CEC1. Furthermore, the propagation conditions remain unchanged throughout this process.

[0067] Route ordering: When a router receives multiple routes with the same Prefix Equivalence Class (PEC), it orders them by comparing their attributes and updates their route advertisements and topology conditions. For attributes represented as concrete values, their sizes can be directly compared. For attributes represented as Attribute Equivalence Classes (AECs), their priority relationships can be easily determined since different equivalence classes are disjoint. Furthermore, only MED equivalence classes participate in route ordering. Assume there are two MED equivalence classes: MEC1(0,49) and MEC2(50,∞). Clearly, MEC1(0,49) has a higher priority than MEC2(50,∞). The comparison of ExternalASPathSize will be explained in Appendix C.

[0068] After priority sorting, suppose there are n routes r1, r2, ..., r n The priority decreases sequentially. The route advertisement conditions and topology conditions for the k-th route are denoted as r. k .(AC∩TC) is updated by negating the corresponding conditions of all higher priority routes in the merge zone, and is represented as In other words, r only becomes valid when all higher-priority routes fail to meet their route advertisement conditions and topology conditions. kOnly then will they be selected. For example, in Figure 5 In case a, assume route B receives a new route with PEC2 and a local priority of 350. The route advertisement condition and topology condition are r.(AC∩TC)=a9l AB Because of its higher local priority, r has a higher priority than r9.

[0069] Therefore, router B is updated.

[0070] Exporting routes: Each router exports routes whose propagation condition is not False to its neighboring routers. In this process, similar to importing routes, each router filters or modifies these routes according to the corresponding exit route policy. Furthermore, 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 It is the link survival variable of the link between R and N.

[0071] Model generalization: When multiple protocols exist (such as ISIS, OSPF), ConVer first sorts routes based on the administrative distance of different protocols. Then, ConVer considers protocol-specific attributes. ConVer can also be easily extended to support route redistribution, route aggregation, and route dependencies between different protocols.

[0072] Optionally, in some embodiments, inferring the forwarding behavior of the network in any environment based on the control plane behavior includes: performing hybrid symbolic 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 packets received in any environment at each router.

[0073] Furthermore, embodiments of this 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] During the forwarding phase, the entire destination IP address space needs to be modeled first to explore the forwarding behavior of all packets. A simple approach is to model each bit of the IP address as a symbolic variable, which results in 128 variables for IPv6, making prefix matching using symbolic formulas inefficient. Therefore, this application introduces a hybrid symbolic IP address model using PEC (Packet Equivalence Class) to directly model the entire IP address space. When all packets carrying prefixes within a PEC exhibit the same forwarding behavior, that PEC can be directly used to represent the corresponding IP address space. However, some sub-PECs contain prefixes that are part of another PEC: PEC... A A subset of the prefix, which affects those with PECA The forwarding behavior of packets with prefixes. For this purpose, the entire IP address space is modeled as an n-bit integer, called a hybrid symbol IP, where n represents the number of all PECs, and each bit corresponds to one PEC. For example, in... Figure 5 In this context, the hybrid symbol IP can be represented as a 3-bit integer, with the nth bit corresponding to the PEC. n+1 Then, the hybrid symbolic IP address space guided by the PEC can be represented as an n-bit integer, with the bits corresponding to the PEC and its child PECs set to 1, and the remaining bits set to 0. Any IP address can be represented as an n-bit integer, where each bit is set to 1. For example, in... Figure 5 In b, the mixed symbolic IP address space guided by PEC1 is represented as 001. Since PEC1 is a sub-PEC of PEC2, the mixed symbolic IP address space guided by PEC2 is represented as 011. This means that PEC2 can guide the forwarding of IP packets with its own prefix and the PEC1 prefix. Therefore, prefix matching can be accomplished through bitwise operations on integers.

[0075] A basic concolic packet is defined as a tuple (concolicIP, AC∩TC), where the concolic IP is an n-bit integer as defined above, representing the destination IP, and AC∩TC is a symbolic formula that captures the route advertisement and topology conditions for which the packet is forwarded. Other attributes, such as port and source IP, can be added as specific values ​​to this tuple to obtain the data plane by forwarding concolic packets in the network.

[0076] Further, a hybrid symbol FIB is generated. First, a FIB (forwarding table) is generated 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 generated the rule. For example, in Figure 5 In b, router B's initial FIB contains three rules ( arrive Then, the FIB is simplified by merging multiple forwarding rules with the same PEC and port into a single rule. The AC∩TC of this merged rule is the disjunction of the AC∩TCs of all the rules to be merged. Next, the PEC is converted into a hybrid symbolic 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 From It is derived from this. 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 When it becomes invalid, packets whose mixed symbolic IP representation is binary 001 will be processed accordingly. The packet will be forwarded. This is because PEC1 (192.0.0.0 / 2,3-32) contains a subprefix of PEC2 (192.0.0.0 / 2,2), and packets with a destination IP such as 192.0.0.1 will be forwarded according to the rule of the longest prefix. Forwarding is then performed. In the mixed symbol FIB, this means that the FPECs of the rules contain the same bits, for example, the zeroth bit of FPEC1 and FPEC2 is both 1. Therefore, before forwarding the packet, the "valid" FIB is calculated first: for two rules f A (FPEC A PC A ,port A ) and f B (FPEC B PC B ,port B ), among which, FPEC A and FPEC B Having the same bit and f A Priority over f B f B It 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 This indicates that packets with mixed symbol IP representation as 001 are only valid when... It will only be forwarded to port1 if it is not feasible. This indicates that the data packet has the PEC2 prefix but is not under the PEC1 prefix, as long as the link... AB The connection is maintained, and the packet will still be forwarded to port1. Therefore, when the mixed-symbol packet pkt arrives, we can determine which part of the packet each rule can forward 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. Furthermore, this embodiment 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 shows the final mixed symbol FIB of B.

[0077] Further forwarding of hybrid symbol packets: First, a hybrid symbol packet is constructed with a destination IP set to an arbitrary hybrid symbol IP (each bit set to 1), and route advertisement conditions and topology conditions set to True. This packet is then injected into each router. When a router receives a hybrid symbol packet, it first performs a bitwise AND operation on the hybrid 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 route advertisement conditions and topology conditions. If the logical operation result is not False, the packet is forwarded through the corresponding port. This process continues until the hybrid symbol IP is zero or the route advertisement conditions and topology conditions of the packet are False. Ultimately, each router will have a set of received hybrid symbol packets containing scenario information indicating that they can reach that router. For example, in Figure 5 In step c, when the mixed symbol packet pkt(111,True) arrives at router B, it will be compared with each forwarding rule ( arrive Perform an intersection operation. Finally, and The data packet will be forwarded to port2. and pkt2(010,l AB The message will be forwarded to port1.

[0078] In step S103, the forwarding result is used to determine whether the network's forwarding behavior conforms to the network administrator's intention.

[0079] Optionally, in some embodiments, determining whether the network's forwarding behavior conforms to the network administrator's intent based on the forwarding result further includes: extracting attribute-related data packets corresponding to the data packets to be verified, and determining whether the network's forwarding behavior conforms to the network administrator's intent in any environment based on the attribute-related data packets; if the attribute-related data packets do not conform to the network administrator's intent, then returning all erroneous forwarding behaviors that caused the network administrator's intent to be violated, so that the network administrator can correct the misconfiguration.

[0080] Specifically, the attribute-related data packets are extracted as follows: First, Packets(s,d,p) is extracted, representing the mixed symbolic data packets with prefix p sent from s to d. Specifically, in this embodiment, the corresponding PEC is used to convert the 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 the packets in P that match CIP. p Data packets with non-zero intersection. For example, in Figure 5In c, since the mixed symbolic packets are only injected into router B, Packets(B,A,192.0.0.0 / 2) is a set containing pkt1 and pkt2.

[0081] Scenario predicate generation: Before validating attributes, a scenario predicate is pre-computed for validation. It is a symbolic formula representing external advertising and failure scenarios that need to satisfy the attributes. For example, in... Figure 5 In a network like C, if an operator wants to verify attributes in scenarios where various external announcements are received without link failures, the scenario predicate sp can be set to l. AB l BC ∧Ture.

[0082] Verification Attributes: ConVer can primarily verify the following four attributes, with other attributes verified similarly: (i) Reachability(s,d,p): Packets from the prefix p of s can reach d; (ii) Isolation(s,d,p): Packets from the prefix p of s can never reach d; (iii) Waypointing(s,d,w,p): Packets from the prefix p of s can reach d through router w; (iv) NeighborPreference(s,n1,n2,p): Router s always prefers to reach the prefix p through its external neighbor n1 rather than n2.

[0083] This application embodiment mainly demonstrates how to perform reachability verification, which consists of two steps: (1) verifying whether data packets that can reach d satisfy the constraints of the scenario; and (2) verifying whether there are data packets that cannot reach d under the prefix p. In the first step, for each data packet in Packets(s,d,p), its advertisement and topology conditions are conjunct with sp. If the result equals sp, then the data packet satisfies the reachability property under the corresponding scenario. Otherwise, the data packet is returned as a counterexample. For example, in Figure 5 In case c, if the operator uses the scenario predicate sp calculated above to verify the reachability between router B and router A, then the result of pkt1.(ac∧tc)∧sp is equal to This indicates that pkt1 can only reach router A if the network receives a specific external route advertisement, thus violating this property. In the second step, if the mixed symbolic IP space of prefix p equals the result of a 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 case c, if router B only receives pkt2, it means that packets from C with IP addresses having the PEC2 prefix cannot successfully reach B.

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

[0085] In the application of this embodiment, ConVer has been running 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, each virtual network being called a slice. The routers in FITI mainly have two roles: border routers and core routers. The former has approximately 130,000 lines of configuration each, while the latter has more than 1,000 lines of commands each.

[0086] Over the past two years, ConVer has identified 51 attribute violations in FITI, including 25 reachability violations, 5 heading / positioning violations, and 21 new attribute violations. Most reachability and waypoint violations were caused by external route advertisements. For example, the FITI border routers were initially not configured with inbound routing policies to filter external route advertisements with FITI sub-prefixes, causing traffic in FITI to be redirected to external networks. ConVer also identified several new attribute violations.

[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 advertisements into 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, and users entering slice B from different border routers can also access user 1. (2) Users in slice A can reach user 1 who connects to slice B through border router R, but users entering slice B from different border routers cannot reach user 1. ConVer returned packets with all erroneous forwarding behaviors and corresponding scenario information as counterexamples. Based on the feedback, 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, causing routes belonging to slice B to be incorrectly imported into slice A; (2) The second violation was caused by a misconfiguration of router R, where the VPN target of slice B was incorrectly set to the VPN target of slice A. This misconfiguration prevented other users in slice B from accessing user 1.

[0088] Community Attribute Privacy: In FITI, fragment isolation and the implementation of numerous 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 ​​could potentially reveal sensitive information. ConVer verified this attribute by examining route advertisements published by FITI to external neighbors. During verification, ConVer discovered an error: border router A propagated route advertisements containing the sensitive community attribute 'c' to its external neighbors. Furthermore, these route advertisements consistently specified prefix 'p' as the destination. Through feedback, the operator discovered that a routing policy associated with prefix 'p' existed 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] ConVer's scalability was evaluated on a range of synthetic wide area networks (WANs) with varying routing policy complexities and scales. Furthermore, it was also evaluated on a set of synthetic fat-tree networks, such as... Figure 6 As shown.

[0090] Verification performance under different external route advertisement scenarios: First, ConVer's ability to check all-pair reachability under various external advertisement scenarios was evaluated on synthetic wide area networks. In this application embodiment, it was compared with Minesweeper (Minesweeper is the only validator with this capability).

[0091] The runtime of ConVer was specifically analyzed when validating networks with different numbers of external neighbors. For example... Figure 7 As shown in diagram a, each WAN connects to n external neighbors (ranging from 1 to 5), and ConVer's speed is consistently 100 times faster than Minesweeper. ConVer's runtime increases slightly with the number of external neighbors. This is because the experimental WAN lacks inbound routing policies configured for external route advertisements, meaning each external neighbor could potentially hijack traffic from the internal network. ConVer searches for all possible violations caused by external route advertisements and returns them as counterexamples to help fix errors. Therefore, the more external neighbors there are, the larger ConVer's exploration space and the longer its runtime. Minesweeper, on the other hand, maintains a stable runtime because it stops immediately upon detecting a violation. When validating the aforementioned WAN, Minesweeper typically only considers the potential impact of one external neighbor hijacking traffic and returns a corresponding counterexample. However, this also means that when network operators want to find all errors, they must fix the current errors and then rerun Minesweeper for further validation. ConVer, however, eliminates this repetitive process.

[0092] The performance of ConVer was then evaluated when validating networks with varying routing policies of different complexity. These policies included internal routing policies and external neighbor policies. The WAN was connected to three external neighbors, each configured with an inbound routing policy of varying complexity, enabling the border router to filter different proportions (ranging from 10% to 90%) of external route advertisements carrying internal network subprefixes. Figure 7 As shown in b, ConVer's runtime decreases as the percentage increases, but it is still 100 times faster than Minesweeper.

[0093] Furthermore, the performance of ConVer and Minesweeper in detecting network-specific errors was compared. For this purpose, each WAN was connected to three external neighbors and configured with varying numbers of specific errors (ranging from 1 to 5), triggered by specific external route advertisements, such as route advertisements with specific prefixes and community attributes. Figure 7 As shown in c, ConVer's performance is consistently 100 times that of Minesweeper, and ConVer's runtime does not increase significantly with the increase of a specific number of errors.

[0094] Verification performance under different link failure scenarios: By examining all-pair reachability under failure conditions in synthetic WAN and fat-tree networks, the performance of ConVer was evaluated compared with other top-tier open-source verifiers, such as... Figure 8As shown, in wide area networks, ConVer is consistently 10 times faster than other validators. In fat-tree networks, ConVer outperforms Tiramisu and is 100 times faster than Minesweeper and Batfish. Furthermore, ConVer's performance in validating large networks was also evaluated. Figure 9 As shown, ConVer can complete the verification of a network with 180 nodes within 1000 seconds in the event of a maximum of one link failure.

[0095] Error Finding Performance: The performance of ConVer and Minesweeper in finding errors caused by specific external route advertisements and link failures was evaluated. Each network is connected to three external neighbors and configured with five errors, which only result in unreachability if a specific external route advertisement is received simultaneously and k link failures are experienced. We then used ConVer and Minesweeper to check the reachability of all network pairs to identify these errors. Figure 10 As shown, 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 further decreases (halving when k=4), while Minesweeper's runtime remains relatively stable. This is because as k increases, our optimization measures (routing and prefix pruning) become increasingly effective, thus reducing runtime.

[0096] In this embodiment, by proposing a hybrid symbolic routing and using it for hybrid symbolic simulation, the impact of arbitrary external route announcements and arbitrary link states on the network is effectively explored, thereby effectively reflecting all potential errors in the network configuration. During the hybrid symbolic simulation, the impact of data plane ACLs, subprefix routes, and longest prefix matching on data plane forwarding is considered. In the actual verification process of the FITI network, several previously undiscovered network attribute information was discovered and proposed, and these attribute information was successfully verified.

[0097] The routing configuration verification method based on hybrid symbolization proposed in this application constructs a hybrid symbolic network model based on the network configuration. This model is then used to infer the control plane behavior of the network in any environment. Furthermore, the control plane behavior is used to infer the forwarding behavior of the network in any environment. Finally, the forwarding results are used to determine whether the network's forwarding behavior aligns with the network administrator's intentions. This solves the problem that current routing configuration verification methods cannot adequately detect errors in routing configurations while maintaining scalability. It enables the verification of network forwarding behavior in any environment and fully identifies potential errors in the configuration.

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

[0099] Figure 11 This is a block diagram of a routing configuration verification device based on hybrid symbolization according to an embodiment of this application.

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

[0101] The system includes a construction module 100, which is used to construct a hybrid symbolic network model based on the network configuration; an inference module 200, which is 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; and a verification module 300, which is used to determine whether the forwarding behavior of the network conforms to the intention of the network administrator based on the forwarding results.

[0102] Optionally, in some embodiments, the construction module 100 is further configured to: determine the protocols running in the network and the corresponding protocol routes; divide the corresponding attribute equivalence classes according to the protocol route 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 inference module 200 is further configured to: construct a corresponding hybrid symbolic protocol route based on the symbolic route declaration conditions and route topology conditions, combined with the protocol route 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 further configured to: perform hybrid symbolic packet forwarding based on 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 packets received in any environment at each router.

[0105] Optionally, in some embodiments, the verification module 300 is further configured to: extract the attribute-related data packets corresponding to the data packets to be verified, and determine whether the forwarding behavior of the network conforms to the network administrator's intent in any environment based on the attribute-related data packets; if the attribute-related data packets do not conform to the network administrator's intent, then return all erroneous forwarding behaviors that cause the network administrator's intent to be violated, so that the network administrator can correct the erroneous configuration.

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

[0107] The routing configuration verification device based on hybrid symbolization proposed in this application constructs a hybrid symbolic network model based on the network configuration, uses the hybrid symbolic network model to infer the control plane behavior of the network in any environment, and infers the forwarding behavior of the network in any environment based on the control plane behavior; based on the forwarding results, it determines whether the network's forwarding behavior conforms to the network administrator's intention. Therefore, it solves the problem that current routing configuration verification methods cannot fully discover errors in routing configuration while satisfying scalability, and can verify the forwarding behavior of the network in any environment, fully discovering potential errors in the configuration.

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

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

[0110] When the processor 1202 executes the program, it implements the routing configuration verification method based on hybrid symbolization provided in the above embodiments.

[0111] Furthermore, electronic devices also include:

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

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

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

[0115] If the memory 1201, processor 1202, and communication interface 1203 are implemented independently, then the communication interface 1203, memory 1201, and processor 1202 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 12 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

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

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

[0118] This application also provides a computer program product on which a computer program is stored, which, when executed by a processor, implements the above-described hybrid symbolization-based routing configuration verification method.

[0119] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

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

[0121] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0122] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequential list of executable instructions for implementing logical functions, and can be specifically implemented in any computer program product for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer program product" can be any means that can contain, store, communicate, propagate, or transmit a program for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer program products include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic device, and portable optical disc read-only memory (CDROM). Furthermore, the computer program product can even be paper or other suitable medium on which the program can be printed, because the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0123] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0124] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer program product, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0125] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can 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 embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

Claims

1. A routing configuration verification method based on hybrid symbolization, characterized in that, Includes the following steps: Construct a hybrid symbolic network model based on the network configuration; The hybrid symbolic network model is used to infer the control plane behavior of the network in any environment, and the forwarding behavior of the network in any environment is inferred based on the control plane behavior. The forwarding results are used to determine whether the network's forwarding behavior aligns with the network administrator's intent. The construction of the hybrid symbolic network model includes: determining the protocols running in the network and their corresponding protocol routes; dividing the network into corresponding attribute equivalence classes based on the protocol route attributes and the corresponding network configuration; and constructing the hybrid symbolic network model based on the attribute equivalence classes and the network configuration. The method of inferring the control plane behavior of a network in any environment using a hybrid symbolic network model includes: constructing corresponding hybrid symbolic protocol routes based on symbolic route declaration conditions and route topology conditions, combined with protocol routing attributes represented by equivalence classes; and obtaining the control plane behavior of the network in any environment through hybrid symbolic simulation. The method of inferring the forwarding behavior of the network in any environment based on the control plane behavior includes: performing hybrid 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. The step of determining whether the forwarding behavior of the network conforms to the network administrator's intent based on the forwarding result further includes: extracting attribute-related data packets corresponding to the data packets based on the attributes to be verified, and determining whether the forwarding behavior of the network conforms to the network administrator's intent in any environment based on the attribute-related data packets; if the attribute-related data packets do not conform to the network administrator's intent, then returning all erroneous forwarding behaviors that caused the network administrator's intent to be violated, so that the network administrator can correct the misconfiguration.

2. A routing configuration verification device based on hybrid symbolization, characterized in that, include Build modules are used to construct hybrid symbolic network models based on network configurations; The inference module is 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 conforms to the intention of the network administrator based on the forwarding result; The construction module is further configured to: determine the protocols running in the network and their corresponding protocol routes; divide the network into corresponding attribute equivalence classes based on the protocol route attributes and the corresponding network configuration; and construct a hybrid symbolic network model for the network based on the attribute equivalence classes and the network configuration. The reasoning module is also used to: construct corresponding hybrid symbolic protocol routes based on symbolic route declaration conditions and route 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. The reasoning module is also used to: perform hybrid symbolic data packet forwarding based on 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; The verification module is further configured to: extract the attribute-related data packet corresponding to the data packet based on the attribute to be verified, and determine whether the forwarding behavior of the network conforms to the intention of the network administrator in any environment based on the attribute-related data packet; If the attribute-related data packet does not conform to the network administrator's intent, then all erroneous forwarding behaviors that caused the network administrator's intent to be violated are returned so that the network administrator can correct the misconfiguration.

3. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the hybrid symbolization-based routing configuration verification method as described in claim 1.

Images