Edge device communication processing method and system, electronic device, and storage medium

Abstract

The application provides an edge device communication processing method and system, electronic equipment and a storage medium. The method comprises the following steps: a multicast receiving end PE monitors first state information of a locally stored virtual routing forwarding table in real time, and a multicast sending end PE monitors second state information of a locally stored virtual routing forwarding table in real time; the multicast receiving end PE encapsulates the first state information through a border gateway protocol module to obtain routing information, and sends the routing information to the multicast sending end PE; and the multicast sending end PE determines whether to establish a communication connection with the multicast receiving end PE according to the routing information and the second state information. The purpose of batch and rapid cutting off of multicast traffic is achieved, and the forwarding of redundant traffic in a backbone network is reduced.

Description

Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to an edge device communication processing method, system, electronic device, and storage medium. Background Technology

[0002] With the widespread adoption of BGP / MPLS IP VPNs in existing networks and the development of multicast services such as IPTV, video conferencing, and distance education, service providers have generated increasing demand for running multicast services on BGP / MPLS IP VPN networks. Multicast VPNs transmit private network data traffic to the VPN remote site via the public network by enabling multicast services on existing BGP / MPLS IP VPNs. NG-MVPN establishes a private network neighbor relationship between network edge devices (Provider Edge, PE) to transmit multicast protocol messages and achieve data forwarding. When the multicast interface on the private network side fails, it needs to wait for BGP Update messages to deliver pruning messages to remove the multicast tunnel interface of the multicast sending Provider Edge device (Sender PE). This results in multicast traffic still being forwarded to the MPLS domain for a period of time.

[0003] Currently, NG-MVPN establishes multicast neighbor relationships between PEs based on private networks through a special MVPN tunnel interface. Once established, the multicast PIM (Protocol Independent Multicast) neighbors on the tunnel interface never time out. This means the Sender PE cannot detect interface changes on the multicast receiver PE. When the receiver on the Receiver PE fails, the multicast interface on the Receiver PE is deleted, and a pruning message is sent to the Sender PE via a BGP Update message. Only upon receiving this message will the Sender PE delete the outgoing interface from its multicast forwarding table, thus cutting off multicast traffic.

[0004] In NG-MVPN, PIM neighbors between PEs never time out, making it impossible to quickly delete outgoing interfaces by detecting PIM neighbors. If a private network PIM interface fails, it is necessary to wait for BGP Update messages to delete the outgoing interfaces of upstream PEs one by one. This will cause multicast traffic to be forwarded to the MPLS domain for a period of time, preventing the batch and rapid deletion of upstream PE outgoing interfaces and resulting in a waste of network bandwidth. Summary of the Invention

[0005] The purpose of this application is to address the shortcomings of the prior art by providing an edge device communication processing method, system, electronic device, and storage medium to improve the efficiency of fault handling.

[0006] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows:

[0007] In a first aspect, embodiments of this application provide an edge device communication processing method, the method comprising:

[0008] The multicast receiver PE monitors the first status information of the virtual routing table stored locally in real time, and the multicast sender PE monitors the second status information of the virtual routing table stored locally in real time. The first status information and the second status information respectively include: normal status or fault status.

[0009] The multicast receiver PE encapsulates the first state information through the Border Gateway Protocol (BGP) module to obtain routing information, and then sends the routing information to the multicast sender PE.

[0010] The multicast sending end PE determines whether to establish a communication connection with the multicast receiving end PE based on the routing information and the second status information.

[0011] Optionally, the multicast receiver PE monitors the first state information of the locally stored virtual routing and forwarding table in real time, including:

[0012] The multicast receiver PE monitors the status information of the connection interfaces on each network device connected to the multicast receiver PE in the virtual routing table in real time.

[0013] The first status information is determined based on the status information of the connection interfaces on each network device connected to the multicast receiver PE.

[0014] Optionally, the status information of the connection interfaces on each network device connected to the multicast receiver PE determines the first status information, including:

[0015] If the status information of the connection interfaces on all network devices connected to the multicast receiver PE is in a fault state, then the first status information is determined to be in a fault state; otherwise, the first status information is determined to be in a normal state.

[0016] Optionally, the multicast receiver PE encapsulates the first state information through the Border Gateway Protocol (BGP) module to obtain routing information, and sends the routing information to the multicast sender PE, including:

[0017] The BGP module encapsulates the first status information, the identifier of the multicast tunnel interface, and the routing identifier to obtain the routing information. The source address of the routing information is the address of the multicast receiver PE, and the destination address of the routing information is the address of the multicast sender PE.

[0018] The routing information is sent to the multicast sender PE based on the source address and the destination address.

[0019] Optionally, the multicast sending end PE determines whether to establish a communication connection with the multicast receiving end PE based on the routing information and the second status information, including:

[0020] The multicast transmitter (PE) parses the routing information to obtain the first status information, the routing identifier, and the identifier of the multicast tunnel interface.

[0021] The multicast sending end PE matches the corresponding virtual routing forwarding table stored by the multicast sending end PE according to the routing identifier and obtains the second status information of the virtual routing forwarding table;

[0022] The multicast sending end PE determines whether to establish a communication connection with the multicast receiving end PE based on the first status information and the second status information.

[0023] Optionally, the multicast sending end PE determines whether to establish a communication connection with the multicast receiving end PE based on the first status information and the second status information, including:

[0024] If the value in the first status information is a first preset value, then the multicast sending end PE determines whether the value in the second status information is consistent with the first preset value. The first preset value is used to indicate that the virtual routing forwarding table of the multicast receiving end PE is in normal status.

[0025] If they match, a communication connection is established between the multicast sending end PE and the multicast receiving end PE.

[0026] Optionally, the multicast sending end PE determines whether to establish a communication connection with the multicast receiving end PE based on the first status information and the second status information, including:

[0027] If the value in the first status information is the second preset value, then the multicast sending end PE disconnects the communication connection with the multicast receiving end PE. The second preset value is used to indicate that the virtual routing table of the multicast receiving end PE is in a fault state.

[0028] Secondly, embodiments of this application also provide an edge device communication processing system, wherein the system has a receiving end (PE) and a transmitting end (PE), wherein:

[0029] The receiving end PE is used to execute the method steps executed by any of the receiving end PEs in the first aspect described above; the sending end PE is used to execute the method steps executed by any of the sending end PEs in the first aspect described above.

[0030] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a storage medium, and a bus. The storage medium stores program instructions executable by the processor. When an application runs, the processor communicates with the storage medium via the bus, and the processor executes the program instructions to perform the method steps executed by the receiving end PE or the sending end PE as described in the first aspect.

[0031] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which is read and executes the method steps executed by the receiving end PE or the sending end PE as described in the first aspect.

[0032] The beneficial effects of this application are:

[0033] This application provides an edge device communication processing method, system, electronic device, and storage medium. By monitoring the status information of the virtual routing tables stored by each device at both the multicast receiver (PE) and multicast sender (PE), the multicast receiver (PE) encapsulates the monitored status information into routing information using a border gateway protocol module and sends the routing information to the multicast sender (PE). This allows the multicast sender (PE) to determine whether to establish a communication connection with the multicast receiver (PE) based on the received routing information and the status information of its monitored virtual routing tables. Therefore, when the multicast receiver (PE) fails, the multicast sender (PE) can directly switch to edge device communication. Deleting private network multicast neighbors in the broadcast sending PE means directly deleting the multicast receiving PE in the multicast sending PE, achieving the effect of synchronously deleting all connection interfaces in the multicast forwarding table. This achieves the purpose of batch and quickly cutting off multicast traffic, reducing redundant traffic forwarding in the backbone network, and avoiding the need for existing technologies to wait for the multicast sending PE to delete each of its outgoing interfaces one by one before multicast traffic can be cut off, thus reducing network bandwidth waste. At the same time, by monitoring the status information of each virtual forwarding routing table on each device in real time, changes in the status of the virtual forwarding routing table can be quickly detected, improving the efficiency of fault handling. Attached Figure Description

[0034] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0035] Figure 1 This application provides an architectural diagram of an edge device communication processing system according to an embodiment of the present application.

[0036] Figure 2 A flowchart illustrating an edge device communication processing method provided in an embodiment of this application;

[0037] Figure 3 A flowchart illustrating another edge device communication processing method provided in an embodiment of this application;

[0038] Figure 4 A flowchart illustrating another edge device communication processing method provided in this application embodiment;

[0039] Figure 5 This is a structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0040] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0041] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0042] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0043] Figure 1 This application provides an embodiment of an edge device communication processing system architecture diagram, as shown below. Figure 1 As shown, it includes a multicast sender PE (Sender Provider Edge) and a multicast receiver PE (Receiver Provider Edge). The multicast sender PE is an edge device located close to the multicast source. Taking PE1 as an example, it can connect to the multicast source network device (e.g., Figure 1 The CE1 in the multicast receiver is used for communication; the PE is an edge device located close to the multicast receiver. Taking PE2 as an example, it can communicate with the network device of the multicast receiver (e.g., CE1). Figure 1 The CE2 and CE3 in the network communicate with each other. Among them, the Next Generation Multicast Virtual Private Network (NG-MVPN) is capable of transmitting private network multicast routes and establishing public network tunnels. Specifically, it can establish a private network multicast neighbor relationship between PE1 and PE2 to transmit multicast protocol messages and realize data forwarding.

[0044] like Figure 1 As shown, network devices CE1, CE2, and CE3 are all network devices in the same virtual routing table VRF1. PE1, PE2, and PE1 together form the operator's backbone network. CE1 acts as a multicast source network device and can forward multicast traffic. CE2 and CE3 act as multicast receiver network devices and receive messages from the multicast source network device.

[0045] Optionally, this application provides a Protocol Independent Multicast (PIM) interface monitoring mechanism in the Virtual Routing Edge (VRF) of a PE device. Each PE device in the NG-MVPN environment maintains this PIM neighbor monitoring mechanism. PE devices can enable the PIM function based on the interfaces under different VRFs, thereby recording the PIM interface status under each VRF. By having each PE monitor the PIM interfaces under different VRFs in real time, when a PIM interface under a VRF monitored by the multicast receiving PE fails, the method provided in this application is used to delete the private network multicast neighbors of the multicast sending PE, achieving batch and rapid deletion of the tunnel outgoing interfaces of the multicast sending PE, reducing network bandwidth waste.

[0046] It is worth noting that, Figure 1 The number of network devices, edge devices, and VRFs shown are exemplary, and this application does not impose specific limitations on them.

[0047] The following section will explain in detail the specific implementation process of the edge device communication processing provided in the embodiments of this application.

[0048] Figure 2 This is a flowchart illustrating an edge device communication processing method provided in an embodiment of this application, which is applied in the aforementioned application scenario. For example... Figure 2 As shown, the method includes:

[0049] S101. The multicast receiver PE monitors the first status information of the virtual routing table stored locally in real time, and the multicast sender PE monitors the second status information of the virtual routing table stored locally in real time.

[0050] Optionally, the first state information and the second state information may respectively include: normal state or fault state. For example, the normal state can be identified by the value "1", and the fault state can be identified by the value "0", or other methods can be used. This application embodiment does not impose specific limitations on this.

[0051] Optionally, both the multicast receiver (PE) and the multicast sender (PE) can store at least one virtual routing table. Each virtual routing table stores the interfaces with PIM enabled and their status information. For example, the status information of the virtual routing table can be represented using VRF[i].PIM.status, where i refers to the identifier of each VRF. Figure 1As shown, PE2, acting as a multicast receiver PE, can monitor the first status information of VRF1 in this device in real time, and PE1, acting as a multicast sender PE, can monitor the second status information of VRF1 in this device in real time.

[0052] S102. The multicast receiver PE encapsulates the first state information through the border gateway protocol module to obtain routing information, and then sends the routing information to the multicast sender PE.

[0053] The Border Gateway Protocol (BGP) module is mainly used for interconnection between autonomous network systems, primarily for controlling route propagation and selecting the best route.

[0054] The BGP module can be deployed in either the multicast receiver PE or the multicast sender PE. The BGP module in the multicast receiver PE can obtain the first status information monitored by this device, while the BGP module in the multicast sender PE can obtain the second status information monitored by this device.

[0055] For example, when the BGP module in PE2 receives the first state information of VRF1, it encapsulates the first state information of VRF1 to obtain routing information. This routing information contains the first state information of VRF1 of PE2, and the routing information containing the first state information of VRF1 of PE2 is sent to PE1.

[0056] S103. The multicast sender PE determines whether to establish a communication connection with the multicast receiver PE based on the routing information and the second state information.

[0057] Specifically, the multicast transmitter PE can determine whether to establish a communication connection with the multicast receiver PE based on the routing information containing the first state information of VRF1 monitored by the multicast receiver PE and the second state information of VRF1 monitored by the multicast transmitter PE.

[0058] The establishment of a communication connection can also refer to the establishment of a neighbor relationship. Specifically, the multicast sending PE determines whether to establish a neighbor relationship with the multicast receiving PE. If the multicast sending PE determines not to establish a neighbor relationship with the multicast receiving PE, the neighbor table containing the multicast receiving PE can be deleted from the multicast sending PE's records, effectively deleting the private network multicast neighbor from the multicast sending PE. If a neighbor relationship is established, the neighbor table with the multicast receiving PE in the multicast sending PE's records can be re-established, thus establishing a neighbor relationship with the multicast receiving PE. This neighbor table includes the multicast receiving PE's address, tunnel interface, and timer status. The tunnel interface refers to the tunnel interface between the multicast sending PE and the multicast receiving PE.

[0059] For example, when PE1 receives the routing information in S102 above, PE1 determines whether to establish a communication connection with PE2 based on the routing information containing the first state information of VRF1 of PE2 and the second state information of VRF1 monitored by PE1.

[0060] In this embodiment, by monitoring the status information of the virtual routing tables stored on each device at both the multicast receiver PE and the multicast sender PE, the multicast receiver PE encapsulates the monitored first status information through the border gateway protocol module to generate routing information and sends the routing information to the multicast sender PE. This allows the multicast sender PE to determine whether to establish a communication connection with the multicast receiver PE based on the received routing information and the status information of the virtual routing tables it monitors. This enables the multicast sender PE to directly delete its private network multicast neighbors when it malfunctions, effectively deleting the multicast receiver PE from the multicast sender PE's records. This achieves the effect of simultaneously deleting all connection interfaces in the multicast forwarding table, achieving the goal of batch and quickly cutting off multicast traffic, reducing redundant traffic forwarding in the backbone network, and avoiding the need in existing technologies where the multicast sender PE must delete each of its outgoing interfaces sequentially before multicast traffic can be cut off, thus reducing network bandwidth waste. Furthermore, by monitoring the status information of each virtual forwarding routing table on each device in real time, changes in the status of the virtual forwarding routing table can be quickly detected, improving the efficiency of fault handling.

[0061] Figure 3 A flowchart illustrating another edge device communication processing method provided in this application embodiment is shown below. Figure 3 As shown, the first state information of the virtual routing and forwarding table stored locally in real time by the multicast receiver PE as described above in S101 may include:

[0062] S201. The multicast receiver PE monitors in real time the status information of the connection interfaces on each network device connected to the multicast receiver PE in the virtual routing table.

[0063] Specifically, the multicast receiver PE can monitor in real time the status information of the connection interfaces on each network device connected to the multicast receiver PE in the virtual routing table stored by the multicast receiver PE. Each connection interface has PIM enabled, and the multicast receiver backbone device can monitor the status information of the PIM-enabled connection interface in real time.

[0064] Optionally, the multicast receiver PE can include multiple virtual routing tables, each with different connection interfaces. Different virtual routing tables can represent different data forwarding methods. For example, PE2 can include multiple different virtual routing tables such as VRF1, VRF2, and VRF3, and VRF1, VRF2, and VRF3 can have different data forwarding methods. For instance, VRF1 includes CE2 and CE3; VRF2 includes CE4; and VRF5 includes CE5, CE6, and CE7. Thus, the multicast receiver PE can monitor the status information of each connection interface in each VRF.

[0065] It is worth noting that the network devices and the number of multicast receivers included in the VRF listed in this embodiment are all exemplary, and this application embodiment does not limit them.

[0066] For example, such as Figure 1 As shown, the receiver network devices in VRF1 connected to PE2, namely the Customer Edge (CE), are CE2 and CE3. The connection interfaces between CE2 and PE2, as well as between CE3 and PE2, have enabled the PIM function. PE2 can monitor the status information of the connection interfaces between CE2 and CE3 in VRF1 in real time.

[0067] S202. Determine the first status information based on the status information of the connection interfaces on each network device of the multicast receiver PE.

[0068] Specifically, the multicast receiver (PE) can determine the first status information of each virtual routing forwarding table based on the status information of the connection interfaces on each network device. The status information of each connection interface can also include normal status or fault status, where normal status can be represented by 1, which can also indicate that the connection interface is up; fault status can be represented by 0, which can also indicate that the connection interface is down.

[0069] For example, such as Figure 1The first state information of VRF1 of PE2 shown can be determined together with the state information of the connection interface on CE2 and the connection interface on CE3 connected to PE2 obtained by real-time monitoring.

[0070] For example, the first state information of other VRFs stored in PE2 can be determined by the state information of all the connection interfaces contained in each VRF.

[0071] Optionally, S201-S202 above describes the process of determining the first state information of each virtual routing table of the multicast receiving PE. The process of determining the second state information of each virtual routing table of the multicast sending PE is similar to that of the multicast receiving PE. Referring to steps S201-S202, the second state information of the virtual routing table of the multicast sending PE can be obtained. For example, the attached... Figure 1 The second state information of VRF1 stored in PE1, such as Figure 1 As shown, the second state information of VRF1 of PE1 is determined by the state information of the connection interface on CE1 connected to PE1. For the attached Figure 1 The multicast source network device CE1 and the receiver network devices CE2 and CE3 are both devices in the VRF1 routing table.

[0072] Using the method of this embodiment, the first status information of each virtual routing table of the multicast receiver PE and the second status information of each virtual routing table of the multicast sender PE can be obtained respectively.

[0073] Optionally, determining the first status information based on the status information of the connection interfaces on each network device of the multicast receiver PE in S202 above may include:

[0074] Optionally, if the status information of the connection interface on all network devices connected to the multicast receiver PE is in a fault state, then the first status information is determined to be in a fault state; otherwise, the first status information is determined to be in a normal state.

[0075] For example, continue with the appendix Figure 1 Taking PE2 as an example, if the status of the connection interface on CE2 and the connection interface on CE3 are both 0, it means that the first status information of VRF1 on PE2 is 0; if the status of any one of the connection interfaces on CE2 and the connection interface on CE3 is 1 or both are 1, it means that the first status information of VRF1 on PE2 is 1.

[0076] For example, the status information VRF[1].PIM.status of the virtual routing forwarding table stored on PE2 is shown in Table 1 below:

[0077] VRF Interface Status 1 1 1 1 2 1

[0078] Table 1

[0079] Specifically, according to the above table, VRF[1].PIM.status={interface[1].status}||{interface[2].status}=1, where interface[1].status can be the status information of the connection interface on the CE2 device connected to PE2, and interface[2].status can be the status information of the connection interface on the CE3 device connected to PE2. Then, PE2 monitors that the PIM interface of VRF1 on its own end is normal, and notifies the BGP module of the result 1 of VRF[1].PIM.status.

[0080] Optionally, the determination of the second state information of each virtual routing table of the multicast sending PE is consistent with the method of the multicast receiving PE, and continues with the appendix. Figure 1 Taking PE1 as an example, if the state of the connection interface on CE1 is 1, then the second state information of VRF1 of PE1 is 1; if the state of the connection interface on CE1 is 0, then the second state information of VRF1 of PE1 is 0.

[0081] Optionally, in S102 above, the multicast receiver PE encapsulates the first state information through the border gateway protocol module to obtain routing information, and sends the routing information to the multicast sender PE, which may include:

[0082] Optionally, the border gateway protocol module encapsulates the first state information, the identifier of the multicast tunnel interface, and the routing identifier to obtain routing information. The source address of this routing information is the address of the multicast receiver (PE), and the destination address is the address of the multicast sender (PE).

[0083] The BGP module can encapsulate the first state information into a type of route. This type of route information, carried in the network layer reachability field of the BGP update message, is transmitted for automatic discovery of MVPN members within the domain. The attributes in this type of route can include: PMSI_TUNNEL_ATTRIBUTE (multicast tunnel information), MP_REACH_NLRI (routing information), and PIM.STATUS (local multicast interface status information). Specifically, the multicast tunnel interface identifier, route identifier, and first state information can be encapsulated in each attribute. The multicast tunnel interface identifier can be encapsulated in the PMSI_TUNNEL_ATTRIBUTE attribute, the route identifier in the MP_REACH_NLRI attribute, and the first state information value in the PIM.STATUS attribute. The following...

[0084] Table 2 shows the attributes included in one type of route as an example.

[0085] TYPE (update message) Path Attribute-PMSI_TUNNEL_ATTRIBUTE(Tunnel id:65536) Path Attribute-MP_REACH_NLRI(Router Distinguisher:20:1) Path Attribute-PIM.STATUS(flag: 1)

[0086] Table 2

[0087] In this BGP message, the source address is the IP address of PE2 that sent the first state information, for example, 2.2.2.2, and the destination address is the IP address of PE1, for example, 1.1.1.1. From Table 2, we can see that the identifier of this multicast tunnel interface is 65536, the route identifier is 20:1, and the flag value is 1, which is equivalent to the value of 1 in the first state information. This multicast tunnel interface refers to the multicast tunnel interface between PE2 and PE1.

[0088] Optionally, the BGP module can send the routing information to the multicast sender PE based on the source address and destination address.

[0089] In this embodiment, the first state information is encapsulated into a type of routing information by the BGP module and sent to the multicast sender PE. When all the connection interfaces in the virtual routing table of the multicast receiver PE fail, the BGP module can be immediately triggered to send a routing update message so that the multicast sender PE can synchronously receive the interface state information of the multicast receiver PE.

[0090] Figure 4 A flowchart illustrating another edge device communication processing method provided in this application embodiment is shown below. Figure 4 As shown, in S103 above, the multicast sending end PE determines whether to establish a communication connection with the multicast receiving end PE based on routing information and second state information, which may include:

[0091] S301, the multicast sending end PE parses the routing information to obtain the first state information, the routing identifier, and the identifier of the multicast tunnel interface.

[0092] S302. The multicast sending end PE matches the corresponding virtual routing forwarding table stored by the multicast sending end PE according to the routing identifier and obtains the second status information of the virtual routing forwarding table.

[0093] Specifically, the virtual routing table on the multicast sending PE can be matched according to the routing identifier. For example, the VRF1 on PE1 can be matched according to the routing identifier 20:1 in Table 2. At the same time, PE1 can also obtain the second status information of VRF1 of PE1 monitored by the local end. The corresponding tunnel interface 40960 can also be obtained through the identifier 65536 of the multicast tunnel interface in Table 2.

[0094] S303. The multicast transmitter PE determines whether to establish a communication connection with the multicast receiver PE based on the first status information and the second status information.

[0095] For example, PE1 can determine whether to establish a communication connection with PE2 by parsing the first status information of VRF1 on PE2 and the second status information of VRF1 on its own PE1.

[0096] Optionally, in S303 above, the multicast transmitter PE determines whether to establish a communication connection with the multicast receiver PE based on the first status information and the second status information, which may include:

[0097] Optionally, if the value in the first status information is a first preset value, the multicast sender PE determines whether the value in the second status information is consistent with the first preset value. If they are consistent, a communication connection is established between the multicast sender PE and the multicast receiver PE.

[0098] The first preset value can be used to indicate that the virtual routing table of the multicast receiver PE is in normal condition, for example, the value of VRF1 on PE2 is 1.

[0099] Optionally, the initial value of the VRF on each PE is 0. If the first state information in the routing information sent by the multicast sending PE is 1 for the first time, a neighbor relationship is established with the multicast receiving PE, and the neighbor state timeout timer is set to never time out. After the private network PIM neighbor is successfully established, the multicast traffic is forwarded normally. When the multicast receiving PE monitors that the state of its own VRF becomes 0.

[0100] For example, if PE1 receives a routing information sent by PE2 through the BGP module with a VRF1 value of 1, and finds the VRF1 value on its local PE1 through the routing identifier, and if the VRF1 value on PE1 is also 1, then a communication connection is established between PE1 and PE2, that is, a neighbor relationship is established with PE2, and the neighbor status timeout timer is set to never time out, as shown in Table 3 below.

[0101] Optionally, the multicast sending PE also stores a neighbor table for the multicast receiving PE. This neighbor table includes the address, tunnel interface, and timer status of the multicast receiving PE, as shown in Table 3 below:

[0102] Neighbor Address Interface Expires 2.2.2.2 Tunnel40960 Never

[0103] Table 3

[0104] Optionally, in S303 above, the multicast transmitter PE determines whether to establish a communication connection with the multicast receiver PE based on the first status information and the second status information, which may include:

[0105] Optionally, if the value in the first status information is a second preset value, the multicast sender PE disconnects the communication connection with the multicast receiver PE, wherein the second preset value is used to indicate that the virtual routing table of the multicast receiver PE is in a fault state.

[0106] Specifically, after the multicast sending PE and the multicast receiving PE establish a communication connection, multicast traffic is forwarded normally. When the multicast receiving PE detects that the value of its virtual routing table is 0, it notifies the BGP module to immediately send a routing information update message. The source address of this message is the address of the multicast receiving PE, the destination address is the address of the multicast sending PE, and it carries the first state information of 0. After receiving this message, the multicast sending PE sets the multicast neighbor timer of the tunnel interface under the corresponding virtual routing table in the multicast sending PE to 0, which means it deletes the multicast receiving PE from the multicast sending PE.

[0107] Optionally, when the multicast sender PE deletes the multicast receiver PE in the multicast sender PE, all outgoing interfaces in the virtual routing table on the multicast sender PE are also deleted. In addition, the multicast sender PE can also send a pruning message to the multicast source to delete the communication connection between the multicast sender PE and the multicast source.

[0108] Optionally, after the multicast sender PE and the multicast receiver PE are disconnected, when the multicast receiver PE monitors that its local virtual routing table has become 1, it notifies the BGP module to immediately send a route update message, carrying the first state information as 1. When the multicast sender PE receives the message and parses the first state information as 1, it re-establishes the private network multicast neighbor of the tunnel interface in the message, that is, re-establishes the communication connection with the multicast receiver PE, and at the same time sets the timer to never time out.

[0109] In this embodiment, when all the connection interfaces in the virtual routing table of the multicast receiver PE fail, the BGP module can be immediately triggered to send a routing update message, directly deleting the multicast receiver PE under the corresponding virtual routing table in the multicast sender PE. This achieves the effect of simultaneously deleting the multicast forwarding table output interface, thereby achieving the purpose of batch and quickly cutting off multicast traffic, thereby reducing the forwarding of redundant traffic in the backbone network and reducing the waste of network bandwidth.

[0110] Optionally, when the enabling function of the connection interface of each network device in the virtual routing table of the multicast receiver PE fails, the virtual routing table of the multicast receiver PE will also be in a fault state. In this case, the fault handling is the same as the fault handling method described above.

[0111] Figure 5A structural block diagram of an electronic device 400 provided in this application embodiment is shown below. Figure 5 As shown, the electronic device may include: a processor 401 and a memory 402.

[0112] Optionally, a bus 403 may also be included, wherein the memory 402 is used to store machine-readable instructions executable by the processor 401. When the electronic device 400 is running, the processor 401 and the memory 402 communicate via the bus 403. When the machine-readable instructions are executed by the processor 401, the method steps in the above method embodiments are performed.

[0113] This application also provides a computer-readable storage medium storing a computer program, which, when run by a processor, executes the method steps described in the above-described edge device communication processing method embodiments.

[0114] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and devices described above can be referred to the corresponding processes in the method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection can be through some communication interfaces; the indirect coupling or communication connection of devices or modules can be electrical, mechanical, or other forms.

[0115] Furthermore, the functional units in the various embodiments of this application 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. If the functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, 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: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, optical disks, and other media capable of storing program code.

[0116] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A method of edge device communication processing, the method comprising: The method comprises: The multicast receiving end PE monitors the first state information of the locally stored virtual route forwarding table in real time, the multicast sending end PE monitors the second state information of the locally stored virtual route forwarding table in real time, and the first state information and the second state information respectively comprise: a normal state or a fault state; The multicast receiving end PE encapsulates the first state information through a border gateway protocol (BGP) module to obtain route information, and sends the route information to the multicast sending end PE; The multicast sending end PE determines whether to establish a communication connection with the multicast receiving end PE according to the route information and the second state information; The multicast sending end PE analyzes the route information to obtain the first state information, route identification and identification of a multicast tunnel interface; The multicast sending end PE matches the corresponding virtual route forwarding table stored in the multicast sending end PE according to the route identification and obtains the second state information of the virtual route forwarding table; The multicast sending end PE determines whether to establish a communication connection with the multicast receiving end PE according to the first state information and the second state information; The multicast sending end PE determines whether to establish a communication connection with the multicast receiving end PE according to the first state information and the second state information, which comprises: If the value in the first state information is a first preset value, the multicast sending end PE judges whether the value in the second state information is consistent with the first preset value, if yes, the multicast sending end PE establishes a communication connection between the multicast sending end and the multicast receiving end PE; the first preset value is used to indicate that the state of the virtual route forwarding table of the multicast receiving end PE is normal; If the value in the first state information is a second preset value, the multicast sending end PE disconnects the communication connection with the multicast receiving end PE; the second preset value is used to indicate that the state of the virtual route forwarding table of the multicast receiving end PE is a fault state.

2. The edge device communication processing method of claim 1, wherein, The multicast receiving end PE monitors the first state information of the locally stored virtual route forwarding table in real time, which comprises: The multicast receiving end PE monitors the state information of the connection interface on each network device connected with the multicast receiving end itself in the virtual route forwarding table in real time; The multicast receiving end PE determines the first state information according to the state information of the connection interface on each network device connected with the multicast receiving end itself.

3. The edge device communication processing method according to claim 2, wherein The multicast receiving end PE determines the first state information according to the state information of the connection interface on each network device connected with the multicast receiving end itself, which comprises: If the state information of the connection interface on all network devices connected with the multicast receiving end itself is a fault state, it is determined that the first state information is a fault state, otherwise, it is determined that the first state information is a normal state.

4. The edge device communication processing method of claim 1, wherein, The multicast receiving end PE encapsulates the first state information through a border gateway protocol (BGP) module to obtain route information, and sends the route information to the multicast sending end PE, which comprises: The BGP module of the multicast receiving end PE encapsulates the first state information, the identification of the multicast tunnel interface and the route identification to obtain the route information, wherein a source address of the route information is an address of the multicast receiving end PE and a destination address of the route information is an address of the multicast sending end PE. The multicast receiving end PE sends the route information to the multicast sending end PE according to the source address and the destination address.

5. An edge device communication handling system, characterized by The application relates to a multicast network system, comprising a receiving end PE and a sending end PE, wherein: The receiving end PE is configured to perform the method steps of any one of claims 1-4, and the sending end PE is configured to perform the method steps of any one of claims 1-4.

6. An electronic device, comprising: The application relates to a receiving end PE and a sending end PE, wherein the receiving end PE comprises a memory and a processor, the memory stores a computer program executable by the processor, and the processor executes the computer program to implement the method steps of any one of claims 1-4; and the sending end PE comprises a memory and a processor, the memory stores a computer program executable by the processor, and the processor executes the computer program to implement the method steps of any one of claims 1-4.

7. A computer readable storage medium characterized in that, The computer readable storage medium stores a computer program, and the computer program is run by the processor to perform the method steps of any one of claims 1-4.

Images