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
