Preventing transmission of repeated multicast traffic flows by high availability network device pairs

Abstract

The disclosure relates to preventing high availability network device pairs from transmitting repeated multicast traffic flows. A process includes receiving a join request at a downstream interface of a high availability network device pair. The pair of available network devices includes a first network device and a second network device. The join request represents a request by a client device to join a multicast group associated with a source address and a multicast group address. The process includes deriving, by the first network device, first static multicast routing information from a second interface of the first network device in response to the join request. The first static multicast routing information corresponds to routing of multicast traffic associated with the multicast group through the first network device. The process further includes, in response to the join message, controlling, by the second network device, derivation of the second static multicast routing information from the second network device to prevent repeated multicast traffic associated with the multicast group from being sent by the high availability pair. The second static multicast routing information corresponds to routing of multicast traffic associated with the multicast group through the second network device.

Description

Background Art

[0001] There are many different ways to transmit data between a source network device and a recipient network device. For example, in unicast communication (one-to-one transmission), data is sent from a source network device to a specific recipient network device. As another example, in broadcast communication (one-to-many transmission), data is sent from a source network device to all network devices located in a network or a specific subnet. As another example, in multicast communication (one-to-many transmission), data is sent from a source network device to a collection of recipient network devices belonging to a specific multicast group. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Figure 1 is a block diagram of a network with a high availability (HA) router pair that selectively derives static multicast routes in a manner that prevents the HA pair from sending duplicate multicast traffic flows, according to an example implementation.

[0003] Figure 2 is a flow diagram depicting a process used by a Selective Static Multicast Route Export (SSMRE) engine of an HA router pair according to an example implementation.

[0004] Figure 3 is an illustration of selective delivery of a Protocol Independent Multicast (PIM) join by a secondary router in a HA router pair according to an example implementation.

[0005] Figure 4 is an illustration of routing of multicast traffic through a network including a multicast distribution tree arranged to prevent HA router pairs from sending duplicate multicast traffic streams according to an example implementation.

[0006] Figure 5 is a flow chart depicting a process by a network device in a HA network device pair for selectively deriving static multicast routes to prevent the HA pair from sending duplicate multicast traffic flows, according to an example implementation.

[0007] Figure 6 is an illustration of machine-readable instructions stored on a machine-readable storage medium according to an example implementation that, when executed by a router in a HA router pair, causes the router to selectively derive static multicast routes to prevent the HA pair from sending duplicate multicast traffic flows.

[0008] Figure 7 is a block diagram of a system including a pair of network devices that provide a virtual switch that selectively derives static multicast routes to prevent the virtual switch from sending duplicate multicast traffic flows, according to an example implementation. DETAILED DESCRIPTION

[0009] The following detailed description refers to the accompanying drawings. Where possible, the same reference numerals are used in the drawings and the following description to refer to the same or similar parts. However, it is to be clearly understood that the drawings are for illustration and description purposes only. Although several examples are described in this document, modifications, adaptations and other implementations are also possible. Therefore, the following detailed description does not limit the disclosed examples. On the contrary, the correct scope of the disclosed examples can be defined by the appended claims.

[0010] The terms used herein are only for the purpose of describing specific examples and are not intended to be limited. As used herein, unless the context clearly indicates otherwise, the singular forms "one", "one" and "the" are also intended to include plural forms. As used herein, the term "multiple" is defined as two or more than two. As used herein, the term "another" is defined as at least the second or more. Unless otherwise indicated, as used herein, the term "connection" is defined as connection, whether directly without any intermediate element or indirectly using at least one intermediate element. Two elements can be mechanically coupled, electrically coupled or communicated through a communication channel, a path, a network or a system. As used herein, the term "and / or" refers to and covers any and all possible combinations of the listed items associated. It is also understood that although the terms first, second, third, etc. can be used to describe various elements in this article, these elements should not be limited by these terms because these terms are only used to distinguish one element from another element, unless otherwise specified or the context indicates otherwise. As used herein, the term "including" refers to including but not limited to, and the term "including" refers to including but not limited to. The term "based on" refers to at least partially based on.

[0011] A network may include one or more routers, which may serve many different roles. For example, a router may be part of a network access layer at the edge of the network, connecting network end devices (e.g., client devices and source devices) to the network. As another example, a router may be part of a high-speed core layer of a network. As another example, a router may be part of a distribution layer that connects the core layer and the access layer.

[0012] A network can deliver multiple multicast service streams. A given multicast service stream can include data (e.g., a datagram or a sequence of packets) received by a specific multicast group of receiving network devices (referred to herein as "client devices"). A multicast group and a corresponding multicast service stream can be identified by a multicast group address and a source address. The source address corresponds to the source of the multicast service stream. A multicast group can have an associated network structure called a multicast distribution tree, which defines the routing between the multicast source and the client devices. In an example, the multicast distribution tree can be a source tree where the multicast source is the root of the tree. In another example, the multicast distribution tree can be a rendezvous tree in which a specific forwarding network device or rendezvous point is the root of the tree.

[0013] Protocols such as the Simple Service Discovery Protocol (SSDP) can be used by providers of multicast services (e.g., print services, streaming services, or other services) to advertise services, and SSDP can be used by client devices to subscribe to multicast services. A client device can join a specific multicast group (and thus subscribe to a multicast service) by sending a join message (e.g., an Internet Group Management Protocol (IGMP) message), which indicates that the client device wants to become a member of the multicast group and receive the corresponding multicast traffic stream. An IGMP message generally refers to a message having a specific format (e.g., a specific format) that conforms to the IGMP protocol, such as IGMPv2 defined in Request for Comments (RFC) 2236 or IGMPv3 defined in RFC 3376 and RFC 4604. An IGMP message includes a message type, such as a query or a join; and the IGMP message can also specify a group address. An IGMP message can specify a multicast source address. A router can add itself to a multicast distribution tree of a specific multicast group by sending a join message (e.g., a Protocol Independent Multicast (PIM) join message) to the root of the multicast distribution tree.

[0014] Due to the nature of multicast communications, a given router may receive packets corresponding to duplicate multicast traffic flows on multiple ingress interfaces of the router. In this context, an "ingress interface" refers to a port or interface of a router that receives a particular packet. An "egress interface" refers to a port or interface of a router that is used by the router to send a particular packet. For purposes such as reducing network congestion and preventing loopbacks, a router may perform a reverse path forwarding (RPF) check on a received multicast packet to determine whether the router will select the ingress interface on which the packet is received as the egress interface to send the packet to the source of the received multicast packet. If the router determines that the ingress interface will be selected by the router as the interface to reach the source, the router sends the packet, otherwise, the router discards the packet.

[0015] The effect of the router's RPF check is that the router has a single RPF interface for a given multicast group, and the router discards packets corresponding to the same given multicast group that are received at other non-RPF ingress interfaces of the router. The RPF check prevents the router from potentially sending duplicate multicast traffic flows. In general, challenges may arise if a client device receives duplicate multicast traffic flows, as the duplicate multicast traffic flows may cause any of a number of adverse effects, such as causing the client device to malfunction or causing a denial of service.

[0016] A network may include one or more pairs of high availability (HA) routers. In this context, a HA network device pair, such as an HA router pair, refers to a network device pair that provides failover capabilities such that if one network device in the HA pair fails, the other network device in the HA pair takes over the failed network device without interruption. In an example, for an HA router pair, each router in the HA pair can independently maintain its own control plane and forward data while keeping synchronization with important routing information (e.g., media address control (MAC) addresses and address resolution protocol (ARP) addresses) currently being used by the other router. In this way, if a router in the HA pair fails, the other router in the HA pair has routing information to take over the failed router. Routers can exchange routing information by passing messages to each other via inter-switch communication links that communicatively connect the routers.

[0017] A particular HA router pair may correspond to a distribution layer of a network, and a multicast distribution tree for a particular set of multicast groups may terminate at the HA router pair. The interfaces of the routers in the HA pair may be aggregated together as part of a link aggregation group to form a corresponding multicast export interface (e.g., an interface associated with a virtual local area network (VLAN) identifier) ​​of the HA pair, which provides multicast services to one or more downstream client network devices. Although each router in the HA pair may use an RPF check to ensure that the router does not send duplicate multicast service streams, the RPF check does not prevent the HA pair from sending duplicate multicast service streams as a single entity. In this way, two routers may receive the same multicast service stream on corresponding RPF interfaces, and each router may correspondingly send the received multicast service via the multicast export interface of the HA pair, resulting in duplicate multicast streams being sent to client devices.

[0018] According to example implementations described herein, HA router pairs are constructed to configure a multicast distribution tree in a manner that prevents the HA pair from sending duplicate multicast traffic flows. More specifically, according to some implementations, HA router pairs are constructed to prevent more than one RPF interface of the HA pair from being added to a particular multicast distribution tree. Since the multicast distribution tree is configured in this manner, RPF checks can be effectively used by routers to discard duplicate packets of the same multicast flow.

[0019] In an example, as further described herein, a specific router in a HA router pair can be constructed to prevent any interface of the router (which may be an RPF interface of a multicast traffic flow) from becoming part of the corresponding multicast distribution tree. In this way, due to the configuration of the multicast distribution tree and the RPF check used by the specific router, the specific router discards all multicast packets of the multicast group. The other non-specific router in the HA router pair discards all packets of the multicast group, except for the multicast packets received on the RPF interface of the non-specific router for the multicast group. Therefore, the HA router pair does not send duplicate multicast traffic flows.

[0020] A given router may be part of one or more multicast distribution trees. In one approach, the router learns the source addresses, group addresses, and upstream interfaces of different multicast distribution trees from data traffic. Also, with this approach, the router uses a dynamic protocol (such as the PIM Sparse Mode (SM) or PIM Dense Mode (DM) protocols) to derive the corresponding downstream interfaces. However, building multicast distribution trees in this manner may place a significant burden on the router, and this burden may increase with the number of client devices and with the number of routers.

[0021] In another method, the router can be configured with a static multicast table, which can define static routes through the router for different corresponding multicast groups. In an example, the static multicast table can have a record or entry corresponding to the corresponding multicast group. In this way, in order to identify a specific multicast group, each entry can contain a 2-tuple of a multicast source address and a multicast group address. In an example, the entry of the static multicast table can associate the corresponding multicast group with the ingress interface of the router and the egress interface of the router. The static multicast table can have multiple entries, which correspond to the same multicast group, but are associated with different (multiple) ingress interfaces and / or (multiple) egress interfaces. Moreover, the entry of the static multicast table can be compressed, because by using a wildcard symbol (e.g., a wildcard symbol of a source address), a single entry of the static multicast table can be associated with multiple multicast groups (e.g., groups sharing the same group address) that share the same ingress interface and egress interface.

[0022] Using the static multicast routing method, a router can export the router's static multicast routes for a given multicast group to other routers through a redistribution operation. The exported static multicast routes allow other routers to build or update their corresponding static multicast tables. In response to an ingress interface of the router receiving a PIM join / IGMP join associated with a given multicast group, the router can export the router's static multicast routes for the given multicast group. In one method, in response to receiving a PIM / IGMP join at a specific ingress interface, the router can export a set of static multicast routes by embedding information describing the static multicast routes in a PIM join set that the router sends to other routers.

[0023] One router in the HA pair may be designated as serving as a "primary role" (or "primary router"), while the other router in the HA pair may be designated as serving as a "secondary role" (or "secondary router"). In an example, the primary and secondary roles may be used to designate a specific router in the HA pair that takes over in the event of a failure of an inter-switch link between the routers in the HA pair (e.g., the primary router). According to further implementations, the primary and secondary designations may be based on other criteria.

[0024] According to the example implementation described herein, a HA router pair is constructed to selectively export static multicast routes for a specific multicast group in a manner that ensures that no more than a single RPF interface of the HA pair is added to the corresponding multicast distribution tree. For this purpose, according to some implementations, a specific router of the HA pair (such as a secondary router in the HA pair) includes a selective static multicast route export (SSMRE) engine. The SSMRE engine exports the static multicast routes of the secondary router in a manner that excludes any interface of the interface of the secondary router that may potentially be an RPF interface for a specific multicast group.

[0025] In an example, according to some implementations, in response to a secondary router receiving an IGMP / PIM join associated with a particular multicast group, the SSMRE engine exports static multicast routes for multicast routing on the secondary router in a manner that bypasses or omits exporting static multicast routes on any interface of the secondary router, which interface could potentially be an RPF interface for the multicast group.

[0026] According to an example implementation, for a specific multicast group, the SSMRE engine relies on the grouping or classification of the interfaces of the secondary router to determine which (multiple) interfaces should be used to export static multicast routing information and which (multiple) interfaces should be excluded from exporting static multicast routing information. Depending on the specific implementation, the SSMRE engine can perform the classification directly through the configuration information of the classification of the egress interfaces of different multicast groups, or the SSMRE engine can indirectly determine the classification through other information. Regardless of the specific entity that performs the classification, the classification identifies the potential RPF interface of the secondary router of a specific multicast group, and accordingly, the SSMRE engine excludes the interface from exporting the static multicast routing of the specific multicast group. According to some implementations, if the interface meets the following criteria, the classification can exclude the interface from exporting static multicast routing information: 1. The interface is specific to the secondary router (that is, the interface is not shared with the primary router); and 2. The interface corresponds to the next hop towards the multicast source. According to the example implementation, the interface that does not meet these two criteria will not be an RFP interface. In the example, the interface that does not meet the criteria includes an orphan interface that cannot be used to reach the multicast source. In another example, the interface that does not meet the criteria is an interface that is aggregated with an interface of a primary router. According to further implementations, one or more other criteria may define interfaces that may potentially be RFP interfaces and interfaces that will not be RFP interfaces, and the SSMRE engine may derive its static multicast routers based on these criteria.

[0027] Reference Figure 1 According to an example implementation, computer network 100 may include one or more multicast source devices 110 (referred to herein as “source devices 110”) coupled to one or more multicast receiving client devices 104 (referred to herein as “client devices 104”) via network structure 101. Figure 1 In the specific implementation depicted, the network structure 101 includes two source devices 110-1 and 110-2 and two client devices 104-1 and 104-2, although according to further implementations, the network structure may have more or less than two source devices 110 and / or more or less than two client devices 104. Figure 1 In the particular implementation depicted, network fabric 101 includes routers 120 coupled together via links 124 (eg, network cable-based links and backplane-based links). Figure 1 Seven example routers 120-1, 120-2, 120-3, 120-4, 120-5, 120-6, and 120-7 are depicted, but according to further implementations, the network structure 101 may include fewer or more than seven routers 120. Moreover, according to further implementations, the routers 120 may be configured in different Figure 1The depicted exemplary network architecture arrangement is connected.

[0028] In an example, the source device 110 may be a computer platform. As used herein, a "computer platform" refers to an electronic device having processing resources that is capable of executing machine-readable instructions (e.g., "software"). In an example, the source device 110 may be a server, such as a blade server, a rack server, or a standalone server. In another example, the source device may be an administrative or management node of a cluster (e.g., a high performance computing (HPC) cluster). In another example, the source device may be an Internet of Things (IoT) device. According to further implementations, the source device 110 may take many other forms, such as a portable computer, a desktop computer, a tablet computer, a sensor, a camera, or other electronic devices having processing resources.

[0029] Regardless of its specific form or architecture, source device 110 can provide one or more multicast service flows. In this context, a "multicast service flow" refers to the delivery of data (e.g., packets or datagrams) associated with a source address and a multicast group address of source device 110. In an example, the source address can be an IP address, and the group address can be an IP address.

[0030] In an example, source device 110 may be a content delivery server that provides a multicast service stream in order to provide a stream of audio content, visual content, or audio-visual content. In an example, the multicast service stream may be a data stream representing voice over IP (VOIP) content. In another example, the multicast service stream may contain data representing the content of a television channel. In another example, the multicast service stream may contain data representing video on demand (VOD) content. In another example, the multicast service stream may contain data representing video conferencing content. In another example, the multicast service stream may contain data representing streaming audio content. In another example, the multicast service stream may contain data representing image content captured by one or more sensors (e.g., a camera).

[0031] In another example, source device 110 may be an administrative node of a cluster, and the administrative node may provide a multicast service flow for delivering data to a selected group of computing nodes of the cluster. In an example, the multicast service flow may include data representing an installation image (e.g., an image including a root file system). In another example, the multicast service flow may include data representing a patch image.

[0032] According to further implementations, the multicast traffic stream may be associated with any of a number of different services (eg, financial services, file sharing services, printing services, learning services, data warehouse services, or other services).

[0033] In an example, the client device 104 may be a computer platform. As specific examples, the client device 104 may be a desktop computer, a laptop computer, a tablet computer, a smartphone, a storage array, a network switch, a gateway device, a router, an IoT device, a television, a wearable computer, or another electronic device with processing resources.

[0034] Regardless of its specific form or architecture, client device 104 (such as, client device 104-1) can be part of a multicast group, such as a specific multicast group corresponding to a specific address of source device 110-1 (referred to herein as a "source address") and a multicast group address. In an example, source device 110-1 can use SSDP to advertise a service, and client device 104-1 can use IGMP messaging to subscribe to or join a multicast group associated with the service. In an example, an IGMP querier (e.g., router 120-6 or another router) can send an IGMP query message to client devices 104-1 and 104-2, which identifies a specific multicast group and serves as an inquiry as to whether client devices 104-1 and 104-2 want to become or be members of the multicast group. Continuing with the example, client device 104-1 can respond to the query message by sending an IGMP join message indicating that client device 104-1 wants to become or be a member of the multicast group.

[0035] According to an example implementation, the sending of an IGMP join message by the client device 104 initiates a series of IGMP / PIM joins sent upstream to the source device 110. For example, in response to receiving an IGMP join message from the client device 104, the router 120-6 may send a join message (e.g., an IGMP join message) to the source device 110 to indicate that the router 120-6 will become part of the multicast distribution tree of the multicast group. In the example, in response to the IGMP join message from the router 120-6, the router 120-4 may send a PIM join message upstream to the source device 110-1 to add the static multicast routes of the router 120-4 to the multicast distribution tree. In response to receiving the PIM join message, the other routers 120 may use the corresponding PIM join to export their static multicast routes upstream to the source device 110-1. Exporting the static multicast routes upstream to the source device 110-1 constructs the multicast distribution tree of the multicast group.

[0036] According to some implementations, the computer network 100 may use a PIM-SM routing protocol that assumes that the recipient client devices of the multicast group are sparsely distributed throughout the computer network 100. In other words, the PIM-SM routing protocol assumes that a given client device does not want to become a member of a given multicast group, and relies on the client device to request to join the multicast group so that the corresponding portion of the network can be added to the multicast distribution tree of the multicast group. In another example, the computer network 100 may employ a PIM-DM routing protocol that initially assumes that for a given multicast group, all client devices are part of the multicast group. According to the PIM-DM protocol, the computer network 100 prunes or removes paths of the computer network 100 from the multicast distribution tree that do not contain client devices that have subscribed to the multicast group.

[0037] In the context used herein, a "router" generally refers to a network device that connects multiple networks together and is constructed to identify and respond to a multicast communication protocol (e.g., a PIM-SM protocol or a PIM-DM protocol). In an example, a router can operate at the third level (L3) of the open system interconnection (OSI) model. In an example, a router can be a component of an L3 switch, a gateway, a multicast router, a bridge, a gateway, a Z-generation or a computing high-speed link (CXL) network, a processor device, or a fabric switch including one or more of the foregoing devices.

[0038] According to an example implementation, router 120 includes a plurality of ports or interfaces 122 for connecting router 120 to different networks. Figure 1 In the depicted example implementation, router 120-4 has three interfaces 122-1, 122-2, and 122-3, which are connected to interface 122-3 of router 120-2, interface 122-2 of router 120-3, and interface 122-1 of router 120-6 via corresponding links 124, respectively. Figure 1 As depicted in the example implementation of , router 120-5 has four interfaces 122-1, 122-2, 122-3, and 122-4, which are connected to interface 122-2 of router 120-2, interface 122-3 of router 120-3, interface 122-1 of router 120-7, and interface 122-2 of router 120-6 through corresponding links, respectively.

[0039] According to an example implementation, when a given router 120 receives a multicast packet on an ingress interface 122, the router 120 determines whether the ingress interface 122 is the RPF interface for the multicast packet. In general, an "RPF interface" refers to an interface 122 of a router 120 that corresponds to an optimal unicast route (as determined by the router 120) to the source of the packet (e.g., a rendezvous point (RP) device or source device 110). The router 120 may determine the optimal unicast route using any of a variety of different techniques.

[0040] If the router 120 determines that the ingress interface 122 at which the multicast packet is received is not the RPF interface for the multicast packet, then the router 120 discards the multicast packet. If the router 120 determines that the ingress interface at which the multicast packet is received is the RPF interface for the multicast packet, then according to an example implementation, the router 120 sends the packet on its egress interface 122. In this way, although the router 120 may receive the same multicast packet on multiple ingress interfaces, due to the RPF check, the router 120 discards all received multicast packets except for the multicast packet received on the RPF interface 122.

[0041] In an example, as part of the RPF check, router 120 may first check a multicast forwarding table to determine whether an entry of the multicast forwarding table corresponds to a received multicast packet. The entries of the multicast forwarding table may be associated with different (S, G) tuples, where "S" represents the source address of a particular multicast group and "G" represents the group address of a particular multicast group. The entry identifies the interface 122 of router 120 associated with the (S, G) tuple. If router 120 determines that the entry of the multicast forwarding table corresponds to the received multicast packet, then the entry identifies the RPF interface.

[0042] If the multicast forwarding table does not contain an entry corresponding to the multicast packet, then according to an example implementation, router 120 can determine an RPF route (e.g., an optimal unicast route) back to the source of the multicast packet and identify the RPF interface for the multicast packet accordingly. Router 120 can then create an entry in the multicast forwarding table for the multicast group and the corresponding identified RPF interface.

[0043] Based on the RPF interface identified by the multicast routing table or the RPG interface identified by the router 120 that determines the RPF route, the router 120 determines whether the interface 122 receiving the multicast packet is an RPF interface. Based on this determination, the router 120 drops the multicast packet (if the interface 122 is not an RPF interface) or sends the multicast packet on all outgoing interfaces 122 (if the interface 122 is an RPF interface).

[0044] against Figure 1In the depicted example implementation, routers 120-4 and 120-5 together form a virtual switch 160. According to the example implementation, virtual switch 160 corresponds to a high availability (HA) router pair that are both active (assuming neither router 120-4 or 120-5 fails) and maintain their respective control planes independently of each other. According to the example implementation, using inter-switch communication link 151, routers 120-4 and 120-5 share information (e.g., MAC addresses and ARP addresses) so that if one of routers 120-4 and 120-5 fails, the surviving router 120 can take over the control plane of the failed router 120. Figure 1 As further depicted, according to the example implementation, router 120-4 has a master role and is therefore specifically referred to as a "master router." Figure 1 As depicted, router 120-1 has a secondary role and is therefore designated as a "secondary router." According to some implementations, the designation of primary and secondary roles refers to which router 120-4 or 120-5 takes over as the sole router in HA pair 150 if inter-switch communication link 151 fails. According to further implementations, the designation of primary and secondary roles may depend on other criteria.

[0045] The interfaces of the primary router 120-4 and the secondary router 120-5 may be grouped or aggregated together. For example, according to some implementations, the interface 122-3 of the primary router 120-4 may be aggregated with the interface 122-4 of the secondary router 120-5 to form a corresponding link aggregation group (LAG) 140. Moreover, as depicted at 144, the LAG 140 may be associated with a particular VLAN identifier, such as Figure 1 Due to this association, LAG 140 is referred to herein as "VLAN10 interface 144". Figure 1 As further depicted, according to some implementations, the interface 122-1 of the primary router 120-4 may be aggregated with the interface 122-1 of the secondary router 120-5 to form a corresponding LAG 130. Additionally, as Figure 1 As further depicted, the interface 122 - 2 of the primary router 120 - 4 may be aggregated with the interface 122 - 2 of the secondary router 120 - 5 to form a corresponding LAG 134 .

[0046] Even if both primary router 120-4 and secondary router 120-5 perform RPF checks, HA pair 150 may still potentially send duplicate multicast traffic flows. For example, without the measures described herein to prevent HA pair 160 from sending duplicate multicast traffic flows, primary router 120-4 may, for example, receive a multicast traffic flow on a particular ingress interface 122, determine that ingress interface 122 is the RPF interface for the corresponding multicast group, and send the multicast packet via VLAN10 interface 144. Continuing with this example, secondary router 120-5 may receive a copy of the same multicast packet on one of its ingress interfaces 122, determine that ingress interface 122 is the RPF interface for the multicast group, and send the multicast packet via VLAN10 interface 144. Therefore, even though both primary router 120-4 and secondary router 120-5 of HA pair 160 apply RPF checks, HA pair 160 sends duplicate multicast packets.

[0047] To prevent HA pair 160 from sending duplicate multicast traffic flows, according to an example implementation, one of routers 120-4 and 120-5 includes a selective static multicast routing exchange (SSMRE) engine 170. Figure 1 Of the specific implementations depicted and described herein, secondary router 120-5 includes SSMRE engine 170. According to further implementations, primary router 120-4 may include SSMRE engine 170 (instead of secondary router 120-5).

[0048] Typically, the SSMRE engine 170 selectively derives static multicast routing information in a manner that excludes the secondary router 120-5 from receiving multicast traffic flows, and the secondary router 120-5 does not discard these multicast traffic flows using the RPF check. In other words, the SSMRE engine takes measures to exclude the secondary router 120-5 from the corresponding multicast distribution tree. Therefore, according to the example implementation, since the SSMRE engine 170 excludes the secondary router 120-5 from the multicast distribution tree, the secondary router 120-5 does not send duplicate multicast traffic.

[0049] More specifically, according to the example implementation, the SSMRE engine 170 is constructed to not export the static multicast routes of the secondary router 120-5 through its interface(s) 122, which may potentially be the RPF interface of the corresponding multicast group. Therefore, due to this exclusion, the secondary router 120-5 does not receive any multicast packets at the corresponding RPF interface 122 of the secondary router 120-5. Therefore, due to the RPF check of the secondary router 120-5, all multicast packets received by the secondary router 120-5 are discarded.

[0050] According to some implementations, the primary router 120-4 and the secondary router 120-5 may derive a specific static multicast route by sending a PIM join containing data representing the static multicast route. In an example, a specific multicast group may have a source address of "10.1.1.1" and a multicast group address of "231.1.1.1". The static multicast route for the multicast group may be defined by the source address (here "10.1.1.1"), the multicast group address (here "231.1.1.1"), the ingress interface, and the egress interface. In an example, the specific static multicast route of the primary router 120-4 for the example multicast group may include interface 122-1 as the ingress interface and VLAN10 interface 144 as the egress interface. By deriving the static route from its interface 122-1 via a PIM join, the primary router 120-4 may add the static multicast route to the corresponding multicast distribution tree. According to an example implementation, the primary router 120-4 may be configured with the specific multicast static route using the following command:

[0051] IP multicast static route R4_IF01 10.1.1.1 231.1.1.1VLAN10, where “R4_IF01” is the name of the ingress interface 122 - 1 ; “10.1.1.1” represents the source address; “231.1.1.1” represents the multicast group address; and “VLAN10” represents the VLAN10 interface 144 .

[0052] Routers 120 (such as primary router 120-4) can be programmed or configured with specific static multicast routes in any of a number of different ways. In an example, one or more static multicast routes of router 120 can be programmed via execution of an application. As another example, a human administrator can program router 120 with one or more static multicast routes.

[0053] As another example, the primary router 120-4 may have another static multicast route for the (10.1.1.1, 231.1.1.1) multicast group that specifies the interface 122-2 as the ingress interface and the VLAN10 interface 144 as the egress interface. More specifically, the primary router 120-4 may be configured with this particular static multicast route using the following command:

[0054] IP multicast static route R4_IF02 10.1.1.1 231.1.1.1VLAN10,

[0055] Here, "R4_IF02" indicates the identifier of the interface 122-2.

[0056] The secondary router 120-5 may have static multicast routes configured as follows: IP multicast static route R5_IF01 10.1.1.1 231.1.1.1 VLAN10, IP multicast static route R5_IF02 10.1.1.1 231.1.1.1 VLAN10, and IP multicast static route R5_IF05 10.1.1.1 231.1.1.1 VLAN10.

[0057] Here, "R5_IF01", "R5_IF02" and "R5_IF05" are identifiers of the egress interfaces 122-1, 122-2 and 122-5 of the secondary router 120-5, respectively.

[0058] Although secondary router 120-5 may be configured with static multicast routes, such as those set forth above, according to an example implementation, SSMRE engine 170 selectively derives these static routes to prevent multicast packets from being received on interface 122 of secondary router 120-5, which is the RPF interface for the corresponding multicast group. More specifically, according to some implementations, SSMRE engine 170 relies on a classification of interface 122 that excludes potential RPF interfaces from a set of interfaces 122 from which secondary router 120-5 derives static multicast routes. The classification may be performed by SSMRE engine 170, another component of secondary router 120-4, or another component of the computer network, depending on the particular implementation.

[0059] Regardless of the specific entity that performs the classification, according to some implementations, the classification may include three groups: Group 1, Group 2, and Group 3. Group 1 interfaces include any interface 122 of the secondary router 120-5 that is aggregated with the interface 122 of the primary router 120-4. Group 2 interfaces include any interface 122 that is specific to the secondary router 120-5 (and therefore not shared with the interface 122 of the primary router 120-4) and associated with the next hop toward the multicast source. Group 3 interfaces include any interface 122 corresponding to an isolated port specific to the secondary router 120-5. In this context, an "isolated" port or interface refers to an interface that cannot be used to reach the multicast source. According to an example implementation, if the SSMRE engine 170 determines that the interface 122 belongs to Group 1 or Group 3, the SSMRE engine 170 exports static multicast routes via a given interface 122. Moreover, according to an example implementation, the SSMRE engine 170 bypasses exporting static multicast routes through any interface 122 belonging to Group 2.

[0060] As an example, Figure 1As depicted, the specific example interface 122 of the secondary router 120-5 can be classified as follows. The interface 122 of the secondary router 120-5 is part of the LAG 130 shared with the primary router 120-4, and therefore, the interface 122-1 belongs to group 1. Therefore, the SSMRE engine 170 exports static multicast routing information via the interface 122-1 of the secondary router 120-5. As another example, the interface 122-2 of the secondary router 120-5 is specific to the secondary router 120-5 and corresponds to the next hop towards the multicast source. Therefore, according to the example implementation, the SSMRE engine 170 configures the secondary router 120-5 to bypass or prevent the static multicast routing from being exported through the interface 122-2. As another example, the interface 122-3 of the secondary router 120-5 is isolated and is accordingly classified as belonging to group 3. Therefore, the SSMRE engine 170 allows the secondary router 120-5 to export static multicast routing information via the interface 122-3.

[0061] As used herein, an "engine" may refer to one or more circuits. For example, a circuit may be a hardware processing circuit, which may include any or some combination of a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit (e.g., a programmable logic device (PLD) such as a complex PLD (CPLD)), a programmable gate array (e.g., a field programmable gate array (FPGA)), an application specific integrated circuit (ASIC), or another hardware processing circuit. An "engine" may refer to a combination of one or more hardware processing circuits and machine-readable instructions (software and / or firmware) executable on the one or more hardware processing circuits. Depending on the specific implementation, an engine may be formed solely of hardware processing circuits that execute machine-executable instructions; be formed by a combination of hardware processing circuits that execute machine-executable instructions and other hardware circuit systems that do not execute machine-readable instructions; or be formed solely of hardware circuits that do not execute machine-executable instructions. Figure 1 As depicted, according to some implementations, the SSMRE engine 170 may include one or more processors 174 (e.g., one or more central processing unit (CPU) cores or other processing circuits) that execute machine-readable instructions 178 stored in a memory 176. As an example, Figure 1 As depicted, processor(s) 174 and memory 176 may be components of secondary router 120 - 5 , according to some implementations.

[0062] According to an example implementation, a collection of physical memory devices can be used to implement memory 176. Typically, the memory devices forming memory 176 and other memories and storage media described herein are examples of non-transient machine-readable storage media. According to an example implementation, the machine-readable storage medium can be used for various storage-related and computing-related functions. As an example, the memory device may include a semiconductor memory device, a flash memory device, a memristor, a phase change memory device, a magnetic storage device, a combination of one or more of the aforementioned storage technologies, and a memory device based on other technologies. Moreover, the memory device may be a volatile memory device (e.g., a dynamic random access memory (DRAM) device, a static random access (SRAM) device, etc.) or a non-volatile memory device (e.g., a flash memory device, a read-only memory (ROM) device, etc.), unless otherwise specified herein.

[0063] Figure 2 2 is a flowchart 200 depicting a process used by SSMRE engine 170 to derive static multicast routes from secondary router 120-5, according to an example implementation. Figure 2 According to an example implementation, in response to receiving a join 202 (e.g., a PIM join or an IGMP join), the SSMRE engine 170 may perform an action based on the classification of the interfaces 122-1, 122-2, and 122-3 of the secondary router 120-5. Although in the following description, the SSMRE engine 170 determines the classification, according to further implementations, the interfaces 122-1, 122-2, and 122-3 may have been previously classified.

[0064] As depicted at 204, SSMRE engine 170 may determine that interface 122-2 is aggregated with primary router 120-4. In other words, SSMRE engine 170 determines that interface 122-2 is associated with group 1. Therefore, interface 122-2 will not be the RPF interface for any multicast packets received on interface 122-2, and therefore, as depicted at 208, SSMRE engine 170 causes secondary router 120-5 to send a PIM join from interface 122-2, which exports a static multicast route that includes interface 122-2 as an ingress interface.

[0065] As depicted at 212, the SSMRE engine 170 determines that the interface 122-1 of the secondary router 120-5 is the next hop toward the source and is specific to the secondary router 120-5. In other words, the SSMRE engine 170 determines that the interface 122-1 belongs to group 2. Therefore, the SSMRE engine 170 bypasses deriving a static multicast route via the interface 122-1, as depicted at 216, because the interface 122-1 may potentially be the RPF interface for the multicast group.

[0066] As depicted at 220, the SSMRE engine 170 determines that the interface 122-3 of the secondary router 120-5 is orphaned. In other words, the SSMRE engine 170 determines that the interface 122-3 belongs to group 3. Therefore, the SSMRE engine 170 causes the secondary router 120-5 to export a static multicast route via the interface 122-3 with the interface 122-3 as the ingress interface, as depicted at 224.

[0067] Figure 3 Diagram 300 depicts deriving static multicast routes in response to IGMP join 304 from client device 104-1 according to an example implementation. In response to receiving IGMP join 304, router 120-6 provides corresponding IGMP joins 308 and 312, which are received by primary router 120-4 and secondary router 120-5, respectively.

[0068] like Figure 3 As depicted, primary router 120-4 and secondary router 120-5 undergo corresponding redistribution operations 340 and 342, respectively. In general, the redistribution operation causes router 120 to export static multicast routes via PIM joins. More specifically, primary router 120-4 exports static multicast routes on all of its upstream interfaces, as depicted by reference numerals 320, 324, and 328. However, secondary router 120-5 selectively exports its static multicast routes. In this way, secondary router 120-5 exports static multicast routes via PIM joins through group 1 and group 3 interfaces, as depicted by 312, 316, and 320. However, as depicted by 312 (and the corresponding "X"), secondary router 120-5 does not export static multicast routes via the group 2 interface (here, the interface connecting secondary router 120-5 to router 120-3).

[0069] Also like Figure 3 As depicted, other routers 120 may also export static multicast routes upstream to build a multicast distribution tree. Figure 3 As depicted, router 120-2 may export the static multicast route upstream to router 120-2 via PIM join 336. As another example, router 120-3 may export the static multicast route via PIM join 338 to router 120-1.

[0070] Since the static multicast routes are selectively derived by the secondary router 120-5, the secondary router 120-5 is effectively excluded from the multicast distribution tree. More specifically, Figure 4 Diagram 400 depicts routing of a particular multicast traffic flow in a network according to an example implementation. Figure 4 It illustrates how the selective export of static multicast routes by secondary router 120-5 excludes secondary router 120-5 from the multicast distribution tree.

[0071] More specifically, refer to Figure 4 , since the secondary router 120-5 is excluded from the multicast distribution tree, the source device 110-1 sends a multicast service flow, such as Figure 4 As depicted, the multicast traffic flow propagates along path 410 through router 120-1, router 120-2, primary router 120-4, router 120-6, and terminates at client device 104-1. For comparison, Figure 4 A path 414 of a multicast traffic flow is depicted, which would exist if a static multicast route were not selectively derived by the secondary router 120-5. The absence of the path 414 of the multicast traffic flow is indicated by an "X" at 420. Without excluding or preventing duplicate traffic flow 414, both traffic flows 410 and 414 would otherwise reach the HA pair and cause the secondary router 120-5 to send duplicate multicast traffic flows to the VLAN10 interface 144. However, due to the selective derivation of the static multicast route by the secondary router 120-5, duplicate multicast traffic flows are prevented.

[0072] Reference Figure 5 According to an example implementation, process 500 includes receiving (block 504) a join request at a first interface of a high availability network device pair. The high availability network device pair includes a first network device and a second network device. In an example, the high availability network device pair may be a high availability router pair. In an example, the high availability network device pair may form a virtual switch. The join request represents a request by a client device to join a multicast group associated with a source address and a multicast group address. In an example, the join request may be a PIM message.

[0073] Process 500 includes deriving, by the first network device, first static multicast routing information from a second interface of the first network device in response to the join request, according to block 508. The first static multicast routing information corresponds to a route of multicast traffic associated with the multicast group through the first network device. In an example, the first static multicast routing information may identify the second interface as an ingress interface of a path through the first network device associated with the multicast group, and the first static multicast routing information may identify another interface of the first network device as an egress interface associated with the multicast group. In an example, the deriving of the first static multicast information may include the first network device sending a PIM join message in a direction toward the multicast source.

[0074] In an example, a first network device can be associated with a primary role of a high availability network device pair, and a second network device can be associated with a secondary role of the high availability network device pair. In an example, the designation of the primary role and the secondary role can be based on a particular network device that takes over in the event of a failure of an inter-switch communication link between the first network device and the second network device. In an example, if another network device in the high availability pair fails, one network device in the high availability network device pair takes over for the other network device. In an example, the takeover occurs without interruption.

[0075] According to block 508, process 500 also includes controlling, by the second network device, in response to the join message, exporting of second static multicast routing information from the second network device to prevent duplicate multicast traffic associated with the multicast group from being sent by the high availability pair. In an example, the second static multicast routing information corresponds to routing of multicast traffic associated with the multicast group through the second network device.

[0076] In an example, controlling the export of the second static routing information includes classifying the interfaces of the second network device. The classification may include identifying potential RPF interfaces of the second network device so as to exclude these interfaces from the corresponding multicast distribution tree. In an example, the classification corresponding to the potential RPF interface may take into account the criteria of whether the interface is specific to the second network device and is not associated with the first network device and whether the interface corresponds to the next hop toward the multicast source. The classification may also include classifications such as whether a particular interface is an isolated interface and whether a particular interface is associated with the first network device, and these other classifications may correspond to the interface through which the second static multicast routing information is exported.

[0077] Reference Figure 6 According to an example implementation, a non-transitory machine-readable storage medium 600 stores machine-readable instructions 610. When executed by a given router in a high-availability router pair, the instructions 610 cause the given router to receive a join request representing a request by a client device to join a multicast group associated with a source address and a multicast group address. In an example, the high-availability network device pair may form a virtual switch. In an example, the join request may be a PIM message.

[0078] In an example, a given router can be associated with a secondary role of a high availability router pair, and another router in the high availability pair can be associated with a primary role. In an example, the designation of the primary and secondary roles can be based on a particular router in the high availability pair that takes over in the event of a failure of an inter-switch communication link between the routers. In an example, one router in the high availability router pair takes over for the other router if the other router in the high availability router pair fails. In an example, the takeover occurs without interruption. In an example, the high availability router pair can be part of a distribution layer of a network.

[0079] When executed by a given router, instruction 610 further causes the given router to classify a given interface of the given router based on whether the given interface is associated with a next hop toward the source address and whether the given interface is associated with another router in the high availability router pair. When executed by the given router, instruction 610 further causes the given router to selectively derive static multicast routing information via the given interface in response to a join request based on the classification. In an example, the static multicast routing information corresponds to the routing of multicast traffic associated with the multicast group through the given router. In an example, the given router derives the static multicast routing information by sending a PIM join message containing the static multicast routing information upstream of the source address.

[0080] In an example, in response to determining that the given interface is not associated with a next hop toward a source address and determining that the given interface is not associated with another router in a high availability pair, the given router may not export static multicast routing information via the given interface. In an example, in response to determining that the given interface is isolated, the given router may export static multicast routing information via the given interface. In an example, in response to determining that the given interface is associated with another router in a high availability pair, the given router may export static multicast routing information via the given interface. In an example, in response to determining that the given interface is not associated with a next hop toward a source address, the given router may export static multicast routing information via the given interface.

[0081] Reference Figure 7According to an example implementation, the system 700 includes a network device pair 710 to provide a virtual switch. The pair 710 includes a first network device 720 and a second network device 730. In an example, the pair 710 is a high availability pair, so that if another network device 720, 730 fails, one network device 720, 730 in the pair 710 takes over the other network device 720, 730 in the pair. In an example, the pair 710 is a high availability router. In an example, the pair 710 can be part of the distribution layer of the network. In an example, the first network device 720 and the second network device 730 can communicate with each other via an inter-switch communication link. In an example, the first network device 720 and the second network device 730 can pass information (e.g., MAC addresses and ARP addresses), which is used by the surviving network devices 720, 730 if another network device 720, 730 fails.

[0082] The first network device 720 is associated with a master role of the network device pair 710. In the example, the designation of the master role corresponds to the network device in the pair 710 that takes over if an inter-switch communication link between the network switches fails.

[0083] In response to network device pair 700 receiving the join request, first network device 720 exports first static multicast routing information via a first network interface of first network device 720. The first join request represents a request by a client device to join a multicast group associated with a source address and a multicast group address, and the first static multicast routing information identifies the first network interface as an incoming interface for receiving multicast traffic associated with the multicast group, identifies an outgoing interface of the first network device for multicast traffic, identifies the source address, and identifies the group address.

[0084] In an example, the first static multicast routing information corresponds to routing of multicast traffic associated with the multicast group through the first network device 720. In an example, the first network device 720 derives the first static multicast routing information by sending a PIM join message containing the static multicast routing information upstream of the source address.

[0085] The second network device 730 is associated with the secondary role of the network device pair 700. In response to the network device pair 700 receiving the join request, the second network device 730 is configured to determine whether the second network interface of the second network device 730 is associated with the next hop towards the source address and whether the second network interface is aggregated with the interface of the first network interface. In response to the network device pair 700 receiving the join request and in response to the determination, the second network device 730 is configured to selectively derive the second static multicast routing information via the second network interface.

[0086] In an example, in response to determining that the second network interface is not associated with a next hop towards the source address and determining that the second network interface is not associated with the first network device 720, the second network device 730 may not export the second static multicast routing information via the second network interface. In an example, in response to determining that the second network interface is isolated, the second network device 730 may export the second static multicast routing information via the second network interface. In an example, in response to determining that the second network interface is associated with the first network device 720, the second network device 730 may export the second static multicast routing information via the second network interface. In an example, in response to determining that the second network interface is not associated with the next hop towards the source address, the second network device 730 may export the second static multicast routing information via the second network interface.

[0087] In an example, the second static multicast routing information corresponds to routing of multicast traffic associated with the multicast group through the second network device 730. In an example, the second network device 730 derives the second static multicast routing information by sending a PIM join message containing the static multicast routing information upstream of the source address.

[0088] According to an example implementation, the control includes determining, by the second network device, whether a second interface of the second network device corresponds to a next hop toward the source address; and selectively deriving, by the second network device, second static multicast routing information via the second interface based on the result of the determination. Specific advantages include preventing duplicate multicast traffic flows from being sent to client devices.

[0089] According to an example implementation, the second upstream interface does not correspond to a next hop towards the source address; and deriving the second multicast routing information includes communicating the second static multicast information via the second interface. Particular advantages include preventing duplicate multicast traffic flows from being sent to client devices.

[0090] According to an example implementation, the second upstream interface corresponds to a next hop toward the source address. The process also includes determining, by the second network device, whether the second interface is aggregated with an interface of the first network device; and based on the determination result of whether the second interface is aggregated, controlling the delivery of the second static multicast information via the second network interface. Specific advantages include preventing duplicate multicast traffic flows from being sent to the client device.

[0091] According to an example implementation, the second interface is aggregated with an interface of the first network device; and controlling delivery of the second static multicast information includes selectively exporting the second static multicast information via the second upstream interface. Specific advantages include preventing duplicate multicast traffic flows from being sent to client devices.

[0092] According to an example implementation, the second interface is not aggregated with an interface of the first network device; and controlling delivery of the second static multicast information includes preventing the second static multicast information from being exported via the second interface. Specific advantages include preventing duplicate multicast traffic flows from being sent to client devices.

[0093] According to an example implementation, the process includes controlling the export in response to a determination by the second network device that the second network device is associated with a secondary role of the network device pair.Particular advantages include preventing duplicate multicast traffic streams from being sent to client devices.

[0094] According to an example implementation, the process further includes the first network device and the second network device independently controlling respective control planes; and the first network device and the second network device controlling data planes as a single virtual network device. Specific advantages include preventing duplicate multicast traffic flows from being sent to client devices.

[0095] According to an example implementation, the first static multicast routing information identifies the first interface as an ingress interface for receiving multicast traffic, identifies the aggregated interface of the high availability pair as an egress interface, identifies a source address, and identifies a group address. Specific advantages include preventing duplicate multicast traffic streams from being sent to client devices.

[0096] According to an example implementation, deriving the first static multicast routing information includes sending a PIM join message via the first network interface.Particular advantages include preventing duplicate multicast traffic streams from being sent to client devices.

[0097] According to an example implementation, receiving the join message includes receiving an IGMP join message or receiving a PIM join message.Particular advantages include preventing duplicate multicast traffic streams from being sent to client devices.

[0098] While the present disclosure has been described with respect to a limited number of implementations, numerous modifications and variations thereof will become apparent to those skilled in the art having the benefit of this disclosure. The appended claims are intended to cover all such modifications and variations.

Claims

1. A method comprising: receiving a join request at a first interface of a high availability network device pair, wherein the high availability network device pair includes a first network device and a second network device, and the join request represents a request by a client device to join a multicast group associated with a source address and a multicast group address; as well as In response to the first join request: deriving, by the first network device, first static multicast routing information from a second interface of the first network device, wherein the first static multicast routing information corresponds to routing of multicast traffic associated with the multicast group through the first network device; as well as The second network device controls the export of second static multicast routing information from the second network device to prevent duplicate multicast traffic associated with the multicast group from being sent by the high availability pair, wherein the second static multicast routing information corresponds to routing of the multicast traffic associated with the multicast group through the second network device.

2. The method according to claim 1, wherein the controlling comprises: determining, by the second network device, whether a second interface of the second network device corresponds to a next hop toward the source address; as well as The second static multicast routing information is selectively derived by the second network device via the second interface based on a result of the determination.

3. The method according to claim 2, wherein: The second interface does not correspond to a next hop towards the source address; and Selectively deriving the second static multicast routing information includes communicating the second static multicast information via the second interface.

4. The method of claim 2, wherein the second interface corresponds to a next hop toward the source address, the method further comprising: Determining, by the second network device, whether the second interface is aggregated with an interface of the first network device; Selectively deriving the second static multicast information includes deriving the second static multicast information via the second network interface based on a result of the determination whether the second interface is aggregated.

5. The method according to claim 4, wherein: The second interface is aggregated with an interface of the first network device; and Selectively deriving the second static multicast routing information includes deriving the second static multicast information via the second interface.

6. The method according to claim 4, wherein: The second interface is not aggregated with the interface of the first network device; and Selectively exporting the second static multicast routing information includes preventing the second static multicast information from being exported via the second interface.

7. The method according to claim 1, further comprising: The exporting is controlled in response to a determination by the second network device that the second network device is associated with a secondary role for the network device pair.

8. The method according to claim 1, further comprising: The first network device and the second network device independently control corresponding control planes; and The first network device and the second network device control a data plane as a single virtual network device.

9. The method of claim 1, wherein the first static multicast routing information identifies the first interface as an ingress interface for receiving the multicast service, identifies the aggregated interface of the high availability pair as an egress interface, identifies the source address, and identifies the group address.

10. The method of claim 1, wherein deriving the first static multicast routing information comprises: A protocol independent multicast (PIM) join message is sent via the first network interface.

11. The method of claim 1, wherein receiving the join request comprises receiving an Internet Group Management Protocol (IGMP) message, or receiving a Protocol Independent Multicast (PIM) message.

12. A non-transitory machine-readable storage medium storing machine-readable instructions that, when executed by a given router in a high availability router pair, cause the given router to: receiving a join request, the join request representing a request by a client device to join a multicast group associated with a source address and a multicast group address; classifying a given interface of the given router based on whether the given interface is associated with a next hop toward the source address and whether the given interface is associated with another router in the pair of high availability routers; as well as In response to the join request, static multicast routing information is selectively derived via the given interface based on the classification.

13. The storage medium of claim 12, wherein the static multicast routing information identifies the given interface as an incoming interface for receiving multicast traffic, identifies an outgoing interface of the router for the multicast traffic, identifies the source address, and identifies the group address.

14. The storage medium according to claim 12, wherein: The classification indicates whether exporting the static multicast routing information through the given interface will cause the given router to receive a multicast traffic flow that is a copy of a multicast traffic flow received by the other router in the high availability router pair.

15. The storage medium of claim 14, wherein when executed by the storage medium, the instructions further cause the router to: in response to the classification indicating that the export of the static multicast routing information through the given interface will cause the given router to receive a multicast service flow, not export the static multicast routing information through the given interface, the multicast service flow being a copy of a multicast service flow received by the other router in the high availability router pair.

16. A system comprising: A network device pair, for jointly providing a virtual network switch, wherein the network device pair comprises: a first network device, wherein the first network device is associated with a master role for the network device pair, and the first network device is configured to derive first static multicast routing information via a first network interface of the first network device in response to the network device pair receiving a join request, wherein the first join request represents a request by a client device to join a multicast group associated with a source address and a multicast group address, and the first static multicast routing information identifies the first network interface as an incoming interface for receiving multicast traffic associated with the multicast group, identifies an outgoing interface of the first network device for the multicast traffic, identifies the source address, and identifies the group address; and a second network device, wherein the second network device is associated with a secondary role for the network device pair and the second network device is configured to, in response to the network device pair receiving the join request: determining whether a second network interface of the second network device is associated with a next hop toward the source address and whether the second network interface is aggregated with an interface of the first network interface; and In response to the determination, second static multicast routing information is selectively derived via the second network interface.

17. The system of claim 16, further comprising: The network includes a distribution layer, an access layer, and a core layer, and the pair of network devices is part of the distribution layer.

18. The system of claim 16, wherein the pair of network devices is to fail over to the first network device in response to a disruption in an inter-switch link between the first network device and the second network device.

19. The system of claim 16, wherein the second network device is further configured to: responsive to the determination, not exporting the second static multicast routing information via the second network interface; determining that a third network interface of the second network device is isolated; as well as In response to determining that the third network interface is orphaned, third static multicast routing information is derived via the third network interface.

20. The system of claim 16, wherein the second network device is further configured to: in response to the network device pair receiving the join request: responsive to the determination, not exporting the second static multicast routing information via the second network interface; Determining that a third network interface of the second network device is not aggregated with an interface of the first network device; as well as In response to determining that the third network interface is not aggregated with an interface of the first network device, third static multicast routing information is derived via the third network interface.

Images