Route configuration method, apparatus, device, storage medium and product

Abstract

The application discloses a routing configuration method, device, equipment, storage medium and product. In the scene of user subnet multi-homing access, a routing prefix is directly configured on a network device or the routing prefix is announced by a subnet, so that the network device updates a source address verification rule or adds a corresponding static route after receiving routing configuration information, and the network device generates a corresponding source address verification rule after receiving announcement information. Therefore, precise protection of more scenes such as asymmetric routing, intra-domain user multi-homing asymmetric access and flow bypassing can be realized, and the problem of misfiltering of legal flow can be avoided.

Description

Technical Field

[0001] This invention relates to the field of communications, and more particularly to a routing configuration method, apparatus, device, storage medium, and product. Background Technology

[0002] The lack of security considerations in the initial design of the Internet architecture has led to data transmission security vulnerabilities. Statistics show that many network attacks are based on source address spoofing. To mitigate the impact of source address spoofing attacks, many Source Address Validation (SAV) technologies have been proposed. Currently, commonly used source address validation technologies include relaxed uRPF (Unicast Reverse Path Forwarding), strict uRPF, and ACL (Access Control List) technologies based on SAV. In scenarios where a user network has a single-homed access network, ACL or strict uRPF can generally provide good protection. However, in scenarios where a user network has multiple-homed access networks, for traffic engineering purposes, there may be path asymmetry, and the asymmetric routing prefixes on the router may dynamically change to achieve dynamic traffic adjustment. In this case, ACL or strict uRPF cannot be directly used for UNI interface whitelist protection, otherwise, false filtering may occur. Summary of the Invention

[0003] The purpose of this invention is to provide a routing configuration method, apparatus, device, storage medium, and product that can achieve precise protection in more scenarios such as asymmetric routing, multi-homed asymmetric access of users within a domain, and traffic bypass, thereby avoiding the problem of mistakenly filtering legitimate traffic.

[0004] To achieve the above objectives, embodiments of the present invention also provide a routing configuration method applied to a subnet, the method comprising:

[0005] Sending a route advertisement to at least one network device; wherein the route advertisement is used to instruct the network device to generate a corresponding source address verification rule, and the route advertisement includes at least one of the following information:

[0006] At least two routing prefixes and their corresponding priority indication information;

[0007] At least one child route prefix and its parent route prefix.

[0008] As an improvement to the above scheme, when the subnet accesses at least one network device through the internal border gateway protocol, the priority indication information is a local priority value.

[0009] As an improvement to the above scheme, when the subnet accesses at least one network device through an external border gateway protocol, the priority indication information is a multi-exit distinction value.

[0010] As an improvement to the above scheme, the priority indication information corresponding to the same routing prefix advertised by the subnet is different for different network devices.

[0011] As an improvement to the above scheme, the source address verification rules include a source prefix whitelist and interface information.

[0012] As an improvement to the above solution, the interface information is the user network interface of the network device.

[0013] To achieve the above objectives, embodiments of the present invention also provide a routing configuration method applied to a network device, the method comprising:

[0014] Receive routing announcements sent by the subnet;

[0015] The corresponding source address verification rules are generated based on the route advertisement; wherein the route advertisement includes at least one of the following information:

[0016] At least two routing prefixes and their corresponding priority indication information;

[0017] At least one child route prefix and its parent route prefix.

[0018] To achieve the above objectives, embodiments of the present invention provide a routing configuration method applied to a network device, the method comprising:

[0019] Receive routing configuration information, which includes routing prefixes and interface information;

[0020] Update the source address verification rules or add corresponding static routes based on the routing configuration information.

[0021] As an improvement to the above scheme, the routing prefix includes the sub-routing prefix and its corresponding parent routing prefix.

[0022] As an improvement to the above scheme, the routing configuration information also includes priority indication information for the routing prefix.

[0023] As an improvement to the above scheme, the routing configuration information also includes one of the following priority configuration information:

[0024] The static route has a lower priority than the dynamic route of the network device;

[0025] The management distance of the static route is greater than the management distance of the dynamic route of the network device.

[0026] As an improvement to the above scheme, the source address verification rules include a source prefix whitelist and interface information.

[0027] As an improvement to the above solution, the interface information is the user network interface of the network device.

[0028] To achieve the above objectives, embodiments of the present invention provide a routing configuration device applied to a subnet, the device comprising:

[0029] A route announcement sending module is configured to send route announcements to at least one network device; wherein the route announcement is used to instruct the network device to generate corresponding source address verification rules, and the route announcement includes at least one of the following information:

[0030] At least two routing prefixes and their corresponding priority indication information;

[0031] At least one child route prefix and its parent route prefix.

[0032] To achieve the above objectives, embodiments of the present invention provide a routing configuration apparatus applied to a network device, the apparatus comprising:

[0033] The routing advertisement receiving module is used to receive routing advertisements sent by the subnet;

[0034] A routing configuration module is used to generate corresponding source address verification rules based on the routing advertisement; wherein the routing advertisement includes at least one of the following information:

[0035] At least two routing prefixes and their corresponding priority indication information;

[0036] At least one child route prefix and its parent route prefix.

[0037] To achieve the above objectives, embodiments of the present invention provide a routing configuration apparatus applied to a network device, the apparatus comprising:

[0038] A routing configuration information receiving module is used to receive routing configuration information, which includes routing prefixes and interface information.

[0039] The routing configuration module is used to update the source address verification rules or add corresponding static routes based on the routing configuration information.

[0040] To achieve the above objectives, embodiments of the present invention also provide a routing configuration device, including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor. When the processor executes the computer program, it implements the routing configuration method as described in any of the above embodiments.

[0041] To achieve the above objectives, embodiments of the present invention also provide a computer-readable storage medium, the computer-readable storage medium including a stored computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to perform the routing configuration method as described in any of the above embodiments.

[0042] To achieve the above objectives, embodiments of the present invention also provide a computer program product, including computer instructions, which, when executed by a processor, implement the routing configuration method as described in any of the above embodiments.

[0043] Compared to existing technologies, the routing configuration method, apparatus, device, storage medium, and product disclosed in this invention, in scenarios with multiple user subnets accessing the network, directly configure the routing prefix on the network device or have the subnet announce the routing prefix. This enables the network device to update the source address verification rules or add corresponding static routes after receiving the routing configuration information, and also enables the network device to generate corresponding source address verification rules after receiving the announcement information. This can achieve more precise protection in scenarios such as asymmetric routing, asymmetric access of multiple users within the domain, and traffic bypassing, avoiding the problem of mistakenly filtering legitimate traffic. Attached Figure Description

[0044] Figure 1 This is a schematic diagram of intra-domain access points and extra-domain scenarios in existing technologies;

[0045] Figure 2 This is a schematic diagram of a multi-homed access subnet scenario in existing technology;

[0046] Figure 3 This is a flowchart of the first routing configuration method provided in the embodiments of the present invention;

[0047] Figure 4 This is a schematic diagram of a network device accessing a subnet according to an embodiment of the present invention;

[0048] Figure 5 This is a first schematic diagram of a subnet performing route announcement according to an embodiment of the present invention;

[0049] Figure 6 This is a second schematic diagram of subnet route announcement provided in an embodiment of the present invention;

[0050] Figure 7 This is a flowchart of the second routing configuration method provided in the embodiments of the present invention;

[0051] Figure 8 This is a flowchart of the third routing configuration method provided in this embodiment of the invention;

[0052] Figure 9 This is a third schematic diagram of subnet route announcement provided in the embodiments of the present invention;

[0053] Figure 10 This is a structural block diagram of the first routing configuration device provided in the embodiments of the present invention;

[0054] Figure 11 This is a structural block diagram of the second routing configuration device provided in the embodiments of the present invention;

[0055] Figure 12 This is a structural block diagram of the third routing configuration device provided in the embodiments of the present invention;

[0056] Figure 13 This is a structural block diagram of a routing configuration device provided in an embodiment of the present invention. Detailed Implementation

[0057] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0058] The feasibility of source address verification technology stems from the fact that devices with forged source addresses and devices with legitimate source addresses usually have different geographical or access locations. Therefore, forged and legitimate packets heading to the same destination will use different forwarding paths and pass through routers along the way from different ingress interfaces. Thus, routers can identify which information is legitimate and which is forged by the mapping relationship between source addresses and ingress interfaces.

[0059] When using loose uRPF technology, the router checks its local forwarding information base (FIB) to confirm the existence of the source address in the received packet. If the source address exists in the FIB, the packet is processed normally; otherwise, it is discarded. Using loose uRPF technology within an autonomous system can lead to overly lenient source address verification, failing to effectively prevent source address spoofing between legitimate network addresses and mistakenly allowing attack traffic with spoofed source addresses to pass through, resulting in false negatives. Figure 1 As shown, Figure 1This diagram illustrates an intra-domain access point and an inter-domain scenario in existing technology. The autonomous system includes six network devices A through F. Device C has a legitimate source prefix P1, device D has a legitimate source prefix P2, device F has a legitimate source prefix P3, and device A has a legitimate source prefix P4. A1, A2, B1, B2, and E1 are the outgoing interfaces of their respective devices. Assuming device B's FIB table is as shown in Table 1, when device D forwards traffic with a forged source prefix P1 to device B, the attack traffic will be mistakenly allowed to pass because device B's FIB table contains that prefix.

[0060] Table 1. FIB Table for Device B

[0061] Target prefix Output interface P1 B1 P2 B2 ... ...

[0062] Using strict uRPF technology, the router looks up the source interface in its local FIB table. The incoming interface for transmitting packets must be the same as the outgoing interface corresponding to the source address in the FIB table; otherwise, the packet will be discarded. Strict uRPF technology strictly requires that the forwarding interface and the incoming interface be consistent, primarily used in single-homed or symmetric routing scenarios. In asymmetric multi-homed access scenarios, it can mistakenly filter legitimate traffic, leading to false positives. Figure 2 As shown, Figure 2 This is a schematic diagram of a multi-homed access subnet scenario in the existing technology. The multi-homed subnet has a valid source prefix P1 and P2. Assuming that the FIB table of device A is as shown in Table 2, since the FIB table of device A only stores the outgoing interface of prefix P2 as A2, the valid prefix P2 will be incorrectly intercepted by the incoming interface A1 of device A.

[0063] Table 2 FIB Table for Equipment A

[0064] Target prefix Output interface P1 Subnet P2 A2 ... ...

[0065] In summary, both lenient and strict uRPF schemes can cause false negatives and false positives in some scenarios. Regarding SAV-based ACL technology, manually configuring filtering rules and defining a list of valid source prefixes on the device is burdensome, error-prone, and severely limits scalability. It is typically used as an auxiliary technique to other authentication technologies. Therefore, SAV-based ACL methods rely on static manual configuration, making them difficult to scale independently. Furthermore, manually maintaining ACL rules incurs high maintenance costs, and misconfiguration can lead to false blocking or false passage. Additionally, existing technologies use the SAVNET (Source Address Validation in Networks) scheme, which uses BGP (Border Gateway Protocol) to probe packets. This scheme first exchanges source prefix information across the entire packet domain, then accurately reconstructs the actual forwarding path by sending BGP probe packets. Routers with SAVNET enabled record the ingress interfaces they traverse and generate a source address validation table consisting of the source prefix and the corresponding valid ingress interface. This source address validation table provides comprehensive protection at edge and relay nodes both within and between domains. However, this solution is not yet mature and may incur significant packet and path computation overhead, as well as substantial latency, when used on large-scale networks.

[0066] In scenarios where a user network has a single-homed access to the local network, ACLs or strict uRPFs are generally sufficient for good protection. However, in scenarios where a user network has multiple homed access to the local network, path asymmetry may exist for traffic engineering purposes, and the asymmetric routing prefixes on the router may dynamically change to achieve dynamic traffic adjustment. In this case, ACLs or strict uRPFs cannot be directly used for UNI (User Network Interface) whitelist protection, otherwise false filtering may occur. To overcome the above-mentioned shortcomings of existing technologies, this invention provides a routing configuration method to solve the problem of weak protection accuracy in intra-domain multi-homed asymmetric access scenarios.

[0067] The network devices described in this embodiment of the invention are edge devices, such as switches, routers, routing switches, IADs (Integrated Access Devices), and various MAN (Multiple-Access Network) / WAN (Wide Area Network) devices.

[0068] See Figure 3 , Figure 3 This is a flowchart of a first routing configuration method provided in an embodiment of the present invention. The first routing configuration method is implemented by a subnet and includes:

[0069] S11. Send a route advertisement to at least one network device; wherein the route advertisement is used to instruct the network device to generate a corresponding source address verification rule, and the route advertisement includes at least one of the following information:

[0070] 1) At least two routing prefixes and their corresponding priority indication information;

[0071] 2) At least one child route prefix and its parent route prefix.

[0072] For example, with Figure 4 The two route announcement methods will be explained using examples. Figure 4 This is a schematic diagram of network device access to subnet provided in an embodiment of the present invention. In a scenario of multi-homed access to user subnet, there are three network devices, namely R1 to R3. Network device R1 accesses subnet 1 through interface R1-1 and network device R3 through interface R1-2. Network device R2 accesses subnet 1 through interface R2-1 and network device R3 through interface R2-2.

[0073] For case 1), the route advertisement includes at least two route prefixes and their corresponding priority indication information.

[0074] For example, see Figure 5 , Figure 5 This is a first schematic diagram of subnet route advertising provided in this embodiment of the invention. Subnet 1 is mostly connected to network devices R1 and R2. For different network devices, the priority indication information corresponding to the same route prefix advertised by the subnet is different. For example, subnet 1 advertises the high-priority route prefix 2001:0db8:3c4d:1000:: / 64 to network device R1, and also advertises the low-priority route prefix 2001:0db8:3c4d:1001:: / 64; In addition, subnet 1 advertises the high-priority route prefix 2001:0db8:3c4d:1001:: / 64 to network device R2, and also advertises the low-priority route prefix 2001:0db8:3c4d:1000:: / 64. At this point, R1 and R2 will generate the FIB table as shown in Table 3. Packets destined for the prefix 2001:0db8:3c4d:1000:: / 64 will be forwarded to subnet 1 via R1 first, and packets destined for the prefix 2001:0db8:3c4d:1001:: / 64 will be forwarded to subnet 1 via R2 first, thus achieving load balancing of downlink traffic in subnet 1.

[0075] Table 3 FIB Tables for R1 and R2

[0076]

[0077] In this scenario, directly using strict uRPF based on FIB will cause false filtering. When subnet 1 sends a packet with a source address of 2001:0db8:3c4d:1001:: / 64, it will be intercepted by interface R1-1. This is because strict uRPF (with the outgoing and incoming interfaces being the same) extracts the source address of the packet and searches for a matching entry in the FIB by matching the longest prefix. BGP first looks for a route that matches the longest prefix of the destination IP address and checks whether the outgoing interface of the matching entry matches the incoming interface of the packet. If they match, the packet is valid. However, in this example, R1 will find through strict uRPF that the packet with a source address of 2001:0db8:3c4d:1001:: / 64 should arrive from interface R1-2, which is inconsistent with the actual interface R1-1 corresponding to this packet. Therefore, the packet is mistakenly identified as an illegal packet.

[0078] After adopting the embodiments of the present invention, R1 will generate a complete source prefix whitelist based on RIB information on the UNI interface (i.e., R1-1). This whitelist will simultaneously contain 2001:0db8:3c4d:1000:: / 64 and 2001:0db8:3c4d:1001:: / 64. Similarly, R2 will generate a complete source prefix whitelist based on RIB information on the UNI interface (i.e., R2-1). This whitelist will simultaneously contain 2001:0db8:3c4d:1000:: / 64 and 2001:0db8:3c4d:1001:: / 64. The source address verification rules of R1 and R2 are shown in Table 4. The source address verification rules include the source prefix whitelist and interface information, where the interface information is the user network interface of the network device. At this time, packets whose source addresses belong to these two address spaces sent by the user subnet will not be intercepted by R1-1 or R1-2, thereby avoiding the problem of false filtering.

[0079] Table 4 Source Address Verification Rules for R1 and R2 (SVA Table)

[0080] interface Source prefix whitelist R1-1 2001:0db8:3c4d:1000:: / 64, 2001:0db8:3c4d:1001:: / 64 R2-1 2001:0db8:3c4d:1000:: / 64, 2001:0db8:3c4d:1001:: / 64

[0081] Specifically, in case 1), when the subnet accesses at least one network device via an internal border gateway protocol, the priority indication information is a local priority value.

[0082] For example, when a subnet advertises routes to network devices, it needs to carry both high-priority and low-priority routes. This requires the user subnet to change its route advertising configuration. Assume subnet 1 is dual-homed to network devices R1 and R2 via iBGP (Internal Border Gateway Protocol). When advertising routes using BGP, it advertises routes 2001:0db8:3c4d:1000:: / 64 and 2001:0db8:3c4d:1001:: / 64 to both R1 and R2. The next-hop interfaces for both routes are the user-side UNI interfaces (i.e., R1-1 and R2-1). When subnet 1 advertises routes, the route advertisement sent to R1 needs to set a larger local preference value for 2001:0db8:3c4d:1000:: / 64 and a smaller local preference value for 2001:0db8:3c4d:1001:: / 64. Conversely, the route advertisement sent to R2 needs to set a smaller local preference value for 2001:0db8:3c4d:1000:: / 64 and a larger local preference value for 2001:0db8:3c4d:1001:: / 64. As a result, devices R1 and R2 can achieve load balancing of downlink traffic to the destination prefixes 2001:0db8:3c4d:1000:: / 64 and 2001:0db8:3c4d:1001:: / 64. Simultaneously, both R1 and R2 can obtain user routes with the next hop being the UNI interface from the RIB. Using the SAVNET scheme described above, the source prefix whitelists for R1 and R2 on R1-1 and R2-1 will ultimately include both 2001:0db8:3c4d:1000:: / 64 and 2001:0db8:3c4d:1001:: / 64. Packets originating from the user subnet with source addresses belonging to this address space will not be intercepted by R1-1 or R2-1, thus avoiding false filtering.

[0083] Specifically, in case 1), when the subnet accesses at least one network device via an external border gateway protocol, the priority indication information is a multi-exit distinction value.

[0084] For example, suppose subnet 1 is dual-homed to access devices R1 and R2 via eBGP (External Border Gateway Protocol). When advertising routes using BGP, it advertises routes 2001:0db8:3c4d:1000:: / 64 and 2001:0db8:3c4d:1001:: / 64 to both R1 and R2. The next-hop interface for both routes is the user-side UNI interface (i.e., R1-1 or R2-1). When advertising routes, subnet 1 needs to set a smaller MED (Multi-Exit Discriminator) value for 2001:0db8:3c4d:1000:: / 64 and a larger MED value for 2001:0db8:3c4d:1001:: / 64 in its route advertisement to R1. Conversely, in the route advertisement from subnet 1 to R2, a larger MED value needs to be set for 2001:0db8:3c4d:1000:: / 64, and a smaller MED value needs to be set for 2001:0db8:3c4d:1001:: / 64. MED is a BGP attribute used to influence eBGP neighbor route selection decisions. Routes with smaller MED values ​​are considered superior, thus affecting route selection. As a result, R1 and R2 can achieve load balancing of downlink traffic to the destination prefixes of 2001:0db8:3c4d:1000:: / 64 and 2001:0db8:3c4d:1001:: / 64, and both R1 and R2 can obtain user routes with the next hop being the UN I interface in the RIB. Using the SAVNET scheme described above, the source prefix whitelists for R1 and R2 on R1-1 and R2-1 will ultimately include both 2001:0db8:3c4d:1000:: / 64 and 2001:0db8:3c4d:1001:: / 64. Packets originating from the user subnet with source addresses belonging to this address space will not be intercepted by R1-1 or R2-1, thus avoiding false filtering.

[0085] For case 2), the route announcement includes at least one sub-route prefix and its parent route prefix.

[0086] For example, see Figure 6 , Figure 6This is a second schematic diagram of subnet route announcement provided in this embodiment of the invention. Subnet 1 is multi-homed to network devices R1 and R2. Subnet 1 announces the sub-route prefix 2001:0db8:3c4d:1000:: / 64 to network device R1, and also announces the parent route prefix 2001:0db8:3c4d:1000:: / 63. Furthermore, subnet 1 announces the sub-route prefix 2001:0db8:3c4d:1001:: / 64 to network device R2, and also announces the parent route prefix 2001:0db8:3c4d:1000:: / 63. It is worth noting that the parent route prefix is ​​the prefix of the parent node, and the sub-route prefix is ​​the prefix of the child nodes under that parent node; a parent node can have multiple child nodes. At this point, R1 and R2 will generate the FIB table shown in Table 5. Packets destined for the prefix 2001:0db8:3c4d:1000:: / 64 will be forwarded to subnet 1 via R1 first, and packets destined for the prefix 2001:0db8:3c4d:1001:: / 64 will be forwarded to subnet 1 via R2 first. At this time, the network can still achieve load balancing of subnet downlink traffic.

[0087] Table 5 FIB Tables for R1 and R2

[0088]

[0089] Similarly, for the same reason as in case 1), directly using strict uRPF can lead to false filtering. With this embodiment of the invention, R1 will generate a complete source prefix whitelist on the UNI interface (R1-1) based on RIB information. This whitelist will contain both 2001:0db8:3c4d:1000:: / 63 and 2001:0db8:3c4d:1000:: / 64. Likewise, R2 will generate a complete source prefix whitelist on the UNI interface (R2-1) based on RIB information. This whitelist will contain both 2001:0db8:3c4d:1000:: / 63 and 2001:0db8:3c4d:1001:: / 64. The source address verification rules for R1 and R2 are shown in Table 6. In this case, packets originating from the user subnet with source addresses belonging to this address space will not be intercepted by R1-1 or R1-2, thus avoiding false filtering.

[0090] Table 6 Source Address Verification Rules for R1 and R2 (SVA Table)

[0091] interface Source prefix whitelist R1-1 2001:0db8:3c4d:1000:: / 63, 2001:0db8:3c4d:1000:: / 64 R2-1 2001:0db8:3c4d:1000:: / 63, 2001:0db8:3c4d:1001:: / 64

[0092] Compared to existing technologies, the first routing configuration method disclosed in this invention, in scenarios with multi-homed access in user subnets, involves the subnet announcing a routing prefix on the network device. Upon receiving the announcement information, the network device generates corresponding source address verification rules, enabling precise protection in more scenarios such as asymmetric routing, multi-homed asymmetric access within a domain, and traffic bypass, thus avoiding the problem of falsely filtering legitimate traffic. Furthermore, compared to existing lenient uRPF and strict uRPF technologies, it solves the false negative and false positive problems caused by uRPF schemes. Compared to existing static access control list technologies based on SAV, it does not require continuous manual maintenance and can achieve adaptive protection and application in large-scale networks. Compared to source address verification technologies that use BGP packets for real-time probing, the route announcement / configuration process is simple and fast, saving additional packet overhead and complex path calculation overhead, and reducing latency.

[0093] See Figure 7 , Figure 7 This is a flowchart of a second routing configuration method provided in an embodiment of the present invention. The second routing configuration method is implemented by a network device and includes:

[0094] S21. Receive the routing announcement sent by the subnet;

[0095] S22. Generate corresponding source address verification rules based on the route advertisement; wherein, the route advertisement includes at least one of the following information:

[0096] At least two routing prefixes and their corresponding priority indication information;

[0097] At least one child route prefix and its parent route prefix.

[0098] Specifically, the source address verification rules include a source prefix whitelist and interface information.

[0099] Specifically, the interface information refers to the user network interface of the network device.

[0100] Specifically, when the subnet accesses at least one network device via an internal border gateway protocol, the priority indication information is a local priority value.

[0101] Specifically, when the subnet accesses at least one network device via an external border gateway protocol, the priority indication information is a multi-exit differentiation value.

[0102] Specifically, for different network devices, the priority indication information corresponding to the same routing prefix advertised by the subnet is different.

[0103] It is worth noting that the working process of the second routing configuration method described in the embodiments of the present invention can refer to the working process of the first routing configuration method described in the above embodiments, and will not be repeated here.

[0104] See Figure 8 , Figure 8 This is a flowchart of a third routing configuration method provided in an embodiment of the present invention. The third routing configuration method is implemented by a network device, and the method includes:

[0105] S31. Receive routing configuration information, which includes routing prefix and interface information;

[0106] S32. Update the source address verification rules or add corresponding static routes based on the routing configuration information.

[0107] It is worth noting that the routing configuration information can be sent by the user through a human-computer interaction interface. After receiving the routing configuration information, the network device has two routing configuration methods: one is to update the source address verification rules according to the routing configuration information, and the other is to add the corresponding static routes according to the routing configuration information. Figure 9 Let's take an example to illustrate. Figure 9 This is a third schematic diagram of subnet route advertising provided in this embodiment of the invention. If the route prefixes advertised by subnet 1 to R1 and R2 are asymmetrical, such as the route prefix advertised by subnet 1 to R1 being 2001:0db8:3c4d:1000:: / 64 and the route prefix advertised by subnet 1 to R2 being 2001:0db8:3c4d:1001:: / 64, then R1 cannot obtain complete prefix information on interface R1-1 (i.e., it does not include both route prefixes at the same time), and R2 cannot obtain complete prefix information on interface R2-1. Therefore, a complete source prefix whitelist cannot be generated.

[0108] In the first implementation, static SAV rules are configured, that is, the source address verification rules are updated according to the routing configuration information, such as... Figure 9As shown, using the SAVNET scheme, R1 generates a source prefix whitelist on interface R1-1 based on the advertisement information of subnet 1, which only includes 2001:0db8:3c4d:1000:: / 64. At this time, the route prefix 2001:0db8:3c4d:1001:: / 64 can be configured into R1's source prefix whitelist on interface R1-1 by sending route configuration information. Finally, R1's source prefix whitelist on interface R1-1 will contain two route prefixes: 2001:0db8:3c4d:1000:: / 64 and 2001:0db8:3c4d:1001:: / 64. Similarly, the source prefix whitelist generated by R2 on interface R2-1 only includes 2001:0db8:3c4d:1001:: / 64. In this case, the route prefix 2001:0db8:3c4d:1000:: / 64 can be configured into R2's source prefix whitelist on interface R2-1 by sending routing configuration information. Ultimately, R2's source prefix whitelist on interface R2-1 will contain two route prefixes: 2001:0db8:3c4d:1000:: / 64 and 2001:0db8:3c4d:1001:: / 64. Packets originating from subnet 1 with source addresses belonging to these two address spaces will not be intercepted by interfaces R1-1 or R2-1, thus avoiding false filtering.

[0109] Specifically, the source address verification rules include a source prefix whitelist and interface information. The updated source prefix whitelists for R1 and R2 can be found in Table 3. The interface information refers to the user network interfaces of the network devices. Figure 5 R1-1 and R2-1 in the example.

[0110] Table 7. Updated source prefix whitelists for R1 and R2

[0111] interface Source prefix whitelist R1-1 2001:0db8:3c4d:1000:: / 64, 2001:0db8:3c4d:1001:: / 64 R2-1 2001:0db8:3c4d:1000:: / 64, 2001:0db8:3c4d:1001:: / 64

[0112] Specifically, when updating the source address verification rules based on the routing configuration information, the routing configuration information also includes priority indication information for the routing prefix.

[0113] For example, the routing configuration information adds the priorities of 2001:0db8:3c4d:1000:: / 64 and 2001:0db8:3c4d:1001:: / 64. For instance, a high-priority routing prefix of 2001:0db8:3c4d:1000:: / 64 is configured for network device R1, while a low-priority routing prefix of 2001:0db8:3c4d:1001:: / 64 is configured simultaneously. Similarly, a high-priority routing prefix of 2001:0db8:3c4d:1001:: / 64 is configured for network device R2, while a low-priority routing prefix of 2001:0db8:3c4d:1000:: / 64 is configured simultaneously. Packets destined for the prefix 2001:0db8:3c4d:1000:: / 64 will be forwarded to subnet 1 via R1 first, and packets destined for the prefix 2001:0db8:3c4d:1001:: / 64 will be forwarded to subnet 1 via R2 first, thus achieving load balancing of downlink traffic in subnet 1.

[0114] Specifically, the routing prefix includes the sub-routing prefix and its corresponding parent routing prefix.

[0115] For example, the routing configuration information includes sub-route prefixes and their corresponding parent route prefixes. For instance, network device R1 is configured with a sub-route prefix of 2001:0db8:3c4d:1000:: / 64, and its parent route prefix is ​​configured as 2001:0db8:3c4d:1000:: / 63; similarly, network device R2 is configured with the same sub-route prefix of 2001:0db8:3c4d:1001:: / 64 and its parent route prefix is ​​also configured as 2001:0db8:3c4d:1000:: / 63. This also achieves load balancing for downlink traffic in subnet 1.

[0116] In the second implementation, a static backup route is configured, that is, a corresponding static route is added according to the route configuration information. In this case, the route configuration information also includes one of the following priority configuration information:

[0117] The static route has a lower priority than the dynamic route of the network device;

[0118] The management distance of the static route is greater than the management distance of the dynamic route of the network device.

[0119] For example, configure a static route on R1 with the next hop to interface R1-1 and the route prefix 2001:0db8:3c4d:1001:: / 64. This static route has a lower priority than the dynamic route 2001:0db8:3c4d:1001:: / 64 learned from network R3. Alternatively, the administrative distance (AD) of the static route must be greater than that of the dynamic route. A higher administrative distance indicates lower trust and lower priority; that is, the configured static route should not affect the original dynamic route, hence the need for a lower priority. Using the SAVNET scheme described above, the source prefix whitelists on interface R1-1 of R1 and interface R2-1 of R2 will ultimately include both 2001:0db8:3c4d:1000:: / 64 and 2001:0db8:3c4d:1001:: / 64. Packets originating from a user's subnet and whose source address belongs to this address space will not be intercepted by R1-1 or R2-1, thus avoiding the problem of false filtering.

[0120] Furthermore, when configuring static routes, you can also configure sub-route prefixes and their parent route prefixes. Similarly, you need to set the priority of the sub-route prefixes and their parent route prefixes to be lower than that of dynamic routes, or the management distance of the sub-route prefixes and their parent route prefixes to be greater than that of dynamic routes.

[0121] Compared to existing technologies, the routing configuration method disclosed in this invention directly configures the routing prefix on the network device in scenarios with multi-homed access in user subnets. This allows the network device to update source address verification rules or add corresponding static routes upon receiving the routing configuration information. This enables precise protection in more scenarios, such as asymmetric routing, multi-homed asymmetric access for users within a domain, and traffic routing, avoiding the problem of mistakenly filtering legitimate traffic. Furthermore, compared to existing relaxed and strict uRPF technologies, it solves the false negative and false positive problems caused by uRPF schemes. Compared to existing static access control list technologies based on SAV, it does not require continuous manual maintenance and can achieve adaptive protection and application in large-scale networks. Compared to source address verification technologies that use BGP packets for real-time probing, the route announcement / configuration process is simple and fast, saving additional packet overhead and complex path calculation overhead, and reducing latency.

[0122] See Figure 10 , Figure 10 This is a structural block diagram of a first type of routing configuration device 100 provided in an embodiment of the present invention. The routing configuration device 100 is applied to a subnet, and the routing configuration includes:

[0123] The route announcement sending module 11 is used to send a route announcement to at least one network device; wherein the route announcement is used to instruct the network device to generate a corresponding source address verification rule, and the route announcement includes at least one of the following information:

[0124] At least two routing prefixes and their corresponding priority indication information;

[0125] At least one child route prefix and its parent route prefix.

[0126] Specifically, when the subnet accesses at least one network device via an internal border gateway protocol, the priority indication information is a local priority value.

[0127] Specifically, when the subnet accesses at least one network device via an external border gateway protocol, the priority indication information is a multi-exit differentiation value.

[0128] Specifically, for different network devices, the priority indication information corresponding to the same routing prefix advertised by the subnet is different.

[0129] Specifically, the source address verification rules include a source prefix whitelist and interface information.

[0130] Specifically, the interface information refers to the user network interface of the network device.

[0131] It is worth noting that the working process of each module in the routing configuration device 100 described in the embodiments of the present invention can refer to the working process of the first routing configuration method described in the above embodiments, and will not be repeated here.

[0132] See Figure 11 , Figure 11 This is a structural block diagram of a second routing configuration device 200 provided in an embodiment of the present invention. The routing configuration device 200 is applied to a network device and includes:

[0133] The routing announcement receiving module 21 is used to receive routing announcements sent by the subnet;

[0134] The routing configuration module 22 is used to generate corresponding source address verification rules based on the routing advertisement; wherein the routing advertisement includes at least one of the following information:

[0135] At least two routing prefixes and their corresponding priority indication information;

[0136] At least one child route prefix and its parent route prefix.

[0137] Specifically, when the subnet accesses at least one network device via an internal border gateway protocol, the priority indication information is a local priority value.

[0138] Specifically, when the subnet accesses at least one network device via an external border gateway protocol, the priority indication information is a multi-exit differentiation value.

[0139] Specifically, for different network devices, the priority indication information corresponding to the same routing prefix advertised by the subnet is different.

[0140] Specifically, the source address verification rules include a source prefix whitelist and interface information.

[0141] Specifically, the interface information refers to the user network interface of the network device.

[0142] It is worth noting that the working process of each module in the routing configuration device 200 described in the embodiments of the present invention can refer to the working process of the second routing configuration method described in the above embodiments, and will not be repeated here.

[0143] See Figure 12 , Figure 12 This is a structural block diagram of a third routing configuration device 300 provided in an embodiment of the present invention. The routing configuration device 300 is applied to a network device and includes:

[0144] The routing configuration information receiving module 31 is used to receive routing configuration information, which includes routing prefix and interface information.

[0145] The routing configuration module 32 is used to update the source address verification rules or add corresponding static routes based on the routing configuration information.

[0146] Specifically, the routing prefix includes the sub-routing prefix and its corresponding parent routing prefix.

[0147] Specifically, the routing configuration information also includes priority indication information for the routing prefix.

[0148] Specifically, the routing configuration information also includes one of the following priority configuration information:

[0149] The static route has a lower priority than the dynamic route of the network device;

[0150] The management distance of the static route is greater than the management distance of the dynamic route of the network device.

[0151] Specifically, the source address verification rules include a source prefix whitelist and interface information.

[0152] Specifically, the interface information refers to the user network interface of the network device.

[0153] It is worth noting that the working process of each module in the routing configuration device 300 described in the embodiments of the present invention can refer to the working process of the third routing configuration method described in the above embodiments, and will not be repeated here.

[0154] See Figure 13 , Figure 13 This is a structural block diagram of a routing configuration device 400 provided in an embodiment of the present invention. The routing configuration device 400 includes a processor 41, a memory 42, and a computer program stored in the memory 42 and executable on the processor 41. When the processor 41 executes the computer program, it implements the steps in the various routing configuration method embodiments described above.

[0155] For example, the computer program may be divided into one or more modules / units, which are stored in the memory 42 and executed by the processor 41 to complete the present invention. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the routing configuration device 400.

[0156] The routing configuration device 400 may include, but is not limited to, a processor 41 and a memory 42. Those skilled in the art will understand that the schematic diagram is merely an example of the routing configuration device 400 and does not constitute a limitation on the routing configuration device 400. It may include more or fewer components than illustrated, or combine certain components, or use different components. For example, the routing configuration device 400 may also include input / output devices, network access devices, buses, etc.

[0157] The processor 41 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor. The processor 41 is the control center of the routing configuration device 400, connecting all parts of the routing configuration device 400 via various interfaces and lines.

[0158] The memory 42 can be used to store the computer programs and / or modules. The processor 41 implements various functions of the routing configuration device 400 by running or executing the computer programs and / or modules stored in the memory 42 and calling the data stored in the memory 42. The memory 42 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the mobile phone (such as audio data, phonebook, etc.). In addition, the memory 42 may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital card (SD) card, flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0159] If the modules / units integrated in the routing configuration device 400 are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by the processor 41, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0160] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A routing configuration method, characterized in that, Applied to a subnet, wherein the subnet is multihomed to at least two network devices, the method includes: A route advertisement is sent to at least two network devices; wherein the route advertisement is used to instruct the network devices to generate corresponding source address verification rules, and the route advertisement includes at least one of the following information: At least two routing prefixes and their corresponding priority indication information; At least one child route prefix and its parent route prefix; The source address verification rule includes a source prefix whitelist and interface information. The source prefix whitelist includes at least two routing prefixes or at least one sub-routing prefix and its parent routing prefix corresponding to priority indication information.

2. The routing configuration method as described in claim 1, characterized in that, When the subnet accesses at least one network device via an internal border gateway protocol, the priority indication information is a local priority value.

3. The routing configuration method as described in claim 1, characterized in that, When the subnet accesses at least one network device via an external border gateway protocol, the priority indication information is a multi-exit distinction value.

4. The routing configuration method as described in any one of claims 1 to 3, characterized in that, For different network devices, the priority indication information corresponding to the same routing prefix advertised by the subnet is different.

5. The routing configuration method as described in claim 1, characterized in that, The interface information refers to the user network interface of the network device.

6. A routing configuration method, characterized in that, Applied to network devices, the method includes: Receive routing announcements sent by a subnet; wherein the subnet is multihomed to at least two network devices; The corresponding source address verification rules are generated based on the route advertisement; wherein the route advertisement includes at least one of the following information: At least two routing prefixes and their corresponding priority indication information; At least one child route prefix and its parent route prefix; The source address verification rule includes a source prefix whitelist and interface information. The source prefix whitelist includes at least two routing prefixes or at least one sub-routing prefix and its parent routing prefix corresponding to priority indication information.

7. The routing configuration method as described in claim 6, characterized in that, The interface information refers to the user network interface of the network device.

8. A routing configuration device, characterized in that, Applied to a subnet, wherein the subnet is multihomed to at least two network devices, the device includes: A route announcement sending module is used to send route announcements to at least two network devices; wherein the route announcement is used to instruct the network devices to generate corresponding source address verification rules, and the route announcement includes at least one of the following information: At least two routing prefixes and their corresponding priority indication information; At least one child route prefix and its parent route prefix; The source address verification rule includes a source prefix whitelist and interface information. The source prefix whitelist includes at least two routing prefixes or at least one sub-routing prefix and its parent routing prefix corresponding to priority indication information.

9. A routing configuration device, characterized in that, Applied to network devices, the device includes: A routing announcement receiving module is used to receive routing announcements sent by a subnet; wherein the subnet is multihomed to at least two network devices; A routing configuration module is used to generate corresponding source address verification rules based on the routing advertisement; wherein the routing advertisement includes at least one of the following information: At least two routing prefixes and their corresponding priority indication information; At least one child route prefix and its parent route prefix; The source address verification rule includes a source prefix whitelist and interface information. The source prefix whitelist includes at least two routing prefixes or at least one sub-routing prefix and its parent routing prefix corresponding to priority indication information.

10. A routing configuration device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein the processor, when executing the computer program, implements the routing configuration method as described in any one of claims 1 to 7.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored computer program, wherein, when the computer program is executed, it controls the device on which the computer-readable storage medium is located to perform the routing configuration method as described in any one of claims 1 to 7.

12. A computer program product, characterized in that, It includes computer instructions that, when executed by a processor, implement the routing configuration method as described in any one of claims 1 to 7.

Images