L3VPN service restoration method and system supporting multiple service models

Abstract

The invention relates to the technical field of L3VPN services, and discloses an L3VPN service restoration method and system supporting multiple service models, and the method comprises the steps: adding a backbone device needing to be managed in a network control system; selecting a service model, and configuring a corresponding tunnel strategy; a distributed multi-thread method is adopted to collect service configuration information from each network device and return message information, and a backbone device collects current service configuration information and returns the current service configuration information to a network control system; the network control system converts the service configuration information into each model in a unified service model; the L3VPN service is restored based on the synchronized configuration message information and different service model data in the system, and the restored L3VPN service comprises a service instance, a service networking mode, an access point, an access route, a flow strategy and a service tunnel, and binding of the completed service and the synchronized tunnel is completed. Compared with the prior art, the problems of configuration splitting, insufficient expansibility, low efficiency and the like in the prior art are solved.

Description

Technical Field

[0001] The present invention relates to the technical field of L3VPN services, and in particular to an L3VPN service restoration method and system supporting multiple service models. Background Art

[0002] With the continuous development of network technology, Layer 3 Virtual Private Network (L3VPN) technology has become widely used, with each L3VPN carrying different private network service requirements. L3VPN is a virtual private network technology based on Layer 3 network protocols (such as IP), primarily used to build private, secure communication networks on public networks (such as the Internet or carrier networks). L3VPN connects dispersed sites through tunneling technology to form a logically private network, enabling users to achieve secure and efficient data transmission between geographically diverse locations. L3VPN services are widely used in scenarios such as enterprise networking, cross-regional branch office interconnection, and cloud service access, meeting enterprise needs for network isolation, security, and flexibility.

[0003] Network control systems manage a large number of L3VPN services. L3VPN service restoration typically refers to restoring the VPN configuration or status to the state managed by the network control system. After adding a managed device, the network control system must fully restore the existing L3VPN configuration information (such as routing policies, tunnel parameters, and quality of service rules) on the device to the controller, enabling centralized management and dynamic adjustments.

[0004] Current L3VPN service restoration technologies have significant limitations, including support for a single networking model, lack of support for new service tunnel models, and low dynamic synchronization efficiency. These issues limit the network's flexibility and adaptability to diverse and dynamically changing service demands.

[0005] 1. Single restoration configuration: Restoration technology can only perform restoration based on the device's configuration blocks, such as restoring a VPN or interface individually, without integrating the device's physical configuration, logical configuration, routing information, etc. into a business-level configuration entity presented to the user. This results in a lack of effective association between access points, VPNs, tunnels, routes, and other information.

[0006] 2. Service tunnel model limitations: Lack of support for new service tunnel models such as SR-TE (Segment Routing Traffic Engineering), SRv6 (Segment Routing over IPv6), and SR-Policy, and inability to meet the intelligent network's requirements for path optimization, traffic engineering, and IPv6 evolution.

[0007] 3. Low compatibility: Different network equipment vendors may use different implementations and standards to support L3VPN, which can lead to compatibility issues when configuring L3VPN in a multi-vendor environment. Different devices also have varying levels of support for routing protocols. Some devices may only support a limited range of routing protocols or have poor support for certain features, limiting the flexibility and scalability of L3VPN services. Summary of the Invention

[0008] Purpose of the invention: In response to the problems existing in the prior art, the present invention provides an L3VPN service restoration method and system that supports multiple business models. Through four core innovations: business model abstraction design, support for multiple tunnel types, intelligent adaptation and dynamic synchronization optimization, and enhanced multi-vendor compatibility, the present invention systematically solves the problems of configuration fragmentation, insufficient scalability, and low efficiency existing in the prior art.

[0009] Technical solution: The present invention provides an L3VPN service restoration method supporting multiple service models, comprising the following steps:

[0010] Step 1: Manage devices. Add the backbone devices that need to be managed to the network control system and initialize and configure each device to ensure that it can communicate with the network control system.

[0011] Step 2: Select an appropriate service model based on actual needs and configure the corresponding tunnel policy.

[0012] Step 3: Select all relevant devices that need to synchronize service configuration information in the network control system, and use a distributed multi-threaded method to collect service configuration information from each network device;

[0013] Step 4: Collect service configuration information and return message information. The service configuration collection module on the backbone device collects the current service configuration information and returns it to the network control system;

[0014] Step 5: The network control system converts the service configuration information unique to each device into individual models in the unified service model of the system, stores the synchronized and processed unified model data in the network control system, and checks the synchronization results to ensure that the service configuration information of all devices has been successfully synchronized.

[0015] Step 6: The network control system starts restoring the L3VPN service based on the synchronized configuration message information and different service model data in the system. The restored L3VPN service includes service instances, service networking modes, access points, access routes, traffic policies, and service tunnels.

[0016] Step 7: The network control system determines the specific service tunnel type that needs to be restored based on the service demand tunnel strategy and completes the binding of the service and the synchronized tunnel.

[0017] Furthermore, when restoring L3VPN services, the service instance relies on the RD (Route Distinguisher) and RT (Route Target) attributes, as well as the VRF name, to distinguish the same service running on multiple devices. RD is used to distinguish routes from different VPNs; RT is used to control the import and export of VPN routes; and the VRF name is the name of the virtual routing forwarding instance.

[0018] Search for the same VRF on different devices based on the VRF name. Ensure that the Import RT and Export RT under the VRF are the same or match each other. The RD values ​​under the VRF can be different, but the routes between the devices can be accessed through the correct RT policy.

[0019] Furthermore, the business networking mode includes Full-Mesh and Hub-Spoke.

[0020] In a fully meshed network, all sites (PE routers) are directly interconnected, allowing each site to communicate directly with any other site in the network. To achieve this full meshing, L3VPN requires uniformly configuring RT attributes to ensure correct exchange of routing information between all sites. A hub-and-spoke network topology is a hub-and-spoke network topology with a central hub connected to multiple spokes. Routing isolation is achieved through different VRF instances.

[0021] The restoration process of a fully-mesh network is as follows:

[0022] The Export RT value for the same VRF name on each PE is the same; the Import RT value for the same VRF name on each PE is the same; the Export RT value and the Import RT value are the same; this network is a fully meshed network.

[0023] Restoration process of Hub-Spoke network:

[0024] If there is only an Export RT and no Import RT in all VRF instances, then the VRF instance is the VPN-out in the Hub node, which is used to advertise routes to the Spoke sites.

[0025] If there is only Import RT but no Export RT in all VRF instances, then the VRF instance is the VPN-in in the Hub node, which is used to receive routes from all Spoke sites.

[0026] Find the remaining VRF instances. If their Export RT is the same as the Import RT in VPN-in, their Import RT is the same as the Export RT in VPN-out, and their Import RT and Export RT are different, then the VRF instance is the Spoke node's VRF instance.

[0027] The VPN service networking was finally determined to be Hub-Spoke networking.

[0028] Furthermore, when restoring L3VPN services, the access point refers to the connection point between the customer network (CE) and the service provider network (PE). The PE device is responsible for connecting the customer network traffic to the L3VPN and performing routing and forwarding, accessing the VPN's physical or logical interface. The specific access point restoration process is as follows:

[0029] The interface is identified as an access point based on the VRF instance bound to it. The access point information is then supplemented with the interface name, IP address, and VLAN information based on the interface configuration.

[0030] Furthermore, access routes include static routes, OSPF routes, and BGP routes. The specific restoration process is as follows:

[0031] 1) Static route restoration process:

[0032] The VPN instance name vpn-instance-name directly identifies the corresponding VPN service instance. Multiple destination networks can be configured for the same access point. The next-hop address of a static route must be an address that can be directly reached by the PE device, usually the interface address of the CE device. The system requires that each access point support only one next-hop address. If a device has multiple access points for the same VPN service and uses access static routes, the next-hop address and the access point IP address are handled based on whether they are in the same network segment.

[0033] 2) OSPF route restoration process:

[0034] The VPN instance name vpn-instance-name directly finds the corresponding VPN service instance. The area ID of the OSPF route is processed based on whether the network address and the access point IP address are in the same network segment.

[0035] 3) BGP route restoration process:

[0036] The BGP route restoration process is associated with the access point. The peer address refers to the address of the CE device, the peer BGP AS number (peer-as-number) is the BGP AS number of the CE device, and the VPN instance name (vpn-instance-name) directly finds the corresponding VPN service instance. The peer address must be in the same network segment as the access point IP address to identify the corresponding access point.

[0037] Furthermore, when restoring L3VPN services, traffic policies are used to manage and optimize traffic within L3VPN, including traffic classification, rate limiting, and priority adjustment. Traffic policies identify specific traffic by defining traffic classification rules. Based on the source address, destination address, protocol type, and port number, access control lists (ACLs) are used to clearly specify which traffic needs to be protected or prioritized. The restoration process is as follows:

[0038] The system searches for the corresponding traffic classifier and behavior information based on the traffic classifier name and behavior name configured in the traffic policy. If the traffic classifier has an ACL, the system searches for the corresponding ACL based on the ACL name. The system binds the restored traffic policy to the access point based on the traffic policy name on the access point.

[0039] Furthermore, the service tunnel includes SR-TE, SRv6-Policy, and SR-Policy, and the restoration process is as follows:

[0040] SR-TE tunnel: restore the SR-TE tunnel based on the SR-TE tunnel path and tunnel BFD reported by the device.

[0041] SRv6-Policy: restores the SRv6-Policy based on the SRv6-Policy, candidate path, and SegmentList reported by the device.

[0042] SR-Policy: restores the SR-Policy based on the SR-Policy, candidate path, and SegmentList reported by the device.

[0043] Furthermore, the specific service tunnel type that needs to be restored is determined based on the service demand tunnel policy, as follows:

[0044] 1) SR-TE type association: A tunnel policy is configured in the VPN instance. The tunnel policy configuration is bound to the SR-TE tunnel name. The SR-TE name is used to query the corresponding SR-TE tunnel information.

[0045] Tunnel policy configuration:

[0046] tunnel-policy <tnl-policy-name>

[0047] tunnel binding destination <address>the <tunnel-name> ；

[0048] <tnl-policy-name>Indicates the tunnel policy name; <address>Indicates the destination address;

[0049] <tunnel-name>Indicates the tunnel name;

[0050] 2) SRv6-Policy Association: Tunnel policies are configured in the VPN instance, including color-based traffic diversion and DSCP-based traffic diversion.

[0051] Color-based traffic diversion: The tunnel policy configuration specifies the SRv6 Policy priority and the number of tunnels participating in load balancing. The corresponding SRv6 Policy information is then found based on the color information in the corresponding routing policy configuration.

[0052] tunnel-policy <tnl-policy-name>

[0053] tunnel select-seq ipv6 srv6-te-policy load-balance-number 1;

[0054] DSCP traffic diversion: The tunnel policy configuration specifies the priority of the SRv6 Policy Group, and then finds the corresponding SRv6 Policy Group information based on the multiple colors corresponding to the SRv6 Policy Group.

[0055] tunnel-policy <tnl-policy-name>

[0056] tunnel select-seq ipv6 srv6-te-flow-group load-balance-number 1;

[0057] 3) SR-Policy Association: A tunnel policy is configured in the VPN instance. The color-based traffic diversion tunnel policy specifies the SR-Policy priority and the number of tunnels participating in load balancing. The corresponding SR-Policy information is then found through the color information in the corresponding routing policy configuration.

[0058] tunnel-policy <tnl-policy-name>

[0059] tunnel select-seq sr-te-policy load-balance-number 1.

[0060] The present invention also discloses an L3VPN service restoration system supporting multiple service models, including:

[0061] The service model abstraction module defines the service object model, including VPN instances, access points, access routes, and tunnel templates. It is used to integrate support for SR-TE, SRv6, and SR-Policy service models and realize automatic conversion from network control system service configuration to underlying device configuration.

[0062] Distributed configuration collection module supports asynchronous configuration collection of devices from multiple vendors. It uses a distributed multi-threaded approach to collect configuration data from various network devices. Each device independently reports its configuration information to the network control system.

[0063] Data standardization and conversion module, multi-vendor configuration syntax parsing and normalization, unified data storage and compression, converting configuration data unique to different devices into a unified business format;

[0064] The service association and feature extraction module identifies services based on RD / RT and VPN instance names, hierarchically binds access points to VRFs, and restores related L3VPN services based on synchronized network element configuration data and different system service models. It also manages access routing, tunnel binding, and policies, supporting SR-TE, SRv6, and SR-Policy tunnel types, dynamic tunnel adaptation, and load balancing policies.

[0065] The service configuration collection and reporting module is responsible for collecting service configuration information and reporting the message information to the network control system, providing the network control system with the latest service configuration data.

[0066] Beneficial effects:

[0067] 1. The present invention proposes to build a business object model, and realize the end-to-end associated presentation of L3VPN services by defining L3VPN business entities, including core object models such as business instances, access points, access routing protocols, routing policies, tunnel templates, and traffic policies. A business entity refers to a logical business unit composed of multiple devices. The control system can automatically aggregate the configuration information of each device, complete the data information of each model of the business entity, and ultimately achieve business recovery. Users only need to configure high-level intentions such as business names and access points to automatically generate complex cross-device and cross-protocol configurations (such as routing policies, tunnel parameters, and QoS rules), shielding the differences between underlying devices and significantly simplifying the complexity of operation and maintenance.

[0068] 2. This invention proposes a restoration model that supports multiple service tunnel models: SR-TE, SRv6-Policy, and SR-Policy. Service tunnels contain information such as whether backup paths are enabled and primary and backup paths, enabling dynamic tunnel adaptation and efficient load balancing, thereby improving overall network performance and service quality.

[0069] 3. The present invention proposes enhanced compatibility in multi-vendor heterogeneous environments and unified business model adaptation: through standardized business object models and protocol conversion layers (such as BGP / OSPF multi-protocol adaptation), the configuration differences of devices from different manufacturers are shielded, the configuration and restoration process of L3VPN services is simplified, and consistency and compatibility are ensured between different devices.

[0070] 4. This invention proposes an optimized distributed synchronization and restoration process: All relevant network elements are selected on the controller, and service configuration data for each device is synchronized in a distributed manner. After each device completes network element configuration synchronization, an automatic identification mechanism is integrated into the network control system to automatically detect and adapt to different service models. Related L3VPN services are restored based on these different service models. This process uses a phased execution strategy, prioritizing critical service traffic to ensure service continuity and stability. BRIEF DESCRIPTION OF THE DRAWINGS

[0071] Figure 1 A network structure diagram provided in the embodiment;

[0072] Figure 2 A workflow diagram provided in the embodiment;

[0073] Figure 3 A hierarchical structure diagram of a VPN service instance provided by the embodiment

[0074] Figure 4 A module block diagram provided by the embodiment;

[0075] Figure 5 A detailed flow chart is provided in the embodiment. DETAILED DESCRIPTION

[0076] The present invention will be further described below in conjunction with the accompanying drawings. The following embodiments are only used to more clearly illustrate the technical solutions of the present invention and are not intended to limit the scope of protection of the present invention.

[0077] The present invention discloses a L3VPN service restoration method and system supporting multiple service models. Figures 1 to 5 ,

[0078] like Figure 1 The entire network consists of two parts: the network control system and backbone equipment. The network control system primarily manages devices and virtual private network (VPN) services, including configuring and restoring L3VPN services. Backbone equipment collects and reports service configurations, receives services issued by the network control system, and distributes service messages.

[0079] In order to support L3VPN service restoration for various service models, the specific workflow is as follows: Figure 2 and Figure 5 As shown:

[0080] (1) The system starts a distributed synchronization task and uses a distributed multi-threaded method to collect service configuration information from various network devices.

[0081] (2) The device collects business configuration information. All relevant devices managed by the system will collect their own business configuration information.

[0082] (3) The device returns the collected service configuration information to the network control system.

[0083] (4) The network control system receives the service configuration information of each device, and then identifies and associates it according to the service model to restore the L3VPN service and tunnel.

[0084] (5) Finally, the binding between the service and the tunnel is completed.

[0085] The present invention requires that devices be managed on a network control system and a service model be created, all relevant network elements be selected to synchronize network element configuration data, and relevant L3VPN services be restored according to different service models.

[0086] L3VPN (Layer 3 Virtual Private Network) is a VPN technology that interconnects multiple groups of hosts and routers based on Layer 3 addresses and is widely used in the interconnection between corporate headquarters and branches. Figure 3 The following is the core object model definition of the L3VPN service entity and the VPN service restoration process, including core object models such as service instance, service networking (FullMesh, HubSpoke), access point, access route, traffic policy and service tunnel.

[0087] (1) Service instance: A service instance depends on the RD (Route Distinguisher) and RT (Route Target) attributes, as well as the VRF name. The system uses these attributes to distinguish the same service running on multiple devices. RD is used to distinguish routes from different VPNs; RT is used to control the import and export of VPN routes; and VRF name is the name of the virtual routing forwarding instance (e.g., VRF_A).

[0088] Restoring a VPN service instance:

[0089] Search for the same VRF on different devices based on the VRF name.

[0090] The Import RT and Export RT under the VRF are the same or match each other.

[0091] The RD values ​​under VRF (because RD ensures the uniqueness of routing entries) can be different, but the routes between these devices can access each other through the correct RT policy.

[0092] (2) Business networking mode: defines the connection method of VPN sites and supports multiple networking modes, including Full-Mesh and Hub-Spoke.

[0093] In a Full-Mesh network, all sites (PE routers) are directly interconnected, meaning each site can communicate directly with any other site in the network. To achieve this full interconnection, L3VPN requires uniformly configuring the RouteTarget (RT) attribute to ensure that routing information can be correctly exchanged between all sites.

[0094] Restoration process of Full-Mesh network:

[0095] The same VRF on each PE has the same Export RT value;

[0096] The same VRF on each PE has the same Import RT value.

[0097] The Export RT value is the same as the Import RT value;

[0098] Ensure that the network is a Full-Mesh network.

[0099] Hub-Spoke networking is a hub-and-spoke network topology with a central node (the hub) connected to multiple spokes (the spokes). In this structure, routing isolation is achieved through different VRF instances.

[0100] Restoration process of Hub-Spoke network:

[0101] If there is only an Export RT and no Import RT in all VRF instances, then the VRF instance is the VPN-out port in the Hub node, used to advertise routes to Spoke sites.

[0102] If all VRF instances contain only Import RTs but no Export RTs, then the VRF instance is the VPN-in in the Hub node, which receives routes from all Spoke sites.

[0103] The remaining VRF instances are searched for. If their Export RT is the same as the Import RT in VPN-in, their Import RT is the same as the Export RT in VPN-out, and their Import RT and Export RT are different, then this VRF instance is the Spoke node's VRF instance.

[0104] The VPN service network was finally determined to be a Hub-Spoke network.

[0105] (3) Access point: The access point is the connection point between the customer network (CE) and the service provider network (PE). The PE device is responsible for connecting the customer network traffic to the L3VPN and performing routing and forwarding. The physical or logical interface that accesses the VPN, interface name: physical interface (such as Gig0 / 1) or logical interface (such as VLAN100); IP address: IP address of the interface (such as 192.168.1.1 / 30); VRF binding: associated VRF instance (such as VRF_A); access route: static route, BGP, OSPF, etc.

[0106] Access point restoration process:

[0107] Determine whether the interface is an access interface based on the VRF instance bound to it.

[0108] ·Complete the access point information according to the configuration information under the interface, including the interface name, IP address, and VLAN.

[0109] (4) Access routing: Access routing is used to control routing information within a VPN instance, including route introduction, publication, and filtering. Routing policies within a VRF instance can be used to isolate routes between different customer networks. This includes static routing, OSPF routing, and BGP routing.

[0110] Access routing refers to the process of connecting a user's local network to the L3VPN service. CE devices play a key role in this process. They establish a connection with PE devices and, through this connection, advertise local routing information to them. After receiving this routing information, PE devices use BGP (Border Gateway Protocol) to propagate these routes within the service provider network, ensuring that data packets can be correctly transmitted from one site to another.

[0111] 1) Access static routing is a common access routing protocol used to transfer routing information between customer edge (CE) and service provider edge (PE) devices. When configuring static routing on a PE device, you need to bind the static route to a specific VPN instance.

[0112] Here are the configuration steps:

[0113] ip route-static vpn-instance <vpn-instance-name> <dest-address> <mask-length> <next-hop-address>

[0114] Parameter Description:

[0115] <vpn-instance-name>: Specifies the name of a VPN instance.

[0116] <dest-address>: Destination network address.

[0117] <mask-length>: Subnet mask length.

[0118] <next-hop-address>: Next hop address.

[0119] Static route restoration process:

[0120] The vpn-instance-name parameter directly identifies the corresponding VPN service instance. Multiple destination networks can be configured for the same access point. The next-hop address of a static route must be directly reachable by the PE device, typically the interface address of the CE device. The system requires each access point to support only one next-hop address. If a device has multiple access points for the same VPN service and uses access static routing, the next-hop address and the access point IP address are handled based on the network segment.

[0121] example:

[0122] Table 1 VPN service and access point information in PE devices

[0123] PE equipment VPN service Access point interface IP PE1 VPN1 TP1 (1.1.1.1 / 24) PE1 VPN1 TP2 (2.1.1.1 / 24) PE1 VPN2 TP3 (3.1.1.1 / 24) PE2 VPN1 TP1(1.1.1.2 / 24) PE2 VPN2 TP2 (3.1.1.2 / 24)

[0124] Table 2 Static routing information in PE devices

[0125] PE equipment Static routing PE1 Static1(vpn-instancevpn121.21.21.0255.255.255.01.1.1.3) PE1 Static2(vpn-instancevpn121.21.22.0255.255.255.01.1.1.3) PE1 Static3(vpn-instancevpn222.22.22.0255.255.255.03.1.1.3) PE2 Static4(vpn-instancevpn121.21.21.0255.255.255.01.1.1.4) PE2 Static5(vpn-instancevpn121.21.22.0255.255.255.02.1.1.4) PE2 Static6(vpn-instancevpn221.21.23.0255.255.255.03.1.1.4)

[0126] The system access static route is restored to:

[0127] Table 3 Static routes in the system are restored to the access point

[0128] PE equipment VPN service Access point interface IP Static routing PE1 VPN1 TP1 (1.1.1.1 / 24) Static1, Static2 PE1 VPN1 TP2 (2.1.1.1 / 24) none PE1 VPN2 TP3 (3.1.1.1 / 24) Static3 PE2 VPN1 TP1(1.1.1.2 / 24) Static4 PE2 VPN2 TP2 (2.1.1.2 / 24) Static6

[0129] 2) Accessing OSPF routes is a common networking method used to implement route exchange and traffic forwarding between PE (Provider Edge) and CE (Customer Edge) devices. When configuring OSPF on a PE device, you need to bind OSPF to a VPN instance to ensure that OSPF routes are correctly imported into the VPN instance.

[0130] Here are the configuration steps:

[0131] Ospf <process-id>router-id <router-id>vpn-instance <vpn-instance-name>

[0132] area <area-id>

[0133] network <network-address> <wildcard-mask>

[0134] Parameter Description:

[0135] <process-id>: OSPF process

[0136] <router-id>: Specifies the name of the VPN instance

[0137] <vpn-instance-name>: Specifies the name of a VPN instance.

[0138] <area-id>: Backbone area

[0139] <network-address> <wildcard-mask>: Add the network where the interface is located to the OSPF area

[0140] OSPF route restoration process:

[0141] The vpn-instance-name command can be used to directly find the corresponding VPN service instance. The area ID of OSPF routing is processed based on the network address and the access point IP being in the same network segment.

[0142] example:

[0143] Table 4 VPN service and access point information in PE devices

[0144] PE equipment VPN service Access point interface IP PE1 VPN1 TP1 (1.1.1.1 / 24) PE1 VPN1 TP2 (2.1.1.1 / 24) PE1 VPN2 TP3 (3.1.1.1 / 24) PE2 VPN1 TP1(1.1.1.2 / 24) PE2 VPN1 TP3 (2.1.1.2 / 24) PE2 VPN2 TP3 (3.1.1.2 / 24)

[0145] Table 5 OSPF routing information in PE devices

[0146]

[0147]

[0148] The system access OSPF route is restored to:

[0149] Table 6: OSPF routes restored to access points in the system

[0150] PE equipment VPN service Access point interface IP OSPF routing area ID PE1 VPN1 TP1 (1.1.1.1 / 24) area2.2.2.2 PE1 VPN1 TP2 (2.1.1.1 / 24) area2.2.2.2 PE1 VPN2 TP3 (3.1.1.1 / 24) area3.3.3.3 PE2 VPN1 TP1(1.1.1.2 / 24) area4.4.4.4 PE2 VPN1 TP2 (2.1.1.2 / 24) area5.5.5.5 PE2 VPN2 TP3 (3.1.1.2 / 24) area6.6.6.6

[0151] 3) Accessing BGP routes. Accessing EBGP (External Border Gateway Protocol) routes is a key step in enabling route exchange between PE (Provider Edge) devices and CE (Customer Edge) devices. The BGP parameters configured for EBGP routes on PE and CE, such as the AS number, must be unique. The following are the steps and precautions for configuring EBGP route access based on the search results:

[0152] Here are the configuration steps:

[0153] bgp <as-number>

[0154] vpn-instance <vpn-instance-name>

[0155] peer <peer-address>as-number <peer-as-number>

[0156] Parameter Description:

[0157] <as-number>: BGP AS number

[0158] <vpn-instance-name>: Specifies the name of a VPN instance.

[0159] <peer-address>: peer address

[0160] <peer-as-number>: Peer BGP AS number

[0161] BGP route restoration process:

[0162] It is associated with an access point. The peer address is the CE device's address, and the peer-as-number is the CE device's BGP AS number. The vpn-instance-name field directly identifies the corresponding VPN service instance. The peer address must be in the same network segment as the access point's IP address to identify the corresponding access point.

[0163] example:

[0164] Table 7 VPN service and access point information in PE devices

[0165] PE equipment VPN service Access point interface IP PE1 VPN1 TP1 (1.1.1.1 / 24) PE1 VPN1 TP2 (2.1.1.1 / 24) PE1 VPN2 TP3 (3.1.1.1 / 24) PE2 VPN1 TP1(1.1.1.2 / 24) PE2 VPN2 TP2 (2.1.1.2 / 24)

[0166] Table 8 BGP routing information in PE devices

[0167]

[0168] The system access BGP route is restored to:

[0169] Table 9 BGP routes in the system are restored to the access point

[0170] PE equipment VPN service Access point interface IP BGP routing PE1 VPN1 TP1 (1.1.1.1 / 24) peer1.1.1.3as-number5 PE1 VPN1 TP2 (2.1.1.1 / 24) peer2.1.1.3as-number6 PE1 VPN2 TP3 (3.1.1.1 / 24) peer3.1.1.3as-number6 PE2 VPN1 TP1(1.1.1.2 / 24) peer1.1.1.6as-number5 PE2 VPN2 TP2 (2.1.1.2 / 24) peer2.1.1.6as-number6

[0171] (5) Traffic policy is used to manage and optimize traffic in L3VPN, including traffic classification, rate limiting, and priority adjustment. Traffic policy can identify specific traffic by defining traffic classification rules. These rules can be based on information such as source address, destination address, protocol type, port number, etc. Through ACL (Access Control List), it can be clearly specified which traffic needs to be protected or prioritized. Through traffic policy, priority transmission of critical business traffic can be ensured, improving network performance and reliability. It includes traffic classification, traffic scheduling, bandwidth limitation, and traffic monitoring (packet loss rate, delay, jitter), etc.

[0172] Traffic policy restoration process:

[0173] Search for the corresponding traffic classifier and behavior information based on the traffic classifier name and behavior name configured in the traffic policy.

[0174] If an ACL exists in the traffic classifier, find the corresponding ACL based on the ACL name.

[0175] The restored traffic policy can be bound to the access point according to the traffic policy name in the access point;

[0176] (6) Service tunnels, including new service tunnels such as SR-TE, SRv6-Policy, and SR-Policy.

[0177] Restoration process of the service tunnel:

[0178] SR-TE tunnel: restore the SR-TE tunnel based on the SR-TE tunnel path and tunnel BFD reported by the device.

[0179] SRv6-Policy: restores the SRv6-Policy based on the SRv6-Policy, candidate path, and SegmentList reported by the device.

[0180] SR-Policy: restores the SR-Policy based on the SR-Policy, candidate path, and SegmentList reported by the device.

[0181] (7) Service binding tunnels: L3VPN services are iterated onto relevant tunnels. Tunnel types include SR-TE, SRv6-Policy, and SR-Policy. This is typically accomplished through tunnel policies. The tunnel policy for L3VPN services specifies which traffic should be transmitted through which tunnel and how these tunnels should be established between PE (Provider Edge) devices. Tunnel policies take into account not only performance requirements but also security requirements, ensuring that data is transmitted along the correct path and is appropriately protected.

[0182] VPN instance configuration:

[0183] ip vpn-instance <vpn-instance-name>

[0184] tnl-policy <tnl-policy-name>

[0185] Parameter Description:

[0186] <vpn-instance-name>: Specifies the name of a VPN instance.

[0187] <tnl-policy-name>: Tunnel policy name

[0188] SR-TE type association: A tunnel policy is configured in the VPN instance, and the tunnel policy is bound to the SR-TE tunnel name. You can query information about the corresponding SR-TE tunnel using the SR-TE name.

[0189] Tunnel policy configuration:

[0190] tunnel-policy <tnl-policy-name>

[0191] tunnel binding destination <address>the <tunnel-name>

[0192] Parameter Description:

[0193] <tnl-policy-name>: Tunnel policy name

[0194] <address>: Destination address

[0195] <tunnel-name>: Tunnel name

[0196] SRv6-Policy Association: A tunnel policy is configured in the VPN instance, which includes color-based traffic diversion and DSCP-based traffic diversion.

[0197] 1) Color-based traffic diversion: Tunnel policy configuration specifies the SRv6 Policy priority and the number of tunnels participating in load balancing. The corresponding SRv6 Policy information is then found using the color information in the corresponding routing policy configuration.

[0198] tunnel-policy <tnl-policy-name>

[0199] tunnel select-seq ipv6 srv6-te-policy load-balance-number 1

[0200] Parameter Description:

[0201] <tnl-policy-name>: Tunnel policy name

[0202] 2) DSCP traffic diversion: The tunnel policy configuration specifies the priority of the SRv6 Policy Group, and then finds the corresponding SRv6 Policy Group information based on the multiple color information corresponding to the corresponding SRv6 Policy Group.

[0203] tunnel-policy <tnl-policy-name>

[0204] tunnel select-seq ipv6 srv6-te-flow-group load-balance-number 1

[0205] SR-Policy Association: A tunnel policy is configured in a VPN instance. The color-based traffic diversion tunnel policy specifies the SR-Policy priority and the number of tunnels participating in load balancing. The corresponding SR-Policy information is then found using the color information in the corresponding routing policy configuration.

[0206] tunnel-policy <tnl-policy-name>

[0207] tunnel select-seq sr-te-policy load-balance-number 1

[0208] Parameter Description:

[0209] <tnl-policy-name>:Tunnel strategy name The L3VPN service restoration system supporting multiple service models disclosed in the present invention covers the following modules, such as Figure 4 :

[0210] Module 1: Service Model Abstraction Module. This is a functional module of the network control system. It defines service object models (such as VPN instances, access points, access routes, and tunnel templates). It integrates support for new service models such as SR-TE, SRv6, and SR-Policy, and enables automatic conversion from network control system service configuration to underlying device configuration.

[0211] Module 2: Distributed Configuration Collection Module. This module is a functional module of the network control system and supports asynchronous configuration collection of devices from multiple vendors. It uses a distributed multi-threaded approach to collect configuration data from various network devices. Each device independently reports its configuration information to the network control system, allowing the system to process this data asynchronously.

[0212] Module 3: Data Standardization and Conversion Module. This module is a functional module of the network control system. It parses and normalizes multi-vendor configuration syntax, and unifies data storage and compression. The system converts the configuration data unique to different devices into a unified business format.

[0213] Module 4: Service Association and Feature Extraction Module. This module is a functional module of the network control system. It identifies services based on RD / RT and VPN instance names, hierarchical binding of access points and VRFs, and restores related L3VPN services based on synchronized network element configuration data and different service models of the system. It also provides access routing, tunnel binding and policy management, supports tunnel types such as SR-TE, SRv6, and SR-Policy, and provides dynamic tunnel adaptation and load balancing strategies.

[0214] Module 5: Service Configuration Collection and Reporting Module. This module is a functional module of the backbone network equipment and is responsible for collecting service configuration information and reporting it to the network control system, providing the network control system with the latest service configuration data to ensure data consistency.

[0215] The above embodiments are intended only to illustrate the technical concepts and features of the present invention. Their purpose is to enable those skilled in the art to understand the contents of the present invention and implement them accordingly. They are not intended to limit the scope of protection of the present invention. Any equivalent changes or modifications made in accordance with the spirit of the present invention are intended to be covered by the scope of protection of the present invention. < / address> < / address> < / network-address> < / network-address> < / mask-length> < / dest-address> < / vpn-instance-name> < / address> < / tunnel-name> < / address>

Claims

1. A L3VPN service restoration method supporting multiple service models, characterized in that: The steps include: Step 1: Manage devices. Add the backbone devices that need to be managed to the network control system and initialize and configure each device to ensure that it can communicate with the network control system. Step 2: Select an appropriate service model based on actual needs and configure the corresponding tunnel policy. Step 3: Select all relevant devices that need to synchronize service configuration information in the network control system, and use a distributed multi-threaded method to collect service configuration information from each network device; Step 4: Collect service configuration information and return message information. The service configuration collection module on the backbone device collects the current service configuration information and returns it to the network control system; Step 5: The network control system converts the service configuration information unique to each device into individual models in the unified service model of the system, stores the synchronized and processed unified model data in the network control system, and checks the synchronization results to ensure that the service configuration information of all devices has been successfully synchronized. Step 6: The network control system starts restoring the L3VPN service based on the synchronized configuration message information and different service model data in the system. The restored L3VPN service includes service instances, service networking modes, access points, access routes, traffic policies, and service tunnels. Step 7: The network control system determines the specific service tunnel type that needs to be restored based on the service demand tunnel strategy and completes the binding of the service and the synchronized tunnel.

2. The L3VPN service restoration method supporting multiple service models according to claim 1, wherein: When restoring L3VPN services, service instances rely on the RD (Route Distinguisher) and RT (Route Target) attributes, as well as the VRF name, to distinguish the same service running on multiple devices. RD is used to distinguish routes from different VPNs; RT is used to control the import and export of VPN routes; and the VRF name is the name of the virtual routing forwarding instance. Search for the same VRF on different devices based on the VRF name. Ensure that the Import RT and Export RT under the VRF are the same or match each other. The RD values ​​under the VRF can be different, but the routes between the devices can be accessed through the correct RT policy.

3. The L3VPN service restoration method supporting multiple service models according to claim 1, wherein: The business networking modes include Full-Mesh and Hub-Spoke. In a fully meshed network, all sites (PE routers) are directly interconnected, allowing each site to communicate directly with any other site in the network. To achieve this full meshing, L3VPN requires uniformly configuring RT attributes to ensure correct exchange of routing information between all sites. A hub-and-spoke network topology is a hub-and-spoke network topology with a central hub connected to multiple spokes. Routing isolation is achieved through different VRF instances. The restoration process of a fully-mesh network is as follows: The Export RT value for the same VRF name on each PE is the same; the Import RT value for the same VRF name on each PE is the same; the Export RT value and the Import RT value are the same; this network is a fully meshed network. Restoration process of Hub-Spoke network: If there is only an Export RT and no Import RT in all VRF instances, then the VRF instance is the VPN-out in the Hub node, which is used to advertise routes to the Spoke sites. If there is only Import RT but no Export RT in all VRF instances, then the VRF instance is the VPN-in in the Hub node, which is used to receive routes from all Spoke sites. Find the remaining VRF instances. If their Export RT is the same as the Import RT in VPN-in, their Import RT is the same as the Export RT in VPN-out, and their Import RT and Export RT are different, then the VRF instance is the Spoke node's VRF instance. The VPN service networking was finally determined to be Hub-Spoke networking.

4. The L3VPN service restoration method supporting multiple service models according to claim 1, wherein: When restoring L3VPN services, the access point refers to the connection point between the customer network (CE) and the service provider network (PE). The PE device is responsible for connecting the customer network traffic to the L3VPN and performing routing and forwarding, accessing the VPN's physical or logical interface. The specific access point restoration process is as follows: The interface is identified as an access point based on the VRF instance bound to it. The access point information is then supplemented with the interface name, IP address, and VLAN information based on the interface configuration.

5. The L3VPN service restoration method supporting multiple service models according to claim 1, characterized in that: Access routes include static routes, OSPF routes, and BGP routes. The specific restoration process is as follows: 1) Static route restoration process: The VPN instance name vpn-instance-name directly identifies the corresponding VPN service instance. Multiple destination networks can be configured for the same access point. The next-hop address of a static route must be an address that can be directly reached by the PE device, usually the interface address of the CE device. The system requires that each access point support only one next-hop address. If a device has multiple access points for the same VPN service and uses access static routes, the next-hop address and the access point IP address are handled based on whether they are in the same network segment. 2) OSPF route restoration process: The VPN instance name vpn-instance-name directly finds the corresponding VPN service instance. The area ID of the OSPF route is processed based on whether the network address and the access point IP address are in the same network segment. 3) BGP route restoration process: The BGP route restoration process is associated with the access point. The peer address refers to the address of the CE device, the peer BGP AS number (peer-as-number) is the BGP AS number of the CE device, and the VPN instance name (vpn-instance-name) directly finds the corresponding VPN service instance. The peer address must be in the same network segment as the access point IP address to identify the corresponding access point.

6. The L3VPN service restoration method supporting multiple service models according to claim 1, characterized in that: When restoring L3VPN services, traffic policies are used to manage and optimize traffic in L3VPN, including traffic classification, rate limiting, and priority adjustment. Traffic policy identifies specific traffic by defining traffic classification rules. Based on source address, destination address, protocol type, and port number, it uses access control lists (ACLs) to clearly specify which traffic needs to be protected or prioritized. The restoration process is: The system searches for the corresponding traffic classifier and behavior information based on the traffic classifier name and behavior name configured in the traffic policy. If the traffic classifier has an ACL, the system searches for the corresponding ACL based on the ACL name. The system binds the restored traffic policy to the access point based on the traffic policy name on the access point.

7. The L3VPN service restoration method supporting multiple service models according to claim 1, characterized in that: The service tunnel includes SR-TE, SRv6-Policy, and SR-Policy. The restoration process is as follows: SR-TE tunnel: restore the SR-TE tunnel based on the SR-TE tunnel path and tunnel BFD reported by the device. SRv6-Policy: restores the SRv6-Policy based on the SRv6-Policy, candidate path, and SegmentList reported by the device. SR-Policy: restores the SR-Policy based on the SR-Policy, candidate path, and SegmentList reported by the device.

8. The L3VPN service restoration method supporting multiple service models according to claim 7, characterized in that: Determine the specific service tunnel type that needs to be restored based on the tunnel policy required by the service, as follows: 1) SR-TE type association: A tunnel policy is configured in the VPN instance. The tunnel policy configuration is bound to the SR-TE tunnel name. The SR-TE name is used to query the corresponding SR-TE tunnel information. Tunnel policy configuration: tunnel-policy <tnl-policy-name>< / tnl-policy-name> tunnel binding destination <address>the <tunnel-name> ；< / tunnel-name> < / address> <tnl-policy-name>Indicates the tunnel policy name; <address> Indicates the destination address;< / address> <tunnel-name> Indicates the tunnel name; 2) SRv6-Policy Association: The VPN instance is configured with a tunnel policy, which includes color-based traffic diversion and DSCP-based traffic diversion. Color-based traffic diversion: The tunnel policy configuration specifies the SRv6 Policy priority and the number of tunnels participating in load balancing. The corresponding SRv6 Policy information is then found based on the color information in the corresponding routing policy configuration. tunnel-policy <tnl-policy-name>< / tnl-policy-name> tunnel select-seq ipv6 srv6-te-policy load-balance-number 1; DSCP traffic diversion: The tunnel policy configuration specifies the priority of the SRv6 Policy Group, and then finds the corresponding SRv6 Policy Group information based on the multiple color information corresponding to the corresponding SRv6 Policy Group; tunnel-policy <tnl-policy-name>< / tnl-policy-name> tunnel select-seq ipv6 srv6-te-flow-group load-balance-number 1; 3) SR-Policy Association: A tunnel policy is configured in the VPN instance. The color-based traffic diversion tunnel policy specifies the SR-Policy priority and the number of tunnels participating in load balancing. The corresponding SR-Policy information is then found based on the color information in the corresponding routing policy configuration. tunnel-policy <tnl-policy-name>< / tnl-policy-name> tunnel select-seq sr-te-policy load-balance-number 1.

9. An L3VPN service restoration system supporting multiple service models, characterized in that: include: The service model abstraction module defines the service object model, including VPN instances, access points, access routes, and tunnel templates. It is used to integrate support for SR-TE, SRv6, and SR-Policy service models and realize automatic conversion from network control system service configuration to underlying device configuration. Distributed configuration collection module supports asynchronous configuration collection of devices from multiple vendors. It uses a distributed multi-threaded approach to collect configuration data from various network devices. Each device independently reports its configuration information to the network control system. Data standardization and conversion module, multi-vendor configuration syntax parsing and normalization, unified data storage and compression, converting configuration data unique to different devices into a unified business format; The service association and feature extraction module identifies services based on RD / RT and VPN instance names, binds access points to VRFs at the hierarchical level, and restores related L3VPN services based on synchronized configuration data of network elements and different service models of the system. Access routing, tunnel binding and policy management, support for SR-TE, SRv6, and SR-Policy tunnel types, dynamic tunnel adaptation, and load balancing strategies; The service configuration collection and reporting module is responsible for collecting service configuration information and reporting the message information to the network control system, providing the network control system with the latest service configuration data.

Images