Understanding Multicast Replication in a Junos Fusion
This topic introduces how multicast packets are replicated in a Junos Fusion and forwarded to multicast subscribers on satellite device extended ports.
Junos Fusion Multicast Replication Overview
Aggregation devices and satellite devices work together to manage the traffic flow from multicast sources to multicast destination ports in a Junos Fusion, resolving a source packet forwarding path to multiple destination ports.
Multicast source packets might be received through a network port on the aggregation device or an extended port on a satellite device. When a multicast source packet ingresses at a satellite device, the satellite device sends the source packet on an uplink port to the aggregation device. The satellite device load-balances forwarded source traffic over the available uplink ports to the aggregation device.
The aggregation device that initially receives the source traffic to be forwarded is referred to as the ingress aggregation device. All multicast destination resolution is done on the aggregation devices. In Junos Fusion architectures with multiple aggregation devices, the ingress aggregation device also forwards the multicast traffic to the other aggregation device or devices to reach multicast subscribers that are only accessible through those other devices, or to support the forwarding behavior of a particular Junos Fusion architecture.
To forward multicast traffic to destinations on satellite device extended ports, the aggregation device uses E-channel Identifier (ECID) mappings to determine the forwarding paths to the destination extended ports, including which cascade ports link to the corresponding satellite devices. (See ECIDs for Multicast Traffic.) Multicast traffic flowing from the aggregation device to destination satellite devices is load-balanced over the available cascade ports to each destination satellite device. Satellite devices use the ECID in the multicast packets from the aggregation device to determine which local port or ports should receive the multicast traffic.
This behavior applies similarly to flooding unknown unicast traffic within a VLAN in a Junos Fusion.
By default, the ingress aggregation device replicates multicast and broadcast packets to forward to each destination extended port. This behavior is referred to as ingress multicast replication. The aggregation device sends multiple copies of the packet to each satellite device, one copy for each destination extended port on that satellite device, identified by the extended port’s unicast ECID. See Ingress Replication at the Aggregation Device to Satellite Devices for more information.
Starting in Junos OS Release 16.1, Junos Fusion supports enabling egress multicast replication, also referred to as local replication, where satellite devices replicate the multicast and broadcast packets destined for their local ports. Egress or local replication uses special multicast ECIDs corresponding to one or more extended ports to which a satellite device should forward the traffic. (See ECIDs for Multicast Traffic.) Local replication helps to distribute most of the replication load from aggregation devices to the satellite devices where the traffic egresses, and reduces traffic on cascade ports. When enabled, local replication applies to all satellite devices in the Junos Fusion; you cannot enable it only for individual satellite devices.
Local replication behavior differs slightly for different types of multicast and broadcast traffic, and for different Junos Fusion architectures. See Egress (Local) Replication on the Satellite Devices for details.
To avoid creating loops and broadcast storms, for both ingress and egress multicast replication, both the aggregation devices and satellite devices maintain split-horizon next-hop information to prevent resending multicast or broadcast packets back out of the ingress port.
ECIDs for Multicast Traffic
Traffic sent between aggregation devices and satellite devices is sent over a logical path, called an e-channel. The packets sent between the aggregation device and satellite device include the IEEE 802.1BR E-channel tag (ETAG) header with an E-channel identifier (ECID). The ECID identifies the path that will be used in forwarding traffic packets. Each extended port is identified by a unique ECID value. Junos Fusion reserves ECID values 1 through 4095 for unicast data packets. ECID values from 4096 through 16382, also called multicast ECIDs, are reserved for multicast, VLAN flooding, and broadcast data packets. Multicast ECIDs correspond to one or more destination extended ports on a satellite device.
The aggregation device automatically creates virtual interfaces
named sd-fpc-id/0/0 (where fpc-id is the satellite device ID) to represent satellite
devices, and uses these virtual interfaces as the next-hop interface
when forwarding traffic to a satellite device.
When local replication is disabled, similar to unicast packet flow (see Understanding the Flow of Data Packets in a Junos Fusion Topology), the aggregation device assigns a unicast ECID value for each destination extended port on a satellite device for both unicast traffic and multicast traffic. The aggregation device replicates multicast packets, tags them with the assigned ECID for the destination, and sends a copy to each destination extended port by way of the corresponding satellite device interface.
When local replication is enabled, Junos Fusion uses ECID values greater than 4095 to identify multicast traffic and associate one or more extended ports on a satellite device as the multicast destination. Junos Fusion dynamically assigns multicast ECID values. When the aggregation device requires a new multicast ECID value for a group of ports or if it needs to add a port to an existing ECID, the process is as follows:
The aggregation device sends a request to the satellite device to assign an ECID value (or update an existing ECID mapping when multicast group or VLAN membership changes).
The satellite device assigns an ECID value and adds an entry to its ECID table to map the ECID value to the corresponding extended ports.
The satellite device sends a message back to the aggregation device with the ECID value that satisfies the request for the corresponding extended ports.
The aggregation device adds this information to its ECID table. It uses the
sdvirtual interface as the next-hop interface to send multicast traffic for those extended ports on the satellite device.
When the satellite device receives a data packet from the aggregation device with a multicast ECID value, the satellite device begins to replicate and forward packets to the extended ports associated with that ECID. Satellite devices do not do multicast lookups; they only maintain ECID tables to determine the port or ports corresponding to an ECID in a packet received from the aggregation device. The aggregation devices perform all multicast route maintenance and forwarding path resolution.
An ECID value is only unique locally on the satellite device. Another satellite device can use the same ECID value for its own extended ports. The aggregation device maintains a composite mapping of ECID values to the different satellite devices and the corresponding extended ports on those satellite devices.
Multicast Replication Limitations in a Junos Fusion
Junos Fusion strives to optimize data replication on satellite devices when local replication is enabled. However, for the following features, although local replication might be enabled, Junos Fusion does not trigger egress replication optimization, and instead defaults to using ingress replication:
Multicast traffic on pure Layer 3 extended ports
Multicast Listener Discovery (MLD) snooping on an IPv6 network
You might choose not to enable local replication because egress multicast replication is incompatible with some Junos OS protocol and traffic management features programmed on individual extended ports. The following features do not work when egress multicast replication is enabled; if you want to use these features, you cannot take advantage of egress replication optimizations:
VLAN tag manipulations, such as VLAN tag translations, VLAN tag stacking, and VLAN per-port policies. Using egress multicast replication with this feature can cause dropped packets due to unexpected VLAN tags.
Multicast support for the extended ports on the edge side of Pseudowire connection in a VPLS network.
Multicast support for the extended ports on the edge side of EVPNs.
Multicast VPN deployments.
Features that perform egress actions on individual extended ports, such as egress local-port mirroring (port mirroring on endpoints connected to satellite device extended ports).