WO2017114158A1

WO2017114158A1 - Method and device for publishing tenant routing in nvo3 network

Info

Publication number: WO2017114158A1
Application number: PCT/CN2016/109933
Authority: WO
Inventors: 庄顺万; 倪辉; 阴元斌; 郝卫国; 李振斌; 陈国义
Original assignee: 华为技术有限公司
Priority date: 2015-12-28
Filing date: 2016-12-14
Publication date: 2017-07-06
Also published as: CN106921573A; CN106921573B

Abstract

An embodiment of the present invention provides a method and device for publishing tenant routing in an NVo3 network, and can simplify routing deployment schemes in an NVo3 network. In the method, a peripheral PE of a first service provider acquires, according to a first tenant routing from a first user peripheral CE, a second tenant routing, the first tenant routing comprising a network protocol IP address of the first CE, the second tenant routing comprising a first virtual network identifier (VNID), the IP address of the first CE, and a virtual tunnel end point (VTEP) address of the first PE, and the first VNID being used to identify a virtual private network (VPN) to which the first CE belongs; and the first PE transmits the second tenant routing to a target PE.

Description

Method and device for publishing tenant routes in NVo3 network

This application claims the priority of the Chinese Patent Application filed on Dec. 28, 2015, the Chinese Patent Office, Application No. CN201510998749.4, entitled "Method and Apparatus for Issuing Tenant Routes in NVo3 Networks", the entire contents of which are hereby incorporated by reference. This is incorporated herein by reference.

Technical field

The embodiments of the present invention relate to the NVo3 network technology, and in particular, to a method and an apparatus for issuing tenant routes in an NVo3 network.

Background technique

NVo3 (Network Virtualization over Layer 3) is a technology for implementing network virtualization. This technology can virtualize the physical network so that it can be used by different tenants. The NVo3 network can adopt the MPLS (Multiple Protocol Label Switch) protocol. An MPLS-based virtual private network (VPN) can be called an MPLS L3VPN. MPLS L3VPN uses BGP (Border Gateway Protocol) to advertise VPN routes on the service provider backbone network and MPLS (Multiple Protocol Label Switch) to forward VPN packets on the service provider backbone network.

In the MPLS L3VPN, the CE (Customer Edge) device is deployed on the VPN edge and connected to the SP (Service Provider) network. The PE (Provider Edge) device in the SP network is deployed on the edge of the service provider backbone and connected to the CE device. The P (Provider, Service Provider) device is a backbone router in the service provider backbone network and is connected to the PE device. In the MPLS L3VPN, the advertisement of the VPN routing information includes: the route advertisement from the local CE to the ingress PE, the route advertisement from the ingress PE to the egress PE, and the route advertisement from the egress PE to the remote CE. After the route is advertised, the reachable route is set up between the local CE and the remote CE. That is, the VPN private network routing information can be advertised on the backbone network.

The process of the route is as follows: After the local CE establishes an adjacency with the connected first PE, the local CE is advertised to the first PE. The VPN route advertised by the local CE to the first PE is a standard format IPv4 or IPv6 route. After obtaining the VPN route from the local CE, the first PE adds the RD (Route Distinguisher) and Route Target attributes to the VPN route to form a VPN-IPv4 route. The Route Target attribute can also be called a VPN Target attribute. The first PE of the VPN stores the VPN-IPv4 route to the VPN instance created for the local CE. The first PE advertises the VPN-IPv4 route to the second PE through the Multi-Protocol Border Gateway Protocol (MP-BGP). The remote CE learns VPN-IPv4 routes from the second PE.

The current NVo3 network uses RD and RT policies to deploy VPN routes. The implementation process is relatively complicated.

Summary of the invention

The method and device for issuing tenant routes in the NVo3 network provided by the embodiment of the present invention can simplify the route deployment scheme in the NVo3 network.

In a first aspect, a method for publishing tenant routes in an NVo3 network is provided, where the method includes:

The first service provider edge PE device obtains a second tenant route according to the first tenant route from the first user edge CE device, where the first tenant route includes a network protocol IP address of the first CE device, where the The second tenant route includes a first virtual network identifier VNID, an IP address of the first CE device, and an address of a virtual tunnel endpoint VTEP of the first PE, where the first VNID is used to identify a virtual private entity to which the first CE device belongs. Network VPN;

The first PE device sends the second tenant route to the target PE device.

Optionally, the first service provider edge PE device obtains the second tenant route according to the first tenant route from the first user edge CE device, including:

Determining, by the first PE device, the first VNID according to the first CE device IP address included in the first tenant route;

The first PE device adds the address of the first VNID and the virtual tunnel endpoint VTEP of the first PE to the first tenant route to obtain the second tenant route.

Optionally, the second tenant route further includes a type of the first virtual tunnel, where the first virtual tunnel is a virtual tunnel between the first PE and the target PE device.

Optionally, the sending, by the first PE device, the second tenant route to the target PE device includes:

The first PE device sends the second tenant route to the target PE device by using a route reflector RR.

Optionally, the method further includes:

The first PE device receives a third tenant route from the second PE device, where the third tenant route includes a second VNID, an IP address of the second CE device, and an address of the VTEP of the second PE, where the second VNID It is used to identify the VPN to which the second CE device belongs.

Optionally, the receiving, by the first PE device, the third tenant route from the second PE device includes:

Receiving, by the first PE device, the third tenant route pushed by the RR; or

Sending, by the first PE device, a request message to the RR, where the request message is used to request the third tenant route from the RR;

The first PE device receives the third tenant route sent by the RR.

Optionally, the third tenant route further includes a type of the second virtual tunnel, where the second virtual tunnel is a virtual tunnel between the first PE device and the second PE device, the method further includes:

Determining, by the first PE device, the second virtual tunnel that is used by the third tenant route according to the second VNID and the type of the second virtual tunnel.

Optionally, the request message carries a VNI_Based ORF entry that is based on the outbound route filtering ORF protocol. The VNI_Based ORF entry includes the VNID included in the tenant route that the first PE device requests the RR to send.

Optionally, the VNI_Based ORF entry further includes a VNID included in the tenant route that the first PE device requests the RR to revoke.

Optionally, after the first PE device receives the third tenant route from the second PE device, the method further includes: the first PE device, according to the second VNID included in the third tenant route, The third tenant route is added to the tenant routing table corresponding to the VNID.

Optionally, the second tenant route further includes: a first virtual tunnel parameter;

The method further includes: the first PE device sending service data to the target PE device according to the type of the first virtual tunnel and the first virtual tunnel parameter.

Optionally, the first virtual network identifier VNID, the IP address of the first CE device, and the address of the virtual tunnel endpoint VTEP of the first PE are all located in a multi-protocol _ reach_network layer reachable by the border gateway protocol BGP Information in MP_REACH_NLRI.

Optionally, the first virtual network identifier VNID, the IP address of the first CE device, and the address of the virtual tunnel endpoint VTEP of the first PE are respectively located in a preset extended community attribute.

Optionally, the first virtual network identifier VNID is located in a preset extended community attribute, and the IP address of the first CE device and the address of the virtual tunnel endpoint VTEP of the first PE are both located in the MP_REACH_NLRI of the BGP.

A second aspect provides a method for publishing tenant routes in an NVo3 network, where the method includes:

The route reflector RR receives the second tenant route sent by the first PE device, where the second tenant route is obtained by the first PE device according to the first tenant route from the first user edge CE device, the first tenant The route includes a network protocol IP address of the first CE device, and the second tenant route includes a first virtual network identifier VNID, an IP address of the first CE device, and an address of a virtual tunnel endpoint VTEP of the first PE, where The first VNID is used to identify a virtual private network VPN to which the first CE device belongs;

The RR sends the second tenant route to the target PE device.

Optionally, the method further includes: the RR storing the second tenant route into a routing table corresponding to the VNID included in the second tenant route.

Optionally, the RR sends the second tenant route to the target PE device, including:

The RR pushes the second tenant route to other PE devices connected to the RR except the first PE device.

According to the second aspect or the first possible implementation of the second aspect, the third in the second aspect In a possible implementation manner, the RR sends the second tenant route to the target PE device, including:

Receiving, by the PE device, a request message for requesting a tenant route, where the request message carries a VNID included in the requested tenant route;

The RR sends the second tenant route to the PE device that carries the VNID carried in the request message and is consistent with the VNID in the second tenant route.

Optionally, the request message carries a VNI_Based ORF entry based on the outbound route filtering ORF protocol, where the VNI_Based ORF entry includes a VNID of the requested tenant route.

Optionally, the VNI_Based ORF entry further includes a VNID that is included in the tenant route that the PE device requests the RR to revoke. The method further includes: the RR is revoked according to the VNID included in the tenant route that the PE device requests the RR to revoke. The corresponding tenant route.

A third aspect provides an apparatus for publishing tenant routes in an NVo3 network, where the apparatus includes:

a route generation module, configured to obtain a second tenant route according to the first tenant route from the first user edge CE device, where the first tenant route includes a network protocol IP address of the first CE device, and the second tenant The route includes a first virtual network identifier VNID, an IP address of the first CE device, and an address of a virtual tunnel endpoint VTEP of the first PE, where the first VNID is used to identify a virtual private network VPN to which the first CE device belongs. ;

The route issuing module is configured to send the second tenant route to the target PE device.

Optionally, the route generation module is specifically configured to:

Determining the first VNID according to the first CE device IP address included in the first tenant route;

Adding the address of the first VNID and the virtual tunnel endpoint VTEP of the first PE to the first tenant route to obtain the second tenant route.

Optionally, the route publishing module is specifically configured to:

The second tenant route is sent to the target PE device by using a route reflector RR.

Optionally, the device further includes:

a receiving module, configured to receive a third tenant route from the second PE device, where the third tenant route includes a second VNID, an IP address of the second CE device, and an address of the VTEP of the second PE, where the second VNID is used The VPN to which the second CE device belongs is identified.

Optionally, the receiving module is specifically configured to:

Receiving the third tenant route pushed by the RR; or

Sending a request message to the RR, where the request message is used to request the third tenant route from the RR;

Receiving the third tenant route sent by the RR.

Optionally, the third tenant route further includes a type of the second virtual tunnel, where the second virtual tunnel is a virtual tunnel between the first PE device and the second PE device, and the device further includes:

And a determining module, configured to determine, according to the second VNID and the type of the second virtual tunnel, the second virtual tunnel used by the third tenant route.

In the method provided by the embodiment of the present invention, the first PE device advertises the first virtual network identifier VNID, the IP address of the first CE device, and the virtual tunnel endpoint VTEP of the first PE device to the target PE device by using the second tenant route. The address does not need to adopt RD policy and RT policy, which simplifies the route deployment scheme of the NVo3 network.

DRAWINGS

Figure 1 is a schematic diagram of a scenario of an MPLS L3VPN;

2 is a schematic diagram of a scenario of an NVo3 network;

3 is a flowchart of a method for publishing a tenant route in an NVo3 network according to Embodiment 1 of the present invention;

4 is a flowchart of a method for publishing a tenant route in an NVo3 network according to Embodiment 2 of the present invention;

FIG. 5 is a flowchart of a method for publishing tenant routes in an NVo3 network according to Embodiment 3 of the present invention;

6 is a flowchart of a method for publishing a tenant route in an NVo3 network according to Embodiment 4 of the present invention;

FIG. 7 is a flowchart of a method for publishing tenant routes in an NVo3 network according to Embodiment 5 of the present invention;

8 is a schematic diagram of publishing tenant routes in an NVo3 network;

FIG. 9 is another schematic diagram of issuing tenant routes in an NVo3 network;

FIG. 10 is a schematic structural diagram of an apparatus for issuing a tenant route in an NVo3 network according to an embodiment of the present disclosure;

FIG. 11 is a schematic structural diagram of a PE device according to an embodiment of the present invention.

detailed description

The method for issuing the tenant route in the NVo3 network in the embodiment of the present invention is described. The MPLS L3VPN (Multiple Protocol Label Switch Layer 3 Virtual Private Network) and the NVo3 network are described first.

Figure 1 shows the scenario of MPLS L3VPN. As shown in Figure 1, the MPLS L3VPN includes the CE device 1, the CE device 2, the CE device 3, the CE device 4, the PE device 1, the PE device 2, and the P device.

As shown in Figure 1, CE device 1 and CE device 4 belong to VPN 1, respectively, and CE device 2 and CE device 3 belong to VPN 2. Due to the independence of the VPN network, VPN1 and VPN2 independently manage the range of addresses used by themselves. Among them, the address range is also called Address Space.

In the actual application scenario, the address spaces of different VPNs may overlap in a certain range. For example, both VPN1 and VPN2 use the address of the 10.110.10.0/24 network segment, and Overlapping Address Spaces occur. Assume that both VPN1 and VPN2 advertise a route to the rejoined network segment. The PE device only selects one of the routes, which causes the other route to be lost.

In order to solve the problem of route advertisement in MPLS L3VPN, policies such as RD, RT, and tunnel are usually adopted.

(1) RD strategy

Taking the PE device 1 as an example, after receiving the VPN route from the CE device 1, the PE device 1 adds an RD to the VPN route to make it globally unique. For example, the PE device 1 attaches an RD to the received IPv4 route, and obtains a VPN-IPv4 route, and the VPN-IPv4 route is globally unique.

(2) RT strategy

MPLS L3VPN uses the BGP extended community attribute—Route Target to control the advertisement of VPN routing information. Two types of RT attributes are deployed on any PE: Export Target attribute: VPN-IPv4 that PE device 1 will acquire. The route is advertised to other PE devices, such as PE device 2. Before, the Export Target attribute is further set for VPN-IPv4 routes. Import target attribute: PE device 2 receives other VPN devices, such as PE device 1, and sends the VPN-IPv4 route, and then checks the Export Target attribute of the received VPN-IPv4 route, only when its Export Target attribute is When the Import Target attribute set in PE 2 matches, the received route is added to the corresponding VPN routing table.

(3) Tunneling Policy

The tunneling policy is used to determine the tunnel used to transmit the service packets in the VPN. For example, the LSP (Label Switch Path) is selected as the tunnel.

Figure 2 is a schematic diagram of a scenario of an NVo3 network. NVo3 (Network Virtualization over Layer 3) is a technology for implementing network virtualization. This technology can virtualize a physical network so that it can be used by different tenants.

As shown in Figure 2, the NVo3 network includes TES (tenant end system). And NVE (Network Virtulizaiton Edge, virtual network edge) devices. The TES is the virtualized node of the CE in the MPLS L3VPN. The NVE is the node after the PE is virtualized in the MPLS L3VPN. Specifically, TES1 to TES4 in Figure 2 correspond to CE1 to CE4 in the MPLS L3VPN, and NVE1 and NVE2 respectively correspond to PE1 and PE2 in the MPLS L3VPN. The NVo3 network can also directly adopt the route advertisement policy in MPLS L3VPN, that is, advertise routes according to policies such as RD, RT, and tunnel. However, in the NVo3 network, the above routing policy is deployed to advertise routes. The implementation process is relatively complicated.

In order to solve the problem that the route publishing process is complicated in the existing NVo3 network, the embodiment of the present invention provides a method for publishing a tenant route in an NVo3 network, in which both the control plane and the data plane use the same virtual network identifier ( Virtual network identifier, VNID). The VNID represents the division of tenants in the control plane and can be used for isolation of tenant routes. Further, the VNID can be used as a forwarding identifier in the data plane. According to the method provided by the embodiment of the present invention, the first PE device sends the first virtual network identifier VNID, the IP address of the first CE device, and the VTEP (virtual tunnel end point) of the first PE device to the target PE device through the second tenant route. The address of the virtual tunnel endpoint does not need to adopt the RD policy and the RT policy, which simplifies the route deployment scheme of the NVo3 network.

The tenant communication method in the NVo3 network according to the embodiment of the present invention will be described in detail below with reference to the accompanying drawings.

FIG. 3 is a flowchart of a method for publishing a tenant route in an NVo3 network according to Embodiment 1 of the present invention. The NVo3 network includes: a service provider backbone network and at least one VPN; each tenant corresponds to at least one VPN. The method provided in Embodiment 1 of the present invention includes:

S11: The first PE device obtains the second tenant route according to the first tenant route from the first CE device.

The first tenant route includes an IP address of the first CE device, such as an IPv4 address or an IPv6 address of the first CE device. The second tenant route includes a first VNID, an IP address of the first CE device, and an address of a VTEP of the first PE device. The first VNID is used to identify a VPN to which the first CE device belongs.

In the embodiment of the present invention, the first PE device is configured according to the first device from the first CE device The first VNID is determined by the first PE device according to the first CE device IP address included in the first tenant route; the first The PE device adds the address of the first VNID and the VTEP of the first PE to the first tenant route to obtain the second tenant route.

Further, the second tenant route may further include a type of the first virtual tunnel, where the first virtual tunnel is a virtual tunnel between the first PE and the target PE device. The target PE device is a PE device that receives the route of the second tenant.

S12: The first PE device sends the second tenant route to the target PE device.

For example, the first PE device sends the second tenant route to the target PE device. The target PE device obtains the first VNID, the IP address of the first CE device, and the address of the VTEP of the first PE device by using the second tenant route. The first VNID can be separated from other tenant routes, and the RD policy and the RT policy in the existing method need not be deployed. The target PE device can exchange VPN routing information directly through the BGP protocol according to the address of the VTEP of the first PE device, and does not need to transfer the VPNv4/6 routing table in the existing method. It can be seen that the route publishing method of the embodiment of the present invention does not need to adopt an RD policy and an RT policy, and simplifies the route deployment scheme of the NVo3 network.

In the embodiment of the present invention, the target PE device may be a PE device directly connected to the first PE device, or may be a PE device connected to the first PE device by using a route reflector (RR). . The RR is configured to reflect routing information between PE devices connected to the RR.

If the target PE device is connected to the first PE device by using the RR, the first PE device sends the second tenant route to the RR, and the RR sends the second tenant route to the The target PE device.

FIG. 4 is a flowchart of a method for publishing tenant routes in an NVo3 network according to Embodiment 2 of the present invention. The method provided in the second embodiment of the present invention includes:

S21: The first PE device receives a third tenant route from the second PE device.

The third tenant route includes a second VNID, an IP address of the second CE device, and a location The address of the VTEP of the second PE. The second VNID is used to identify a VPN to which the second CE device belongs.

In the embodiment of the present invention, the first PE device may be directly connected to the second PE device, and receive the third tenant route from the second PE device. In addition, the first PE device may be connected to the second PE device by using the RR, and obtain the third tenant route from the second PE by using the RR.

In an implementation manner, the receiving, by the first PE device, the third tenant route from the second PE device by using the RR includes: the first PE device receiving the third Tenant routing. Optionally, after receiving the third tenant route pushed by the RR, the first PE device determines whether the third tenant route is a tenant route required for transmitting the service information by itself. If the third tenant route is a required tenant route, the first PE device stores the third tenant route into a routing table that matches the second VNID. If the third tenant route is not the required tenant route, the first PE device may discard the received third tenant route.

In another implementation manner, the receiving, by the first PE device, the third tenant route from the second PE device by using the RR includes: sending, by the first PE device, a request message to the RR, where The request message is used to request the third tenant route to the RR; the first PE device receives the third tenant route sent by the RR. The request message may carry information for identifying the third tenant route, such as the second VNID. The third tenant route sent by the RR is a tenant route determined according to the information used to identify the third tenant route.

S22: The first PE device stores the received third tenant route into a tenant routing table that matches the second VNID.

Optionally, the third tenant route further includes a type of the second virtual tunnel. The second virtual tunnel is a virtual tunnel between the first PE device and the second PE device.

S23: The first PE device determines, according to the second VNID and the type of the second virtual tunnel, the second virtual tunnel used by the third tenant route.

Optionally, the third tenant route further includes a tunnel parameter. The tunnel parameters are used to determine As a tunnel of the second virtual tunnel.

S24: The first PE device sends service data to the second PE device according to the determined second virtual tunnel.

Optionally, if the third tenant route further includes the tunnel parameter in S23, the first PE device further performs the second according to the determined second virtual tunnel and the tunnel parameter. The PE device sends service data.

FIG. 5 is a flowchart of a method for publishing tenant routes in an NVo3 network according to Embodiment 3 of the present invention. An RR is deployed on the NVo3 network. The PEs connected to the RR reflect the primary route through the RR. The method provided in Embodiment 3 of the present invention includes:

S31: The first PE device sends a request message to the RR, where the request message is used to request a third tenant route to the RR.

The request message sent by the first PE device to the RR includes a VNID included in the requested tenant route. If the VNID included in the tenant route requested by the first PE device is the second VNID, the RR sends the third tenant route including the second VNID to the first PE device.

S32: The first PE device receives the third tenant route from the RR.

The third tenant route includes a second VNID, an IP address of the second CE device, and an address of the VTEP of the second PE. The second VNID is used to identify a VPN to which the second CE device belongs.

S33: The first PE device stores the received third tenant route into a tenant routing table that matches the second VNID.

S34: The first PE device determines, according to the second VNID and the type of the second virtual tunnel, a second virtual tunnel used by the third tenant route.

Optionally, the third tenant route further includes a tunnel parameter.

S35: The first PE device sends service data to the second PE device according to the determined second virtual tunnel and the tunnel parameter.

In the embodiment of the present invention, the request message sent by the first PE device carries a VNI_Based ORF entry based on an outbound route filtering (ORF) protocol;

The VNI_Based ORF entry includes at least one set of routing information, and each group of routing information includes a VNID and an action, where the action is to apply for a tenant routing action or to cancel the tenant routing action, and the revoke tenant routing action is used for the RR to cancel the tenant with the corresponding VNID. routing.

Table 1 Schematic diagram of the structure of the VNI_Based ORF entry

ORF条目数(Num of ORF Entries)Number of ORF entries (Num of ORF Entries)	1字节1 byte
VNID 1VNID 1	4字节4 bytes
执行动作(Action)Execution action (Action)	1字节1 byte
……......
VNID NVNID N	4字节4 bytes
执行动作(Action)Execution action (Action)	1字节1 byte

Table 1 shows the structure of the VNI_Based ORF entry. As shown in Table 1, multiple VNIDs and their corresponding execution actions can be carried in a VNI_Based ORF entry. The above-mentioned execution action may indicate the action type by using a specified number. For example, when the value of the action is set to 0x01, the route for applying the corresponding VNI is indicated, and the value of 0x02 indicates that the route of the corresponding VNI is revoked.

When the VNI_Based ORF entry carried in the request message sent by the first PE device includes the second VNID, and the performing action of the second VNID is the application for the tenant route, the RR sends the third tenant route to the first PE device.

Optionally, the first PE device can simultaneously request the RR to send multiple tenant routes by using the VNI_Based ORF entry.

Optionally, the first PE device may also use the VNI_Based ORF entry to request the RR to revoke the tenant route including the specified VNID.

In the foregoing Embodiments 1 to 3, there are various implementations of the tenant route including the VNID, the IP address of the CE device, and the address of the VTEP of the PE device. Several examples are given as references in the embodiments of the present invention. Possible implementations are not listed one by one.

The first implementation manner is as follows: As shown in Table 2, the VNID, the IP address of the CE device, and the VTEP address of the PE device are all located in MP_REACH_NLRI.

Table 2 New MP_REACH_NLRI package table

The second implementation manner is as follows: The VNID is located in the preset extended community attribute, and the IP address of the CE device and the VTEP address of the PE device are both located in the MP_REACH_NLRI of the BGP.

Table 3 shows an extended community attribute of a VNID mapping, in which a tenant route carries multiple VNID extended community attributes and is advertised to multiple VPN networks.

Table 3 New Extended Community Attribute Structure Table

The third implementation mode is that the VNID, the IP address of the CE device, and the VTEP address of the PE device are respectively located in a preset extended community attribute.

FIG. 6 is a flowchart of a method for publishing tenant routes in an NVo3 network according to Embodiment 4 of the present invention; Figure. The method provided in Embodiment 4 of the present invention includes:

S41: The RR receives the second tenant route sent by the first PE device.

The second tenant route is obtained by the first PE device according to a first tenant route from the first CE device. The first tenant route includes an IP address of the first CE device. The second tenant route includes a first VNID, an IP address of the first CE device, and an address of a VTEP of the first PE. The first VNID is used to identify a VPN to which the first CE device belongs.

S42: The RR sends the second tenant route to the target PE device.

The RR maintains routes of all tenants corresponding to all PE devices connected to the RR, where each tenant corresponds to one routing table.

After the RR receives the second tenant route, the RR stores the second tenant route into a routing table corresponding to the VNID included in the second tenant route.

FIG. 7 is a flowchart of a method for publishing tenant routes in an NVo3 network according to Embodiment 5 of the present invention. The method provided in Embodiment 5 of the present invention includes:

S51: The RR receives the second tenant route sent by the first PE device, where the second tenant route is obtained by the first PE device according to the first tenant route from the first CE device, and the first tenant route includes the network protocol of the first CE device. The IP address, the second tenant route includes a first virtual network identifier VNID, an IP address of the first CE device, and an address of the VTEP of the first PE, where the first VNID is used to identify the VPN to which the first CE device belongs.

S52: The RR pushes the second tenant route to other PE devices except the first PE device, and the other PE device connects to the RR.

In this embodiment, after receiving the second tenant route pushed by the RR, any one of the PE devices determines whether the received second tenant route is a tenant route required for the transmission of the service data. The any one of the PE devices determines that the received second tenant route is not the tenant route required for the transmission of the service data, and the any one of the PE devices discards the second tenant route.

In the method of the embodiment of the present invention, the method for the RR to send the second tenant route to the target PE device may also be that the RR receives the request message for requesting the tenant route sent by the target PE device, where the request message carries the requested message. The VNID included in the tenant route; the RR will be the second tenant road Sent to the target PE device. The VNID carried in the request message is consistent with the VNID in the second tenant route.

Optionally, the request message carries a VNI_Based ORF entry based on the ORF protocol; the VNI_Based ORF entry includes a VNID of the requested tenant route.

Optionally, the VNI_Based ORF entry further includes a VNID included in a tenant route that the PE device requests the RR to revoke. The method provided by the embodiment of the present invention further includes: the RR cancels the corresponding tenant route according to the VNID included in the tenant route that the PE device requests the RR to revoke.

In the embodiment of the present invention, the manner in which the tenant route includes the VNID, the IP address of the CE device, and the address of the virtual tunnel endpoint VTEP of the PE device is the same as that in the third embodiment, and details are not described herein again.

Figure 8 is a schematic diagram of a scenario for publishing tenant routes on an NVo3 network.

The structure shown in Figure 8 is a common topology in the NVo3 network. A forwarding device, such as a Spine device, acts as a BGP RR. The leaf device serves as the virtual machine for the NVE device to access the tenant. As shown in FIG. 9 , the system includes a leaf, a leaf 2, and a leaf 3, and a virtual machine (VM) belonging to a different tenant, where the VM 11 and the VM 13 are virtual to the tenant VNI 100. VM21, VM22, and VM23 are virtual machines belonging to the tenant VNI200, VM31 and VM33 are virtual machines belonging to the tenant VNI300, and the RR node maintains a routing table for the tenants VNI100, VNI200, and VNI300, respectively.

Based on the topology shown in FIG. 8, the tenant communication method in the NVo3 network includes:

(1) Leaf3 publishes tenant routes to Spine.

Among them, Leaf3 publishes tenant routes including:

NLRI: VNID 300, tunnel type 8, address prefix p1;

Tunnel attribute: parameters related to the specific tunnel type

NHP (Next hop, next hop): Leaf3

Leaf3 publishes the tenant route encapsulated into BGP UPDATE (Border Gateway Protocol Update Packet) and sends it to Spine.

(2) Spine receives the route advertised by Leaf3, Spine does not change its next hop, and will receive the route. Routes sent to Leaf1, such as Leaf1, sent by Spine to Leaf1 include:

NLRI: VNID 300, tunnel type: 8, address prefix: p1

Tunnel attribute: parameters related to the specific tunnel type

NHP: Leaf3

The tenant route sent by Spine is encapsulated into a BGP UPDATE.

(3) After receiving the reflected route of Spine, Leaf1 can perform the following operations, including:

(a) According to the VNID in the NLRI, the route is added to the routing table corresponding to the VNID.

(b) According to the VNID and the tunnel type specified in the NLRI, the tunnel to Leaf3 used by the route is uniquely determined.

(c) Obtain the tunnel-related parameters carried by the route for use when the leaf1 uses the tunnel to forward traffic to the Leaf3.

Figure 9 is a schematic diagram of another scenario for publishing tenant routes in an NVo3 network.

As shown in Figure 9, the Spine node, which is a BGP route reflector, maintains all routes of the tenants 100, 200, and 300. When VM22 in Leaf2 is not online, Leaf2 does not need a tenant route with a VNID of 200. After VM22 goes online, Leaf2 needs to apply to Spine for a tenant route with a VNID of 200.

The lease route that the leaf2 applies to the Spine with a VNID of 200 includes:

(a) Leaf2 sends a request message requesting tenant 200 routing to Spine

Specifically, the request message sent by the Leaf2 is encapsulated into a BGP ORF Request message, where the message includes a VNID 200, indicating that the tenant route of the VNID 200 is requested, and the request is sent to the Spine.

(b) Spine sends the tenant route requested by Leaf2 to Leaf2.

In the method provided by the embodiment of the present invention, the Spine node collects the route of the tenant 200, and the route of the tenant 200 collected by the Spine node is encapsulated into a BGP UPDATE, and is sent to the Leaf2.

FIG. 10 is a schematic structural diagram of an apparatus for issuing a tenant route in an NVo3 network according to an embodiment of the present disclosure. As shown in FIG. 10, the device: a tenant route generation module 1201 and a route issuance module 1202, wherein:

The tenant route generating module 1201 is configured to obtain a second tenant route according to the first tenant route from the first user edge CE device, where the first tenant route includes a network protocol IP of the first CE device The second tenant route includes a first virtual network identifier VNID, an IP address of the first CE device, and an address of the virtual tunnel endpoint VTEP of the first PE, where the first VNID is used to identify the virtual private network VPN to which the first CE device belongs;

The route issuing module 1202 is configured to send a second tenant route to the target PE device.

In the above embodiment, the tenant route generation module 1201 is specifically configured to:

Determining a first VNID according to the first CE device IP address included in the first tenant route;

Adding the address of the first VNID and the virtual tunnel endpoint VTEP of the first PE to the first tenant route to obtain a second tenant route.

In the above embodiment, the second tenant route further includes a type of the first virtual tunnel, and the first virtual tunnel is a virtual tunnel between the first PE and the target PE device.

In the above embodiment, the route issuance module 1202 is specifically configured to:

The second tenant route is sent to the target PE device through the route reflector RR.

In the above embodiment, the apparatus for issuing the tenant route in the NVo3 network further includes a receiving module, configured to receive a third tenant route from the second PE device, where the third tenant route includes the second VNID and the IP of the second CE device. The address and the address of the VTEP of the second PE, where the second VNID is used to identify the VPN to which the second CE device belongs.

In the above embodiment, the receiving module is specifically configured to:

Receive the third tenant route pushed by the RR; or

Sending a request message to the RR, where the request message is used to request a third tenant route from the RR;

Receives the third tenant route sent by the RR.

In the above embodiment, the third tenant route further includes a type of the second virtual tunnel, and the second virtual tunnel is a virtual tunnel between the first PE device and the second PE device, and the device further includes:

FIG. 11 is a schematic structural diagram of a PE device according to an embodiment of the present invention. The PE device is deployed as the first PE device in the NVo3 network, where the NVo3 network includes: a service provider backbone network and at least one virtual private network VPN; each tenant corresponds to at least one VPN; the PE device 1400 package The communication interface 1401, the memory 1403, and the processor 1402, wherein the communication interface 1401, the processor 1402, the memory 1403 are connected to each other through the bus 1404; the bus 1404 may be a peripheral component interconnection standard (PE device ripheral component interconnect, referred to as PCI) ) Bus or extended industry standard architecture (EISA) bus. The bus can be divided into an address bus, a data bus, a control bus, and the like. For ease of representation, only one thick line is shown in Figure 14, but it does not mean that there is only one bus or one type of bus.

The communication interface 1401 is for communicating with the transmitting end. The memory 1403 is configured to store a program. In particular, the program can include program code, the program code including computer operating instructions. The memory 1403 may include a random access memory (random acCE device ss memory, RAM for short), and may also include a non-volatile memory, such as at least one disk storage.

The processor 1402 executes the program stored in the memory 1403 and executes:

Obtaining a second tenant route according to the first tenant route from the first CE device, where the first tenant route includes an IP address of the first CE device, and the second tenant route includes a first VNID, an IP address of the first CE device, and the first The address of the VTEP of the PE device. The first VNID is used to identify the VPN to which the first CE device belongs.

Send a second tenant route to the target PE device.

The processor 1402 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP processor, etc.), or a digital signal processing (DSP). , application-specific integrated circuit (ASIC), field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware component.

One of ordinary skill in the art will appreciate that all or part of the steps to implement the various method embodiments described above may be accomplished by hardware associated with the program instructions. The aforementioned program can be stored in a computer readable storage medium. The program, when executed, performs the steps including the foregoing method embodiments; and the foregoing storage medium includes various media that can store program codes, such as a ROM, a RAM, a magnetic disk, or an optical disk.

Finally, it should be noted that the above embodiments are only used to exemplify the technical solutions of the present invention, and are not limited thereto; although the beneficial effects brought by the present invention and the present invention are described in detail with reference to the foregoing embodiments, the field It should be understood by those skilled in the art that the technical solutions described in the foregoing embodiments may be modified or equivalently replaced with some of the technical features; and such modifications or substitutions do not deviate from the essence of the corresponding technical solutions. The scope of the claims.

Claims

A method for publishing tenant routes in an NVo3 network, where the method includes:

The first service provider edge PE device obtains a second tenant route according to the first tenant route from the first user edge CE device, where the first tenant route includes a network protocol IP address of the first CE device, where the The second tenant route includes a first virtual network identifier VNID, an IP address of the first CE device, and an address of a virtual tunnel endpoint VTEP of the first PE device, where the first VNID is used to identify the virtuality to which the first CE device belongs. Private network VPN;

The first PE device sends the second tenant route to the target PE device.
The method according to claim 1, wherein the first service provider edge PE device obtains the second tenant route according to the first tenant route from the first user edge CE device, including:

Determining, by the first PE device, the first VNID according to the first CE device IP address included in the first tenant route;

The first PE device adds the address of the first VNID and the virtual tunnel endpoint VTEP of the first PE to the first tenant route to obtain the second tenant route.
The method according to claim 1 or 2, wherein the second tenant route further includes a type of the first virtual tunnel, and the first virtual tunnel is between the first PE and the target PE device Virtual tunnel.
The method according to any one of claims 1 to 3, wherein the sending, by the first PE device, the second tenant route to the target PE device comprises:

The first PE device sends the second tenant route to the target PE device by using a route reflector RR.
The method according to any one of claims 1 to 4, wherein the method further comprises:

The first PE device receives a third tenant route from the second PE device, where the third tenant route includes a second VNID, an IP address of the second CE device, and an address of the VTEP of the second PE. The second VNID is used to identify the VPN to which the second CE device belongs.
The method according to claim 5, wherein the receiving, by the first PE device, the third tenant route from the second PE device comprises:

Receiving, by the first PE device, the third tenant route pushed by the RR; or

Sending, by the first PE device, a request message to the RR, where the request message is used to request the third tenant route from the RR;

The first PE device receives the third tenant route sent by the RR.
The method according to claim 5, wherein the third tenant route further includes a type of the second virtual tunnel, and the second virtual tunnel is between the first PE device and the second PE device The virtual tunnel, the method further includes:

Determining, by the first PE device, the second virtual tunnel that is used by the third tenant route according to the second VNID and the type of the second virtual tunnel.
An apparatus for publishing tenant routes in an NVo3 network, where the apparatus includes:

a route generation module, configured to obtain a second tenant route according to the first tenant route from the first user edge CE device, where the first tenant route includes a network protocol IP address of the first CE device, and the second tenant The route includes a first virtual network identifier VNID, an IP address of the first CE device, and an address of a virtual tunnel endpoint VTEP of the first PE, where the first VNID is used to identify a virtual private network VPN to which the first CE device belongs. ;

The route issuing module is configured to send the second tenant route to the target PE device.
The device according to claim 8, wherein the route generation module is specifically configured to:

Determining the first VNID according to the first CE device IP address included in the first tenant route;

Adding the address of the first VNID and the virtual tunnel endpoint VTEP of the first PE to the first tenant route to obtain the second tenant route.
Apparatus according to claim 8 or claim 9 wherein said second tenant route The first virtual tunnel is a virtual tunnel between the first PE and the target PE device.
The device according to any one of claims 8 to 10, wherein the route issuing module is specifically configured to:

The second tenant route is sent to the target PE device by using a route reflector RR.
The device according to any one of claims 8 to 11, wherein the device further comprises:

a receiving module, configured to receive a third tenant route from the second PE device, where the third tenant route includes a second VNID, an IP address of the second CE device, and an address of the VTEP of the second PE, where the second VNID is used The VPN to which the second CE device belongs is identified.
The device according to claim 12, wherein the receiving module is specifically configured to:

Receiving the third tenant route pushed by the RR; or

Sending a request message to the RR, where the request message is used to request the third tenant route from the RR;

Receiving the third tenant route sent by the RR.
The apparatus according to claim 12, wherein the third tenant route further includes a type of the second virtual tunnel, and the second virtual tunnel is between the first PE device and the second PE device The virtual tunnel, the device further includes:

And a determining module, configured to determine, according to the second VNID and the type of the second virtual tunnel, the second virtual tunnel used by the third tenant route.