A method and device for processing packets in a static Layer 3 Virtual Private Network (L3VPN).

Abstract

This application discloses a method and apparatus for processing packets in a static Layer 3 Virtual Private Network (L3VPN). The method includes: receiving a first L3VPN packet through a first tunnel. In response to determining that the peer endpoint device of the first tunnel and the next hop of the first L3VPN packet are the same device, forwarding the first L3VPN packet to the next hop is avoided. The solution provided by this application can effectively detect routing loops, prevent traffic storms, and reduce the risk of packet congestion.

Description

Technical Field

[0001] This application relates to the field of communication technology, specifically to a method and device for processing packets in a static three-layer virtual private network (L3VPN). Background Technology

[0002] With the development of Internet Protocol (IP) in telecommunications services, the explosive growth of services, and the surge in data services, the Synchronous Digital Hierarchy (SDH) technology, based on Time Division Multiplexing (TDM) circuit switching, has become inadequate for the needs of packet transmission. Network technologies based on IP packet switching (such as Packet Transport Network (PTN)) have emerged, successfully achieving unified transport of all services and network convergence, forming a flexible, efficient, and low-cost packet transport network.

[0003] The rapid increase in business volume and users' higher demands for service stability have placed greater demands on network reliability. Routing loops, or traffic loops, refer to the phenomenon where data packets continuously travel through the network but never reach their destination. When routing loops occur in a network, they can cause network congestion, packet loss, and other problems, affecting the delivery of normal services. Therefore, how to effectively detect routing loops in the network and avoid problems such as network congestion and packet loss urgently needs to be addressed. Summary of the Invention

[0004] This application discloses a method and device for statically processing packets in a layer 3 virtual private network (L3VPN), which can effectively detect routing loops in the network (e.g., PTN network) and avoid problems such as service congestion and packet loss in the network.

[0005] The first aspect of this application provides a method for processing packets in a static Layer 3 Virtual Private Network (L3VPN), executed by a first network-side edge device (provider edge router, PE). In a static L3VPN scenario, it is necessary to configure the VPN instance maintained by the PE device, or in other words, configure the VPN routing and forwarding (VRF) maintained by the PE device, including but not limited to configuring the tunnels and routes of the PE device in each VPN instance. The tunnel configuration includes, but is not limited to, configuring the ingress label of the tunnel, the outgress label of the tunnel corresponding to the ingress label, and the label switching router ID (LSR ID) of the peer at the ingress. The route configuration includes, but is not limited to, configuring the destination IP and the LSR ID of the peer at the egress. The method includes: the PE device receiving a first L3VPN packet through the first tunnel. In response to determining that the peer endpoint device of the first tunnel and the next hop of the first L3VPN packet are the same device, the PE device avoids forwarding the first L3VPN packet to the next hop. As can be seen from the solution provided in the first aspect, the solution provided in this application embodiment is based on peer-to-peer loop detection. Two devices connected through at least one tunnel are referred to as forming a peer group. The solution provided in this application embodiment can effectively detect any routing loop that occurs within the same peer. Peer-based loop detection is applicable to more scenarios, such as when multiple tunnels are configured between PE devices. It can effectively detect routing loops, prevent traffic storms, avoid traffic congestion affecting other services, and improve service reliability.

[0006] In one possible implementation of the first aspect, the method further includes: in response to determining that the first identifier and the second identifier match, determining that the peer endpoint device of the first tunnel and the next hop of the first L3VPN packet are the same device, wherein the first identifier is used to uniquely correspond to the peer endpoint device, and the second identifier is used to uniquely correspond to the next hop. This implementation provides a specific way to determine that the peer endpoint device of the first tunnel and the next hop of the first L3VPN packet are the same device, which can be determined by judging whether the first identifier and the second identifier match, increasing the versatility of the solution.

[0007] In one possible implementation of the first aspect, the first L3VPN packet includes a first tunnel label and a first virtual private network (VPN) label. The first tunnel label identifies the first tunnel, and the first VPN label identifies the first VPN instance. The method further includes determining a first identifier and a second identifier based on the first L3VPN packet. In this implementation, the first identifier can be obtained based on the first tunnel label included in the first L3VPN packet, and the second identifier can be obtained through the first virtual private network (VPN) label.

[0008] In one possible implementation of the first aspect, both the first identifier and the second identifier are next-hop indices. This implementation provides a specific representation of the first and second identifiers, increasing the diversity of the solutions. When the next-hop index and the previous-hop index are the same, it can be determined that a routing loop has formed. In other words, the incoming and outgoing packets share the same peer, constituting a loop. Therefore, it is necessary to avoid sending the packet to the peer device to prevent routing loop problems, such as traffic storms and packet loss.

[0009] In one possible implementation of the first aspect, both the first identifier and the second identifier are device identifiers (IDs). If, for a given PE device, the sender and receiver of a message are the same device, then a routing loop has been formed. In other words, the incoming and outgoing messages originate from the same peer, constituting a loop. Therefore, it is crucial to avoid forwarding the message to the other end device to prevent routing loop problems that could lead to traffic storms, message loss, and other issues.

[0010] In one possible implementation of the first aspect, the first PE stores a first mapping relationship, which includes a mapping between a first identifier, the identifier of the first tunnel, and the identifier of the first VPN instance. In this implementation, once the identifier of the first tunnel and the identifier of the first VPN instance are determined, a first identifier can be uniquely identified. This first identifier is used to indicate a unique corresponding ingress endpoint device. In one possible implementation, the identifier of the first tunnel and the identifier of the first VPN instance can be determined based on the ingress tag of the first tunnel and the first VPN tag. It should be noted that, besides determining the identifier of the first tunnel and the identifier of the first VPN instance based on the ingress tag of the first tunnel and the first VPN tag, other schemes that can uniquely identify the identifier of the first tunnel and the identifier of the first VPN instance can also be used in the embodiments of this application.

[0011] In one possible implementation of the first aspect, determining the first identifier and the second identifier based on the first L3VPN message includes: determining the identifier of the first tunnel and the identifier of the first VPN instance based on the first tunnel label and the first VPN label. Using the identifier of the first tunnel and the identifier of the first VPN instance as key values, the first identifier is determined according to a first mapping relationship. In this implementation, a specific method for querying the first mapping relationship is provided: first, using the identifier of the first tunnel and the identifier of the first VPN instance as key values, and then searching for the first identifier uniquely corresponding to that key value.

[0012] In one possible implementation of the first aspect, the second identifier is included in the first forwarding table of the first VPN instance. In this implementation, the second identifier can be obtained by querying the forwarding information table (FIB) to obtain the next hop (NHP) index. Alternatively, the second identifier can be obtained by querying the next hop (NHP) table to obtain the NHP index.

[0013] In one possible implementation of the first aspect, determining the first identifier and the second identifier based on the first L3VPN message includes: after receiving the first L3VPN message, determining the identifier of the first VPN instance based on the first VPN tag; and determining the second identifier in a first forwarding table based on the destination Internet Protocol IP address of the first L3VPN message and the identifier of the first VPN instance. In this implementation, when a PE device receives a message, it first locates the VRFID based on the message, and then queries the aforementioned A mapping relationship and B mapping relationship based on the incoming tag and destination IP indicated in the message. When it is determined that the peer LSR ID indicated by the first identifier and the second identifier are the same, it can be determined that the message received from the peer device should be forwarded to the same peer device again. In other words, this indicates that the incoming and outgoing messages are from the same peer, forming a loop, and the message should be avoided from being forwarded to the peer device again to prevent routing loop problems, such as traffic storms and message loss.

[0014] In one possible implementation of the first aspect, the method further includes: issuing an alarm to indicate a packet loop. In one possible implementation, the alarm includes the VRF ID carried by the loop packet and the destination IP address to quickly locate the packet.

[0015] A second aspect of this application provides a network edge device (PE), including: a transceiver module for receiving a first L3VPN packet through a first tunnel; and a processing module for avoiding forwarding the first L3VPN packet to the next hop in response to determining that the next hop of the peer endpoint device of the first tunnel and the first L3VPN packet received by the transceiver module is the same device.

[0016] In one possible implementation of the second aspect, the processing module is further configured to: determine, in response to determining that the peer endpoint device of the first tunnel and the next hop of the first L3VPN packet are the same device, wherein the first identifier is used to uniquely correspond to the peer endpoint device, and the second identifier is used to uniquely correspond to the next hop.

[0017] In one possible implementation of the second aspect, the first L3VPN message includes a first tunnel label and a first virtual private network (VPN) label. The first tunnel label is used to identify the first tunnel, and the first VPN label is used to identify the first VPN instance. The processing module is also used to: determine the first identifier and the second identifier based on the first L3VPN message.

[0018] In one possible implementation of the second aspect, both the first identifier and the second identifier are next-hop indices.

[0019] In one possible implementation of the second aspect, both the first identifier and the second identifier are device identifiers (IDs).

[0020] In one possible implementation of the second aspect, the first PE stores a first mapping relationship, which includes a mapping between a first identifier, an identifier of a first tunnel, and an identifier of a first VPN instance.

[0021] In one possible implementation of the second aspect, the processing module is specifically configured to: determine the identifier of the first tunnel and the identifier of the first VPN instance based on the first tunnel label and the first VPN label; and determine the first identifier based on the first mapping relationship, using the identifier of the first tunnel and the identifier of the first VPN instance as key values.

[0022] In one possible implementation of the second aspect, the first forwarding table of the first VPN instance includes the second identifier.

[0023] In one possible implementation of the second aspect, the processing module is specifically configured to: upon receiving a first L3VPN message, determine the identifier of a first VPN instance based on a first VPN label; and determine a second identifier in a first forwarding table based on the destination Internet Protocol (IP) address of the first L3VPN message and the identifier of the first VPN instance.

[0024] In one possible implementation of the second aspect, the transceiver module is also used to: issue alarms and indicate message loops.

[0025] A third aspect of this application provides a method for processing packets in a static Layer 3 Virtual Private Network (L3VPN), executed by a first network-side edge device (provider edge router, PE). The method includes: receiving a first L3VPN packet through a first tunnel; and forwarding the first L3VPN packet to the next hop in response to determining that the peer endpoint device of the first tunnel and the next hop of the first L3VPN packet are not the same device.

[0026] In one possible implementation of the third aspect, the method further includes: in response to determining that the first identifier and the second identifier do not match, determining that the peer endpoint device of the first tunnel and the next hop of the first L3VPN message are not the same device, wherein the first identifier is used to uniquely correspond to the peer endpoint device, and the second identifier is used to uniquely correspond to the next hop.

[0027] In one possible implementation of the third aspect, the first L3VPN message includes a first tunnel label and a first virtual private network (VPN) label, the first tunnel label being used to identify the first tunnel and the first VPN label being used to identify the first VPN instance. The method further includes: determining a first identifier and a second identifier based on the first L3VPN message.

[0028] In one possible implementation of the third aspect, both the first identifier and the second identifier are next-hop indices.

[0029] In one possible implementation of the third aspect, both the first identifier and the second identifier are device identifiers (IDs).

[0030] In one possible implementation of the third aspect, the first PE stores a first mapping relationship, which includes a mapping between a first identifier, the identifier of a first tunnel, and the identifier of a first VPN instance.

[0031] In one possible implementation of the third aspect, determining the first identifier and the second identifier based on the first L3VPN message includes: determining the identifier of the first tunnel and the identifier of the first VPN instance based on the first tunnel label and the first VPN label; and determining the first identifier based on the identifier of the first tunnel and the identifier of the first VPN instance as key values, according to a first mapping relationship.

[0032] In one possible implementation of the third aspect, the first forwarding table of the first VPN instance includes the second identifier.

[0033] In one possible implementation of the third aspect, determining the first identifier and the second identifier based on the first L3VPN message includes: upon receiving the first L3VPN message, determining the identifier of the first VPN instance based on the first VPN label; and determining the second identifier in a first forwarding table based on the destination Internet Protocol (IP) address of the first L3VPN message and the identifier of the first VPN instance.

[0034] A fourth aspect of this application provides a network-side edge device (PE), characterized in that it includes: one or more processors coupled to a memory, the memory storing a program that, when executed by the one or more processors, implements the method described in the first aspect or any possible implementation of the first aspect.

[0035] A fifth aspect of this application provides a computer-readable storage medium, characterized in that it includes a program, which, when executed by a processing unit, performs the method described in the first aspect or any possible implementation thereof.

[0036] A sixth aspect of this application provides a chip, characterized in that the chip is coupled to a memory for executing a program stored in the memory to perform a method as described in the first aspect or any possible implementation thereof.

[0037] A seventh aspect of this application provides a computer program product, including a computer program / instructions, characterized in that, when the computer program / instructions are executed by a processor, they implement the method described in the first aspect or any possible implementation thereof.

[0038] The technical effects of the second to seventh aspects or any of their possible implementations can be found in the first aspect or the technical effects of different possible implementations of the first aspect, and will not be repeated here. Attached Figure Description

[0039] Figure 1 This application provides a schematic diagram of the architecture of a communication system.

[0040] Figure 2 This is a schematic diagram of the architecture of another communication system provided in an embodiment of this application;

[0041] Figure 3 A flowchart illustrating a method for processing packets in a static L3VPN, provided as an embodiment of this application;

[0042] Figure 4 This is a schematic diagram of the architecture of another communication system provided in an embodiment of this application;

[0043] Figure 5 This is a schematic diagram of a statically configured L3VPN according to an embodiment of this application;

[0044] Figure 6 This is a schematic diagram of another static configuration of L3VPN in an embodiment of this application;

[0045] Figure 7 This is a schematic diagram of another static configuration of L3VPN in an embodiment of this application;

[0046] Figure 8 A flowchart illustrating another method for processing packets in a static L3VPN provided in this application embodiment;

[0047] Figure 9 A schematic diagram of the structure of a PE provided in an embodiment of this application;

[0048] Figure 10 This is a schematic diagram of another PE structure provided in an embodiment of this application. Detailed Implementation

[0049] The embodiments of this application are described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. As those skilled in the art will recognize, with the development of technology and the emergence of new scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0050] This application provides a method and device for processing packets in a static Layer 3 Virtual Private Network (L3VPN). The solution provided by this application can effectively detect routing loops and avoid problems such as service congestion and packet loss caused by routing loops.

[0051] To better understand the solutions provided in the embodiments of this application, the system architecture that may be applicable to the embodiments of this application will be introduced below.

[0052] For example, Figure 1 This is a schematic diagram of the architecture of a communication system provided in an embodiment of this application. Figure 1 As shown, the architecture of this communication system includes an access layer network, an aggregation layer network, and a core layer network. It should be noted that... Figure 1 The devices in the access layer network, aggregation layer network, and core layer network shown are merely illustrative examples and do not represent that the communication system in this application embodiment can only include... Figure 1 The devices shown are as follows. Specifically, the architecture of the communication system, the devices included in the communication system, and the connection relationships between the various devices in the communication system can be determined according to the actual situation.

[0053] In this context, the access-side equipment in the access layer network can be radio access network (RAN) equipment. RAN equipment can include various types of base stations. For example, it can include various forms of macro base stations, micro base stations, relay stations, access points, etc. The name of the equipment with base station functions may differ in systems employing different radio access technologies. For example, in a long term evolution (LTE) system network, it is called an evolved Node B (eNB or eNodeB), in a 3G network, it is called Node B, etc. In a 5G network, it can be called a g node (gNode B, gNB), etc., and this application embodiment is not limited to these terms. Furthermore, one possible approach is that the access network equipment can consist of centralized units (CUs) and distributed units (DUs). One CU can connect to one DU, or multiple DUs can share one CU, which can save costs and facilitate network expansion.

[0054] The core network-side equipment in the core layer network may vary across different communication systems. For example, in a 4G-based communication network, core network-side equipment may include a mobility management entity (MME) or a serving gateway (S-GW). In a 5G system, core network-side equipment may include access and mobility management functions (AMF), session management functions (SMF), and so on.

[0055] The aggregation layer network connects access-side devices and core network-side devices through network devices, enabling traffic exchange between access-side devices and core network-side devices (sometimes referred to as packet forwarding in this application), or traffic exchange between access-side devices. In some embodiments, the aggregation layer network may be, for example, a PTN. It should be noted that other types of services can also be carried through this communication network, which is not limited in specific embodiments of this application. In this communication network, network devices can forward packets based on a layer 2 virtual private network (L2VPN) or a layer 3 virtual private network (L3VPN). The solution provided in this application mainly targets the scenario of packet forwarding based on L3VPN, specifically the scenario of packet forwarding based on static L3VPN.

[0056] L3VPN is an IP-based virtual private network (VPN) technology. Specifically, it's a three-layer reachable VPN (layers: core, aggregation, and access), providing virtual private routes for users at different access points and achieving route isolation and interconnection between them. The static L3VPN scheme involves configuring VPN routes statically. Unlike dynamic L3VPN schemes, which automatically distribute VPN route configuration based on routing protocols, static L3VPN schemes configure routes manually. Once configured, the routes are fixed and visible, making them easy to manage and maintain.

[0057] Routing loops, or traffic loops, refer to the phenomenon where packets continuously travel through a communication network but never reach their destination. When routing loops occur in an aggregation layer network, they can cause service congestion, packet loss, and other problems, affecting the delivery of normal services. For example, in... Figure 1In the communication system shown, it is assumed that the destination address of the message received by device A is a core network device. The normal forwarding path of the message should be that device A forwards the message to device B, and device B then forwards the message to the core network device. However, when a routing loop occurs, after device A forwards the message to device B, device B may forward the message back to device A. The message is continuously transmitted between device A and device B, failing to reach the core network device. Because the message is continuously transmitted between device A and device B, it consumes the transmission bandwidth of both devices, posing a risk of traffic storms and resulting in message loss. It should be noted that in practical applications, routing loops may occur for various reasons, and this embodiment does not limit the causes of routing loops. For example, errors in device configuration table entries or misconfiguration during device relocation could lead to a routing loop.

[0058] To address the various problems caused by routing loops, port-based detection methods are typically employed. This method primarily determines whether a packet was sent from one port and then received from the same port. Specifically, a device can detect if a packet originating from its first port re-enters the device via that same port, and can then block that packet. For instance, by determining if the source and destination IP addresses of a packet originating from device A's first port are the same, and if the source and destination IP addresses of a packet entering device A's first port are identical—specifically, if the destination IP address of the packet originating from the first port is the same as the destination IP address of the packet entering from the first port, and the source IP address of the packet originating from the first port is the same as the source IP address of the packet entering from the first port—then it is considered that the packet originating from device A's first port has re-entered device A via that first port, thus preventing the packet from being sent through that first port again.

[0059] However, the port-based detection methods described above have significant limitations in some scenarios, failing to effectively detect routing loops and still posing a risk of traffic storms. Specifically, in communication networks employing static L3VPN solutions, multiple tunnels are typically configured between network devices to achieve network protection. These tunnels can be used for traffic load balancing or primary / backup failover; for example, if one tunnel fails, it can switch to another tunnel to continue forwarding packets without affecting normal service operation. See also... Figure 2Suppose that multiple tunnels, including tunnel1 and tunnel2, are configured between device A and device B. Tunnel1 uses ports A1 and B1, and tunnel2 uses ports A2 and B2. Device A might forward packets to device B through tunnel1. When a routing loop occurs, device B might resend the packets back to device A through tunnel2. In this scenario, device A sends a packet based on port A1 and receives the same packet based on port A2. Since the same packet is not sent and received through the same port, port-based detection methods cannot effectively detect routing loops and block further packet forwarding in this scenario.

[0060] To address the aforementioned issues, this application provides a method and device for processing packets in a static Layer 3 Virtual Private Network (L3VPN). This method effectively detects routing loops and blocks further packet forwarding in scenarios where multiple tunnels are configured between network devices, preventing traffic storms and packet loss.

[0061] The research approach of the embodiments of this application will be introduced below:

[0062] In scenarios where multiple tunnels are configured between network devices, effective detection of routing loops requires that if a packet is sent from any one of the tunnels configured between the two network devices and then received from any one of the tunnels configured between the two network devices, the network device can identify it as a loop packet, i.e., a routing loop problem has occurred, and the packet should be prevented from being forwarded again through the tunnel between the two network devices.

[0063] To achieve this objective, embodiments of this application consider loop detection based on peers. Two devices are said to form a peer if they are connected via at least one tunnel.

[0064] Peer-based loop detection detects loops when one device in a peer sends a message to another, which then sends the same message back to the first device. In this case, the forwarding of the message within the peer should be avoided. This differs from port-based loop detection, which only detects loops when the same message is sent and received through the same port. Peer-based loop detection can effectively detect loops occurring within the same peer. Furthermore, it is applicable to more scenarios, such as those with multiple tunnels configured between network devices. This effectively prevents traffic storms, avoids traffic congestion affecting other services, and improves service reliability.

[0065] The solutions provided in this application will be described in detail below with reference to specific embodiments.

[0066] See Figure 3 This is a flowchart illustrating a method for processing packets in a static L3VPN, as provided in an embodiment of this application.

[0067] like Figure 3 As shown, the method may include the following steps:

[0068] 301. The PE device receives the first L3VPN message through the first tunnel.

[0069] exist Figure 1 Based on the architecture of the communication system shown, when forwarding messages in this communication system using L3VPN technology, the architecture can be further divided. The following section will combine... Figure 4 This communication system will be further described. For example... Figure 4 As shown, the communication system includes a customer edge router (CE), a provider edge router (PE), and a provider core router (P). In this application, PE is sometimes referred to as a network-side edge device; both terms have the same meaning. Furthermore, this application sometimes refers to CE as a CE node / device, PE as a PE node / device, and P as a P node / device.

[0070] CE nodes include source CE nodes and destination CE nodes. Figure 1 Based on this, CE nodes can be viewed as devices in the access layer network or the core-side network. When a source CE node sends a packet, it only needs to forward the packet to the PE node connected to it; it does not need to understand how the PE node forwards the packet to the target CE node. PE nodes are directly connected to CE nodes and are responsible for VPN service access. Each PE can maintain one or more VPN routing and forwarding (VRF) services. PE nodes can, for example, use multi-protocol label switching (MPLS) to achieve packet communication between different CE nodes. P nodes are responsible for transparently forwarding packets and are not directly connected to CE nodes. When a P node sends a packet, it does not need to understand how to transmit the packet to the target CE node.

[0071] The solution provided in this application is mainly for PE nodes. In a static L3VPN scenario, the PE device is pre-configured statically. The following describes the solution in conjunction with... Figure 5 This displays several important configuration information that may be included when statically configuring a PE. For example... Figure 5 As shown, when performing static configuration on a PE device, it is necessary to configure the VPN instance maintained by the PE device, or in other words, configure the VRF maintained by the PE device. Specifically, in... Figure 5 In this context, VRF (Virtual Radio Frequency) identifiers are used to represent unique identifiers for each VPN instance. This includes, but is not limited to, configuring the tunneling of the PE (Peer Device) and configuring routes within each VPN instance. Figure 5 As shown, assuming the configured PE device is device A, and device A maintains VPN instances including VPN1, VPN2, and VPN3. For each VPN instance, further configuration is required for the peers included within that VPN instance, the tunnels bound to each peer, and the corresponding static routes. Combined with... Figure 5 For example, for device A, VPN1 includes two peers: device A and device B (hereinafter referred to as peer1), and device A and device C (hereinafter referred to as peer2). Further configuration involves uniquely binding each peer to a tunnel. Tunnel configuration includes, but is not limited to, configuring the tunnel's ingress label, the tunnel's egress label corresponding to the ingress label, and the label switching router ID (LSR ID) of the peer at the ingress point. Routing configuration includes, but is not limited to, configuring the destination IP address and the LSR ID of the peer at the egress point. The following section combines... Figure 5 These are some typical configuration settings.

[0072] When device B forwards a message to device A, it encapsulates the incoming label of device A to guide forwarding. After receiving the message through a pre-configured tunnel between device A and device B, device A verifies that the incoming label is the same as the locally pre-configured incoming label. If so, it removes the incoming label and encapsulates the message with the corresponding outgoing label before sending it to the next device. In this embodiment, during the static configuration process, the incoming and outgoing labels of each tunnel are configured, and the incoming label of each tunnel is unique, while the outgoing label of each tunnel is not unique.

[0073] exist Figure 5In the example shown, for peer1, the counterpart of device A is device B. Devices A and B form a peer. Device B can act as the ingress counterpart of device A, meaning packets are sent from device B to device A, and it can also act as the egress counterpart of device A, meaning packets are sent from device A to device B. Therefore, for a peer consisting of devices A and B, the ingress counterpart LSR ID and the egress counterpart LSR ID are the same. The following explanation uses the ingress counterpart LSR ID as an example to illustrate how to configure it. In this example, the ingress counterpart LSR ID is used to identify device B. In one possible implementation, the identifier of device B can be represented by its address. Therefore, in one possible implementation, the ingress counterpart LSR ID can be configured by configuring the address of device B. Furthermore, other information that can be used to uniquely identify the ingress counterpart device LSR ID can also be used in this application example to configure the ingress counterpart device LSR ID. As mentioned above, when device B forwards a packet to device A, it encapsulates the ingress label of device A to guide the forwarding. Therefore, after the static configuration process, the ingress label of device A corresponds to a unique peer LSR ID. In one possible implementation, after static configuration, the ingress label of device A corresponds to a unique peer device address. During the static configuration process, it is also necessary to configure the forwarding path to guide the packet from the source IP address to the destination IP address. For each device, after receiving a packet, if the destination IP address to which the packet is to be sent is different, the next hop of the packet may also be different, that is, the egress peer LSR ID of the device will also be different. In this embodiment, during the static configuration process, for a single device, each possible destination IP address and its corresponding egress peer LSR ID are pre-configured. In other words, after configuring the destination IP address during the static configuration process, the destination IP address corresponds to one egress peer LSR ID. It should be noted that multiple destination IP addresses may correspond to the same egress peer LSR ID.

[0074] It should be noted that in the embodiments of this application, the peer device is sometimes referred to as the peer endpoint device, and the two have the same meaning. This will not be repeated below.

[0075] The PE device receives the first L3VPN packet through the first tunnel. This first tunnel has been configured during the static configuration process, including but not limited to the ingress label of the first tunnel. Please refer to the content related to tunnel configuration above for understanding, and it will not be repeated here.

[0076] 302. In response to determining that the peer endpoint device of the first tunnel and the next hop of the first L3VPN message are the same device, the PE device avoids forwarding the first L3VPN message to the next hop.

[0077] The solution provided in this application embodiment can determine that the peer endpoint device of the first tunnel and the next-hop indicator of the first L3VPN packet are the same device in various ways, so as to avoid forwarding the first L3VPN packet to the device indicated by the next hop. The following describes how to determine that the peer endpoint device of the first tunnel and the next-hop indicator of the first L3VPN packet are the same device in this application embodiment with reference to several typical solutions.

[0078] In one possible implementation, when the PE device determines that the first identifier and the second identifier match, it determines that the peer endpoint device of the first tunnel and the next hop of the first L3VPN message indicate the same device, wherein the first identifier is used to uniquely correspond to the peer endpoint device and the second identifier is used to uniquely correspond to the next hop.

[0079] The solution provided in this application embodiment can obtain the first identifier and the second identifier through different channels. For example, in one possible implementation, the first identifier and the second identifier can be determined through the first L3VPN message. Specifically, the first L3VPN message includes a first tunnel label and a first VPN label. The first tunnel label is used to identify the first tunnel, and the first VPN label is used to identify the first VPN instance.

[0080] In the above embodiments, the first identifier and the second identifier can be represented in various ways. For example, in one possible embodiment, both the first identifier and the second identifier are device identifiers (IDs). In another possible embodiment, both the first identifier and the second identifier are next-hop indexes. The following uses these two representations as examples to further describe the solution provided in the embodiments of this application.

[0081] First and second identifiers are both the device's identification ID.

[0082] After completing the static configuration of the PE device, two mapping relationships can be generated based on the static configuration, hereinafter referred to as mapping relationship A and mapping relationship B. Mapping relationship A indicates the LSR ID of the ingress peer, uniquely determined by the ingress tag and VRF ID, while mapping relationship B indicates the LSR ID of the egress peer, uniquely determined by the destination IP and VRF ID. (Refer to...) Figure 6 The 'a' in the text refers to the mapping relationship of A, see reference. Figure 6 The 'b' in the diagram represents the mapping relationship between 'B' and 'B'. The first identifier indicates the LSR ID of the inlet peer, and the second identifier indicates the LSR ID of the outlet peer.

[0083] When a PE device receives a message, it first locates the VRFID tag based on the message, and then queries the A and B mapping relationships mentioned above based on the incoming tag and destination IP indicated in the message. If it is determined that the peer LSR ID indicated by the first and second tags are the same, it can be concluded that the message received from the peer device needs to be re-sent to that peer device. In other words, this indicates that the incoming and outgoing messages are from the same peer, forming a loop. Therefore, it is necessary to avoid re-sending the message to the peer device to prevent routing loop problems, such as traffic storms and message loss.

[0084] It should be noted that, since ingress labels are unique, in some implementations, the A mapping relationship can also be used only to indicate the mapping between an ingress label and the ingress peer LSR ID uniquely corresponding to that ingress label. Furthermore, since destination addresses are generally not unique, it is impossible to determine the mapping between uniquely corresponding egress peer LSR IDs based on the destination address.

[0085] 2. Both the first and second identifiers are next-hop indices.

[0086] Once the static configuration of the PE device is completed, the PE device can generate the next hop (NHP) and the next hop index based on the static configuration information.

[0087] In one possible implementation, a unique next hop can be determined based on a tunnel's outgoing port and a VRF ID. In another possible implementation, a unique next hop can also be determined based on a destination IP address and a VRF ID. This application does not limit the method used to uniquely determine the next hop based on the tunnel's outgoing port / destination IP address and VRF ID; any mapping method can be used to establish the mapping relationship between the tunnel's outgoing port / destination IP address, VRF ID, and next hop. In one possible implementation, once a mapping method is chosen, the outgoing port / destination IP address and VRF ID of each tunnel need to be mapped to the next hop according to this method. This avoids situations where some tunnels have their outgoing ports / destination IP addresses and VRF IDs mapped to the next hop using one method, while other tunnels have theirs mapped using a different method.

[0088] In one possible implementation, the second identifier, which is the next-hop index, can be obtained by querying the NHP.

[0089] After statically configuring the PE device, in addition to generating an NHP, more mapping relationships can be generated. The solution provided in this application embodiment can also obtain the next-hop index through other mappings. Several other possible mapping relationships are given below as examples.

[0090] In one possible implementation, after the static configuration of the PE device is completed, a forwarding information table (FIB), a routing information table (RIB), and a next hop table can be generated based on the tunnel and routing configurations. When the PE device receives a packet, it can obtain the next hop index by querying the mapping relationships indicated by these tables. For example, it can obtain the RE index in the FIB based on the VRF ID and the destination IP in the packet, obtain the NHP index in the RE table using the RE index, and further obtain the outgoing interface of the packet, i.e., the next hop, in the NHP table. In another possible implementation, the NHP index may be obtained directly from the FIB. For example, it might also include an ingress port attribute table (IPAT) and an ingress cluster information base (ICIB). When a PE device receives a packet, it obtains the index corresponding to the port of the tunnel that received the packet. Using this port index and the VLAN identifier carried in the packet, it retrieves the VRF ID from the ICIB. Based on the VRF ID and the destination IP address in the packet, it retrieves the RE index from the FIB. Using the RE index, it retrieves the NHP index from the RE table and then obtains the next hop from the NHP table. Furthermore, it might also include an access information base (AIB). The NHP table can also indicate the AIB index, and the AIB table can be further accessed through the AIB index to obtain the packet encapsulation information.

[0091] In addition to the mapping relationships mentioned above, this application embodiment also generates a new mapping relationship, hereinafter referred to as the first mapping relationship, through which the first identifier can be obtained. See also... Figure 7 After the static configuration is completed, the first mapping relationship is generated. Figure 7 To better illustrate this mapping relationship, a table is used to present it.

[0092] The first mapping relationship includes a mapping between a first identifier, a first tunnel identifier, and a first VPN instance identifier. Once the first tunnel identifier and the first VPN instance identifier are determined, a first identifier can be uniquely identified. This first identifier is used to indicate a unique corresponding ingress endpoint device. In one possible implementation, the first tunnel identifier and the first VPN instance identifier can be determined based on the first tunnel's ingress label and the first VPN label. It should be noted that, besides determining the first tunnel identifier and the first VPN instance identifier based on the first tunnel's ingress label and the first VPN label, other schemes that can uniquely identify the first tunnel identifier and the first VPN instance identifier can also be used in the embodiments of this application.

[0093] In one possible implementation, when generating the first mapping relationship, the static configuration of the PE is considered, specifically considering the ingress tag and VRF ID of a tunnel to determine a unique index of the previous hop. In this embodiment, the first mapping relationship is generated using the same mapping method as that used to generate the NHP. For example, if the mapping relationship between the tunnel's egress port, destination IP, and next-hop index is established using the A mapping method, then the mapping relationship between the tunnel's ingress tag, VRFID, and previous-hop index is also established using the same A mapping method.

[0094] In this way, if the next-hop index obtained through the normal table lookup process (such as by querying the FIB or the NHP table) is the same as the previous-hop index obtained through the first mapping relationship, it can be determined that a routing loop has formed. In other words, it means that the incoming and outgoing packets are from the same peer, which constitutes a loop. The packet should not be sent to the peer device again to prevent routing loop problems, such as traffic storms and packet loss.

[0095] It should be noted that since the previous hop index and the next hop index are essentially the same, both used to indicate the peer device of the PE device, the embodiments of this application also refer to the previous hop index and the next hop index as the next hop index.

[0096] In one possible implementation, an alarm can also be issued to indicate a packet loop. In one possible implementation, the alarm includes the VRF ID and destination IP carried by the loop packet to quickly locate the packet.

[0097] The above describes the scheme for detecting loop packets in the embodiments of this application. When it is determined that the peer endpoint device of the first tunnel and the next hop of the first L3VPN packet are the same device, the forwarding of the first L3VPN packet to the next hop is avoided. In some embodiments, in response to determining that the peer endpoint device of the first tunnel and the next hop of the first L3VPN packet are not the same device, the first L3VPN packet is forwarded to the next hop. A specific embodiment will be described below.

[0098] See Figure 8 This is a flowchart illustrating another method for processing packets in a static L3VPN provided in this application embodiment.

[0099] like Figure 8 As shown, the method may include the following steps:

[0100] 801. The PE device receives the first L3VPN message through the first tunnel.

[0101] Step 801 can be referred to Figure 3 The steps 301 in the corresponding embodiments will be understood and will not be repeated here.

[0102] 802. In response to determining that the peer endpoint device of the first tunnel and the next hop of the first L3VPN message are not the same device, the PE device forwards the first L3VPN message to the next hop.

[0103] In one possible implementation, in response to determining that the first identifier and the second identifier do not match, it is determined that the peer endpoint device of the first tunnel and the next hop of the first L3VPN message are not the same device, wherein the first identifier is used to uniquely correspond to the peer endpoint device; and the second identifier is used to uniquely correspond to the next hop.

[0104] In one possible implementation, a first identifier and a second identifier can be determined based on the first L3VPN message. The first identifier and the second identifier represent references... Figure 3 The first and second identifiers described in the corresponding embodiments are for reference only and will not be repeated here.

[0105] It should be noted that the various implementation methods described in the embodiments of this application can be combined, and the embodiments of this application do not limit this.

[0106] Based on the above method embodiments, in order to better implement the above solutions of this application, related equipment for implementing the above solutions is also provided below. See details. Figure 9 A schematic diagram of the structure of a PE device according to an embodiment of this application. The PE device includes:

[0107] Transceiver module 901 is used to perform... Figure 3 In the corresponding embodiment, step 301, Figure 8 Step 801 in the corresponding embodiment.

[0108] Processing module 902 is used to execute Figure 3 In the corresponding embodiment, step 302, Figure 8 Step 802 in the corresponding embodiment.

[0109] Specifically, in one possible implementation, transceiver module 901 is configured to receive a first L3VPN message through a first tunnel. Processing module 902 is configured to avoid forwarding the first L3VPN message to the next hop in response to determining that the peer endpoint device of the first tunnel and the next hop of the first L3VPN message received by transceiver module 901 are the same device.

[0110] In one possible implementation, the processing module 902 is further configured to: in response to determining that the peer endpoint device of the first tunnel and the next hop of the first L3VPN packet are the same device, wherein the first identifier is used to uniquely correspond to the peer endpoint device, and the second identifier is used to uniquely correspond to the next hop.

[0111] In one possible implementation, the first L3VPN message includes a first tunnel label and a first virtual private network (VPN) label. The first tunnel label is used to identify the first tunnel, and the first VPN label is used to identify the first VPN instance. The processing module 902 is further configured to: determine the first identifier and the second identifier based on the first L3VPN message.

[0112] In one possible implementation, both the first identifier and the second identifier are next-hop indices.

[0113] In one possible implementation, both the first identifier and the second identifier are device identifiers (IDs).

[0114] In one possible implementation, the first PE stores a first mapping relationship, which includes a mapping between a first identifier, the identifier of a first tunnel, and the identifier of a first VPN instance.

[0115] In one possible implementation, the processing module 902 is specifically configured to: determine the identifier of the first tunnel and the identifier of the first VPN instance based on the first tunnel label and the first VPN label; and determine the first identifier based on the first mapping relationship, using the identifier of the first tunnel and the identifier of the first VPN instance as key values.

[0116] In one possible implementation, the first forwarding table of the first VPN instance includes a second identifier.

[0117] In one possible implementation, the processing module 902 is specifically configured to: upon receiving a first L3VPN message, determine the identifier of a first VPN instance based on a first VPN tag; and determine a second identifier in a first forwarding table based on the destination Internet Protocol (IP) address of the first L3VPN message and the identifier of the first VPN instance.

[0118] In one possible implementation, the transceiver module 901 is also used to: issue an alarm to indicate a message loop.

[0119] Figure 9 The beneficial effects of the corresponding embodiments can be referred to Figure 3 The beneficial effects of the corresponding embodiments will be understood and will not be repeated here.

[0120] See Figure 10 This application provides a schematic diagram of another structure of a PE, which may include at least one processor 1001, at least one transceiver 1002, and a memory 1003. The at least one processor 1001, at least one transceiver 1002, and memory 1003 may be connected via a bus or other means. Figure 10 Taking a bus connection as an example, memory 1003 may include read-only memory 1003 and random access memory 1003, providing instructions and data to processor 1001. A portion of memory 1003 may also include non-volatile random access memory (NVRAM). Memory 1003 stores operating system and program instructions, executable modules or data structures, or subsets thereof, or extended sets thereof. The program instructions may include various operation instructions for implementing various operations. The operating system may include various system programs for implementing various basic tasks and handling hardware-based tasks.

[0121] Processor 1001 can control the operation of communication devices that process messages; processor 1001 can also be called a central processing unit (CPU). In specific applications, the various components of the software upgrade management device are coupled together via a bus, which includes not only a data bus but also a power bus, control bus, and status signal bus, etc. However, for clarity, in... Figure 10 In general, all kinds of buses can be called buses.

[0122] It should be noted that, Figure 9 In the corresponding embodiments, the physical device corresponding to all the transceiver modules described can be transceiver 1002. Figure 9In the corresponding embodiments, the physical device corresponding to all the processing modules described can be processor 1001. Figure 10 The processor 1001 and transceiver 1002 in the above embodiments implement the same or similar functions as the processing module and transceiver module provided in the foregoing embodiments. Figure 10 The memory 1003 stores the program code that the processor 1001 needs to call when executing the above method. The transceiver 1002 can also be replaced by a receiver and a transmitter, which can be the same or different physical entities. When they are the same physical entity, they can be collectively referred to as transceiver 1002; for example, the transceiver 1002 can be a radio frequency (RF) circuit. The memory 1003 can be integrated into the processor 1001 or can be set separately from the processor 1001.

[0123] The methods disclosed in the embodiments of this application described above can be applied to... Figure 10 In the processor 1001 shown, or by Figure 10 The processor 1001 shown is implemented. For example, in some embodiments, Figure 10 The processor 1001 can call program instructions stored in the memory 1003, which are the program codes that the processor 1001 needs to call when specifically executing the method in the embodiment of this application.

[0124] For example, when the controller has such Figure 10 When the structure shown is used, Figure 10 The memory 1003 stores the program code that the processor 1001 needs to call when executing the method described above by the controller. Specifically, Figure 10 The processor 1001 can call program code in memory 1003 to execute. Figure 3 In the corresponding embodiment, step 302, and Figure 8 Step 802 in the corresponding embodiment.

[0125] This application also provides a chip system including a processor for supporting a PE device in implementing the functions involved in the above aspects. In one possible design, the chip system further includes a memory for storing necessary program instructions and data. This chip system may be composed of chips or may include chips and other discrete devices.

[0126] This application also provides a processor for coupling with a memory to perform the methods and functions related to the PE device in any of the above embodiments.

[0127] This application also provides a computer-readable storage medium storing a computer program thereon. When executed by a computer, the computer program implements the method flow related to the PE device in any of the above method embodiments. Correspondingly, the computer can be the aforementioned PE device.

[0128] In the embodiments of this application, the functional units can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0129] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application embodiment, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0130] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. The term "and / or" in the embodiments of this application is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or modules is not necessarily limited to those steps or modules explicitly listed, but may include other steps or modules not explicitly listed or inherent to these processes, methods, products, or devices. The naming or numbering of steps in the embodiments of this application does not imply that the steps in the method flow must be executed in the time / logical order indicated by the naming or numbering. The execution order of the named or numbered process steps can be changed according to the technical purpose to be achieved, as long as the same or similar technical effect can be achieved. The division of modules in the embodiments of this application is a logical division. In actual applications, there may be other division methods. For example, multiple modules may be combined into or integrated into another system, or some features may be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the modules shown or discussed may be through some ports, and the indirect coupling or communication connection between modules may be electrical or other similar forms. None of these are limited in the embodiments of this application. Furthermore, the modules or sub-modules described as separate components may or may not be physically separated, may or may not be physical modules, or may be distributed in multiple circuit modules. Some or all of the modules can be selected to achieve the purpose of the embodiments of this application according to actual needs.

Claims

1. A method for processing packets in a static Layer 3 Virtual Private Network (L3VPN), characterized in that, Performed by a first network-side edge device (PE), the method includes: Receive the first L3VPN message through the first tunnel; In response to determining that the peer endpoint device of the first tunnel and the next hop of the first L3VPN packet are the same device, the forwarding of the first L3VPN packet to the next hop is avoided; In response to determining that the peer endpoint device of the first tunnel and the next hop of the first L3VPN message are not the same device, the first L3VPN message is forwarded to the next hop.

2. The method according to claim 1, characterized in that, The method further includes: In response to determining that the first identifier and the second identifier match, it is determined that the peer endpoint device of the first tunnel and the next hop of the first L3VPN packet are the same device, wherein the first identifier is used to uniquely correspond to the peer endpoint device; and the second identifier is used to uniquely correspond to the next hop.

3. The method according to claim 2, characterized in that, The first L3VPN message includes a first tunnel label and a first Virtual Private Network (VPN) label. The first tunnel label is used to identify the first tunnel, and the first VPN label is used to identify the first VPN instance. The method further includes: Based on the first L3VPN message, determine the first identifier and the second identifier.

4. The method according to claim 3, characterized in that, Both the first identifier and the second identifier are next-hop indices.

5. The method according to claim 3, characterized in that, Both the first identifier and the second identifier are device identifiers.

6. The method according to claim 4 or 5, characterized in that, The first PE stores a first mapping relationship, which includes a mapping between the first identifier, the identifier of the first tunnel, and the identifier of the first VPN instance.

7. The method according to claim 6, characterized in that, Based on the first L3VPN message, determine the first identifier and the second identifier, including: Based on the first tunnel label and the first VPN label, determine the identifier of the first tunnel and the identifier of the first VPN instance; Using the identifier of the first tunnel and the identifier of the first VPN instance as key values, the first identifier is determined according to the first mapping relationship.

8. The method according to any one of claims 5-7, characterized in that, The first forwarding table of the first VPN instance includes the second identifier.

9. The method according to claim 8, characterized in that, Determining the first identifier and the second identifier based on the first L3VPN message includes: Upon receiving the first L3VPN message, the identifier of the first VPN instance is determined based on the first VPN tag; The second identifier is determined in the first forwarding table based on the destination Internet Protocol IP address of the first L3VPN message and the identifier of the first VPN instance.

10. The method according to any one of claims 1-9, characterized in that, The method further includes: An alarm is issued, indicating a message loop.

11. A network-side edge device (PE), characterized in that, include: The transceiver module is used to receive the first L3VPN message through the first tunnel; The processing module is configured to avoid forwarding the first L3VPN message to the next hop in response to determining that the peer endpoint device of the first tunnel and the next hop of the first L3VPN message received by the transceiver module are the same device. The processing module is further configured to forward the first L3VPN message to the next hop in response to determining that the peer endpoint device of the first tunnel and the next hop of the first L3VPN message are not the same device.

12. The PE according to claim 11, characterized in that, The processing module is further configured to: In response to determining that the first identifier and the second identifier match, it is determined that the peer endpoint device of the first tunnel and the next hop of the first L3VPN packet are the same device, wherein the first identifier is used to uniquely correspond to the peer endpoint device; and the second identifier is used to uniquely correspond to the next hop.

13. The PE according to claim 12, characterized in that, The first L3VPN message includes a first tunnel label and a first Virtual Private Network (VPN) label. The first tunnel label is used to identify the first tunnel, and the first VPN label is used to identify the first VPN instance. The processing module is further configured to: Based on the first L3VPN message, determine the first identifier and the second identifier.

14. The PE according to claim 13, characterized in that, Both the first identifier and the second identifier are next-hop indices.

15. The PE according to claim 13, characterized in that, Both the first identifier and the second identifier are device identifiers.

16. The PE according to claim 14 or 15, characterized in that, The first PE stores a first mapping relationship, which includes a mapping between the first identifier, the identifier of the first tunnel, and the identifier of the first VPN instance.

17. The PE according to claim 16, characterized in that, The processing module is specifically used for: Based on the first tunnel label and the first VPN label, determine the identifier of the first tunnel and the identifier of the first VPN instance; Using the identifier of the first tunnel and the identifier of the first VPN instance as key values, the first identifier is determined according to the first mapping relationship.

18. The PE according to any one of claims 15-17, characterized in that, The first forwarding table of the first VPN instance includes the second identifier.

19. The PE according to claim 18, characterized in that, The processing module is specifically used for: Upon receiving the first L3VPN message, the identifier of the first VPN instance is determined based on the first VPN tag; The second identifier is determined in the first forwarding table based on the destination Internet Protocol IP address of the first L3VPN message and the identifier of the first VPN instance.

20. The PE according to any one of claims 11-19, characterized in that, The transceiver module is also used for: An alarm is issued, indicating a message loop.

21. A network-side edge device (PE), characterized in that, include: One or more processors coupled to a memory storing a program, wherein the program instructions stored in the memory are executed by the one or more processors to implement the method of any one of claims 1-10.

22. A computer-readable storage medium, characterized in that, The program, when executed by the processing unit, performs the method as described in any one of claims 1-10.

23. A chip, characterized in that, The chip is coupled to a memory for executing a program stored in the memory to perform the method as described in any one of claims 1 to 10.

24. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method as described in any one of claims 1 to 10.

Images