CN109218207B - Multicast traffic processing method and device and routing equipment - Google Patents

Multicast traffic processing method and device and routing equipment Download PDF

Info

Publication number
CN109218207B
CN109218207B CN201811160061.9A CN201811160061A CN109218207B CN 109218207 B CN109218207 B CN 109218207B CN 201811160061 A CN201811160061 A CN 201811160061A CN 109218207 B CN109218207 B CN 109218207B
Authority
CN
China
Prior art keywords
routing device
routing
multicast
multicast traffic
devices
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201811160061.9A
Other languages
Chinese (zh)
Other versions
CN109218207A (en
Inventor
张勇
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hangzhou H3C Technologies Co Ltd
Original Assignee
Hangzhou H3C Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hangzhou H3C Technologies Co Ltd filed Critical Hangzhou H3C Technologies Co Ltd
Priority to CN201811160061.9A priority Critical patent/CN109218207B/en
Publication of CN109218207A publication Critical patent/CN109218207A/en
Application granted granted Critical
Publication of CN109218207B publication Critical patent/CN109218207B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/16Multipoint routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/12Avoiding congestion; Recovering from congestion
    • H04L47/125Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering

Abstract

The present disclosure provides a multicast traffic processing method, apparatus and routing device, where the routing device receives a first assertion message sent by other routing devices in the same network segment, where the message includes a priority of a unicast route to a multicast source, a metric to the multicast source, and an identifier used to indicate whether the routing device has carried multicast traffic of the multicast source; determining a second routing device from the network segment, wherein the second routing device is the routing device with the minimum metric value determined from the routing device with the highest priority; determining a third routing device from the second routing devices, wherein the third routing device is a routing device which is determined based on the identifier corresponding to the second routing device and does not carry the multicast traffic of the multicast source; and determining the first routing equipment for carrying the current multicast traffic from the third routing equipment. According to the method and the device, the multicast traffic of the same multicast source is commonly borne by the plurality of routing devices, so that the processing pressure of a single device can be reduced.

Description

Multicast traffic processing method and device and routing equipment
Technical Field
The present disclosure relates to the field of network communication technologies, and in particular, to a multicast traffic processing method and apparatus, and a routing device.
Background
PIM (Protocol Independent Multicast) provides routing for IP (Internet Protocol) Multicast using a unicast routing table generated by a static route or an arbitrary unicast routing Protocol. The multicast routing is independent of the unicast routing protocol employed.
The PIM realizes Forwarding of the multicast packet by means of an RPF (Reverse Path Forwarding) mechanism. When the multicast message reaches the local device, firstly, the RPF check is carried out: if the RPF passes the check, a corresponding multicast routing table item is created, so that the multicast message is forwarded; if the RPF check fails, the message is discarded.
When a plurality of routing devices supporting PIM exist in a network segment, a unique multicast message forwarder needs to be selected for the network segment so as to avoid the same multicast message in the network segment.
Disclosure of Invention
The present disclosure provides a multicast traffic processing method, an apparatus, and a routing device, for solving the problem of high processing pressure when multicast traffic of the same multicast source is carried by a single routing device, so as to implement that multicast traffic of the same multicast source is carried by multiple routing devices.
In order to achieve the above disclosure purpose, the present disclosure provides the following technical solutions:
in a first aspect, the present disclosure provides a multicast traffic processing method, applied to a routing device, where the method includes:
receiving first assertion messages sent by other routing devices in the same network segment, wherein the first assertion messages are used for determining a first routing device to be loaded with current multicast traffic, and the first assertion messages comprise the priority of a unicast route to a multicast source sending the multicast traffic, a metric value to the multicast source and an identifier used for indicating whether the routing device already loads the multicast traffic of the multicast source;
determining a second routing device from the network segment, wherein the second routing device is the routing device with the minimum metric value determined from the routing device with the highest priority;
determining a third routing device from the second routing devices, where the third routing device is a routing device that does not carry the multicast traffic of the multicast source and is determined based on the identifier corresponding to the second routing device;
determining the first routing device from the third routing device;
and if the routing equipment is the first routing equipment, bearing the current multicast flow.
In a second aspect, the present disclosure further provides a multicast traffic processing apparatus, applied to a routing device, where the apparatus includes:
a receiving unit, configured to receive a first assertion message sent by other routing devices in the same network segment, where the first assertion message is used to determine a first routing device to be configured with a current multicast traffic, and the first assertion message includes a priority of a unicast route to a multicast source that sends the multicast traffic, a metric to the multicast source, and an identifier indicating whether the routing device has configured with the multicast traffic of the multicast source;
a determining unit, configured to determine a second routing device from the network segment, where the second routing device is a routing device with a smallest metric value determined from a routing device with a highest priority; determining a third routing device from the second routing devices, where the third routing device is a routing device that does not carry the multicast traffic of the multicast source and is determined based on the identifier corresponding to the second routing device; determining the first routing device from the third routing device;
and the bearing unit is used for bearing the current multicast flow if the routing equipment is the first routing equipment.
In a third aspect, the present disclosure also provides a routing device comprising a processor and a machine-readable storage medium storing machine-executable instructions executable by the processor, the processor being caused by the machine-executable instructions to: the multicast traffic processing method is realized.
In a fourth aspect, the present disclosure also provides a machine-readable storage medium, in which machine-executable instructions are stored, and when executed by a processor, the machine-executable instructions implement the multicast traffic processing method.
It can be seen from the above description that in the present disclosure, multiple routing devices in the same network segment jointly bear multicast traffic of the same multicast source, so that processing pressure of a single device can be reduced, a forwarding bottleneck is avoided, and network resources are reasonably utilized.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present disclosure, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present disclosure, and it is obvious for those skilled in the art to obtain other drawings based on the drawings without creative efforts.
Fig. 1 is a schematic networking diagram of a network segment including multiple routing devices according to an embodiment of the present disclosure;
fig. 2 is a flowchart illustrating a multicast traffic processing method according to an embodiment of the disclosure;
fig. 3 is a schematic hardware structure diagram of a routing device according to an embodiment of the present disclosure;
fig. 4 is a schematic structural diagram of multicast traffic processing logic according to an embodiment of the present disclosure.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the exemplary embodiments below are not intended to represent all implementations consistent with the present disclosure. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present disclosure, as detailed in the appended claims.
The terminology used in the present disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used in this disclosure and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.
It is to be understood that although the terms first, second, third, etc. may be used herein to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the present disclosure. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.
Referring to fig. 1, a networking schematic diagram that a same network segment includes multiple routing devices is shown in the embodiment of the present disclosure. Among them, the devices 111 to 116 are multicast routing devices in the network segment, and the host 120 is a multicast receiver.
When the devices 111 to 115 receive the multicast packet from the upstream interface, the multicast packet is forwarded to the local network segment through the downstream interface. The upstream interface is an interface for the routing device to receive the multicast message, and the downstream interface is an interface for the routing device to forward the multicast message.
The device 116 receives 5 identical multicast packets, and the devices 111 to 115 also receive multicast packets forwarded by 4 other routing devices except the device itself. At this time, the devices 111 to 115 send assertion messages to all the routing devices in the network segment in a multicast manner, where the assertion messages carry addresses of multicast sources, addresses of multicast groups, priorities of unicast routes to the multicast sources (hereinafter referred to as priorities), and metric values to the multicast sources (hereinafter referred to as metric values).
Taking the device 111 as an example, the device 111 receives the assertion message sent by the devices 112 to 115, and locally records the corresponding relationship among the IP address (source IP address of the assertion message), the priority, and the metric of each routing device, as shown in table 1.
IP address of routing device Priority level Metric value
10.0.0.1 1 1
10.0.0.2 1 1
10.0.0.3 1 1
10.0.0.4 1 2
10.0.0.5 2 3
TABLE 1
Wherein 10.0.0.1 to 10.0.0.5 are the IP addresses of the downstream interfaces of the devices 111 to 115, respectively.
First, the device 111 compares the priorities corresponding to the routing devices, and determines the routing device with the highest priority (in this embodiment, the smaller the value, the higher the corresponding priority). As can be seen from Table 1, the priority levels of the devices 111 to 114(10.0.0.1 to 10.0.0.4) are highest.
Then, the device 111 selects a routing device having the smallest metric value from the devices 111 to 114. As can be seen from Table 1, the metric values for the devices 111 through 113(10.0.0.1 through 10.0.0.3) are the smallest.
Finally, the device 111 selects a routing device having the largest IP address from the devices 111 to 113. As can be seen from table 1, the IP address (10.0.0.3) of the device 113 is the largest among the devices 111 to 113(10.0.0.1 to 10.0.0.3).
Device 111 selects device 113 as the only forwarder of multicast traffic of the multicast source in the current network segment. Similarly, the devices 112 to 115 in the segment select the device 113 as the only forwarder of the multicast traffic of the multicast source in the current segment based on the same election mode. Therefore, only the device 113 in the network segment is responsible for forwarding the multicast traffic of the current multicast source, thereby avoiding multiple identical multicast messages in the network segment.
However, one routing device is responsible for forwarding all multicast traffic of the same multicast source, which causes a large processing pressure on the routing device, and a forwarding bottleneck is easily formed, thereby wasting network resources.
In order to solve the problems, the present disclosure provides a multicast traffic processing method, in which multiple routing devices in the same network segment jointly carry multicast traffic of the same multicast source, so that processing pressure of a single device can be reduced, a forwarding bottleneck is avoided, and network resources are reasonably utilized.
For the purpose of making the objects, aspects and advantages of the present disclosure more apparent, the present disclosure will be described in detail below with reference to the accompanying drawings and specific embodiments:
referring to fig. 2, a flowchart of a multicast traffic processing method according to the present disclosure is shown, and the flowchart is applied to a routing device.
As shown in fig. 2, the process may include the following steps:
step 201, receiving a first assertion message sent by other routing devices in the same network segment.
The first assertion message is used for determining a first routing device to be loaded with the current multicast traffic. The first assertion message includes: the priority of the unicast route to the multicast source sending the current multicast traffic, the metric value to the multicast source, and an identifier indicating whether the routing device already carries the multicast traffic of the multicast source.
Here, the first routing device and the first assertion message are only named for convenience of description and are not intended to be limiting.
Step 202, a second routing device is determined from the network segment.
The second routing device is the routing device with the smallest metric value determined from the routing devices with the highest priority. Here, the second routing device is named for convenience of description only and is not limiting.
The present disclosure first determines the routing device with the highest priority. If only one route device with the highest priority is available, the route device with the highest priority can be directly selected to bear the current multicast flow.
And if a plurality of routing devices with the highest priority exist, determining the routing device with the minimum metric value, namely the second routing device, from the plurality of routing devices with the highest priority. If only one second routing device is available, the second routing device can be directly selected to carry the current multicast flow; if there are more than one second routing device, go to step 203.
Step 203, determining a third routing device from the second routing devices.
The third routing device is a routing device which is determined based on the identifier corresponding to the second routing device and does not carry the multicast traffic of the current multicast source. Here, the third routing device is named only for convenience of description and is not intended to be limiting.
It should be noted that the identifier corresponding to the second routing device is an identifier included in the first assertion packet sent by the second routing device.
Step 204, determining the first routing device from the third routing devices.
That is, the first routing device for carrying the current multicast traffic is determined from the third routing device that does not carry the multicast traffic of the current multicast source.
The process of determining the first routing device is described below, and is not repeated here.
Step 205, if the routing device is the first routing device, the current multicast traffic is carried.
Thus, the flow shown in fig. 2 is completed.
As can be seen from the flow shown in fig. 2, in the present disclosure, multiple routing devices in the same network segment jointly bear the multicast traffic of the same multicast source, so that the processing pressure of a single device can be reduced, the forwarding bottleneck is avoided, and network resources are reasonably utilized.
As an embodiment, after performing step 205, the routing device sets its corresponding identifier as a first value, where the first value is used to indicate that the routing device already carries multicast traffic of the current multicast source. So that when the next time the new multicast traffic carrying the multicast source is determined, the new multicast traffic is carried by other routing devices not carrying the multicast traffic of the multicast source. Here, the first value is named for convenience of description only and is not intended to be limiting.
As an embodiment, if the second routing device does not have the third routing device, it is described that all the second routing devices already carry the multicast traffic of the current multicast source. And if the routing equipment is the second routing equipment, the routing equipment sends a second assertion message. The identifier included in the second assertion message is a second value, and the second value is used for indicating that the routing device does not carry the multicast traffic of the current multicast source. And all the routing devices re-determine the first routing device bearing the current multicast flow based on the second assertion message sent by the second routing device.
Determining the first routing device from the third routing devices in step 204 is described below.
For one embodiment, the routing device may select a third routing device with the smallest IP address in the current network segment as the first routing device.
As another embodiment, the routing device may select a third routing device with the largest IP address in the current network segment as the first routing device.
As another embodiment, the routing device may select any third routing device in the current network segment as the first routing device.
So far, the selection of the first routing device is realized.
The method provided by the present disclosure is described below by a specific embodiment:
the networking shown in fig. 1 is still taken as an example.
If the devices 111 to 115 receive the multicast Packet1 sent by the multicast source 1.1.1.1 to the multicast group 225.0.0.1, the devices 111 to 115 forward the Packet1 to the local network segment. The devices 111 to 115 receive the packets 1 forwarded by 4 other routing devices except the devices themselves. At this time, the devices 111 to 115 send assertion messages to all the routing devices in the local network segment in a multicast manner, where the assertion messages carry an address (1.1.1.1) of the multicast source, an address (225.0.0.1) of the multicast group, a priority of a unicast route to the multicast source, a metric value to the multicast source, and an identifier indicating whether the routing device has carried multicast traffic of the multicast source 1.1.1.1.
Taking the device 111 as an example, the device 111 receives the assertion message sent by the devices 112 to 115, and locally records the correspondence between the IP address (source IP address of the assertion message), the priority, the metric value, and the identifier of each routing device, as shown in table 2.
IP address of routing device Priority level Metric value Identification
10.0.0.1 1 1 0
10.0.0.2 1 1 0
10.0.0.3 1 1 0
10.0.0.4 1 2 0
10.0.0.5 2 3 0
TABLE 2
Wherein 10.0.0.1 to 10.0.0.5 are the IP addresses of the devices 111 to 115 in the local network segment, respectively.
It should be noted that, in this embodiment, the identifier value is 0, which indicates that the routing device does not carry the multicast traffic of the multicast source 1.1.1.1; the identifier value is 1, which indicates that the routing device already carries the multicast traffic of the multicast source 1.1.1.1.
First, the device 111 compares the priorities corresponding to the routing devices, and determines the routing device with the highest priority (in this embodiment, the smaller the value, the higher the corresponding priority). As can be seen from Table 2, the priority levels of the devices 111 to 114(10.0.0.1 to 10.0.0.4) are highest.
Then, the device 111 selects a routing device having the smallest metric value from the devices 111 to 114. As can be seen from Table 2, the metric values for the devices 111 to 113(10.0.0.1 to 10.0.0.3) are the smallest.
The identifiers corresponding to the devices 111 to 113 are all 0, that is, none of the devices 111 to 113 currently carries the multicast traffic of the multicast source 1.1.1.1. Therefore, the device 111 may select one device from the devices 111 to 113 to carry the multicast traffic from the multicast source 1.1.1.1 to the multicast group 225.0.0.1. For example, the device 111 with the smallest IP address (10.0.0.1) is selected to carry the multicast traffic, and the corresponding identifier of the device 111 is set to 1. Similarly, the devices 112 to 115 also select the device 111 to carry the multicast traffic based on the same processing method.
If the devices 111 to 115 receive the multicast Packet2 sent by the multicast source 1.1.1.1 to the multicast group 225.0.0.2, the devices 111 to 115 forward the Packet2 to the local network segment. The devices 111 to 115 receive the packets 2 forwarded by 4 other routing devices except the devices themselves. At this time, the devices 111 to 115 send assertion messages to all the routing devices in the local network segment in a multicast manner, where the assertion messages carry an address (1.1.1.1) of the multicast source, an address (225.0.0.2) of the multicast group, a priority of a unicast route to the multicast source, a metric value to the multicast source, and an identifier indicating whether the routing device has carried multicast traffic of the multicast source 1.1.1.1.
Still taking the device 111 as an example, the device 111 receives the assertion packet sent by the devices 112 to 115, and locally records the corresponding relationship among the IP address, the priority, the metric value, and the identifier of each routing device, as shown in table 3.
IP address of routing device Priority level Metric value Identification
10.0.0.1 1 1 1
10.0.0.2 1 1 0
10.0.0.3 1 1 0
10.0.0.4 1 2 0
10.0.0.5 2 3 0
TABLE 3
First, the device 111 compares the priorities corresponding to the respective routing devices, and determines the routing device with the highest priority. As can be seen from Table 3, the priority levels of the devices 111 to 114(10.0.0.1 to 10.0.0.4) are highest.
Then, the device 111 selects a routing device having the smallest metric value from the devices 111 to 114. As can be seen from Table 3, the metric values for the devices 111 through 113(10.0.0.1 through 10.0.0.3) are the smallest.
The identifier corresponding to the device 111 is 1, which indicates that the device 111 already carries the multicast traffic of the multicast source 1.1.1.1 (as described above, the device 111 already carries the multicast traffic sent by the multicast source 1.1.1.1 to the multicast group 225.0.0.1); the identifiers corresponding to the device 112 and the device 113 are both 0, which indicates that neither the device 112 nor the device 113 carries the multicast traffic of the multicast source 1.1.1.1. Thus, device 111 may select one of device 112 and device 113 to carry multicast traffic from multicast source 1.1.1.1 to multicast group 225.0.0.2. For example, the device 112 with the smallest current IP address (10.0.0.2) is selected to carry the multicast traffic. Similarly, the devices 112 to 115 also select the device 112 to carry the multicast traffic based on the same processing manner. At the same time, device 112 will set its corresponding identification to 1.
If the devices 111 to 115 receive the multicast Packet3 sent by the multicast source 1.1.1.1 to the multicast group 225.0.0.3, the devices 111 to 115 forward the Packet3 to the local network segment. The devices 111 to 115 receive the packets 3 forwarded by 4 other routing devices except the devices themselves. At this time, the devices 111 to 115 send assertion messages to all the routing devices in the local network segment in a multicast manner, where the assertion messages carry an address (1.1.1.1) of the multicast source, an address (225.0.0.3) of the multicast group, a priority of a unicast route to the multicast source, a metric value to the multicast source, and an identifier indicating whether the routing device has carried multicast traffic of the multicast source 1.1.1.1.
Still taking the device 111 as an example, the device 111 receives the assertion packet sent by the devices 112 to 115, and locally records the correspondence between the IP address, the priority, the metric value, and the identifier of each routing device, as shown in table 4.
IP address of routing device Priority level Metric value Identification
10.0.0.1 1 1 1
10.0.0.2 1 1 1
10.0.0.3 1 1 0
10.0.0.4 1 2 0
10.0.0.5 2 3 0
TABLE 4
First, the device 111 compares the priorities corresponding to the respective routing devices, and determines the routing device with the highest priority. As can be seen from Table 4, the priority levels of the devices 111 to 114(10.0.0.1 to 10.0.0.4) are highest.
Then, the device 111 selects a routing device having the smallest metric value from the devices 111 to 114. As can be seen from Table 4, the metric values for the devices 111 to 113(10.0.0.1 to 10.0.0.3) are the smallest.
The identifiers corresponding to the device 111 and the device 112 are both 1, which indicates that both the device 111 and the device 112 have carried the multicast traffic of the multicast source 1.1.1.1 (as described above, the device 111 has carried the multicast traffic sent by the multicast source 1.1.1.1 to the multicast group 225.0.0.1, and the device 112 has carried the multicast traffic sent by the multicast source 1.1.1 to the multicast group 225.0.0.2); the identifier corresponding to the device 113 is 0, which indicates that the device 113 does not carry the multicast traffic of the multicast source 1.1.1.1. Thus, device 111 selects device 113 to carry multicast traffic for multicast source 1.1.1.1 to multicast group 225.0.0.3. Similarly, the devices 112 to 115 also select the device 113 to carry the multicast traffic based on the same processing method. At the same time, the device 113 will set its corresponding flag to 1.
If the devices 111 to 115 receive the multicast Packet4 sent by the multicast source 1.1.1.1 to the multicast group 225.0.0.4, the devices 111 to 115 forward the Packet4 to the local network segment. The devices 111 to 115 receive the packets 4 forwarded by 4 other routing devices except the devices themselves. At this time, the devices 111 to 115 send assertion messages to all the routing devices in the local network segment in a multicast manner, where the assertion messages carry an address (1.1.1.1) of the multicast source, an address (225.0.0.4) of the multicast group, a priority of a unicast route to the multicast source, a metric value to the multicast source, and an identifier indicating whether the routing device has carried multicast traffic of the multicast source 1.1.1.1.
Still taking the device 111 as an example, the device 111 receives the assertion packet sent by the devices 112 to 115, and locally records the corresponding relationship among the IP address, the priority, the metric value, and the identifier of each routing device, as shown in table 5.
IP address of routing device Priority level Metric value Identification
10.0.0.1 1 1 1
10.0.0.2 1 1 1
10.0.0.3 1 1 1
10.0.0.4 1 2 0
10.0.0.5 2 3 0
TABLE 5
First, the device 111 compares the priorities corresponding to the respective routing devices, and determines the routing device with the highest priority. As can be seen from Table 5, the priority levels of the devices 111 to 114(10.0.0.1 to 10.0.0.4) are highest.
Then, the device 111 selects a routing device having the smallest metric value from the devices 111 to 114. As can be seen from Table 5, the metric values for the devices 111 to 113(10.0.0.1 to 10.0.0.3) are the smallest.
The identifiers corresponding to the devices 111 to 113 are all 1, which indicates that the devices 111 to 113 all have multicast traffic of the multicast source 1.1.1.1 (as described above, the device 111 has carried multicast traffic sent by the multicast source 1.1.1.1 to the multicast group 225.0.0.1, the device 112 has carried multicast traffic sent by the multicast source 1.1.1.1 to the multicast group 225.0.0.2, and the device 113 has carried multicast traffic sent by the multicast source 1.1.1.1 to the multicast group 225.0.0.3). At this time, the device 111 sets its corresponding identifier to 0, and sends an assertion message to the local network segment, where the assertion message includes an address (1.1.1.1) of the multicast source, an address (225.0.0.4) of the multicast group, a priority (1) of the unicast route to the multicast source, a metric (1) to the multicast source, and the identifier (0). Similarly, the device 112 and the device 113 also set their corresponding identifiers to 0, and send an assertion packet to the local network segment.
After receiving the new assertion packet, the device 111 updates the correspondence between the IP address, the priority, the metric value, and the identifier of each routing device, as shown in table 2. The foregoing processing procedure is re-executed, and is not described herein again.
This completes the description of the present embodiment.
The method provided by the present disclosure is described above, and the routing device and the machine-readable storage medium provided by the present disclosure are described below:
referring to fig. 3, a hardware structure diagram of a routing device provided in the present disclosure is shown. The routing device may include a processor 301, a machine-readable storage medium 302 having machine-executable instructions stored thereon. The processor 301 and the machine-readable storage medium 302 may communicate via a system bus 303. Also, the processor 301 may perform the multicast traffic processing method described above by reading and executing machine-executable instructions in the machine-readable storage medium 302 corresponding to the multicast traffic processing logic.
The machine-readable storage medium 302 referred to herein may be any electronic, magnetic, optical, or other physical storage device that can contain or store information such as executable instructions, data, and the like. For example, the machine-readable storage medium 302 may include at least one of the following: volatile memory, non-volatile memory, other types of storage media. The volatile Memory may be a Random Access Memory (RAM), and the nonvolatile Memory may be a flash Memory, a storage drive (e.g., a hard disk drive), a solid state disk, and a storage disk (e.g., a compact disk, a DVD).
Referring to fig. 4, functionally, the multicast traffic processing logic may include a receiving unit 401, a determining unit 402, and a carrying unit 403, where:
a receiving unit 401, configured to receive a first assertion message sent by other routing devices in the same network segment, where the first assertion message is used to determine a first routing device to be configured with a current multicast traffic, and the first assertion message includes a priority of a unicast route to a multicast source that sends the multicast traffic, a metric to the multicast source, and an identifier used to indicate whether the routing device has configured with the multicast traffic of the multicast source;
a determining unit 402, configured to determine a second routing device from the network segment, where the second routing device is a routing device with a smallest metric value determined from a routing device with a highest priority; determining a third routing device from the second routing devices, where the third routing device is a routing device that does not carry the multicast traffic of the multicast source and is determined based on the identifier corresponding to the second routing device; determining the first routing device from the third routing device;
a carrying unit 403, configured to carry the current multicast traffic if the current routing device is the first routing device.
As an embodiment, the apparatus further comprises:
and the setting unit is used for setting the identifier corresponding to the routing device as a first value, and the first value is used for indicating that the routing device already bears the multicast traffic of the multicast source.
As an embodiment, the apparatus further comprises:
and a sending unit, configured to send a second assertion packet if the third routing device does not exist and the routing device is the second routing device, where an identifier included in the second assertion packet is a second value, and the second value is used to indicate that the routing device does not carry the multicast traffic of the multicast source.
As an embodiment, the determining unit 402 determines the first routing device from the third routing devices, including: selecting a third routing device with the minimum IP address in the network segment as the first routing device; or selecting a third routing device with the largest IP address in the network segment as the first routing device; or selecting any third routing device in the network segment as the first routing device.
The present disclosure also provides a machine-readable storage medium, such as machine-readable storage medium 302 in fig. 3, comprising machine-executable instructions that are executable by processor 301 in a routing device to implement the multicast traffic processing method described above.
Up to this point, the description of the routing device shown in fig. 3 is completed.
The above description is only exemplary of the present disclosure and should not be taken as limiting the disclosure, as any modification, equivalent replacement, or improvement made within the spirit and principle of the present disclosure should be included in the scope of the present disclosure.

Claims (10)

1. A multicast traffic processing method is applied to a routing device, and the method comprises the following steps:
receiving first assertion messages sent by other routing devices in the same network segment, wherein the first assertion messages are used for determining a first routing device to be loaded with current multicast traffic, and the first assertion messages comprise the priority of a unicast route to a multicast source sending the multicast traffic, a metric value to the multicast source and an identifier used for indicating whether the routing device already loads the multicast traffic of the multicast source;
determining a second routing device from the network segment, wherein the second routing device is the routing device with the minimum metric value determined from the routing device with the highest priority;
determining a third routing device from the second routing devices, where the third routing device is a routing device that does not carry the multicast traffic of the multicast source and is determined based on the identifier corresponding to the second routing device;
determining the first routing device from the third routing device;
and if the routing equipment is the first routing equipment, bearing the current multicast flow.
2. The method of claim 1, wherein after the carrying the current multicast traffic, further comprising:
and setting the identifier corresponding to the routing equipment as a first value, wherein the first value is used for indicating that the routing equipment bears the multicast traffic of the multicast source.
3. The method of claim 1, wherein the method further comprises:
and if the third routing equipment does not exist and the routing equipment is the second routing equipment, sending a second assertion message, wherein the identifier included in the second assertion message is a second value, and the second value is used for indicating that the routing equipment does not bear the multicast traffic of the multicast source.
4. The method of claim 1, wherein said determining the first routing device from the third routing device comprises:
selecting a third routing device with the minimum IP address in the network segment as the first routing device;
alternatively, the first and second electrodes may be,
selecting a third routing device with the largest IP address in the network segment as the first routing device;
alternatively, the first and second electrodes may be,
and selecting any third routing device in the network segment as the first routing device.
5. A multicast traffic processing apparatus, applied to a routing device, the apparatus comprising:
a receiving unit, configured to receive a first assertion message sent by other routing devices in the same network segment, where the first assertion message is used to determine a first routing device to be configured with a current multicast traffic, and the first assertion message includes a priority of a unicast route to a multicast source that sends the multicast traffic, a metric to the multicast source, and an identifier indicating whether the routing device has configured with the multicast traffic of the multicast source;
a determining unit, configured to determine a second routing device from the network segment, where the second routing device is a routing device with a smallest metric value determined from a routing device with a highest priority; determining a third routing device from the second routing devices, where the third routing device is a routing device that does not carry the multicast traffic of the multicast source and is determined based on the identifier corresponding to the second routing device; determining the first routing device from the third routing device;
and the bearing unit is used for bearing the current multicast flow if the routing equipment is the first routing equipment.
6. The apparatus of claim 5, wherein the apparatus further comprises:
and the setting unit is used for setting the identifier corresponding to the routing device as a first value, and the first value is used for indicating that the routing device already bears the multicast traffic of the multicast source.
7. The apparatus of claim 5, wherein the apparatus further comprises:
and a sending unit, configured to send a second assertion packet if the third routing device does not exist and the routing device is the second routing device, where an identifier included in the second assertion packet is a second value, and the second value is used to indicate that the routing device does not carry the multicast traffic of the multicast source.
8. The apparatus of claim 5, wherein the determining unit determines the first routing device from the third routing devices, comprising:
selecting a third routing device with the minimum IP address in the network segment as the first routing device;
alternatively, the first and second electrodes may be,
selecting a third routing device with the largest IP address in the network segment as the first routing device;
alternatively, the first and second electrodes may be,
and selecting any third routing device in the network segment as the first routing device.
9. A routing device comprising a processor and a machine-readable storage medium storing machine-executable instructions executable by the processor, the processor being caused by the machine-executable instructions to: carrying out the method steps of any one of claims 1 to 4.
10. A machine-readable storage medium having stored therein machine-executable instructions which, when executed by a processor, perform the method steps of any of claims 1-4.
CN201811160061.9A 2018-09-30 2018-09-30 Multicast traffic processing method and device and routing equipment Active CN109218207B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201811160061.9A CN109218207B (en) 2018-09-30 2018-09-30 Multicast traffic processing method and device and routing equipment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201811160061.9A CN109218207B (en) 2018-09-30 2018-09-30 Multicast traffic processing method and device and routing equipment

Publications (2)

Publication Number Publication Date
CN109218207A CN109218207A (en) 2019-01-15
CN109218207B true CN109218207B (en) 2021-02-26

Family

ID=64982826

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811160061.9A Active CN109218207B (en) 2018-09-30 2018-09-30 Multicast traffic processing method and device and routing equipment

Country Status (1)

Country Link
CN (1) CN109218207B (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111600798B (en) 2019-02-21 2021-11-19 华为技术有限公司 Method and equipment for sending and obtaining assertion message

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1437367A (en) * 2002-02-09 2003-08-20 华为技术有限公司 Multicast business realizing method in mobile network
CN101035009A (en) * 2007-03-31 2007-09-12 华为技术有限公司 Multicast traffic redundancy protection method and device
CN102315951A (en) * 2011-09-19 2012-01-11 华为技术有限公司 Transmission method for multicast message, correlated equipment and system
CN103117935A (en) * 2013-02-28 2013-05-22 杭州华三通信技术有限公司 Multicast data forwarding method and multicast data forwarding device applied to multi-homing networking
CN104901893A (en) * 2015-06-11 2015-09-09 杭州华三通信技术有限公司 Method and device for protecting multicast traffic
CN105591961A (en) * 2015-07-29 2016-05-18 杭州华三通信技术有限公司 Method and device for selecting rendezvous point RP for multicast group

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1437367A (en) * 2002-02-09 2003-08-20 华为技术有限公司 Multicast business realizing method in mobile network
CN101035009A (en) * 2007-03-31 2007-09-12 华为技术有限公司 Multicast traffic redundancy protection method and device
CN102315951A (en) * 2011-09-19 2012-01-11 华为技术有限公司 Transmission method for multicast message, correlated equipment and system
CN103117935A (en) * 2013-02-28 2013-05-22 杭州华三通信技术有限公司 Multicast data forwarding method and multicast data forwarding device applied to multi-homing networking
CN104901893A (en) * 2015-06-11 2015-09-09 杭州华三通信技术有限公司 Method and device for protecting multicast traffic
CN105591961A (en) * 2015-07-29 2016-05-18 杭州华三通信技术有限公司 Method and device for selecting rendezvous point RP for multicast group

Also Published As

Publication number Publication date
CN109218207A (en) 2019-01-15

Similar Documents

Publication Publication Date Title
US10447496B2 (en) Multicast traffic steering using tree identity in bit indexed explicit replication (BIER)
US20200169432A1 (en) Bridging of non-capable subnetworks in bit indexed explicit replication
JP4474247B2 (en) System and method for managing multicast group membership
US11140069B2 (en) Optimizing information related to a route and/or a next hop for multicast traffic
CN108600099B (en) Message forwarding method and device and leaf equipment
US9112787B2 (en) First hop load balancing
CN108600069B (en) Link switching method and device
US20200328914A1 (en) Packet transmission
CN107948066B (en) Designated forwarder DF election method, system and device
CN112367257B (en) Route notification method and device
US20190349293A1 (en) Managing Data Frames in Switched Networks
CN108600070B (en) Designated forwarder DF election method and device
CN104754070A (en) Method and device for learning address resolution protocol table entries and network device
CN110768917B (en) Message transmission method and device
CN108322376B (en) Route synchronization method, device and machine-readable storage medium
CN108259348B (en) Message transmission method and device
CN109218207B (en) Multicast traffic processing method and device and routing equipment
US10476774B2 (en) Selective transmission of bidirectional forwarding detection (BFD) messages for verifying multicast connectivity
CN113037879A (en) ARP learning method and node equipment
CN107566302B (en) Message forwarding method and device
CN109039957B (en) Message forwarding method and device and CB equipment
CN112187635B (en) Message forwarding method and device
CN112242907B (en) Multicast group membership management
CN111565145B (en) Cross-domain path protection method and system
CN109039902B (en) Method and device for forwarding multicast message

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant