WO2009071024A1 - Procédé de traitement d'échec de vpn et routeur pe pour fournisseur de réseau - Google Patents

Procédé de traitement d'échec de vpn et routeur pe pour fournisseur de réseau Download PDF

Info

Publication number
WO2009071024A1
WO2009071024A1 PCT/CN2008/073121 CN2008073121W WO2009071024A1 WO 2009071024 A1 WO2009071024 A1 WO 2009071024A1 CN 2008073121 W CN2008073121 W CN 2008073121W WO 2009071024 A1 WO2009071024 A1 WO 2009071024A1
Authority
WO
WIPO (PCT)
Prior art keywords
fault
notification
module
fault processing
processing information
Prior art date
Application number
PCT/CN2008/073121
Other languages
English (en)
French (fr)
Inventor
Jian Li
Yuping Jiang
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Publication of WO2009071024A1 publication Critical patent/WO2009071024A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities

Definitions

  • Virtual private network fault processing method and network provider border routing device The application is submitted to the Chinese Patent Office on November 30, 2007, and the application number is 200710188274.8, and the invention name is "virtual private network fault processing method and network provider border routing device". The priority of the Chinese Patent Application, the entire contents of which is incorporated herein by reference.
  • the technical field relates to a virtual private network VPN fault processing method and a network provider border router (PE).
  • VPN is a technology that relies on an Internet Service Provider (ISP) and a Network Service Provider (NSP) to establish a dedicated data communication network in a public network.
  • ISP Internet Service Provider
  • NSP Network Service Provider
  • the PE in the public network establishes a connection with the client edge router (CE) in the private network.
  • CEs that belong to a private network can communicate through the public network to establish private data in the public network. Communication network technology.
  • FIG. 1 is a schematic diagram of a VPN service deployment implementation.
  • CE1 and CE2 belong to the same VPN.
  • CE1 and CE2 can communicate through the Autonomous System (AS) 100.
  • AS Autonomous System
  • CE2 is dual-homed to two local PEs, namely PE2 and PE3 in the figure.
  • the remote PE1 and the local PE2 and PE3 establish the neighbor border gateway protocol (IBGP) neighbor relationship respectively.
  • IBGP neighbor border gateway protocol
  • ⁇ 2 and ⁇ 3 can receive the remote VPN routes advertised by the remote PE1. Route 1 and Route 2 in the figure.
  • the remote VPN route of ⁇ 2 refers to the VPN route advertised by PE1 to ⁇ 2, that is, VPN route 1.
  • PI and ⁇ 2 establish internal gateway protocol (IGG) neighbor relationships with PE1, ⁇ 2, and ⁇ 3, respectively.
  • IBG internal gateway protocol
  • the local PE2, the PE3, and the CE2 device use the Bidirectional Forwarding Detection (BFD) to detect the link and the node in real time, that is, the fault is reported according to the status of the BFD session.
  • BFD Bidirectional Forwarding Detection
  • CE2 uses PE2 and PE3 as the default gateways to forward traffic to the remote PE1 through VPN route 1 and VPN route 2, and then forwards the traffic to the remote CE1 through the PE1-CE1 IP route.
  • the VPN fault handling method is as follows: When a fault occurs, the PE uses the fault processing information to notify the fault, so that the CE that belongs to the PE selects other available route forwarding traffic; the PE is notified of the fault. After that, the device automatically restarts and performs fault elimination notification, so that the CE belonging to the PE re-switches the traffic back to the constant communication. After the PE fails, the PE is used as the main control board. In the normal case, the main control board works. When the PE fails, the main control board fails to work normally. Automatically switch to the standby main control board to work, and complete the PE restart.
  • the fault processing information may be BFD or a routing protocol, such as Open Shortest Path First (OSPF), intermediate system to intermediate system.
  • OSPF Open Shortest Path First
  • ISIS Internet Protocol
  • the method for notifying the fault includes: The bidirectional forwarding detection session (BFD session) is automatically set to the Down state. Then, the CE can quickly detect the BFD session of the PE through the BFD session. That is, the CE does not receive the BFD control packet from the PE within a certain period of time, and then determines the BFD session Down, and then selects other available routes to forward traffic.
  • the fault elimination method includes: triggering the establishment of a BFD session, that is, triggering the PE and the CE to mutually send BFD control packets. Once the BFD session is established, that is, the BFD convergence between the PE and the CE, the CE will cut back the traffic. To the PE. BFD has four states: initial (Init) state, established (Up) state, unestablished (Down) state, and management not established.
  • the CE quickly detects PE faults through the Hello mechanism of routing protocols such as OSPF, ISIS, or BGP, and selects other routes that can be used to forward traffic. After the PE is restarted, the PE will advertise a default route to the CE. After receiving the default route, the CE will switch back the traffic to the PE.
  • routing protocols such as OSPF, ISIS, or BGP
  • FIG. 2 is a flowchart of a VPN fault processing method in the prior art. as shown in picture 2:
  • Step 201 The BFD session of PE2 is automatically Down, that is, PE2 reports the fault.
  • the BFD session of the PE2 is Down.
  • the BFD session of the PE2 is Down.
  • CE2 can switch all traffic to PE3. That is, the traffic is all routed from the CE2 to the remote CE1 through the CE2-PE3 IP route to the PE3 and PE3 through the VPN route 2 to the remote PE1 and PE1 through the PE1-CE1 IP route.
  • Step 202 PE2 starts automatic restart.
  • Step 203 After the restart of the PE2, the establishment of the BFD session is triggered, that is, the fault elimination notification is performed.
  • Step 204 After the BFD session is established, the BFD session between PE2 and CE2 is converged, and PE2 sends a BFD session U message to CE2.
  • CE2 After receiving the BFD session U message from PE2, CE2 will switch back the traffic to PE2.
  • a timer can be statically configured to restart the BFD session after the convergence of the protocol in the public network AS 100 is complete. That is, in step 203, PE2 first waits for the timer through the timer, and then performs the fault cancellation notification after the timer waits.
  • the setting of the static timer can relieve the service interruption problem during the PE restart process to some extent.
  • the convergence time of the control plane in the public network cannot be accurately set, the timer setting of the timer is difficult to locate. Therefore, this method cannot solve the service interruption problem caused by the CE forwarding traffic to the PE in the case that the PE does not have a remote VPN route in the PE restart process.
  • the embodiment of the present invention provides a virtual private network VPN fault processing method and a network provider border routing device PE, so as to solve the service interruption problem caused by the CE forwarding traffic to the PE without the remote VPN routing of the PE. .
  • a virtual private network VPN fault processing method comprising:
  • the PE detects whether the number of remote VPN routes of the PE meets the preset requirements. When the number of remote VPN routes of the PE does not meet the preset requirements, the PE uses The fault processing information is processed by the fault until the number of the remote VPN routes of the PE meets the preset requirements, and the fault elimination information is used to perform the fault elimination notification.
  • a network provider border routing device PE the device includes: a route detection module and a fault processing module;
  • the route detection module is configured to detect whether the number of remote VPN routes of the PE itself meets a preset requirement, and if the number of remote VPN routes does not meet the preset requirement, The processing module sends the fault processing information to control the fault processing module to use the fault processing information to perform fault processing, and after the remote VPN routing number of the PE meets the preset requirement, the fault is eliminated by sending the fault to the fault processing module.
  • Information Control The fault handling module utilizes fault handling information for fault elimination notification.
  • the VPN fault processing method and the PE provided by the embodiment of the present invention associate the number of the remote VPN routes of the PE with the fault processing information, which can solve the problem that the CE does not have the remote VPN route in the PE.
  • FIG. 1 is a schematic diagram of a VPN system architecture in the prior art
  • FIG. 2 is a flowchart of a VPN fault processing method in the prior art
  • FIG. 3 is a flowchart of a VPN fault processing method according to Embodiment 1 of the present invention
  • FIG. 4 is a flowchart of a VPN fault processing method according to Embodiment 2 of the present invention
  • FIG. FIG. 6 is a schematic diagram of a VPN system architecture according to an embodiment of the present invention
  • FIG. 7 is a flowchart of a VPN fault processing method according to Embodiment 4 of the present invention
  • FIG. 9 is a schematic structural diagram of a PE according to Embodiment 6 of the present invention.
  • FIG. 10 is a schematic structural diagram of a PE according to Embodiment 7 of the present invention.
  • the embodiment of the present invention provides a method for processing a VPN fault.
  • the PE detects the number of remote VPN routes of the PE. When the number of remote VPN routes of the PE does not meet the preset requirements, the PE uses fault processing information. The fault is processed until the number of remote VPN routes of the PE meets the preset requirements.
  • Embodiment 1 The predetermined requirements are not met. For example, if all the uplinks of the PEs are faulty, the CEs forward traffic to the PEs if the PEs do not have remote VPN routes, or the PE does not converge on the public network. In the case of a remote VPN route, traffic is forwarded to the PE.
  • FIG. 3 is a flowchart of a VPN fault processing method according to Embodiment 1 of the present invention. As shown in FIG. 3, the VPN fault processing method provided in this embodiment may include:
  • Step 301 The PE detects whether the number of remote VPN routes of the PE meets the preset requirements. If the number of the remote VPN routes meets the preset requirements, step 302 is performed; otherwise, step 303 is performed.
  • the method for the PE to detect whether the number of remote VPN routes of the PE meets the preset requirements may include:
  • the number of remote VPN routes of the PE is higher than the threshold, it is determined that the number of remote VPN routes of the PE meets a preset requirement.
  • the timer is used to time until the preset time is reached, and the timer ends, and then step 302 is performed.
  • This allows the number of remote VPN routes to be arbitrarily set according to different needs, improving the flexibility of the application and the performance of the PE for fault handling.
  • Step 302 The PE uses the fault processing information to perform fault elimination.
  • the fault The management information can be BFD or a default route.
  • Step 303 Use the fault handling information for troubleshooting and continue with the steps.
  • the method for performing fault processing by using the fault processing information may include: determining whether there is a fault processing information session between the UI and the CE, and if yes, using the fault processing information to perform fault occurrence, otherwise, using fault processing information Wait for recovery processing.
  • the method provided by the first embodiment of the present invention associates the number of remote VPN routes of the ⁇ with the fault processing information, and uses the remote VPN route number to control the fault processing information for fault processing or fault elimination notification, only in the far distance If the number of the VPN routes meets the pre-set requirements, the CEs that belong to the UI are allowed to forward the traffic to the port.
  • the present embodiment can solve the problem that the CE does not have the remote VPN route in the prior art. In the case of a service interruption caused by forwarding traffic to the port.
  • the VPN fault processing provided by the embodiment of the present invention is performed in the case where the fault processing information is BFD (that is, the fault is reported according to the state of the BFD session) and the default route (that is, the fault is reported according to the state of the default route session).
  • BFD that is, the fault is reported according to the state of the BFD session
  • the default route that is, the fault is reported according to the state of the default route session
  • the fault processing information session is a BFD session; and the PE uses the BFD session as the Admindown mode to perform the fault occurrence. Or use the method of suppressing the establishment of the BFD session to wait for the recovery process, and use the method of triggering the establishment of the BFD session to perform the fault elimination notification.
  • the VPN system architecture of FIG. 1 is used to further explain the VPN fault processing method provided by the embodiment of the present invention in the case that the PE is faulty and the fault handling information is BFD.
  • Embodiment 2 is a diagrammatic representation of Embodiment 1:
  • FIG. 4 is a flowchart of a VPN fault processing method according to Embodiment 2 of the present invention.
  • the threshold for detecting the number of remote VPN routes is set to 0 in advance.
  • the VPN fault processing method provided in this embodiment may include: Step 401: When the PE2 fails, the status of the BFD session of the PE2 is automatically Down.
  • the BFD session of the PE2 is Down.
  • the BFD session of the PE2 is Down.
  • CE2 can switch all traffic to PE3. That is, the traffic is all routed from the CE2 to the remote CE1 through the CE2-PE3 IP route to the PE3 and PE3 through the VPN route 2 to the remote PE1 and PE1 through the PE1-CE1 IP route.
  • Step 402 PE2 starts automatic restart.
  • Step 403 The PE2 detects the number of the remote VPN routes. If the number of the remote VPN routes meets the preset requirements, go to step 407. Otherwise, go to step 404.
  • the method for detecting whether the number of remote VPN routes meets the preset requirements includes: if the number of remote VPN routes of the PE2 is greater than 0, determining that the number of remote VPN routes of the PE2 meets the preset requirement; otherwise, determining the PE2 The number of remote VPN routes does not meet the preset requirements. If the protocol of the PE2 in the public network AS100 is not converged, PE2 does not receive the remote route. The number of remote VPN routes of PE2 is 0. The number of remote VPN routes of PE2 does not meet the preset. Set requirements. If the protocol of the PE2 in the public network AS 100 has been converged, the number of remote VPN routes of the PE2 is not 0. The result is that the number of remote VPN routes of the PE2 meets the preset requirements.
  • Step 404 PE2 determines whether there is a BFD session between PE2 and CE2. If yes, go to step 406. Otherwise, go to step 405.
  • Step 405 PE2 waits for recovery processing, that is, suppresses establishment of the BFD session, and returns to step 403.
  • PE2 can suppress the establishment of a BFD session by not sending a BFD session U message to the CE2. It can also suppress the establishment of a BFD session by not receiving the control message from the CE2. I won't go into details here. As long as the BFD session is not established, CE2 will not forward traffic to PE2.
  • Step 406 PE2 sets the BFD session to Admindown, and returns to step 403.
  • CE2 detects that the BFD session of PE2 is Down through BFD, and then selects other routes that can be used to forward traffic.
  • CE2 can switch all traffic to PE3. That is, the traffic is all routed from the CE2 to the remote CE1 through the CE2-PE3 IP route to the PE3 and the PE3 through the VPN route 2 to the remote PE1 and PE1 through the PE1-CE1 IP route.
  • Step 407 PE2 performs fault elimination notification, that is, triggers establishment of a BFD session between PE2 and CE2.
  • Step 408 The BFD session is established, that is, the BFD convergence between PE2 and CE2, and the PE2 sends a BFD session U message to CE2.
  • CE2 After receiving the BFD session U message from PE2, CE2 will cut the traffic back to
  • step 403 to step 407 after the restart of the PE2, if the remote VPN route advertised by the PE1 or the PE3 is not received, the establishment of the BFD session is suppressed, and the BFD session is triggered after the remote VPN route number is not 0. The establishment of the session. This effectively solves the problem that the BFD session between PE2 and CE2 has been established, and PE2 does not have the service interruption caused by the remote VPN route.
  • the VPN system architecture of FIG. 1 is provided, and all the uplinks of the PEs are faulty, that is, the PE2-P1, the PE2-P2, and the PE2-PE3 links are all faulty, and the fault processing information is BFD.
  • the VPN troubleshooting method is described in further detail.
  • Embodiment 3 is a diagrammatic representation of Embodiment 3
  • FIG. 5 is a flowchart of a VPN fault processing method according to Embodiment 3 of the present invention.
  • the threshold for detecting the number of remote VPN routes is set to 0.
  • the VPN fault processing method provided in this embodiment may include:
  • Step 501 The PE2 detects the number of the remote VPN routes. If the number of the remote VPN routes meets the preset requirements, step 505 is performed. Otherwise, step 502 is performed. If the uplink of the PE2 is invalid, the PE2 does not receive the remote route. The number of remote VPN routes of the PE2 is 0. The detection result is as follows: The number of remote VPN routes does not meet the preset requirements. If the uplink of the PE2 is partially or completely converged, the number of routes of the PE2 is not 0. The detection result is as follows: The number of remote VPN routes of the PE2 meets the requirements.
  • Step 502 PE2 determines whether there is a BFD session between PE2 and CE2. If yes, go to step 503. Otherwise, go to step 504.
  • PE2 works normally, and the BFD session between PE2 and CE2 is established. The judgment result is that a BFD session exists between PE2 and CE2. If the PE2 fails to be restarted and the BFD session between PE2 and CE2 is not established, the result is that there is no BFD session between PE2 and CE2, as in the second embodiment.
  • Step 503 PE2 performs notification of failure occurrence.
  • the specific method is as follows: Set the BFD session to Admindown and return to step 501.
  • CE2 can switch all traffic to PE3. That is, the traffic is all routed from the CE2 to the remote CE1 through the CE2-PE3 IP route to the PE3 and PE3 through the VPN route 2 to the remote PE1 and PE1 through the PE1-CE1 IP route.
  • Step 504 The PE2 waits for the recovery process, that is, suppresses the establishment of the BFD session, and returns to step 501.
  • Step 505 PE2 performs fault elimination notification, that is, triggers establishment of a BFD session between PE2 and CE2.
  • Step 506 A BFD session is established, that is, BFD convergence between PE2 and CE2, and PE2 sends a BFD session U message to CE2.
  • CE2 After receiving the BFD session U message from PE2, CE2 then cuts the traffic back to PE2.
  • step 501 to step 505 when all the uplinks are faulty, the fault occurs when the BFD session is set to Admindown.
  • the CE2 can detect the PE2 uplink fault through BFD, and then select other available. Route forwarding traffic. This solves the prior art, because CE2 cannot pass BFD inspection.
  • the PE2 has a remote VPN route, and the PE2 still forwards traffic to the PE2 without the remote VPN route.
  • the second embodiment and the third embodiment use the VPN system architecture of Fig. 1, and the fault processing is detailed.
  • the fault processing information session is the release of the default route; the PE usage suppression is attributed to the PE.
  • the CE advertises a default route, and sends a revoke of the default route message to the CE to notify the failure of the failure.
  • the method is used to suppress the release of the default route to the CE.
  • the default route is used for fault elimination notification.
  • the VPN system architecture of FIG. 6 is used in the following, and the VPN fault processing method provided by the present invention is further described in detail in the case where the fault handling information is the default route.
  • FIG. 6 is a schematic structural diagram of a VPN system according to an embodiment of the present invention. As shown in Figure 6:
  • CE1 and CE2 belong to the same VPN.
  • CE2 is dual-homed to two local PEs, namely PE2 and PE3 in the figure.
  • the remote PE1 and the local PE2 and PE3 establish an IBGP neighbor relationship.
  • PE2 and PE3 can receive the remote VPN routes advertised by the remote PE1, namely VPN route 1 and VPN route 2.
  • the remote VPN route of PE2 is the VPN route advertised by PE1 to PE2.
  • PI and P2 establish an IGP neighbor relationship with PE1, PE2, and PE3.
  • the OSPF/ISIS or BGP routing protocol is used to detect the faults of the link and the node.
  • the PE2 advertises a default route to the CE2.
  • the traffic is routed from CE2 to the PE2, and the PE2 is routed through the PE2->P1->PE1 VPN route 1 to the remote PE1 and PE1 and then to the CE1 through the PE1->CE1 IP route.
  • Routes and IP routes advertised by PE3 are used for traffic load balancing.
  • the traffic is divided into two parts: part of the route from CE2 to PE2 and PE2.
  • PE1->CE1 IP route arrives at CE1; at the same time, another part is routed from CE2 to CE3 and PE3 via PE2->PE3 to PE3, PE3 via PE3->P2->PE1 VPN route 2 to remote PE1, PE1 and then PE1->CE1 IP Road By arriving at CE1.
  • the VPN service deployment implementation of Figure 6 is used, and the fault handling information is the default path.
  • Embodiment 4 is a diagrammatic representation of Embodiment 4:
  • FIG. 7 is a flowchart of a VPN fault processing method according to Embodiment 4 of the present invention.
  • the threshold for detecting the number of remote VPN routes is set to 0 in advance.
  • the VPN fault processing method provided in this embodiment may include:
  • Step 701 PE2 automatically stops sending messages and reports the failure.
  • CE2 can detect PE2 faults through routing protocols such as OSPF/ISIS or BGP, and then select other routes that can be used to forward traffic.
  • CE2 can switch all traffic to PE3. That is, the traffic is all routed from CE2 to the remote CE1 through the CE2-PE3 IP route to the PE3 and PE3 via the VPN route 2 to the remote PE1 and PE1.
  • Step 702 PE2 will start to restart automatically due to a fault.
  • Step 703 PE2 detects the number of remote VPN routes, that is, the number of remote VPN routes advertised by PE1. If the number of remote VPN routes meets the preset requirements, step 707 is performed; otherwise, step 704 is performed.
  • the detection result is as follows: The number of remote VPN routes does not meet the preset. Requirements. If the protocol of the PE2 in the public network AS100 is converged, the number of routes of the PE2 is not 0. The detection result is as follows: The number of remote VPN routes of the PE2 meets the requirements.
  • Step 704 PE2 determines whether there is a default route advertisement between PE2 and CE2. If yes, go to step 706. Otherwise, go to step 705.
  • the PE2 is restarted, so the default route is not advertised.
  • the judgment result is that there is no default route advertisement between PE2 and CE2.
  • Step 705 The PE2 waits for the recovery process, that is, the PE2 is suppressed from issuing the default route to the CE2, and the process returns to step 703. In this step, if CE2 does not receive the default route from PE2, it will not forward traffic to PE2.
  • Step 706 PE2 stops issuing the default route to CE2, and sends a default route revocation message to CE2, and returns to step 703.
  • CE2 selects other routes that can be used to forward traffic.
  • CE2 can switch all traffic to PE3. That is, the traffic is all routed from the CE2 to the remote CE1 through the CE2-PE3 IP route to the PE3 and PE3 through the VPN route 2 to the remote PE1 and PE1 through the PE1-CE1 IP route.
  • Step 707 PE2 performs fault elimination and sends a default route to CE2.
  • the method of the CE2 to switch the traffic back to the PE2 can be: The default route is used to switch back the traffic to the PE2, and the PE2 forwards the traffic through the remote VPN route. Together with the published IP routes, the load balancing of the traffic is resumed. Whether it is all back-cut or load-sharing, you can choose according to different application needs.
  • the PE2 does not advertise the default route to the CE2, and then advertises the default route to the CE2. After the number of VPN routes is not 0, the default route is advertised to CE2. This effectively solves the problem that CE2 forwards traffic to PE2 and causes service interruption due to the release of the default route to CE2.
  • the VPN system architecture of FIG. 6 is used to provide the fault to all the uplinks of the PE, that is, all the PE2-P1, PE2-P2, and PE2-PE3 links are faulty, and the fault handling information is a routing protocol.
  • the VPN troubleshooting method is described in further detail.
  • Embodiment 5 is a diagrammatic representation of Embodiment 5:
  • All uplinks of PE2 are faulty, that is, all the PE2-P1, PE2-P2, and PE2-PE3 links are faulty.
  • FIG. 8 is a flowchart of a VPN fault processing method according to Embodiment 5 of the present invention. Pre First set the threshold for detecting the number of remote VPN routes to 0. As shown in FIG. 8, the VPN fault processing method provided in this embodiment may include:
  • Step 801 The PE2 detects the number of the remote VPN routes. If the number of the remote VPN routes meets the preset requirements, step 805 is performed. Otherwise, step 802 is performed. If the uplink of the PE2 fails, the PE2 does not receive the remote route. The number of remote VPN routes of the PE2 is 0. The detection result is as follows: The number of remote VPN routes does not meet the preset requirements. If the uplink of the PE2 is partially or completely converged, the number of routes of the PE2 is not 0. The detection result is as follows: The number of remote VPN routes of the PE2 meets the requirements.
  • Step 802 PE2 determines whether there is a default route advertisement between PE2 and CE2. If yes, go to step 803. Otherwise, go to step 804.
  • the PE2 is working properly.
  • the default route is advertised between PE2 and CE2.
  • the result is that the default route is advertised between PE2 and CE2. If the PE2 fails to restart at this time, there is no default route between PE2 and CE2, as in the case of the third embodiment.
  • Step 803 PE2 performs notification of the failure.
  • the specific method is as follows: Stop sending a default route to CE2, and send a default route to CE2, and return to step 801.
  • CE2 selects other routes that can be used to forward traffic.
  • CE2 switches all traffic to PE3. That is, the traffic is all routed from the CE2 to the remote CE1 through the CE2-PE3 IP route to the PE3 and PE3 through the VPN route 2 to the remote PE1 and PE1.
  • Step 804 The PE2 waits for the recovery process, that is, the PE2 is suppressed from issuing the default route to the CE2, and the process returns to step 801.
  • CE2 does not receive the default route from PE2, it will not forward traffic to PE2.
  • Step 805 PE2 performs fault elimination, that is, PE2 advertises a default route to CE2. If CE2 receives the default route from PE2, the traffic is switched back to PE2.
  • the method of the CE2 to switch the traffic back to the PE2 is as follows: The traffic is forwarded back to the PE2 through the default route, and the PE2 forwards the traffic through the remote VPN route. The traffic is switched back to PE2, and the IP traffic advertised by PE3 is used to restore load balancing. Whether it is all back-cut or load-sharing, you can choose according to different application needs.
  • step 801 to step 805 when all the uplinks are faulty, the PE2 notifies the failure of the default route to the CE2 and sends a default route revocation message to the CE2 to notify the fault that the CE2 receives the default route. After the message is revoked, select other routes that can be used to forward traffic. This effectively solves the problem of service interruption caused by the fact that the CE2 cannot detect the PE2 with or without the remote VPN route through the routing protocol, and continues to forward traffic to the PE2 without the remote VPN route.
  • the threshold of the number of remote VPN routes can also be set to a non-zero value. For example, if the number of remote VPN routes of the PE is less than or equal to 2, it is determined that the number of remote VPN routes of the PE does not meet the preset requirement; if the number of remote VPN routes of the PE is If it is greater than 2, it is determined that the number of remote VPN routes of the PE meets the preset requirements.
  • the method for determining whether the number of remote VPN routes of the PE meets the preset requirement may be: if the VPN of the PE is lower than a preset threshold, determining that the number of remote VPN routes of the PE does not meet the pre-determination Set the requirement, otherwise it is determined that the number of remote VPN routes of the PE meets the preset requirements.
  • the timer When the number of remote VPN routes of the PE is greater than the preset threshold, it is timed by the timer to wait for the PE to receive more routes until the preset time is reached. The timer expires and continues. The steps to perform a fault elimination notification.
  • the timing of the timer can be selected according to different application scenarios. This allows the number of remote VPN routes to be set according to different requirements, which improves the flexibility of the application and the performance of the PE for fault handling.
  • an embodiment of the present invention further provides a network provider border routing device PE.
  • FIG. 9 is a schematic structural diagram of a PE according to Embodiment 6 of the present invention.
  • the PE provided by the embodiment of the present invention includes a route detection module 901 and a fault processing module 902.
  • the route detection module 901 is configured to detect whether the number of remote VPN routes of the PE itself meets a preset requirement, and the number of the remote VPN routes does not meet the preset requirement.
  • the fault processing module 902 is configured to perform fault processing by using the fault processing information. After the number of remote VPN routes of the PE meets the preset requirements, the fault processing module 902 is notified to use the fault processing information to perform fault elimination notification.
  • the fault processing module 902 is configured to receive the notification from the route detection module 901, and if the notification of the fault processing from the route detection module 901 is received, the fault processing information is used for fault processing; if the fault cancellation notification from the route detection module 901 is received The notification uses the fault handling information to report the failure cancellation.
  • the fault processing module 902 can be a BFD module, and the fault processing information is a BFD.
  • the fault processing module 902 can also be a default routing module, and the fault processing information is a default route.
  • the fault processing module 902 may further include a discriminating submodule 9021 and a processing submodule 9022;
  • the discriminating sub-module 9021 is configured to receive a notification of the fault processing from the route detecting module 901, and after receiving the notification of the fault processing, determine whether there is a fault handling information session between the PE and the CE belonging to the PE, and if so, Then, the notification processing sub-module 9022 uses the fault processing information to perform the fault occurrence notification; otherwise, the notification processing sub-module 9022 uses the fault processing information to perform the wait recovery processing;
  • the processing sub-module 9022 is configured to receive a notification from the discriminating sub-module 9021 or the route detecting module 901, and use the fault-handling information to perform a fault occurrence notification, a wait recovery process, or a fault cancellation notification according to the received notification.
  • the route detection module controls the fault processing module to use the fault processing information to perform fault processing by using the remote VPN routing number of the PE. That is, the PE provided by the embodiment of the present invention associates the number of its own remote VPN routes with the fault handling information, and only allows the attribution of the remote VPN route number of the PE to meet the preset requirement.
  • the CE of the PE forwards traffic to the PE. Therefore, the service interruption problem caused by the CE forwarding traffic to the PE in the absence of the remote VPN route of the PE in the prior art can be solved.
  • the PE provided in the embodiment of the present invention is further described in detail below.
  • FIG. 10 is a schematic structural diagram of a PE according to Embodiment 7 of the present invention.
  • the PE provided by the embodiment of the present invention includes: a route detection module 101 and a fault processing module 102.
  • the fault handling module 102 includes a discriminating sub-module 1021 and a processing sub-module 1022.
  • the processing sub-module 1022 includes a fault occurrence module 10221, a waiting recovery module 10222, and a fault elimination module 10223.
  • the route detection module 101 is configured to detect whether the number of the remote VPN routes of the PE itself meets the preset requirements, and notify the discriminator of the fault processing module 102 if the number of the remote VPN routes does not meet the preset requirements.
  • the module 1021 performs fault processing by using the fault processing information. After the number of the remote VPN routes of the PE meets the preset requirements, the fault clearing and receiving module 10223 is notified to use the fault processing information to perform the fault elimination notification.
  • the discriminating sub-module 1021 is configured to receive the notification from the route detecting module 101, and after receiving the notification, determine whether there is a fault handling information session between the PE and the CE belonging to the PE, and if yes, notify The failure occurrence notification module 10221 performs failure occurrence notification using the failure processing information. Otherwise, the notification waiting recovery module 10222 performs the waiting recovery processing using the failure processing information.
  • the fault occurrence notification module 10221 is configured to receive a notification of the failure occurrence notification from the discriminating sub-module 1021, and after receiving the notification, use the fault processing information to perform the fault occurrence notification.
  • the waiting recovery module 10222 is configured to receive a notification of the waiting recovery process from the discriminating sub-module 1021, and after receiving the notification, perform the waiting recovery process using the failure processing information.
  • the failure cancellation notification module 10223 is configured to receive a notification of the failure cancellation notification from the route detection module 101, and after receiving the notification, use the failure processing information to perform the failure cancellation notification.
  • the fault processing module 102 can be a BFD module, the fault processing information is BFD, and the fault processing information session is a BFD session.
  • the fault processing information is BFD
  • the fault processing information session is a BFD session.
  • the fault occurrence notification module 10221 of the BFD module is configured to set the BFD session to be notified after receiving the notification of the failure occurrence notification from the discriminating submodule 1021. Admindown. This allows the CEs that belong to the PE to detect the PE fault through BFD, and then select other available routes to forward traffic.
  • the wait recovery module 10222 of the BFD module is configured to suppress the establishment of the BFD session after receiving the notification of the wait for recovery process from the discriminating submodule 1021. This causes the CE that belongs to the PE to not forward traffic to the PE without a BFD session.
  • the fault elimination notification module 10223 of the BFD module is configured to trigger the establishment of the BFD session after receiving the notification of the fault cancellation notification from the route detection module 101.
  • the CE that belongs to the PE can receive the message from the BFD session U, and after receiving the BFD session U message, the traffic is switched back to the PE.
  • the fault processing module 102 can also be a default routing module, the fault processing information is a default route, and the fault processing information session is a default route.
  • the fault occurrence notification module 10221 of the default routing module is used. After receiving the notification of the failure occurrence notification from the discriminating sub-module 1021, it stops issuing the default route to the CE belonging to the PE and sends a default route revocation message. This allows the CE that belongs to the PE to detect the PE fault after receiving the default route revocation message, and then select other routes that can be used to forward traffic.
  • the waiting for recovery module 10222 of the default routing module is configured to suppress the PE from issuing a default route to the CE belonging to the PE after receiving the notification from the discriminating sub-module 1021 to wait for the recovery process. This causes the CE belonging to the PE to not forward traffic to the PE without a default route.
  • the fault elimination notification module 10223 is configured to issue a default route to the CE belonging to the PE after receiving the notification of the fault cancellation notification from the route detection module 101. This allows the CE belonging to the PE to switch back traffic to the PE after receiving the default route from the PE.
  • the routing detection module 101 determines whether the number of remote VPN routes meets the preset requirements. For example, a threshold may be preset. When the number of remote VPN routes is lower than or equal to the threshold, the determination is performed. The number of remote VPN routes does not meet the preset. The requirement is that the fault processing information is sent to the fault processing module 102. Otherwise, it is determined that the remote VPN route number meets the preset requirement, and the fault elimination information is sent to the fault processing module 102.
  • a threshold may be preset. When the number of remote VPN routes is lower than or equal to the threshold, the determination is performed. The number of remote VPN routes does not meet the preset. The requirement is that the fault processing information is sent to the fault processing module 102. Otherwise, it is determined that the remote VPN route number meets the preset requirement, and the fault elimination information is sent to the fault processing module 102.
  • the route detection module 101 may further include a timer 1011.
  • the timer 1011 is configured to perform timing after the route detection module 101 determines that the number of remote VPN routes of the PE meets the preset requirements, until the preset time is reached, and the timing ends, and then the route detection module 101 is triggered to the fault processing module 102. Send fault elimination information. This allows the number of remote VPN routes to wait for more remote VPN routes at a predetermined time after the requirements are met.
  • the timer 1011 timing can be selected according to different application needs.
  • the PE provided by the embodiment of the present invention can use the fault processing information to perform fault processing when the number of remote VPN routes does not meet the preset requirements, until the number of remote VPN routes meets the requirements. Then, use the fault handling information to report the fault elimination.
  • the PE provided by the embodiment of the present invention can set the threshold of the number of remote VPN routes according to actual application requirements, and can also use the timer to wait for more remote VPN routes, thereby providing flexible control. Improve the performance of PEs by requiring the number of remote VPN routes.
  • the present invention can be implemented by hardware or by software plus a necessary general hardware platform.
  • the technical solution of the present invention may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (which may be a CD-ROM, a USB flash drive, a mobile hard disk, etc.), including several The instructions are for causing a computer device (which may be a personal computer, server, or network device, etc.) to perform the methods described in various embodiments of the present invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

虛拟专用网絡故障处理方法及网絡提供商边界路由设备 本申请要求于 2007年 11 月 30 日提交中国专利局， 申请号为 200710188274.8, 发明名称为 "虚拟专用网络故障处理方法及网络提 供商边界路由设备"的中国专利申请的优先权， 其全部内容通过引用 结合在本申请中。 技术领域 涉及虚拟专用网络 VPN故障处理方法及网络提供商边界路由设备 ( Provider Edge Router, PE )。
背景技术
VPN是依靠 Internet服务提供商 ( Internet Service Provider, ISP ) 和网络服务提供商 （Network Service Provider, NSP )在公共网络中 建立专用数据通信网络的技术。
在 VPN中， 公网中的 PE和私网中的客户边界路由设备 ( Client Edge Router, CE )建立连接， 同属于一个私网的 CE可以通过公网进 行通信， 实现在公共网络中建立专用数据通信网络的技术。
图 1为一种 VPN业务部署实施的示意图。
如图 1所示： CE1和 CE2同属一个 VPN,那么 CE1与 CE2可以 通过公网自治系统（Autonomous System, AS ) 100 进行通信。 CE2 双归属两个本地 PE, 即图中的 PE2、 PE3。 在公网 AS100 内， 远端 PE1 和本地 PE2、 PE3 分别建立内部边界网关协议（Interior Border Gateway Protocol, IBGP )邻居关系， ΡΕ2和 ΡΕ3可以同时接收到远 端 PE1发布的远端 VPN路由， 分别为图中的路由 1和路由 2。 这里 ΡΕ2的远端 VPN路由是指 PE1发布给 ΡΕ2的 VPN路由， 即 VPN路 由 1。 PI、 Ρ2分别和 PEl、 ΡΕ2、 ΡΕ3建立内部网关协议（ Interior Gateway Protocol, IGP )邻居关系。 本地 PE2、 PE3与 CE2设备之间釆用双向 转发检测 （Bidirectional Forwarding Detection, BFD )进行链路和节 点故障的实时检测，也就是根据 BFD session的状态上报故障； 同时， CE2将 PE2、 PE3做缺省网关 , 分别经 VPN路由 1、 VPN路由 2转 发流量至远端 PE1 , 再通过 PE1-CE1 IP路由到达远端 CE1设备， 实 现流量负载分担。
在网络高速发展的今天， 三网合一的需求日益迫切， 运营商对网 络故障时的业务收敛速度非常重视。 特别是在 VPN 自治系统内部的 故障问题受到了运营商的极大重视。
通常情况下， VPN故障处理方法为： PE在出现故障时， 利用故 障处理信息进行故障出现通报， 使归属于所述 PE的 CE选择其它可 以利用的路由转发流量；所述 PE在进行故障出现通报后会自动重启， 进行故障消除通报， 使归属于所述 PE的 CE重新将流量回切到所述 常通信。 所述 PE故障后重启是指， 由于 PE釆用主备两块主控板， 在正常情况下主用主控板工作， 在 PE出现故障时， 即主用主控板无 法正常工作时，会自动切换至备用主控板进行工作，完成 PE的重启。 所述故障处理信息可以为 BFD, 也可以为路由协议， 如开放式最短 路径优先 （ Open Shortest Path First, OSPF )、 中间系统到中间系统
( Intermediate System to Intermediate System, ISIS )或边界网关协议
( Border Gateway Protocol , BGP )等。
如果故障处理信息为 BFD, 则所述故障出现通报的方法包括： 双向转发检测会话（BFD session ) 自动为未建立 （Down )状态。 那 么 CE通过 BFD就可以快速检测到所述 PE的 BFD session Down, 即 CE在一定时间内没有接收到来自 PE的 BFD控制报文则判定 BFD session Down, 进而选择其它可以利用的路由转发流量。 所述故障消 除通 的方法包括： 触发 BFD session的建立， 即触发 PE与 CE互发 BFD控制报文，一旦 BFD session建立，也就是 PE和 CE之间的 BFD 收敛， CE就会将流量回切到所述 PE。 BFD有四种状态： 初始（Init ) 状态、 建立 （Up ) 状态、 未建立 （Down ) 状态以及管理未建立
( Admindown )状态, 其中, Admindown状态为人为置 Down„
类似的， 如果故障处理信息为路由协议， 那么 PE出现故障时， CE会通过 OSPF、 ISIS或 BGP等路由协议的 Hello机制快速检测到 PE故障， 选择其它可以利用的路由转发流量。 PE重启后， PE和 CE 之间的路由协议一旦收敛， PE就会向 CE发布一条缺省路由， CE收 到缺省路由后， 将流量回切到所述 PE。
下面， 以图 1中 VPN业务的架构为例， 在釆用 BFD作为故障处 理信息的情况下， 对 VPN故障处理方法进行说明。
在 PE2出现故障的情况下， 由于 PE2 自身的故障会导致 PE2的 所有链路都中断， 即 PE2-P1、 PE2-P2, PE2-PE3和 PE2-CE2。 图 2 为现有技术中 VPN故障处理方法的流程图。 如图 2所示：
步骤 201 : PE2的 BFD session自动为 Down, 即 PE2进行故障出 现通报。
本步骤中， 在 BFD session Down之后， 会使得 CE2通过 BFD检 测到 PE2的 BFD session为 Down, 进而选择其它可以利用的路由转 发流量。 这里， CE2可以将全部流量切换至 PE3。 即流量全部从 CE2 经 CE2-PE3 IP路由至 PE3、 PE3经 VPN路由 2至远端 PE1、 PE1经 PE1-CE1 IP路由到达远端 CE1设备。
步骤 202: PE2开始自动重启。
步骤 203 : PE2在重启开始后， 触发 BFD session的建立， 也就 是进行故障消除通报。
步骤 204: BFD session建立后， 也就是 PE2和 CE2之间的 BFD 收敛， PE2向 CE2发送 BFD session U 消息。
这样， CE2收到来自 PE2的 BFD session U 的消息后， 就会将 流量回切到 PE2。
在实现本发明的过程中， 发明人发现现有技术至少存在以下问 题：
在 PE2设备重启过程中， 其控制平面的所有协议需要全部重启， 而 CE2-PE2上的 BFD要比公网 AS100内的 LDP、 BGP等协议收敛 快得多。 因此， 一旦 CE2-PE2上的 BFD session重建并 Up后， CE2 就会将部分流量回切到 PE2上， 恢复流量负载分担。 但是， 此时 PE2 在公网 AS100还未完成所有协议的收敛， 也就是说， PE2没有远端 VPN路由， 必然找不到可以转发流量的路径， 因而导致业务中断。
为此， 可以在 PE2重启过程中， 静态配置一个定时器， 用于等待 PE2在公网 AS 100内的协议收敛完成后，再触发 BFD session的重建。 也就是在步骤 203中， PE2先通过定时器进行计时等待， 在计时等待 结束后， 再进行故障消除通报。
虽然通过静态定时器的设置， 可以从一定程度上緩解 PE重启过 程中的业务中断问题。 但是， 由于无法准确设定公网内控制平面的收 敛时间， 导致定时器的时长设置很难定位。 故此， 这种方法不能从根 本上解决 PE重启过程中由于所述 CE在 PE没有远端 VPN路由的情 况下向所述 PE转发流量造成的业务中断问题。
另外， 如果在图 1提供的 VPN架构中， PE2所有上行链路发生 故障， 即， PE2-P1、 PE2-P2和 PE2-PE3链路全部故障。 在这种情况 下，本地 CE2设备通过 BFD根本无法检测到 PE2所有上行链路的故 障， 因此， 仍然将部分流量下发到 PE2、 PE3 , 做流量的负载负担； 而 PE2所有上行链路失效，也就是 PE2没有到达 PE1的远端 VPN路 由， 必然找不到可以转发流量的路径， 因而导致部分造成业务中断。 目前还无法解决这种问题， 急需相应的解决方案。
由此可见， 目前急需一种方法能够解决由于 CE在 PE没有远端 VPN路由的情况下向所述 PE转发流量造成的业务中断问题。
发明内容
本发明实施例提供一种虚拟专用网络 VPN故障处理方法和一种 网络提供商边界路由设备 PE, 以解决由于 CE在 PE没有远端 VPN 路由的情况下向所述 PE转发流量造成的业务中断问题。
以下为本发明实施例提供的技术方案：
一种虚拟专用网络 VPN故障处理方法， 该方法包括：
PE检测自身的远端 VPN路由数是否满足预先设定的要求，在所 述 PE的远端 VPN路由数不满足预先设定的要求时， 所述 PE利用故 障处理信息进行故障处理，直到所述 PE的远端 VPN路由数满足预先 设定的要求后利用故障处理信息进行故障消除通报。
一种网络提供商边界路由设备 PE, 该设备包括： 路由检测模块 和故障处理模块；
所述路由检测模块用于检测所述 PE自身的远端 VPN路由数是否 满足预先设定的要求， 在所述远端 VPN路由数不满足预先设定的要 求的情况下，通过向所述故障处理模块发送要求故障处理信息来控制 所述故障处理模块利用故障处理信息进行故障处理， 直到所述 PE的 远端 VPN路由数满足预先设定的要求后， 通过向所述故障处理模块 发送故障消除信息控制所述故障处理模块利用故障处理信息进行故 障消除通报。
与现有技术相比，本发明实施例提供的 VPN故障处理方法及 PE, 将 PE的远端 VPN路由数与故障处理信息相关联， 能够解决由于 CE 在 PE没有远端 VPN路由的情况下向所述 PE转发流量造成的业务中 断问题。 附图说明
图 1为现有技术中一种 VPN系统架构示意图；
图 2为现有技术中 VPN故障处理方法的流程图；
图 3为本发明实施例一提供的 VPN故障处理方法的流程图； 图 4为本发明实施例二提供的 VPN故障处理方法的流程图； 图 5为本发明实施例三提供的 VPN故障处理方法的流程图； 图 6为本发明实施例四釆用的一种 VPN系统架构示意图； 图 7为本发明实施例四提供的 VPN故障处理方法的流程图； 图 8为本发明实施例五提供的 VPN故障处理方法的流程图； 图 9为本发明实施例六提供的 PE的结构示意图；
图 10为本发明实施例七提供的 PE的结构示意图。
具体实施方式 为使本发明的目的、技术方案和优点表达得更加清楚明白， 下面 结合附图及具体实施例对本发明再作进一步详细的说明。
本发明的实施例提供了一种 VPN故障处理方法， PE检测自身的 远端 VPN路由数， 在所述 PE的远端 VPN路由数不满足预先设定的 要求时， 所述 PE利用故障处理信息进行故障处理， 直到所述 PE的 远端 VPN路由数满足预先设定的要求后进行故障消除通报。
实施例一： 不满足预先设定的要求。 例如， PE的上行链路全部发生故障导致 CE 在 PE没有远端 VPN路由的情况下向所述 PE转发流量， 或者 PE重 启的过程中， PE在公网内的协议没有收敛导致 CE在 PE没有远端 VPN路由的情况下向所述 PE转发流量。
图 3为本发明实施例一提供的 VPN故障处理方法的流程图。 如 图 3所示， 本实施例提供的 VPN故障处理方法可以包括：
步骤 301： PE检测自身的远端 VPN路由数是否满足预先设定的 要求， 如果所述远端 VPN路由数满足预先设定的要求， 则执行步骤 302, 否则执行步骤 303。
这里所述 PE检测自身的远端 VPN路由数是否满足预先设定的要 求的方法可以包括：
预先设置一个远端 VPN路由数的阔值；
如果 PE的远端 VPN路由数低于或等于所述阔值， 则判定所述 PE的远端 VPN路由数不满足预先设定的要求；
如果 PE的远端 VPN路由数高于所述阔值， 则判定所述 PE的远 端 VPN路由数满足预先设定的要求。
较佳地，还可以在 PE的远端 VPN路由数高于预先设定的阔值时， 通过定时器进行计时， 直到达到预先设定的时间， 计时结束， 再执行 步骤 302。 这使得对远端 VPN路由数的要求可以根据不同需要随意 设定， 提高了应用的灵活性及 PE进行故障处理的性能。
步骤 302: PE利用故障处理信息进行故障消除通 ^艮。所述故障处 理信息可以为 BFD , 也可以为缺省路由。
步骤 303: ΡΕ 利用故障处理信息进行故障处理， 继续执行步骤
301。
这里所述利用故障处理信息进行故障处理的方法可以包括：判断 所述 ΡΕ与所述 CE之间是否存在故障处理信息会话， 如果存在， 则 利用故障处理信息进行故障出现通 否则， 利用故障处理信息进行 等待恢复处理。
这里所述 ΡΕ可以周期性检测自身的远端 VPN路由数。
由此可见，本发明实施例一提供的方法将 ΡΕ的远端 VPN路由数 与故障处理信息相关联， 用远端 VPN路由数控制故障处理信息进行 故障处理或故障消除通报，只有在 ΡΕ的远端 VPN路由数满足预先设 定的要求的情况下，才允许归属于所述 ΡΕ的 CE向所述 ΡΕ转发流量， 通过本实施例能够解决现有技术中由于 CE在 ΡΕ没有远端 VPN路由 的情况下向所述 ΡΕ转发流量造成的业务中断问题。
下面， 分别就故障处理信息为 BFD (即根据 BFD session的状态 上报故障）和缺省路由 （即根据缺省路由 session的状态上报故障） 这两种情况下， 对本发明实施例提供的 VPN故障处理方法进行详细 说明。
本发明实施例提供的 VPN故障处理方法中， 在故障处理信息为 BFD的情况下， 所述故障处理信息会话为 BFD session; PE釆用将 BFD session置为 Admindown的方式进行故障出现通 4艮； 或釆用抑制 BFD session建立的方式进行等待恢复处理，釆用触发 BFD session建 立的方式进行故障消除通报。
下面釆用图 1的 VPN系统架构，在 PE发生故障，故障处理信息 为 BFD的情况下，对本发明实施例提供的 VPN故障处理方法作进一 步详细说明。
实施例二：
在 PE2出现故障的情况下， 图 4为本发明实施例二提供的 VPN 故障处理方法的流程图。 预先设定检测远端 VPN路由数的阔值为 0。 如图 4所示， 本实施例提供的 VPN故障处理方法可以包括： 步骤 401 : PE2出现故障时， PE2的 BFD session的状态会自动为 Down。
本步骤中， 在 BFD session Down之后， 会使得 CE2通过 BFD检 测到 PE2的 BFD session为 Down, 进而选择其它可以利用的路由转 发流量。 这里， CE2可以将全部流量切换至 PE3。 即流量全部从 CE2 经 CE2-PE3 IP路由至 PE3、 PE3经 VPN路由 2至远端 PE1、 PE1经 PE1-CE1 IP路由到达远端 CE1设备。
步骤 402: PE2开始自动重启。
步骤 403: PE2检测自身远端 VPN路由数， 如果所述远端 VPN 路由数满足预先设定的要求， 则执行步骤 407, 否则执行步骤 404。
这里，检测远端 VPN路由数是否满足预先设定要求的方法包括： 如果 PE2的远端 VPN路由数大于 0,则判定 PE2的远端 VPN路由数 满足预先设定的要求， 否则， 判定 PE2的远端 VPN路由数不满足预 先设定的要求。 如果此时 PE2在公网 AS100内的协议未完成收敛， 则 PE2接收不到远端路由， 那么 PE2的远端 VPN路由数就为 0, 检 测结果为 PE2的远端 VPN路由数不满足预先设定的要求。 如果此时 PE2在公网 AS 100内的协议已经完成收敛， 那么 PE2的远端 VPN路 由数就不为 0, 检测结果为 PE2的远端 VPN路由数满足预先设定的 要求。
步骤 404: PE2判断 PE2与 CE2之间是否存在 BFD session, 如 果是， 则执行步骤 406, 否则执行步骤 405。
在本实施例中， 由于此时 PE2重启， BFD session还没有建立， 所以判断结果为 PE2和 CE2之间不存在 BFD session„
步骤 405: PE2进行等待恢复处理， 即抑制 BFD session的建立， 返回步骤 403。
所述抑制 BFD session建立的方法有很多种， 例如： PE2可以通 过不向 CE2发送 BFD session U 消息来抑制 BFD session的建立； 也 可以通过不接收来自 CE2的控制消息来抑制 BFD session的建立等， 这里不再赘述。 只要 BFD session不建立， CE2就不会向 PE2转发流 量。
步骤 406: PE2将 BFD session置为 Admindown, 返回步骤 403。 本步骤中， CE2会通过 BFD检测到 PE2的 BFD session为 Down, 进而选择其它可以利用的路由转发流量。 这里， CE2可以将全部流量 切换至 PE3。 即流量全部从 CE2经 CE2-PE3 IP路由至 PE3、 PE3经 VPN路由 2至远端 PE1、PE1经 PE1-CE1 IP路由到达远端 CE1设备。
步骤 407: PE2进行故障消除通报，即触发 PE2与 CE2之间 BFD session 建立。
步骤 408: BFD session建立， 也就是 PE2和 CE2之间的 BFD收 敛， PE2向 CE2发送 BFD session U 消息。
CE2收到来自 PE2的 BFD session U 的消息后， 将流量回切到
PE2。
步骤 403〜步骤 407中， PE2在重启开始后，如果没有接收到 PE1 或 PE3发布的远端 VPN路由， 就会抑制 BFD session的建立， 直到 判断远端 VPN路由数不为 0之后，再触发 BFD session的建立。这就 有效解决了由于 PE2和 CE2之间的 BFD session已经建立， 而 PE2 没有远端 VPN路由所导致的业务中断的问题。
下面釆用图 1的 VPN系统架构，在 PE的所有上行链路发生故障， 即 PE2-P1、 PE2-P2和 PE2-PE3链路全部故障， 故障处理信息为 BFD 的情况下， 对本发明提供的 VPN故障处理方法作进一步详细说明。
实施例三：
在本实施例中， 假设 PE2的上行链路全部发生故障， 即 PE2-P1、 PE2-P2和 PE2-PE3链路全部故障， 而 PE2没有发生故障。
图 5为本发明实施例三提供的 VPN故障处理方法的流程图。 预 先设定检测远端 VPN路由数的阔值为 0。 如图 5所示， 本实施例提 供的 VPN故障处理方法可以包括：
步骤 501 : PE2检测自身远端 VPN路由数， 如果所述远端 VPN 路由数满足预先设定的要求， 则执行步骤 505, 否则执行步骤 502。 如果此时 PE2的上行链路全部失效， 则 PE2接收不到远端路由， 那 么 PE2的远端 VPN路由数就为 0, 检测结果为： 远端 VPN路由数不 满足预先设定的要求。 如果此时 PE2 的上行链路已经部分或全部收 敛， 那么 PE2的路由数就不为 0, 检测结果为： PE2的远端 VPN路 由数满足要求。
步骤 502: PE2判断 PE2与 CE2之间是否存在 BFD session, 如 果是， 则执行步骤 503 , 否则执行步骤 504。
在本实施例中， PE2正常工作， PE2和 CE2之间的 BFD session 已经建立， 判断结果为 PE2和 CE2之间存在 BFD session。 如果此时 PE2故障重启 , PE2和 CE2之间的 BFD session还没有建立 , 则判 断结果为 PE2和 CE2之间不存在 BFD session,如实施例二中的情况。
步骤 503: PE2进行故障出现通报。 具体方法为： 将 BFD session 置为 Admindown , 返回步骤 501。
这会使得 CE2通过 BFD检测到 PE2的 BFD session为 Down,进 而选择其它可以利用的路由转发流量。 这里， CE2可以将全部流量切 换至 PE3。即流量全部从 CE2经 CE2-PE3 IP路由至 PE3、PE3经 VPN 路由 2至远端 PE1、 PE1经 PE1-CE1 IP路由到达远端 CE1设备。
步骤 504: PE2进行等待恢复处理， 即抑制 BFD session的建立， 返回步骤 501。
步骤 505: PE2进行故障消除通报，即触发 PE2与 CE2之间 BFD session 建立。
步骤 506: BFD session建立， 也就是 PE2和 CE2之间的 BFD收 敛， PE2向 CE2发送 BFD session U 消息。
CE2收到来自 PE2的 BFD session U 的消息后， 将流量回切到 PE2。
步骤 501〜步骤 505 中， PE2在所有上行链路出现故障时， 釆用 将 BFD session置为 Admindown的方式进行故障出现通 使得 CE2 可以通过 BFD检测到 PE2上行链路故障， 进而选择其它可以利用的 路由转发流量。 这就解决了现有技术中， 由于 CE2无法通过 BFD检 测 PE2有无远端 VPN路由， 而在 PE2没有远端 VPN路由的情况下 仍然向 PE2转发流量所导致的业务中断问题。
实施例二和实施例三釆用图 1的 VPN系统架构， 在故障处理信 了详细的说明。
相应的， 本发明实施例提供的 VPN故障处理方法中， 在故障处 理信息为缺省路由的情况下，所述故障处理信息会话为缺省路由的发 布； PE釆用抑制向归属于所述 PE的 CE发布缺省路由， 并向所述 CE发送撤销缺省路由消息的方式进行故障出现通报； 釆用抑制向所 述 CE发布缺省路由的方式进行等待恢复处理； 釆用向所述 CE发布 缺省路由的方式进行故障消除通报。
下面釆用图 6的 VPN系统架构， 在故障处理信息为缺省路由的 情况下， 对本发明提供的 VPN故障处理方法作进一步详细说明。
图 6为本发明实施例一种 VPN系统架构示意图。 如图 6所示：
CE1和 CE2同属一个 VPN, CE2双归属两个本地 PE, 即图中的 PE2、 PE3。 在公网 AS100内， 远端 PE1和本地 PE2、 PE3分别建立 IBGP邻居关系， PE2和 PE3可以同时接收到远端 PE1发布的远端 VPN路由，分别为图中的 VPN路由 1和 VPN路由 2。这里 PE2的远 端 VPN路由是指 PE1发布给 PE2的 VPN路由。 PI、 P2分别和 PE1、 PE2、 PE3建立 IGP邻居关系。 本地 PE2、 PE3与 CE2设备之间釆用 OSPF/ISIS或 BGP等路由协议进行链路和节点故障的实时检测； 同 时， PE2发布一条缺省路由给 CE2, CE2优选这条缺省路由转发流量， 即： 流量从 CE2经缺省路由至 PE2、 PE2经 PE2->P1->PE1 VPN路由 1至远端 PE1、 PE1再经 PE1->CE1 IP路由到达 CE1 ; 或者， CE2将 PE2发布的缺省路由、 和 PE3发布的 IP路由做流量负载分担， 即将 流量一分为二： 一部分从 CE2 经缺省路由至 PE2、 PE2 经 PE2->P1->PE1 VPN路由 1至远端 PE1、 PE1再经 PE1->CE1 IP路由 到达 CE1 ; 同时， 另一部分从 CE2经 CE2->PE3 IP路由至 PE3、 PE3 经 PE3->P2->PE1 VPN路由 2至远端 PE1、 PE1再经 PE1->CE1 IP路 由到达 CE1。
首先釆用图 6的 VPN业务部署实施， 在故障处理信息为缺省路 进一步详细说明。
实施例四：
在 PE2发生故障的情况下， 图 7为本发明实施例四提供的 VPN 故障处理方法的流程图。 预先设定检测远端 VPN路由数的阔值为 0。 如图 7所示， 本实施例提供的 VPN故障处理方法可以包括：
步骤 701 : PE2自动停止发送消息， 进行故障出现通报。
本步骤中， CE2会通过 OSPF/ISIS或 BGP等路由协议可以检测 到 PE2 故障， 进而选择其它可以利用的路由转发流量。 这里， CE2 可以将全部流量切换至 PE3。 即流量全部从 CE2经 CE2-PE3 IP路由 至 PE3、 PE3经 VPN路由 2至远端 PE1、 PE1经 PE1-CE1 IP路由到 达远端 CE1设备。
步骤 702: PE2由于故障会开始自动重启。
步骤 703: PE2检测自身的远端 VPN路由数， 即 PE1发布的远 端 VPN路由数， 如果所述远端 VPN路由数满足预先设定的要求， 则 执行步骤 707 , 否则执行步骤 704。
如果此时 PE2在公网 AS100内的协议未完成收敛， 则 PE2接收 不到远端路由， 那么 PE2的远端 VPN路由数就为 0, 检测结果为： 远端 VPN路由数不满足预先设定的要求。如果此时 PE2在公网 AS100 内的协议已经完成收敛， 那么 PE2的路由数就不为 0, 检测结果为： PE2的远端 VPN路由数满足要求。
步骤 704： PE2判断 PE2与 CE2之间是否存在缺省路由的发布， 如果是， 则执行步骤 706, 否则执行步骤 705。
在本实施例中， 由于 PE2重启， 所以还没有开始发布缺省路由， 判断结果为 PE2和 CE2之间不存在缺省路由的发布。
步骤 705: PE2进行等待恢复处理， 即抑制 PE2向 CE2发布缺省 路由， 返回步骤 703。 本步骤中， CE2如果接收不到来自 PE2的缺省路由， 就不会向 PE2转发流量。
步骤 706: PE2停止向 CE2发布缺省路由， 同时向 CE2发送缺 省路由撤销消息， 返回步骤 703。
本步骤中， CE2接收到来自 PE2的缺省路由撤销消息后， 会选 择其它可以利用的路由转发流量。 这里， CE2可以将全部流量切换至 PE3。 即流量全部从 CE2经 CE2-PE3 IP路由至 PE3、 PE3经 VPN路 由 2至远端 PE1、 PE1经 PE1-CE1 IP路由到达远端 CE1设备。
步骤 707: PE2进行故障消除通 向 CE2发布缺省路由。
这会使得 CE2收到来自 PE2的缺省路由后， 将流量回切到 PE2。
CE2将流量回切到 PE2 的方法可以为： 通过缺省路由将全部流量回 切到 PE2, PE2再通过远端 VPN路由转发流量； 或者， 通过缺省路 由将部分流量回切至 PE2, 和 PE3发布的 IP路由一起， 恢复流量的 负载分担。 至于是全部回切还是负载分担， 可以依据不同的应用需要 来选择。
步骤 703〜步骤 707中， PE2在重启开始后， PE2不会在 PE2与 CE2之间的路有协议收敛后马上向 CE2发布缺省路由， 而是抑制向 CE2发布缺省路由，直到判断远端 VPN路由数不为 0之后，再向 CE2 发布缺省路由。 这有效解决了由于向 CE2发布了缺省路由， 而 PE2 没有远端 VPN路由，导致 CE2向 PE2转发流量进而造成业务中断的 问题。
下面釆用图 6的 VPN系统架构，在 PE的所有上行链路发生故障， 即 PE2-P1、 PE2-P2和 PE2-PE3链路全部故障， 故障处理信息为路由 协议的情况下， 对本发明提供的 VPN故障处理方法作进一步详细说 明。
实施例五：
PE2的上行链路全部发生故障， 即 PE2-P1、 PE2-P2和 PE2-PE3 链路全部故障。
图 8为本发明实施例五提供的 VPN故障处理方法的流程图。 预 先设定检测远端 VPN路由数的阔值为 0。 如图 8所示， 本实施例提 供的 VPN故障处理方法可以包括：
步骤 801 : PE2检测自身远端 VPN路由数， 如果所述远端 VPN 路由数满足预先设定的要求， 则执行步骤 805, 否则执行步骤 802。 如果此时 PE2的上行链路全部失效， 则 PE2接收不到远端路由， 那 么 PE2的远端 VPN路由数就为 0, 检测结果为： 远端 VPN路由数不 满足预先设定的要求。 如果此时 PE2 的上行链路已经部分或全部收 敛， 那么 PE2的路由数就不为 0, 检测结果为： PE2的远端 VPN路 由数满足要求。
步骤 802： PE2判断 PE2与 CE2之间是否存在缺省路由的发布， 如果是， 则执行步骤 803 , 否则执行步骤 804。
在本实施例中， 由于此时 PE2正在正常工作， 所以 PE2和 CE2 之间已存在缺省路由的发布， 判断结果为 PE2和 CE2之间存在缺省 路由的发布。 如果此时 PE2故障重启， 那么 PE2和 CE2之间还不存 在缺省路由， 如实施例三中的情况。
步骤 803: PE2进行故障出现通报。 具体方法为： 停止向 CE2发 布缺省路由， 并向 CE2发送缺省路由 4敦销消息， 返回步骤 801。
本步骤中， CE2接收到来自 PE2的缺省路由撤销消息后， 会选 择其它可以利用的路由转发流量。 本实施例中， CE2将流量全部切换 至 PE3。 即流量全部从 CE2经 CE2-PE3 IP路由至 PE3、 PE3经 VPN 路由 2至远端 PE1、 PE1再经 PE1-CE1 IP路由到达远端 CE1设备。
步骤 804: PE2进行等待恢复处理， 即抑制 PE2向 CE2发布缺省 路由， 返回步骤 801。
本步骤中， CE2如果接收不到来自 PE2的缺省路由， 就不会向 PE2转发流量。
步骤 805: PE2进行故障消除通 即 PE2向 CE2发布缺省路由。 如果 CE2收到来自 PE2的缺省路由，会将流量回切到 PE2。 CE2 将流量回切到 PE2 的方法可以为： 通过缺省路由将流量全部回切到 PE2, PE2再通过远端 VPN路由转发流量； 或者， 通过缺省路由将部 分流量回切至 PE2, 和 PE3发布的 IP路由一起， 恢复流量的负载分 担。至于是全部回切还是负载分担，可以依据不同的应用需要来选择。
步骤 801〜步骤 805 中， PE2在所有上行链路出现故障时， 釆用 停止向 CE2发布缺省路由并向 CE2发送缺省路由撤销消息的方式进 行故障出现通报， 使得 CE2在接收到缺省路由撤销消息后， 选择其 它可以利用的路由转发流量。 这就有效的解决了现有技术中， 由于 CE2无法通过路由协议检测 PE2有无远端 VPN路由， 而在 PE2没有 远端 VPN路由的情况下继续向 PE2转发流量所导致的业务中断问题。
在以上五个实施例中， 也可以将远端 VPN路由数目的阔值设置 为一个非零的值。 例如， 设置所述阔值为 2, 如果 PE的远端 VPN路 由数小于或等于 2,就判定所述 PE的远端 VPN路由数不满足预先设 定的要求；如果 PE的远端 VPN路由数大于 2,则判定 PE的远端 VPN 路由数满足预先设定的要求。 当然，判定 PE的远端 VPN路由数是否 满足预先设定的要求的方式也可以为：如果 PE的 VPN低于预先设定 的阔值， 则判定所述 PE的远端 VPN路由数不满足预先设定的要求， 否则判定所述 PE的远端 VPN路由数满足预先设定的要求。
另外，还可以静态配置一个定时器。 当 PE的远端 VPN路由数大 于预先设定的阔值时， 通过定时器进行计时， 以此来等待 PE接收到 更多的路由， 直到达到预先设定的时间， 定时器计时结束， 再继续执 行故障消除通报的步骤。定时器的计时时间可以依据不同的应用场景 来选择。 这使得对远端 VPN路由数的要求可以根据不同需要随意设 定， 提高了应用的灵活性及 PE进行故障处理的性能。
基于本发明实施例提供的 VPN故障处理方法， 本发明实施例还 提供了一种网络提供商边界路由设备 PE。
实施例六：
图 9为本发明实施例六提供的 PE的结构示意图。 如图 9所示， 本发明实施例提供的 PE包括路由检测模块 901和故障处理模块 902。
路由检测模块 901用于检测 PE自身的远端 VPN路由数是否满足 预先设定的要求， 在所述远端 VPN路由数不满足预先设定的要求的 情况下， 通知故障处理模块 902利用故障处理信息进行故障处理； 直 到所述 PE的远端 VPN路由数满足预先设定的要求后，通知所述故障 处理模块 902利用故障处理信息进行故障消除通报。
故障处理模块 902用于接收来自路由检测模块 901的通知，如果 接收到来自路由检测模块 901的故障处理的通知，则利用故障处理信 息进行故障处理；如果接收到来自路由检测模块 901的故障消除通报 的通知， 则利用故障处理信息进行故障消除通报。 这里故障处理模块 902可以为 BFD模块， 所述故障处理信息为 BFD; 故障处理模块 902 也可以为缺省路由模块， 所述故障处理信息为缺省路由。
故障处理模块 902 还可以包括判别子模块 9021 和处理子模块 9022;
判别子模块 9021用于接收来自路由检测模块 901的故障处理的 通知， 并在接收到所述故障处理的通知后判定 PE与归属于所述 PE 的 CE间是否存在故障处理信息会话，如果是，则通知处理子模块 9022 利用故障处理信息进行故障出现通报， 否则， 通知处理子模块 9022 利用故障处理信息进行等待恢复处理；
处理子模块 9022用于接收来自判别子模块 9021或路由检测模块 901的通知，根据接收到的通知利用故障处理信息进行故障出现通报、 等待恢复处理或故障消除通报。
由此可见，本发明实施例六提供的 PE中，路由检测模块通过 PE 自身的远端 VPN路由数来控制故障处理模块利用故障处理信息进行 故障处理。也就是说，本发明实施例提供的 PE将自身的远端 VPN路 由数与故障处理信息相关联，只有在所述 PE的远端 VPN路由数满足 预先设定要求时， 才允许归属于所述 PE的 CE向所述 PE转发流量。 因此，能够解决现有技术中由于 CE在 PE没有远端 VPN路由的情况 下向所述 PE转发流量造成的业务中断问题。
下面对本发明实施例提供的 PE作进一步详细说明。
实施例七：
图 10为本发明实施例七提供的 PE的结构示意图。如图 10所示， 本发明实施例提供的 PE 包括： 路由检测模块 101 和故障处理模块 102。
故障处理模块 102包括判别子模块 1021和处理子模块 1022。 处理子模块 1022 包括故障出现通^艮模块 10221、 等待恢复模块 10222和故障消除通 模块 10223。
路由检测模块 101用于检测 PE自身的远端 VPN路由数是否满足 预先设定的要求， 在所述远端 VPN路由数不满足预先设定的要求的 情况下， 通知故障处理模块 102的判别子模块 1021利用故障处理信 息进行故障处理，直到所述 PE的远端 VPN路由数满足预先设定的要 求后，通知故障消除通^艮模块 10223利用故障处理信息进行故障消除 通报。
判别子模块 1021用于接收来自所述路由检测模块 101的通知， 并在接收到所述通知后判定所述 PE与归属于所述 PE的 CE间是否存 在故障处理信息会话， 如果是， 则通知故障出现通报模块 10221利用 故障处理信息进行故障出现通报， 否则， 通知等待恢复模块 10222利 用故障处理信息进行等待恢复处理。
故障出现通报模块 10221用于接收来自所述判别子模块 1021的 故障出现通报的通知， 在接收到所述通知后， 利用故障处理信息进行 故障出现通报。
等待恢复模块 10222用于接收来自所述判别子模块 1021的等待 恢复处理的通知， 在接收到所述通知后， 利用故障处理信息进行等待 恢复处理。
故障消除通报模块 10223用于接收来自路由检测模块 101的故障 消除通报的通知， 在接收到所述通知后， 利用故障处理信息进行故障 消除通报。
这里，故障处理模块 102可以为 BFD模块，故障处理信息为 BFD, 故障处理信息会话为 BFD session, 这种情况下：
BFD模块的故障出现通报模块 10221 用于在接收到来自判别子 模块 1021 的故障出现通报的通知后， 将 BFD session 置为 Admindown。 这使得归属于 PE的 CE通过 BFD可以检测到所述 PE 故障， 进而选择其它可以利用的路由转发流量。
BFD模块的等待恢复模块 10222用于在接收到来自判别子模块 1021的等待恢复处理的通知后， 抑制 BFD session的建立。 这使得归 属于 PE的 CE在没有 BFD session建立的情况下， 不会向所述 PE转 发流量。
BFD模块的故障消除通报模块 10223用于在接收到来自路由检 测模块 101的故障消除通报的通知后， 触发 BFD session的建立。 这 使得归属于所述 PE的 CE在 BFD session建立后，可以接收到来自所 述 BFD session U 消息， 并在接收到 BFD session U 消息后，将流量 回切到所述 PE。
另外， 故障处理模块 102也可以为缺省路由模块， 故障处理信息 为缺省路由， 故障处理信息会话为缺省路由的发布， 这种情况下： 缺省路由模块的故障出现通报模块 10221 用于在接收到来自判 别子模块 1021 的故障出现通报的通知后， 停止向归属于所述 PE的 CE发布缺省路由并发送缺省路由撤销消息。 这使得归属于 PE的 CE 可以在接收到缺省路由撤销消息后， 检测到 PE故障， 进而选择其它 可以利用的路由转发流量。
缺省路由模块的等待恢复模块 10222 用于在接收到来自判别子 模块 1021等待恢复处理的通知后， 抑制 PE向归属于所述 PE的 CE 发布缺省路由。 这使得归属于 PE的 CE在没有缺省路由的情况下， 不会向所述 PE转发流量。
故障消除通报模块 10223用于在接收到来自路由检测模块 101的 故障消除通报的通知后， 向归属于所述 PE的 CE发布缺省路由。 这 使得归属于所述 PE的 CE可以在接收到来自所述 PE的缺省路由之 后， 将流量回切到所述 PE。
路由检测模块 101判定远端 VPN路由数是否满足预先设定的要 求的实现方式有很多种， 例如， 可以预先设定一个阔值， 当远端 VPN 路由数低于或等于这个阔值时， 判定远端 VPN路由数不满足预先设 定的要求， 向故障处理模块 102发送要求故障处理信息， 否则， 判定 远端 VPN路由数满足预先设定的要求， 向故障处理模块 102发送故 障消除信息。
另外， 路由检测模块 101还可以包括定时器 1011。 定时器 1011 用于在路由检测模块 101判定 PE的远端 VPN路由数满足预先设定的 要求后进行计时， 直到达到预先设定的时间， 计时结束， 再触发路由 检测模块 101 向故障处理模块 102发送故障消除信息。 这使得远端 VPN路由数在满足要求之后， 进一步以预先设定的时间等待更多的 远端 VPN路由。定时器 1011的计时时间可以根据不同的应用需要来 选择。
由以上内容可以看出， 本发明实施例提供的 PE, 可以在自身远 端 VPN路由数不满足预先设定的要求的情况下， 利用故障处理信息 进行故障处理， 直到远端 VPN路由数满足要求后， 再利用故障处理 信息进行故障消除通报。 这有效解决了由于 CE在 PE没有远端 VPN 路由的情况下向所述 PE转发流量造成的业务中断问题。 另外， 本发 明实施例提供的 PE可以根据实际应用需要设定远端 VPN路由数的阔 值， 还可以在此基础上釆用定时器来等待更多的远端 VPN路由数， 进而可以灵活控制对远端 VPN路由数的要求， 提高 PE的性能。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解 到本发明， 可以通过硬件实现， 也可以借助软件加必要的通用硬件平 台的方式来实现。基于这样的理解， 本发明的技术方案可以以软件产 品的形式体现出来， 该软件产品可以存储在一个非易失性存储介质 (可以是 CD-ROM, U盘， 移动硬盘等） 中， 包括若干指令用以使 得一台计算机设备（可以是个人计算机， 服务器， 或者网络设备等） 执行本发明各个实施例所述的方法。
总之， 以上所述仅为本发明的较佳实施例而已， 并非用于限定本 发明的保护范围。 凡在本发明的精神和原则之内， 所作的任何修改、 等同替换、 改进等， 均应包含在本发明的保护范围之内。

Claims

权利要求
1、 一种虚拟专用网络 VPN故障处理方法， 其特征在于， 该方法 包括：
网络提供商边界路由设备 PE检测自身的远端 VPN路由数是否满 足预先设定的要求， 当所述远端 VPN路由数不满足预先设定的要求 时，所述 PE利用故障处理信息进行故障处理， 当所述远端 VPN路由 数由不满足预先设定的要求转为满足预先设定的要求后利用故障处 理信息进行故障消除通报。
2、 如权利要求 1所述的方法， 其特征在于， 所述利用故障处理 信息进行故障处理的方法包括：
判断所述 PE与归属于所述 PE的 CE之间是否存在故障处理信息 会话， 如果存在， 则利用故障处理信息进行故障出现通报， 否则， 利 用故障处理信息进行等待恢复处理。
3、 如权利要求 2所述的方法， 其特征在于， 所述故障处理信息 为双向转发检测 BFD, 所述故障处理信息会话为双向转发检测会话 BFD session;
所述利用故障处理信息进行故障出现通报的方法包括： 将 BFD session置为管理未建立 Admindown;
所述利用故障处理信息进行等待恢复处理的方法包括:抑制 BFD session 建立；
所述利用故障处理信息进行故障消除通 的方法包括：触发 BFD session 建立。
4、 如权利要求 2所述的方法， 其特征在于， 所述故障处理信息 为缺省路由， 所述故障处理信息会话为缺省路由的发布；
所述利用故障处理信息进行故障出现通 的方法包括： 所述 PE 停止向所述 CE发布缺省路由，并向所述 CE发送缺省路由 4敦销消息； 所述利用故障处理信息进行等待恢复处理的方法包括：抑制所述 PE向所述 CE发布缺省路由； 所述利用故障处理信息进行故障消除通报的方法包括： 向所述
CE发布缺省路由。
5、 如权利要求 1~4任一所述的方法， 其特征在于， 所述 PE检 测自身的远端 VPN路由数是否满足预先设定的要求的方法包括： 预先设置一个检测远端 VPN路由数的阔值；
如果 PE的远端 VPN路由数低于或等于所述阔值， 则判定所述 PE的远端 VPN路由数不满足预先设定的要求；
如果 PE的远端 VPN路由数高于所述阔值， 则判定所述 PE的远 端 VPN路由数满足预先设定的要求。
6、 如权利要求 1~4任一所述的方法， 其特征在于， 当所述远端 VPN路由数由不满足预先设定的要求转为满足预先设定的要求后利 用故障处理信息进行故障消除通 包括：
在所述 PE检测到自身的远端 VPN路由数满足预先设定的要求 后， 就利用故障处理信息进行故障消除通报。
7、 如权利要求 1~4任一所述的方法， 其特征在于， 当所述远端 VPN路由数由不满足预先设定的要求转为满足预先设定的要求后利 用故障处理信息进行故障消除通 包括：
在所述 PE检测到自身的远端 VPN路由数满足预先设定的要求 后， 通过定时器进行计时， 直到达到预先设定的时间， 计时结束， 再 利用故障处理信息进行故障消除通报。
8、一种网络提供商边界路由设备 PE,其特征在于，该设备包括： 路由检 'J模块和故障处理模块；
所述路由检测模块，用于检测所述 PE自身的远端 VPN路由数是 否满足预先设定的要求， 在所述远端 VPN路由数不满足预先设定的 要求的情况下，通知所述故障处理模块利用故障处理信息进行故障处 理， 当所述远端 VPN路由数由不满足预先设定的要求转为满足预先 设定的要求后，通知所述故障处理模块利用故障处理信息进行故障消 除通报；
所述故障处理模块用于接收来自所述路由检测模块的通知，根据 接收到的通知利用故障处理信息进行故障处理或故障消除通报。
9、 如权利要求 8所述的设备， 其特征在于， 所述故障处理模块 包括判别子模块和处理子模块，所述故障处理为故障出现通报或等待 恢复处理；
所述判别子模块用于接收来自所述路由检测模块的故障处理的 通知， 并在接收到所述故障处理的通知后判定 PE与归属于所述 PE 的 CE间是否存在故障处理信息会话， 如果是， 则通知所述处理子模 块利用故障处理信息进行故障出现通报， 否则， 通知所述处理子模块 利用故障处理信息进行等待恢复处理；
所述处理子模块用于接收来自所述判别子模块通知，根据接收到 的通知利用故障处理信息进行故障出现通报、等待恢复处理或故障消 除通报。
10、 如权利要求 9所述的设备， 其特征在于， 所述处理子模块包 括故障出现通报模块、 等待恢复模块和故障消除通报模块；
所述故障出现通报模块用于接收来自所述判别子模块的故障出 现通报的通知， 在接收到所述通知后， 利用故障处理信息进行故障出 现通报；
所述等待恢复模块用于接收来自所述判别子模块的等待恢复处 理的通知， 在接收到所述通知后， 利用故障处理信息进行等待恢复处 理；
所述故障消除通报模块用于接收来自路由检测模块的故障消除 通报的通知， 在接收到所述通知后， 利用故障处理信息进行故障消除 通报。
11、 如权利要求 10所述的设备， 其特征在于， 所述故障处理模 块为 BFD模块， 所述故障处理信息为 BFD, 所述故障处理信息会话 为 BFD session;
所述利用故障处理信息进行故障出现通报为： 将 BFD session置 为 Admindown;
所述利用故障处理信息进行等待恢复处理为： 抑制 BFD session 的建立；
所述利用故障处理信息进行故障消除通 ^艮为： 触发 BFD session 的建立。
12、 如权利要求 10所述的设备， 其特征在于， 所述故障处理模 块为缺省路由模块， 所述故障处理信息为缺省路由， 所述故障处理信 息会话为缺省路由的发布；
所述利用故障处理信息进行故障出现通报为：停止发布缺省路由 并发送缺省路由 4敦销消息；
所述利用故障处理信息进行等待恢复处理为：抑制缺省路由的发 布；
所述利用故障处理信息进行故障消除通报为： 发布缺省路由。
13、 如权利要求 8~12任一所述的设备， 其特征在于， 所述路由 检测模块进一步包括定时器；
所述定时器用于在判定所述远端 VPN路由数满足预先设定的要 求后进行计时， 直到达到预先设定的时间， 计时结束， 再通知所述故 障处理模块利用故障处理信息进行故障消除通报。
PCT/CN2008/073121 2007-11-30 2008-11-20 Procédé de traitement d'échec de vpn et routeur pe pour fournisseur de réseau WO2009071024A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200710188274.8 2007-11-30
CN2007101882748A CN101170450B (zh) 2007-11-30 2007-11-30 虚拟专用网络故障处理方法及网络提供商边界路由设备

Publications (1)

Publication Number Publication Date
WO2009071024A1 true WO2009071024A1 (fr) 2009-06-11

Family

ID=39390929

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2008/073121 WO2009071024A1 (fr) 2007-11-30 2008-11-20 Procédé de traitement d'échec de vpn et routeur pe pour fournisseur de réseau

Country Status (2)

Country Link
CN (1) CN101170450B (zh)
WO (1) WO2009071024A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105791156A (zh) * 2016-03-03 2016-07-20 盛科网络（苏州）有限公司 一种支持多种bfd发送时间的芯片实现方法

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101170450B (zh) * 2007-11-30 2010-07-07 华为技术有限公司 虚拟专用网络故障处理方法及网络提供商边界路由设备
CN109274546B (zh) * 2018-08-07 2020-08-14 新华三技术有限公司 一种定时器调度方法及装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006101825A2 (en) * 2005-03-18 2006-09-28 Cisco Technology, Inc. Algorithm for backup pe selection
CN1913457A (zh) * 2005-08-10 2007-02-14 华为技术有限公司 对双向转发链路进行故障检测的方法
CN1933422A (zh) * 2006-09-30 2007-03-21 成都迈普产业集团有限公司 网络故障切换方法
CN1968159A (zh) * 2006-11-16 2007-05-23 杭州华为三康技术有限公司 网络故障检测联动方法及网络运营商边缘设备
US20070121486A1 (en) * 2005-11-28 2007-05-31 James Guichard System and method for PE-node protection
CN101170450A (zh) * 2007-11-30 2008-04-30 华为技术有限公司 虚拟专用网络故障处理方法及网络提供商边界路由设备

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006101825A2 (en) * 2005-03-18 2006-09-28 Cisco Technology, Inc. Algorithm for backup pe selection
CN1913457A (zh) * 2005-08-10 2007-02-14 华为技术有限公司 对双向转发链路进行故障检测的方法
US20070121486A1 (en) * 2005-11-28 2007-05-31 James Guichard System and method for PE-node protection
CN1933422A (zh) * 2006-09-30 2007-03-21 成都迈普产业集团有限公司 网络故障切换方法
CN1968159A (zh) * 2006-11-16 2007-05-23 杭州华为三康技术有限公司 网络故障检测联动方法及网络运营商边缘设备
CN101170450A (zh) * 2007-11-30 2008-04-30 华为技术有限公司 虚拟专用网络故障处理方法及网络提供商边界路由设备

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105791156A (zh) * 2016-03-03 2016-07-20 盛科网络（苏州）有限公司 一种支持多种bfd发送时间的芯片实现方法
CN105791156B (zh) * 2016-03-03 2019-03-15 盛科网络（苏州）有限公司 一种支持多种bfd发送时间的芯片实现方法

Also Published As

Publication number Publication date
CN101170450A (zh) 2008-04-30
CN101170450B (zh) 2010-07-07

Similar Documents

Publication Publication Date Title
US9705735B2 (en) System and method using RSVP hello suppression for graceful restart capable neighbors
CN108512739B (zh) 以太网虚拟专用网络中的多宿主路由器之间的组播状态
US7990852B1 (en) Methods and apparatus for improving network communication using BFD and VRRP tracking system
US8565098B2 (en) Method, device, and system for traffic switching in multi-protocol label switching traffic engineering
US8218429B2 (en) Method and device for multicast traffic redundancy protection
JP5899305B2 (ja) ネットワークノードを動作させる技術
US9059902B2 (en) Procedures, apparatuses, systems, and computer-readable media for operating primary and backup network elements
WO2009092253A1 (zh) 实现快速重路由的方法及路由器
WO2009089784A1 (fr) Procédé, système et équipement permettant l'accès d'un dispositif réseau à un réseau d'échange de paquets
WO2012028029A1 (zh) 一种切换方法及系统
WO2009046644A1 (fr) Procédé et dispositif pour la commutation de flux de trafic
WO2009082923A1 (fr) Procédé de traitement de défaut de liaison et dispositif de transfert de données
WO2012075731A1 (zh) 基于arp交互的链路故障检测与恢复的方法和设备
WO2007012239A1 (fr) Procédé permettant de commuter la prestation de services d'un lan privé virtuel et système y afférant
WO2009105974A1 (zh) Mpls vpn中实现快速重路由的方法及设备
WO2010020126A1 (zh) 一种vpls网络中的数据传输方法、装置和系统
JP2010518710A (ja) 多機能サービスを提供するメトロイーサネット（登録商標）ネットワークのネットワーキングにおける高信頼性処理の方法およびシステム
WO2012171378A1 (zh) 解决vpls接入l3故障切换导致断流的方法及路由器
JP2008236212A (ja) Ｖｐｎ装置
WO2012075831A1 (zh) 一种实现组播保护的方法及系统
WO2012130034A1 (zh) 一种vpls快速重路由方法和设备
WO2012159489A1 (zh) 一种伪线双归网络的切换方法、系统和双归属运营商设备
US8520509B2 (en) System and a method for routing data traffic
EP3217608B1 (en) Switchback delay methods and devices
WO2007036103A1 (fr) Procede de reparation de trajet de reacheminement de service et systeme associe

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08857168

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08857168

Country of ref document: EP

Kind code of ref document: A1