PREVENTION OF HIGH AVAILABILITY PAIRS OF NETWORK DEVICES TO PREVENT THE OUTPUT OF DOUBLE MULTICAST TRAFFIC FLOWS

Abstract

A process involves receiving a connection request at a downstream interface of a highly available pair of network devices. The availability pair of network devices comprises a first network device and a second network device. The connection request represents a request from a client device to join a multicast group associated with a source address and a multicast group address. In response to the connection request, the process involves the first network device exporting initial static multicast route information from a second interface of the first network device. This initial static multicast route information corresponds to the routing of multicast traffic associated with the multicast group by the first network device.The process further includes, in response to the join message, controlling the export of second static multicast route information from the second network device to prevent duplicate multicast traffic associated with the multicast group from being sent by the high-availability pair. The second static multicast route information corresponds to routing the multicast traffic associated with the multicast group through the second network device.

Description

BACKGROUNDThere are various ways in which data can be transmitted between source and receiver network devices. In unicast communication, which is a one-to-one transmission, data is transmitted from a source network device to a particular receiver network device. Another example is broadcast communication, in which data is sent from a source network device to all network devices that are located in a network or in a specific subnet, i.e., a one-to-multiple transmission. Another example is multicast communication, in which data is sent from a source network device to a group of receivers belonging to a particular multicast group.BRIEF DESCRIPTION OF THE DRAWINGSFIG. 1 is a block diagram of a network having a high availability (HA) router pair that selectively exports static multicast routes in a manner that prevents the HA pair from sending duplicate multicast traffic streams, according to an example implementation. FIG. 2 is a flow diagram illustrating a process used by a selective static multicast route export engine (SSMRE) of an HA router pair, according to an example implementation. FIG. 3 illustrates selective communication of protocol independent multicast (PIM) joins by a secondary router of an HA router pair, according to an example implementation. FIG. 4 illustrates the forwarding of multicast traffic through a network that includes a multicast distribution tree that is configured to prevent an HA router pair from sending duplicate multicast traffic streams, according to an example implementation. FIG. 5 is a flow diagram illustrating a process used by a network device of an HA pair of network devices to selectively export static multicast routes to prevent the HA pair from sending dual multicast traffic streams, according to an example implementation. FIG. 6 is an illustration of machine readable instructions stored on a machine readable storage medium that, when executed by a router of an HA pair of routers, cause the router to selectively export static multicast routes to prevent the HA pair from sending dual multicast traffic streams, according to an example implementation. FIG. 7 is a block diagram of a system including a pair of network devices that provide a virtual switch that selectively exports static multicast routes to prevent the virtual switch from sending duplicate multicast traffic streams, according to an example implementation.DETAILED DESCRIPTIONThe following detailed description refers to the accompanying drawings. Wherever possible, the same reference numbers will be used in the drawings and the following description to refer to the same or like parts. It is expressly understood, however, that the drawings are for purposes of illustration and description only. Although several examples are described in this document, modifications, adaptations, and other implementations are possible. Accordingly, the following detailed description does not limit the disclosed examples. Rather, the true scope of the disclosed examples may be defined by the appended claims.The terminology used herein is for the purpose of describing particular examples only and is not to be taken as limiting. As used herein, the singular forms "a", "an" and "the" also include the plural forms, unless the context clearly indicates otherwise. The term "plurality" as used herein is defined as two or more than two. The term "another" as used herein means at least a second or more. The term "connected" as used herein is defined as being connected, either directly without intermediate members or indirectly with at least one intermediate member, unless otherwise indicated. Two elements may be mechanically, electrically, or communicatively interconnected via a communication channel, path, network, or system. As used herein, the term "and / or" refers to and encompasses all possible combinations of the listed elements. Although the terms "first", "second", "third", etc. are used herein to describe various elements, these elements should not be limited by these terms, as these terms are only used to distinguish one element from another unless otherwise stated or the context indicates otherwise. As used herein, the term "includes" means including, but not limited to, the term "including" means including, but not limited to. The term "based on" means based at least in part on.A network may include one or more routers that can perform various tasks. For example, a router may be part of the access layer of a network at the edge of the network to connect network terminals (e.g., client devices and source devices) to the network. Another example: a router may be part of the high speed core layer of a network. Another example: A router may be part of a distribution layer that connects the core and access layers together.A network may transmit a series of multicast traffic streams. A particular multicast traffic flow may include data (e.g., a datagram or sequence of packets) received from a particular multicast group of network receivers (hereafter "client devices"). A multicast group and corresponding multicast traffic flow may be identified by a multicast group address and a source address. The source address corresponds to the source of the multicast traffic flow. A multicast group may have an associated network structure, referred to as a multicast distribution tree, that defines the routes between the multicast source and the client devices. In one example, a multicast distribution tree may be a source tree in which the multicast source is the root of the tree. In another example, a multicast distribution tree may be a broadcast tree in which a particular forwarding network device or broadcast point is the root of the tree.A protocol such as the Simple Service Discovery Protocol (SSDP) may be used by multicast service providers (e.g., print services, streaming services, or other services) to advertise the services, and the SSDP may be used by client devices to subscribe to multicast services. A client device may join a particular multicast group (and thus subscribe to the multicast service) by sending a join message (e.g., an Internet Group Management Protocol (IGMP) message) indicating that the client device wishes to be a member of the multicast group and receive the corresponding multicast traffic flow. An IGMP message generally refers to a message having a particular format (e.g., a particular format) conforming to an 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, e.g., a query or join, and an IGMP message may also indicate a group address. An IGMP message may contain a multicast source address. A router may add itself to a multicast distribution tree for a particular multicast group by sending a join message (e.g., a protocol independent multicast (PIM) join message) back to the root of the multicast distribution tree.Due to the nature of multicast communication, a particular router may receive packets corresponding to duplicate multicast traffic streams on multiple input interfaces of the router. In this context, an "input interface" refers to a port or interface of a router that receives a particular packet. An "output interface" refers to a port or interface of the router through which the router sends a particular packet. To reduce network congestion and prevent loopback, the router may perform a reverse path forwarding (RPF) check on a received multicast packet to determine whether the input interface over which the packet was received would be selected by the router as an output interface for sending a packet to the source of the received multicast packet. If the router determines that the input interface would be selected by the router as an interface to reach the source, the router will send out the packet, otherwise it will discard the packet.The RPF checks of a router result in the router having only a single RPF interface for a particular multicast group and discarding packets corresponding to the same multicast group and received at other, non-RPF input interfaces of the router. The RPF checks prevent a router from possibly sending duplicate multicast traffic streams. In general, problems may arise when a client device receives duplicate multicast traffic streams, as duplicate multicast traffic streams may have a number of adverse effects, e.g., client device malfunction or a loss of service.A network may include one or more pairs of high availability routers (HA). In this context, an HA pair of network devices, such as an HA pair of routers, refers to a pair of network devices that provide failover capability such that upon failure of one network device of the HA pair, the other network device of the HA pair will enter without interruption for the failed network device. In an example of an HA router pair, each router of the HA pair may independently maintain its own control plane and forward data while remaining synchronized with important routing information (e.g., MAC addresses and ARP addresses) currently being used by the other router. Should one router of the HA pair fail, the other router of the HA pair has the routing information to replace the failed router. The routers may exchange routing information by sending messages to each other over an inter-switch communication link that communicatively connects the routers to each other.A particular HA router pair may correspond to a distribution layer of a network, and the multicast distribution trees for a particular set of multicast groups may end on the HA router pair. The interfaces of the routers of the HA pair may be merged as part of a link aggregation group to form a corresponding multicast egress interface (e.g., an interface associated with a virtual local area network (VLAN) identifier) of the HA pair that forwards the multicast traffic to one or more downstream client network devices. Although each router of the HA pair may use RPF checks to ensure that the router does not broadcast double multicast traffic streams, RPF checks do not prevent the HA pair from broadcasting double multicast traffic streams as a single entity. In this way, both routers may receive the same multicast traffic flow on the respective RPF interfaces, and each router may correspondingly broadcast the received multicast traffic flow over the multicast output interface of the HA pair, resulting in dual multicast traffic flows being sent to a client device.According to the example implementations described herein, an HA router pair is configured to configure multicast distribution trees such that the HA pair does not broadcast dual multicast traffic streams. More specifically, according to some implementations, an HA router pair is configured to prevent more than one RPF interface of the HA pair from being added to a particular multicast distribution tree. Due to the configuration of the multicast distribution tree in this manner, RPF checks can be efficiently used by the routers to discard duplicate packets of the same multicast stream.In an example, as further described herein, a designated router of an HA router pair may be constructed to prevent an interface of the router, which may be an RPF interface for a multicast traffic flow, from being part of the corresponding multicast distribution tree. In this way, due to the configuration of the multicast distribution tree and the RPF checks used by the designated router, the designated router drops all multicast packets for the multicast group. The other undesignated router of the HA router pair discards all packets for the multicast group, except for the multicast packets received at the RPF interface of the undesignated router for the multicast group. Therefore, the HA router pair does not transmit duplicate multicast traffic streams.A particular router may be part of one or more multicast distribution trees. In one approach, a router learns the source addresses, group addresses, and upstream interfaces for different multicast distribution trees from the traffic. Moreover, in this approach, the router derives the corresponding downstream interfaces using a dynamic protocol, such as a PIM Sparse Mode (SM) or a PIM Density Mode (DM) protocol. However, constructing a multicast distribution tree in this manner may represent a significant burden on the routers, which may increase with the number of client devices and the number of routers.In another approach, a router may be configured with a static multicast table that may define static routes by the router for various corresponding multicast groups. In one example, the static multicast table may include records or entries corresponding to the respective multicast groups. In this way, each entry may include a 2-tuple of a multicast source address and a multicast group address to identify a particular multicast group. In one example, a static multicast table entry may associate a corresponding multicast group with an ingress interface of the router and an egress interface of the router. A static multicast table may include multiple entries corresponding to the same multicast group but connected to different input interfaces and / or output interfaces. Moreover, the static multicast table entries may be compressed by being able to associate a single static multicast table entry with multiple multicast groups (e.g., groups having the same group address) having the same input interface and output interface by using a dummy symbol (e.g., a dummy symbol for the source address).In the concept of static multicast routes, a router may export its static multicast routes to other routers for a particular multicast group by a redistribution process. The exported static multicast routes allow the other routers to create or update their corresponding static multicast tables. A router may export the router's static multicast routes for a particular multicast group in response to an ingress interface of the router receiving a PIM join / IGMP join associated with the particular multicast group. In one approach, in response to receiving a PIM / IGMP join at a particular ingress interface, a router may export a set of static multicast routes by embedding information describing the static multicast routes in a set of PIM joins that the router sends to other routers.One router of an HA pair may be referred to as a "primary role" (or "primary router") and the other router of the HA pair may be referred to as a "secondary role" (or "secondary router"). In one example, the primary and secondary roles may be used to determine the specific router (e.g., the primary router) of the HA pair that takes over in the event of a failure of the inter-switch connection between the routers of the HA pair. The primary and secondary labels may be based on other criteria, in accordance with other implementations.According to the example implementations described herein, an HA router pair is configured to selectively export static multicast routes for a particular multicast group to ensure that no more than a single RPF interface of the HA pair is added to the corresponding multicast distribution tree. To this end, according to some implementations, a designated router of an HA pair, e.g., a secondary router of the HA pair, includes a selective static multicast route export (SSMRE) engine. The SSMRE module exports the secondary router's static multicast routes such that all secondary router interfaces, which could potentially be an RPF interface for a particular multicast group, are excluded from export.In one example, in accordance with some implementations, in response to the secondary router receiving an IGMP / PIM join associated with a particular multicast group, the SSMRE engine exports the secondary router's static multicast routes for the multicast route in a manner that bypasses or omits exporting a static multicast route on any secondary router interface, which could possibly be an RPF interface for the multicast group.According to example implementations, the SSMRE module relies on grouping or classification of the interfaces of the secondary router for a particular multicast group to determine which interface(s) should be used for the export of static multicast route information and which interface(s) should be excluded from the export of static multicast route information(s). Depending on the implementation, the SSMRE engine may perform the classification directly based on configuration information that determines the classifications of the egress interfaces for different multicast groups, or the SSMRE engine may determine the classifications indirectly based on other information. Regardless of the particular entity performing the classification, the classification identifies a potential RPF interface of the secondary router for a particular multicast group, and accordingly, the SSMRE module excludes that interface from exporting static multicast routes for the particular multicast group. In accordance with some implementations, the classification may exclude an interface from exporting static multicast route information if the interface satisfies the following criteria: 1. the interface is specific to the secondary router (i.e., the interface is not shared with the primary router); and 2. the interface corresponds to the next hop toward the multicast source. According to example implementations, interfaces that do not meet both criteria would not be RFP interfaces. An example: An interface that does not meet the criteria is a legacy interface that cannot be used to reach the multicast source. In another example, an interface that does not meet the criteria is an interface aggregated with an interface of the primary router. In accordance with 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 export its static multicast routers based on these criteria.Referring to FIG. 1, a computer network 100 may include one or more multicast source devices 110 (referred to herein as "source devices 110") connected via the network fabric 101 to one or more multicast recipient client devices 104 (referred to herein as "client devices 104"), according to example implementations. In the specific implementation illustrated in FIG. 1, the network fabric 101 includes two source devices 110- 1 and 110- 2 and two client devices 104- 1 and 104- 2, although the network fabric may include more or less than two source devices 110 and / or more or less than two client devices 104, according to further implementations. In the particular implementation illustrated in FIG. 1, the network fabric 101 also includes routers 120 interconnected via links 124 (e.g., network cables and backplane links). Although seven routers 120- 1, 120- 2, 120- 3, 120- 4, 120- 5, 120- 6, and 120- 7 are illustrated in FIG. 1, network fabric 101 may include fewer or more than seven routers 120, in accordance with other implementations. Moreover, routers 120 may be connected in an arrangement other than the example network architecture shown in FIG. 1, according to further implementations.In one example, a source device 110 may be a computing platform. A "computing platform" as used herein refers to an electronic device having a processing resource capable of executing machine readable instructions (e.g., "software"). In an example, a source device 110 may be a server, such as a blade server, a rack server, or a stand-alone server. In another example, a source device may be a cluster's management node (e.g., a high performance computing (HPC) cluster). In another example, a source device may be an Internet of Things (IoT) device. A 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 device having a processing resource, in accordance with other implementations.Regardless of its particular form or architecture, a source device 110 may provide one or more multicast traffic streams. In this context, a "multicast traffic flow" refers to a data transmission (e.g., packets or datagrams) associated with a source address of the source device 110 and a multicast group address. In one example, the source address may be an IP address and the group address may be an IP address.In one example, a source device 110 may be a content delivery server that delivers a multicast traffic flow for the purpose of delivering a stream of audio content, visual content, or audio-visual content. In one example, a multicast traffic stream may be a data stream representing voice over IP content (VOIP). In another example, a multicast traffic stream may include data representing content for a television channel. In another example, a multicast traffic stream may include data representing video-on-demand (VOD) content. In another example, a multicast traffic flow may include data representing content for video conferencing. In another example, a multicast traffic flow may include data representing streaming audio content. In another example, a multicast traffic flow may include data representing image content captured by one or more sensors (e.g., cameras).In another example, a source device 110 may be a cluster's management node, and the management node may provide a multicast traffic flow for the purpose of communicating data to a selected group of compute nodes of the cluster. In one example, the multicast traffic flow may include data representing an installation image (e.g., an image including a root file system). In another example, the multicast traffic flow may include data representing a patch image.The multicast traffic flow may relate to any number of different services (e.g., financial services, file sharing services, print services, learning services, data warehouse services, or other services), as described in further implementations.In one example, a client device 104 may be a computing platform. As specific examples, a client device 104 may be a desktop computer, a notebook computer, a tablet computer, a smartphone, a storage array, a network switch, a gateway device, a router, an IoT device, a television, a portable computer, or other electronic device having a processing resource.Regardless of its particular form or architecture, a client device 104, e.g., client device 104- 1, may be part of a multicast group, e.g., a particular multicast group corresponding to a particular address (referred to herein as a "source address") of source device 110- 1 and a multicast group address. In one example, source device 110- 1 may advertise a service using SSDP, and client device 104- 1 may subscribe to or join a multicast group associated with the service using IGMP messages. In one example, an IGMP router (e.g., router 120-6 or other router) may send IGMP query messages to client devices 104-1 and 104-2 that identify a particular multicast group and serve as a query whether client devices 104-1 and 104-2 wish to be or are members of the multicast group. Continuing with the example, the client device 104- 1 may respond to the query message by sending an IGMP join message indicating that the client device 104- 1 wishes to be or is a member of the multicast group.Sending an IGMP join message by a client device 104 initiates a series of IGMP / PIM joins sent upstream to the source device 110, according to example implementations. For example, in response to receiving an IGMP join message from a client device 104, router 120- 6 may send a join message (e.g., an IGMP join message) to source device 110 to indicate that router 120- 6 is to be part of the multicast distribution tree for the multicast group. In one example, in response to an IGMP join message from router 120-6, router 120-4 may send PIM join messages upstream towards source device 110- 1 to add static multicast routes of router 120-4 to the multicast distribution tree. Other routers 120, in response to receiving PIM join messages, may export their static multicast routes upstream toward the source device 110- 1 by using corresponding PIM joins. By exporting the static multicast routes upstream towards the source device 110- 1, the multicast distribution tree for the multicast group is set up.In accordance with some implementations, the computer network 100 may use a PIM SM routing protocol that assumes that the recipient client devices for the multicast group are only sparsely distributed over the computer network 100. In other words, the PIM SM routing protocol assumes that a particular client device does not wish to be a member of a particular multicast group, and relies on client devices requesting access to the multicast group to allow the corresponding portion of the network to be added to the multicast distribution tree for the multicast group. In another example, the computer network 100 may use a PIM DM routing protocol that, for a given multicast group, first assumes that all client devices are part of the multicast group. According to the PIM DM protocol, the computer network 100 removes or deletes paths of the computer network 100 from the multicast distribution tree that do not include client devices subscribed to the multicast group.As used herein, a "router" generally refers to a network device that interconnects multiple networks and is designed to recognize and respond to a multicast communication protocol (e.g., the PIM SM protocol or the PIM DM protocol). In one example, a router may operate at level three (L3) of the open systems interconnection (OSI) model. The router may be, for example, an L3 switch, a gateway, a multicast router, a bridge, a gateway, a component of a gen-Z or a compute express link (CXL) network, a processor device, or a fabric switch that includes one or more of the aforementioned devices.Router 120 has multiple ports or interfaces 122, according to example implementations, for connecting router 120 to various networks. In the example implementation illustrated in FIG. 1, router 120-4 has three interfaces 122-1, 122-2, and 122-3 that are connected by respective links 124 to an interface 122-3 of router 120-2, an interface 122-2 of router 120-3, and an interface 122-1 of router 120-6, respectively. As also shown in the example implementation of FIG. 1, router 120- 5 has four interfaces 122- 1, 122- 2, 122- 3, and 122- 4 that are connected via respective links to an interface 122- 2 of router 120- 2, an interface 122- 3 of router 120- 3, an interface 122- 1 of router 120- 7, and an interface 122- 2 of router 120- 6, respectively.When a particular router 120 receives a multicast packet at an input interface 122, the router 120 determines whether the input interface 122 is the RPF interface for the multicast packet, in accordance with example implementations. Generally, an "RPF interface" refers to the interface 122 of the router 120 corresponding to the optimal unicast route (as determined by the router 120) to reach the source (e.g., a broadcast point (RP) device or a source device 110) of the packet. A router 120 may use any number of different techniques to determine the optimal unicast route.If a router 120 determines that an ingress interface 122 receiving a multicast packet is not the RPF interface for the multicast packet, then the router 120 discards the multicast packet. If router 120 determines that the input interface that receives the multicast packet is the RPF interface for the multicast packet, then router 120 sends the packet on its output interfaces 122, in accordance with example implementations. In this manner, although router 120 may receive the same multicast packet at multiple input interfaces, due to the RPF check it discards all received multicast packets, except for the multicast packet received at RPF interface 122.In one example, a router 120 as part of an RPF check may first check a multicast forwarding table to determine whether an entry of the multicast forwarding table matches the received multicast packet. The entries of the multicast forwarding table may be associated with different (S,G) tuple, where the "S" represents the source address of a particular multicast group and the "G" represents the group address of the particular multicast group. The entry identifies an interface 122 of the router 120 that is associated with the (S,G) tuple. When router 120 determines that an entry of the multicast forwarding table corresponds to the received multicast packet, the entry identifies the RPF interface.If the multicast forwarding table does not include an entry corresponding to the multicast packet, the router 120 may determine the RPF route (e.g., the optimal unicast route) back to the source for the multicast packet and accordingly identify the RPF interface for the multicast packet, in accordance with example implementations. Router 120 may then create an entry in the multicast forwarding table for the multicast group and the corresponding identified RPF interface.Router 120 determines whether interface 122 that received the multicast packet is the RPF interface based on either the RPF interface identified via the multicast routing table or the RPF interface identified via router 120 that determines the RPF route. Based on this determination, router 120 either discards the multicast packet (if interface 122 is not the RPF interface) or broadcasts the multicast packet on all outgoing interfaces 122 (if interface 122 is the RPF interface).In the example implementation illustrated in FIG. 1, routers 120- 4 and 120- 5 collectively form a virtual switch 160. According to the example implementations, virtual switch 160 corresponds to a high availability (HA) router pair that are both active (assuming neither routers 120- 4 nor 120- 5 have failed) and maintain their respective control planes independently of each other. Via an inter-switch communication link 151, routers 120- 4 and 120- 5 exchange information (e.g., MAC addresses and ARP addresses) in accordance with example implementations so that upon failure of one of routers 120- 4 and 120- 5, surviving router 120 may take over the control plane of failed router 120. As further illustrated in FIG. 1, router 120- 4 has a primary role, and is referred to as a "primary router," in accordance with example implementations. Moreover, as also shown in Figure 1, router 120-1 has a secondary role and is referred to as a "secondary router". In accordance with some implementations, the designation of the primary and secondary roles refers to which router 120- 4 or 120- 5 takes over as the sole router for the HA pair 150 when the inter-switch communication link 151 fails. The determination of the primary and secondary roles may depend on other criteria, in accordance with further implementations.The interfaces of the primary router 120- 4 and the secondary router 120- 5 may be grouped or aggregated. For example, in some implementations, an interface 122- 3 of the primary router 120- 4 may be aggregated with an interface 122- 4 of the secondary router 120- 5 to form a corresponding link aggregated group (LAG) 140. Additionally, as shown in 144, the LAG 140 may be associated with a particular VLAN ID, such as "VLAN10" as shown in FIG. 1. Based on this mapping, the LAG 140 is referred to herein as a "VLAN10 interface 144.". As further shown in FIG. 1, 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. Moreover, as further shown in FIG. 1, 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.Even if both the primary router 120-4 and the secondary router 120-5 perform RPF checks, the HA pair 150 may still potentially broadcast duplicate multicast traffic streams. For example, without the measures described herein to prevent the HA pair 160 from sending duplicate multicast traffic streams, the primary router 120-4 may receive a multicast traffic stream at a particular input interface 122, determine that the input interface 122 is an RPF interface for the corresponding multicast group, and send the multicast packet over the VLAN10 interface 144. To continue the example, secondary router 120-5 may receive a duplicate of the same multicast packet on one of its input interfaces 122, determine that input interface 122 is an RPF interface for the multicast group, and broadcast the multicast packet over VLAN10 interface 144. Thus, although both the primary router 120-4 and the secondary router 120-5 of the HA pair 160 perform RPF checks, the HA pair 160 sends out duplicate multicast packets.To prevent the HA pair 160 from sending duplicate multicast traffic streams, one of the routers 120- 4 and 120- 5 includes a selective static multicast route exchange (SSMRE) engine 170, according to example implementations. In the particular implementation illustrated in FIG. 1 and described herein, secondary router 120- 5 includes SSMRE engine 170. In accordance with further implementations, the primary router 120- 4 may include the SSMRE engine 170 (instead of the secondary router 120- 5).In general, the SSMRE engine 170 selectively exports static multicast route information in a manner that excludes the secondary router 120- 5 from receiving multicast traffic streams that would not be discarded by the secondary router 120- 5 using RPF checks. In other words, the SSMRE engine takes action to exclude the secondary router 120-5 from the corresponding multicast distribution tree. Accordingly, secondary router 120- 5 does not transmit duplicate multicast traffic due to the exclusion of secondary router 120- 5 from the multicast distribution tree by SSMRE module 170, according to the example implementations.More specifically, in accordance with example implementations, the SSMRE engine 170 is constructed so as not to export static multicast routes of the secondary router 120- 5 via its interface(s) 122, which could possibly be RPF interfaces for the corresponding multicast group. Thus, due to this exclusion, secondary router 120-5 does not receive multicast packets at the corresponding RPF interfaces 122 of secondary router 120-5. Therefore, due to the RPF checks by the secondary router 120-5, all multicast packets received by the secondary router 120-5 are discarded.In accordance with some implementations, the primary router 120- 4 and the secondary router 120- 5 may export a particular static multicast route by sending a PIM join that includes data representing the static multicast route. In one example, a particular multicast group may have a source address of "10.1.1.1" and a multicast group address of "231.1.1.1.1.1.1.1.1.1.1.1.". A static multicast route for this multicast group can be defined by the source address (here "10.1.1.1"), a multicast group address (here "231.1.1.1"), an ingress interface and an egress interface. In one example, a particular static multicast route for the primary router 120-4 for this example multicast group may include the interface 122-1 as an ingress interface and the VLAN10 interface 144 as an egress interface. By exporting this 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. In accordance with example implementations, the primary router 120-4 may be configured with this particular static multicast route using the following command:IP MULTICAST STATIC ROUTE R4_IF01 10.1.1.1 231.1.1.1 VLAN10,where "R4_IF01" is the name of the input interface 122-1; "10.1.1.1" is the source address; "231.1.1.1" is the multicast group address; and "VLAN10" is the VLAN10 interface 144.A router 120, e.g., the primary router 120-4, may be programmed or configured in various ways with a particular static multicast route. In one example, one or more static multicast routes of a router 120 may be programmed via an executing application. As another example, a human administrator may program a router 120 with one or more static multicast routes.As another example, the primary router 120-4 may have a different static multicast route for the (10.1.1.1, 231.1.1.1) multicast group that determines the interface 122-2 as an input interface and the VLAN10 interface 144 as an output interface. More specifically, the primary router 120-4 may be configured for this particular static multicast route with the following command:IP MULTICAST STATIC ROUTE R4_IF02 10.1.1.1 231.1.1.1 VLAN10,where "R4_IF02" represents the identifier for interface 122-2.On the secondary router 120-5, static multicast routes may be 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, andIP MULTICAST STATIC ROUTE R5_IF05 10.1.1.1 231.1.1.1 VLAN10,where "R5_IF01", "R5_IF02", and "R5_IF05" are identifiers for the output interfaces 122-1, 122-2, and 122-5, respectively, of the secondary router 120-5.Although the secondary router 120- 5 may be configured with static multicast routes such as those mentioned above, according to example implementations, the SSMRE engine 170 selectively exports these static routes to prevent a multicast packet from being received at an interface 122 of the secondary router 120- 5, which is the RPF interface for the corresponding multicast group. More specifically, in some implementations, the SSMRE engine 170 relies on a classification of the interfaces 122 that excludes potential RPF interfaces from the set of interfaces 122 from which static multicast routes are exported by the secondary router 120- 5. The classification may be performed by the SSMRE engine 170, another component of the secondary router 120- 4, or another component of the computer network, depending on the particular implementations.Regardless of the particular entity that performs the classification, the classification may include three groups, group 1, group 2, and group 3 interfaces of group 1 include all interfaces 122 of the secondary router 120- 5 aggregated with an interface 122 of the primary router 120- 4, in accordance with some implementations. Group 2 interfaces include all interfaces 122 specific to the secondary router 120-5 (and therefore not shared with an interface 122 of the primary router 120-4) and connected to the next hop to the multicast source. Group 3 interfaces include any interface 122 corresponding to a trusted port specific to the secondary router 120-5. In this context, a "leased" port or interface refers to an interface that cannot be used to reach the multicast source. According to example implementations, SSMRE engine 170 exports a static multicast route over a particular interface 122 when SSMRE engine 170 determines that interface 122 belongs to either group 1 or group 3. Moreover, according to example implementations, the SSMRE module 170 bypasses the export of a static multicast route via an interface 122 belonging to group 2.As examples, the specific example interfaces 122 of the secondary router 120- 5 as shown in FIG. 1 may 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 as such, the interface 122- 1 belongs to group 1. 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 to the multicast source. Accordingly, in accordance with example implementations, the SSMRE engine 170 configures the secondary router 120- 5 to bypass or prevent the export of a static multicast route via the interface 122- 2. As another example, the interface 122- 3 of the secondary router 120- 5 is a legacy interface and is accordingly classified as belonging to group 3. Thus, SSMRE engine170 allows secondary router 120-5 to export multicast static route information over interface 122-3.As used herein, a "motor" may refer to one or more circuits. The circuits may be, for example, hardware processing circuits that may include any one or a 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 particular implementation, an engine may consist solely of hardware processing circuitry that executes machine-executable instructions; it may consist of a combination of hardware processing circuitry that executes machine-executable instructions and other hardware circuitry that does not execute machine-readable instructions; or it may consist solely of hardware circuitry that does not execute machine-executable instructions. As shown in FIG. 1, in accordance with some implementations, the SSMRE engine 170 may include one or more processors 174 (e.g., one or more CPU cores or other processing circuitry) executing machine readable instructions 178 stored in the memory 176. As shown in FIG. 1, processor(s) 174 and memory 176 may be components of secondary router 120- 5, in accordance with some implementations.According to embodiments, the memory 176 may be implemented with a collection of physical storage devices. In general, the storage devices forming the memory 176, as well as other memories and storage media described herein, are examples of non-transitory machine-readable storage media. In accordance with example implementations, the machine readable storage media may be used for a variety of memory and computer related functions. As examples, the memory devices may include semiconductor memory, flash memory, memristors, phase change memory, magnetic memory, a combination of one or more of the foregoing memory technologies, as well as memory devices based on other technologies. Moreover, the memory devices may be volatile memory devices (e.g., dynamic random access memory (DRAM), static random access memory (SRAM), etc.) or nonvolatile memory devices (e.g., flash memory, read only memory (ROM), etc.), unless otherwise specified herein.FIG. 2 is a flow diagram 200 illustrating a process used by the SSMRE engine 170 for purposes of exporting static multicast routes from the secondary router 120- 5, according to example implementations. Referring to FIG. 2, in accordance with example implementations, in response to receiving a join 202 (e.g., a PIM join or an IGMP join), the SSMRE engine 170 may perform actions based on classifications 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 classifications, the interfaces 122- 1, 122- 2, and 122- 3 may have been previously classified according to other implementations.As shown at 204, the SSMRE engine 170 may determine that the interface 122- 2 is aggregated with the primary router 120- 4. In other words, the SSMRE engine 170 determines that the interface 122- 2 is associated with the group 1. As such, interface 122- 2 would not be an RPF interface for all multicast packets received on interface 122- 2, and as such, SSMRE engine 170 as shown at 208 causes secondary router 120- 5 to send a PIM join from interface 122- 2 exporting the static multicast route that includes interface 122- 2 as an input interface.As shown at 212, the SSMRE engine 170 determines that the interface 122- 1 of the secondary router 120- 5 is the next hop to the source and is specific to the secondary router 120- 5. In other words, the SSMRE module 170 determines that the interface 122- 1 belongs to the group 2. Accordingly, the SSMRE engine 170 bypasses exporting a static multicast route via the interface 122- 1, as shown at 216, as the interface 122- 1 may be an RPF interface for the multicast group.As shown in FIG. 220, the SSMRE module 170 determines that the interface 122- 3 of the secondary router 120- 5 is a legacy interface. In other words, the SSMRE engine 170 determines that the interface 122- 3 belongs to the group 3. Therefore, the SSMRE engine 170 causes the secondary router 120-5 to export the multicast static route with the interface 122-3 as an input interface via the interface 122-3 (see Fig. 224).FIG. 3 shows an illustration 300 of the export of static multicast routes in response to an IGMP join 304 from the client device 104- 1, according to example implementations. In response to receiving the IGMP join 304, the router 120- 6 provides corresponding IGMP joins 308 and 312 received from the primary router 120- 4 and the secondary router 120- 5, respectively.As shown in FIG. 3, the primary router 120- 4 and the secondary router 120- 5 perform corresponding redistribution operations 340 and 342, respectively. A redistribution operation generally causes router 120 to export multicast static routes via PIM joins. More specifically, primary router 120-4 exports static multicast routes on all of its upstream interfaces, as shown at reference numerals 320, 324, and 328. On the other hand, secondary router 120-5 selectively exports its static multicast routes. In this manner, secondary router 120-5 exports static multicast routes over PIM joins via the Group 1 and 3 interfaces as shown in Figures 312, 316, and 320. However, as shown at 312 (and corresponding "X"), secondary router 120-5 does not export a static multicast route over a group 2 interface (here, the interface connecting secondary router 120-5 to router 120-3).As also shown in Figure 3, other routers 120 may also export static multicast routes to build the multicast distribution tree. For example, as shown in FIG. 3, router 120-2 may export a static multicast route upstream to router 120-2 via a PIM join 336. As another example, router 120-3 may export a static multicast route to router 120-1 via a PIM join 338.Because of the selective export of static multicast routes by the secondary router 120-5, the secondary router 120-5 is effectively excluded from the multicast distribution tree. More specifically, FIG. 4 shows an illustration 400 of routing a particular multicast traffic flow in the network, according to an example implementation. FIG. 4 illustrates how selectively exporting static multicast routes by the secondary router 120-5 excludes the secondary router 120-5 from the multicast distribution tree.More specifically, due to the exclusion of secondary router 120-5 from the multicast distribution tree, source device 110- 1 sends a multicast traffic flow that, as shown in FIG. 4, propagates along a path 410 through router 120-1, router 120-2, primary router 120-4, and router 120-6 and terminates at client device 104-1. For comparison, a path 414 is shown in Figure 4 for the multicast traffic flow that would exist without the selective export of static multicast routes by the secondary router 120-5. The absence of the multicast traffic flow path 414 is indicated by the "X" at 420. Without the exclusion of the dual traffic flow 414, both traffic flows 410 and 414 would otherwise reach the HA pair and result in the secondary router 120-5 sending a dual multicast traffic flow to the VLAN10 interface 144. However, due to the selective export of the static multicast routes by the secondary router 120-5, a double multicast traffic flow is prevented.As shown in FIG. 5, according to example implementations, a process 500 includes receiving (block 504) a connection request at a first interface of a highly available pair of network devices. The high availability pair of network devices includes a first network device and a second network device. In one example, the high availability pair of network devices may be a high availability pair of routers. In one example, the high availability pair of network devices may form a virtual switch. The connection request represents a request of a client device to join a multicast group that is connected to a source address and a multicast group address. In one example, the connection request may be a PIM message.The process 500 includes exporting, by the first network device, first static multicast route information from a second interface of the first network device in response to the connection request, according to block 508. The first static multicast route information corresponds to routing multicast traffic connected to the multicast group through the first network device. In one example, the first static multicast route information may identify the second interface as an input interface of a path through the first network device connected to the multicast group, and the first static multicast route information may identify an interface of the first network device other than an output interface connected to the multicast group. In an example, exporting the first static multicast information may include the first network device sending a PIM Join message towards the multicast source.In one example, the first network device may be connected to a primary role for the high availability pair of network devices and the second network device may be connected to a secondary role for the high availability pair of network devices. In one example, the primary and secondary role designations may be based on the respective network device that operates in the event of failure of an inter-switch communication link between the first and second network devices. In one example, one of the network devices of the high availability pair accepts the other network device of the high availability pair if the other network device fails. In one example, this takeover occurs without interruption.According to block 508, the process 500 further comprises, in response to the connection request, controlling the export of second static multicast route information from the second network device to prevent duplicate multicast traffic associated with the multicast group from being sent from the high availability pair. In one example, the second static multicast route information corresponds to routing of the multicast traffic associated with the multicast group by the second network device.In one example, controlling export of the second static route information includes classifying interfaces of the second network device. The classification may include identifying potential RPF interfaces of the second network device for the purpose of excluding those interfaces from the corresponding multicast distribution tree. In one example, the classification corresponding to potential RPF interfaces may take into account criteria of whether an interface is specific to the second network device and is not connected to the first network device and whether the interface corresponds to a next hop to the multicast source. The classification may further include classifications such as whether a particular interface is a legacy interface and whether a particular interface is connected to the first network device, and these other classifications may correspond to interfaces over which the second static multicast route information is exported.Referring to FIG. 6, a non-transitory machine readable storage medium 600 stores machine readable instructions 610, in accordance with example implementations. The instructions 610, when executed by a particular router of a high availability router pair, cause the particular router to receive a connection request representing a request of a client device to join a multicast group associated with a source address and a multicast group address. In one example, the highly available pair of network devices may form a virtual switch. In one example, the connection request may be a PIM message.In one example, the given router may be assigned to a secondary role for the high availability router pair, and the other router of the high availability pair may be assigned to a primary role. In one example, the primary and secondary role designations may be based on the particular router of the high availability pair that takes over in the event of failure of an inter-switch communication link between the routers. In one example, one of the routers of the high availability pair will take over the other router if it fails. In one example, this takeover occurs without interruption. In one example, the high availability router pair may be part of a network's distribution layer.The instructions 610, when executed by the given router, further cause the given router to classify a given interface of the given router based on whether the given interface is connected to a next hop to the source address and whether the given interface is connected to the other router of the high availability router pair. The instructions 610, when executed by the given router, also cause the given router to selectively export multicast static route information over the given interface based on the classification, in response to the connection request. In one example, the static multicast route information corresponds to routing of the multicast traffic associated with the multicast group by the given router. In one example, the given router exports the static multicast route information by sending a PIM join message containing the static multicast route information upstream toward the source address.In one example, the given router may not export the static multicast route information over the given interface if it determines that the given interface is not connected to a next hop to the source address and if it determines that the given interface is not connected to the other router of the high availability pair. In one example, the given router may export the static multicast route information over the given interface when it determines that the given interface is an orphan. In one example, the given router may export the static multicast route information over the given interface when it determines that the given interface is connected to the other router of the high availability pair. In one example, the given router may export the static multicast route information over the given interface if it determines that the given interface is not associated with the next hop to the source address.As shown in FIG. 7, according to example implementations, a system 700 includes a pair 710 of network devices to provide a virtual switch. The pair 710 includes a first network device 720 and a second network device 730. In one example, the pair 710 is a high availability pair such that one network device 720, 730 of the pair 710 enters for the other network device 720, 730 of the pair when the other network device 720, 730 fails. In one example, the pair 710 is a high availability router. In an example, the pair 710 may be part of a distribution layer of a network. In an example, the first network device 720 and the second network device 730 may communicate with each other via an inter-switch communication link. In an example, the first network device 720 and the second network device 730 may communicate information (e.g., MAC addresses and ARP addresses) used by the surviving network device 720, 730 if the other network device 720, 730 fails.The first network device 720 is connected to a primary role for the pair 710 of network devices. In one example, the designation of the primary roles corresponds to the network device of the pair 710 that takes over in the event of a failure of a communication link between the network switches.The first network device 720 is to export first multicast static route information over a first network interface of the first network device 720, in response to the pair 700 of network devices receiving a connection request. The first connection request represents a request of a client device to join a multicast group connected to a source address and a multicast group address, and the first static multicast route information identifies the first network interface as an incoming interface for receiving multicast traffic connected to 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.In one example, the first static multicast route information corresponds to routing of the multicast traffic connected to the multicast group by the first network device 720. In one example, the first network device 720 exports the first static multicast route information by sending a PIM connection message containing the static multicast route information upstream toward the source address.The second network device 730 is connected to a secondary role for the pair 700 of network devices. The second network device 730 is to determine whether a second network interface of the second network device 730 is connected to a next jump to the source address and whether the second network interface is aggregated with an interface of the first network interface, in response to the pair 700 of network devices receiving the connection request. The second network device 730 selectively exports second multicast static route information over the second network interface in response to the pair 700 of network devices that received the connection request and in response to the determination.In one example, the second network device 730 may not export the second static multicast route information via the second network interface when it is determined that the second network interface is not connected to a next hop to the source address and when it is determined that the second network interface is not connected to the first network device 720. In one example, the second network device 730 may export the second static multicast route information via the second network interface when it is determined that the second network interface is an orphan. In one example, the second network device 730 may export the second static multicast route information via the second network interface when it is determined that the second network interface is connected to the first network device 720. In one example, the second network device 730 may export the second static multicast route information over the second network interface when it is determined that the second network interface is not associated with the next hop to the source address.In one example, the second static multicast route information corresponds to routing of the multicast traffic connected to the multicast group through the second network device 730. In one example, the second network device 730 exports the second static multicast route information by sending a PIM connection message containing the static multicast route information upstream toward the source address.According to example implementations, the controller includes determining, by the second network device, whether a second interface of the second network device corresponds to a next jump to the source address; and selectively exporting, by the second network device, the second static multicast route information via the second interface based on a result of the determination. Among the particular advantages is preventing dual multicast traffic streams from being sent to client devices.According to example implementations, the second upstream interface does not correspond to a next hop towards the source address; and exporting the second multicast route information includes transmitting the second static multicast information over the second interface. Among the particular advantages is preventing dual multicast traffic streams from being sent to client devices.In accordance with example implementations, the second upstream interface corresponds to a next jump toward the source address. The process further includes determining, by the second network device, whether the second interface is aggregated with an interface of the first network device; and controlling communication of the second static multicast information via the second network interface based on a result of the determination as to whether the second interface is aggregated. Among the particular advantages is preventing dual multicast traffic streams from being sent to client devices.In accordance with example implementations, the second interface is aggregated with an interface of the first network device; and controlling communication of the second static multicast information comprises selectively exporting the second static multicast information via the second upstream interface. Among the particular advantages is preventing dual multicast traffic streams from being sent to client devices.In accordance with example implementations, the second interface is not aggregated with an interface of the first network device; and controlling communication of the second static multicast information includes preventing the second static multicast information from being exported via the second interface. Among the particular advantages is preventing dual multicast traffic streams from being sent to client devices.According to example implementations, the process includes controlling the export in response to the second network device determining that the second network device is associated with a secondary role for the pair of network devices. Among the particular advantages is preventing dual multicast traffic streams from being sent to client devices.In accordance with example implementations, the process further includes the first and second network devices that independently control the respective control planes and the first and second network devices that control a data plane as a single virtual network device. Among the particular advantages is preventing dual multicast traffic streams from being sent to client devices.According to example implementations, the first static multicast route information identifies the first interface as an input interface for receiving the multicast traffic, identifies an aggregated interface of the high availability pair as an output interface, identifies the source address, and identifies the group address. Among the particular advantages is preventing dual multicast traffic streams from being sent to client devices.According to example implementations, exporting the first static multicast route information includes sending a PIM join message over the first network interface. Among the particular advantages is preventing dual multicast traffic streams from being sent to client devices.In accordance with example implementations, receiving the join message includes receiving an IGMP join message or a PIM join message. Among the particular advantages is preventing dual multicast traffic streams from being sent to client devices.Although the present disclosure has been described with respect to a limited number of implementations, those skilled in the art having the advantages of this disclosure will recognize numerous modifications and variations thereof. It is intended that the appended claims cover all such modifications and variations.

Claims

A method comprising: receiving a connection request at a first interface of a high availability pair of network devices, the high availability pair of network devices comprising a first network device and a second network device, and the connection request representing a request by a client device to join a multicast group connected to a source address and a multicast group address; and in response to the first connection request: exporting first static multicast route information from a second interface of the first network device by the first network device, wherein the first static multicast route information corresponds to routing of multicast traffic associated with the multicast group by the first network device; controlling export of second static multicast route information from the second network device to prevent duplicate multicast traffic associated with the multicast group from being sent from the high availability pair, wherein the second static multicast route information corresponds to routing of the multicast traffic associated with the multicast group by the second network device.The method of 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 jump to the source address; and selectively exporting, by the second network device, the second static multicast route information via the second interface based on a result of the determining.The method of claim 2, wherein: the second interface does not correspond to a next jump to the source address; and selectively exporting the second static multicast route information comprises transmitting the second static multicast information over the second interface.The method of claim 2, wherein the second interface corresponds to a next jump to 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; and selectively exporting the second static multicast information comprises exporting the second static multicast information via the second network interface based on a result of the determination as to whether the second interface is aggregated.The method of claim 4, wherein: the second interface is aggregated with an interface of the first network device; and selectively exporting the second static multicast route information comprises exporting the second static multicast information via the second interface.The method of claim 4, wherein: the second interface is not aggregated with an interface of the first network device; and selectively exporting the second static multicast information comprises preventing the second static multicast information from being exported via the second interface.The method of claim 1, further comprising: controlling the export in response to the second network device determining that the second network device is associated with a secondary role for the pair of network devices.The method of claim 1, further comprising: the first and second network devices independently controlling the respective control levels; and the first and second network devices control a data level as a single virtual network device.The method of claim 1, wherein the first static multicast route information identifies the first interface as an ingress interface for receiving the multicast traffic, identifies an aggregated interface of the high availability pair as an egress interface, identifies the source address, and identifies the group address.The method of claim 1, wherein exporting the first static multicast route information comprises sending a protocol independent multicast (PIM) join message over the first network interface.The method of claim 1, wherein receiving the connection request comprises receiving an Internet Group Management Protocol (IGMP) message or receiving a Protocol Independent Multicast (PIM) message.A non-transitory machine readable storage medium for storing machine readable instructions that, when executed by a given router of a high availability router pair, cause the given router to: receive a join request representing a request of a client device to join a multicast group associated with a source address and a multicast group address; classify a given interface of the given router based on whether the given interface is associated with a next hop to the source address and whether the given interface is associated with the other router of the high availability router pair; and selectively export static multicast route information over the given interface based on the classification in response to the join request.The storage medium of claim 12, wherein the static multicast route 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.The storage medium of claim 12, wherein: the classification indicates whether export of the static multicast route information over the given interface would result in the given router receiving a multicast traffic stream that is a duplicate of a multicast traffic stream received from the other router of the high availability router pair.The storage medium of claim 14, wherein the instructions, when executed by the storage medium, further cause the router to not export the static multicast route information over the given interface in response to the classification representing that exporting the static multicast route information over the given interface would cause the given router to receive a multicast traffic flow that is a duplicate of a multicast traffic flow received from the other router of the high availability router pair.A system comprising: a pair of network devices to collectively provide a virtual network switch, the pair of network devices comprising: a first network device, wherein the first network device is associated with a primary role for the pair of network devices, and the first network device exports first static multicast route information via a first network interface of the first network device in response to the pair of network devices receiving a connection request, wherein the first connection 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 route information identifies the first network interface as an incoming interface to receive multicast traffic connected to the multicast group, an outgoing interface of the first network device for the multicast traffic, identifying the source address and identifying the group address; and a second network device, wherein the second network device is associated with a secondary role for the pair of network devices, and the second network device, in response to the pair of network devices receiving the connection request: determining whether a second network interface of the second network device is connected to a next hop to the source address and whether the second network interface is aggregated with an interface of the first network interface; and selectively export second static multicast route information over the second network interface in response to the determination.The system of claim 16, further comprising: a network comprising a distribution layer, an access layer, and a core layer, wherein the pair of network devices is part of the distribution layer.The system of claim 16, wherein the pair of network devices are responsive to an interruption in an inter-switch connection between the first network device and the second network device to switch to the first network device.The system of claim 16, wherein the second network device is further responsive to receipt of the connection request by the pair of network devices: responsive to determining that the second multicast static route information is not exported via the second network interface; determining that a third network interface of the second network device is legacy; and responsive to determining that the third network interface is a legacy interface, exporting third multicast static route information via the third network interface.The system of claim 16, wherein the second network device is further responsive to receipt of the connection request by the pair of network devices: responsive to determining that the second multicast static route information is not exported 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; and responsive to determining that the third network interface is not aggregated with an interface of the first network device, exporting third multicast static route information via the third network interface.

Images