Network Working Group T. Nandy Internet Draft Hewlett-Packard Enterprise Intended status: Proposed Standard Chethan, C R Expires: December 2024 Hewlett-Packard Enterprise M. Subramanian Hewlett-Packard Enterprise June 22, 2024 Mtrace2 L2 Extensions: Traceroute Facility for Layer 2 Multicast draft-nandy-chethan-subramanian-mtrace-layer2-00 Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 21, 2024. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Tathagata, et al. Expires December 21, 2024 [Page 1] Internet-Draft Mtrace2 for Layer 2 Multicast June 2024 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This document describes extensions to IP multicast traceroute facility, named Mtrace2 version 2 (Mtrace2), to include traced path for Layer 2 multicast. Mtrace2 allows tracing the path from Last-Hop Router (LHR) to a source. Tracing the Layer 2 path from LHR till the actual receivers requires special implementations on the part of switches in the Layer 2 path. This specification describes the required functionality in multicast routers and switches. This feature functions along with the Layer 2 multicast protocols like IGMP (Internet Group Management Protocol) Snooping and MLD(Multicast Listener Discovery) Snooping. Table of Contents 1. Introduction...................................................3 2. Conventions used in this document..............................3 2.1. Definitions.................................................3 3. Overview.......................................................4 4. Specification..................................................6 4.1. Receiving an Mtrace2 Query on LHR.........................6 4.2. Sending Layer 2 Mtrace2 request...........................6 4.2.1. Destination Address..................................7 4.3. Receiving Layer 2 Mtrace2 request.........................7 4.3.1. Snooping disabled switch.............................8 4.3.2. Non supported device.................................8 4.4. Sending L2 Mtrace2 reply to LHR...........................9 4.5. Receiving Mtrace2 reply on LHR............................9 5. Packet Format.................................................10 6. Reply Timeout.................................................10 7. Security Considerations.......................................10 8. IANA Considerations...........................................11 9. References....................................................11 9.1. Normative References.....................................11 9.2. Informative References...................................11 10. Acknowledgments..............................................11 Tathagata, et al. Expires December 21, 2024 [Page 2] Internet-Draft Mtrace2 for Layer 2 Multicast June 2024 1. Introduction This document provides extensions to Mtrace2 facility described in RFC 8487[RFC8487] to include the layer 2 multicast path details. This path begins from LHR and includes the layer 2 switches that are in the path to subscribed hosts. IP hosts will subscribe to a given group by sending IGMP/MLD membership reports. The membership reports are forwarded by the switches to Querier, PIM routers in the LAN segment which then eventually reaches the LHR. On LHR, multicast traffic is forwarded to the ports where joins are received. The membership information maintained in each of these switches is used to construct the layer 2 traced path. The specification describes methods to trace the layer 2 path. Mtrace2 request packets are forwarded to the ports where membership reports are received. Every switch in the traced path appends the path details to Mtrace2 request packet and then forwards the packet to the next switch from which a join is received. The process stops when the joined port is directly connected to a client. The switch that is directly connected to the client will append the client details and send the Mtrace2 reply to LHR. LHR will receive multiple such response packets each of which carries the path information from LHR to an L2 switch. Additional information can be included by the switches which can help in troubleshooting problems. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying significance described in RFC 2119. 2.1. Definitions First-Hop Router (FHR): The router that is directly connected to the source that the Mtrace2 Query specifies. Last-Hop Router (LHR): Tathagata, et al. Expires December 21, 2024 [Page 3] Internet-Draft Mtrace2 for Layer 2 Multicast June 2024 A router that is directly connected to a receiver. It is also the router that receives the Mtrace2 Query from an Mtrace2 client. Upstream router: The router, connecting to the Incoming Interface of the current router, is responsible for forwarding data for the specified source and group to the current router. 3. Overview Mtrace2 allows tracing the path from Last-Hop Router (LHR) to a source. In a multicast distribution tree, once the LHR routes the packet to a LAN segment, the packets are forwarded towards the clients based on the layer 2 forwarding rules governed by IGMP/MLD snooping. If IGMP/MLD snooping is not enabled, the switch will broadcast the packets to all ports in the LAN segment. The details specific to building layer 2 distribution tree using IGMP[RFC3376] or IGMP snooping[RFC4541] are outside the scope of this document. It is important to note that there can be multiple receivers subscribed to the same group and multiple switches between LHR and the actual receivers. For a given receiver, the path taken by the multicast packets depends on the port where IGMP/MLD Querier is reachable as the joins are forwarded towards Querier. This document specifies methods to populate and visualize the layer 2 multicast distribution tree using Mtrace2 utility. This will enable network administrator to inspect the multicast packet path for a given source, group from source to actual receivers. As per Mtrace2 specifications, when an Mtrace2 client initiates a multicast trace, it sends an Mtrace2 Query packet to an LHR or RP for a multicast group and, optionally, a source address. The LHR/RP turns the Query packet into a Request. The LHR/RP then appends a Standard Response Block containing its interface addresses and packet statistics to the Request packet, then forwards the packet towards the source/RP. This document specifies additional steps on LHR/RP before forwarding the packet to its upstream neighbor. Note that on RP, layer 2 tree may not be present, in which case the RP must simply continue tracing the layer 3 path. Upon receiving a Mtrace2 query, LHR will initiate layer 2 tracing. LHR must start a timer whose value is set to Mtrace2 Request Response Interval (default 2 seconds). LHR should then send layer 2 Multicast Mtrace2 request to the subscribed ports and wait for Mtrace2 responses from snooping switches. Upon timer expiry, LHR should consolidate the responses from different switches and append Tathagata, et al. Expires December 21, 2024 [Page 4] Internet-Draft Mtrace2 for Layer 2 Multicast June 2024 this information in Augmented Response Blocks (ARB). The response includes the switch details, port identifier from every switch in the path and the client details. Additional information like statistics may be included for troubleshooting purposes. This completes the layer 2 tracing and LHR proceeds with layer 3 tracing by forwarding the packet to its upstream neighbor. | Mtrace2 query | v +---+----+ +------+ LHR +-----------+ | | | | | +---+-+--+ | | Mtrace2| |request | | | | | +----------+ +---+----+ | | +----+---+ | Receiver +--------+L2Switch+<----+ +-------->+L2Switch| +----------+ +---+--+-+ --+--+---+ | | | | | | Mtrace2 request | | | v | | +---+--+-+ +-v--+---+ |L2Switch| |L2Switch| +---+----+ +----+---+ | | +---+-----+ +----+---+ |Receiver | |Receiver| +---------+ +--------+ Layer 2 Mtrace request flow +---+----+ Tathagata, et al. Expires December 21, 2024 [Page 5] Internet-Draft Mtrace2 for Layer 2 Multicast June 2024 +------+ LHR +-----------+ | | | | | ++---+--++ | | ^ ^ ^ Mtrace2 L2 | | | | | Response | +----------+ +---+----+ | | | +----+---+ | Receiver +--------+L2Switch+--+ | | |L2Switch| +----------+ +---+----+ | | +----+---+ | | | | | | | | +---+----+ | | +-v--+---+ |L2Switch+------+ +-------+L2Switch| +---+----+ +----+---+ | | +---+-----+ +----+---+ |Receiver | |Receiver| +---------+ +--------+ Layer 2 Mtrace response flow 4. Specification This section describes the LHR router and snooping switches behavior in the context of layer 2 Mtrace2 in detail. 4.1. Receiving an Mtrace2 Query on LHR Mtrace2 operation starts when a Mtrace2 client invokes query towards LHR/RP. There are no additional changes specific to layer 2 tracing. Packet format remains the same for both layer 2 and layer 3 Mtrace2 Query. When LHR receives the Mtrace2 Query, it should invoke both layer 2 and layer 3 tracing, if supported. 4.2. Sending Layer 2 Mtrace2 request Upon receiving an Mtrace2 Query message and validating the Query message, LHR should initiate layer 2 tracing process. LHR should convert the message type from query to request. Based on the membership reports, LHR may be routing the incoming multicast packets to several interfaces. Tathagata, et al. Expires December 21, 2024 [Page 6] Internet-Draft Mtrace2 for Layer 2 Multicast June 2024 For every interface in outgoing interface list, LHR maintains the membership state information on a per port and per group basis. LHR should use this information and replicate the request packet to every port where a join is received. If LHR does not have snooping enabled, then the multicast data packets are flooded on all the ports in the LAN segment. LHR should send the layer 2 Mtrace2 request on all the ports in the LAN segment if snooping is disabled. Before sending the request packet, LHR should append a new ARB which contains the system MAC address of the switch. The new ARB should have type code set to 0x0002. Section 6 describes the new type codes introduced for layer 2 tracing. One more ARB which includes the joined port identifier should be appended. Joined Port Identifier ARB should have type code set to 0x0004. Layer 2 switches downstream may not have a valid IP address configured on the snooping enabled interfaces. Additionally, there can be multiple recipients for the flow. So, it is not possible to send the layer 2 Mtrace2 request as an unicast packet. The destination address is set to multicast address as described in the below section. 4.2.1. Destination Address Layer 2 Mtrace2 request packets are destined to all layer 2 snooping switches in the LAN segment. The IP destination address is set to the All-Snoopers multicast address. RFC 4286[RFC4286] also uses All-Snoopers destination IP for Multicast Router Discovery(MRD). MRD uses IGMP/MLD packets with All-Snoopers destination IP. Switches should differentiate the packets based on the payload. Layer 2 Mtrace2 messages are UDP based. 4.3. Receiving Layer 2 Mtrace2 request Snooping switches that are directly connected to the LHR will receive the layer 2 Mtrace2 request packets sent by the LHR. The switch MUST verify the following: o The request packet is originated from a multicast router that it has learnt already via PIM Hello messages. o The checksum is correct and the IP destination address is the All-Snoopers multicast address. TTL of the packet should be set to 1. o For IPv6, the IP source address MUST be a link-local address. Tathagata, et al. Expires December 21, 2024 [Page 7] Internet-Draft Mtrace2 for Layer 2 Multicast June 2024 Request packets that do not meet the above requirements MUST be silently discarded and may be logged in a rate-limited manner. Destination IP in the packet along with the destination UDP port number is used to identify the packet as a layer 2 Mtrace2 packet. The receiving switch should append a new ARB which contains the system MAC of the switch. The new ARB should have type set code set to 0x0002. Section 6 describes the new type codes introduced for layer 2 tracing. System MAC ARB MUST be the first ARB in the request packet. The switch should then read the multicast forwarding table for the given group to get a list of ports where joins are received. For every port in this list, the request packet is replicated, and a new ARB is appended which includes the joined port identifier. The new ARB should have type code set to 0x0004. Additional ARBs like up time, expiry time, system name can be optionally included in the trace request packet. If the joined port is connected to another switch, then the packet is sent out of the port to the next switch in the path. Using the capabilities learnt from LLDP neighbor discovery, the switch could identify if the device connected to a port is an end host or not. If it's connected to end host, the Mtrace2 request should be terminated and a new ARB with type code 0x0003 containing the MAC address of the end client is appended to the packet. Additional information like the hostname of the client, type of device etc. can be optionally included in the packet. After appending the ARBs, the Mtrace2 request packet is converted to MTrace2 response packet and is sent back to LHR as a unicast message. 4.3.1. Snooping disabled switch If IGMP/MLD snooping is not enabled on the switch, the incoming data packets are flooded on all the ports in the LAN segment. In this case, the switch may forward the layer 2 request packets to all the ports after appending ARBs with switch's information and port identifier. Mtrace2 request should be terminated if the ports are connected to end hosts. 4.3.2. Non supported device If the switch does not support Mtrace2, it may flood the incoming Mtrace2 request packets without any modifications to the incoming request. In this case, the traced path will not include the switch details. Since LHR does not get any response in this case, it should complete the layer 2 trace after the Mtrace2 request response timer expiry. Tathagata, et al. Expires December 21, 2024 [Page 8] Internet-Draft Mtrace2 for Layer 2 Multicast June 2024 4.4. Sending L2 Mtrace2 reply to LHR When the switch terminates the layer 2 Mtrace2 request, it should change the request packet into a reply, and unicast the reply to the LHR. LHR's IP will be present in the source IP of the request packet. It should be used as the destination IP in the reply packet. If the switch does not have a valid IP address, then it may use the all- zeros IP Source-Address to send the reply to LHR. LHR must not discard the Mtrace2 reply packets received by the snooping switch with all-zeros IP Source-Address. If appending the ARB makes the total packet size to exceed the MTU of the incoming interface, the snooping switch must change the Forwarding Code in the last Standard Response Block of the received Mtrace2 Request into NO_SPACE and send it to LHR. The traced path will include all the switches till the NO_SPACE error is encountered. 4.5. Receiving Mtrace2 reply on LHR LHR receives Mtrace2 replies from the snooping switches. LHR MUST verify that the checksum is correct and TTL of the packet should be set to 1. LHR must not discard the Mtrace2 reply packets received by the snooping switch with all-zeros IP Source-Address. Multiple reply packets will reach LHR. LHR should process all the reply packets till Mtrace2 request response timer expiry. LHR should discard the reply packets that arrive after the timer expiry. Every reply packet contains several ARBs which includes the traced path from LHR to a given receiver. Total number of ARBs that contains code 0x002 indicate number of switches in the path. LHR uses switch MAC ARB to identify beginning of a new switch, since every switch appends switch MAC as first ARB (code = 0x0002) in the request packet. Type code 0x0003 is used to identify the MAC of an end client device. Section 6 describes the ARB types introduced for layer 2 tracing. LHR should process the reply packet and cache the path details. The reply cache should be kept till the Mtrace2 request response timer expiry. Upon timer expiry, LHR should consolidate the information cached from multiple reply packets. Consolidated information can be visualized as the layer 2 distribution tree for the given group. A new Mtrace2 request packet should be formed and LHR should append a SRB with its own details for layer 3 tracing. Consolidated layer 2 path details are then appended into the request packet using one or multiple Augmented Response Blocks. Once this packet is formed, layer 2 tracing process is complete and regular layer 3 tracing begins. The new Mtrace2 request packet should be forwarded to its upstream l3 neighbor to continue with the regular l3 tracing. When the tracing is complete and Mtrace2 client receives a reply, the packet will include Tathagata, et al. Expires December 21, 2024 [Page 9] Internet-Draft Mtrace2 for Layer 2 Multicast June 2024 the path from FHR to LHR and the layer 2 tree details from LHR till the last switch that is connected to a receiver. 5. Packet Format Layer 2 tracing uses the Augmented Response Block. The format of the packet remains the same. New types are introduced for the 'Augmented Response Type' column to include layer 2 path specific details. New types added to the Augmented Response Type are listed below: Code Type ====== ======================== 0x0002 System MAC address 0x0003 Client MAC address 0x0004 Joined Port Identifier 0x0005 System name (Optional) 0x0006 Up Time (Seconds since epoch, Optional) 0x0007 Expiry Time (In seconds, Optional) 0x0008 Client Hostname (Optional) 0x0009 Client Device Type (Optional) 6. Reply Timeout Mtrace2 defines the [Mtrace2 Reply Timeout] value to time out an Mtrace2 reply(default 10 seconds). This document defines [Mtrace2 Request Response Interval] on LHR to time out the layer 2 tracing. By default, this is set to 2 seconds. It can be administratively changed on LHR. 7. Security Considerations All the security considerations listed for Mtrace2 applies for layer 2 tracing as well. Tathagata, et al. Expires December 21, 2024 [Page 10] Internet-Draft Mtrace2 for Layer 2 Multicast June 2024 8. IANA Considerations This document does not contain any IANA actions. 9. References 9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997 [RFC8487] Asaeda, H., Meyer, K., and W. Lee, Ed., "Mtrace2 Version 2: Traceroute Facility for IP Multicast", RFC 8487, DOI 0.17487/RFC8487, October 2018. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002. [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", RFC 4286, DOI 10.17487/RFC4286, December 2005. 9.2. Informative References [RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006. 10. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Tathagata, et al. Expires December 21, 2024 [Page 11] Internet-Draft Mtrace2 for Layer 2 Multicast June 2024 Authors' Addresses Tathagata Nandy Hewlett Packard Enterprise Mahadevapura, Bangalore 560048 Email: tathagata.nandy@gmail.com Chethan C R Hewlett Packard Enterprise Mahadevapura, Bangalore 560048 Email: chethu123@gmail.com Subramanian Muthukumar Hewlett Packard Enterprise Mahadevapura, Bangalore 560048 Email: subu690@gmail.com Tathagata, et al. Expires December 21, 2024 [Page 12]