- play_arrow Overview
- play_arrow Managing Group Membership
- play_arrow Configuring IGMP and MLD
- play_arrow Configuring IGMP Snooping
- IGMP Snooping Overview
- Overview of Multicast Forwarding with IGMP Snooping or MLD Snooping in an EVPN-VXLAN Environment
- Configuring IGMP Snooping on Switches
- Example: Configuring IGMP Snooping on Switches
- Example: Configuring IGMP Snooping on EX Series Switches
- Verifying IGMP Snooping on EX Series Switches
- Changing the IGMP Snooping Group Timeout Value on Switches
- Monitoring IGMP Snooping
- Example: Configuring IGMP Snooping
- Example: Configuring IGMP Snooping on SRX Series Devices
- Configuring Point-to-Multipoint LSP with IGMP Snooping
- play_arrow Configuring MLD Snooping
- Understanding MLD Snooping
- Configuring MLD Snooping on an EX Series Switch VLAN (CLI Procedure)
- Configuring MLD Snooping on a Switch VLAN with ELS Support (CLI Procedure)
- Example: Configuring MLD Snooping on EX Series Switches
- Example: Configuring MLD Snooping on SRX Series Devices
- Configuring MLD Snooping Tracing Operations on EX Series Switches (CLI Procedure)
- Configuring MLD Snooping Tracing Operations on EX Series Switch VLANs (CLI Procedure)
- Example: Configuring MLD Snooping on EX Series Switches
- Example: Configuring MLD Snooping on Switches with ELS Support
- Verifying MLD Snooping on EX Series Switches (CLI Procedure)
- Verifying MLD Snooping on Switches
- play_arrow Configuring Multicast VLAN Registration
-
- play_arrow Configuring Protocol Independent Multicast
- play_arrow Understanding PIM
- play_arrow Configuring PIM Basics
- Configuring Different PIM Modes
- Configuring Multiple Instances of PIM
- Changing the PIM Version
- Optimizing the Number of Multicast Flows on QFabric Systems
- Modifying the PIM Hello Interval
- Preserving Multicast Performance by Disabling Response to the ping Utility
- Configuring PIM Trace Options
- Configuring BFD for PIM
- Configuring BFD Authentication for PIM
- play_arrow Routing Content to Densely Clustered Receivers with PIM Dense Mode
- play_arrow Routing Content to Larger, Sparser Groups with PIM Sparse Mode
- Understanding PIM Sparse Mode
- Examples: Configuring PIM Sparse Mode
- Configuring Static RP
- Example: Configuring Anycast RP
- Configuring PIM Bootstrap Router
- Understanding PIM Auto-RP
- Configuring All PIM Anycast Non-RP Routers
- Configuring a PIM Anycast RP Router with MSDP
- Configuring Embedded RP
- Configuring PIM Filtering
- Examples: Configuring PIM RPT and SPT Cutover
- Disabling PIM
- play_arrow Configuring Designated Routers
- play_arrow Receiving Content Directly from the Source with SSM
- Understanding PIM Source-Specific Mode
- Example: Configuring Source-Specific Multicast
- Example: Configuring PIM SSM on a Network
- Example: Configuring an SSM-Only Domain
- Example: Configuring SSM Mapping
- Example: Configuring Source-Specific Multicast Groups with Any-Source Override
- Example: Configuring SSM Maps for Different Groups to Different Sources
- play_arrow Minimizing Routing State Information with Bidirectional PIM
- play_arrow Rapidly Detecting Communication Failures with PIM and the BFD Protocol
- play_arrow Configuring PIM Options
- play_arrow Verifying PIM Configurations
-
- play_arrow Configuring Multicast Routing Protocols
- play_arrow Connecting Routing Domains Using MSDP
- play_arrow Handling Session Announcements with SAP and SDP
- play_arrow Facilitating Multicast Delivery Across Unicast-Only Networks with AMT
- play_arrow Routing Content to Densely Clustered Receivers with DVMRP
-
- play_arrow General Multicast Options
- play_arrow Bit Index Explicit Replication (BIER)
- play_arrow Prevent Routing Loops with Reverse Path Forwarding
- play_arrow Use Multicast-Only Fast Reroute (MoFRR) to Minimize Packet Loss During Link Failures
- play_arrow Enable Multicast Between Layer 2 and Layer 3 Devices Using Snooping
- play_arrow Configure Multicast Routing Options
- play_arrow Controller-Based BGP Multicast Signaling
-
- play_arrow Troubleshooting
- play_arrow Knowledge Base
-
- play_arrow Configuration Statements and Operational Commands
Example: Configuring Any-Source Draft-Rosen 6 Multicast VPNs
Understanding Any-Source Multicast
Any-source multicast (ASM) is the form of multicast in which you can have multiple senders on the same group, as opposed to source-specific multicast where a single particular source is specified. The original multicast specification, RFC 1112, supports both the ASM many-to-many model and the SSM one-to-many model. For ASM, the (S,G) source, group pair is instead specified as (*,G), meaning that the multicast group traffic can be provided by multiple sources.
An ASM network must be able to determine the locations of all sources for a particular multicast group whenever there are interested listeners, no matter where the sources might be located in the network. In ASM, the key function of source discovery is a required function of the network itself.
In an environment where many sources come and go, such as for a video conferencing service, ASM is appropriate. Multicast source discovery appears to be an easy process, but in sparse mode it is not.
In PIM dense mode, it is simple enough to flood traffic to every router in the network so that every router learns the source address of the content for that multicast group.
However, in PIM sparse mode, traffic flooding is not a viable option as it presents issues related to scalability and network resource use.
See Also
Example: Configuring Any-Source Multicast for Draft-Rosen VPNs
This example shows how to configure an any-source multicast VPN (MVPN) using dual PIM configuration with a customer RP and provider RP and mapping the multicast routes from customer to provider (known as draft-rosen). The Junos OS complies with RFC 4364 and Internet draft draft-rosen-vpn-mcast-07.txt, Multicast in MPLS/BGP VPNs.
Requirements
Before you begin:
Configure the router interfaces. See the Junos OS Network Interfaces Library for Routing Devices.
Configure an interior gateway protocol or static routing. See the Junos OS Routing Protocols Library for Routing Devices.
Configure the VPN. See the Junos OS VPNs Library for Routing Devices.
Configure the VPN import and VPN export policies. See Configuring Policies for the VRF Table on PE Routers in VPNs in the Junos OS VPNs Library for Routing Devices.
Make sure that the routing devices support multicast tunnel (mt) interfaces for encapsulating and de-encapsulating data packets into tunnels. See Tunnel Services PICs and Multicast and Load Balancing Multicast Tunnel Interfaces Among Available PICs.
For multicast to work on draft-rosen Layer 3 VPNs, each of the following routers must have tunnel interfaces:
Each provider edge (PE) router.
Any provider (P) router acting as the RP.
Any customer edge (CE) router that is acting as a source's DR or as an RP. A receiver's designated router does not need a Tunnel Services PIC.
Overview
Draft-rosen multicast virtual private networks (MVPNs) can be configured to support service provider tunnels operating in any-source multicast (ASM) mode or source-specific multicast (SSM) mode.
In this example, the term multicast Layer 3 VPNs is used to refer to draft-rosen MVPNs.
This example includes the following settings.
interface lo0.1—Configures an additional unit on the loopback interface of the PE router. For the lo0.1 interface, assign an address from the VPN address space. Add the lo0.1 interface to the following places in the configuration:
VRF routing instance
PIM in the VRF routing instance
IGP and BGP policies to advertise the interface in the VPN address space
In multicast Layer 3 VPNs, the multicast PE routers must use the primary loopback address (or router ID) for sessions with their internal BGP peers. If the PE routers use a route reflector and the next hop is configured as self, Layer 3 multicast over VPN will not work, because PIM cannot transmit upstream interface information for multicast sources behind remote PEs into the network core. Multicast Layer 3 VPNs require that the BGP next-hop address of the VPN route match the BGP next-hop address of the loopback VRF instance address.
protocols pim interface—Configures the interfaces between each provider router and the PE routers. On all CE routers, include this statement on the interfaces facing toward the provider router acting as the RP.
protocols pim mode sparse—Enables PIM sparse mode on the lo0 interface of all PE routers. You can either configure that specific interface or configure all interfaces with the
interface allstatement. On CE routers, you can configure sparse mode or sparse-dense mode.protocols pim rp local—On all routers acting as the RP, configure the address of the local lo0 interface. The P router acts as the RP router in this example.
protocols pim rp static—On all PE and CE routers, configure the address of the router acting as the RP.
It is possible for a PE router to be configured as the VPN customer RP (C-RP) router. A PE router can also act as the DR. This type of PE configuration can simplify configuration of customer DRs and VPN C-RPs for multicast VPNs. This example does not discuss the use of the PE as the VPN C-RP.
Figure 1 shows multicast connectivity on the customer edge. In the figure, CE2 is the RP router. However, the RP router can be anywhere in the customer network.
Figure 1: Multicast Connectivity on the CE Routers
protocols pim version 2—Enables PIM version 2 on the lo0 interface of all PE routers and CE routers. You can either configure that specific interface or configure all interfaces with the
interface allstatement.group-address—In a routing instance, configure multicast connectivity for the VPN on the PE routers. Configure a VPN group address on the interfaces facing toward the router acting as the RP.
The PIM configuration in the VPN routing and forwarding (VRF) instance on the PE routers needs to match the master PIM instance on the CE router. Therefore, the PE router contains both a master PIM instance (to communicate with the provider core) and the VRF instance (to communicate with the CE routers).
VRF instances that are part of the same VPN share the same VPN group address. For example, all PE routers containing multicast-enabled routing instance VPN-A share the same VPN group address configuration. In Figure 2, the shared VPN group address configuration is 239.1.1.1.
Figure 2: Multicast Connectivity for the VPN
routing-instances instance-name protocols pim rib-group—Adds the routing group to the VPN's VRF instance.
routing-options rib-groups—Configures the multicast routing group.
Topology
This example describes how to configure multicast in PIM sparse mode for a range of multicast addresses for VPN-A as shown in Figure 3.
Configuration
Procedure
CLI Quick Configuration
To quickly configure this example, copy the following commands, paste
them into a text file, remove any line breaks, change any details necessary to match your
network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.
PE1
set interfaces lo0 unit 0 family inet address 192.168.27.13/32 primary set interfaces lo0 unit 0 family inet address 127.0.0.1/32 set interfaces lo0 unit 1 family inet address 10.10.47.101/32 set protocols pim rp static address 10.255.71.47 set protocols pim interface fxp0.0 disable set protocols pim interface all mode sparse set protocols pim interface all version 2 set routing-instances VPN-A instance-type vrf set routing-instances VPN-A interface t1-1/0/0:0.0 set routing-instances VPN-A interface lo0.1 set routing-instances VPN-A route-distinguisher 10.255.71.46:100 set routing-instances VPN-A vrf-import VPNA-import set routing-instances VPN-A vrf-export VPNA-export set routing-instances VPN-A protocols ospf export bgp-to-ospf set routing-instances VPN-A protocols ospf area 0.0.0.0 interface t1-1/0/0:0.0 set routing-instances VPN-A protocols ospf area 0.0.0.0 interface lo0.1 set routing-instances VPN-A protocols pim rib-group inet VPNA-mcast-rib set routing-instances VPN-A protocols pim rp static address 10.255.245.91 set routing-instances VPN-A protocols pim interface t1-1/0/0:0.0 mode sparse set routing-instances VPN-A protocols pim interface t1-1/0/0:0.0 version 2 set routing-instances VPN-A protocols pim interface lo0.1 mode sparse set routing-instances VPN-A protocols pim interface lo0.1 version 2 set routing-instances VPN-A provider-tunnel pim-asm group-address 239.1.1.1 set routing-instances VPN-A protocols pim mvpn set routing-options interface-routes rib-group inet VPNA-mcast-rib set routing-options rib-groups VPNA-mcast-rib export-rib VPN-A.inet.2 set routing-options rib-groups VPNA-mcast-rib import-rib VPN-A.inet.2
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.
To configure multicast for draft-rosen VPNs:
Configure PIM on the P router.
content_copy zoom_out_map[edit] user@host# edit protocols pim [edit protocols pim] user@host# set dense-groups 224.0.1.39/32 [edit protocols pim] user@host# set dense-groups 224.0.1.40/32 [edit protocols pim] user@host# set rp local address 10.255.71.47 [edit protocols pim] user@host# set interface all mode sparse [edit protocols pim] user@host# set interface all version 2 [edit protocols pim] user@host# set interface fxp0.0 disable
Configure PIM on the PE1 and PE2 routers. Specify a static RP—the P router (10.255.71.47).
content_copy zoom_out_map[edit] user@host# edit protocols pim [edit protocols pim] user@host# set rp static address 10.255.71.47 [edit protocols pim] user@host# set interface interface all mode sparse [edit protocols pim] user@host# set interface interface all version 2 [edit protocols pim] user@host# set interface fxp0.0 disable [edit protocols pim] user@host# exit
Configure PIM on CE1. Specify the RP address for the VPN RP—Router CE2 (10.255.245.91).
content_copy zoom_out_map[edit] user@host# edit protocols pim [edit protocols pim] user@host# set rp static address 10.255.245.91 [edit protocols pim] user@host# set interface all mode sparse [edit protocols pim] user@host# set interface all version 2 [edit protocols pim] user@host# set interface fxp0.0 disable [edit protocols pim] user@host# exit
Configure PIM on CE2, which acts as the VPN RP. Specify CE2's address (10.255.245.91).
content_copy zoom_out_map[edit] user@host# edit protocols pim [edit protocols pim] user@host# set rp local address 10.255.245.91 [edit protocols pim] user@host# set interface all mode sparse [edit protocols pim] user@host# set interface all version 2 [edit protocols pim] user@host# set interface fxp0.0 disable [edit protocols pim] user@host# exit
On PE1, configure the routing instance (VPN-A) for the Layer 3 VPN.
content_copy zoom_out_map[edit] user@host# edit routing-instances VPN-A [edit routing-instances VPN-A] user@host# set instance-type vrf [edit routing-instances VPN-A] user@host# set interface t1-1/0/0:0.0 [edit routing-instances VPN-A] user@host# set interface lo0.1 [edit routing-instances VPN-A] user@host# set route-distinguisher 10.255.71.46:100 [edit routing-instances VPN-A] user@host# set vrf-import VPNA-import [edit routing-instances VPN-A] user@host# set vrf-export VPNA-export
On PE1, configure the IGP policy to advertise the interfaces in the VPN address space.
content_copy zoom_out_map[edit routing-instances VPN-A] user@host# set protocols ospf export bgp-to-ospf [edit routing-instances VPN-A] user@host# set protocols ospf area 0.0.0.0 interface t1-1/0/0:0.0 [edit routing-instances VPN-A] user@host# set protocols ospf area 0.0.0.0 interface lo0.1
On PE1, set the RP configuration for the VRF instance. The RP configuration within the VRF instance provides explicit knowledge of the RP address, so that the (*,G) state can be forwarded.
content_copy zoom_out_map[edit routing-instances VPN-A] user@host# set protocols pim mvpn [edit routing-instances VPN-A] user@host# set protocols provider-tunnel pim-asm group-address 239.1.1.1 [edit routing-instances VPN-A] user@host# set protocols pim rp static address 10.255.245.91 [edit routing-instances VPN-A] user@host# set protocols pim interface t1-1/0/0:0.0 mode sparse [edit routing-instances VPN-A] user@host# set protocols pim interface t1-1/0/0:0.0 version 2 [edit routing-instances VPN-A] user@host# set protocols pim interface lo0.1 mode sparse [edit routing-instances VPN-A] user@host# set protocols pim interface lo0.1 version 2 [edit routing-instances VPN-A] user@host# exit
On PE1, configure the loopback interfaces.
content_copy zoom_out_map[edit] user@host# edit interface lo0 [edit interface lo0] user@host# set unit 0 family inet address 192.168.27.13/32 primary [edit interface lo0] user@host# set unit 0 family inet address 127.0.0.1/32 [edit interface lo0] user@host# set unit 1 family inet address 10.10.47.101/32 [edit interface lo0] user@host# exit
As you did for the PE1 router, configure the PE2 router.
content_copy zoom_out_map[edit] user@host# edit routing-instances VPN-A [edit routing-instances VPN-A] user@host# set instance-type vrf [edit routing-instances VPN-A] user@host# set interface t1-2/0/0:0.0 [edit routing-instances VPN-A] user@host# set interface lo0.1 [edit routing-instances VPN-A] user@host# set route-distinguisher 10.255.71.51:100 [edit routing-instances VPN-A] user@host# set vrf-import VPNA-import [edit routing-instances VPN-A] user@host# set vrf-export VPNA-export [edit routing-instances VPN-A] user@host# set protocols ospf export bgp-to-ospf [edit routing-instances VPN-A] user@host# set protocols ospf area 0.0.0.0 interface t1-2/0/0:0.0 [edit routing-instances VPN-A] user@host# set protocols ospf area 0.0.0.0 interface lo0.1 [edit routing-instances VPN-A] user@host# set protocols pim rp static address 10.255.245.91 [edit routing-instances VPN-A] user@host# set protocols pim mvpn [edit routing-instances VPN-A] user@host# set protocols pim interface t1-2/0/0:0.0 mode sparse [edit routing-instances VPN-A] user@host# set protocols pim interface lo0.1 mode sparse [edit routing-instances VPN-A] user@host# set protocols pim interface lo0.1 version 2 [edit routing-instances VPN-A] user@host# set provider-tunnel pim-asm group-address 239.1.1.1 user@host# exit [edit] user@host# edit interface lo0 [edit interface lo0] user@host# set unit 0 family inet address 192.168.27.14/32 primary [edit interface lo0] user@host# set unit 0 family inet address 127.0.0.1/32 [edit interface lo0] user@host# set unit 1 family inet address 10.10.47.102/32
When one of the PE routers is running Cisco Systems IOS software, you must configure the Juniper Networks PE router to support this multicast interoperability requirement. The Juniper Networks PE router must have the lo0.0 interface in the master routing instance and the lo0.1 interface assigned to the VPN routing instance. You must configure the lo0.1 interface with the same IP address that the lo0.0 interface uses for BGP peering in the provider core in the master routing instance.
Configure the same IP address on the lo0.0 and lo0.1 loopback interfaces of the Juniper Networks PE router at the
[edit interfaces lo0]hierarchy level, and assign the address used for BGP peering in the provider core in the master routing instance. In this alternate example, unit 0 and unit 1 are configured for Cisco IOS interoperability.content_copy zoom_out_map[edit interface lo0] user@host# set unit 0 family inet address 192.168.27.14/32 primary [edit interface lo0] user@host# set unit 0 family inet address 127.0.0.1/32 [edit interface lo0] user@host# set unit 1 family inet address 192.168.27.14/32 [edit interface lo0] user@host# exit
Configure the multicast routing table group. This group accesses inet.2 when doing RPF checks. However, if you are using inet.0 for multicast RPF checks, this step will prevent your multicast configuration from working.
content_copy zoom_out_map[edit] user@host# edit routing-options [edit routing-options] user@host# set interface-routes rib-group inet VPNA-mcast-rib [edit routing-options] user@host# set rib-groups VPNA-mcast-rib export-rib VPN-A.inet.2 [edit routing-options] user@host# set rib-groups VPNA-mcast-rib import-rib VPN-A.inet.2 [edit routing-options] user@host# exit
Activate the multicast routing table group in the VPN's VRF instance.
content_copy zoom_out_map[edit] user@host# edit routing-instances VPN-A [edit routing-instances VPN-A] user@host# set protocols pim rib-group inet VPNA-mcast-rib
If you are done configuring the device, commit the configuration.
content_copy zoom_out_map[edit routing-instances VPN-A] user@host# commit
Results
Confirm your configuration by entering the show interfaces, show protocols, show routing-instances, and show routing-options commands from configuration mode. If the output does not display the intended configuration,
repeat the instructions in this example to correct the configuration. This output shows the
configuration on PE1.
user@host# show interfaces
lo0 {
unit 0 {
family inet {
address 192.168.27.13/32 {
primary;
}
address 127.0.0.1/32;
}
}
unit 1 {
family inet {
address 10.10.47.101/32;
}
}
}
user@host# show protocols
pim {
rp {
static {
address 10.255.71.47;
}
}
interface fxp0.0 {
disable;
}
interface all {
mode sparse;
version 2;
}
}
user@host# show routing-instances
VPN-A {
instance-type vrf;
interface t1-1/0/0:0.0;
interface lo0.1;
route-distinguisher 10.255.71.46:100;
vrf-import VPNA-import;
vrf-export VPNA-export;
provider-tunnel {
pim-asm {
group-address 239.1.1.1;
}
}
protocols {
ospf {
export bgp-to-ospf;
area 0.0.0.0 {
interface t1-1/0/0:0.0;
interface lo0.1;
}
}
pim {
mvpn;
rib-group inet VPNA-mcast-rib;
rp {
static {
address 10.255.245.91;
}
}
interface t1-1/0/0:0.0 {
mode sparse;
version 2;
}
interface lo0.1 {
mode sparse;
version 2;
}
}
}
}
user@host# show routing-options
interface-routes {
rib-group inet VPNA-mcast-rib;
}
rib-groups {
VPNA-mcast-rib {
export-rib VPN-A.inet.2;
import-rib VPN-A.inet.2;
}
}
Verification
To verify the configuration, run the following commands:
Display multicast tunnel information and the number of neighbors by using the
show pim interfaces instance instance-namecommand from the PE1 or PE2 router. When issued from the PE1 router, the output display is:content_copy zoom_out_mapuser@host> show pim interfaces instance VPN-A Instance: PIM.VPN-A Name Stat Mode IP V State Count DR address lo0.1 Up Sparse 4 2 DR 0 10.10.47.101 mt-1/1/0.32769 Up Sparse 4 2 DR 1 mt-1/1/0.1081346 Up Sparse 4 2 DR 0 pe-1/1/0.32769 Up Sparse 4 1 P2P 0 t1-2/1/0:0.0 Up Sparse 4 2 P2P 1
You can also display all PE tunnel interfaces by using the
show pim joincommand from the provider router acting as the RP.Display multicast tunnel interface information, DR information, and the PIM neighbor status between VRF instances on the PE1 and PE2 routers by using the
show pim neighbors instance instance-namecommand from either PE router. When issued from the PE1 router, the output is as follows:content_copy zoom_out_mapuser@host> show pim neighbors instance VPN-A Instance: PIM.VPN-A Interface IP V Mode Option Uptime Neighbor addr mt-1/1/0.32769 4 2 HPL 01:40:46 10.10.47.102 t1-1/0/0:0.0 4 2 HPL 01:41:41 192.168.196.178
Load Balancing Multicast Tunnel Interfaces Among Available PICs
When you configure multicast on draft-rosen Layer 3 VPNs, multicast tunnel interfaces are automatically generated to encapsulate and de-encapsulate control and data traffic.
To generate multicast tunnel interfaces, a routing device must have one or more of the following tunnel-capable PICs:
Adaptive Services PIC
Multiservices PIC or Multiservices DPC
Tunnel Services PIC
On MX Series routers, a PIC created with the
tunnel-servicesstatement at the[edit chassis fpc slot-number pic number]hierarchy level
A routing device is a router or an EX Series switch that is functioning as a router.
If a routing device has multiple such PICs, it might be important in your implementation to load balance the tunnel interfaces across the available tunnel-capable PICs.
The multicast tunnel interface
that is used for encapsulation, mt-[xxxxx], is in the range from 32,768 through 49,151. The interface mt-[yyyyy], used for de-encapsulation,
is in the range from 1,081,344 through 1,107,827. PIM runs only on
the encapsulation interface. The de-encapsulation interface populates
downstream interface information. For the default MDT, an instance’s
de-encapsulation and encapsulation interfaces are always created on
the same PIC.
For each VPN, the PE routers build a multicast distribution tree within the service provider core network. After the tree is created, each PE router encapsulates all multicast traffic (data and control messages) from the attached VPN and sends the encapsulated traffic to the VPN group address. Because all the PE routers are members of the outgoing interface list in the multicast distribution tree for the VPN group address, they all receive the encapsulated traffic. When the PE routers receive the encapsulated traffic, they de-encapsulate the messages and send the data and control messages to the CE routers.
If a routing device has multiple tunnel-capable PICs (for example, two Tunnel Services PICs), the routing device load balances the creation of tunnel interfaces among the available PICs. However, in some cases (for example, after a reboot), a single PIC might be selected for all of the tunnel interfaces. This causes one PIC to have a heavy load, while other available PICs are underutilized. To prevent this, you can manually configure load balancing. Thus, you can configure and distribute the load uniformly across the available PICs.
The definition of a balanced state is determined by you and by the requirements of your Layer 3 VPN implementation. You might want all of the instances to be evenly distributed across the available PICs or across a configured list of PICs. You might want all of the encapsulation interfaces from all of the instances to be evenly distributed across the available PICs or across a configured list of PICs. If the bandwidth of each tunnel encapsulation interface is considered, you might choose a different distribution. You can design your load-balancing configuration based on each instance or on each routing device.
In a Layer 3 VPN, each of the following routing devices must have at least one tunnel-capable PIC:
Each provider edge (PE) router.
Any provider (P) router acting as the RP.
Any customer edge (CE) router that is acting as a source's DR or as an RP. A receiver's designated router does not need a tunnel-capable PIC.
To configure load balancing:
