WO2012103694A1 - 一种二层组播路径跟踪方法、装置及系统 - Google Patents

一种二层组播路径跟踪方法、装置及系统 Download PDF

Info

Publication number
WO2012103694A1
WO2012103694A1 PCT/CN2011/075912 CN2011075912W WO2012103694A1 WO 2012103694 A1 WO2012103694 A1 WO 2012103694A1 CN 2011075912 W CN2011075912 W CN 2011075912W WO 2012103694 A1 WO2012103694 A1 WO 2012103694A1
Authority
WO
WIPO (PCT)
Prior art keywords
multicast
state
useredge
layer
port instance
Prior art date
Application number
PCT/CN2011/075912
Other languages
English (en)
French (fr)
Other versions
WO2012103694A9 (zh
Inventor
周正斌
Original Assignee
华为技术有限公司
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 华为技术有限公司 filed Critical 华为技术有限公司
Priority to CN201180000900.0A priority Critical patent/CN102265554B/zh
Priority to PCT/CN2011/075912 priority patent/WO2012103694A1/zh
Publication of WO2012103694A1 publication Critical patent/WO2012103694A1/zh
Publication of WO2012103694A9 publication Critical patent/WO2012103694A9/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast

Definitions

  • the present invention relates to the field of communications, and in particular, to a Layer 2 multicast path tracking method, apparatus, and system. Background technique
  • IP multicast is to transmit IP data packets to hosts located in a multicast group according to the principle of maximum delivery by using a specific IP multicast address. IP multicast working at the data link layer is usually called Layer 2 Multicast.
  • Layer 2 multicast you can learn which ports of the switch are connected to a multicast group by listening to/blocking the IGMP (Internet Group Management Protocol) packets exchanged between the multicast router and the host. The member of the group member only sends multicast data to these ports, thus realizing the forwarding of multicast data in the Layer 2 network.
  • IGMP Internet Group Management Protocol
  • the device forwarding node is used to track the multicast forwarding path of the multicast data between the multicast router and the group member host, so that the multicast forwarding path of the multicast data can be learned.
  • the embodiment of the invention provides a method, device and system for tracking a layer 2 multicast path.
  • the technical solution is as follows:
  • a Layer 2 multicast path tracking method where the method includes:
  • the path tracking request packet is added, and the MAC address of the device is added to the path tracking request packet, and the NetPath shape is obtained from the path tracking request packet.
  • the mode of the port corresponds to the multicast path information of the device corresponding to the user interface state port instance, and the multicast path information is sent to the query device.
  • a Layer 2 multicast path tracking device includes:
  • An obtaining module configured to obtain a path tracking request packet
  • a judging module configured to determine a port instance status of a multicast member port of the Layer 2 multicast forwarding table
  • a first processing module configured to: when a non-UserEdge state exists in the port instance state, add a media access control MAC address of the device to the path tracking request packet, and send the adding by using the port instance in the non-UserEdge state Path tracking request message of the MAC address to the downstream device;
  • the second processing module is configured to: when the port instance status is a UserEdge state, the path tracking request packet is added, and the MAC address of the device is added to the path tracking request packet, and the path tracking request packet is obtained from the path tracking request packet.
  • the multicast path information is sent to the querying device from the multicast path information of the device corresponding to the device of the user state port instance.
  • a Layer 2 multicast path tracking system includes the foregoing Layer 2 multicast tracking device and the query device, where the query device is configured to receive a multicast from the NetEdge state port instance corresponding device to the UserEdge state port instance corresponding device. Path information.
  • the technical solution provided by the embodiment of the present invention has the beneficial effects of: obtaining a path tracking request packet by using a Layer 2 multicast device in the Layer 2 multicast, and after the corresponding judgment processing, the MAC address of the device is obtained.
  • the information is added to the path tracking request packet and is sent to the end of the path tracking request packet.
  • the request packet contains the multicast path information from the device corresponding to the NetEdge state port instance to the device corresponding to the user edge state port instance.
  • the operation and maintenance costs are reduced and the efficiency is improved.
  • FIG. 1 is a flowchart of a method for tracking a Layer 2 multicast path according to Embodiment 1 of the present invention
  • FIG. 2 is a flowchart of a method for tracking a Layer 2 multicast path provided in Embodiment 2 of the present invention
  • FIG. 3 is a flowchart of an embodiment of a method for acquiring a path tracking request packet according to Embodiment 3 of the present invention
  • FIG. 1 is a flowchart of a method for tracking a Layer 2 multicast path according to Embodiment 1 of the present invention
  • FIG. 2 is a flowchart of a method for tracking a Layer 2 multicast path provided in Embodiment 2 of the present invention
  • FIG. 3 is a flowchart of an embodiment of a method for acquiring a path tracking request packet according to Embodiment 3 of the present invention
  • FIG. 4 is a flowchart of an embodiment of a method for acquiring a path tracking request packet according to Embodiment 3 of the present invention
  • Figure 5 is a flowchart of an embodiment of a Layer 2 multicast path tracking method according to Embodiment 4 of the present invention
  • 6 is a flowchart of an embodiment of a method for dynamically setting a UserEdge state or a non-UserEdge state port instance according to Embodiment 4 of the present invention
  • FIG. 7 is a schematic diagram of a format of an IGMPvl Report message provided in Embodiment 4 of the present invention.
  • FIG. 8 is a schematic diagram of a format of an IGMPv2 Report/Leave message according to Embodiment 4 of the present invention.
  • FIG. 9 is a schematic diagram of a format of an IGMPv3 Report message provided in Embodiment 4 of the present invention.
  • FIG. 10 is a schematic diagram of networking for dynamically setting a port instance according to Embodiment 4 of the present invention.
  • FIG. 11 is a schematic diagram of a networking diagram of a method for processing a Layer 2 multicast mtrace packet according to Embodiment 5 of the present invention
  • FIG. 12 is a schematic diagram of an embodiment of a Layer 2 multicast path tracking apparatus according to Embodiment 6 of the present invention
  • FIG. 13 is a schematic structural diagram of an embodiment of a Layer 2 multicast path tracking apparatus according to Embodiment 7 of the present invention
  • FIG. 14 is a schematic diagram of a Layer 2 multicast path tracking apparatus according to Embodiment 8 of the present invention;
  • FIG. 14b is a second schematic structural diagram of an embodiment of a Layer 2 multicast path tracking apparatus according to Embodiment 8 of the present invention.
  • Figure 15a is a schematic structural diagram of an embodiment of a Layer 2 multicast path tracking apparatus according to Embodiment 9 of the present invention
  • Figure 15b is a structure of an embodiment of a Layer 2 multicast path tracking apparatus according to Embodiment 9 of the present invention
  • FIG. 16 is a schematic structural diagram of an embodiment of a layer 2 multicast path tracking system according to Embodiment 10 of the present invention.
  • the embodiment of the invention provides a method, device and system for tracking a layer 2 multicast path.
  • the mtrace message of the Layer 2 multicast includes the information fields of the Layer 2 multicast, such as: multicast source, multicast group, multicast media access control (MAC, Media Access Control) address, and system MAC address.
  • the mtrace message of the Layer 2 multicast includes a path tracking query (Query) message, a path tracking request (Request) message, and a path tracking response (Response) message.
  • FIG. 1 is a flowchart of an embodiment of a method for tracking a layer 2 multicast path according to Embodiment 1 of the present invention.
  • the Layer 2 multicast path tracking method includes:
  • the obtaining the path tracking request packet includes: Receiving a path tracking query message sent by the querying device;
  • the path tracking query packet is modified into a path tracking request packet.
  • the obtaining the path tracking request packet includes: receiving the path tracking request sent by the upstream Layer 2 multicast device Message.
  • S102 Determine the port instance status of the multicast member port in the Layer 2 multicast forwarding table. When there is a non-UserEdge state in the port instance state, execute S103; when the port instance status is UserEdge state, execute S 104.
  • S103 Add a medium access control MAC address of the device to the path tracking request message, and send the path tracking request message with the added MAC address to the downstream device by using the port instance in the non-UserEdge state.
  • S104 Terminate the path tracking request packet, add the MAC address of the device to the path tracking request packet, and obtain, from the path tracking request packet, the device corresponding to the NetEdge state port instance corresponding device to the UserEdge state port instance.
  • the multicast path information of the device sends the multicast path information to the querying device.
  • the Layer 2 multicast device in the Layer 2 multicast device obtains the path tracking request packet, and adds the MAC address of the device to the path tracking request packet after the corresponding judgment process.
  • the path tracking request packet includes the multicast path information from the corresponding device of the NetEdge state port instance to the device corresponding to the user edge state port instance.
  • FIG. 2 is a flowchart of a method for tracking a Layer 2 multicast path according to Embodiment 2 of the present invention.
  • the Layer 2 multicast path tracking method includes:
  • S201 Set a port instance status of the layer 2 multicast device, where the port instance status includes: a network edge edge NetEdge state, a user edge edge UserEdge state, and a non-UserEdge state.
  • the Layer 2 multicast device can be directly connected to the host or directly connected to other Layer 2 multicast devices. Therefore, the port or virtual local area network (Vlan) can be used as the host or Layer 2.
  • the interface of the multicast device; the NetEdge state, the UserEdge state, and the non-UserEdge state are all based on the port or the Vlan port.
  • the port or the Vlan port is collectively referred to as a port instance.
  • the port instance in the NetEdge state is mainly used to terminate the path tracking query packet, and send the path tracking request packet to prevent the path query message from being forwarded in the Layer 2 multicast network.
  • the non-UserEdge state port instance is mainly The device is configured to forward the Layer 2 multicast mtrace packet.
  • the UserEdge state port instance is used to terminate the path tracking request packet and send the path tracking response packet to prevent the path request packet from being infinitely in the Layer 2 multicast network. Forward.
  • the number of Layer 2 multicast devices connected to the multicast source or multicast router is small. You can directly set the port instance of the Layer 2 multicast device to the NetEdge state. Specifically, you can specify direct connection to upstream multicast.
  • the port instance status of the Layer 2 multicast device of the source or multicast router is the NetEdge state.
  • the method of setting the port instance state of the Layer 2 multicast device to the NetEdge state is not limited to this method, and details are not described herein.
  • the obtaining the path tracking request packet is the Layer 2 multicast device corresponding to the NetEdge port instance, the obtaining the path tracking request packet includes:
  • the path tracking query packet is modified into a path tracking request packet.
  • the obtaining the path tracking request packet includes: receiving the path tracking request sent by the upstream Layer 2 multicast device Message.
  • S203 Determine the port instance status of the multicast member port in the Layer 2 multicast forwarding table.
  • S204 When the non-UserEdge state exists in the port instance state, perform S204; when the port instance status is the UserEdge state. , execute S205.
  • Each Layer 2 multicast device has a Layer 2 multicast forwarding table.
  • the Layer 2 multicast forwarding table stores multicast member ports of its own device. The multicast member ports directly or indirectly connect to group member hosts. .
  • the specific form of the Layer 2 multicast forwarding table is similar to the prior art and will not be described here.
  • the port instance state of the multicast member port is stored in the port instance state set.
  • the port instance state set is mainly used to store port instance state information of all multicast member ports on the Layer 2 multicast device.
  • S204 Add a media access control MAC address of the device to the path tracking request message, and send the path tracking request message with the added MAC address to the downstream device by using the port instance in the non-UserEdge state.
  • S205 Terminate the path tracking request packet, and add the MAC address of the device to the path tracking request packet.
  • the multicast path information from the device corresponding to the NetEdge state port instance to the device corresponding to the user interface state port instance is obtained from the path tracking request message, and the multicast path information is sent to the query device.
  • obtaining the multicast path information from the corresponding device of the NetEdge state port instance to the device corresponding to the UserEdge state port instance that is, obtaining a group from the multicast source or the multicast router to the group member host Broadcast forwarding path information.
  • the Layer 2 multicast device in the Layer 2 multicast device obtains the path tracking request packet, and adds the MAC address of the device to the path tracking request packet after the corresponding judgment process.
  • the path tracking request packet includes the multicast path information from the corresponding device of the NetEdge state port instance to the device corresponding to the user edge state port instance.
  • the operation and maintenance is reduced. Cost, increased efficiency.
  • the Layer 2 multicast device may be a Layer 2 multicast switch or other Layer 2 multicast device.
  • the embodiment of the present invention is not limited thereto. The following Embodiment 3 and Embodiment 4 are mainly described in detail by taking a Layer 2 multicast switch as an example.
  • FIG. 3 is a flowchart of a method for tracking a Layer 2 multicast path according to Embodiment 3 of the present invention.
  • the Layer 2 multicast path tracking method includes:
  • S301 Set a port instance status of the switch device, where the port instance status includes: a NetEdge status, a UserEdge status, and a non-UserEdge status.
  • the port instance status of the switch device is the NetEdge state.
  • the method of setting the port instance state of the switch device to the NetEdge state is not limited to this method, and will not be described herein.
  • the user interface status port instance or non-UserEdge status port instance of the switch device can also be statically set. Specifically, you can specify that the port instance status of the switch device directly connected to the downstream switch device is non-UserEdge. You can specify that the switch device directly connects to the downstream device. The port instance status of the host is UserEdge.
  • the executor in this embodiment may be any switch device in the Layer 2 network. If the executor is the switch device corresponding to the NetEdge state port instance, refer to FIG. 4, which is provided in Embodiment 3 of the present invention.
  • a flowchart of the method for obtaining a path tracking request packet, where the acquiring the path tracking request packet includes: S302a: Receive a path tracking query message sent by the querying device.
  • the query device sends a path tracking query message to the upstream switch device through the router interface.
  • the path tracking query packet is forwarded to the NetEdge state port instance through the router interface through the router interface.
  • Corresponding switch device Corresponding switch device.
  • the source MAC address of the Layer 2 header of the path tracking query packet is the MAC address of the device, that is, the MAC address of the device, and the source address of the IP packet carried by the path tracking query packet is an arbitrary address.
  • the address is the group address to be queried; the mtrace message type is Query, which encapsulates the multicast information to be queried: (S, G), (*, G) or (GMAC).
  • S302b Modify the path tracking query message to a path tracking request message.
  • the switch device corresponding to the NetEdge state port instance After receiving the path tracking query packet, the switch device corresponding to the NetEdge state port instance changes the mtrace packet type from Query to Request, and adds the MAC address of the query device and the MAC address of the device to the path tracking request packet.
  • the source MAC address of the Layer 2 header of the path tracking query packet is changed to the MAC address of the device, and the MAC address of the device is the MAC address of the switch device corresponding to the NetEdge state port instance.
  • the acquiring the request message includes: receiving the path tracking request packet sent by the upstream switch device.
  • the path tracking request packet is received by the non-UserEdge state port instance of the upstream switch device, where the path tracking request packet includes the switch device corresponding to the NetEdge state port instance to the previous hop switch of the device. Multicast path information.
  • S303 Determine a port instance status of the multicast member port in the Layer 2 multicast forwarding table.
  • S304 When the non-UserEdge state exists in the port instance state, perform S304; when the port instance status is the UserEdge state. , execute S305.
  • the device in the Layer 2 multicast device queries the Layer 2 multicast forwarding table on the device to determine the port of the multicast member port in the Layer 2 multicast forwarding table.
  • S304 when the non-UserEdge state exists in the port instance state, S304 is performed; when the port instance state is the UserEdge state, S305 is performed.
  • S304 Add a MAC address of the device to the path tracking request packet, and send the path tracking request packet with the added MAC address to the downstream device by using the port instance in the non-UserEdge state.
  • S305 Add a path tracking request packet, add a MAC address of the device to the path tracking request packet, and obtain, from the path tracking request packet, a device from the NetEdge state port instance corresponding device to the UserEdge state port.
  • the instance corresponds to the multicast path information of the device, and sends the multicast path information to the query device.
  • the path tracking request message includes the multicast path information from the switch device corresponding to the NetEdge state port instance to the switch device corresponding to the user edge state port instance; the multicast path information is obtained from the request packet and sent to the The device is queried, and the multicast path information is displayed by the query device.
  • obtaining the multicast path information from the corresponding device of the NetEdge state port instance to the device corresponding to the UserEdge state port instance that is, obtaining a group from the multicast source or the multicast router to the group member host Broadcast forwarding path information.
  • each hop switch device in the Layer 2 multicast device obtains the path tracking request packet, and after the corresponding judgment process, adds the MAC address of the device to the path tracking request packet, and then delivers the packet.
  • the path tracking request packet is terminated, and the path tracking request packet includes the multicast path information from the switch device corresponding to the NetEdge state port instance to the switch device corresponding to the user edge state port instance. Compared with the prior art, the operation and maintenance is reduced. Cost, increased efficiency.
  • FIG. 5 is a flowchart of a method for tracking a Layer 2 multicast path according to Embodiment 4 of the present invention, where the method for tracking a Layer 2 multicast path includes:
  • S501 Set a port instance status of the switch device, where the port instance status includes: a NetEdge status, a UserEdge status, and a non-UserEdge status.
  • the setting method of the NetEdge state, the UserEdge state, or the non-UserEdge state of the switch device port instance in this embodiment is similar to the setting method of the NetEdge state, the UserEdge state, or the non-UserEdge state of the switch device port instance in Embodiment 3.
  • S301 The method is set and will not be described here.
  • Settings for the UserEdge state or non-UserEdge state of the switch device port instance can also be dynamically set.
  • the method for obtaining the path tracking request packet in the embodiment is similar to the method for obtaining the path tracking request packet in S302. For details, refer to S302, and details are not described herein.
  • S503 Determine whether the non-UserEdge state exists in the port instance state of the multicast member port in the Layer 2 multicast forwarding table. If yes, execute S504, if no, execute S505.
  • the device in the Layer 2 multicast device queries the Layer 2 multicast forwarding table to determine whether the port instance status of the multicast member port in the Layer 2 multicast forwarding table is The non-UserEdge is present State, if it exists, execute S504, if it does not exist, execute S505.
  • S504 Add a MAC address of the device to the path tracking request packet, and send the path tracking request packet with the added MAC address to the downstream device by using the port instance in the non-UserEdge state.
  • the MAC address of the device is added to the path tracking request packet, and the port instance in the non-UserEdge state is along the multicast forwarding table.
  • the downstream switch device sends the path tracking request message with the added MAC address.
  • the path tracking request message includes multicast path information from the switch device corresponding to the NetEdge state port instance to the own device, because the MAC address of the device is added to the path tracking request message.
  • the path tracking request packet is not forwarded to the port instance in the UserEdge state to prevent the path tracking packet from being forwarded. To the host, the path tracking request packet needs to be forwarded only to the port instance that is not in the UserEdge state.
  • S505 Determine whether the state of the port instance of the multicast member requesting multicast in the multicast forwarding table is the UserEdge state, and if yes, execute S506.
  • S506 Add a path tracking request packet, add a MAC address of the device to the path tracking request packet, and obtain, from the path tracking request packet, a device from the NetEdge state port instance corresponding device to the UserEdge state port.
  • the instance corresponds to the multicast path information of the device, and sends the multicast path information to the query device.
  • the path tracking request message includes multicast path information from the switch device corresponding to the NetEdge state port instance to the switch device corresponding to the UserEdge state port instance.
  • the multicast path information of the corresponding device is displayed. Specifically, the mtrace packet type is modified from the Request to the Response, and the destination MAC address of the Layer 2 header of the path tracking response packet is modified to the MAC address of the query device.
  • the layer network unicasts the path tracking response packet, where the path tracking response packet includes multicast path information from the switch device corresponding to the NetEdge state port instance to the switch device corresponding to the user edge state port instance. .
  • the querier device After receiving the path tracking response packet, the querier device terminates the path tracking response packet, and obtains, from the path tracking response packet, the switch device corresponding to the NetEdge state port instance to the switch corresponding to the UserEdge state port instance.
  • the multicast path information of the device displays the multicast member information in the order from the switch device corresponding to the NetEdge state port instance to the downstream switch device.
  • obtaining the multicast path information from the corresponding device of the NetEdge state port instance to the device corresponding to the UserEdge state port instance that is, obtaining a group from the multicast source or the multicast router to the group member host Broadcast forwarding path information.
  • FIG. 6 is a flowchart of a method for dynamically setting a UserEdge state or a non-UserEdge state port instance according to Embodiment 4 of the present invention. Specifically include:
  • S601a Sets the port instance status of the downstream Layer 2 multicast device to the UserEdge state.
  • S601b Receives an IGMP report message or a Leave message, and modifies a Layer 2 multicast forwarding table of the device according to the IGMP report message or the Leave message.
  • the IGMP Report message or the Leave message is an IGMPvl/v2/v3 Report (Report) message or an IGMPv2 Leave message.
  • the packets can only be sent by the host, and the IGMP messages are linear when they pass through each switch. There is only one copy from the bottom to the top. Therefore, the switch device that receives the IGMP messages first is connected to the host. The most recent Layer 2 multicast switch device.
  • the host When the host sends an IGMP Report message, the host requests to join the multicast group. When the host sends an IGMP Leave message, the host requests to leave the multicast group.
  • each hop switch device After receiving the IGMP report message or the leaving message, each hop switch device modifies the Layer 2 multicast forwarding table of the device according to the IGMP report message or the leaving message. Specifically, if the IGMP report message is received, The port that receives the IGMP report message is added to the multicast member port of the Layer 2 multicast forwarding table of the device. If the IGMP Leave message is received, the port that receives the IGMP Leave message is the Layer 2 of the device. The multicast member port of the multicast forwarding table is deleted.
  • S601c Determine whether the flag Flag value in the IGMP report message or the leaving message is consistent with the flagset value set by the device itself. If yes, execute S601d, if no, execute S601e.
  • the flag value may be stored in any one of the following manners, specifically:
  • the Option field added in the IGMP report message or the IP packet carried in the Leave message is used to store the Flag value, that is, the Flag value is stored in the newly added Option field;
  • the insertion position of the Option field is located after the packet header of the IP packet, and is used to record the system MAC address + port instance of the local node.
  • FIG. 7 is a schematic diagram of a format of an IGMPv1 Report message according to Embodiment 4 of the present invention
  • FIG. 8 is a schematic diagram of a format of an IGMPv2 Report Leave message according to Embodiment 4 of the present invention. This hair A schematic diagram of the format of the IGMPv3 Report message provided in Embodiment 4 is shown.
  • the second field in the header of the IGMPvl Report message in Figure 7 is described in RFC1112: The unused area is 0 when transmitted, and is ignored when receiving.
  • the second field in the header of the IGMPv2 Report Leave message in Figure 8 is described in RFC2236: The maximum response time area is meaningful only in the membership query message. In all other messages, when sending 0, ignored when receiving.
  • the second field in the header of the IGMPv3 Rep 0 rt message in Figure 9 is described in RFC 3376: The reserved area is set to 0 when transmitted and ignored when received.
  • the second field in the header of the IGMPvl/v2/v3 Iteport packet or the IGMPv2 Leave packet is the second in the header of the IGMPvl/v2/v3 Iteport packet or the IGMPv2 Leave packet.
  • the fields are all 0s when they are sent, and are ignored when they are received. Therefore, the field can be reused for other purposes. Therefore, this embodiment multiplexes the second field in the header of the IGMP report message or the message leaving the message. Store the Flag value.
  • the value of the Flag in the IGMP Report message or the Leave message sent by the host is zero.
  • the host device may send an IGMP report message or a leave message that does not comply with the protocol.
  • the flag value of the IGMP report message or the leave message that does not comply with the protocol is non-zero.
  • the flagset value set by the device itself is zero, and the flagset value can be regarded as the flag value in the IGMP trusted by the device.
  • the flag value of the IGMP report message or the leaving message is the same as the flag set value (zero) set by the device, the IGMP report message or the leaving message is sent by the host.
  • S601d The UserEdge state of the port instance remains unchanged, and the flag value is modified to a first non-zero value, and the modified IGMP report message or the leaving message is sent to the upstream switch device.
  • the value of the flag in the IGMP report message or the leave message is zero, that is, the IGMP report message or the leave message is sent by the host and received by the switch device port instance closest to the host, The user edge state of the switch device port instance that is closest to the host is unchanged, and the value of the flag is changed from zero to the first non-zero value, and the modified IGMP report message or the leaving message is sent to the upstream switch device.
  • S601e Modify the flagset value to a predetermined Flagset value, determine whether the Flag value is consistent with the predetermined Flagset value, and if yes, execute S601f, if no, execute S601g.
  • the IGMP report message or the leave message may be an IGMP message sent by the host device that does not comply with the protocol. It is an IGMP message modified by the downstream switch device. Therefore, after the Flagset value is modified, the value of the Flagset value is determined, and then the judgment is performed to perform corresponding processing.
  • the predetermined Flagset value is an empirical value of the flag value in the IGMP message sent by the host that does not comply with the protocol.
  • S601f The UserEdge state of the port instance remains unchanged, and the flag value is modified to a second non-zero value, and the modified IGMP report message or the leaving message is sent to the upstream switch device. If the value of the Flag is the same as the value of the predetermined Flagset, that is, the IGMP message is an IGMP message sent by the host that does not comply with the protocol, so the UserEdge state of the port instance remains unchanged. The value of the flag is modified to a second non-zero value, and the modified IGMP report message or the leaving message is sent to the upstream switch device.
  • the first non-zero value in S601d and the second non-zero value in S601f are any non-zero value other than the predetermined Flagset value.
  • S601g The UserEdge state of the port instance is changed to a non-UserEdge state, and the flag value is unchanged, and the IGMP report message or the leaving message is sent to the upstream switch device.
  • the IGMP message is an IGMP message modified by the downstream switch device, so that the UserEdge state of the port instance is changed to a non-UserEdge state.
  • the value of the Flag is unchanged, and the IGMP Report message or the Leave message is sent to the upstream switch device.
  • the IGMP report message or the leave message is forwarded to the NetEdge status port instance one by one.
  • the NetEdge status port instance corresponds to the switch device to restore the flag in the IGMP report message or the leave message to zero and then send it to the group. Broadcast router or multicast source.
  • the S601c may not determine whether the flagged flag value in the IGMP report message or the leaving message is consistent with the Flagset value set by the device itself, but directly determines the IGMP report message or the leaving message. If the Flag value is zero, if S601d is executed, if S601e is executed, the corresponding S601e may be replaced by a subordinate scheme. Specifically, S601e: determining whether the Flag value is consistent with the predetermined value, and if yes, executing S601f If not, executing S601g, where the predetermined value is an empirical value of the Flag value in the IGMP message sent by the host that does not comply with the protocol.
  • the switches in Layer 2 multicast determine the UserEdge status or non-port of the port instance.
  • FIG. 10 is a networking diagram of a dynamic setting port instance provided in Embodiment 4 of the present invention.
  • each hop switch device in the Layer 2 multicast device obtains the path tracking request packet, and after the corresponding judgment process, adds the MAC address of the device to the path tracking request packet, and then delivers the packet.
  • the path tracking request packet is terminated, and the path tracking request packet includes the multicast path information from the switch device corresponding to the NetEdge state port instance to the switch device corresponding to the user edge state port instance. Compared with the prior art, the operation and maintenance is reduced. Cost, increased efficiency.
  • FIG. 11 is a schematic diagram of a networking diagram of a method for processing a Layer 2 multicast mtrace packet according to Embodiment 5 of the present invention, where a dotted arrow indicates a path of a path tracking query message, and a solid arrow indicates a path tracking request.
  • the switch 1 is the NetEdge status port instance corresponding device, and the switch 4 is the query device;
  • the user includes: user 1, user 2, user 3, and user 4, where User 1, User 2, and User 3 are group member hosts, User 4 is not a group member host;
  • Port 5s of Switch 5 directly connected to User 1 and User 2 are in the UserEdge state, and the port of Switch 6 directly connected to User 3
  • the instance state is the UserEdge state, and the port instance state of the switch 2 connected to the user 4 is the UserEdge state.
  • the path of the path tracking query message in Figure 11 is as follows: Switch 4 passes through switch 2 to switch 1; the path of the path tracking request message is: Switch 1 through switch 2 to switch 5, switch 1 through switch 3 to switch 6; The path of the path tracking response message is: by switch 5 via switch 2 to switch 4, by switch 6 via switch 3, switch 1 switch 2 to switch 4.
  • each hop switch device in the Layer 2 multicast device obtains the path tracking request packet, and after the corresponding judgment processing, adds the MAC address of the device to the path tracking request packet, and finally delivers the packet.
  • the query device displays the multicast path information from the switch device corresponding to the NetEdge state port instance to the switch device corresponding to the UserEdge state port instance.
  • the foregoing embodiment of the present invention is mainly directed to the description of the IGMP-S protocol.
  • the process of the IGMP-P protocol is similar to the IGMP-S protocol.
  • the mtrace parameter may be extended, for example: adding IPv6 information to track the data flow forwarded by the IPv6; or adding a field in the path tracking request message to indicate each Layer 2 multicast status on the switch device (such as Layer 2 multicast settings: IGMP/MLD (Multicast Listener Discovery Protocol) Snooping static group; or existing multicast member information) to implement multicast. Operation, Administration and Maintenance (0AM).
  • Layer 2 multicast settings such as Layer 2 multicast settings: IGMP/MLD (Multicast Listener Discovery Protocol) Snooping static group; or existing multicast member information
  • FIG. 12 is a schematic structural diagram of an embodiment of a Layer 2 multicast path tracking apparatus according to Embodiment 6 of the present invention, where the Layer 2 multicast path tracking apparatus includes:
  • the obtaining module 102 is configured to obtain a path tracking request message.
  • the determining module 103 is configured to determine a port instance status of the multicast member port of the Layer 2 multicast forwarding table.
  • the first processing module 104 is configured to: when a non-UserEdge state exists in the port instance state, add a media access control MAC address of the device to the path tracking request packet, and send the message through the port instance in the non-UserEdge state.
  • a path tracking request packet with a MAC address is added to the downstream device.
  • the second processing module 105 is configured to: when the port instance status is in the UserEdge state, the path tracking request packet, add the MAC address of the device to the path tracking request packet, and track the request packet from the path. And obtaining the multicast path information from the device corresponding to the NetEdge state port instance to the device corresponding to the user interface state port instance, and sending the multicast path information to the query device.
  • the Layer 2 multicast device in the Layer 2 multicast device obtains the path tracking request packet, and after the corresponding judgment process, adds the MAC address of the device to the path tracking request packet.
  • the path tracking request packet includes the multicast path information from the corresponding device of the NetEdge state port instance to the device corresponding to the UserEdge state port instance.
  • FIG. 13 is a schematic structural diagram of an embodiment of a Layer 2 multicast path tracking apparatus according to Embodiment 7 of the present invention, where the Layer 2 multicast path tracking apparatus includes:
  • the setting module 101 is configured to set a port instance status of the layer 2 multicast device, where the port instance status includes: a network edge edge NetEdge state, a user edge edge UserEdge state, and a non-UserEdge state.
  • the number of Layer 2 multicast devices connected to the multicast source or multicast router is small. You can directly set the port instance status of the Layer 2 multicast device to the NetEdge state. Specifically, you can specify the direct connection to the upstream group.
  • the port instance status of the Layer 2 multicast device of the broadcast source or multicast router is in the NetEdge state.
  • the method of setting the port instance status of the Layer 2 multicast device to the NetEdge state is not limited to this method, and is not described here.
  • the user interface status port instance or non-UserEdge status port instance of the Layer 2 multicast device can also be statically configured. Specifically, you can specify the port instance status of the downstream Layer 2 multicast device to be non-UserEdge. The port instance status of the host is UserEdge. Alternatively, you can also dynamically set the UserEdge status port instance or non-UserEdge status port instance of the Layer 2 multicast device.
  • the obtaining module 102 is configured to obtain a path tracking request message.
  • the determining module 103 is configured to determine a port instance status of the multicast member port of the Layer 2 multicast forwarding table.
  • the Layer 2 multicast device in the Layer 2 multicast device queries the Layer 2 multicast forwarding table to determine the port instance of the multicast member port in the Layer 2 multicast forwarding table. status.
  • the first processing module 104 is configured to: when the non-UserEdge state exists in the port instance state, add a media access control MAC address of the device to the path tracking request message, and send the port instance in the non-UserEdge state.
  • the second processing module 105 is configured to: when the port instance status is the UserEdge state, end path tracking Requesting a packet, adding a MAC address of the device to the path tracking request packet, and obtaining, from the path tracking request packet, a group from the NetEdge state port instance corresponding device to the user edge state port instance corresponding device Broadcast path information, and the multicast path information is sent to the querying device.
  • the Layer 2 multicast device in the Layer 2 multicast device obtains the path tracking request packet, and after the corresponding judgment process, adds the MAC address of the device to the path tracking request packet.
  • the path tracking request packet includes the multicast path information from the corresponding device of the NetEdge state port instance to the device corresponding to the UserEdge state port instance.
  • FIG. 14a is a first schematic structural diagram of an embodiment of a Layer 2 multicast path tracking apparatus according to Embodiment 8 of the present invention.
  • the Layer 2 multicast path tracking apparatus includes: a setting module 101, an obtaining module 102. , the determining module 103, the first processing module 104 and the second processing module 105;
  • the functions of the determining module 103, the first processing module 104, and the second processing module 105 are similar to those of the determining module 103, the first processing module 104, and the second processing module 105 in Embodiment 5, and are not Let me repeat.
  • the setting module 101 includes a first setting unit 1011 and a second setting unit 1012:
  • the first preset unit 1011 is configured to set a port instance state of the layer 2 multicast device to a NetEdge state.
  • the first setting unit 1011 includes:
  • the NetEdge setting sub-module is used to statically set the state of the port instance directly connected to the upstream multicast source or multicast router to the NetEdge state.
  • the second setting unit 1012 is configured to set a port instance status of the layer 2 multicast device to a UserEdge state or a non-
  • the second setting unit 1012 includes a UserEdge setting sub-module 1012a and a non-UserEdge setting sub-module 1012b:
  • the UserEdge setting sub-module 1012a is configured to statically set the port instance status of the Layer 2 multicast device to the UserEdge state, where the port instance state directly connected to the downstream host is the UserEdge state.
  • the non-UserEdge setting sub-module 1012b is configured to statically set the port instance status of the Layer 2 multicast device to be a non-UserEdge state, and the port instance state of the downstream Layer 2 multicast device is a non-UserEdge state.
  • the obtaining module 102 includes a first receiving unit 1021 and a first modifying unit 1022:
  • the first receiving unit 1021 is configured to receive a path tracking query message sent by the querying device.
  • the first modifying unit 1022 is configured to modify the path tracking query message to a Layer 2 multicast request message.
  • the acquiring module 102 includes a second receiving unit 1023, as shown in FIG. 14b, and FIG. 14b is a layer 2 group provided in Embodiment 8 of the present invention.
  • the second receiving unit 1023 is configured to receive a Layer 2 multicast request packet sent by the upstream Layer 2 multicast device.
  • the Layer 2 multicast device in the Layer 2 multicast device obtains the path tracking request packet, and after the corresponding judgment process, adds the MAC address of the device to the path tracking request packet.
  • the path tracking request packet includes the multicast path information from the corresponding device of the NetEdge state port instance to the device corresponding to the UserEdge state port instance. Compared with the prior art, the operation and maintenance cost is reduced and the efficiency is improved.
  • FIG. 15a is a first structural diagram of an embodiment of a Layer 2 multicast path tracking apparatus according to Embodiment 9 of the present invention
  • FIG. 15b is a second layer group provided in Embodiment 9 of the present invention
  • the layer 2 multicast path tracking device includes: a setting module 101, an obtaining module 102, a determining module 103, a first processing module 104, and a second processing module 105.
  • the determining module 103, the first processing module 104, and the The functions of the two processing modules 105 are similar to those of the determining module 103, the first processing module 104, and the second processing module 105 in Embodiment 7. For reference, refer to the related description in Embodiment 7, and details are not described herein again.
  • the setting module 101 includes a first setting unit 1011 and a second setting unit 1012, wherein the function of the first setting unit 1011 is similar to the function of the first setting unit 1011 in the embodiment 8. For details, refer to the embodiment. The related description in 8 is not repeated here.
  • the obtaining module 102 includes a first receiving unit 1021 and a first modifying unit 1022, wherein the functions of the first receiving unit 1021 and the first modifying unit 1022 and the first receiving unit 1021 and the first in Embodiment 8
  • the function of the modification unit 1022 is similar.
  • the acquiring module 102 includes a second receiving unit 1023, where the function and implementation of the second receiving unit 1023 are implemented.
  • the function of the second receiving unit 1023 in the example 8 is similar. For details, refer to the related description in Embodiment 8, and details are not described herein again.
  • the second setting unit 1012 may include: an initializing submodule 1012c, a first receiving submodule 1012d, a first determining submodule 1012e, a first processing submodule 1012f, a second determining submodule 1012g, a second processing submodule 1012h, The third processing sub-module 1012i:
  • the initialization sub-module 1012c is configured to set the port instance status of the downstream Layer 2 multicast device to the UserEdge state.
  • the first receiving submodule 1012d is configured to receive an Internet Group Management Protocol (IGMP) report message or leave the message, according to Modifying the Layer 2 multicast forwarding table of the device by using the IGMP report message or the leaving message;
  • IGMP Internet Group Management Protocol
  • the first determining sub-module 1012e is configured to determine whether the flag Flag value in the IGMP report message or the leaving message is consistent with the flagset value set by the device itself.
  • the first processing sub-module 1012f is configured to: when the determination result of the first determining module is yes, the UserEdge state of the port instance remains unchanged, and the flag value is modified to a first non-zero value, and the modified The IGMP report message or the leaving message to the upstream Layer 2 multicast device, where the first non-zero value is any non-zero value other than the predetermined Flagset value;
  • the second determining sub-module 1012g when the determining result of the first determining module is negative, modifying the Flagset value to the predetermined Flagset value, and determining whether the Flag value is consistent with the predetermined Flagset value;
  • the second processing sub-module 1012h is configured to: when the determination result of the second determining module is yes, the port instance
  • the UserEdge state is unchanged, the Flag value is modified to a second non-zero value, and the modified IGMP report message or the leaving message is sent to the upstream switch device, where the second non-zero value is in addition to the predetermined Any non-zero value other than the Flagset value;
  • the third processing sub-module 1012i is configured to: when the determination result of the second determining module is negative, modify the UserEdge state of the port instance to a non-UserEdge state, the Flag value does not change, and send the IGMP report message or Leave the packet to the upstream Layer 2 multicast device.
  • the Layer 2 multicast device in the Layer 2 multicast device obtains the path tracking request packet, and after the corresponding judgment process, adds the MAC address of the device to the path tracking request packet.
  • the path tracking request packet includes the multicast path information from the corresponding device of the NetEdge state port instance to the device corresponding to the UserEdge state port instance.
  • FIG. 16 is a schematic structural diagram of an embodiment of a Layer 2 multicast path tracking system according to Embodiment 10 of the present invention, where the Layer 2 multicast path tracking system includes:
  • the Layer 2 multicast path tracking device 11 is configured to obtain a path tracking request message, determine a port instance state of a multicast member port of the Layer 2 multicast forwarding table, and add a self device when the port instance state exists in a non-UserEdge state.
  • the media access control MAC address is sent to the path tracking request message, and the path tracking request message with the added MAC address is sent to the downstream device by the port instance of the non-UserEdge state; when the port instance status is UserEdge a device that adds a MAC address of the device to the path tracking request packet, and obtains, from the path tracking request packet, a device corresponding to the NetEdge state port instance to the user interface state port instance.
  • the multicast path information is sent to the querying device.
  • the querying device 22 is configured to receive multicast path information from the corresponding device of the NetEdge state port instance to the device corresponding to the UserEdge state port instance.
  • the Layer 2 multicast path tracking device 11 is further configured to set a port instance state of the Layer 2 multicast device, where the port instance states include: a network edge edge NetEdge state, a user edge edge UserEdge state, and a non-UserEdge state.
  • the port instance status of the Layer 2 multicast device is as follows:
  • the port instance status of the upstream multicast source or the multicast router is set to the NetEdge state.
  • the port instance status of the Layer 2 multicast device is set to the UserEdge state or the non-UserEdge state.
  • the port instance status of the directly connected downstream host is In the UserEdge state, the port instance status of the downstream Layer 2 multicast device is non-UserEdge.
  • Dynamically setting the port instance status of the Layer 2 multicast device to the UserEdge state or the non-UserEdge state including: setting the port instance status of the downstream Layer 2 multicast device to the UserEdge state; receiving the Internet Group Management Protocol IGMP Report message or The packet is discarded, and the Layer 2 multicast forwarding table of the device is modified according to the IGMP report message or the leaving message.
  • the flag of the IGMP report message or the leaving message is determined to be the default flag set of the device. The values are the same. If yes, the UserEdge state of the port instance remains unchanged. The value of the flag is changed to the first non-zero value, and the modified IGMP report message or the leaving message is sent to the upstream Layer 2 multicast.
  • modifying the Flagset value to a predetermined Flagset value determining whether the Flag value is consistent with the predetermined Flagset value, and if yes, the UserEdge state of the port instance remains unchanged, and the Flag value is The second non-zero value is modified, and the modified IGMP report message or the leaving message is sent to the upstream Layer 2 multicast device. If no, the user edge state of the port instance is changed to a non-UserEdge state, and the flag value is unchanged, and the IGMP report message or the leaving message is sent to the upstream Layer 2 multicast device; the first non-zero value And the second non-zero value is any non-zero value other than the predetermined Flagset value.
  • the Layer 2 multicast forwarding table of the device that is modified according to the IGMP report message or the leaving message is specifically: adding the port that receives the IGMP report message to the multicast of the Layer 2 multicast forwarding table of the device Member port: The port that receives the IGMP Leave message is deleted from the multicast member port of the Layer 2 multicast forwarding table of its own device.
  • the obtaining the path tracking request message includes:
  • the NetEdge state port instance corresponding device receives the path tracking query message sent by the querying device
  • the device corresponding to the NetEdge state port instance modifies the path tracking query packet to a path tracking request packet.
  • the obtaining the path tracking request message includes:
  • the device corresponding to the non-NetEdge state port instance receives the path tracking request packet sent by the upstream Layer 2 multicast device.
  • the query device 22 is further configured to send a path tracking query message to the layer 2 multicast tracking device.
  • a person skilled in the art may understand that all or part of the steps of implementing the above embodiments may be completed by hardware, or may be instructed by a program to execute related hardware, and the program may be stored in a computer readable storage medium.
  • the storage medium mentioned may be a read only memory, a magnetic disk or an optical disk or the like.

Landscapes

  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)

Abstract

本发明实施例公开了一种二层组播路径跟踪方法、装置及系统，属于通信领域。二层组播路径跟踪方法实施例包括：获取路径跟踪请求报文；判断二层组播转发表的组播成员端口的端口实例状态；当端口实例状态中存在非UserEdge状态，添加MAC地址至路径跟踪请求报文，经非UserEdge状态的端口实例发送路径跟踪请求报文至下游设备；当端口实例状态均为UserEdge状态，终结路径跟踪请求报文，将MAC地址添加至路径跟踪请求报文，从路径跟踪请求报文中获取从NetEdge状态端口实例对应设备到UserEdge状态端口实例对应设备的组播路径信息，将组播路径信息发送至查询设备。本发明实施例可以降低运维成本，提高效率。

Description

一种二层组播路径跟踪方法、 装置及系统 技术领域 本发明涉及通信领域， 特别涉及一种二层组播路径跟踪方法、 装置及系统。 背景技术
IP组播就是通过使用特定的 IP组播地址， 按照最大投递的原则， 将 IP数据包传输到 位于一个组播群组的主机； 通常把工作在数据链路层的 IP组播称为二层组播。 在二层组播 中， 通过侦听 /拦截组播路由器和主机之间交互的 IGMP ( Internet Group Management Protocol , 因特网组管理协议） 报文， 可以获知交换机的哪些端口下连接着一个组播群组 的组成员主机， 只将组播数据发送至这些端口， 从而实现了组播数据在二层网络中的转发。 在二层组播中， 如果想获知组播数据在组播路由器和组成员主机之间的组播转发路径， 主 要通过路径跟踪的方法来实现。
现有技术需通过命令行或逐台排查设备节点来跟踪组播数据在组播路由器和组成员主 机之间的组播转发路径， 从而可以获知组播数据的组播转发路径。
在实现本发明的过程中， 发明人发现现有技术至少存在以下问题： 庞大的二层组播网 络中涉及的组播设备太多， 现有技术中的路径跟踪方法使得运维成本增加， 效率降低。 发明内容
为了降低运维成本， 提高效率， 本发明实施例提供了一种二层组播路径跟踪方法、 装 置及系统。 所述技术方案如下：
一种二层组播路径跟踪方法， 所述方法包括：
获取路径跟踪请求报文；
判断二层组播转发表中组播成员端口的端口实例状态；
当所述端口实例状态中存在所述非 UserEdge状态， 添加自身设备的介质访问控制 MAC 地址至所述路径跟踪请求报文， 经所述非 UserEdge状态的端口实例发送所述添加了 MAC地 址的路径跟踪请求报文至下游设备；
当所述端口实例状态均为所述 UserEdge状态， 终结路径跟踪请求报文， 添加自身设备 的 MAC地址至所述路径跟踪请求报文， 从所述路径跟踪请求报文中获取从所述 NetEdge状 态端口实例对应设备到所述 UserEdge状态端口实例对应设备的组播路径信息， 将所述组播 路径信息发送至查询设备。
一种二层组播路径跟踪装置， 包括：
获取模块， 用于获取路径跟踪请求报文；
判断模块， 用于判断二层组播转发表的组播成员端口的端口实例状态；
第一处理模块， 用于当所述端口实例状态中存在非 UserEdge状态， 添加自身设备的介 质访问控制 MAC地址至所述路径跟踪请求报文， 经所述非 UserEdge状态的端口实例发送所 述添加了 MAC地址的路径跟踪请求报文至下游设备；
第二处理模块，用于当所述端口实例状态均为 UserEdge状态，终结路径跟踪请求报文， 添加自身设备的 MAC 地址至所述路径跟踪请求报文， 从所述路径跟踪请求报文中获取从 NetEdge状态端口实例对应设备到所述 UserEdge状态端口实例对应设备的组播路径信息， 将所述组播路径信息发送至查询设备。
一种二层组播路径跟踪系统， 包括上述二层组播跟踪装置和查询设备， 所述查询设备 用于接收从所述 NetEdge状态端口实例对应设备到所述 UserEdge状态端口实例对应设备的 组播路径信息。
本发明实施例提供的技术方案带来的有益效果是： 通过二层组播中的每一跳二层组播 设备获取路径跟踪请求报文， 经过相应的判断处理后， 将自身设备的 MAC地址添加到路径 跟踪请求报文中进行下发， 直到终结路径跟踪请求报文， 使得请求报文中包含了从 NetEdge 状态端口实例对应设备到 UserEdge状态端口实例对应设备的组播路径信息； 相比较现有技 术而言， 降低了运维成本， 提高了效率。 附图说明
为了更清楚地说明本发明实施例中的技术方案， 下面将对实施例描述中所需要使用的 附图作简单地介绍， 显而易见地， 下面描述中的附图仅仅是本发明的一些实施例， 对于本 领域普通技术人员来讲， 在不付出创造性劳动的前提下， 还可以根据这些附图获得其他的 附图。
图 1是本发明实施例 1中提供的一种二层组播路径跟踪方法实施例的流程图； 图 2是本发明实施例 2中提供的一种二层组播路径跟踪方法实施例的流程图； 图 3是本发明实施例 3中提供的一种二层组播路径跟踪方法实施例的流程图； 图 4是本发明实施例 3中提供的获取路径跟踪请求报文方法实施例的流程图； 图 5是本发明实施例 4中提供的一种二层组播路径跟踪方法实施例的流程图； 图 6是本发明实施例 4中提供的动态设置 UserEdge状态或非 UserEdge状态端口实例 的方法实施例的流程图；
图 7是本发明实施例 4中提供的 IGMPvl Report报文格式示意图；
图 8是本发明实施例 4中提供的 IGMPv2 Report/ Leave报文格式示意图；
图 9是本发明实施例 4中提供的 IGMPv3 Report报文格式示意图；
图 10是本发明实施例 4中提供的动态设置端口实例的组网示意图；
图 11是本发明实施例 5中提供的二层组播 mtrace报文处理方法实施例的组网示意图； 图 12是本发明实施例 6提供的一种二层组播路径跟踪装置实施例的结构示意图； 图 13是本发明实施例 7中提供的一种二层组播路径跟踪装置实施例的结构示意图； 图 14a是本发明实施例 8中提供的一种二层组播路径跟踪装置实施例的第一结构示意 图；
图 14b是本发明实施例 8中提供的一种二层组播路径跟踪装置实施例的第二结构示意 图；
图 15a是本发明实施例 9中提供的一种二层组播路径跟踪装置实施例的结构示意图； 图 15b是本发明实施例 9中提供的一种二层组播路径跟踪装置实施例的结构示意图； 图 16是本发明实施例 10中提供的一种二层组播路径跟踪系统实施例的结构示意图。 具体实施方式
本发明实施例提供一种二层组播路径跟踪方法、 装置及系统。
为使本发明的目的、 技术方案和优点更加清楚， 下面将结合附图对本发明实施方式作 进一步地详细描述。
发明实施例中二层组播的 mtrace报文包含二层组播的信息字段， 如： 组播源、组播组、 组播介质访问控制 （MAC, Media Access Control ) 地址和系统 MAC地址。 所述二层组播的 mtrace报文包括路径跟踪查询 （Query ) 报文、 路径跟踪请求 （Request ) 报文和路径跟踪 响应 ( Response ) 报文。
实施例 1
参考图 1，图 1为本发明实施例 1中提供的一种二层组播路径跟踪方法实施例的流程图。 所述二层组播路径跟踪方法包括：
S 101 : 获取路径跟踪请求报文。
当获取路径跟踪请求报文的执行主体是所述 NetEdge 状态端口实例对应的二层组播设 备时， 获取路径跟踪请求报文具体包括： 接收由查询设备发送的路径跟踪查询报文；
将所述路径跟踪查询报文修改为路径跟踪请求报文。
或者， 当获取路径跟踪请求报文的执行主体不是所述 NetEdge 状态端口实例对应的二 层组播设备时， 获取路径跟踪请求报文具体包括： 接收由上游二层组播设备发送的路径跟 踪请求报文。
S 102 : 判断二层组播转发表中组播成员端口的端口实例状态， 当所述端口实例状态中 存在非 UserEdge状态时，执行 S 103 ;当所述端口实例状态均为 UserEdge状态时，执行 S 104。
S 103 : 添加自身设备的介质访问控制 MAC 地址至所述路径跟踪请求报文， 经所述非 UserEdge状态的端口实例发送所述添加了 MAC地址的路径跟踪请求报文至下游设备。
S 104: 终结路径跟踪请求报文， 添加自身设备的 MAC地址至所述路径跟踪请求报文， 从所述路径跟踪请求报文中获取从 NetEdge状态端口实例对应设备到所述 UserEdge状态端 口实例对应设备的组播路径信息， 将所述组播路径信息发送至查询设备。
本实施例中， 二层组播中的每一跳二层组播设备获取路径跟踪请求报文， 经过相应的 判断处理后， 将自身设备的 MAC地址添加到路径跟踪请求报文中进行下发， 直到终结路径 跟踪请求报文， 使得路径跟踪请求报文中包含了从 NetEdge 状态端口实例对应设备到 UserEdge状态端口实例对应设备的组播路径信息； 相比较现有技术而言， 降低了运维成本， 提高了效率。 实施例 2
参考图 2 ,图 2为本发明实施例 2中提供的一种二层组播路径跟踪方法实施例的流程图。 所述二层组播路径跟踪方法包括：
S201 :设置二层组播设备的端口实例状态，所述端口实例状态包括：网络侧边缘 NetEdge 状态、 用户侧边缘 UserEdge状态和非 UserEdge状态。
在二层组播中， 二层组播设备既可以直接连接主机， 又可以直接连接其他的二层组播 设备， 因此端口或虚拟局域网 （Vlan， Virtual local area network ) 端口可以作为主机 或二层组播设备的接口； NetEdge状态、 UserEdge状态和非 UserEdge状态都是基于端口或 Vlan端口， 为了描述方便， 将端口或 Vlan端口统称为端口实例。
所述 NetEdge 状态的端口实例主要用于终结路径跟踪查询报文， 发送路径跟踪请求报 文， 防止路径查询报文被无限止的在二层组播网络中转发； 所述非 UserEdge状态端口实例 主要用于转发二层组播 mtrace报文； 所述 UserEdge状态端口实例主要用于终结路径跟踪 请求报文， 发送路径跟踪响应报文， 防止路径请求报文被无限止的在二层组播网络中转发。 在实际应用中， 由于连接组播源或组播路由器的二层组播设备较少， 所以可以直接静 态设置二层组播设备的端口实例为 NetEdge 状态， 具体地， 可以指定直接连接上游组播源 或组播路由器的二层组播设备的端口实例状态为 NetEdge状态。 对于本领域技术人员而言， 设置二层组播设备的端口实例状态为 NetEdge 状态的方法不仅仅局限于此方法， 在此不作 赘述。
对于二层组播设备的 UserEdge状态端口实例或非 UserEdge状态端口实例也可以进行 静态设置， 具体地， 可以指定二层组播设备上直接连接下游二层组播设备的端口实例状态 为非 UserEdge 状态， 可以指定二层组播设备上直接连接下游主机的端口实例状态为 UserEdge 状态； 或者， 也可以动态设置二层组播设备的 UserEdge 状态端口实例或非 UserEdge状态端口实例。
S202: 获取路径跟踪请求报文。
当获取路径跟踪请求报文的执行主体是所述 NetEdge 状态端口实例对应的二层组播设 备时， 获取路径跟踪请求报文具体包括：
接收由查询设备发送的路径跟踪查询报文；
将所述路径跟踪查询报文修改为路径跟踪请求报文。
或者， 当获取路径跟踪请求报文的执行主体不是所述 NetEdge 状态端口实例对应的二 层组播设备时， 获取路径跟踪请求报文具体包括： 接收由上游二层组播设备发送的路径跟 踪请求报文。
S203 : 判断二层组播转发表中组播成员端口的端口实例状态， 当所述端口实例状态中 存在所述非 UserEdge状态时， 执行 S204; 当所述端口实例状态均为所述 UserEdge状态时， 执行 S205。
每个二层组播设备上都有一个二层组播转发表， 所述二层组播转发表中存储着自身设 备的组播成员端口， 所述组播成员端口直接或间接连接组成员主机。 二层组播转发表的具 体形式与现有技术类似， 在此不再赘述。
所述组播成员端口的端口实例状态存储于端口实例状态集中， 所述端口实例状态集主 要用于存储二层组播设备上所有组播成员端口的端口实例状态信息。
S204: 添加自身设备的介质访问控制 MAC 地址至所述路径跟踪请求报文， 经所述非 UserEdge状态的端口实例发送所述添加了 MAC地址的路径跟踪请求报文至下游设备。
实际应用中， 下游设备接收所述添加了 MAC地址的路径跟踪请求报文后， 再循环执行 S203, 直至当所述端口实例状态均为所述 UserEdge状态时， 执行 S205。
S205: 终结路径跟踪请求报文， 添加自身设备的 MAC地址至所述路径跟踪请求报文， 从所述路径跟踪请求报文中获取从所述 NetEdge状态端口实例对应设备到所述 UserEdge状 态端口实例对应设备的组播路径信息， 将所述组播路径信息发送至查询设备。
实际应用中， 获取从所述 NetEdge状态端口实例对应设备到所述 UserEdge状态端口实 例对应设备的组播路径信息， 也就表示获取了从组播源或组播路由器到组成员主机之间的 组播转发路径信息。
本实施例中， 二层组播中的每一跳二层组播设备获取路径跟踪请求报文， 经过相应的 判断处理后， 将自身设备的 MAC地址添加到路径跟踪请求报文中进行下发， 直到终结路径 跟踪请求报文， 使得路径跟踪请求报文中包含了从 NetEdge 状态端口实例对应设备到 UserEdge状态端口实例对应设备的组播路径信息； 相比较现有技术而言， 降低了运维成本， 提高了效率。 在二层组播网络中， 二层组播设备可以是二层组播交换机， 也可以是其他二层组播设 备， 本发明实施例并不局限于此。 下述实施例 3和实施例 4主要以二层组播交换机为例进 行详细描述。
实施例 3
参考图 3，图 3为本发明实施例 3中提供的一种二层组播路径跟踪方法实施例的流程图。 所述二层组播路径跟踪方法包括：
S301 : 设置交换机设备的端口实例状态， 所述端口实例状态包括： NetEdge 状态、 UserEdge状态和非 UserEdge状态。
在实际应用中， 由于连接组播源或组播路由器的交换机设备较少， 所以可以直接静态 设置交换机设备的端口实例状态为 NetEdge 状态， 具体地， 可以指定直接连接上游组播源 或组播路由器的交换机设备的端口实例状态为 NetEdge 状态。 对于本领域技术人员而言， 设置交换机设备的端口实例状态为 NetEdge 状态的方法不仅仅局限于此方法， 在此不作赘 述。
对于交换机设备的 UserEdge状态端口实例或非 UserEdge状态端口实例也可以进行静 态设置， 具体地， 可以指定交换机设备上直接连接下游交换机设备的端口实例状态为非 UserEdge状态；可以指定交换机设备上直接连接下游主机的端口实例状态为 UserEdge状态。
S302: 获取路径跟踪请求报文。
本实施例中的执行主体可以是二层网络中的任一交换机设备， 如果执行主体是所述 NetEdge状态端口实例对应的交换机设备时， 参考图 4， 图 4为本发明实施例 3中提供的获 取路径跟踪请求报文方法实施例的流程图， 所述获取路径跟踪请求报文包括： S302a: 接收由查询设备发送的路径跟踪查询报文。
二层组播中， 查询设备通过路由器口向上游交换机设备发送路径跟踪查询报文， 所述 路径跟踪查询报文经过二层组播交换机设备通过路由器口一跳一跳地转发至 NetEdge 状态 端口实例对应的交换机设备。
其中， 所述路径跟踪查询报文的二层头的源 MAC为自身设备的 MAC地址， 即查询设备 的 MAC地址； 所述路径跟踪查询报文承载的 IP报文的源地址为任意地址， 目的地址为要查 询的组地址； mtrace报文类型为 Query,封装要查询的组播信息： （S， G)、 （*， G)或（GMAC)。
S302b : 将所述路径跟踪查询报文修改为路径跟踪请求报文。
NetEdge状态端口实例对应的交换机设备收到所述路径跟踪查询报文后， 将 mtrace报 文类型由 Query修改为 Request ,添加所述查询设备的 MAC地址和本设备的 MAC地址至路径 跟踪请求报文， 将所述路径跟踪查询报文的二层头的源 MAC地址修改为自身设备的 MAC地 址， 所述自身设备的 MAC地址为所述 NetEdge状态端口实例对应的交换机设备的 MAC地址。
如果执行主体不是所述 NetEdge 状态端口实例对应的交换机设备时， 所述获取请求报 文包括： 接收由上游交换机设备发送的路径跟踪请求报文。
实际应用中，通过上游交换机设备的非 UserEdge状态端口实例接收路径跟踪请求报文， 所述路径跟踪请求报文中包含从所述 NetEdge 状态端口实例对应的交换机设备到自身设备 的上一跳交换机的组播路径信息。
S303 : 判断二层组播转发表中组播成员端口的端口实例状态， 当所述端口实例状态中 存在所述非 UserEdge状态时， 执行 S304; 当所述端口实例状态均为所述 UserEdge状态时， 执行 S305。
二层组播中的每一跳交换机设备收到所述路径跟踪请求报文后， 查询自身设备上的二 层组播转发表， 判断所述二层组播转发表中组播成员端口的端口实例状态， 当所述端口实 例状态中存在所述非 UserEdge状态时，执行 S304; 当所述端口实例状态均为所述 UserEdge 状态时， 执行 S305。
S304: 添加自身设备的 MAC地址至所述路径跟踪请求报文， 经所述非 UserEdge状态的 端口实例发送所述添加了 MAC地址的路径跟踪请求报文至下游设备。
实际应用中， 下游设备接收所述添加了 MAC地址的路径跟踪请求报文后， 再循环执行 S303 , 直至当所述端口实例状态均为所述 UserEdge状态时， 执行 S305。
S305 : 终结路径跟踪请求报文， 将自身设备的 MAC地址添加至所述路径跟踪请求报文， 从所述路径跟踪请求报文中获取从所述 NetEdge状态端口实例对应设备到所述 UserEdge状 态端口实例对应设备的组播路径信息， 将所述组播路径信息发送至查询设备。 终结路径跟踪请求报文； 将自身设备的 MAC 地址添加到所述请求报文中， 即将所述 UserEdge状态端口实例对应的交换机设备的 MAC地址添加到所述路径跟踪请求报文中， 因 此所述路径跟踪请求报文包含了从所述 NetEdge 状态端口实例对应交换机设备到所述 UserEdge状态端口实例对应交换机设备的组播路径信息； 从所述请求报文中获取所述组播 路径信息并发送至查询设备， 由查询设备将所述组播路径信息进行显示。
实际应用中， 获取从所述 NetEdge状态端口实例对应设备到所述 UserEdge状态端口实 例对应设备的组播路径信息， 也就表示获取了从组播源或组播路由器到组成员主机之间的 组播转发路径信息。
在本实施例中， 二层组播中的每一跳交换机设备获取路径跟踪请求报文， 经过相应的 判断处理后， 将自身设备的 MAC地址添加到路径跟踪请求报文中进行下发， 直到终结路径 跟踪请求报文， 使得路径跟踪请求报文中包含了从 NetEdge 状态端口实例对应交换机设备 到 UserEdge状态端口实例对应交换机设备的组播路径信息； 相比较现有技术而言， 降低了 运维成本， 提高了效率。 实施例 4
参考图 5，图 5为本发明实施例 4中提供的一种二层组播路径跟踪方法实施例的流程图， 所述二层组播路径跟踪方法包括：
S501 : 设置交换机设备的端口实例状态， 所述端口实例状态包括： NetEdge 状态、 UserEdge状态和非 UserEdge状态。
本实施例中交换机设备端口实例的 NetEdge状态、 UserEdge状态或非 UserEdge状态的 设置方法和实施例 3中交换机设备端口实例的 NetEdge状态、 UserEdge状态或非 UserEdge 状态的设置方法类似， 具体可以参考 S301中的方法进行设置， 在此不再赘述。
对于交换机设备端口实例的 UserEdge状态或非 UserEdge状态的设置也可以进行动态 设置。
S502 : 获取路径跟踪请求报文。
本实施例中路径跟踪请求报文的获取方法和 S302 中路径跟踪请求报文的获取方法相 似， 具体可以参考 S302 , 在此不再赘述。
S503 : 判断二层组播转发表中组播成员端口的端口实例状态中是否存在所述非 UserEdge状态， 如果是， 执行 S504, 如果否， 执行 S505。
二层组播中的每一跳交换机设备收到所述路径跟踪请求报文后， 查询二层组播转发表， 判断所述二层组播转发表中组播成员端口的端口实例状态中是否存在所述非 UserEdge 状 态， 如果存在， 执行 S504， 如果不存在， 执行 S505。
S504: 添加自身设备的 MAC地址至所述路径跟踪请求报文， 经所述非 UserEdge状态的 端口实例发送所述添加了 MAC地址的路径跟踪请求报文至下游设备。
实际应用中，当所述端口实例状态中存在所述非 UserEdge状态时，添加自身设备的 MAC 地址至所述路径跟踪请求报文， 沿着组播转发表经所述非 UserEdge状态的端口实例向下游 交换机设备发送所述添加了 MAC地址的路径跟踪请求报文。 由于将自身设备的 MAC地址添 加至所述路径跟踪请求报文， 因此所述路径跟踪请求报文包含了从所述 NetEdge 状态端口 实例对应交换机设备到自身设备的组播路径信息。
如果请求组播的组播成员的端口实例状态中既有 UserEdge状态， 又有非 UserEdge状 态时， 则不需要向 UserEdge状态的端口实例转发所述路径跟踪请求报文， 防止路径跟踪报 文被转发至主机， 只需要向非 UserEdge状态的端口实例转发所述路径跟踪请求报文。
S505: 判断组播转发表中请求组播的组播成员的端口实例状态是否都为所述 UserEdge 状态， 如果是， 执行 S506。
S506: 终结路径跟踪请求报文， 将自身设备的 MAC地址添加至所述路径跟踪请求报文， 从所述路径跟踪请求报文中获取从所述 NetEdge状态端口实例对应设备到所述 UserEdge状 态端口实例对应设备的组播路径信息， 将所述组播路径信息发送至查询设备。
终结路径跟踪请求报文； 将自身设备的 MAC地址添加到所述路径跟踪请求报文中， 即 将所述 UserEdge 状态端口实例对应交换机设备的 MAC地址添加到所述路径跟踪请求报文 中， 因此所述路径跟踪请求报文包含从所述 NetEdge 状态端口实例对应交换机设备到所述 UserEdge状态端口实例对应交换机设备的组播路径信息。
将所述路径跟踪请求报文修改为路径跟踪响应报文， 发送所述路径跟踪响应报文至查 询设备， 由所述查询设备将从所述 NetEdge状态端口实例对应设备到所述 UserEdge状态端 口实例对应设备的组播路径信息进行显示； 具体地， 将 mtrace报文类型由 Request修改为 Response, 同时将路径跟踪响应报文的二层头的目的 MAC地址修改为查询设备的 MAC地址， 向整个二层网络单播转发所述路径跟踪响应报文， 其中， 所述路径跟踪响应报文中包含了 从所述 NetEdge状态端口实例对应交换机设备到所述 UserEdge状态端口实例对应交换机设 备的组播路径信息。
查询设备接收所述路径跟踪响应报文后， 终结所述路径跟踪响应报文； 从所述路径跟 踪响应报文中获取从所述 NetEdge状态端口实例对应交换机设备到所述 UserEdge状态端口 实例对应交换机设备的组播路径信息， 将组播成员信息按照从 NetEdge 状态端口实例对应 交换机设备到下游交换机设备的顺序进行显示。 实际应用中， 获取从所述 NetEdge状态端口实例对应设备到所述 UserEdge状态端口实 例对应设备的组播路径信息， 也就表示获取了从组播源或组播路由器到组成员主机之间的 组播转发路径信息。
对于交换机设备端口实例的 UserEdge状态或非 UserEdge状态的动态设置具体可以参 见图 6，图 6为本发明实施例 4中提供的动态设置 UserEdge状态或非 UserEdge状态端口实 例的方法实施例的流程图， 具体包括：
S601a: 将连接下游二层组播设备的端口实例状态均设置为 UserEdge状态。
S601b: 接收 IGMP报告报文或离开报文， 根据所述 IGMP报告报文或离开报文修改自身 设备的二层组播转发表。
在二层组播中， IGMP报告报文或离开报文具体为 IGMPvl/v2/v3报告 （Report ) 报文 或 IGMPv2离开 ( Leave) 报文， 所述 IGMPvl/v2/v3 Report报文或 IGMPv2 Leave报文只 能由主机发出， 并且这类 IGMP报文在经过每台交换机设备时都是线性的， 从下到上只有一 份， 因此最先收到这类 IGMP报文的交换机设备就是连接主机最近的二层组播交换机设备。
当主机发送 IGMP报告报文时， 表示主机申请加入组播群组； 当主机发送 IGMP离开报 文时， 表示主机申请离开组播群组。
每一跳交换机设备接收 IGMP报告报文或离开报文后， 根据所述 IGMP报告报文或离开 报文修改自身设备的二层组播转发表，具体地，如果接收的是 IGMP报告报文，则将接收 IGMP 报告报文的端口添加到自身设备的二层组播转发表的组播成员端口中； 如果接收的 IGMP离 开报文， 则将接收 IGMP离开报文的端口从自身设备的二层组播转发表的组播成员端口中删 除。
S601c: 判断所述 IGMP报告报文或离开报文中的标记 Flag值是否与自身设备默认设置 的 Flagset值一致， 如果是， 执行 S601d， 如果否， 执行 S601e。
所述 Flag值可以通过以下任一方式进行存储， 具体为：
1 ) 在所述 IGMP报告报文或离开报文承载的 IP报文中新增的 Option字段来存储所述 Flag值， 即将所述 Flag值存储于所述新增的 Option字段； 其中， 所述 Option字段的插入 位置位于所述 IP报文的报文头后， 用于记录本节点的系统 MAC地址 +端口实例。
或者，
2) 复用 IGMP报告报文或离开报文的报文头中的第二个字段来存储所述 Flag值， 即将 所述 Flag值存储于所述 IGMP报告报文或离开报文的报文头中的第二个字段。
参考图 7-图 9， 其中， 图 7为本发明实施例 4中提供的 IGMPvl Report报文格式示意 图， 图 8为本发明实施例 4中提供的 IGMPv2 Report/ Leave报文格式示意图， 图 9为本发 明实施例 4中提供的 IGMPv3 Report报文格式示意图。
图 7中 IGMPvl Report报文的报文头中的第二个字段在 RFC1112中的说明是： 不使用 区域当发送时为 0， 当接收时忽略。 图 8中 IGMPv2 Report/ Leave报文的报文头中的第二 个字段在 RFC2236 中的说明是： 最大响应时间区域仅仅在会员身份查询消息中有意义， 在 其他所有消息中， 当发送时置为 0， 接收时忽略。 图 9中 IGMPv3 Rep0rt报文的报文头中的 第二个字段在 RFC3376中的说明是： 保留区域当传送时置为 0， 当接收时忽略。
通过对 IGMPvl/v2/v3 Iteport报文或 IGMPv2 Leave报文的报文头中的第二个字段的分 析可知， IGMPvl/v2/v3 Iteport报文或 IGMPv2 Leave报文的报文头中的第二个字段都是发 送时为 0， 接收时忽略， 所以该字段是可以复用做其他的用途， 因此本实施例复用 IGMP报 告报文或离开报文的报文头中的第二个字段来存储 Flag值。
其中， 由主机发出的符合协议的 IGMP报告报文或离开报文中的 Flag值为零。 但是， 主机设备有可能发出不符合协议的 IGMP报告报文或离开报文， 其中不符合协议的 IGMP报 告报文或离开报文中的 Flag值为非零值。
所述自身设备默认设置的 Flagset值为零， 所述 Flagset值可以认为是设备可信任的 IGMP中 Flag值。当所述 IGMP报告报文或离开报文中的标记 Flag值与自身设备默认设置的 Flagset值 （零） 一致， 表示所述 IGMP报告报文或离开报文是由主机发出的。
S601d: 所述端口实例的 UserEdge状态保持不变， 将所述 Flag值修改为第一非零值， 发送所述修改后的 IGMP报告报文或离开报文至上游交换机设备。
如果所述 IGMP报告报文或离开报文中的 Flag值是零， 也就是说， 所述 IGMP报告报文 或离开报文是由主机发出， 由离主机最近的交换机设备端口实例接收到， 则将离主机最近 的交换机设备端口实例的 UserEdge状态保持不变， 将所述 Flag值由零修改为第一非零值， 发送所述修改后的 IGMP报告报文或离开报文至上游交换机设备。
S601e: 修改所述 Flagset 值为预定的 Flagset 值， 判断所述 Flag值与所述预定的 Flagset值是否一致， 如果是， 执行 S601f， 如果否， 执行 S601g。
如果所述 IGMP报告报文或离开报文中的 Flag值不是零， 也就是说， 所述 IGMP报告报 文或离开报文有可能是由主机设备发出的不符合协议的 IGMP报文， 也有可能是经过下游交 换机设备修改后的 IGMP报文； 所以需要修改所述 Flagset值为预定的 Flagset值后， 再进 行判断， 从而执行相应处理。
所述预定的 Flagset值为由主机发出的不符合协议的 IGMP报文中 Flag值的经验值。
S601f: 所述端口实例的 UserEdge状态保持不变， 将所述 Flag值修改为第二非零值， 发送所述修改后的 IGMP报告报文或离开报文至上游交换机设备。 如果所述 Flag值与所述预定的 Flagset值一致， 也就是说， 所述 IGMP报文为由主机 发出的不符合协议的 IGMP报文，因此所述端口实例的 UserEdge状态保持不变，将所述 Flag 值修改为第二非零值， 发送所述修改后的 IGMP报告报文或离开报文至上游交换机设备。
S601d中的所述第一非零值和 S601f中的所述第二非零值为除所述预定的 Flagset值之 外的任一非零值。
S601g: 将所述端口实例的 UserEdge状态修改为非 UserEdge状态， 所述 Flag值不变， 发送所述 IGMP报告报文或离开报文至上游交换机设备。
如果所述 Flag值与预置的 Flagset值不一致， 也就是说， 所述 IGMP报文为经过下游 交换机设备修改后的 IGMP报文， 因此将所述端口实例的 UserEdge状态修改为非 UserEdge 状态， 所述 Flag值不变， 发送所述 IGMP报告报文或离开报文至上游交换机设备。
这样， IGMP 报告报文或离开报文一跳一跳地转发至 NetEdge 状态端口实例， 所述 NetEdge状态端口实例对应交换机设备将 IGMP报告报文或离开报文中的 Flag还原为零后发 送至组播路由器或组播源。
本实施例 S601c中可以不判断所述 IGMP报告报文或离开报文中的标记 Flag值是否与 自身设备默认设置的 Flagset值一致， 而是直接判断所述 IGMP报告报文或离开报文中的标 记 Flag值是否为零， 如果是执行 S601d， 如果否， 执行 S601e， 相应的 S601e也可以用下 属方案来代替， 具体的， S601e: 判断所述 Flag值与预定值是否一致， 如果是， 执行 S601f， 如果否， 执行 S601g， 其中， 所述预定值为由主机发出的不符合协议的 IGMP报文中 Flag值 的经验值。
通过上述动态设置， 二层组播中的交换机都确定了端口实例的 UserEdge 状态或非
UserEdge状态， 参考图 10， 图 10为本发明实施例 4中提供的动态设置端口实例的组网示 意图。
在本实施例中， 二层组播中的每一跳交换机设备获取路径跟踪请求报文， 经过相应的 判断处理后， 将自身设备的 MAC地址添加到路径跟踪请求报文中进行下发， 直到终结路径 跟踪请求报文， 使得路径跟踪请求报文中包含了从 NetEdge 状态端口实例对应交换机设备 到 UserEdge状态端口实例对应交换机设备的组播路径信息； 相比较现有技术而言， 降低了 运维成本， 提高了效率。 实施例 5
参考图 11， 图 11为本发明实施例 5提供的二层组播 mtrace报文处理方法实施例的组 网示意图， 其中， 虚线箭头表示路径跟踪查询报文的路径， 实线箭头表示路径跟踪请求报 文的路径， 点划线箭头表示路径跟踪响应报文的路径； 交换机 1为 NetEdge状态端口实例 对应设备， 交换机 4为查询设备； 用户包括： 用户 1、 用户 2、 用户 3和用户 4， 其中， 用 户 1、 用户 2和用户 3为组成员主机， 用户 4不是组成员主机； 与用户 1和用户 2直接连接 的交换机 5的端口实例状态均为 UserEdge状态， 与用户 3直接连接的交换机 6的端口实例 状态为 UserEdge状态， 与用户 4连接的交换机 2的端口实例状态为 UserEdge状态。
图 11中的路径跟踪查询报文的路径为： 由交换机 4经过交换机 2到交换机 1 ; 路径跟 踪请求报文的路径为： 由交换机 1经交换机 2到交换机 5， 由交换机 1经交换机 3到交换机 6； 路径跟踪响应报文的路径为： 由交换机 5经交换机 2到交换机 4， 由交换机 6经交换机 3、 交换机 1交换机 2到交换机 4。
对于路径跟踪查询报文、 路径跟踪请求报文和路径跟踪响应报文的详细处理流程请参 见上述本发明实施例的描述， 在此不再赘述。
在本实施例中， 二层组播中的每一跳交换机设备获取路径跟踪请求报文， 经过相应的 判断处理后， 将自身设备的 MAC地址添加到路径跟踪请求报文中进行下发， 最终由查询设 备将从 NetEdge状态端口实例对应交换机设备到 UserEdge状态端口实例对应交换机设备的 组播路径信息进行显示； 相比较现有技术而言， 降低了运维成本， 提高了效率。
上述本发明实施例主要是针对 IGMP-S 协议的描述， 对于 IGMP-P 协议的处理过程与 IGMP-S协议相似， 具体可以参见上述本发明实施例的描述。
基于本发明实施例类似的原理， 可以对 mtrace的参数进行扩展， 例如： 增加 IPv6的 信息， 实现对 IPv6转发的数据流的跟踪； 或者， 在路径跟踪 Request报文中增加字段， 用 来指明每台交换机设备上二层组播的状态（如二层组播设置： IGMP/MLD(Multicast Listener Discover ， 组播侦听发现协议） Snooping 静态组； 或存在的组播成员信息） 来实现组 播的操作、 管理禾口维护 ( 0AM, Operation Administration and Maintenance ) 功能。 实施例 6
参考图 12，图 12为本发明实施例 6提供的一种二层组播路径跟踪装置实施例的结构示 意图， 所述二层组播路径跟踪装置包括：
获取模块 102， 用于获取路径跟踪请求报文。
判断模块 103， 用于判断二层组播转发表的组播成员端口的端口实例状态。
第一处理模块 104， 用于当所述端口实例状态中存在非 UserEdge状态， 添加自身设备 的介质访问控制 MAC地址至所述路径跟踪请求报文， 经所述非 UserEdge状态的端口实例发 送所述添加了 MAC地址的路径跟踪请求报文至下游设备。 第二处理模块 105， 用于当所述端口实例状态均为 UserEdge状态， 终结路径跟踪请求 报文， 将自身设备的 MAC地址添加至所述路径跟踪请求报文， 从所述路径跟踪请求报文中 获取从 NetEdge状态端口实例对应设备到所述 UserEdge状态端口实例对应设备的组播路径 信息， 将所述组播路径信息发送至查询设备。
在本实施例中， 二层组播中的每一跳二层组播设备获取路径跟踪请求报文， 经过相应 的判断处理后， 将自身设备的 MAC地址添加到路径跟踪请求报文中进行下发， 使得路径跟 踪请求报文中包含了从 NetEdge状态端口实例对应设备到 UserEdge状态端口实例对应设备 的组播路径信息； 相比较现有技术而言， 降低了运维成本， 提高了效率。 实施例 7
参考图 13，图 13为本发明实施例 7提供的一种二层组播路径跟踪装置实施例的结构示 意图， 所述二层组播路径跟踪装置包括：
设置模块 101， 用于设置二层组播设备的端口实例状态， 所述端口实例状态包括： 网 络侧边缘 NetEdge状态、 用户侧边缘 UserEdge状态和非 UserEdge状态。
在实际应用中， 由于连接组播源或组播路由器的二层组播设备较少， 所以可以直接静 态设置二层组播设备的端口实例状态为 NetEdge 状态， 具体地， 可以指定直接连接上游组 播源或组播路由器的二层组播设备的端口实例状态为 NetEdge 状态。 对于本领域技术人员 而言， 设置二层组播设备的端口实例状态为 NetEdge 状态的方法不仅仅局限于此方法， 在 此不作赘述。
对于二层组播设备的 UserEdge状态端口实例或非 UserEdge状态端口实例也可以进行 静态设置， 具体地， 可以指定直接连接下游二层组播设备的端口实例状态为非 UserEdge状 态； 可以指定直接连接下游主机的端口实例状态为 UserEdge状态； 或者， 也可以动态设置 二层组播设备的 UserEdge状态端口实例或非 UserEdge状态端口实例。
获取模块 102， 用于获取路径跟踪请求报文。
判断模块 103， 用于判断二层组播转发表的组播成员端口的端口实例状态。
二层组播中的每一跳二层组播设备收到所述路径跟踪请求报文后， 查询二层组播转发 表， 判断所述二层组播转发表中组播成员端口的端口实例状态。
第一处理模块 104， 用于当所述端口实例状态中存在所述非 UserEdge状态， 添加自身 设备的介质访问控制 MAC地址至所述路径跟踪请求报文， 经所述非 UserEdge状态的端口实 例发送所述添加了 MAC地址的路径跟踪请求报文至下游设备。
第二处理模块 105， 用于当所述端口实例状态均为所述 UserEdge状态， 终结路径跟踪 请求报文， 将自身设备的 MAC地址添加至所述路径跟踪请求报文， 从所述路径跟踪请求报 文中获取从所述 NetEdge状态端口实例对应设备到所述 UserEdge状态端口实例对应设备的 组播路径信息， 将所述组播路径信息发送至查询设备。
在本实施例中， 二层组播中的每一跳二层组播设备获取路径跟踪请求报文， 经过相应 的判断处理后， 将自身设备的 MAC地址添加到路径跟踪请求报文中进行下发， 使得路径跟 踪请求报文中包含了从 NetEdge状态端口实例对应设备到 UserEdge状态端口实例对应设备 的组播路径信息； 相比较现有技术而言， 降低了运维成本， 提高了效率。 实施例 8
参考图 14a，图 14a是本发明实施例 8中提供的一种二层组播路径跟踪装置实施例的第 一结构示意图， 所述二层组播路径跟踪装置包括： 设置模块 101、 获取模块 102、 判断模块 103、 第一处理模块 104和第二处理模块 105 ;
其中， 所述判断模块 103、第一处理模块 104和第二处理模块 105的功能与实施例 5中 所述判断模块 103、 第一处理模块 104和第二处理模块 105的功能类似， 在此不再赘述。
所述设置模块 101包括第一设置单元 1011和第二设置单元 1012 :
所述第一预置单元 1011， 用于设置二层组播设备的端口实例状态为 NetEdge状态。 其中， 所述第一设置单元 1011包括：
NetEdge设置子模块，用于静态设置直接连接上游组播源或组播路由器的端口实例的状 态为 NetEdge状态。
所述第二设置单元 1012，用于设置二层组播设备的端口实例状态为 UserEdge状态或非
UserEdge状态。
所述第二设置单元 1012包括 UserEdge设置子模块 1012a和非 UserEdge设置子模块 1012b :
所述 UserEdge 设置子模块 1012a， 用于静态设置二层组播设备的端口实例状态为 UserEdge状态， 其中， 直接连接下游主机的端口实例状态为 UserEdge状态。
所述非 UserEdge设置子模块 1012b， 用于静态设置二层组播设备的端口实例状态为非 UserEdge状态， 其中， 连接下游二层组播设备的端口实例状态为非 UserEdge状态。
当执行主体是所述 NetEdge状态端口实例对应设备时， 所述获取模块 102包括第一接 收单元 1021和第一修改单元 1022 :
所述第一接收单元 1021， 用于接收由查询设备发送的路径跟踪查询报文。
所述第一修改单元 1022， 用于将所述路径跟踪查询报文修改为二层组播请求报文。 或者， 当执行主体不是所述 NetEdge状态端口实例对应设备时， 所述获取模块 102包 括第二接收单元 1023， 如图 14b所示， 图 14b是本发明实施例 8中提供的一种二层组播路 径跟踪装置实施例的第二结构示意图：
所述第二接收单元 1023， 用于接收由上游二层组播设备发送的二层组播请求报文。 在本实施例中， 二层组播中的每一跳二层组播设备获取路径跟踪请求报文， 经过相应 的判断处理后， 将自身设备的 MAC地址添加到路径跟踪请求报文中进行下发， 使得路径跟 踪请求报文中包含了从 NetEdge状态端口实例对应设备到 UserEdge状态端口实例对应设备 的组播路径信息； 相比较现有技术而言， 降低了运维成本， 提高了效率。 实施例 9
参考图 15a和 15b，图 15a为本发明实施例 9中提供的一种二层组播路径跟踪装置实施 例的第一结构示意图； 图 15b为本发明实施例 9中提供的一种二层组播路径跟踪装置实施 例的第二结构示意图。
所述二层组播路径跟踪装置包括： 设置模块 101、 获取模块 102、 判断模块 103、 第一 处理模块 104和第二处理模块 105 ; 其中， 所述判断模块 103、 第一处理模块 104和第二处 理模块 105的功能与实施例 7中所述判断模块 103、 第一处理模块 104和第二处理模块 105 的功能类似， 可参照实施例 7中相关描述， 在此不再赘述。
所述设置模块 101包括第一设置单元 1011和第二设置单元 1012， 其中， 所述第一设置 单元 1011的功能与实施例 8中所述第一设置单元 1011的功能类似， 具体可参照实施例 8 中相关描述， 在此不再赘述。
所述获取模块 102包括第一接收单元 1021和第一修改单元 1022， 其中， 所述第一接收 单元 1021和第一修改单元 1022的功能与实施例 8中所述第一接收单元 1021和第一修改单 元 1022的功能类似， 具体可参照实施例 8中相关描述， 在此不再赘述； 或者， 所述获取模 块 102包括第二接收单元 1023， 其中， 所述第二接收单元 1023的功能与实施例 8中所述第 二接收单元 1023的功能类似， 具体可参照实施例 8中相关描述， 在此不再赘述。
所述第二设置单元 1012可以包括： 初始化子模块 1012c、 第一接收子模块 1012d、 第 一判断子模块 1012e、 第一处理子模块 1012f、 第二判断子模块 1012g、 第二处理子模块 1012h、 第三处理子模块 1012i :
初始化子模块 1012c，用于将连接下游二层组播设备的端口实例状态均设置为 UserEdge 状态；
第一接收子模块 1012d， 用于接收因特网组管理协议 IGMP报告报文或离开报文， 根据 所述 IGMP报告报文或离开报文修改自身设备的二层组播转发表；
第一判断子模块 1012e，用于判断所述 IGMP报告报文或离开报文中的标记 Flag值是否 与自身设备默认设置的 Flagset值一致；
第一处理子模块 1012f， 用于当第一判断模块的判断结果为是时， 所述端口实例的 UserEdge状态保持不变， 将所述 Flag值修改为第一非零值， 发送所述修改后的 IGMP报告 报文或离开报文至上游二层组播设备， 所述第一非零值为除预定的 Flagset 值之外的任一 非零值；
第二判断子模块 1012g， 用于第一判断模块的判断结果为否时， 修改所述 Flagset值为 所述预定的 Flagset值， 判断所述 Flag值与所述预定的 Flagset值是否一致；
第二处理子模块 1012h， 用于当第二判断模块的判断结果为是时， 所述端口实例的
UserEdge状态不变， 将所述 Flag值修改为第二非零值， 发送所述修改后的 IGMP报告报文 或离开报文至上游交换机设备， 所述第二非零值为除所述预定的 Flagset 值之外的任一非 零值；
第三处理子模块 1012i， 用于当第二判断模块的判断结果为否时， 将所述端口实例的 UserEdge状态修改为非 UserEdge状态， 所述 Flag值不变， 发送所述 IGMP报告报文或离开 报文至上游二层组播设备。
在本实施例中， 二层组播中的每一跳二层组播设备获取路径跟踪请求报文， 经过相应 的判断处理后， 将自身设备的 MAC地址添加到路径跟踪请求报文中进行下发， 使得路径跟 踪请求报文中包含了从 NetEdge状态端口实例对应设备到 UserEdge状态端口实例对应设备 的组播路径信息； 相比较现有技术而言， 降低了运维成本， 提高了效率。 实施例 10
参考图 16， 图 16为本发明实施例 10提供的一种二层组播路径跟踪系统实施例的结构 示意图， 所述二层组播路径跟踪系统包括：
二层组播路径跟踪装置 11， 用于获取路径跟踪请求报文； 判断二层组播转发表的组播 成员端口的端口实例状态； 当所述端口实例状态中存在非 UserEdge状态， 添加自身设备的 介质访问控制 MAC地址至所述路径跟踪请求报文， 经所述非 UserEdge状态的端口实例发送 所述添加了 MAC地址的路径跟踪请求报文至下游设备； 当所述端口实例状态均为 UserEdge 状态， 终结路径跟踪请求报文， 添加自身设备的 MAC地址至所述路径跟踪请求报文， 从所 述路径跟踪请求报文中获取从 NetEdge状态端口实例对应设备到所述 UserEdge状态端口实 例对应设备的组播路径信息， 将所述组播路径信息发送至查询设备。 查询设备 22，用于接收从 NetEdge状态端口实例对应设备到 UserEdge状态端口实例对 应设备的组播路径信息。
所述二层组播路径跟踪装置 11还用于设置二层组播设备的端口实例状态， 所述端口实 例状态包括： 网络侧边缘 NetEdge状态、 用户侧边缘 UserEdge状态和非 UserEdge状态。
所述设置二层组播设备的端口实例状态包括：
静态设置直接连接上游组播源或组播路由器的端口实例状态为 NetEdge状态； 静态设置二层组播设备的端口实例状态为 UserEdge状态或非 UserEdge状态， 其中， 直接连接下游主机的端口实例状态为 UserEdge状态， 连接下游二层组播设备的端口实例状 态为非 UserEdge状态；
动态设置二层组播设备的端口实例状态为 UserEdge状态或非 UserEdge状态， 具体包 括： 将连接下游二层组播设备的端口实例状态均设置为 UserEdge状态； 接收因特网组管理 协议 IGMP报告报文或离开报文， 根据所述 IGMP报告报文或离开报文修改自身设备的二层 组播转发表； 判断所述 IGMP报告报文或离开报文中的标记 Flag值是否与自身设备默认设 置的 Flagset值一致， 如果是， 所述端口实例的 UserEdge状态保持不变， 将所述 Flag值 修改为第一非零值， 发送所述修改后的 IGMP报告报文或离开报文至上游二层组播设备； 如 果否， 修改所述 Flagset值为预定的 Flagset值， 判断所述 Flag值与所述预定的 Flagset 值是否一致， 如果是， 所述端口实例的 UserEdge状态保持不变， 将所述 Flag值修改为第 二非零值， 发送所述修改后的 IGMP报告报文或离开报文至上游二层组播设备； 如果否， 将 所述端口实例的 UserEdge状态修改为非 UserEdge状态， 所述 Flag值不变， 发送所述 IGMP 报告报文或离开报文至上游二层组播设备； 所述第一非零值和所述第二非零值为除所述预 定的 Flagset值之外的任一非零值。
其中，所述根据所述 IGMP报告报文或离开报文修改自身设备的二层组播转发表具体为： 将接收 IGMP报告报文的端口添加到自身设备的二层组播转发表的组播成员端口； 将接 收 IGMP离开报文的端口从自身设备的二层组播转发表的组播成员端口中删除。
所述获取路径跟踪请求报文包括：
NetEdge状态端口实例对应设备接收由查询设备发送的路径跟踪查询报文；
NetEdge状态端口实例对应设备将所述路径跟踪查询报文修改为路径跟踪请求报文。 或者， 所述获取路径跟踪请求报文包括：
非 NetEdge状态端口实例对应设备接收由上游二层组播设备发送的路径跟踪请求报文。 所述查询设备 22还用于发送路径跟踪查询报文至二层组播跟踪装置。 需要说明的是， 本说明书中的各个实施例均采用递进的方式描述， 每个实施例重点说 明的都是与其他实施例的不同之处， 各个实施例之间相同相似的部分互相参见即可。 对于 装置类实施例而言， 由于其与方法实施例基本相似， 所以描述的比较简单， 相关之处参见 方法实施例的部分说明即可。
需要说明的是， 在本文中， 诸如第一和第二等之类的关系术语仅仅用来将一个实体或 者操作与另一个实体或操作区分开来， 而不一定要求或者暗示这些实体或操作之间存在任 何这种实际的关系或者顺序。 而且， 术语 "包括"、 "包含"或者其任何其他变体意在涵盖 非排他性的包含， 从而使得包括一系列要素的过程、 方法、 物品或者设备不仅包括那些要 素， 而且还包括没有明确列出的其他要素， 或者是还包括为这种过程、 方法、 物品或者设 备所固有的要素。 在没有更多限制的情况下， 由语句 "包括一个…… " 限定的要素， 并不 排除在包括所述要素的过程、 方法、 物品或者设备中还存在另外的相同要素。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完 成， 也可以通过程序来指令相关的硬件完成， 所述的程序可以存储于一种计算机可读存储 介质中， 上述提到的存储介质可以是只读存储器， 磁盘或光盘等。
以上所述仅为本发明的较佳实施例， 并不用以限制本发明， 凡在本发明的精神和原则 之内， 所作的任何修改、 等同替换、 改进等， 均应包含在本发明的保护范围之内。

Claims

1、 一种二层组播路径跟踪方法， 其特征在于， 所述方法包括：
获取路径跟踪请求报文；
判断二层组播转发表中组播成员端口的端口实例状态；
当所述端口实例状态中存在非用户侧边缘 UserEdge状态，添加自身设备的介质访问控制 MAC地址至所述路径跟踪请求报文， 经所述非 UserEdge状态的端口实例发送所述添加了 MAC 地址的路径跟踪请求报文至下游设备；
当所述端口实例状态均为 UserEdge状态， 终结路径跟踪请求报文， 添加自身设备的 MAC 地址至所述路径跟踪请求报文， 从所述路径跟踪请求报文中获取从网络侧边缘 NetEdge状态 端口实例对应设备到所述 UserEdge状态端口实例对应设备的组播路径信息，将所述组播路径 信息发送至查询设备。
2、根据权利要求 1所述的方法， 其特征在于， 所述获取路径跟踪请求报文之前进一步包 括：
设置二层组播设备的端口实例状态，所述端口实例状态包括： 网络侧边缘 NetEdge状态、 用户侧边缘 UserEdge状态和非 UserEdge状态。
3、根据权利要求 2所述的方法， 其特征在于， 所述设置二层组播设备的端口实例状态包 括：
静态设置直接连接上游组播源或组播路由器的端口实例状态为 NetEdge状态。
4、根据权利要求 2所述的方法， 其特征在于， 所述设置二层组播设备的端口实例状态包 括：
静态设置二层组播设备的端口实例状态为 UserEdge状态或非 UserEdge状态， 其中， 直 接连接下游主机的端口实例状态为 UserEdge状态，连接下游二层组播设备的端口实例状态为 非 UserEdge状态。
5、根据权利要求 2所述的方法， 其特征在于， 所述设置二层组播设备的端口实例状态包 括：
动态设置二层组播设备的端口实例状态为 UserEdge状态或非 UserEdge状态，具体包括： 将连接下游二层组播设备的端口实例状态均设置为 UserEdge状态；
接收因特网组管理协议 IGMP报告报文或离开报文， 根据所述 IGMP报告报文或离开报文 修改自身设备的二层组播转发表； 判断所述 IGMP报告报文或离开报文中的标记 Flag值是否与自身设备默认设置的 Flagset 值一致， 如果是， 所述端口实例的 UserEdge状态保持不变， 将所述 Flag值修改为第一非零 值， 发送所述修改后的 IGMP报告报文或离开报文至上游二层组播设备；
如果否， 修改所述 Flagset 值为预定的 Flagset 值， 判断所述 Flag 值与所述预定的 Flagset值是否一致， 如果是， 所述端口实例的 UserEdge状态保持不变， 将所述 Flag值修 改为第二非零值，发送所述修改后的 IGMP报告报文或离开报文至上游二层组播设备；如果否， 将所述端口实例的 UserEdge状态修改为非 UserEdge状态，所述 Flag值不变，发送所述 IGMP 报告报文或离开报文至上游二层组播设备；
所述第一非零值和所述第二非零值为除所述预定的 Flagset值之外的任一非零值。
6、根据权利要求 5所述的方法， 其特征在于， 所述 Flag值存储于所述 IGMP报告报文或 离开报文的报文头中的第二个字段；
或者，
所述 Flag值存储于所述 IGMP报告报文或离开报文承载的 IP报文中新增的 Option字段， 所述 Option字段的插入位置位于所述 IP报文的报文头后。
7、 根据权利要求 5所述的方法， 其特征在于， 所述根据所述 IGMP报告报文或离开报文 修改自身设备的二层组播转发表具体为：
将接收 IGMP报告报文的端口添加到自身设备的二层组播转发表的组播成员端口；将接收 IGMP离开报文的端口从自身设备的二层组播转发表的组播成员端口中删除。
8、 根据权利要求 1所述的方法， 其特征在于， 所述获取路径跟踪请求报文包括： 所述 NetEdge状态端口实例对应设备接收由查询设备发送的路径跟踪查询报文； 所述 NetEdge 状态端口实例对应设备将所述路径跟踪查询报文修改为路径跟踪请求报 文。
9、 根据权利要求 1所述的方法， 其特征在于， 所述获取路径跟踪请求报文包括： 非 NetEdge状态端口实例对应设备接收由上游二层组播设备发送的路径跟踪请求报文。
10、 一种二层组播路径跟踪装置， 其特征在于， 包括：
获取模块， 用于获取路径跟踪请求报文；
判断模块， 用于判断二层组播转发表的组播成员端口的端口实例状态；
第一处理模块， 用于当所述端口实例状态中存在非 UserEdge状态， 添加自身设备的介质 访问控制 MAC地址至所述路径跟踪请求报文，经所述非 UserEdge状态的端口实例发送所述添 加了 MAC地址的路径跟踪请求报文至下游设备； 第二处理模块， 用于当所述端口实例状态均为 UserEdge状态， 终结路径跟踪请求报文， 添加自身设备的 MAC 地址至所述路径跟踪请求报文， 从所述路径跟踪请求报文中获取从 NetEdge状态端口实例对应设备到所述 UserEdge状态端口实例对应设备的组播路径信息， 将 所述组播路径信息发送至查询设备。
11、 根据权利要求 10所述的装置， 其特征在于， 进一步包括：
设置模块， 用于设置二层组播设备的端口实例状态， 所述端口实例状态包括： 网络侧边 缘 NetEdge状态、 用户侧边缘 UserEdge状态和非 UserEdge状态。
12、 根据权利要求 11所述的装置， 其特征在于， 所述设置模块包括：
第一设置单元， 用于设置二层组播设备的端口实例状态为 NetEdge状态；
第二设置单元， 用于设置二层组播设备的端口实例状态为 UserEdge状态或非 UserEdge 状态。
13、 根据权利要求 12所述的装置， 其特征在于， 所述第一设置单元包括：
NetEdge 设置子模块， 用于静态设置直接连接上游组播源或组播路由器的端口实例的状 态为 NetEdge状态。
14、 根据权利要求 12所述的装置， 其特征在于， 所述第二设置单元包括：
UserEdge设置子模块， 用于静态设置二层组播设备的端口实例状态为 UserEdge状态， 其中， 直接连接下游主机的端口实例状态为 UserEdge状态；
非 UserEdge设置子模块， 用于静态设置二层组播设备的端口实例状态为非 UserEdge状 态， 其中， 连接下游二层组播设备的端口实例状态为非 UserEdge状态。
15、 根据权利要求 12所述的装置， 其特征在于， 所述第二设置单元包括：
初始化子模块， 用于将连接下游二层组播设备的端口实例状态均设置为 UserEdge状态； 第一接收子模块，用于接收因特网组管理协议 IGMP报告报文或离开报文，根据所述 IGMP 报告报文或离开报文修改自身设备的二层组播转发表；
第一判断子模块， 用于判断所述 IGMP报告报文或离开报文中的标记 Flag值是否与自身 设备默认设置的 Flagset值一致；
第一处理子模块， 用于当第一判断模块的判断结果为是时， 所述端口实例的 UserEdge状 态保持不变， 将所述 Flag值修改为第一非零值， 发送所述修改后的 IGMP报告报文或离开报 文至上游二层组播设备， 所述第一非零值为除预定的 Flagset值之外的任一非零值；
第二判断子模块， 用于第一判断模块的判断结果为否时， 修改所述 Flagset值为所述预 定的 Flagset值， 判断所述 Flag值与所述预定的 Flagset值是否一致； 第二处理子模块， 用于当第二判断模块的判断结果为是时， 所述端口实例的 UserEdge状 态不变， 将所述 Flag值修改为第二非零值， 发送所述修改后的 IGMP报告报文或离开报文至 上游交换机设备， 所述第二非零值为除所述预定的 Flagset值之外的任一非零值；
第三处理子模块， 用于当第二判断模块的判断结果为否时， 将所述端口实例的 UserEdge 状态修改为非 UserEdge状态， 所述 Flag值不变， 发送所述 IGMP报告报文或离开报文至上游 二层组播设备。
16、 根据权利要求 10所述的装置， 其特征在于， 所述获取模块包括：
第一接收单元， 用于 NetEdge状态端口实例对应设备接收由查询设备发送的路径跟踪查 询报文；
第一修改单元， 用于 NetEdge状态端口实例对应设备将所述路径跟踪查询报文修改为路 径跟踪请求报文。
17、 根据权利要求 10所述的装置， 其特征在于， 所述获取模块包括：
第二接收单元， 用于非 NetEdge状态端口实例对应设备接收由上游二层组播设备发送的 路径跟踪请求报文。
18、 一种二层组播路径跟踪系统， 其特征在于， 包括如权利要求 10-17任一项所述的二 层组播跟踪装置和查询设备， 所述查询设备用于接收从 NetEdge 状态端口实例对应设备到 UserEdge状态端口实例对应设备的组播路径信息。
19、根据权利要求 18所述的系统， 其特征在于， 所述查询设备还用于发送路径跟踪查询 报文至二层组播跟踪装置。
PCT/CN2011/075912 2011-06-20 2011-06-20 一种二层组播路径跟踪方法、装置及系统 WO2012103694A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201180000900.0A CN102265554B (zh) 2011-06-20 2011-06-20 一种二层组播路径跟踪方法、装置及系统
PCT/CN2011/075912 WO2012103694A1 (zh) 2011-06-20 2011-06-20 一种二层组播路径跟踪方法、装置及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2011/075912 WO2012103694A1 (zh) 2011-06-20 2011-06-20 一种二层组播路径跟踪方法、装置及系统

Publications (2)

Publication Number Publication Date
WO2012103694A1 true WO2012103694A1 (zh) 2012-08-09
WO2012103694A9 WO2012103694A9 (zh) 2012-10-18

Family

ID=45010616

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/075912 WO2012103694A1 (zh) 2011-06-20 2011-06-20 一种二层组播路径跟踪方法、装置及系统

Country Status (2)

Country Link
CN (1) CN102265554B (zh)
WO (1) WO2012103694A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103874105B (zh) * 2012-12-10 2017-09-08 中国移动通信集团公司 一种路径追踪方法、系统及一种网关设备
CN105591943B (zh) * 2014-10-22 2019-12-03 中兴通讯股份有限公司 用户设备进行组播路径追踪的方法及系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101083629A (zh) * 2007-08-07 2007-12-05 华为技术有限公司 定位最后一跳路由器及组播路由跟踪的方法和路由器
CN101159688A (zh) * 2007-11-08 2008-04-09 华为技术有限公司 组播路由跟踪的方法和路由器
CN101980473A (zh) * 2010-10-09 2011-02-23 中兴通讯股份有限公司 一种组播路径跟踪方法和系统
WO2011053290A1 (en) * 2009-10-28 2011-05-05 Hewlett-Packard Development Company Lp Method and apparatus for tracing a multicast flow

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101083629A (zh) * 2007-08-07 2007-12-05 华为技术有限公司 定位最后一跳路由器及组播路由跟踪的方法和路由器
CN101159688A (zh) * 2007-11-08 2008-04-09 华为技术有限公司 组播路由跟踪的方法和路由器
WO2011053290A1 (en) * 2009-10-28 2011-05-05 Hewlett-Packard Development Company Lp Method and apparatus for tracing a multicast flow
CN101980473A (zh) * 2010-10-09 2011-02-23 中兴通讯股份有限公司 一种组播路径跟踪方法和系统

Also Published As

Publication number Publication date
CN102265554A (zh) 2011-11-30
WO2012103694A9 (zh) 2012-10-18
CN102265554B (zh) 2013-02-13

Similar Documents

Publication Publication Date Title
US11240053B2 (en) Overlay signaling for bit indexed explicit replication
WO2018205982A1 (zh) 软件定义网络中广播、组播实现方法、装置及存储介质
WO2019184752A1 (zh) 网络设备的管理方法、装置及系统
US10225295B2 (en) Multicast packet forwarding method and device
WO2018214809A1 (zh) 消息发送方法及装置、存储介质
WO2007019785A1 (fr) Systeme de commutation reseau local virtuel a multidiffusion et procede associe
US9306758B2 (en) Dynamic adjustment of MLDP tunnel and PIM binding
CN102546666B (zh) 防止igmp欺骗和攻击的方法及装置
KR101604810B1 (ko) 단말기의 멀티캐스트 상태를 얻기 위한 방법
WO2010017720A1 (zh) 实现组播负载分担的方法及装置
CN107612809A (zh) 一种组播表项同步方法以及设备
US20140241351A1 (en) Dynamic determination of the root node of an mldp tunnel
WO2009082905A1 (fr) Procédé système et dispositif commutateur permettant l'établissement dynamique de réseau local virtuel de multidiffusion
CN101222425B (zh) 组播转发方法及组播路由器
WO2013139159A1 (zh) 在网络中转发报文的方法和运营商边缘设备
WO2020173340A1 (zh) 基于bier的双向转发检测会话创建方法及bfir、bfer、系统和存储介质
EP3451585B1 (en) Auto-configuring multicast protocol parameters of a network device
EP2892196B1 (en) Method, network node and system for implementing point-to-multipoint multicast
WO2009033388A1 (fr) Procédé d'utilisation d'un système de sécurité étendue, système et appareil de sécurité étendue
WO2007054006A1 (fr) Station de base de système d’accès sans fil large bande et système pour réaliser un service de diffusion de groupe
WO2008138248A1 (fr) Procédé, carte d'interface et routeur destinés à transmettre un message
CN101087246B (zh) 一种实现网络层组播业务及业务管理的系统与方法
WO2012068854A1 (zh) 一种mac地址更新方法及装置
WO2007041942A1 (fr) Système pour ethernet de support de la transmission de la multidiffusion spécifique à une source et procédé idoine
WO2009030143A1 (fr) Système et procédé de routage multidiffusion, passerelle multimédia et contrôleur de passerelle multimédia

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201180000900.0

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11857764

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11857764

Country of ref document: EP

Kind code of ref document: A1