CN117997561A

CN117997561A - Communication method and device

Info

Publication number: CN117997561A
Application number: CN202211354585.8A
Authority: CN
Inventors: 戴健; 朱彤
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2022-11-01
Filing date: 2022-11-01
Publication date: 2024-05-07
Also published as: WO2024093306A1

Abstract

The application provides a communication method and a communication device. The method comprises the following steps: the first communication device receives a first message from the second communication device through the leaf interface. In response to determining to forward the first message through the default MAC address entry, the first communication device forwarding the first message thereto; wherein the default MAC address entry includes a leaf identity and a MAC address of all 0. The application is used for realizing flow isolation.

Description

Communication method and device

Technical Field

The present application relates to the field of communications, and in particular, to a communication method and apparatus.

Background

At present, in large networks such as metropolitan area networks, the effects of improving the transmission safety of data, improving the transmission efficiency of the network and the like can be achieved by carrying out traffic isolation between devices without mutual access requirements.

Therefore, how to effectively and conveniently realize flow isolation is a problem which needs to be solved at present.

Disclosure of Invention

The application provides a communication method and a communication device, which are used for efficiently and conveniently realizing flow isolation.

In a first aspect, a communication method is provided, the method comprising: the first communication device receives a first message from the second communication device through the leaf interface. In response to determining to forward the first message via the default MAC address entry, the first communication device discards the message. Wherein the default MAC address entry includes a leaf identity and a MAC address of all 0.

In the above method, when the first communication device receives the first message through the leaf interface and determines that the first message needs to be forwarded through the default MAC address table entry including the leaf identifier, the first communication device discards the message. Wherein the default MAC address table entry is a MAC address table entry generated according to UMR. In this way, when the AC under the EVPN instance or BD of the network device (hereinafter referred to as third communication means) configuring the UMR function is the AC of the leaf attribute, unicast traffic isolation can be achieved by the above method. Specifically, on the one hand, if the message corresponds to the default MAC address table entry and the default MAC address table entry includes a leaf identifier corresponding to the leaf attribute in the E-tree, it is indicated that the message needs to be forwarded subsequently through the AC of the leaf attribute after being forwarded to the third communication device through the default MAC address table entry (because the AC under the EVPN instance or BD of the third communication device is the AC of the leaf attribute). As an example, the leaf identifier described above may be at least one bit for indicating a leaf attribute. Taking 1 bit as an example, a leaf identifier is represented when bit is 0 (i.e., indicates that the corresponding AC is a leaf attribute), and a root identifier is represented when bit is 1 (i.e., indicates that the corresponding AC is a root attribute). For another example, the leaf identifier may be a value or a string in the E-tree extended community attribute, or the like. In one specific implementation, the value or string is carried in a value field of the E-tree extension community attribute to indicate that the corresponding AC has a leaf attribute. On the other hand, the first communication device is a message received through the leaf interface, and then the two aspects can be combined to determine that the message is from the leaf interface and further needs to be forwarded through the AC of the leaf attribute, so that unicast traffic isolation is realized by discarding the message through the first communication device.

In addition, it will be appreciated that the above method referred to as "forwarding through default MAC address entries" may also be referred to as "forwarding through UMR". The default MAC address entry is a forwarding entry generated based on UMR. From the control plane perspective, the UMR is the control plane route, and when the UMR issues to the forwarding plane, the UMR corresponds to the default MAC address table entry. Thus, in the present application "forward over default MAC address table entry" is "forward over UMR". Because the above method is described from the forwarding plane angle, the expression "forward through default MAC address table entry" is used. The above-described understanding of the relationship between default MAC address entries and UMR is made in the present application unless otherwise specified.

In one implementation, the method further comprises: the first communication device receives a UMR from the third communication device, the UMR carrying leaf indication information indicating that the UMR has a leaf attribute. The first communication device generates a default MAC address table entry including the aforementioned leaf identifier based on the UMR.

In the above implementation manner, the manner in which the third communication device sends the UMR carrying the leaf indication information to the first communication device may enable the first communication device, after receiving the UMR, to establish a default MAC address table entry including the leaf identifier according to the UMR. In this way, when the EVPN instance of the third communication apparatus configured with the UMR function or the AC under BD is the AC of the leaf attribute, unicast traffic isolation can be achieved by the above method.

In one implementation, the UMR carries an E-tree extension community attribute, where the E-tree extension community attribute includes leaf indication information.

In the implementation manner, the leaf indication information is carried in the E-tree extension group attribute in the UMR, so that after the first communication device receives the UMR, the first communication device can determine that the correspondence between the UMR and the leaf attribute exists according to the E-tree extension group attribute in the UMR, and the first communication device establishes a default MAC address table item comprising the leaf identifier.

In one implementation, the leaf indication information is a leaf identifier.

In the implementation manner, the same content is uniformly used for the leaf identification in the default MAC address table entry and the leaf indication information in the UMR, so that the management of data is facilitated. For example, the first communication device, upon receiving the UMR, may copy the content of the leaf indication information of the UMR directly into the default MAC address entry as a leaf identification in the default MAC address entry. Thereby facilitating quick generation of default MAC address entries.

In one implementation, the first communication device is Sleaf equipment, the second communication device is UP equipment, and the third communication device is Aleaf equipment.

In the implementation manner, by applying the method provided by the application to the Spine-leaf network, the first communication device is taken as Sleaf equipment, the second communication device is taken as UP equipment, and the third communication device is taken as Aleaf equipment, so that unicast traffic isolation can be performed on Sleaf equipment under the condition that UMR function is configured on Aleaf equipment.

In one implementation, the UMR is an EVPN MAC route.

In one implementation, the method further comprises: the first communication device receives the second message through the leaf interface. The first communication device searches a matched MAC address table item according to the destination MAC address of the second message, wherein the MAC address table item comprises a root mark. The first communication device forwards the second message.

Through the implementation manner, when the first communication device receives the message through the leaf interface, if the address table item corresponding to the destination MAC address of the message is determined to comprise the root identifier, the message is continuously forwarded, so that the message which does not need to be subjected to unicast traffic isolation can be ensured to be forwarded smoothly.

In a second aspect, a communication method is provided, including: the first communication device receives a UMR from the second communication device, the UMR carrying a leaf indication information indicating that the UMR has a leaf attribute. The first communication device generates a default MAC address entry based on the UMR, the default MAC address entry including a leaf identity and a MAC address of all 0's.

In the above method, the second communication device sends the UMR carrying the leaf indication information to the first communication device, so that the first communication device can establish a default MAC address table entry including the leaf identifier according to the UMR after receiving the UMR. In this way, when the EVPN instance of the second communication device configured with the UMR function or the AC under the BD is the AC of the leaf attribute, unicast traffic isolation can be achieved by the above method. Specifically, after the first communication device receives the message through the leaf attribute, if the message corresponds to the default MAC address table entry (that is, includes the default MAC address table entry identified by the leaf), it is said that the message needs to be forwarded subsequently through the AC of the leaf attribute after being forwarded to the second communication device through the UMR, so that unicast traffic isolation can be achieved by discarding the message by the first communication device.

In one implementation, the UMR carries an E-tree extended community attribute. The E-tree extension community attribute comprises leaf indication information.

In one implementation, the leaf indication information is a leaf identifier.

In one implementation, the first communication device is Sleaf equipment and the second communication device is Aleaf equipment.

In the implementation manner, by applying the method provided by the application to the Spine-leaf network, the first communication device is taken as Sleaf equipment, and the third communication device is taken as Sleaf equipment, so that unicast traffic isolation can be performed on Sleaf equipment under the condition that UMR function is configured on Aleaf equipment.

In one implementation, the UMR is an EVPN MAC route.

In a third aspect, a communication method is provided, including: the second communication device generates UMR, and the UMR carries leaf indication information; the leaf indication information is used to indicate that the UMR has a leaf attribute. The second communication device transmits the UMR to the first communication device.

In the above method, the manner in which the second communication device sends the UMR carrying the leaf indication information to the first communication device may be adopted, so that after the first communication device receives the UMR, the first communication device may establish a default MAC address table entry including the leaf identifier according to the UMR. In this way, when the EVPN instance of the second communication device configured with the UMR function or the AC under the BD is the AC of the leaf attribute, unicast traffic isolation can be achieved by the above method. Specifically, after the first communication device receives the message through the leaf attribute, if the message corresponds to the default MAC address table entry (that is, includes the default MAC address table entry identified by the leaf), it is said that the message needs to be forwarded subsequently through the AC of the leaf attribute after being forwarded to the second communication device through the UMR (because the EVPN instance of the second communication device or the AC under the BD is the AC of the leaf attribute), so that unicast traffic isolation can be achieved by discarding the message by the first communication device.

In one implementation, the second communication device is Aleaf equipment and the first communication device is Sleaf equipment.

In the implementation manner, by applying the method provided by the application to the Spine-leaf network, the second communication device is taken as Aleaf equipment, and the first communication device is taken as Sleaf equipment, unicast traffic isolation can be performed on Sleaf equipment under the condition that UMR function is configured on Aleaf equipment.

In one implementation, the UMR is an EVPN MAC route.

In a fourth aspect, a communication method is provided, including: the second communication device receives a first message from the first communication device. In response to determining that the first outgoing interface in the first MAC address entry matching the destination medium access control MAC address of the first message is a leaf interface, and the second MAC address entry matching the source MAC address of the first message includes a leaf identification, the second communication device discards the first message.

In the above method, it is considered that when the UMR function is configured on the second communication device, since the MAC detailed route on the second communication device is not learned on the first communication device, unicast traffic isolation cannot be performed by the first communication device. That is, a message forwarded by the first communication device to the second communication device via the UMR may be a message that requires unicast traffic isolation (i.e., the message is from the AC of the leaf attribute and the message also requires subsequent forwarding via the AC of the leaf attribute). In this case, the method may be used to filter the received message by the second communication device, that is, when it is determined that the second MAC address table entry including the leaf identifier is included according to the source MAC address of the first message (i.e., it is indicated that the first message is from the leaf interface), and it is determined that the first message needs to be forwarded through the leaf interface of the second communication device (i.e., the message needs to be sent to the next hop device through the leaf interface on the second communication device), the second communication device discards the message, so as to achieve the effect of unicast traffic isolation.

In one implementation, the method further comprises: the second communication device receives the MAC route from the first communication device. The MAC route includes a source MAC address of the first message and leaf indication information indicating that the MAC route has a leaf attribute. The second communication device generates a second MAC address table entry including the leaf identity above according to the MAC route.

By the implementation manner, the MAC address table entry comprising the leaf identifier (in addition, the source MAC address of the first message can be included) can be generated at the second communication device, so that the second communication device can judge whether the message comes from the leaf interface on the first communication device according to the MAC address table entry after receiving the message. Therefore, when the message is determined to come from the leaf interface of the first communication device, and the message is determined to be forwarded through the leaf interface of the second communication device, the second communication device discards the message, so that the unicast traffic isolation effect can be achieved.

In one implementation, the leaf indication information is a leaf identifier.

In the implementation manner, the same content is uniformly used for the leaf identification in the default MAC address table entry and the leaf indication information in the UMR, so that the management of data is facilitated. For example, the second communication device may copy the content of the leaf indication information of the UMR directly into the default MAC address entry as the leaf identifier in the default MAC address entry after receiving the UMR. Thereby facilitating quick generation of default MAC address entries.

In one implementation, the method further comprises: and responding to the fact that the second output interface in the third MAC address table item matched with the destination MAC address of the second message is a leaf interface, and the fourth MAC address table item matched with the source MAC address of the second message comprises a root mark. The second communication device forwards the second message through the second output interface.

Through the implementation manner, when the second communication device determines that the message is to be forwarded through the leaf interface on the first communication device according to the destination MAC address of the second message, and determines that the message is from the root interface according to the source MAC address of the second message, the message is forwarded continuously, so that the message which does not need to be subjected to unicast traffic isolation can be forwarded smoothly.

In one implementation, the second communication apparatus is Aleaf devices, and the first communication apparatus Sleaf devices.

In the implementation manner, by applying the method provided by the application to the Spine-leaf network, the second communication device is taken as Aleaf equipment, and the first communication device is taken as Sleaf equipment, so that unicast traffic isolation can be performed on Aleaf equipment.

In a fifth aspect, a communication device is provided, applied to a first communication device, including: and the receiving unit is used for receiving the first message from the second communication device through the leaf interface. And a processing unit, configured to forward the first message by determining to use a default Media Access Control (MAC) address table entry, and discard the first message, where the default MAC address table entry includes a leaf identifier and a MAC address of all 0's.

In one implementation, the receiving unit is further configured to receive an unknown MAC route UMR from the third communications device, the UMR carrying a leaf indication information indicating that the UMR has a leaf attribute. And the processing unit is also used for generating a default MAC address table item according to the UMR.

In one implementation, UMR carries an Ethernet multicast E-tree extension community attribute; the E-tree extension community attribute includes leaf indication information.

In one implementation, the leaf indication information is a leaf identification.

In one implementation, the first communication device is Sleaf equipment and the third communication device is Aleaf equipment.

In one implementation, the receiving unit is further configured to receive a second packet through the leaf interface; the processing unit is further used for searching a matched MAC address table item according to the destination MAC address of the second message, and the MAC address table item comprises a root mark; and the processing unit is also used for forwarding the second message.

In a sixth aspect, a communication device is provided, applied to a first communication device, including: a receiving unit configured to receive an unknown medium access control route UMR from a second communication apparatus, the UMR carrying leaf indication information indicating that the UMR has a leaf attribute; and the processing unit is used for generating a default MAC address table item according to the UMR, wherein the default MAC address table item comprises a leaf identifier and the MAC address of all 0.

In a seventh aspect, a communication device is provided, applied to a first communication device, including: the processing unit is used for generating an unknown media access control route UMR, wherein leaf indication information is carried in the UMR, and the leaf indication information indicates that the UMR has a leaf attribute; and a transmitting unit configured to transmit the UMR to the second communication device.

In one implementation, the first communication apparatus is Aleaf devices and the second communication apparatus Sleaf devices.

An eighth aspect provides a communication device applied to a second communication device, including: a receiving unit, configured to receive a first packet from a first communication device; and the processing unit is used for responding to the fact that the first output interface in the first MAC address table item matched with the destination Media Access Control (MAC) address of the first message is a leaf interface, and the second MAC address table item matched with the source MAC address of the first message comprises a leaf identifier and discarding the first message.

In one implementation, the receiving unit is further configured to receive a MAC route from the first communication device; the MAC route comprises a source MAC address of the first message and leaf indication information, wherein the leaf indication information indicates that the MAC route has a leaf attribute; and the processing unit is also used for generating a second MAC address table item according to the MAC route.

In one implementation, the receiving unit is further configured to receive a second packet; the processing unit is further configured to respond to determining that the second outgoing interface in the third MAC address table entry matched with the destination MAC address of the second packet is a leaf interface, and forwarding the second packet through the second outgoing interface, where the fourth MAC address table entry matched with the source MAC address of the second packet includes a root identifier.

A ninth aspect provides a communications apparatus comprising a processor and a memory, the memory for storing computer instructions, the processor for invoking and executing the computer instructions from the memory to implement the method of any of the above first aspect or any of the implementation of the first aspect or any of the second aspect or any of the implementation of the third aspect or any of the implementation of the fourth aspect or any of the fourth aspect.

In a tenth aspect, a communication system is provided that includes a first communication device and a second communication device. Wherein the first communication device is configured to implement a method as described in the first aspect or any implementation manner of the second aspect or the second aspect, and the second communication device is configured to implement a method as described in the third aspect or any implementation manner of the third aspect.

An eleventh aspect provides a communication system comprising a first communication device and a second communication device, the first communication device or the second communication device being arranged to implement a method as in any of the fourth or fourth aspects above.

A twelfth aspect provides a computer readable storage medium having instructions stored therein which, when run on a processor, implement any of the above first aspect or the first aspect or any of the above second aspect or the second aspect or any of the above third aspect or any of the above fourth aspect.

A thirteenth aspect provides a computer program product comprising a computer program implementing the method of any of the above first aspect or any of the above second aspect or any of the above third aspect or any of the above fourth aspect when the computer program is run on a processor.

Drawings

Fig. 1 is a schematic structural diagram of a communication system according to an embodiment of the present application;

Fig. 2 is a schematic flow chart of a communication method according to an embodiment of the present application;

FIG. 3 is a schematic diagram of an E-tree extended community attribute according to an embodiment of the present application;

Fig. 4 is a second schematic structural diagram of a communication system according to an embodiment of the present application;

FIG. 5 is a second flow chart of a communication method according to the embodiment of the application;

FIG. 6 is a third flow chart of a communication method according to an embodiment of the present application;

FIG. 7 is a flow chart of a communication method according to an embodiment of the present application;

FIG. 8 is a fifth flow chart of a communication method according to an embodiment of the present application;

FIG. 9 is a flowchart illustrating a communication method according to an embodiment of the present application;

FIG. 10 is a flow chart of a communication method according to an embodiment of the present application;

fig. 11 is a schematic structural diagram of a communication device according to an embodiment of the present application;

Fig. 12 is a second schematic structural diagram of a communication device according to an embodiment of the present application;

fig. 13 is a third schematic structural diagram of a communication device according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be described below with reference to the accompanying drawings in the embodiments of the present application.

First, description is made of a related art related to an embodiment of the present application:

1. Unknown MAC routing (unknown MEDIA ACCESS control route, UMR), also known as "UMR routing", is a solution to replace MAC detail routing.

Typically, a specific MAC address is included in the MAC route, so as to be used for indicating the forwarding of the message with the MAC address as the destination address. This type of MAC routing, which includes specific MAC addresses, is called "MAC detail routing".

Unlike MAC-specific routing, UMR is used to indicate the choice made when there is no address entry matching the message to be forwarded.

For example, after the UMR function is configured on device a, device a sends the UMR to device B to cause device B to generate a default MAC address table entry from the UMR. And when the device B receives the message and the MAC address table entry does not have the table entry matched with the destination address of the message, forwarding the message to the device A according to the default MAC address table entry.

2. Ethernet multicast (E-Tree) is a point-to-multipoint service. In the E-Tree, access lines (ATTACHMENT CIRCUIT, AC) in the network can be classified into two types, leaf (leaf) attribute and root (root) attribute. The interfaces at two ends of the AC can be also understood as being divided into a leaf interface and a root interface, wherein the two ends of the AC with the leaf attribute are leaf interfaces, and the two ends of the AC with the root attribute are root interfaces.

The root interface can be communicated with the root interface or the leaf interface, but two leaf interfaces cannot be communicated with each other.

In this way, traffic isolation can be achieved in the network. For example, traffic isolation may be achieved between two devices without mutual access requirements by configuring the interfaces of the two devices as leaf interfaces.

3. IPv6 based segment routing (segment routing over IPv, SRv 6) is an SR technology based on the IPv6 forwarding plane. SRv6 combines the advantages of SR source routing and the features of simplicity and easy expansion of IPv6, and is increasingly applied to services of various border gateway protocols (border gateway protocol, BGP).

4. A Route Reflector (RR) is a route transfer technology. In the related art, on the one hand, border gateway protocol (border gateway protocol, BGP) routing is considered to be transmitting in a one-hop-only manner; on the other hand, in a real network, there are very many devices, and it is unlikely that an internal border gateway protocol (internal border gateway protocol, IBGP) connection is established between every two devices in the autonomous domain (autonomous system, AS), but the route needs to be transferred. To solve this problem, one router in one AS may be referred to AS RR, and the other routers AS clients (clients). An IBGP connection is established between the client and the RR. In this way, clients can send routing information to the RR, which reflects the routing information to other clients, without requiring BGP connections to be established between the clients.

5. An ethernet virtual private network (ethernet virtual private network, EVPN) is a two-layer network based VPN technology. Currently, EVPN is often used to transfer MAC routing information and IP routing information, and is used as a control layer of an overlay (overlay) network such as VXLAN, SRv6, and the like.

6. Virtual private local area network service (Virtual PRIVATE LAN SERVICE, VPLS) is a point-to-multipoint L2VPN service provided over a multiprotocol label switching (Multiprotocol Label Switching, MPLS) or IP backbone. The service provider provides VPLS services to a customer network by emulating a virtual switch on the backbone network for a customer network that connects a plurality of off-site sites.

The following describes an application scenario of the embodiment of the present application for facilitating understanding of the technical solution provided by the embodiment of the present application:

referring to fig. 1, a schematic diagram of a communication system 10 according to an embodiment of the present application is shown.

The user equipment 101 (e.g., an optical LINE TERMINAL, OLT), in fig. 1, an OLT1011 and an OLT 1012 are connected to a User Plane (UP) device 104 (in fig. 1, an UP device 1041, an UP device 1042, and an UP device 1043) through a bearer network. The UP device 104 is a device for performing authentication management on a user device and responsible for forwarding a user message. In addition, the UP device 104 is further connected to a Control Plane (CP) device 106, and the CP device 106 is configured to manage the active-standby role switching of the UP device and is responsible for management and control of the user device.

In a bearer network, a Leaf-Spine (Leaf-Spine) network structure is employed. As shown in fig. 1, the carrier network includes ridge-Spine devices 105, as well as Leaf devices. The Leaf devices may be divided into Aleaf devices 102 and Sleaf devices 103, among others.

The Aleaf device 102 may be connected to the user device 101, and is used to implement a function of an access side Provider Edge (PE) device. Sleaf device 103 may be connected to UP device 104 for implementing the functionality of a gateway-side (PE) device.

The Spine devices 1051 and 1052 may be used as RR roles for reflection routing.

In addition, in the communication system shown in fig. 1, a dual active (active-active) mode is adopted in the bearer network to ensure the normal operation of the network. As in fig. 1, aleaf devices 1021 and Aleaf device 1022 are dual-active devices, that is, aleaf device 1021 and Aleaf device 1022 provide access as one device to other devices in the network. In this way, when Aleaf device 1021 or Aleaf device 1022 fails, service can be continuously provided by the other device, and uninterrupted switching of services can be achieved. Similarly, the Spine device 1051 and Spine devices 1052, sleaf devices 1031 and Sleaf devices 1032 may be dual-living devices.

It should be noted that, unless otherwise specified, the technical solutions provided by the embodiments of the present application will be described by taking Aleaf equipment 1021, spine equipment 1051 and Sleaf equipment 1031 as main equipment. For the operation of the standby devices (e.g., aleaf device 1022, spine device 1052, and Sleaf device 1032), reference may be made to the description of the operation of Aleaf device 1021, spine device 1051, and Sleaf device 1031.

In addition, in the bearer network, EVPN VPLS traffic (EVPN VPLS over SRv) may be tunneled through SRv < 6 >. In communication system 10, user device 101 may be connected to Aleaf device 102 through a virtual local area network (virtual local area network, VLAN) or VLAN nest (802.1Q in 802.1Q,QinQ). Similarly, the UP device 104 may also be connected to Sleaf devices 103 through a VLAN or QinQ.

In the above-described communication system 10, on the one hand, E-Tree may be utilized to provide traffic isolation between devices that do not have inter-access requirements.

Take OLT 1011 and UP device 1041 for traffic isolation as examples: the AC between OLT 1011 and Aleaf device 1021 (i.e., link 1), and the AC between Sleaf device 1031 and UP device 1041 (i.e., link 5) may be configured as leaf attributes, i.e., interfaces on the devices to which the two ACs correspond are configured as leaf interfaces.

Further, aleaf device 1021, after learning MAC address 1 of OLT 1011 through link1, sends a MAC route (carrying MAC address 1 and a leaf identifier) to Sleaf device 1031, and Sleaf device 1031 generates a MAC address entry (including MAC address 1 and a leaf identifier). In addition, sleaf device 1031, after learning MAC address 2 of UP device 1041 via link5, sends a MAC route (carrying MAC address 2 and a leaf identifier) to Aleaf device 1021, and Aleaf device 1021 generates a MAC address table entry (including MAC address 2 and a leaf identifier).

Further, when the UP device 1041 transmits a unicast message to the OLT 1011: first, when Sleaf device 1031 receives the message through link5, sleaf device 1031 determines that the message is from the leaf interface, and Sleaf device 1031 determines a MAC address table entry corresponding to the leaf attribute according to the destination MAC address of the message (i.e., MAC address 1 of OLT 1011), that is, determines that the message is to be sent to the leaf interface. Furthermore, sleaf device 1031 discards the message, thereby isolating unicast traffic.

On the other hand, in the communication system 10 described above, since the number of users to which the Aleaf device 102 is connected may be very large, the MAC routes learned by the Aleaf device 102 may be large. When Aleaf device 102 advertises these MAC routes to Sleaf device 103 through an RR (i.e., spine device 105), sleaf device 103 needs to learn a large number of MAC routes because there may be many Aleaf devices to which Sleaf device 103 is connected. This results in an overload of Sleaf devices 103.

To reduce the load of Sleaf device 103, configuring UMR functions on Aleaf device 102 may be employed in the related art. Specifically, taking the example of configuring the UMR function on Aleaf devices 1021: after Aleaf device 1021 sends the UMR to Sleaf device 1031, sleaf device 1031 may generate a default MAC address table entry based on the UMR. Thereafter, when Sleaf device 1031 receives a message sent to OLT 1011 or OLT 1012, sleaf device 1031 may forward the message to Aleaf device 1021 according to the default MAC address table entry to complete forwarding of the message, even if there is no table entry in the MAC address table entry that matches the destination address of the message (i.e., the MAC address of OLT 1011 or OLT 1012).

However, it is contemplated that when this manner of configuring the UMR functionality on Aleaf device 102 is employed, since Aleaf device 102 only advertises UMR routes to Sleaf device 103, and does not advertise MAC detail routes carrying leaf attributes to Sleaf device 103. This results in Sleaf device 103 being unable to perform unicast traffic isolation. Still taking the link1 and link5 as the leaf attribute in fig. 1 as an example, when Sleaf device 1031 receives a message from link5 (the destination address of the message is MAC address 1), since there is no MAC address entry of MAC address 1 on Sleaf device 1031 (only the default MAC address entry corresponding to UMR forwarding), it cannot be perceived that the message will pass through the leaf interface in the subsequent forwarding process, and therefore the message will not be discarded, i.e., unicast traffic isolation cannot be performed.

In view of the above problems, embodiments of the present application provide a communication method capable of implementing unicast traffic isolation in a scenario where UMR is adopted. The following describes the method provided by the embodiment of the present application in two implementation manners:

In a first implementation, in the method, when a UMR function is configured on a device (for example, aleaf device 1021 in fig. 1) in a communication system, a UMR sent by the Aleaf device 1021 may carry leaf indication information, where the indication information indicates that the UMR has a leaf attribute, so that, after receiving the UMR, a receiving device (for example, sleaf device 1031 in fig. 1) may correspondingly generate a default MAC address table entry including a leaf identifier (where the leaf identifier may be understood as being used to indicate that the default MAC address table entry corresponds to the leaf attribute). Further, when Sleaf device 1031 receives a message over the leaf interface, if it is determined that the message corresponds to a default MAC address table entry including the leaf identifier, then Sleaf device 1031 discards the message. In this way, unicast traffic isolation may be implemented on Sleaf device 1031 for messages from the leaf interface on Sleaf device 1031 on the one hand, and for messages to be transmitted to the next hop device via the leaf interface on Aleaf device 1021 on the other hand.

In a second implementation, when the UMR function is configured on a device (such as Aleaf device 102 in fig. 1) in the communication system, in the case that the device 103 does not discard the packet that needs to be isolated by unicast traffic and forwards the packet to the device Aleaf by UMR forwarding, unicast traffic isolation is achieved by discarding the received packet that meets the requirement (the source MAC address of the packet corresponds to the leaf-identified MAC address table entry on the device Aleaf and the packet needs to be forwarded by the leaf interface on the device Aleaf device 102) on the device Sleaf.

The method provided by the embodiment of the application is described in detail below with reference to specific scenes.

In a first scenario, an EVPN instance or a Bridge Domain (BD) on a device configured with UMR functions is configured as an E-tree leaf Node, i.e., AC corresponding to the EVPN instance or BD on the device configured with UMR functions is configured as a leaf attribute. For example, link1 and link2 correspond to the same EVPN instance on Aleaf devices 1021, and configuring the EVPN instance as an E-tree leaf Node may be understood as specifically configuring both link1 and link2 as leaf attributes.

Specifically, in fig. 1, when the EVPN instances corresponding to link1 and link2 on the Aleaf device 1021 are configured as an E-tree leaf Node, and link5 (i.e., AC between the Sleaf device 1031 and the UP device 1041) is configured as a leaf attribute, the method provided by the embodiment of the present application is described in connection with the process that the UP device 1041 sends a message to the OLT 1011. As shown in fig. 2, the running process of the control flow in the method provided by the embodiment of the present application may include:

s201, aleaf device 1021 generates a UMR (hereinafter referred to as UMR-1 for ease of distinction).

The UMR-1 may be configured to instruct forwarding of the message to be forwarded to Aleaf devices 1021 when there is no MAC address entry matching the message to be forwarded.

Where UMR may be an EVPN route, as defined in RFC 7543. In one implementation, an EVPN MAC with a MAC address of all 0 may be routed as UMR.

The UMR-1 may be generated by the EVPN instance corresponding to link1 and link2 in Aleaf devices 1021.

In addition, the UMR-1 carries leaf indication information that may be used to indicate that the UMR-1 has a leaf attribute. Specifically, it can be understood that: the leaf identifier may be used to indicate that, after forwarding the message to Aleaf devices 1021 in the UMR manner, aleaf devices 1021 will forward the message over the leaf interface during subsequent forwarding.

In one implementation, the leaf indication information may be carried in an extended community attribute in UMR-1 in an embodiment of the present application.

Specifically, UMR-1 carries an E-tree extended community attribute. The E-tree extension community attribute includes leaf instruction information.

Fig. 3 is a schematic diagram of a message format of an E-tree extended community attribute carried by a UMR according to an embodiment of the present application. The device mainly comprises a leaf label (leaf label) field of 3 bytes and a tag (flags) field of 1 byte, and also comprises a reserved (reserved) field of 2 bytes, a type (type) field of 1 byte and a subtype (sub-type) field of 1 byte. The leaf label field carries the leaf indication information, and the equipment interface for identifying and sending the E-tree extension group attribute is a leaf interface. In addition, the leaf identifier may also be a value or a string carried in other fields in the E-tree extension group attribute, where the value or the string is carried in a value field of the E-tree extension group attribute, and is used to indicate that the corresponding AC (or a device interface corresponding to the AC) is a leaf attribute. In addition, the first 7 bits in the Flags field are all 0. And, if the E-TREE extended community attribute is to achieve isolation of broadcast, unknown unicast, multicast traffic (Broadcast Unknown-unicast Multicast, BUM) traffic between leaf interfaces, the last bit in the Flags field will be 0. If the E-TREE extended community attribute is to achieve isolation of known unicast traffic between leaf interfaces, the last bit in the Flags field will be 1. The device that receives the E-TREE extended community attribute achieves the isolation of known unicast traffic and BUM traffic between the leaf interfaces by identifying the last bit of the leaf indication information and the Flags field.

In addition, it is understood that the leaf indication information may also be carried in other fields in UMR-1 in embodiments of the present application. For example, the leaf indication information may be carried in UMR-1 in an extended community attribute other than the E-tree extended community attribute. The embodiment of the application is not limited.

In addition, it is understood that in the embodiment of the present application, the specific form of the leaf indication information carried by the UMR-1 may not be limited. For example, a bit (bit) is preset in the frame structure of the UMR-1, and when the bit is 0, the corresponding leaf attribute of the UMR-1 is indicated (the bit being 0 can be understood as the leaf indication information); when the bit is 1, it indicates that the UMR-1 does not correspond to the leaf attribute, or that the UMR-1 corresponds to the root attribute (the bit being 1 may be used as a root indication information, where the root indication information may be used to indicate that, after the message is forwarded to Aleaf devices 1021 in the UMR manner, aleaf devices 1021 do not necessarily forward the message through the leaf interface in a subsequent forwarding process).

For another example, a field may be included in the UMR-1 frame structure that indicates whether UMR-1 corresponds to a leaf attribute or a root attribute. The E-tree extension community attribute as described above may be used to indicate the corresponding leaf attribute or root attribute of UMR-1. Then, this field of the corresponding leaf attribute (e.g., the E-tree extended community attribute above) may be taken as the whole as leaf indication information.

S202, aleaf device 1021 sends UMR-1 to Sleaf device 1031.

For example, aleaf device 1021 may send UMR-1 to Sleaf device 1031 via Spine device 1051 as an RR.

S203, sleaf device 1031 generates a default MAC address table entry 1 from UMR-1.

The default MAC address table entry 1 may be used to indicate that, when there is no MAC address table entry matching the message to be forwarded, the message to be forwarded is forwarded to Aleaf devices 1021.

Wherein, the default MAC address table entry 1 includes a MAC address of all 0's, which is used to indicate that the table entry is the default MAC address table entry.

Additionally, the default MAC address table entry 1 also includes a leaf identifier. The leaf identifier may be used to indicate that when forwarding a message according to default MAC address entry 1, the message needs to be forwarded over the leaf interface during subsequent forwarding.

In addition, it should be noted that "the default MAC address table entry 1 includes a leaf identifier" in the embodiment of the present application may be understood as an implementation manner that the default MAC address table entry 1 corresponds to the leaf attribute. Thus, when forwarding the message according to the default MAC address table entry 1, it may be determined that the message needs to be forwarded through the leaf interface in the subsequent forwarding process. The leaf identifier is carried in the default MAC address table 1, which is only one specific expression form of the default MAC address table 1 corresponding to the leaf attribute, and the leaf identifier may not be carried in the default MAC address table in the actual application process, but only if the leaf attribute can be determined according to the default MAC address table.

In addition, it is understood that in embodiments of the present application, the specific form of the leaf identifier included in default MAC address table entry 1 may not be limiting. For example, a bit is preset in the default MAC address table entry 1, and the bit represents the leaf identifier when it is 0; when this bit is 1, the root flag is indicated. For another example, a field may be included in default MAC address entry 1 to indicate whether default MAC address entry 1 corresponds to a leaf attribute or a root attribute. Then the entirety of this field for the corresponding leaf attribute may be identified as leaf.

In addition, it will be appreciated that the leaf indication information carried in UMR-1 (i.e., the UMR sent by Aleaf device 1021 to Sleaf device 1031) and the leaf identification carried in default MAC address entry 1 (i.e., the default MAC address entry generated by Sleaf device 1031) in the above-described procedure functions similarly.

Therefore, in one implementation, the leaf indication information carried in the UMR-1 is a leaf identifier carried in the default MAC address table entry 1.

For example, when Sleaf device 1031 generates default MAC address entry 1, the leaf indication information in UMR-1 may be directly copied into default MAC address entry 1 as a leaf identification in default MAC address entry 1. For example, if one bit with 0in UMR-1 is used as the leaf indication information, then "0" may be copied to one bit preset in the default MAC address table entry 1 as the leaf flag.

In another implementation, the leaf identification in default MAC address table entry 1 and the leaf indication information in UMR-1 may take different forms. For example, in UMR-1, the E-tree extended community attribute is used as the leaf indication information, and a bit with a preset value of 0 is used as the leaf identifier in the default MAC address table entry 1 (it may be understood that Sleaf device 1031, after determining that the leaf indication information is carried in UMR-1 by reading the E-tree extended community attribute in UMR-1, correspondingly generates the default MAC address table entry 1 and sets the preset bit in the default MAC address table entry 1 to "0" to indicate the leaf identifier).

That is, in the actual application process, the specific forms of the leaf identifier in the default MAC address table entry 1 and the leaf indication information in the UMR-1 may be the same or different, which may not limit the embodiment of the present application.

In addition, during the running process of the control flow, a procedure in which Aleaf device 1021 learns the MAC address of the OLT, sleaf device 1031 learns the MAC address of each UP device, and Sleaf device 1031 sends a MAC route (in which the MAC address of each UP device is carried) to Aleaf device 1021 may also be included. For the process that Aleaf device 1021 learns the MAC address of the OLT, sleaf device 1031 learns the MAC address of each UP device, and Sleaf device 1031 sends the MAC route to Aleaf device 1021, reference may be made to the description of the related art, and details are omitted in the embodiments of the present application.

Next, the operation of the data stream in which the UP device 1041 transmits a message to the OLT 1011 will be described in connection with the operation of the control stream shown in fig. 2. As shown in fig. 2, the method further includes:

s204, sleaf device 1031 receives a message a from UP device 1041 via the interface (i.e., leaf interface) corresponding to link5 (i.e., AC of leaf attribute).

Illustratively, after the OLT 1011 accesses the network, the OLT 1011 will send a broadcast message to the network, which is used to send authentication information of the OLT 1011 to each UP device. Aleaf device 1021 forwards the broadcast message to Sleaf device 1031 upon receipt of the broadcast message, and Sleaf device 1031 forwards the broadcast message to each UP device upon receipt of the broadcast message. Each UP device, after receiving the broadcast message, sends a feedback message to OLT 1011 for establishing a connection between OLT 1011 and the UP device, so as to perform device authentication on OLT 1011 later. It is contemplated that only one UP device is required to establish a connection with OLT 1011 during the authentication of OLT 1011. Accordingly, it may be avoided that OLT 1011 and all UP devices establish a connection by way of traffic isolation between OLT 1011 and a portion of the UP devices.

Specifically, in the embodiment of the present application, the UP device 1041 may be understood as an UP device that needs to be traffic isolated from the OLT 1011. Message a may be understood as a feedback message sent by the UP device 1041 after receiving the broadcast message sent by the OLT 1011. The method further comprises the steps of:

s205, in response to determining to forward the first message via default MAC address entry 1, sleaf device 1031 discards the first message.

Wherein, as described above, the default MAC address entry 1 includes the leaf identity and the MAC address of all 0 s.

Specifically, after receiving the message a, the Sleaf device 1031 may search the MAC address table entry according to the destination MAC address (i.e., MAC address 1) of the message a, and then hit the default MAC address table entry 1 including the leaf identifier. That is, on the one hand, it is determined that the packet a hits in the default MAC address table entry 1 including the leaf identifier, and on the other hand, sleaf device 1031 is also capable of determining that the packet a is received through the leaf interface, and further, sleaf device 1031 discards the packet a according to the rule of the E-tree, thereby implementing unicast traffic isolation.

In one implementation, in an embodiment of the present application, when Sleaf device 1031 receives a message (called a message b) that needs to be forwarded to an AC with another root attribute through a leaf interface, then Sleaf device 1031 forwards the message b (i.e., does not discard the message b).

Illustratively, as shown in fig. 4, the user equipment 101 further includes a OLT 1013, where the OLT 1013 is connected Aleaf to the device 1021 through link11, and where the OLT 1013 is further connected Aleaf to the device 1022 through link 12. The link11 and the link12 do not belong to the EVPN corresponding to the link1-link4, and the link11 and the link12 are root attributes. When Sleaf device 1031 receives a message b over the leaf interface (e.g., over the interface corresponding to link 5) that needs to be forwarded to OLT 1013, as shown in fig. 5, the method may further include:

s206, sleaf device 1031 receives message b from UP device 1041 via the leaf interface.

The destination MAC address of this message b is the MAC address of OLT 1013 (i.e. MAC address 2 in fig. 4).

S207, sleaf device 1031 searches for a matching MAC address table according to the destination MAC address of the message b, and if the MAC address table includes a root identifier, sleaf device 1031 forwards the message b.

Specifically, after OLT 1013 accesses the network, aleaf device 1021 can learn the MAC address of OLT 1013 and send a MAC route (carrying MAC address 2 and root indication information) to Sleaf device 1031. Sleaf device 1031 generates a MAC address table (including MAC address 2 and root identifier) according to the MAC route, where the MAC address table may be used to indicate that the destination address is forwarding of MAC address 2, and the root identifier in the MAC address table is used to indicate that unicast traffic isolation is not required for the packet. Further, sleaf device 1031, after receiving the packet b, may forward the packet b to Aleaf device 1021 according to the MAC address table entry.

After that, when Sleaf device 1031 forwards the message b to Aleaf device 1021, aleaf device 1021 can forward the message to OLT 1013 according to the destination MAC address of the message b, thereby completing the forwarding of the message b.

In the above implementation manner, when the Sleaf device 1031 receives a message through the leaf interface, if it is determined that the MAC address table entry corresponding to the destination MAC address of the message includes the root identifier, the message is forwarded continuously, so that it can be ensured that the message that does not need to be isolated by unicast traffic can be forwarded smoothly.

The foregoing fig. 2-5 are mainly described in terms of Aleaf device 1021 sending a UMR-1 carrying a leaf indication to Sleaf device 1031, thereby establishing a default MAC address table entry 1 including a leaf identifier in Sleaf device 1031, and further describing, when Sleaf device 1031 receives a message a via a leaf interface, an implementation (i.e., the first implementation above) of discarding the message a after determining that it is necessary to forward the message a via the default MAC address table entry 1 (including the leaf identifier).

In the following, taking an example that the EVPN instances corresponding to link1 and link2 on the Aleaf device 1021 in fig. 1 are configured as an E-tree leaf Node, and the link5 (i.e., AC between the Sleaf device 1031 and the UP device 1041) is configured as a leaf attribute as an example, the second implementation manner (i.e., the Sleaf device 103 does not discard the packet that needs to be isolated by unicast traffic, and the unicast traffic isolation is implemented by discarding the received packet that meets the requirement on the Aleaf device 102). As shown in fig. 6, the operation of the control flow may include:

S301, aleaf device 1021 generates a UMR (hereinafter referred to as UMR-2).

Similar to UMR-1 in S201, this UMR-2 may be used to indicate that the message to be forwarded is forwarded to Aleaf devices 1021 when there is no MAC address entry matching the message to be forwarded. In addition, UMR-2 may be an EVPN MAC route with MAC addresses of all 0 generated by the instance of EVPN corresponding to link1 and link2 in Aleaf devices 1021.

Unlike S201, there is no leaf indication information carried in UMR-2 of S301.

S302, aleaf device 1021 sends UMR-2 to Sleaf device 1031.

For example, aleaf device 1021 may send UMR-2 to Sleaf device 1031 via Spine device 1051 as an RR.

S303, sleaf device 1031 generates a default MAC address table entry 2 from UMR-2.

Wherein, similar to the default MAC address entry 1 in S203, the default MAC address entry 2 may be used to indicate that when there is no MAC address entry matching the message to be forwarded, the message to be forwarded is forwarded to Aleaf devices 1021.

Unlike S203, default MAC address entry 2 does not include a leaf identifier, in other words default MAC address entry 2 may include a root identifier. In this way, sleaf device 1031 can only determine whether the message needs to be UMR forwarded using default MAC address table entry 2, and cannot determine whether to discard the message that needs to be UMR forwarded (i.e., perform unicast traffic isolation) using default MAC address table entry 2.

S304, sleaf device 1031 learns MAC address 2 (i.e., the MAC address of UP device 1041) via link5 (i.e., AC of the leaf attribute).

S305, sleaf device 1031 sends the MAC route to Aleaf device 1021.

The MAC route carries MAC address 2 and leaf indication information.

Specifically, after learning the MAC address 2, the Sleaf device 1031 may send the MAC address 2 to other devices in the network (such as Aleaf device 1021) by publishing a MAC route, where the MAC route may carry a leaf indication message to perform traffic isolation of the E-tree.

S306, aleaf the device 1021 generates a MAC address table entry a according to the MAC route.

The MAC address table entry includes a MAC address 2 and a leaf identifier. In other words, the MAC address table entry may be used to indicate that the message with the source MAC address of MAC address 2 is from the AC of the leaf attribute.

In addition, during the running of the control flow, it may also include Aleaf devices 1021 learning the MAC address of the OLT (e.g., aleaf devices 1021 learning the MAC address 1 of OLT 1011 in fig. 6), generating a MAC address table entry b indicating that the message is to be forwarded through link1 (i.e., leaf interface), aleaf devices 1021 learning the MAC address 3 of OLT 1013, generating a MAC address table entry c indicating that the message is to be forwarded through link1 (i.e., leaf interface), sleaf devices 1031 learning the MAC addresses of other UP devices (e.g., UP devices 1042, UP devices 1043, etc.), and Sleaf devices 1031 sending MAC routes (where the MAC addresses of the respective UP devices are carried, e.g., sleaf devices 1031 sending the MAC route carrying the MAC address 4 of UP device 1043 to Aleaf devices 1021, assuming that the MAC route carries the root indication information, additionally Aleaf devices 1021 generating a MAC address table entry d) carrying the root identification, etc. For the process that Aleaf device 1021 learns the MAC address of the OLT, sleaf device 1031 learns the MAC addresses of other UP devices, and Sleaf device 1031 sends the MAC route carrying the MAC address of other UP devices to Aleaf device 1021, reference may be made to the description of the related art, and details are omitted in the embodiments of the present application.

Next, a description will be given of a procedure of transmitting the message c having the destination address of MAC address 1 (i.e., the MAC address of OLT 1011) by UP device 1041 in connection with the operation procedure of the control flow shown in fig. 4. As shown in fig. 4, the method includes:

s307, sleaf device 1031 receives message c from UP device 1041 via the leaf interface.

For example, sleaf device 1031 may receive message c from UP device 1041 via the link5 interface (i.e., the leaf interface).

Similar to the description in S204, the UP device 1041 may be understood as an UP device that needs to be traffic isolated from the OLT 1011, and the message c may be understood as a feedback message sent after the UP device 1041 receives a broadcast message sent by the OLT 1011.

S308, sleaf device 1031 forwards message c to Aleaf device 1021 via default MAC address table entry 2.

Specifically, sleaf device 1031, after receiving the packet c, may search the MAC address table according to the destination address (i.e., MAC address 1) of the packet c, and then hit the default MAC address table 2. Unlike S205 above, since default MAC address entry 2 has no leaf id, sleaf device 1031 cannot determine whether to discard (i.e., unicast traffic quarantine) packet c using default MAC address entry 2. Then Sleaf device 1031 forwards the message c to Aleaf device 1021 via UMR.

S309, in response to determining that the first outgoing interface in the MAC address table entry b that matches the destination MAC address of the message c is a leaf interface, and that the MAC address table entry a that matches the source MAC address of the message c includes a leaf identifier, aleaf the device 1021 discards the message c.

Specifically, after receiving the message c, the Aleaf device 1021 may determine that the source MAC address (i.e. MAC address 2) of the message c corresponds to the leaf attribute according to the MAC address table entry a (including the MAC address 2 and the leaf identifier) generated in S306; on the other hand, the MAC address table entry b (indicating that the message is to be forwarded through the leaf interface) may be determined according to the destination address (i.e., MAC address 1) of the message c, so that the message c is discarded according to the rule of the E-tree, thereby implementing unicast traffic isolation.

In one implementation, when Aleaf device 1021 receives a message d with a source MAC address of MAC address 4 (MAC address 4UP device 1043) and a destination MAC address of MAC address 3 (i.e., the MAC address of OLT 1013), the method further includes:

S310, responding to the fact that an outgoing interface (namely an interface corresponding to link 11) in a MAC address table item c matched with a destination MAC address of the message d is a leaf interface, and if the MAC address table item d matched with a source MAC address of the message d comprises a root mark, aleaf equipment 1021 forwards the message d.

Specifically, the Aleaf device 1021 determines the MAC address table entry b (indicating that the message is forwarded through the leaf interface (i.e. the link1 interface)) according to the destination address (i.e. the MAC address 1) of the message d, and the Aleaf device 1021 determines the MAC address table entry c including the root identifier according to the source MAC address of the message d, so that the Aleaf device 1021 continues forwarding the message d according to the rule of the E-tree, thereby ensuring that the message that does not need to be isolated in unicast traffic can be forwarded smoothly.

In the second scenario, in the same EVPN instance or AC corresponding to BD on the device configured with the UMR function, the AC includes both the AC of the leaf attribute and the AC of the root attribute. Then, in this case, the EVPN instance or BD cannot be configured as the E-tree leaf Node.

For example, in fig. 1, link1 and link2 correspond to the same EVPN instance on Aleaf devices 1021, where link1 is a leaf attribute and link2 is a root attribute, where the EVPN instance or BD on Aleaf devices 1021 cannot be configured as an E-tree leaf Node.

Thus, on the one hand, in the second scenario, unicast traffic isolation cannot be achieved by the implementation shown in fig. 2 above (i.e., by Aleaf device 1021 sending a UMR carrying a leaf attribute identifier to Sleaf device 1031, sleaf device 1031 generating a default MAC address table entry for the corresponding leaf attribute, and discarding the packet according to the default MAC address table entry).

On the other hand, in the second scenario, unicast traffic isolation may be achieved through the implementation shown in fig. 3 above. For example, when link1 is the leaf attribute, link2 is the root attribute, and link5 is the leaf attribute in fig. 1, the procedure of transmitting the message by the UP device 1041 to the OLT 1011 may refer to the contents of S301 to S309, which are not described herein.

The method provided by the embodiment of the application is described below from the perspective of a single network device with reference to the accompanying drawings.

Specifically, as shown in fig. 7, the method includes:

S401, the first communication device receives a first message from the second communication device through a leaf interface.

The first communication device may specifically be the Sleaf device 1031 in fig. 2, the second communication device may be the UP device 1041 in fig. 2, and the message received by the first communication device may be the message a in fig. 2.

Specifically, S401 may be specifically implemented by the content of S204 described above.

S402, in response to determining that the first message is forwarded through the default MAC address table entry, the first communication device discards the first message.

Wherein the default MAC address entry includes a leaf identity and a MAC address of all 0. Specifically, the default MAC address entry may be default MAC address entry 1 in fig. 2.

Specifically, S402 may be specifically implemented by the content of S205 described above.

In one implementation, the method further comprises:

S403, the first communication device receives the UMR from the third communication device. Wherein the UMR carries leaf indication information.

The third communication device may be Aleaf equipment 1021 in fig. 2. The UMR received by the first communication device may be UMR-1 in fig. 2.

In one possible design, the UMR may be an EVPN MAC route. For example, UMR may be an EVPN MAC route with a destination MAC address of all 0.

In one possible design, the UMR received by the first communication device carries an E-tree extended community attribute. The E-tree extension community attribute comprises leaf indication information.

Specifically, S403 may be specifically implemented by the content of S202 described above.

S404, the first communication device generates a default MAC address table item comprising a leaf identifier according to the UMR.

Specifically, S404 may be specifically implemented by the content of S203 described above.

In one implementation, the method further comprises:

S405, the first communication device receives a second message;

S406, the first communication device searches the matched MAC address table according to the destination MAC address of the second message, and the first communication device forwards the second message after the MAC address table comprises the root mark.

Specifically, the content of S406 may be implemented by the content of S207 described above.

The implementation of the method described in fig. 7 is described below in terms of control flow in fig. 8 and 9, respectively. Specifically, as shown in fig. 8, the method includes:

s501, the first communication device receives the UMR from the second communication device. The UMR includes leaf indication information.

The first communication device may be Sleaf of fig. 2 and the second communication device may be Aleaf of fig. 2. The UMR received by the first communication device may be UMR-1 in fig. 2.

Specifically, S501 may be specifically implemented by the content of S202 described above.

S502, the first communication device generates a default MAC address table item comprising a leaf identifier according to UMR.

Specifically, S502 may be specifically implemented by the content of S203 described above.

As shown in fig. 9, the method provided by the embodiment of the application includes:

s601, the first communication apparatus generates a UMR. The UMR carries leaf indication information.

Wherein the leaf indication information is used to indicate that the UMR has a leaf attribute. That is, the UMR described above may be used to indicate that a default MAC address table entry is generated that includes a leaf identification.

The first communication device may specifically be Aleaf equipment 1021 in fig. 2. The UMR generated by the first communication device may specifically be UMR-1 in fig. 2.

Specifically, S601 may be specifically implemented by the content of S201 described above.

S602, the first communication device transmits the UMR to the second communication device.

The second communication device may specifically be Sleaf equipment 1031 in fig. 2.

In one implementation, the UMR may be an EVPN MAC route. For example, UMR may be an EVPN MAC route with a destination MAC address of all 0.

In one implementation, the UMR carries an E-tree extended community attribute. The E-tree extension community attribute includes leaf instruction information.

Specifically, S602 may be specifically implemented by the content of S202 described above.

In addition, as shown in fig. 10, the method provided by the embodiment of the present application may further include:

S701, the second communication device receives a first message from the first communication device.

The first message may be a message forwarded by the first communication device to the second communication device through the default MAC address table entry.

The second communication device may be Aleaf equipment 1021 in fig. 6, and the first communication device may be Sleaf equipment 1031 in fig. 6. The message received by the second communication device may be the message c in fig. 6.

Specifically, S701 may be implemented by the content of S308 described above.

S702, responding to the fact that a first output interface in a first MAC address table item matched with a destination MAC address of a first message is a leaf interface, and a second MAC address table item matched with a source MAC address of the first message comprises a leaf identifier, and discarding the message by the second communication device.

Specifically, S702 may be implemented by the content of S309 described above.

In one implementation, the method further comprises:

s703, the second communication device receives the MAC route from the first communication device.

The MAC route comprises a source MAC address of the first message and leaf indication information. The leaf indication information indicates that the MAC route has a leaf attribute.

Specifically, S703 may be implemented by the content of S305 described above.

S704, the second communication device generates an MAC address table item according to the MAC route.

The MAC address table entry comprises a leaf identifier and a source MAC address of the first message. Specifically, the MAC address table entry is configured to indicate a correspondence between the first MAC address and the leaf attribute.

Specifically, S704 may be implemented by the content of S306 described above.

In one implementation, the method further comprises:

S705, the second communication device receives the second message.

S706, responding to the fact that the second output interface in the third MAC address table item matched with the destination MAC address of the second message is a leaf interface, and the fourth MAC address table item matched with the source MAC address of the second message comprises a root mark, and the second communication device forwards the second message.

Specifically, S705 may be implemented by the content of S310 described above.

Based on the above method embodiments, the following describes the device provided in the embodiments of the present application. Fig. 9 is a schematic structural diagram of a communication device according to an embodiment of the present application. In particular, the communication device 80 may be used to implement the functionality of the Aleaf apparatus 1021 in fig. 2, 5 or 6, or the communication device 80 may be used to implement the functionality of the Sleaf apparatus 1031 in fig. 2, 5 or 6, or the communication device 80 may be used to implement the functionality of the first communication device in fig. 7 or 8, or the communication device 80 may be used to implement the functionality of the second communication device in fig. 9 or 10.

Referring to fig. 11, the communication apparatus 80 includes one or more of a receiving unit 801, a processing unit 802, and a transmitting unit 803. These units may perform the respective functions of the devices in the method examples described above.

In one implementation, the communication device 80 may implement the functionality of the first communication device of fig. 7.

Specifically, the receiving unit 801 is configured to receive, via the leaf interface, a first message from the second communication device.

The processing unit 802 is configured to discard the first packet in response to determining to forward the first packet via the default medium access control MAC address entry.

Wherein the default MAC address entry includes a leaf identity and a MAC address of all 0.

Optionally, the receiving unit 801 is further configured to receive an unknown MAC route UMR from the third communication device, where the UMR carries leaf indication information, and the leaf indication information indicates that the UMR has a leaf attribute.

The processing unit 802 is further configured to generate a default MAC address table entry according to the UMR.

Optionally, the UMR carries an Ethernet multicast E-tree extension community attribute. The E-tree extension community attribute includes leaf indication information.

Optionally, the leaf indication information is a leaf identification.

Optionally, the first communication device is Sleaf equipment, and the third communication device is Aleaf equipment.

Optionally, the receiving unit 801 is further configured to receive the second packet through a leaf interface.

The processing unit 802 is further configured to search for a matching MAC address table according to the destination MAC address of the second packet, where the MAC address table includes a root identifier.

The processing unit 802 is further configured to forward the second message.

In another implementation, the communication device 80 may implement the functionality of the first communication device of fig. 8.

Specifically, the receiving unit 801 is configured to receive an unknown medium access control route UMR from the second communication device, where the UMR carries leaf indication information, and the leaf indication information indicates that the UMR has a leaf attribute.

A processing unit 802, configured to generate a default MAC address table entry according to the UMR, where the default MAC address table entry includes a leaf identifier and a MAC address of all 0.

Optionally, the leaf indication information is a leaf identification.

Optionally, the first communication device is Sleaf equipment, and the second communication device is Aleaf equipment.

In another implementation, the communication device 80 may implement the functionality of the second communication device of fig. 9.

Specifically, the processing unit 802 is configured to generate an unknown medium access control route UMR, where the UMR carries leaf indication information, where the leaf indication information indicates that the UMR has a leaf attribute.

A transmitting unit 803 for transmitting the UMR to the first communication device.

Optionally, the UMR carries an Ethernet multicast E-tree extension group attribute; the E-tree extension community attribute includes leaf indication information.

Optionally, the second communication device is Aleaf equipment, and the first communication device Sleaf equipment.

In another implementation, the communication device 80 may implement the functionality of the second communication device of fig. 10.

Specifically, the receiving unit 801 is configured to receive a first packet from a first communication device.

The processing unit 802 is configured to discard the first message in response to determining, according to the destination MAC address of the first message, a first MAC address table entry indicating forwarding of the message over the leaf interface, and determining, according to the source MAC address of the first message, a second MAC address table entry including a leaf identifier.

Optionally, the receiving unit 801 is further configured to receive a MAC route from the first communication device; the MAC route includes the source MAC address of the message and leaf indication information.

The processing unit 802 is further configured to generate a second MAC address table entry according to the MAC route.

Optionally, the leaf indication information is a leaf identification.

Optionally, the receiving unit 801 is further configured to receive a second packet;

The processing unit 802 is further configured to determine, according to a destination MAC address of the second packet, a first MAC address table entry indicating forwarding of the packet through the leaf interface, and determine, according to a source MAC address of the second packet, a third MAC address table entry including a root identifier;

The processing unit 802 is further configured to forward the second message.

Fig. 12 is a schematic diagram of another possible configuration of the communication device involved in the above-described method embodiment. In particular, the communication device 90 may be used to implement the functionality of the Aleaf apparatus 1021 in fig. 2, 5, or 6, or the communication device 90 may be used to implement the functionality of the Sleaf apparatus 1031 in fig. 2, 5, or 6, or the communication device 90 may be used to implement the functionality of the first communication device in fig. 7 or 8, or the communication device 90 may be used to implement the functionality of the second communication device in fig. 9 or 10.

Referring to fig. 10, the communication device 90 includes: all or part of the hardware in the processor 901, communication interface 902, and memory 903. Where the number of processors 901 in the communication device 90 may be one or more, one processor is illustrated in fig. 10. In an embodiment of the application, processor 901, communication interface 902, and memory 903 may be connected by a bus system or other means, with the connection being shown in FIG. 10 as being through bus system 904.

The processor 901 may be a central processor (central processor unit, CPU), a network processor (network processor, NP), or a combination of CPU and NP. Processor 901 may also include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (programmable logic device, PLD), or a combination thereof. The PLD may be a complex programmable logic device (complex programmable logic device, CPLD), a field-programmable gate array (FPGA) GATE ARRAY, generic array logic (GENERIC ARRAY logic, GAL), or any combination thereof.

The communication interface 902 is used for receiving and transmitting data, and in particular, the communication interface 902 may include a receiving interface and a transmitting interface. Wherein the receiving interface may be used for receiving data and the transmitting interface may be used for transmitting data. The number of communication interfaces 902 may be one or more.

The memory 903 may include volatile memory (RAM), such as random-access memory (RAM); the memory 3003 may also include a non-volatile memory (non-volatile memory), such as a flash memory (flash memory), a hard disk (HARD DISK DRIVE, HDD) or a solid state disk (solid-state drive-STATE DRIVE, SSD); memory 3003 may also include combinations of the above types of memory.

Optionally, the memory 903 stores an operating system and programs, executable modules or data structures, or a subset thereof, or an extended set thereof, where the programs may include various operational instructions for performing various operations. The operating system may include various system programs for implementing various underlying services and handling hardware-based tasks. The processor 901 may read the program in the memory 903 to implement the method provided by the embodiment of the present application.

The memory 903 may be a memory device in the communication apparatus 90, or may be a memory device independent of the communication apparatus 90.

The bus system 904 may be a peripheral component interconnect (PERIPHERAL COMPONENT INTERCONNECT, PCI) bus or an extended industry standard architecture (extended industry standard architecture, EISA) bus, or the like. The bus system 3004 may be divided into an address bus, a data bus, a control bus, and the like. For ease of illustration, only one thick line is shown in fig. 10, but not only one bus or one type of bus.

Fig. 11 is a schematic structural diagram of another communication apparatus provided in an embodiment of the present application, specifically, the communication apparatus 100 may be used to implement the function of Aleaf devices 1021 in fig. 2, 5, or 6, or the communication apparatus 100 may be used to implement the function of Sleaf devices 1031 in fig. 2, 5, or 6, or the communication apparatus 90 may be used to implement the function of the first communication apparatus in fig. 7 or 8, or the communication apparatus 90 may be used to implement the function of the second communication apparatus in fig. 9 or 10.

The communication device 100 includes: a main control board 1001 and an interface board 1003.

The main control board 1001 is also called a main processing unit (main processing unit, MPU) or a routing processing card (route processor card), and the main control board 1001 controls and manages various components in the communication apparatus 100, including routing computation, device management, device maintenance, and protocol processing functions. The main control board 1001 includes: a central processing unit 10011 and a memory 10012.

The interface board 1003 is also referred to as a line interface unit card (line processing unit, LPU), line card, or service board. The interface board 1003 is used to provide various service interfaces and to implement forwarding of data packets. The service interfaces include, but are not limited to, ethernet interfaces, such as flexible ethernet service interfaces (flexible ETHERNET CLIENTS, flexE Clients), POS (Packet over SONET/SDH) interfaces, and the like. The interface board 1003 includes: a central processor 10031, a network processor 10032, an address table entry memory 10034, and a physical interface card (PHYSICAL INTERFACE CARD, PIC) 10033.

The cpu 10031 on the interface board 1003 is configured to control and manage the interface board 1003 and communicate with the cpu 10011 on the main control board 1001.

The network processor 10032 is configured to implement forwarding processing of the packet. The network processor 10032 may be in the form of a forwarding chip. Specifically, the processing of the uplink message includes: processing a message input interface and searching a forwarding table; the processing of the downstream message includes forwarding table lookup and the like.

The physical interface card 10033 is used to implement the docking function of the physical layer, from which the original traffic enters the interface board 1003, and from which the processed messages are sent out from the physical interface card 10033. The physical interface card 10033 includes at least one physical interface, also referred to as a physical port. The physical interface card 10033, also called a daughter card, may be mounted on the interface board 1003, and is responsible for converting the photoelectric signal into a message, performing validity check on the message, and forwarding the message to the network processor 10032 for processing. In some embodiments, the central processor 10031 of the interface board 1103 may also perform the functions of the network processor 10032, such as implementing software forwarding based on a general purpose CPU, so that the network processor 10032 is not needed in the physical interface card 10033.

Optionally, the communication device 100 comprises a plurality of interface boards, e.g. the communication device 100 further comprises an interface board 1004, the interface board 1004 comprising: a central processor 10041, a network processor 10042, an address table entry memory 10044, and a physical interface card 10043.

Optionally, communication device 100 also includes a switch fabric 1002. Switch fabric 1002 may also be referred to as a switch fabric unit (switch fabric unit, SFU). In the case where the first communication device has a plurality of interface boards 1003, the switch board 1002 is configured to perform data exchange between the interface boards. For example, interface board 1003 and interface board 1004 may communicate via switch fabric 1002.

The main control board 1001 and the interface board 1003 are coupled. For example. The main control board 1001, the interface board 1003 and the interface board 1004 are connected with the system backboard through a system bus to realize intercommunication among the exchange network boards 1002. In one possible implementation, an inter-process communication protocol (inter-process communication, IPC) channel is established between the master control board 1001 and the interface board 1003, and communication is performed between the master control board 1001 and the interface board 1003 through the IPC channel.

Logically, the communication device 100 includes a control plane including a main control board 1001 and a central processor 10031, and a forwarding plane including various components performing forwarding, such as an address table entry memory 10034, a physical interface card 10033, and a network processor 10032. The control plane performs the functions of router, generating forwarding table, processing signaling and protocol message, configuring and maintaining the state of the device, etc., the control plane issues the generated forwarding table to the forwarding plane, and the network processor 10032 performs table lookup forwarding on the message received by the physical interface card 10033 based on the forwarding table issued by the control plane. The forwarding table issued by the control plane may be stored in address table entry memory 10034. In some embodiments, the control plane and the forwarding plane may be completely separate and not on the same device.

It should be appreciated that the processing unit 802 in the communication device 80 may correspond to the central processor 10011 or the central processor 10031 in the communication device 100.

It should be understood that the operations on the interface board 1004 in the embodiment of the present application are identical to those of the interface board 1003, and for brevity, no further description is provided.

It should be understood that the master control board may have one or more pieces, and that the master control board may include a main master control board and a standby master control board when there are more pieces. The interface boards may have one or more, the more data processing capabilities the communication device 100 provides the more interface boards. The physical interface card on the interface board may also have one or more pieces. The switching network board may not be provided, or may be provided with one or more blocks, and load sharing redundancy backup can be jointly realized when the switching network board is provided with the plurality of blocks. In the centralized forwarding architecture, the communication device 100 may not need a switch board, and the interface board may take on the processing function of the service data of the entire system. Under the distributed forwarding architecture, the communication device 100 may have at least one switch board, through which data exchange between multiple interface boards is implemented, providing high-capacity data exchange and processing capabilities. Therefore, the data access and processing power of the communication apparatus 100 of the distributed architecture is greater than that of the devices of the centralized architecture. Alternatively, the communication apparatus 100 may be in the form of only one board, i.e. there is no switch board, and the functions of the interface board and the main control board are integrated on the one board, where the central processor on the interface board and the central processor on the main control board may be combined into one central processor on the one board, so as to perform the functions after stacking the two, and the data exchange and processing capability of the device in this form are low (for example, a low-end switch or router, etc.). Which architecture is specifically adopted depends on the specific networking deployment scenario.

In some possible embodiments, the above-mentioned communication apparatus may be implemented as a virtualized device. For example, the virtualized device may be a Virtual Machine (VM) running a program for sending message functions, the virtual machine deployed on a hardware device (e.g., a physical server). Virtual machines refer to complete computer systems that run in a completely isolated environment with complete hardware system functionality through software emulation. The virtual machine may be configured as a communication device. For example, the functionality of the communication device may be implemented based on a generic physical server in combination with network function virtualization (network functions virtualization, NFV) technology. A person skilled in the art can virtually obtain the communication device with the above functions on the general physical server by combining the NFV technology by reading the present application, and the details are not repeated here.

It should be noted that, the communication device mentioned in the embodiment of the present application may be a network device such as a switch, a router, or a part of components on the network device, for example, a board on the network device, a line card, a functional module on the network device, or a chip for implementing the method of the present application, and the embodiment of the present application is not limited specifically. When the communication device is a chip, the interface circuit in the chip for performing the receiving or transmitting operation in the communication device may be a processor in the chip for performing the processing operation.

In a specific implementation, the embodiment of the application also provides a chip, which comprises a processor and an interface circuit, wherein the interface circuit is used for receiving the instruction and transmitting the instruction to the processor; and a processor operable to perform the operations of the communication devices in the communication method described above. Wherein the processor is coupled to a memory for storing programs or instructions which, when executed by the processor, cause the chip to implement the method of any of the method embodiments described above.

Alternatively, the processor in the chip may be one or more. The processor may be implemented in hardware and/or in software. When implemented in hardware, the processor may be a logic circuit, an integrated circuit, or the like. When implemented in software, the processor may be a general purpose processor, implemented by reading software code stored in a memory.

Alternatively, the memory in the chip may be one or more. The memory may be integral with the processor or separate from the processor, and the application is not limited. The memory may be a non-transitory processor, such as a ROM, which may be integrated on the same chip as the processor, or may be separately provided on different chips, and the type of memory and the manner of providing the memory and the processor are not particularly limited in the present application.

The chip may be a field programmable gate array (field programmable GATE ARRAY, FPGA), an application-specific integrated chip (ASIC), a system on chip (SoC), a central processing unit (central processor unit, CPU), a network processor (network processor, NP), a digital signal processing circuit (DIGITAL SIGNAL processor, DSP), a microcontroller (micro controller unit, MCU), a programmable controller (programmable logic device, PLD) or other integrated chip, for example.

The embodiments of the present application also provide a computer-readable storage medium comprising instructions or a computer program which, when run on a processor, causes the processor to perform the communication method provided by the above embodiments.

The embodiments of the present application also provide a computer program product comprising instructions or a computer program which, when run on a processor, cause a communication device to perform the method of message forwarding provided by the above embodiments.

The terms "first," "second," "third," "fourth" and the like in the description and in the claims and in the above drawings, if any, are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments described herein may be implemented in other sequences than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing method embodiments, which are not repeated herein.

In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the above-described apparatus embodiments are merely illustrative, e.g., the division of units is merely a logical service division, and there may be additional divisions in actual implementation, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed over a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the embodiment of the present application.

Those skilled in the art will appreciate that in one or more of the examples described above, the services described herein may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the services may be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a general purpose or special purpose computer.

The objects, technical solutions and advantageous effects of the present application have been described in further detail in the above embodiments, and it should be understood that the above are only embodiments of the present application.

The above embodiments are only for illustrating the technical solution of the present application, and not for limiting the same; although the application has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit of the application.

Claims

1. A method of communication, comprising:

the first communication device receives a first message from the second communication device through a leaf interface;

in response to determining to forward the first message via a default media access control, MAC, address table entry, the first communication device discarding the first message, wherein the default MAC address table entry includes a leaf identification and a MAC address of all 0s.

2. The method according to claim 1, wherein the method further comprises:

the first communication device receiving an unknown MAC route UMR from a third communication device, the UMR carrying leaf indication information indicating that the UMR has a leaf attribute;

the first communication device generates the default MAC address table entry according to the UMR.

3. The method of claim 2, wherein the UMR carries an ethernet multicast E-tree extended community attribute; the leaf indication information is included in the E-tree extension community attribute.

4. A method according to claim 2 or 3, wherein the leaf indication information is the leaf identity.

5. The method of any one of claims 2-4, wherein the first communication device is Sleaf equipment and the third communication device is Aleaf equipment.

6. The method according to any one of claims 1-5, further comprising:

the first communication device receives a second message through the leaf interface;

The first communication device searches a matched MAC address table item according to the destination MAC address of the second message, wherein the MAC address table item comprises a root mark;

the first communication device forwards the second message.

7. A method of communication, comprising:

The method comprises the steps that a first communication device receives an unknown medium access control route UMR from a second communication device, wherein the UMR carries leaf indication information, and the leaf indication information indicates that the UMR has a leaf attribute;

The first communication device generates a default MAC address table entry according to the UMR, wherein the default MAC address table entry includes a leaf identifier and a MAC address of all 0s.

8. The method of claim 7, wherein the UMR carries an ethernet multicast E-tree extended community attribute; the leaf indication information is included in the E-tree extension community attribute.

9. The method of claim 7 or 8, wherein the leaf indication information is the leaf identity.

10. The method according to any one of claims 7-9, wherein the first communication means is Sleaf equipment and the second communication means is Aleaf equipment.

11. A method of communication, comprising:

generating an unknown medium access control route UMR by a second communication device, wherein leaf indication information is carried in the UMR, and the leaf indication information indicates that the UMR has a leaf attribute;

the second communication device sends the UMR to the first communication device.

12. The method of claim 11, wherein the UMR carries an ethernet multicast E-tree extended community attribute; the leaf indication information is included in the E-tree extension community attribute.

13. The method according to claim 11 or 12, wherein the second communication means is Aleaf equipment and the first communication means Sleaf equipment.

14. A method of communication, comprising:

the second communication device receives a first message from the first communication device;

In response to determining that a first outgoing interface in a first MAC address table entry matching a destination medium access control MAC address of the first message is a leaf interface, and a second MAC address table entry matching a source MAC address of the first message includes a leaf identity, the second communication device discards the first message.

15. The method of claim 14, wherein the method further comprises:

the second communication device receiving a MAC route from the first communication device; the MAC route comprises a source MAC address of the first message and leaf indication information, and the leaf indication information indicates that the MAC route has a leaf attribute;

and the second communication device generates the second MAC address table item according to the MAC route.

16. The method of claim 15, wherein the leaf indication information is the leaf identification.

17. The method according to any one of claims 14-16, further comprising:

The second communication device receives a second message;

The second communication device responds to the fact that a second output interface in a third MAC address table item matched with the destination MAC address of the second message is a leaf interface, a fourth MAC address table item matched with the source MAC address of the second message comprises a root mark, and the second communication device forwards the second message through the second output interface.

18. The method of any one of claims 14-17, wherein the first communication device is Sleaf equipment and the second communication device Aleaf equipment.

19. A first communication device, comprising:

the receiving unit is used for receiving the first message from the second communication device through the leaf interface;

And a processing unit, configured to forward the first packet through a default media access control MAC address table entry, and discard the first packet, where the default MAC address table entry includes a leaf identifier and a MAC address of all 0.

20. The first communication device of claim 19, wherein the first communication device,

The receiving unit is further configured to receive an unknown MAC route UMR from a third communication device, where the UMR carries leaf indication information that indicates that the UMR has a leaf attribute;

the processing unit is further configured to generate the default MAC address table entry according to the UMR.

21. The first communications apparatus of claim 20, wherein the UMR carries an ethernet multicast E-tree extension community attribute; the leaf indication information is included in the E-tree extension community attribute.

22. The first communication apparatus according to claim 20 or 21, wherein the leaf indication information is the leaf identity.

23. The first communication device of any of claims 20-22, wherein the first communication device is Sleaf equipment and the third communication device is Aleaf equipment.

24. The first communication device according to any of the claims 19-23, wherein the receiving unit is further configured to receive a second message via the leaf interface;

the processing unit is further configured to search a matched MAC address table according to a destination MAC address of the second packet, where the MAC address table includes a root identifier;

the processing unit is further configured to forward the second packet.

25. A first communication device, comprising:

A receiving unit, configured to receive an unknown media access control route UMR from a second communication device, the UMR carrying leaf indication information, the leaf indication information indicating that the UMR has a leaf attribute;

And the processing unit is used for generating a default MAC address table item according to the UMR, wherein the default MAC address table item comprises a leaf identifier and an MAC address of all 0.

26. The first communications apparatus of claim 25, wherein the UMR carries an ethernet multicast E-tree extension community attribute; the leaf indication information is included in the E-tree extension community attribute.

27. The first communication apparatus according to claim 25 or 26, wherein the leaf indication information is the leaf identity.

28. The first communication device of any of claims 25-27, wherein the first communication device is Sleaf equipment and the second communication device is Aleaf equipment.

29. A second communication device, comprising:

A processing unit, configured to generate an unknown media access control route UMR, where the UMR carries leaf indication information, where the leaf indication information indicates that the UMR has a leaf attribute;

And a transmitting unit configured to transmit the UMR to a first communication device.

30. The second communications apparatus of claim 29, wherein the UMR carries an ethernet multicast E-tree extension community attribute; the E-tree extension community attribute comprises leaf indication information.

31. The second communication apparatus according to claim 29 or 30, wherein the first communication apparatus is Aleaf equipment and the second communication apparatus Sleaf equipment.

32. A second communication device, comprising:

a receiving unit, configured to receive a first packet from a first communication device;

And the processing unit is used for responding to the fact that a first output interface in a first MAC address table item matched with the destination Media Access Control (MAC) address of the first message is a leaf interface, and a second MAC address table item matched with the source MAC address of the first message comprises a leaf identifier, and the second communication device discards the first message.

33. The second communication device according to claim 32, wherein the receiving unit is further configured to receive a MAC route from the first communication device; the MAC route comprises a source MAC address of the first message and leaf indication information, and the leaf indication information indicates that the MAC route has a leaf attribute;

The processing unit is further configured to generate the second MAC address table according to the MAC route.

34. The second communication apparatus according to claim 32 or 33, wherein the leaf indication information is the leaf identification.

35. The second communication device according to any of the claims 32-34, wherein the receiving unit is further configured to receive a second message;

The processing unit is further configured to respond to determining that a second output interface in a third MAC address table entry matched with the destination MAC address of the second packet is a leaf interface, and that a fourth MAC address table entry matched with the source MAC address of the second packet includes a root identifier, where the second communication device forwards the second packet through the second output interface.

36. The second communication device according to any of claims 32-35, wherein the second communication device is a Aleaf apparatus and the first communication device Sleaf apparatus.

37. A communication device comprising a processor and a memory for storing computer instructions which, when run in the processor, cause the communication device to implement the method of any one of claims 1-6, or to implement the method of any one of claims 7-10, or to implement the method of any one of claims 11-13, or to implement the method of any one of claims 14-18.

38. A communication system comprising a first communication device and a second communication device;

Wherein the first communication device is adapted to implement the method of any of claims 1-10 and the second communication device is adapted to implement the method of any of claims 11-13.

39. A communication system comprising a first communication device and a second communication device for implementing the method according to any of claims 14-18.

40. A computer readable storage medium having instructions stored therein which, when run on a processor, implement the method of any one of claims 1-6, or the method of any one of claims 7-10, or the method of any one of claims 11-13, or the method of any one of claims 14-18.

41. A computer program product comprising a computer program which, when run on a processor, implements the method of any one of claims 1-6, or implements the method of any one of claims 7-10, or implements the method of any one of claims 11-13, or implements the method of any one of claims 14-18.