min-rate

Syntax

Hierarchy Level

Description

Fast failover (that is, sub-50ms switch over for C-multicast streams as defined in Draft Morin L3VPN Fast Failover 05, ) is supported for MPC cards operating in enhanced-ip mode that are running next generation (NG) MVPNs with hot-root-standby enabled.

Live-live NG MVPN traffic is available by enabling both sender-based reverse path forwarding (RPF) and hot-root standby. In this scenario, any upstream failure in the network can be repaired locally at the egress PE, and fast failover is triggered if the flow rate of monitored traffic falls below the threshold configured for min-rate.

In earlier Junos releases, after the switchover, when the primary upstream is restored and is above the min-rate threshold for that path, traffic reverted to the primary path from the backup path. In certain scale scenarios, the PFE may switch to the primary path even before all the flows converged in the inclusive tunnel, resulting in a slow start which in turn leads to loss of traffic.

Junos OS Release 22.4R3-S1 introduced the no-revert behavior. When there is a primary upstream failure, the traffic is switched from the primary path to the backup path. Traffic will continue to flow through the backup path as long as the traffic flow rate on the backup path does not go below the configured min-rate threshold.

On the egress PE, redundant multicast streams are received from a source that has been multihomed to two or more senders (upstream PEs). Only one stream is forwarded to the customer network, however, because the sender-based RPF running on the egress PE prevents any duplication.

Note that fast failover only supports VRF configured with a virtual tunnel (VT) interface, that is, anchored to a tunnel PIC to provide upstream tunnel termination. Label switched interfaces (LSI) are not supported.

Hot root standby can handle the failure or restoration of one upstream UMH at a time. Multiple network events or failures cannot be handled within 50ms. In scenarios with multiple network events, convergence will normally follow the timeframe of unicast convergence. However if the revert-delay timer is active, the router might wait for the timer to expire before installing the updated route. Though the switchover from one path to another is based on the monitored traffic rate, UMH selection is based on the unicast reachability of the upstream PE. There can be a maximum of two active UMHs at any time from which traffic can be forwarded.

Options

rate—Specify a rate to represent the typical flow rate of aggregate multicast traffic from the provider tunnel (P tunnel). Aggregate multicast traffic from the P tunnel is monitored, and if it falls below the threshold set here a failover to the hot-root standby is triggered.

• Range: 3 Mb through 100 Gb

revert-delay seconds—Use the specified interval to allow time for the network to converge when and if the original link comes back online. You can specify a time, in seconds, for the router to wait before updating its multicast routes. For example, if the original link goes down and triggers the switchover to an alternative link, and then the original link comes back up, the update of multicast routes reflecting the new path can be delayed to accommodate the time it may take to for the network to converge back on the original link.

The revert-delay timer is triggered when the old primary upstream path is designated as the new backup path and a new primary path is coming up. During this time, the PFE maintains the forwarding states of the old primary path from which the traffic is forwarded until the new primary path is established or until the revert-delay timer expires. UMH selection is based on the unicast reachability of the upstream PE and is the only criterion for triggering the revert-delay timer.

• Range: 0 through 600 seconds

ipmsi-min-rate (optional)—Configure a separate min-rate threshold for IPMSI traffic. If not configured, the existing configuration for min-rate will be applicable to both IPMSI and SPMSI traffic.

Selective traffic is per-flow and would be much lesser than inclusive traffic which is the combined traffic of multiple flows. In a transient state, when the primary ingress PE's forwarding states are being updated to remove the core facing provider tunnel (ptnl) from the multicast S,G flows, traffic continues to be forwarded over the core for the flows which are not yet updated. If the threshold configured for min-rate is greatly lesser than the actual inclusive tunnel traffic, even with flows updated to not forward traffic over the core on the ingress PE, the remaining traffic would still be greater than the threshold, therefore the failover to the backup path is not triggered. You will observe traffic loss for the flows which are already updated on the ingress PE until the overall inclusive traffic rate goes below the configured min-rate and the traffic is switched to the backup path. This situation can be avoided with the introduction of ipmsi-min-rate, with a separately configurable threshold for inclusive traffic, exclusive of the min-rate for all other traffic.

• Range: 3 Mb through 100 Gb

Required Privilege Level

routing—To view this statement in the configuration.

routing-control—To add this statement to the configuration.

Release Information

Statement introduced in Junos OS Release 16.1.

Non-revertive behavior introduced in Junos OS Release 22.4R3-S1.

ipmsi-min-rate introduced in Junos OS Release 24.2R1.