CN102882797B

CN102882797B - Batch deletes the method and PE of VPNv4 or VPNv6 routes

Info

Publication number: CN102882797B
Application number: CN201210392481.6A
Authority: CN
Inventors: 田钧宇
Original assignee: New H3C Technologies Co Ltd
Current assignee: Ziguang Hengyue Technology Co ltd
Priority date: 2012-10-16
Filing date: 2012-10-16
Publication date: 2018-03-23
Anticipated expiration: 2032-10-16
Also published as: CN102882797A

Abstract

This application discloses a kind of method that batch deletes VPNv4 or VPNv6 routes, comprise the following steps：First provider edge router PE obtains at least one private network tags, for each private network tags in the private network tags, route withdraw message of the encapsulation containing this private network tags simultaneously sends it to the 2nd PE, the route withdraw message is used to trigger private network tags of the 2nd PE in the route withdraw message, in VPNv4 or VPNv6 routing tables, whole VPNv4 or the VPNv6 route using the private network tags as outgoing label are deleted, the 2nd PE is VPNv4 the or VPNv6 neighbours of the first PE Border Gateway Protocol (BGP)；Disclosed herein as well is a kind of provider edge router PE.The application can mitigate PE equipment and the burden of network, improve network performance.

Description

Method for deleting VPNv4 or VPNv6 routes in batches and PE

Technical Field

The present application relates to the technical field of route withdrawal, and in particular, to a method for deleting VPNv4 or VPNv6 routes in batch and an operator edge router (PE).

Background

Multi-protocol label switching (MPLS) is a switching approach in which a core router implements network layer (layer 3) switching using labels (labels) or tags (tags) containing the forward information provided by edge routers within an IP packet, providing a way to map IP addresses to simple labels having a fixed length for different packet forwarding and packet switching techniques. MPLSL3VPN is a three-layer virtual private network (L3 VPN) technology based on provider edge router (PE) in a service provider Virtual Private Network (VPN) solution, which uses Border Gateway Protocol (BGP) to publish VPN routes on a service provider backbone network and uses multi-protocol label switching (MPLS) to forward VPN messages on the service provider backbone network.

At present, the route revocation of BGP VPNv4 (namely VPN-IPv4, fourth edition of virtual private network Internet protocol) or VPNv6 (namely VPN-IPv6, sixth edition of virtual private network Internet protocol) refers to the route revocation process of BGP IPv4 (fourth edition of Internet protocol) or BGP IPv6 (sixth edition of Internet protocol). When link communication between a PE and a CE is failed, a BGP VPNv4 or VPNv6 neighbor is broken or the PE deletes a VPN routing forwarding table (VRF) locally, a local PE device needs to encapsulate routing withdrawal (bypass routes) messages of all routing information broken by the next hop and send the routing withdrawal messages to a BGP VPNv4 or VPNv6 neighbor of the PE, the local PE is marked as a first PE, the BGP VPNv4 or VPNv6 neighbor of the local PE is marked as a second PE, the routing withdrawal messages carry all VPNv4 or VPNv6 routing information broken by the next hop, a network between the first PE and a second PE needs to transmit the update information, the second PE needs to analyze the update information, and extract VPNv4 or VPNv6 routing information in the bypass routes, so that the instant pressure cancellation information is treated for the first PE, the second PE and the second PE.

Here, taking L3VPN networking as an example, as shown in fig. 1, in L3VPN networking, a customer edge router CE establishes an adjacency with a directly connected first PE, and the CE distributes a VPN route of a local site to the first PE and learns a route of a remote VPN from the first PE; the CE and the first PE exchange routing information by using BGP or IGP (interior gateway protocol), or use static routing; after learning VPN routing information local to a CE from the CE, the first PE exchanges VPNv4 routing information with the second PE through BGP. The PE router only maintains the routing information of the VPN directly connected with the PE router, and does not maintain all VPN routes in the service provider network; the operator backbone router P only maintains routes to the PEs without any knowledge of VPN routing information.

When the link communication between the first PE and the CE fails, the first PE needs to send the revocation message of all the routes disconnected by the next hop, and in the carrier-level network, the number of the VPNv4 or VPNv6 routes maintained by the first PE site is very large, that is, when the private network interface is disconnected, the cost of sending the route revocation message is very large. For example, if there are 100 ten thousand VPNv4 or VPNv6 routes to be withdrawn, the first PE needs to continuously group the packets until the 100 ten thousand VPNv4 or VPNv6 route information is encapsulated into a route withdrawal message and sent to the second PE, the route withdrawal message carries 100 ten thousand VPNv4 or VPNv6 route information, the network between the first PE and the second PE needs to transmit the update information, after the second PE receives the update information, the update information needs to be analyzed, 100 ten thousand VPNv4 or VPNv6 route information in withdrewn routes is extracted for withdrawal, and the processing has very large instantaneous pressure on the first PE, the second PE, and the network between the first PE and the second PE.

Disclosure of Invention

In view of this, the present application provides a method for deleting VPNv4 or VPNv6 routes in batches, which can reduce the burden on the PE device and the network and improve the network performance.

The application also provides an operator edge router (PE), which can reduce the burden of PE equipment and a network and improve the network performance.

In order to achieve the above purpose, the technical solution of the embodiment of the present application is implemented as follows:

a method for bulk deletion of VPNv4 or VPNv6 routes, comprising the steps of:

a first provider edge router (PE) acquires at least one private network label, encapsulates a route revocation message containing the private network label aiming at each private network label in the private network labels and sends the route revocation message to a second PE; the second PE is a VPNv4 or VPNv6 neighbor of a border gateway protocol BGP of the first PE;

and the route revocation message is used for triggering the second PE to delete all VPNv4 or VPNv6 routes which take the private network labels as outgoing labels in a VPNv4 or VPNv6 route table according to the private network labels in the route revocation message.

A carrier edge router (PE), comprising: the system comprises a label acquisition module, a message packaging module and a message transceiving module; wherein,

the tag acquisition module is used for acquiring at least one private network tag;

a message encapsulation module, configured to encapsulate, for each private network tag in the private network tags, a route revocation message including the private network tag;

the message receiving and sending module is used for sending the encapsulated route withdrawal message to a second PE, wherein the second PE is a neighbor of VPNv4 or VPNv6 of a border gateway protocol BGP of the provider edge router PE; and the route revocation message is used for triggering the second PE to delete all VPNv4 or VPNv6 routes using the private network labels as outgoing labels in a VPNv4 or VPNv6 routing table according to the private network labels in the route revocation message.

The method has the advantages that when the link communication between the PE and the CE is failed, or the BGPVPNv4 routing protocol between the PEs is broken, or the PE deletes the VRF table locally, the PE fully utilizes the effective private network label to package the VPNv4 or VPNv6 routing revocation message and sends the VPNv4 or VPNv6 routing revocation message to BGP VPNv4 or VPNv6 neighbor PE 'of the PE, and the PE' utilizes the private network label in the routing revocation message to delete VPNv4 or VPNv6 routes in batches, so that the load of PE equipment and a network can be greatly reduced, and the network performance is improved.

Drawings

FIG. 1 is a diagram illustrating a networking architecture of a three-layer VPN in the prior art;

FIG. 2 is a flowchart of a method according to a first embodiment of the present application;

FIG. 3 is a diagram illustrating an alternative capability type parameter format according to an embodiment of the present application;

FIG. 4 is a flowchart of a method according to a second embodiment of the present application;

FIG. 5 is a flowchart of a method according to a third embodiment of the present application;

FIG. 6 is a diagram illustrating a related art OptionB type cross-domain networking architecture;

FIG. 7 is a flowchart of a method according to a fourth embodiment of the present application;

fig. 8 is a functional structure diagram of a PE device according to an embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is described in detail below with reference to the accompanying drawings by specific embodiments.

In the application, a first PE and a second PE are adjacent to each other in BGP VPNv4 or VPNv6, the first PE acquires at least one private network label, and encapsulates a route revocation message containing the private network label and sends the route revocation message to the second PE aiming at each private network label in the private network labels; the route revocation message is used for triggering the second PE to delete all VPNv4 or VPNv6 routes using the private network labels as outgoing labels in a VPNv4 or VPNv6 routing table according to the private network labels in the route revocation message, namely, triggering the second PE to analyze the route revocation message, extracting the private network labels in the route revocation message and using the private network labels as indexes, and deleting all VPNv4 or VPNv6 routes using the private network labels as outgoing labels in a VPNv4 or VPNv6 routing table. That is to say, using a route revocation message containing the private network label, it is possible to delete VPNv4 or VPNv6 routes in batch, thereby greatly reducing PE device and network load caused by sending too many route revocation messages.

A method flow of the first embodiment of the present application is shown in fig. 2, and a method for deleting VPNv4 or VPNv6 routes in batch includes the following steps:

step 201: a first operator edge router (PE) obtains at least one private network label.

The private network label is locally distributed by the first PE, and the obtained private network label is divided into three scenes, namely:

scene 1: in the three-layer virtual private network shown in fig. 1, when a link communication between a first PE and a customer edge router (CE) fails, the first PE queries whether a next hop is a private network label of the CE for other forwarding equivalence class FEC applications, and if so, the first PE sends a route withdrawal message to a second PE, where the route withdrawal message carries all VPNv4 or VPNv6 route information with the next hop being the CE. And if not, acquiring the private network label.

Scene 2: when a BGP VPNv4 or VPNv6 routing protocol between the first PE and the third PE is disconnected, the first PE acquires a private network label, wherein the private network label is an incoming label in one-to-one correspondence with an outgoing label from the third PE; the first PE performs private network label switching, and the third PE is a BGP VPNv4 or VPNv6 neighbor of the first PE and is different from the second PE. The third PE may be in the same domain as the first PE or may be cross-domain.

Scene 3: when a VPN route forwarding table (VRF) is deleted locally by a first PE, all private network labels distributed by the VRF are obtained.

Three embodiments will be specifically described for these three scenarios: how to acquire private network labels in each scene and how to delete VPNv4 or VPNv6 routes in batches by using the acquired private network labels.

As a preferred embodiment, in the above three scenarios, after the first PE obtains at least one private network label, the first PE may also delete the VPNv4 or VPNv6 route local to the first PE in batch by using the private network label, that is, the first PE deletes all VPNv4 or VPNv6 routes local to the first PE using the obtained private network label as an index in the VPNv4 or VPNv6 routing table local to the first PE.

Step 202: the first PE encapsulates a route revocation message containing the private network label and sends the route revocation message to the second PE aiming at each private network label in the private network labels; the second PE is a Border Gateway Protocol (BGP) VPNv4 or VPNv6 neighbor of the first PE.

The route canceling message containing the private network label is divided into two types, namely a VPNv4 route canceling message and a VPNv6 route canceling message, which both comprise the following fields: a multiprotocol unreachable information Prefix length (MP unaach nlripfix length, abbreviated as "Prefix length"), a multiprotocol unreachable information label stack (MP unaach NLRI labelstock, abbreviated as "label stack"), a multiprotocol unreachable information routing identifier (MP unaach NLRI routedinguisher, abbreviated as "routing identifier"), a multiprotocol unreachable information IPv4 or an IPv6 routing Prefix (MP unarch NLRI IPv4/IPv6Prefix, abbreviated as "IPv 4 or IPv6 routing Prefix");

if the route withdraw message is a VPNv4 route withdraw message, the schematic fields are as shown in table 1 below:

MP unreeach NLRI Prefix length (Prefix length)	120
		MP unreeach NLRI Label Stack (Label Stack)	Label
MP unreeach NLRI Route Distinguisher (Route identification)	0:0
		MP unreeach NLRI IPv4/IPv6Prefix (IPv 4 or IPv6 routing Prefix)	255.255.255.255

TABLE 1

As can be seen from table 1, the value of the encapsulated label stack is the private network label, the IPv4 routing prefix is 255.255.255.255, the prefix length is 120, that is, the length of the 32-bit routing mask of IPv4, the routing identifier is a custom value, and an arbitrary value may be set, as long as the first PE and the second PE negotiate, for example, the value is set to 0:0 or 100: and 0, indicating that the address is VPNv4 or VPNv6 route, and adding the route identifier before the IPv4 or IPv6 address indicates that the address is VPNv4 or VPNv 6.

If the route withdraw message is a VPNv6 route withdraw message, the schematic fields are as shown in table 2 below:

TABLE 2

From table 2, it can be seen that the value of the encapsulated label stack is the private network label, the IPv6 routing prefix is FFFF, and the prefix length is 216, which is the length of the 64-bit routing mask of IPv6, and the routing identifier is a user-defined value.

In the existing route withdrawal message, the content of the label stack field is always in an invalid state, for example, set to 0 or a maximum value, and the IPv4 or IPv6 route prefix is filled with a valid IPv4 or IPv6 address.

In the routing revocation message of the application, the label stack field is filled with an effective private network label, the effective private network label is utilized to realize batch deletion of VPNv4 or VPNv6 routing, IPv4 or IPv6 routing prefix is filled with unavailable IPv4 or IPv6 addresses, such as filled IPv4 addresses 255.255.255.255 or IPv6 addresses FFFF: FFFF: FFFF: FFFF: FFFF: FFFF: FFFF: FFFF, and the unavailable IPv4 or IPv6 addresses are used when the routing revocation message is analyzed later.

Step 203: and triggering the second PE by a route revocation message to delete all VPNv4 or VPNv6 routes using the private network labels as outgoing labels in a VPNv4 or VPNv6 routing table according to the private network labels in the route revocation message.

After receiving the route canceling message from the first PE, the second PE analyzes the route canceling message and extracts a private network label in the route canceling message, and the process is as follows:

for the VPNv4 route withdrawal message, if the route identifier RD is 0:0, whether RD is 0:0 and the IPv4 address is: 255.255.255.255, namely judging whether the VPNv4 address is: 0255.255.255.255, if yes, extracting the private network label in the VPNv4 route revocation message.

The fact is that the IPv4 address is determined to be unavailable, and then the private network tag is read, if the IPv4 address is available, the private network tag is deleted according to the existing flow, or the route is deleted according to the available IPv4 address.

For the VPNv6 route withdrawal message, if the route identifier RD is 0:0, whether RD is 0:0 and the IPv6 address is: FFFF, and FFFF are determined, namely whether the VPNv6 address is 0:0FFFF, and FFFF is determined, and if yes, the private network tag in the VPNv6 route revocation message is extracted.

If the determination on the VPNv4 or VPNv6 route withdrawal message is negative, that is, the VPNv4 address is not: the route identification 255.255.255.255, or the VPNv6 address is not: and deleting the VPNv4 or VPNv6 route according to the original flow, namely deleting the VPNv4 or VPNv6 route one by one according to the IPv4 or IPv6 route prefix in the route revocation message instead of deleting the VPNv 3838 route in batches by using private network labels.

And the second PE analyzes and judges the VPNv4 or VPNv6 route revocation message sent by the first PE, extracts a private network label, uses the private network label as an index, and deletes all VPNv4 or VPNv6 routes using the private network label as an outgoing label in a VPNv4 or VPNv6 routing table of the second PE.

Preferably, before step 201, an optional capability type parameter supporting batch deletion of VPNv4 or VPNv6 routing with a private network label is added in the BGP OPEN message in advance;

before the first PE and the second PE establish BGP VPNv4 or VPNv6 adjacency, the first PE sends BGPOPEN messages, and after the first PE receives BGP OPEN messages sent by the second PE, capability negotiation is carried out according to optional capability type parameters carried in the received OPEN messages and optional capability types locally supported by the first PE. The capability negotiation mechanism will be described later.

The optional capability type parameter in the OPEN message is shown in fig. 3, and includes the following fields: capability type (part.type), parameter length (part.length); wherein,

the capability type value is a custom value negotiated between the first PE and the second PE and is not the same as any capability type value specified in the BGP protocol, so as to avoid collision, for example:

for a capability Type that supports bulk deletion of VPNv4 routes with private network labels, the Type field may be 101.

The Type field may be 102 for a capability Type that supports bulk deletion of VPNv6 routes with private network labels.

Where 101, 102 are custom values, it is not important what value the Type field takes, as long as there is a negotiation between the first PE and the second PE, but the value taken cannot conflict with any of the capability Type values specified in the BGP protocol.

The Length value (Length field) of the parameter is 0, only the information of the capability type value is actually needed, but in order to conform to the standard format of the negotiation message of the BGP, the message information is conveniently read when the capability negotiation is performed between the PEs, and here, the Length field is reserved, and the value is set as 0.

The first PE and the second PE mutually send the OPEN message, and for the first PE, a capability negotiation mechanism supporting batch deletion of VPNv4 or VPNv6 routing by using private network labels is as follows:

1) the optional capability type parameter is carried in an OPEN message sent by a remote BGP VPNv4 or a VPNv6 neighbor second PE received by the first PE, if the first PE does not support the capability, the optional capability type parameter field is ignored, the negotiation is unsuccessful, and the VPNv4 or VPNv6 route is deleted according to the original flow.

2) The first PE supports the capability, the optional capability type parameter is not carried in an OPEN message sent by the second PE, negotiation is unsuccessful, and the VPNv4 or VPNv6 route is deleted according to the original flow.

3) The optional capability type parameter is carried in an OPEN message sent by the second PE and received by the first PE, and the first PE also supports the capability, so that the negotiation is successful, and the VPNv4 or VPNv6 routing is deleted in batches by using the private network label between the first PE and the second PE.

And for the second PE, the same processing is carried out after the OPEN message sent by the first PE is received.

The optional capability type parameter includes the following fields: capability type, parameter length; the capability type value is a custom value agreed between the first PE and the second PE, is not the same as any capability type value specified in the BGP protocol, and has a parameter length value of 0.

Three embodiments are specifically illustrated below for the above three scenarios: how to acquire private network labels in each scene and how to delete VPNv4 or VPNv6 routes in batches by using the acquired private network labels. The formats of the VPNv4 or VPNv6 route withdrawal messages in the following three embodiments are the same as those in the first embodiment.

The method flow of the second embodiment of the present application is shown in fig. 4, and includes the following steps:

step 401: when the link communication between the first PE and the CE is in failure, if the private network label of which the next hop is the CE has no other forwarding equivalence class FEC application, the private network label is obtained.

In the three-layer virtual private network shown in fig. 1, when the link communication between the first PE and the CE fails, if the link is in oscillation, the first PE deletes the direct routing of the private network interface whose next hop is the CE, and the first PE queries, in its VPNv4 or VPNv6 routing table entry, whether the private network label whose next hop is the CE has other forwarding equivalence FEC applications, that is, whether there are other next hop applications for routing:

if so, VPNv4 or VPNv6 routes are deleted as in the prior art.

If not, the first PE releases the private network label from the VPNv4 or VPNv6 routing table entry thereof, so as to obtain the private network label.

The reason why the query operation is required here is that the PE devices produced by the existing manufacturers apply for private network labels according to VPNs, and each VPN has only one label; some PE devices produced by manufacturers apply for private network labels according to the next hop of the VPN route, and the number of the private network labels is the number of the next hops in the VPN route. For the PE device applying for the private network label according to the VPN, if the route is deleted according to the private network label, the route with the fault of the next hop can be deleted, and a plurality of pieces of route information which normally operate can be deleted by mistake.

Therefore, in the present application, in order to consider that two types of PE devices produced by current factories do not have any other forwarding equivalence class FEC application before obtaining a private network label, therefore, as a preferred embodiment, it is required to first query whether a private network label whose next hop is the CE has any other forwarding equivalence class FEC application, if so, it is impossible to delete VPNv4 or VPNv6 routing information in batch according to the private network label, but according to a method of revoking VPNv4 or VPNv6 routing in the prior art, that is, a first PE sends a routing revocation message to a second PE, where the routing revocation message carries all VPNv4 or VPNv6 routing information of the CE at the next hop, and after receiving the routing revocation message, the second PE can only delete the routing revocation message one by one according to a large amount of VPNv4 or VPNv6 routing information carried in the routing revocation message.

Step 401 corresponds to step 201 of embodiment one.

Step 402: and the first PE encapsulates a route revocation message containing the private network label and sends the route revocation message to the second PE, wherein the route revocation message is used for triggering the second PE to delete all VPNv4 or VPNv6 routes which take the private network label as an outgoing label in a VPNv4 or VPNv6 route according to the private network label in the route revocation message.

That is, the route revocation message is used to trigger the second PE to analyze the route revocation message, extract the private network label in the route revocation message, use the extracted private network label as an index, and delete all VPNv4 or VPNv6 routes that use the private network label as an outgoing label in the VPNv4 or VPNv6 routing table.

After acquiring a private network label, a first PE encapsulates a VPNv4 or VPNv6 route withdrawal message containing the private network label, where, taking VPNv4 route withdrawal message as an example, the processing of VPNv6 route withdrawal message is similar, VPNv4 route withdrawal message is as shown in table 1, and sends the VPNv4 route withdrawal message to a second PE, and the second PE analyzes the VPNv4 route withdrawal message after receiving the VPNv4 route withdrawal message, that is, whether a VPNv4 address is 0:0255.255.255.255 is judged:

if so, extracting the private network label in the VPNv4 route revocation message, taking the extracted private network label as an index, and deleting all VPNv4 routes taking the private network label as an outgoing label in a VPNv4 route table;

if not, deleting the VPNv4 route according to the prior art, namely deleting the VPNv4 route according to the IPv4 route prefix in the VPNv4 route revocation message.

Step 402 corresponds to step 202 and step 203 of the first embodiment.

Preferably, before step 401, the capability negotiation between the first PE and the second PE is performed in the same manner as in the first embodiment.

The method flow of the third embodiment of the present application is shown in fig. 5, and includes the following steps:

step 501: when a BGP VPNv4 or VPNv6 routing protocol between the first PE and the third PE is disconnected, the first PE acquires a private network label, wherein the private network label is an incoming label in one-to-one correspondence with an outgoing label from the third PE; the first PE performs private network label switching, and the third PE is a BGP VPNv4 or VPNv6 neighbor of the first PE and is different from the second PE.

Step 501 corresponds to step 201 of embodiment one. Examples are as follows:

in the OptionB-type cross-domain networking shown in fig. 6, the ASBR-PEs are both autonomous system border routers and operator edge routers, ASBR-PE1 (the first PE) will perform private network label switching, thus, one or more entries corresponding to outlabel and inlabel in one-to-one exist in BGP LSP (label switched path) private network entries of ASBR-PE1, wherein outlabel on ASBR-PE1 is allocated by downstream PE1 (third PE), inlabel is allocated to upstream ASBR-PE2 (second PE) for ASBR-PE1, when the BGP VPNv4 or VPNv6 routing protocol between ASBR-PE1 and PE1 is broken, ASBR-PE1 at the same time as the upstream private network label(s) from PE1 are revoked, and obtaining private network labels inlabel (one or more) which are in one-to-one correspondence with the upstream private network labels outlabel from the PE1 according to the corresponding table entries of outlabel and inlabel.

Step 502: and the first PE encapsulates a route revocation message containing the private network label and sends the route revocation message to the second PE aiming at each private network label in the private network labels, wherein the route revocation message is used for triggering the second PE to delete all VPNv4 or VPNv6 routes which take the private network labels as outgoing labels in a VPNv4 or VPNv6 routing table according to the private network labels in the route revocation message.

After obtaining the private network label inlabel, the first PE packages all the inlabels into VPNv4 or VPNv6 route cancellation messages containing the private network label inlabel according to table 1 or table 2, and sends the VPNv4 or VPNv6 route cancellation messages to the second PE, after receiving the route cancellation messages, the second PE analyzes the route cancellation messages, extracts the private network label inlabel in the route cancellation messages, deletes VPNv4 or VPNv6 routes in batches according to the private network label, and the processing after receiving the route cancellation messages by the second PE is the same as that in the first embodiment, and is not described again here.

Step 502 corresponds to step 202 and step 203 of the first embodiment.

Preferably, the process of capability negotiation between the first PE and the second PE before step 501 is the same as that of the first embodiment.

The method flow of the fourth embodiment of the present application is shown in fig. 7, and includes the following steps:

step 701: when a VPN route forwarding table (VRF) is deleted locally by a first PE, all private network labels distributed by the VRF are obtained.

When the first PE deletes the VRF table locally, the first PE obtains all (one or more) private network labels inlabels distributed by the VRF when the first PE revokes all the private network labels inlabels distributed by the VRF.

Step 701 corresponds to step 201 of the first embodiment.

Step 702: and the first PE encapsulates a route revocation message containing the private network label and sends the route revocation message to the second PE aiming at each private network label in the private network labels, wherein the route revocation message is used for triggering the second PE to delete all VPNv4 or VPNv6 routes which take the private network labels as outgoing labels in a VPNv4 or VPNv6 routing table according to the private network labels in the route revocation message.

The first PE encapsulates all the obtained private network labels inlabel into VPNv4 or VPNv6 route revocation messages containing the private network labels inlabel according to table 1 or table 2, and sends the route revocation messages to a second PE, where the second PE is a BGP VPNv4 or VPNv6 route neighbor of the first PE, and the processing of the second PE after receiving the route revocation messages is the same as that in the first embodiment, and is not described herein again.

Step 702 corresponds to step 202 and step 203 of the first embodiment.

Preferably, before step 701, the capability negotiation between the first PE and the second PE is performed in the same manner as in the first embodiment.

Fig. 8 shows a functional structure diagram of a PE device in an embodiment of the present application, where an operator edge router (PE) includes: the system comprises a label acquisition module, a message packaging module and a message transceiving module; wherein,

the message receiving and sending module is used for sending the encapsulated route withdrawal message to a second PE, wherein the second PE is a neighbor of VPNv4 or VPNv6 of a border gateway protocol BGP of the provider edge router PE; and the route revocation message is used for triggering the second PE to delete all VPNv4 or VPNv6 routes which take the private network labels as outgoing labels in a VPNv4 or VPNv6 route table according to the private network labels in the route revocation message.

Preferably, the operator edge router further includes a capability negotiation module, further configured to add an optional capability type parameter supporting batch deletion of VPNv4 or VPNv6 routing with a private network label in a BGP OPEN message, send the BGP OPEN message to the second PE before the operator edge router PE establishes BGP VPNv4 or VPNv6 adjacency with the second PE, and perform capability negotiation according to the optional capability type parameter carried in the received OPEN message and the optional capability type locally supported by the first PE.

Preferably, the label obtaining module is further configured to, when a link communication between the provider edge router PE and the customer edge router CE fails, obtain a private network label of a next hop, which is the CE, if the private network label has no other forwarding equivalence class FEC application;

or,

when a BGP VPNv4 or VPNv6 routing protocol between the provider edge router PE and a third PE is broken, acquiring a private network label, wherein the private network label is an incoming label in one-to-one correspondence with an outgoing label from the third PE; the provider edge router PE performs private network label switching, and the third PE is a BGP VPNv4 or VPNv6 neighbor of the provider edge router PE and is different from the second PE;

or,

when a VPN routing forwarding table (VRF) is deleted locally, all private network labels distributed by the VRF are acquired.

Preferably, the tag obtaining module is further configured to delete all VPNv4 or VPNv6 routes tagged with the private network tag in a local VPNv4 or VPNv6 routing table by using the obtained private network tag as an index.

The optional capability type parameter includes the following fields: capability type, parameter length; the capability type value is a custom value agreed between the provider edge router PE and the BGP VPNv4 or VPNv6 routing neighbor thereof, is not the same as any capability type value specified in the BGP protocol, and has a parameter length value of 0.

Preferably, the label obtaining module is further configured to query whether a private network label with a next hop being the CE has other forwarding equivalence class FEC applications, and if so, notify the message transceiver module to send a route revocation message to the second PE, where the route revocation message carries all VPNv4 or VPNv6 routing information with the next hop being the CE;

and the message receiving and sending module is further configured to send the route cancellation message to the message processing module of the second PE according to the notification of the label obtaining module.

The route revocation message containing the private network label comprises the following fields: prefix length, label stack, route identification, IPv4 or IPv6 route prefix;

if the route revocation message is a VPNv4 route revocation message, the value of a label stack is the private network label, the IPv4 route prefix is 255.255.255.255, the prefix length is 120, and the route identifier is a user-defined value;

if the route revocation message is a VPNv6 route revocation message, the value of the label stack is the private network label, the IPv6 route prefix is FFFF, the prefix length is 216, and the route identifier is a user-defined value.

After receiving the route withdrawal message from the provider edge router PE, the second PE determines, for the VPNv4 route withdrawal message, whether the VPNv4 address is: a route identifier 255.255.255.255, if yes, extracting a private network label in the VPNv4 route revocation message;

for the VPNv6 route withdrawal message, judging whether the VPNv6 address is: and if the route identification FFFF, FFFF and FFFF is the same, extracting a private network label in the VPNv6 route revocation message.

After receiving the route withdrawal message from the provider edge router PE, the second PE determines that the VPNv4 address of the VPNv4 route withdrawal message is not: the route identifier 255.255.255.255, or the VPNv6 address of the VPNv6 route withdrawal message is not: when the route identifier FFFF is FFFF, FFFF and FFFF, the VPNv4 or VPNv6 route is deleted according to the IPv4 or IPv6 route prefix in the route revocation message;

by adopting the scheme, when the communication of the private network interface fails, or the BGP VPNv4 or VPNv6 protocol between PEs is broken, or the PE deletes VRF locally, VPNv4 or VPNv6 routes are deleted by using the private network label, and a large number of VPNv4 or VPNv6 routes can be deleted in batches only by encapsulating and sending one route revocation message or a small number of route revocation messages.

The above description is only for the purpose of illustrating the preferred embodiments of the present invention and is not to be construed as limiting the invention, and any modifications, equivalents, improvements and the like made within the spirit and principle of the present invention should be included in the scope of the present invention.

Claims

1. A method for bulk deletion of VPNv4 or VPNv6 routes, comprising the steps of:

2. The method of claim 1, wherein before the first PE obtaining at least one private network label, further comprising:

adding an optional capability type parameter supporting batch deletion of VPNv4 or VPNv6 routing by using a private network label in a BGP OPEN message;

before the first PE establishes a BGP VPNv4 or VPNv6 neighborhood with the second PE, the first PE sends a BGP OPEN message, and after the first PE receives the BGP OPEN message sent by the second PE, capability negotiation is carried out according to the optional capability type parameters carried in the received OPEN message and the optional capability types locally supported by the first PE.

3. The method of claim 1, wherein obtaining at least one private network label by the first PE comprises:

when the link communication between a first PE and a customer edge router (CE) is in fault, if the private network label of which the next hop is the CE has no other forwarding equivalence class FEC application, the first PE acquires the private network label;

or,

when a BGP VPNv4 or VPNv6 routing protocol between the first PE and the third PE is disconnected, the first PE acquires a private network label, wherein the private network label is an incoming label in one-to-one correspondence with an outgoing label from the third PE; the first PE carries out private network label switching, and the third PE is a BGP VPNv4 or VPNv6 neighbor of the first PE and is different from the second PE;

or,

when the first PE locally deletes the VRF, the first PE acquires all private network labels distributed by the VRF.

4. The method of claim 1, wherein after the first PE obtains at least one private network label, further comprising: and the first PE deletes all VPNv4 or VPNv6 routes which take the private network label as an incoming label in a VPNv4 or VPNv6 routing table of the first PE by taking the private network label as an index.

5. The method of claim 1, wherein the route withdraw message containing the private network label comprises the following fields: prefix length, label stack, route identification, IPv4 or IPv6 route prefix;

6. A provider edge router, PE, comprising: the system comprises a label acquisition module, a message packaging module and a message transceiving module; wherein,

7. The provider edge router of claim 6, wherein the provider edge router further comprises a capability negotiation module, configured to add an optional capability type parameter that supports bulk deletion of VPNv4 or VPNv6 routing with a private network label in a BGP OPEN message, send the BGP OPEN message to the second PE before the provider edge router PE establishes BGP VPNv4 or VPNv6 adjacency with the second PE, and perform capability negotiation according to the optional capability type parameter carried in the received OPEN message and the optional capability type locally supported by the first PE after receiving the BGP OPEN message sent by the second PE.

8. The provider edge router of claim 6, wherein the label obtaining module is further configured to, when a link communication between the provider edge router PE and a customer edge router CE fails, obtain a private network label of a next hop as the CE if the private network label has no other forwarding equivalence class FEC application;

or,

9. The provider edge router of claim 6, wherein the label obtaining module is further configured to delete all VPNv4 or VPNv6 routes tagged with the private network label in a local VPNv4 or VPNv6 routing table using the obtained private network label as an index.

10. The carrier edge router of claim 6, wherein the route withdraw message containing the private network label comprises the following fields: prefix length, label stack, route identification, IPv4 or IPv6 route prefix;