Point-to-Multipoint LSP Configuration

A point-to-multipoint MPLS LSP is an LSP with a single source and multiple destinations. By taking advantage of the MPLS packet replication capability of the network, point-to-multipoint LSPs avoid unnecessary packet replication at the ingress router. Packet replication takes place only when packets are forwarded to two or more different destinations requiring different network paths.

This process is illustrated in Figure 1. Router PE1 is configured with a point-to-multipoint LSP to Routers PE2, PE3, and PE4. When Router PE1 sends a packet on the point-to-multipoint LSP to Routers P1 and P2, Router P1 replicates the packet and forwards it to Routers PE2 and PE3. Router P2 sends the packet to Router PE4.

This feature is described in detail in the Internet drafts draft-raggarwa-mpls-p2mp-te-02.txt (expired February 2004), Establishing Point to Multipoint MPLS TE LSPs, draft-ietf-mpls-rsvp-te-p2mp-02.txt, Extensions to Resource Reservation Protocol-Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label-Switched Paths (LSPs), and RFC 6388, Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths (only point-to-multipoint LSPs are supported).

Figure 1: Point-to-Multipoint LSPs

The following are some of the properties of point-to-multipoint LSPs:

• A point-to-multipoint LSP enables you to use MPLS for point-to-multipoint data distribution. This functionality is similar to that provided by IP multicast.

• You can add and remove branch LSPs from a main point-to-multipoint LSP without disrupting traffic. The unaffected parts of the point-to-multipoint LSP continue to function normally.

• You can configure a node to be both a transit and an egress router for different branch LSPs of the same point-to-multipoint LSP.

• You can enable link protection on a point-to-multipoint LSP. Link protection can provide a bypass LSP for each of the branch LSPs that make up the point-to-multipoint LSP. If any of the primary paths fail, traffic can be quickly switched to the bypass.

• You can configure branch LSPs either statically, dynamically, or as a combination of static and dynamic LSPs.

• You can enable graceful Routing Engine switchover (GRES) and graceful restart for point-to-multipoint LSPs at ingress and egress routers. The point-to-multipoint LSPs must be configured using either static routes or circuit cross-connect (CCC). GRES and graceful restart allow the traffic to be forwarded at the Packet Forwarding Engine based on the old state while the control plane recovers. Feature parity for GRES and graceful restart for MPLS point-to-multipoint LSPs on the Junos Trio chipset is supported in Junos OS Releases 11.1R2, 11.2R2, and 11.4.

A point-to-multipoint MPLS label-switched path (LSP) is an LDP-signaled or RSVP-signaled LSP with a single source and multiple destinations. By taking advantage of the MPLS packet replication capability of the network, point-to-multipoint LSPs avoid unnecessary packet replication at the inbound (ingress) router. Packet replication takes place only when packets are forwarded to two or more different destinations requiring different network paths.

This process is illustrated in Figure 2. Device PE1 is configured with a point-to-multipoint LSP to Routers PE2, PE3, and PE4. When Device PE1 sends a packet on the point-to-multipoint LSP to Routers P1 and P2, Device P1 replicates the packet and forwards it to Routers PE2 and PE3. Device P2 sends the packet to Device PE4.

Figure 2: Point-to-Multipoint LSPs

Following are some of the properties of point-to-multipoint LSPs:

• A point-to-multipoint LSP allows you to use MPLS for point-to-multipoint data distribution. This functionality is similar to that provided by IP multicast.

• You can add and remove branch LSPs from a main point-to-multipoint LSP without disrupting traffic. The unaffected parts of the point-to-multipoint LSP continue to function normally.

• You can configure a node to be both a transit and an outbound (egress) router for different branch LSPs of the same point-to-multipoint LSP.

• You can enable link protection on a point-to-multipoint LSP. Link protection can provide a bypass LSP for each of the branch LSPs that make up the point-to-multipoint LSP. If any primary paths fail, traffic can be quickly switched to the bypass.

• You can configure subpaths either statically or dynamically.

• You can enable graceful restart on point-to-multipoint LSPs.

This example shows how to configure a collection of paths to create an RSVP-signaled point-to-multipoint label-switched path (LSP).

A point-to-multipoint MPLS label-switched path (LSP) is an RSVP LSP with multiple destinations. By taking advantage of the MPLS packet replication capability of the network, point-to-multipoint LSPs avoid unnecessary packet replication at the ingress router. For more information about point-to-multipoint LSPs, see Point-to-Multipoint LSPs Overview.

To configure a point-to-multipoint LSP, you need to configure the primary LSP from the ingress router and the branch LSPs that carry traffic to the egress routers, as described in the following sections:

• Configuring the Primary Point-to-Multipoint LSP
• Configuring a Branch LSP for Point-to-Multipoint LSPs

Link protection helps to ensure that traffic going over a specific interface to a neighboring router can continue to reach this router if that interface fails. When link protection is configured for an interface and a point-to-multipoint LSP that traverses this interface, a bypass LSP is created that handles this traffic if the interface fails. The bypass LSP uses a different interface and path to reach the same destination.

To extend link protection to all of the paths used by a point-to-multipoint LSP, link protection must be configured on each router that each branch LSP traverses. If you enable link protection on a point-to-multipoint LSP, you must enable link protection on all of the branch LSPs.

The Internet draft draft-ietf-mpls-rsvp-te-p2mp-01.txt, Extensions to RSVP-TE for Point to Multipoint TE LSPs, describes link protection for point-to-multipoint LSPs.

To enable link protection on point-to-multipoint LSPs, complete the following steps:

1. Configure link protection on each branch LSP. To configure link protection, include the link-protection statement:

   You can include this statement at the following hierarchy levels:

   • [edit protocols mpls label-switched-path branch-lsp-name]

   • [edit logical-systems logical-system-name protocols mpls label-switched-path branch-lsp-name]

2. Configure link protection for each RSVP interface on each router that the branch LSP traverses. For information about how to configure link protection on RSVP interfaces, see Configuring Link Protection on Interfaces Used by LSPs.

For more information on how to configure link protection, see Configuring Node Protection or Link Protection for LSPs.

You can configure graceful restart on point-to-multipoint LSPs. Graceful restart allows a router undergoing a restart to inform its adjacent neighbors of its condition. The restarting router requests a grace period from the neighbor or peer, which can then cooperate with the restarting router. The restarting router can still forward MPLS traffic during the restart period; convergence in the network is not disrupted. The restart is not apparent to the rest of the network, and the restarting router is not removed from the network topology. RSVP graceful restart can be enabled on both transit routers and ingress routers.

To enable graceful restart on a router handling point-to-multipoint LSP traffic, include the graceful-restart statement:

You can include this statement at the following hierarchy levels:

• [edit routing-options]

• [edit logical-systems logical-system-name routing-options]

The graceful restart configuration for point-to-multipoint LSPs is identical to that of point-to-point LSPs. For more information on how to configure graceful restart, see Configuring RSVP Graceful Restart.

You can control whether a reverse path forwarding (RPF) check is performed for a source and group entry before installing a route in the multicast forwarding cache. This makes it possible to use point-to-multipoint LSPs to distribute multicast traffic to PIM islands situated downstream from the egress routers of the point-to-multipoint LSPs.

By configuring the rpf-check-policy statement, you can disable RPF checks for a source and group pair. You would typically configure this statement on the egress routers of a point-to-multipoint LSP, because the interface receiving the multicast traffic on a point-to-multipoint LSP egress router might not always be the RPF interface.

You can also configure a routing policy to act upon a source and group pair. This policy behaves like an import policy, so if no policy term matches the input data, the default policy action is “acceptance.” An accept policy action enables RPF checks. A reject policy action (applied to all source and group pairs that are not accepted) disables RPF checks for the pair.

To configure a multicast RPF check policy for a point-to-multipoint LSP, specify the RPF check policy using the rpf-check-policy statement:

You can include this statement at the following hierarchy levels:

• [edit routing-options multicast]

• [edit logical-systems logical-system-name routing-options multicast]

You also must configure a policy for the multicast RPF check. You configure policies at the [edit policy-options] hierarchy level. For more information, see the Routing Policies, Firewall Filters, and Traffic Policers User Guide.

You can configure one or more PE routers as part of a backup PE router group to enable ingress PE router redundancy. You accomplish this by configuring the IP addresses of the backup PE routers (at least one backup PE router is required) and the local IP address used by the local PE router.

You must also configure a full mesh of point-to-point LSPs between the primary and backup PE routers. You also need to configure BFD on these LSPs. See Configuring BFD for RSVP-Signaled LSPs and Configuring BFD for LDP LSPs for more information.

To configure ingress PE router redundancy for point-to-multipoint LSPs, include the backup-pe-group statement:

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements.

After you configure the ingress PE router redundancy backup group, you must also apply the group to a static route on the PE router. This ensures that the static route is active (installed in the forwarding table) when the local PE router is the designated forwarder for the backup PE group. You can only associate a backup PE router group with a static route that also has the p2mp-lsp-next-hop statement configured. For more information, see Configuring Static Unicast Routes for Point-to-Multipoint LSPs.

In addition to acting as the ingress or egress for a given sub-LSP, the Packet Forwarding Engine on an FPC also serves as a transit point for other sub-LSPs of the same point-to-multipoint LSP. If an FPC fails, then all the sub-LSPs that it serves are affected.

You can configure a service that enables you to monitor the correlation between FPCs and the point-to-multipoint sub-LSPs—branch paths—that are on an LSR. This information helps you evaluate the effect a failed FPC has on the correlated sub-LSPs. When tracing is enabled, the service also provides syslog messages in the event of an FPC outage that provide detailed information about the sub-LSPs affected.

You can configure a service that enables you to monitor the correlation between FPCs and the point-to-multipoint sub-LSPs—branch paths—on an LSR. An FPC can act as an ingress, egress, or transit point for more than one sub-LSP of the same point-to-multipoint LSP. If an FPC fails, then all the sub-LSPs that it serves are affected.

The information provided by this service helps you evaluate the effect a failure in any FPC has on the correlated sub-LSPs and the point-to-multipoint network. You can use this knowledge to help plan controlled FPC outages.

You can also enable tracing of some or all service operations. The service then provides syslog messages with detailed information about the affected sub-LSPs that facilitates analysis of an FPC outage.

To enable the monitoring and correlation of sub-LSPs and FPCs in the point-to-multipoint network:

1. Configure the point-to-multipoint polling (p2mp_polling_duration) and FPC polling (fpc_polling_duration) by setting the frequency duration (in seconds) in the config.xml file located at the /etc/p2mp_lsp_correlation directory. You can also enable log levels in the config.xml file to configure traceoptions and the logs are created at the /var/log/p2mp_lsp_correlation directory. The log level and message types are as follows:

   The following is a sample config.xml file:

   • p2mp_polling_duration–Refreshes the database by executing various RE/PFE RPC requests. The default value for point-to-multipoint polling duration is 240.
   • fpc_polling_duration–Polls for status of the FPC/PFE to log the impact of point-to-multipoint sub-LSPs. The default for FPC polling duration is 60.
   Note:

   The config.xml file is applicable only for Junos OS Evolved. You need to restart the application after making changes to the config.xml file.

2. Enable the service.
3. Configure tracing of the service operations.
   Note:

   The set p2mp-sublsp-correlation traceoptions flag all command is not applicable for Junos OS Evolved.

When an FPC on an LSR fails or goes offline, all point-to-multipoint sub-LSPs on that FPC are affected. If you have previously enabled FPC correlation for the point-to-multipoint LSPs, and configured tracing for the correlation service, then upon FPC failure messages are logged that provide details about the affected sub-LSPs.

In this case, you need to examine the system log messages and the FPC correlation table to analyze the impact of an FPC failure.

The following is a sample system log output showing information about the point-to-multipoint sub-LSP when the impacted FPC goes offline:

To view the point-to-multipoint sub-LSP correlation information for ingress interface, use the show services p2mp-sublsp-correlation ingress-interface command as follows:

To view the point-to-multipoint sub-LSP correlation information for egress interface, use the show services p2mp-sublsp-correlation egress-interface command as follows:

To view the correlation information for FPC, use the show services p2mp-sublsp-correlation fpc 0 command as follows:

To view the correlation information for PFE instance, use the show services p2mp-sublsp-correlation fpc 0 pfe-instance 0 command as follows:

Configuring an LSP with the associate-backup-pe-groups statement enables it to monitor the status of the PE router to which it is configured. You can configure multiple backup PE router groups using the same router's address. A failure of this LSP indicates to all of the backup PE router groups that the destination PE router is down. The associate-backup-pe-groups statement is not tied to a specific backup PE router group. It applies to all groups that are interested in the status of the LSP to that address.

To allow an LSP to monitor the status of the egress PE router, include the associate-backup-pe-groups statement:

This statement can be configured at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]

If you configure the associate-backup-pe-groups statement, you must configure BFD for the point-to-point LSP. For information about how to configure BFD for an LSP, see Configuring BFD for MPLS IPv4 LSPs and Configuring BFD for LDP LSPs.

You also must configure a full mesh of point-to-point LSPs between the PE routers in the backup PE router group. A full mesh is required so that each PE router within the group can independently determine the status of the other PE routers, allowing each router to independently determine which PE router is currently the designated forwarder for the backup PE router group.

If you configure multiple LSPs with the associate-backup-pe-groups statement to the same destination PE router, the first LSP configured is used to monitor the forwarding state to that PE router. If you configure multiple LSPs to the same destination, make sure to configure similar parameters for the LSPs. With this configuration scenario, a failure notification might be triggered even though the remote PE router is still up.

In Junos OS Release 9.1 and earlier, Resv messages that include the S2L_SUB_LSP object are rejected by default. In Junos OS Release 9.2 and later, such messages are accepted by default. To ensure proper functioning of point-to-multipoint LSPs in a network that includes both devices running Junos OS Release 9.1 and earlier and devices running Junos 9.2 and later, you must include the no-p2mp-sublsp statement in the configuration of the devices running Junos 9.2 and later:

You can include this statement at the following hierarchy levels:

• [edit protocols rsvp]

• [edit logical-systems logical-system-name protocols rsvp]

This section talks about the benefits and overview of controlling the re-merge behavior on RSVP Point-to-Multipoint (P2MP) LSPs.

• Benefits of Controlling the P2MP LSP Re-merge
• What is P2MP LSP Re-merge?
• Modify the Default P2MP LSP Re-merge Behavior

What is P2MP LSP Re-merge?

In a P2MP MPLS LSP network, the term re-merge refers to the case of an ingress (headend) or transit node (re-merge node) that creates a re-merge branch intersecting the P2MP LSP at another node down the tree. This may occur due to events such as an error in path calculation, an error in manual configuration, or network topology changes during the establishment of the P2MP LSP.

RFC 4875 defines the following two approaches for handling the P2MP LSP re-merge:

• First, the node detecting the re-merge allows the re-merge case to persist, but data from all but one incoming interface is dropped at the re-merge node. This works by default without any configuration.

• Second, the re-merge node initiates the pruning of the re-merge sub LSPs through signaling.

On Juniper Networks MX Series routers, the first approach (as defined by RFC 4875) works by default. The second approach can be implemented by one of the following CLI configuration statements depending upon where the Juniper Networks MX Series routers are placed (ingress node or transit node) in the P2MP RSVP MPLS network:

• no-re-merge—This CLI configuration statement when enabled at the ingress (headend) router avoids the path computation of P2MP sub LSPs which creates a re-merge condition. When this CLI configuration statement is configured at the ingress, then configuring the no-p2mp-re-merge CLI configuration statement at the transit router is not required.

• no-p2mp-re-merge—This CLI configuration statement when enabled at the transit router changes the default behavior of allowing the P2MP sub LSP sessions re-merge to rejecting the re-merge. This CLI configuration statement is primarily required when the ingress (headend router) is not a Juniper Networks MX Series router.

• single-abr—This command when enabled reduces re-merge condition beyond the inter-area, or inter-domain, or inter-AS RSVP P2MP LSPs.

The following topology explains the re-merge behavior in a P2MP LSP network:

In this topology, R1 acts as an ingress (headend) router and R2 as the transit (re-merge node) router. There are two sub LSP sessions created in this network, LSP 1 and LSP 2. LSP 1 is a session established among R1, R2, and R3 devices. LSP 2 is a session established between R1, R4, R2, R3, and R5 devices. By default, the transit router allows the re-merge to happen from both the sub LSPs and drops one of the sub LSP branch traffic at the re-merge node. You can control this re-merge behavior by enabling the no-re-merge CLI configuration statement at the ingress router, or the no-p2mp-re-merge CLI configuration statement at the transit router.

If you enable the no-re-merge CLI configuration statement at the ingress router (R1), only one of the two sub LSP sessions is established. For example, if LSP 1 (R1-R2-R3) session is established first, then the other sub LSP session (LSP 2) will not be established.

If you enable the no-p2mp-re-merge CLI configuration statement at the transit router (R2), the transit router rejects the re-merge of one of the sub LSPs and sends a path error message to the ingress router (R1) preventing the ingress router from creating the second P2MP LSP re-merge branch. You can use the show rsvp statistics CLI command to view the path error message.