specified by the timer. This is a random timer with value ranges between 0 to
Max Override Interval. The timer is reset each time join suppression is triggered,
and the defer period is dependent on other settings in the LAN prune delay,
including propagation-delay and override-interval.
Use the show protocols PIM command to see if the reset-tracking-bit is present,
indicating that the T-bit has been changed to 0 and PIM join suppression is
enabled.
[Multicast, Routing Protocols and Policies Command Reference]
■ Improve IGMPv3 snooping performance using bulk updates 1a3,14—Whenever
an individual interface joins or leaves a multicast group, a new next-hop entry
is installed in the routing table and the forwarding table. This can require a lot
of processing time when the frequency and number of IGMP join and leave
messages are high.
A new configuration statement can be used to accumulate outgoing interface
changes and perform bulk updates to the routing table and forwarding table.
This reduces the processing time and memory overhead required when processing
join and leave messages, thus improving scalability.This is useful for applications
such as Internet Protocol television (IPTV), in which users changing channels
can create thousands of interfaces joining or leaving a group in a short period
of time.
To enable bulk updates of join and leave messages, include the next-hop-hold-time
statement and specify the number of milliseconds to wait before processing the
messages. The next-hop-hold-time statement can be configured at the [edit
routing-instances routing-instance-name] hierarchy level. The hold time can be
configured from 1 to 1000 milliseconds. The routing instance must be of type
VPLS or virtual-switch.
If the next-hop-hold-time statement is deleted from the router configuration, IGMP
bulk updates are disabled. The configuration of the next-hop-hold-time statement
can be verified using the show multicast snooping route command.
[Multicast, Routing Protocols and Policies Command Reference]
■ Hub-and-spoke support for multiprotocol BGP-based multicast VPNs with
PIM-SSM GRE S-PMSI transport—Multiprotocol BGP-based (MBGP) multicast
VPNs (also referred to as next-generation Layer 3 VPN multicast) can be
configured using protocol-independent multicast source-specific multicast
(PIM-SSM) selective provider multicast service interface (S-PMSI) tunnels in a
hub-and-spoke topology.
This feature is useful in the following scenarios:
■ Customer sources and rendezvous points (RPs) are located only in the hub
sites and customer receivers are located in spoke sites or other hub sites.
■ Customer sources are located only in spoke sites and customer receivers are
located only in hub sites.
To configure MBGP MVPNs to use PIM-SSM S-PMSI tunnels in a hub-and-spoke
topology:
■
Include the group-range statement and specify the group address range at
the [edit routing-instances routing-instance-name provider-tunnel selective group
New Features in JUNOS Release 10.1 for M Series, MX Series, and T Series Routers ■ 25
New Features in JUNOS Release 10.1 for M Series, MX Series, and T Series Routers
To Next Page
Loading...
Need help?
General
