Multicast data path tracking in Layer 2 networks

Abstract

A method comprising: Receiving, at a Layer 3, L3, router (118, 850), a tracking request for multicast paths associated with a multicast group; in response to the detection of a Layer 2, L2, switch (120, 700) coupled to the L3 router, constructing a request packet and sending the request packet to the coupled L2 switch, the request packet including an initial data block indicating that the request packet is an L2 multicast tracking request, causing the L2 switch to propagate the request packet to each downstream L2 switch in the multicast group until the request packet reaches a last-hop L2 switch (122, 124);Receiving a response packet from the last-hop L2 switch in response to the L2 multicast trace request, wherein the response packet comprises one or more data blocks, each data block containing information about an L2 switch (120, 122, 124) or client device (106, 108, 110, 112) that is on a traversed multicast path for the multicast group, the first data block comprising an augmented response block, ARB, (200) which includes an augmented response type field set to the value 0X2.

Description

BACKGROUND area

[0001] This disclosure generally relates to a multicast network with Layer 2 (L2) switches. More specifically, this disclosure relates to path tracing in the L2 multicast network. BRIEF DESCRIPTION OF THE CHARACTERS Fig. 1 shows an example network environment that facilitates tracing multicast paths in Layer 2 (L2) networks according to one aspect of the present application. Fig. 2A shows an example of an appended data block in the Layer 2 multicast trace request packet according to one aspect of the present application. Fig. Figure 2B shows an example of the data block appended by a switch to the Layer 2 multicast trace request packet, according to one aspect of the present application. Fig. Figure 2C shows an example of a data block associated with a client device, according to one aspect of the present application. Fig. Figure 3 shows in more detail a multicast path tracing scenario in a Layer 2 network, according to one aspect of the present application. Fig. 4 shows a flowchart illustrating an example of a multicast path tracing process performed at the last-hop router, according to one aspect of the present application. Fig. 5 shows an example of a displayed multicast trace result according to one aspect of the present application. Fig. 6 shows a flowchart illustrating an example of a multicast path tracing process performed on a Layer 2 switch according to one aspect of the present application. Fig. Figure 7A shows an example of a switch that supports tracing Layer 2 multicast paths, according to one aspect of the present application. Fig. 7B shows an example of a computer system implemented on a Layer 2 switch to support multicast path tracing according to one aspect of the present application. Fig. 8A shows an example of a computer system that enables improved multicast path tracing according to one aspect of the present application. Fig. Figure 8B shows an example of a Layer 3 router that supports enhanced multicast path tracing according to one aspect of the present application.

[0002] In the figures, like numbers refer to the same elements of the figure. DETAILED DESCRIPTION

[0003] Multicast allows data to be sent from a single source to multiple destinations simultaneously. Multicast data is sent only once but can be received by multiple endpoints subscribed to a specific multicast group. Essentially, multicast distributes the data stream to multiple recipients without generating a separate stream for each destination. Multicast can conserve network bandwidth and reduce overall network traffic. Multicast is widely used for delivering streaming media, IPTV, VoIP, and video conferencing. Compared to unicast communication, multicast communication requires specialized network hardware and protocols to function properly.

[0004] Similar to traceroute, which is used for tracing the paths of unicast traffic, multicast trace (Mtrace) can be used to identify the path multicast traffic takes through a network. Mtrace allows network administrators to troubleshoot problems with multicast traffic, such as missing or delayed packets. Mtrace can be initiated by an Mtrace client sending an Mtrace request to a last-hop router (LHR). The LHR translates the request into a request packet and forwards the request packet upstream until it reaches the router associated with the source, or first-hop router (FHR). Each router along the traced path adds its forwarding information to the received request packet. The FHR adds its local forwarding information to the request packet, converts the request packet into an Mtrace response packet, and sends the response packet to the Mtrace client.The response packet contains the trace information. However, mtrace only works in L3 (IP) networks and cannot provide information about L2 (Ethernet) switches that may exist between the end clients and the LHR. Many campus multicast networks contain L2 switches. In certain scenarios, a multicast network may include a cascade of multiple L2 switches, with each switch introducing some latency to multicast traffic. Multicast path tracing in the L2 network can play an important role in monitoring the performance of the multicast network.

[0005] Fig. Figure 1 shows an example of a network environment that facilitates multicast path tracing in Layer 2 (L2) networks according to one aspect of the present application. Fig. 1, a multicast network 100 may include a source 102 and a number of group members (i.e., client devices that receive multicast traffic from source 102), including client devices 104-112. Source 102 may be a host that sends packets with a destination IP address set to a multicast group, and a group member may be a host or client device that expresses interest in receiving packets sent to a particular group address of the multicast group. Fig. also shows a series of L3 routers (e.g., IP routers) and L2 switches (e.g., Ethernet switches) that route packets from the source 102 to the client devices.

[0006] In the Fig. 1, the L3 routers along the multicast path may include a first-hop router (FHR) 114, one or more intermediate routers (e.g., R1 116), and a last-hop router (LHR) 118. FHR 114 may be the router directly connected to source 102. Among the plurality of routers along the multicast path, LHR 118 may be a router closest to the client devices receiving the multicast traffic. LHR 118 may include a number of multicast-capable interfaces, and each interface may be connected to a client device or an L2 switch. In this example, LHR 118 includes three interfaces, one of which is connected to client device 104 and the other two of which are connected to L2 switches 120 and 122. An L2 switch may also contain one or more multicast-capable interfaces, with some interfaces connected to client devices and some interfaces connected to downstream L2 switches.In this example, L2 switch 120 includes two interfaces, one connected to client device 106 and the other connected to downstream L2 switch 124; L2 switch 122 includes two interfaces connected to client devices 110 and 112, respectively, and L2 switch 124 includes one interface connected to client device 108.

[0007] Mtrace can be used to trace the path of multicast traffic step by step from the source to a receiver connected to the LHR. For example, Mtrace can be used to trace multicast traffic from source 102 to client device 104 connected to LHR 118. However, Mtrace only works in the L3 domain and is unable to provide information about the L2 switches (e.g., switches 120-124) along the multicast traffic path. For example, Mtrace cannot be used to trace the entire path between source 102 and client device 108.To enable L2 multicast path tracing, according to some aspects of the present application, when an LHR receives a multicast trace request for a multicast group from a client device (or client), it may perform extended L2 multicast path tracing (or simply extended multicast path tracing), which may include the L3 mtrace operation upstream to the source and the L2 multicast trace operation downstream to the last-hop L2 switch. Note that a last-hop L2 switch is an L2 switch that is not coupled to a downstream L2 switch that receives multicast traffic for the group. In the example described in . Fig. In the example shown in Figure 1, L2 switches 120-124 all receive multicast traffic for a group, and L2 switches 122 and 124 are last-hop L2 switches.

[0008] According to one aspect, a client may initiate an L2-enhanced multicast trace operation for a multicast group by sending a query packet to the LHR of the multicast group. The query packet may specify a multicast group and a source address and may be referred to as an (S, G) query, where S represents the source address and G represents the multicast group address. If the L2-enhanced multicast trace feature is enabled on the LHR, the LHR may perform the mtrace operation followed by the L2 multicast trace operation. If the L2-enhanced multicast trace feature is not enabled on the LHR, the LHR may perform the mtrace operation only in the L3 domain.

[0009] More specifically, to perform the mtrace operation, the LHR can generate a request packet (which may be referred to as an mtrace request packet) based on the received query. Note that the type of request message allows each of the upstream routers processing the message to apply different packet and message validation rules than those required to handle a query packet. The multicast destination IP address of the request packet can be the all-router multicast group address, which is 224.0.0.2 for IP version 4 and FF02::2 for IP version 6. The LHR can append a data block containing its interface addresses and packet statistics to the request packet and then forward the packet to the source.Similarly, each upstream L3 router that receives the request packet can append a data block to the end of the request packet before forwarding it to its upstream router. The data block can be a Standard Response Block (SRB), as defined in Internet Engineering Task Force (IETF) RFC 8487. When the FHR receives the request packet, it can append its own SRB to the request packet, transform the request packet into a response packet, and unicast the response packet to the client that initiated the trace operation. The mtrace operation can provide information about all L3 routers on the multicast path (for example, routers 114-118 in . Fig. 1).

[0010] Following the mtrace operation, the LHR may construct a second request packet based on the received query packet (which may be referred to as an L2 multicast trace request packet). In some aspects, the LHR may append a special data block to the mtrace request packet to indicate that the new packet is an L2 multicast trace request packet. In one aspect, the special data block may be an extended response block (ARB), which is defined in IETF RFC 8487.

[0011] Fig. Figure 2A shows an example of an appended data block in the L2 multicast trace request packet according to one aspect of the present application. In this example, the data block may be an ARB 200, which may include a 1-octet type field, a 2-octet length field, a 1-octet zero field (containing only zeros), a 2-octet extended response type field, and a value field.

[0012] ARB 200 can be part of a message exchanged between devices on the multicast network. The type field of ARB 200 can be 0X05, indicating that the data block is an ARB. The extended response type field of ARB 200 can be 0X2, indicating that the packet containing ARB 200 is an L2 multicast trace request packet. The value field can contain all zeros.

[0013] The LHR can forward the L2 multicast trace request packet to all downstream switches of the multicast group. Fig. 1, the LHR 118 may forward the L2 multicast trace request packet to the L2 switches 120 and 122. In some aspects, the LHR may detect a paired downstream L2 switch with IGMP snooping. In a multi-hop L2 network, each L2 switch may forward the IGMP Join messages from client devices to the IGMP querier. For example, a switch directly connected to a client device may receive a Join message from the client and forward the Join message upstream to the IGMP querier (which may be the LHR). Intermediate switches may process the Join messages and forward them to the IGMP querier. For a given multicast group G, the IGMP logic in the LHR or switch may have information about the L2 ports that received the join messages from a downstream network device (such as a switch or a client device).To determine whether a join message originates from a client device or a downstream switch, the LHR or switch can use the device information contained in Link Layer Discovery Protocol (LLDP) messages. For example, the LLDP information from devices can be sent in the form of an Ethernet frame containing a sequence of type-length-value (TLV) structures. A special TLV can contain information about the system's capabilities (for example, whether the device is a router, an access point, a switch, or a client device). Fig. 1, LHR 118 may determine that devices 104, 120, and 122 have sent join messages for a multicast group G. Furthermore, based on the LLDP information received from devices 104, 120, and 122, LHR 118 may determine that device 104 is a client device (e.g., a laptop) and that devices 120 and 122 are switches (e.g., Wi-Fi access points). Accordingly, LHR 118 may forward the L2 multicast trace request packet to switches 120 and 122.

[0014] An L2 switch that receives the L2 multicast trace request packet can then determine whether it is a last-hop switch (i.e., it is not connected to any additional downstream switches) or an intermediate switch (i.e., it is connected to at least one downstream switch) for the multicast group. More specifically, the L2 switch can make such a determination based on received multicast join messages and LLDP messages. In the Fig. In the example shown in Figure 1, L2 switches 122 and 124 are last-hop L2 switches, and L2 switch 120 is an intermediate switch.

[0015] Each switch (whether an intermediate switch or a terminal switch) can append an additional data block to the received L2 multicast query packet. This additional data block can contain address information associated with the switch. In one aspect, this additional data block can be an ARB defined by IETF RFC 8487.

[0016] Fig. Figure 2B shows an example of the data block appended by a switch to the L2 multicast trace request packet, according to one aspect of the present application. ARB 210 may be similar to ARB 200, except that the extended response type field of ARB 210 is 0X3, indicating that ARB 210 is connected to an L2 switch. The value field of ARB 210 may contain the address information about the L2 switch. In this example, the value field may contain the system media access control (MAC) address of the L2 switch. In another example, the value field may contain the MAC address of the interface receiving the L2 multicast trace request packet. Fig. 1, the value field of the ARB associated with the L2 switch 120 may contain the MAC address of the interface of the L2 switch 120 connected to the LHR 118.

[0017] If a client device belonging to the multicast group is detected by an intermediate or last-hop switch to which the client device is connected, the intermediate or last-hop switch can also append a data block to a received L2 multicast trace request packet to include information about the client device. In one aspect, the data block can also be an ARB defined by IETF RFC 8487. If a switch is connected to multiple client devices, the switch can add an ARB for each client device.

[0018] Fig. 2C shows an example of a data block associated with a client device, according to one aspect of the present application. ARB 220 may be similar to ARB 200 and ARB 210, except that the extended response type field of ARB 220 is 0X4, indicating that ARB 220 is associated with a client device. The value field of ARB 220 may contain the address information about the client device. In this example, the value field may contain the MAC address of the client device. In another example, in addition to the address information, other information about the client device (such as the type of device, the serial number of the device, etc.) may be included in the value field of ARB 220. Using the example of Fig. 1, an ARB associated with client device 106 may be added to the L2 multicast trace request by L2 switch 120, an ARB associated with client device 108 may be added by L2 switch 124, and ARBs associated with client devices 110 and 112 may be added by L2 switch 122.

[0019] As soon as a last-hop L2 switch (e.g. switch 122 or 124 in Fig. 1) If the last-hop L2 switch has appended ARBs for all paired client devices to the L2 multicast trace request packet (one ARB per client device), the last-hop L2 switch may convert the L2 multicast trace request packet into a response packet (e.g., The ARBs included in the response packet contain information about all L2 switches and client devices on the path of the request packet, thus making it easier for the LHR to determine the multicast path. For example, the LHR may extract the address of each L2 switch on the path from the response packet. Since the network may contain multiple last-hop L2 switches, the LHR may receive multiple L2 multicast response packets. According to some aspects of the present application, the LHR may aggregate path information from multiple received response packets and display the aggregated path information to users (e.g., a network administrator).

[0020] Fig. Figure 3 illustrates in more detail a multicast path tracing scenario in a Layer 2 network according to one aspect of the present application. Fig. 3, an L2 network 300 connected to a multicast group (S, G) may include an LHR 302 and L2 switches 304-312. LHR 302 may receive multicast join requests (e.g., IGMP joins) for the multicast group (S, G) from L2 switches 304 and 306. To initiate a multicast trace operation in the L2 network 300, LHR 302 may send a multicast request packet to L2 switches 304 and 308, as indicated by the arrows pointing from LHR 302 to L2 switches 304 and 306. The multicast trace request packet may specify a multicast group (S, G), where S is the source address and G is the multicast group address. The request packet may contain an ARB whose extended response type is set to 0X2, indicating that the request packet is an L2 multicast trace request packet.

[0021] L2 switch 304 may determine that it is connected to a downstream L2 switch 308 and a client device 314 for the multicast group specified by the request packet. Accordingly, L2 switch 304 may attach two ARBs to the request packet, one for itself and one for the client device 314. In the Fig. In the example illustrated in Figure 3, an ARB corresponding to L2 switch 304 is represented by an unshaded block 316, and an ARB corresponding to client device 314 is represented by a shaded block 318. ARB 316 may include address information associated with L2 switch 304, and ARB 318 may include address information associated with client device 314. L2 switch 304 may then send the attached L2 multicast trace request packet to downstream L2 switch 308.

[0022] Upon receiving the L2 multicast trace request packet, the L2 switch 308 may append an ARB 320 containing its address information to the request packet. The L2 switch 308 may also detect a paired client device 322 belonging to the multicast group. Accordingly, the L2 switch 308 may append an ARB 324 containing the address information of the client device 322 to the request packet.

[0023] L2 switch 308 can also determine whether it is a last-hop L2 switch for the multicast group based on the Multicast Join messages sent by paired devices and the LLDP information about those paired devices. Fig. 3, the L2 switch 308 may determine that it is a last-hop L2 switch for the multicast group because there is no downstream L2 switch for the multicast group connected to the L2 switch 308. It should be noted that although in Fig. 3, an L2 switch 326 is physically coupled to L2 switch 308, L2 switch 326 does not send the multicast join message for group (S, G), which means that L2 switch 326 is not part of the multicast network for group (S, G). Therefore, in Fig. 3 a dashed line is used to represent the connection between L2 switches 308 and 326.

[0024] In response to detecting that it is the last-hop switch, the L2 switch 308 may convert the request packet, which may now contain four additional ARBs, into a response packet. The L2 switch 308 may send the response packet as a unicast packet to the LHR 302, as indicated by the thickened arrow 328 pointing from the LS switch 308 to the LHR 302. As shown in Fig. As can be seen in Figure 3, the four additional ARBs included in the response packet may contain information about all L2 switches (i.e., switches 304 and 308) and client devices (e.g., client devices 314 and 322) encountered by the request packet along the path. Therefore, this response packet may provide sufficient path information to the LHR 302.

[0025] The behavior of the L2 switches in other branches may be similar to switches 304 and 308 described above. For example, L2 switch 306 may append an ARB with its own address information to the request packet and forward the request packet to interfaces connected to last-hop L2 switches 310 and 312. Last-hop L2 switch 310 may append three additional ARBs to the request packet, with one ARB containing its own address information and the other two ARBs each containing the address information of a paired client device. Similarly, last-hop L2 switch 312 may append two ARBs, with one ARB containing its own address information and the other ARB containing the address information of a paired client device.Last-hop L2 switches 310 and 312 may each send a unicast response packet to LHR 302, where the response packet contains address information of switches and client devices encountered by a corresponding request packet.

[0026] As from Fig. As can be seen in Figure 3, the L2 multicast trace request packet can be branched at an L2 switch coupled to multiple downstream switches, forming an L2 multicast trace tree that is routed at the LHR and terminated at the last-hop L2 switches. By aggregating path information contained in response packets sent by the last-hop switches, the LHR can have complete path information about the L2 multicast trace tree.

[0027] Fig. Figure 4 shows a flowchart illustrating an example of a multicast path tracing process performed at the last-hop router according to one aspect of the present application. During operation, the LHR may receive a multicast trace query for a specific multicast group (operation 402). The multicast trace query may be an extended query requiring path tracing in both the L3 and L2 networks. The LHR may perform the L3 multicast trace operation (Mtrace) (operation 404) and determine whether the L2 multicast trace feature is enabled on the LHR (operation 406). Note that the L2 multicast trace feature may be user-configurable.

[0028] If the L2 multicast tracing feature is not enabled, the trace completes, and the LHR can return and display the trace result (operation 408). If the L2 multicast tracing feature is enabled, the LHR can determine whether downstream L2 switches can be discovered (operation 410). A downstream device for the multicast group can be discovered based on a multicast join request (for example, an IGMP join message) received on an interface of the LHR, and the LHR can determine whether the downstream device is a switch or a client device based on the LLDP information about the device.

[0029] If no downstream L2 switch can be discovered, the trace is complete, and the LHR may return and display the trace result (operation 408). If one or more downstream L2 switches can be discovered, the LHR may construct a request packet and send the request packet to each downstream L2 switch (operation 412). In some aspects, the LHR may append a special data block (e.g., an ARB) with a special type field (e.g., 0X2) to indicate that the request packet is an L2 multicast trace request packet, causing the receiving L2 switch to forward the request packet downstream until it reaches a last-hop L2 switch. The value field in the special data block may contain zeros.

[0030] The LHR may then receive response packets from last-hop switches (operation 414). Each response packet may contain one or more additional data blocks, where each data block contains information about an L2 switch or a client device located on the path of the corresponding request packet. For example, a data block associated with an L2 switch may be an ARB whose extended response type field is set to 0X3 and whose value field contains the address information associated with the L2 switch; and a data block associated with a client device may be an ARB whose extended response type field is set to 0X4 and whose value field contains the MAC address of the client device. The address information associated with an L2 switch may be its system MAC address or the MAC address of the interface receiving the L2 multicast trace request.

[0031] The LHR can then summarize the path information in the response packets from all last-stop L2 switches (operation 416). Since each last-stop switch corresponds to a branch of the multicast tree, the response packets from all switches can contain complete path information of the multicast tree. The LHR can then return and display the trace result (operation 408).

[0032] Fig. Figure 5 shows an example of a displayed multicast trace result according to one aspect of the present application. More specifically, Fig. Figure 5 shows the result of an extended multicast trace operation for a multicast group (50.1.1.1, 239.1.1.1), where 50.1.1.1 is the source IP address and 239.1.1.1 is the multicast group address. The displayed trace result 500 consists of two sections. The upper section (i.e., section 502) shows the L3 Mtrace reverse path between source 50.1.1.1 and LHR 20.1.1.2. The lower section (i.e., section 504) shows the L2 multicast trace result, which includes the MAC address of the LHR (i.e., line 1 in section 504) and the three main branches connected to the LHR (i.e., branches 506-510). Each branch can contain one or more client devices and / or one or more L2 switches. Lines a, b, and c in section 504 show the three directly connected switches / clients that sent join messages for group 239.1.1.1 to the LHR.Similarly, the entries under each L2 switch show the switches / clients directly connected to that L2 switch and listening on traffic destined for the 239.1.1.1 group. Note that the . Fig. 5 multicast path shown in Fig. 1, wherein the three branches in Fig. 5 correspond to client device 104 and switches 120 and 122, respectively. In some aspects, the result of the multicast trace may be displayed at the LHR (e.g., through a display associated with the LHR). In other aspects, the multicast trace result may be returned to the client that initiated the multicast trace operation and displayed on a display connected to the client.

[0033] Fig. Figure 6 shows a flowchart illustrating an example of a multicast path tracing process performed in a Layer 2 switch according to one aspect of the present application. During operation, an L2 switch may receive an L2 multicast trace request packet associated with a multicast group (operation 602). The request packet may include a special data block (e.g., an ARB with an extended response type of 0X2) indicating that the packet is an L2 multicast trace request packet. The request packet may be received by an LHR or an upstream L2 switch.

[0034] After receiving the request packet, the L2 switch may append a first data block to the packet containing address information about the L2 switch (operation 604). In one aspect, the first data block may be an ARB with the response type set to 0X3, and the value field of the ARB may contain the system MAC address of the L2 switch or the MAC address of the interface receiving the request packet.

[0035] The L2 switch may further determine whether client devices belonging to the multicast group can be discovered (operation 606). In some aspects, such a determination may be made based on the multicast join messages received at the L2 switch from paired devices and the LLDP information about those paired devices. For example, based on the join messages, the L2 switch may determine which paired devices are listening to traffic destined for the multicast group; and based on the LLDP messages sent by each device, the L2 switch may determine whether the device is a client device or an L2 switch (e.g., an Ethernet switch or a Wi-Fi access point). If one or more client devices paired with the L2 switch and belonging to the multicast group are discovered, the L2 switch may append a second data block to the request for each discovered client device.In one aspect, the second data block may be an ARB whose extended response type is set to 0X4, and the value field of the ARB may contain the MAC address of the corresponding client device.

[0036] The L2 switch may then determine whether it is a last-hop L2 switch (operation 610). This determination may also be made based on received multicast join messages and LLDP messages. If the L2 switch is a last-hop switch, it may generate a response packet based on the request packet appended with a number of data blocks, where each data block corresponds to a switch or client device encountered by the request packet (operation 612). Note that a client device is only considered to have been encountered by the request packet if it belongs to the multicast group and is directly coupled to a switch on the request packet's path. In one aspect, the L2 switch may convert the request packet into a response packet by changing the packet's type field from 0X02 to 0X03. The L2 switch can then send the response packet as a unicast packet to the LHR (operation 614). If the L2 switch is not a last-hop switch, i.e.it is directly connected to one or more downstream L2 switches, the L2 switch can forward the request packet with the attached data blocks to any directly connected downstream switch (operation 616).

[0037] In addition to regular L2 networks (e.g., Ethernet networks), the above-mentioned L2 multicast tracing techniques can also be applied to overlay networks with extended L2 virtual networks via VXLAN tunnel endpoints (VTEPs). The L2 multicast tracing capability can be extended to all leaf VTEPs. This is very important because current mtrace is unable to trace packets in VXLAN networks. The same solution is capable of tracing packets when the multicast route is shared between VTEPs that use both L3 Virtual Network Identifiers (VNIs) and L2 VNIs. In one example, the L2 network can comprise a Virtual System Extension (VSX) cluster, with both VSX peers behaving similarly to an L2 switch. More specifically, due to VLAN flooding, both VSX peers can receive the trace request packet from the upstream.Each peer can then perform similar L2 multicast tracing operations, which may include appending client information to the request packet. If there are clients but no further downstream L2 switches, a response packet can be sent to the LHR. If there are downstream L2 switches, the L2 multicast tracing operation continues by passing the request packet downstream.

[0038] Fig. 7A shows an example of a switch supporting Layer 2 multicast path tracing, according to one aspect of the present application. In this example, a switch 700 may include a number of communication ports 702, a packet header processor 710, and a storage device 750. Switch 700 may also include switch hardware 760 (e.g., processing hardware of switch 700, such as its application-specific integrated circuit (ASIC) chips) that contains information based on which switch 700 processes packets (e.g., determines output ports for packets). Packet header processor 710 may perform the standard packet processing function by extracting and processing header data from received packets. Packet header processor 710 may identify a switch identifier (e.g., a MAC address and / or an IP address) associated with switch 700 in the header of a packet.

[0039] The communication ports 702 may include communication channels between the switches for communication with other switches and / or user devices. The communication channels may be implemented over a standard communication port and may be based on any open or proprietary format. The communication ports 702 may include one or more Ethernet ports capable of receiving frames encapsulated in an Ethernet header. The communication ports 702 may also include one or more IP ports capable of receiving IP packets. An IP port may receive an IP packet and may be configured with an IP address. The packet header processor 710 may process Ethernet frames and / or IP packets. A corresponding port of the communication ports 702 may function as an input port and / or an output port.

[0040] Switch 700 may manage a database 752 (e.g., in storage device 750). Database 752 may be a relational database that may run on one or more DBMS (Database Management System) instances. Database 752 may store information related to the routing, configuration, and interfaces of switch 700. Switch 700 may include an L2 multicast trace logic block 730 that enables switch 700 to process an L2 multicast trace request packet.

[0041] The L2 multicast trace logic block 730 may include a multicast logic block 732, an LLDP logic block 734, an ARB appending logic block 736, a paired device discovery logic block 738, and a response generation and sending logic block 740. The multicast logic block 732 may track multicast join messages (e.g., IGMP join messages) received from paired switches and client devices. The LLDP logic block 734 may collect LLDP information about these paired switches and client devices. The ARB appending logic block 736 may be responsible for appending ARBs to a received L2 multicast trace request packet. The paired device detection logic block 738 may be responsible for detecting downstream L2 switches or client devices that are directly connected to the switch 700 via the communication ports 702.The response generation and transmission logic block 740 may be responsible for generating a response packet to the received L2 multicast trace request packet if the paired device detection logic block 738 determines that no downstream L2 switch is directly connected to the switch 700.

[0042] Fig. 7B shows an example of a computer system implemented on a Layer 2 switch to support multicast path tracing according to one aspect of the present application. Computer system 750 may include a processor 752, a memory 754, and a storage device 756. Furthermore, computer system 750 may be coupled to peripheral input / output user devices 760, such as a display device 762, a keyboard 764, and a pointing device 766. Storage device 756 may store an operating system 768, a multicast trace system 770, and data 790.

[0043] The multicast trace system 770 may include instructions that, when executed by the computer system 750, may cause the computer system 750 or the processor 752 to perform the methods and / or processes described in this disclosure. The multicast trace system 770 may include instructions for performing multicast forwarding operations (multicast forwarding instructions 772), instructions for performing LLDP operations (LLDP instructions 774), instructions for attaching ARBs to a received L2 multicast trace request packet (ARB append instructions 776), instructions for detecting paired devices (pairing device detection instructions 778), and instructions for generating and transmitting a response packet (response generation and transmission instructions 780).

[0044] Fig. 8A shows an example of a computer system enabling enhanced multicast path tracing according to one aspect of the present application. Computer system 800 may include a processor 802, a memory 804, and a storage device 806. Furthermore, computer system 800 may be coupled to peripheral input / output user devices 810, such as a display device 812, a keyboard 814, and a pointing device 816. Storage device 806 may store an operating system 818, an enhanced multicast trace system 820, and data 840. In some aspects, computer system 800 may be embodied as various functional blocks in an L3 router (e.g., the LHR in a multicast network).

[0045] The enhanced multicast trace system 820 may include instructions that, when executed by the computer system 800, may cause the computer system 800 or the processor 802 to perform the methods and / or processes described in this disclosure. In particular, by executing these instructions, the computer system 800 may achieve the goal of performing multicast tracing on both the L3 and L2 networks.The enhanced multicast trace system 820 may include instructions for performing the L3 M-Trace operation (L3 M-Trace instructions 822), instructions for tracking devices that send multicast join messages (multicast join tracking instructions 824), instructions for collecting LLDP information about paired devices (LLDP instructions 826), instructions for generating an L2 multicast trace request packet (L2 multicast request generation instructions 828) and instructions for sending the L2 multicast trace request packet to downstream L2 switches (L2 multicast request send instructions 830), instructions for receiving L2 multicast response packets (L2 multicast response receive instructions 832), instructions for aggregating path information from multiple L2 multicast response packets (path information aggregation instructions 834) and instructions for displaying the multicast path information (path information display instructions 836).

[0046] Fig. Figure 8B shows an example of a Layer 3 router supporting enhanced multicast path tracing according to one aspect of the present application. In this example, a router 850 may include a number of communication ports 852, a packet header processor 860, and a memory device 890. Router 850 may also include packet processing hardware 854 (e.g., its application-specific integrated circuits (ASIC chips)). Packet header processor 860 may perform the standard packet processing function by extracting and processing header data from received packets.

[0047] The communication ports 852 may include IP ports and Ethernet ports. The packet header processor 860 may process IP packets and Ethernet frames. A corresponding port of the communication ports 852 may function as an input port and / or an output port.

[0048] Router 850 may manage a database 892 (e.g., in storage device 890). Database 892 may be a relational database that may run on one or more DBMS (Database Management System) instances. Database 892 may store information related to the routing, configuration, and interfaces of router 850. Router 850 may include a multicast trace logic block 870 that may facilitate enhanced multicast trace operation.

[0049] L2 multicast trace logic block 870 may include an L3 multicast logic block 872, a multicast join tracking logic block 874, an LLDP logic block 876, an L2 multicast request generation and transmission logic block 878, an L2 multicast response reception logic block 880, and a path information collection and display logic block 882. L3 multicast logic block 872 may perform the standard mtrace operation. Multicast join tracking logic block 874 may trace multicast join messages (e.g., IGMP join messages) received from paired switches and client devices. LLDP logic block 876 may collect LLDP information about these paired switches and client devices. The L2 multicast request and send logic block 878 may be responsible for generating and sending an L2 multicast request packet to each coupled L2 switch. The L2 multicast response receive logic block 880 may receive the response packet from the last-hop L2 switches.The path information aggregation and display logic block 882 may aggregate L2 path information from received response packets and display the L2 and L3 path information.

[0050] In the Fig. In the examples shown in Figures 7A-8B, the L2 switch and the L3 router are depicted as separate units. In practice, it is also possible to integrate an L2 switch and an L3 router into a single device that can perform both L3 routing and L2 switching functions.

[0051] In general, the proposed solution extends the current multicast tracing functionality in the L3 network to the L2 domain. Specifically, the solution involves configuring the LHR to create a new type of request packet, an L2 multicast trace request packet. The L2 multicast trace request packet can contain an extended response block (ARB) with predefined type and value fields and can be forwarded to all downstream L2 switches connected to the LHR based on the IGMP join information for the traced multicast group. The join information can indicate which port previously received a join request for the multicast group.Each L2 switch receiving the L2 multicast trace request packet can append an ARB with its own address information and an ARB for each directly paired client device belonging to the multicast group. The L2 switch can forward the request packet downstream until it reaches a last-hop L2 switch. After appending ARBs with its own address information and address information for paired client devices, a last-hop L2 switch can convert the L2 multicast trace request packet into an L2 multicast trace response packet, which can now contain the ARBs from all encountered switches and client devices. The last-stop L2 switch can then send the L2 multicast trace response packet as a unicast packet to the LHR, which can aggregate the path information in the response packets received from multiple last-stop L2 switches to obtain complete multicast path information.The LHR can then display the trace result, which may include both the L3 path information and the L2 path information.

[0052] One aspect of the present application may provide a system and method for enhanced multicast tracing. In operation, a Layer 3 (L3) router may receive a trace request to trace multicast paths associated with a multicast group. In response to detecting a Layer 2 (L2) switch paired with the L3 router, the L3 router may construct a request packet and send the request packet to the paired L2 switch. The request packet includes a first data block indicating that the request packet is an L2 multicast trace request, causing the L2 switch to forward the request packet to each downstream L2 switch in the multicast group until the request packet reaches a last-hop L2 switch.The L3 router may receive a response packet from the last-hop L2 switch in response to the L2 multicast trace request, the response packet comprising one or more data blocks, each data block comprising information about an L2 switch or a client device located on a traversed multicast path for the multicast group.

[0053] In a variation of this aspect, the L3 router can be a last-hop router associated with the multicast group.

[0054] In another variant, the system can detect a number of L3 routers between a source of the multicast group and the last-hop router.

[0055] In a variant of this aspect, the L2 switch coupled to the L3 router can be detected based on a multicast join message received on a corresponding interface of the L3 router.

[0056] In another variant, the multicast join message may contain an Internet Group Management Protocol (IGMP) join request that specifies a source address and a group address associated with the multicast group.

[0057] In a variant of this aspect, the first data block may contain an extended response block (ARB) that includes an Augmented Response Type field with the value 0X2.

[0058] In another variant, a data block associated with a downstream L2 switch may contain an ARB that contains an extended response type field with the value 0X3 and a value field with a media access control (MAC) address of an interface receiving the request packet.

[0059] In another variant, a data block associated with a client device may contain an ARB that includes an extended response type field with the value 0X4 and a value field with a MAC address of the client device.

[0060] In a variation of this aspect, the system may aggregate path information contained in response packets received from multiple last-hop L2 switches and return the aggregated path information to a client initiating the request.

[0061] One aspect of the present application may provide a system and method for enhanced multicast tracing. During operation, a Layer 2 (L2) switch may receive a request packet to trace multicast paths associated with a multicast group, the request packet originating from a Layer 3 (L3) router. The L2 switch may append to the request packet a first data block containing information associated with the L2 switch. In response to detecting that a client device associated with the multicast group is connected to the L2 switch, the L2 switch may append to the request packet a second data block containing information associated with the connected client device.In response to detecting that a downstream L2 switch associated with the multicast group is coupled to the L2 switch, the L2 switch may forward the attached request packet to the downstream L2 switch. In response to detecting that the L2 switch is a last-hop switch, the L2 switch may generate a response packet based on the attached request packet and send the response packet to the L3 router.

[0062] In a variation of this aspect, the client device or downstream L2 switch can be discovered based on a multicast join message and a Link Layer Discovery Protocol (LLDP) message sent by the client device or downstream L2 switch.

[0063] In another variant, the multicast join message may contain an Internet Group Management Protocol (IGMP) join request that specifies a source address and a group address associated with the multicast group.

[0064] In a variation of this aspect, the received request packet may include a third data block indicating that the request packet is an L2 multicast trace request.

[0065] In another variant, the third data block can contain an extended response block (ARB) with a type field 0X2.

[0066] In a variant of this aspect, the first data block may include an extended response block (ARB) comprising a type field 0X3 and a value field with a media access control (MAC) address of an interface receiving the request packet.

[0067] In a variation of this aspect, the second data block may include an extended response block (ARB) comprising a type field 0X4 and a value field with a MAC address of the client device.

[0068] The above description is intended to enable one skilled in the art to make and use the examples and is provided in the context of a specific application and its requirements. Various modifications to the examples shown will be readily apparent to one skilled in the art, and the general principles defined herein may be applied to other implementations and applications without departing from the spirit and scope of the present disclosure. Therefore, the scope of the present disclosure is not limited to the examples shown, but is intended to achieve the widest possible scope consistent with the principles and features disclosed herein.

[0069] The methods and processes described in the "Detailed Description" section may be embodied as code and / or data that may be stored in a computer-readable storage medium as described above. When a computer system reads and executes the code and / or data stored on the computer-readable storage medium, the computer system executes the methods and processes embodied as data structures and code stored in the computer-readable storage medium. The computer-readable storage medium may be, for example, random access memory (RAM), non-volatile random access memory (NVRAM), electrically erasable programmable read-only memory (EEPROM), a storage device, an optical disk, or the like.The computer-readable storage medium may be a non-transitory storage medium, whereby the term “non-transitory” does not include the transitory transmission signals.

[0070] Furthermore, the methods and processes described above can be integrated into hardware components or devices. The hardware components or devices can include, but are not limited to, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), dedicated or shared processors that execute a specific software unit or piece of code at a specific time, and other programmable logic components known today or later developed. When activated, the hardware components or devices execute the methods and processes contained within them.

[0071] The foregoing descriptions of examples are for purposes of illustration and description only. They are not intended to be exhaustive or to limit the scope of this disclosure to the forms disclosed. Accordingly, many modifications and variations will be apparent to those skilled in the art.

Claims

[1] A process comprising: Receiving a trace request at a Layer 3 (L3) router to trace multicast paths associated with a multicast group; in response to detecting a Layer 2 (L2) switch coupled to the L3 router, constructing a request packet and sending the request packet to the coupled L2 switch, the request packet comprising a first data block indicating that the request packet is an L2 multicast trace request, thereby causing the L2 switch to propagate the request packet to each downstream L2 switch in the multicast group until the request packet reaches a last-hop L2 switch; Receiving a response packet from the last-hop L2 switch in response to the L2 multicast trace request, the response packet comprising one or more data blocks, each data block comprising information about an L2 switch or a client device located on a traversed multicast path for the multicast group. [2] The method of claim 1, wherein the L3 router is a last-hop router associated with the multicast group. [3] The method of claim 2, further comprising detecting a number of L3 routers between a source of the multicast group and the last-hop router. [4] The method of claim 1, wherein the L2 switch coupled to the L3 router is detected based on a multicast join message received at a corresponding interface of the L3 router. [5] The method of claim 4, wherein the multicast join message comprises an Internet Group Management Protocol (IGMP) join request specifying a source address and a group address associated with the multicast group. [6] The method of claim 1, wherein the first data block comprises an Augmented Response Block (ARB) containing an extended response type field having the value 0X2. [7] The method of claim 6, wherein a data block associated with a downstream L2 switch comprises an ARB having an extended response type field set to 0X3 and a value field containing a media access control (MAC) address of an interface receiving the request packet. [8] The method of claim 6, wherein a data block associated with a client device comprises an ARB including an extended response type field set as 0X4 and a value field containing a MAC address of the client device. [9] The method of claim 1, further comprising: Aggregating path information contained in response packets received from multiple last-hop L2 switches; and Return the aggregated path information to a client that initiated the request. [10] A process comprising: Receiving a request packet at a Layer 2 (L2) switch to trace multicast paths associated with a multicast group, the request packet originating from a Layer 3 (L3) router; appending a first data block containing information associated with the L2 switch to the request packet; in response to detecting that a client device associated with the multicast group is connected to the L2 switch, appending a second data block containing information associated with the connected client device to the request packet; in response to detecting that a downstream L2 switch associated with the multicast group is coupled to the L2 switch, propagating the attached request packet to the downstream L2 switch; and in response to detecting that the L2 switch is a last-hop switch, generating a response packet based on the attached request packet; and Send the response packet to the L3 router. [11] The method of claim 10, wherein the client device or the downstream L2 switch is detected based on a multicast join message and a Link Layer Discovery Protocol (LLDP) message sent by the client device or the downstream L2 switch. [12] The method of claim 11, wherein the multicast join message comprises an Internet Group Management Protocol (IGMP) join request specifying a source address and a group address associated with the multicast group. [13] The method of claim 10, wherein the received request packet comprises a third data block indicating that the request packet is an L2 multicast trace request. [14] The method of claim 13, wherein the third data block comprises an extended response block (ARB) having a type field 0X2. [15] The method of claim 10, wherein the first data block comprises an extended response block (ARB) containing a type field 0X3 and a value field with a media access control (MAC) address of an interface receiving the request packet. [16] The method of claim 10, wherein the second data block comprises an extended response block (ARB) containing a type field 0X4 and a value field with a MAC address of the client device. [17] A Layer 3 (L3) router in a multicast network, the router comprising: a processor; a memory device storing instructions that, when executed by the processor, cause the processor to perform a method, the method comprising: Receiving a trace request at a Layer 3 (L3) router to trace multicast paths associated with a multicast group; in response to detecting a Layer 2 (L2) switch coupled to the L3 router, Constructing a request packet and sending the request packet to the coupled L2 switch, the request packet comprising a first data block indicating that the request packet is an L2 multicast trace request, causing the L2 switch to propagate the request packet to each downstream L2 switch in the multicast group until the request packet reaches a last-hop L2 switch; Receiving a response packet from the last-hop L2 switch in response to the L2 multicast trace request, the response packet comprising one or more data blocks, each data block comprising information about an L2 switch or a client device located on a traversed multicast path for the multicast group. [18] The L3 router of claim 17, wherein the L2 switch coupled to the L3 router is discovered based on an Internet Group Management Protocol (IGMP) join request specifying a source address and a group address associated with the multicast group. [19] L3 router according to claim 17, wherein the first data block comprises an extended response block (ARB) with a type field 0X2; wherein a data block associated with a downstream L2 switch comprises an ARB comprising a type field 0X3 and a value field carrying a Media Access Control (MAC) address of an interface receiving the request packet; and wherein a data block associated with a client device comprises an ARB containing a type field 0X4 and a value field with a MAC address of the client device. [20] The L3 router of claim 17, wherein the method further comprises: Aggregating path information contained in response packets received from multiple last-hop L2 switches; and Return the aggregated path information to a client that initiated the request.

Images