Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

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-services statement at the [edit chassis fpc slot-number pic number] hierarchy level

Note: 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.

Note: 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.

1. On an M Series or T Series router or on an EX Series switch, install more than one tunnel-capable PIC. (In some implementations, only one PIC is required. Load balancing is based on the assumption that a routing device has more than one tunnel-capable PIC.)
2. On an MX Series router, configure more than one tunnel-capable PIC.
   [edit chassis fpc 0]user@host# set pic 0 tunnel-services bandwidth 10guser@host# set pic 1 tunnel-services bandwidth 10g
3. Configure Layer 3 VPNs as described in Example: Configuring Any-Source Multicast for Draft-Rosen VPNs.
   [edit routing-instances vpn1]user@host# set provider-tunnel pim-asm group-address 234.1.1.1user@host# set protocols pim rp static address 10.255.72.48 user@host# set protocols pim interface fe-1/0/0.0user@host# set protocols pim interface lo0.1
4. For each VPN, specify a PIC list.
   [edit routing-instances vpn1 protocols pim]user@host# set tunnel-devices [ mt-1/1/0 mt-1/2/0 mt-2/0/0 ]

   The physical position of the PIC in the routing device determines the multicast tunnel interface name. For example, if you have an Adaptive Services PIC installed in FPC slot 0 and PIC slot 0, the corresponding multicast tunnel interface name is mt-0/0/0. The same is true for Tunnel Services PICs, Multiservices PICs, and Multiservices DPCs.

   In the tunnel-devices statement, the order of the PIC list that you specify does not impact how the interfaces are allocated. An instance uses all of the listed PICs to create default encapsulation and de-encapsulation interfaces, and data MDT encapsulation interfaces. The instance uses a round-robin approach to distributing the tunnel interfaces (default and data MDT) across the PIC list (or across the available PICs, in the absence of a PIC list).

   For the first tunnel, the round-robin algorithm starts with the lowest-numbered PIC. The second tunnel is created on the next-lowest-numbered PIC, and so on, round and round. The selection algorithm works routing device-wide. The round robin does not restart at the lowest-numbered PIC for each new instance. This applies to both the default and data MDT tunnel interfaces.

   If one PIC in the list fails, new tunnel interfaces are created on the remaining PICs in the list using the round-robin algorithm. If all the PICs in the list go down, all tunnel interfaces are deleted and no new tunnel interfaces are created. If a PIC in the list comes up from the down state and the restored PIC is the only PIC that is up, the interfaces are reassigned to the restored PIC. If a PIC in the list comes up from the down state and other PICs are already up, an interface reassignment is not done. However, when a new tunnel interface needs to be created, the restored PIC is available for the selection process. If you include in the PIC list a PIC that is not installed on the routing device, the PIC is treated as if it is present but in the down state.

   To balance the interfaces among the instances, you can assign one PIC to each instance. For example, if you have vpn1-10 and you have three PICs—for example, mt-1/1/0, mt-1/2/0, mt-2/0/0—you can configure vpn1-4 to only use mt-1/1/0, vpn5-7 to use mt-1/2/0, and vpn8-10 to use mt-2/0/0.

5. Commit the configuration.
   user@host# commit

   When you commit a new PIC list configuration, all the multicast tunnel interfaces for the routing instance are deleted and re-created using the new PIC list.

6. If you reboot the routing device, some PICs come up faster than others. The difference can be minutes. Therefore, when the tunnel interfaces are created, the known PIC list might not be the same as when the routing device is fully rebooted. This causes the tunnel interfaces to be created on some but not all available and configured PICs. To remedy this situation, you can manually rebalance the PIC load.

   Check to determine if a load rebalance is necessary.

   user@host#> show interfaces terse | match mt-

   mt-1/1/0        up     up
   mt-1/1/0.32768  up     up      inet
   mt-1/1/0.1081344  up     up      inet
   mt-1/2/0        up     up
   mt-1/2/0.32769  up     up      inet
   mt-1/2/0.32770  up     up      inet
   mt-1/2/0.32771  up     up      inet

   The output shows that mt-1/1/0 has only one tunnel encapsulation interface, while mt-1/2/0 has three tunnel encapsulation interfaces. In a case like this, you might decide to rebalance the interfaces. As stated previously, encapsulation interfaces are in the range from 32,768 through 49,151. In determining whether a rebalance is necessary, look at the encapsulation interfaces only, because the default MDT de-encapsulation interface always resides on the same PIC with the default MDT encapsulation interface.

7. (Optional) Rebalance the PIC load.
   user@host#> request pim multicast-tunnel rebalance instance vpn1

   This command re-creates and rebalances all tunnel interfaces for a specific instance.

   user@host#> request pim multicast-tunnel rebalance

   This command re-creates and rebalances all tunnel interfaces for all routing instances.

8. Verify that the PIC load is balanced.
   user@host#> show interfaces terse | match mt-

   mt-1/1/0        up     up
   mt-1/1/0.32770  up     up      inet
   mt-1/1/0.32768  up     up      inet
   mt-1/1/0.1081344  up     up      inet
   mt-1/2/0        up     up
   mt-1/2/0.32769  up     up      inet
   mt-1/2/0.32771  up     up      inet

   The output shows that mt-1/1/0 has two encapsulation interfaces, and mt-1/2/0 also has two encapsulation interfaces.