Home  TechLibrary  Junos OS  MPLS Applications User Guide 

Point-to-Mul point LSP Configura on

 26-Mar-21  Product and Release Support ward 

Point-to-Mul point LSPs Overview

A point-to-mul point MPLS LSP is an LSP with a single source and mul ple des na ons. By taking
advantage of the MPLS packet replica on capability of the network, point-to-mul point LSPs avoid
unnecessary packet replica on at the ingress router. Packet replica on takes place only when
packets are forwarded to two or more different des na ons requiring different network paths.

This process is illustrated in Figure 1. Router PE1 is configured with a point-to-mul point LSP to
Routers PE2, PE3, and PE4. When Router PE1 sends a packet on the point-to-mul point 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 dra s dra -raggarwa-mpls-p2mp-te-02.txt (expired
February 2004), Establishing Point to Multipoint MPLS TE LSPs, dra -ie -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-mul point
LSPs are supported).

Figure 1: Point-to-Mul point LSPs

The following are some of the proper es of point-to-mul point LSPs:

A point-to-mul point LSP enables you to use MPLS for point-to-mul point data distribu on.
This func onality is similar to that provided by IP mul cast.

You can add and remove branch LSPs from a main point-to-mul point LSP without disrup ng
traffic. The unaffected parts of the point-to-mul point LSP con nue to func on normally.

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

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

You can configure branch LSPs either sta cally, dynamically, or as a combina on of sta c and
dynamic LSPs.

You can enable graceful Routing Engine switchover (GRES) and graceful restart for point-to-
mul point LSPs at ingress and egress routers. The point-to-mul point LSPs must be configured
using either sta c 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-mul point LSPs
on the Junos Trio chipset is supported in Junos OS Releases 11.1R2, 11.2R2, and 11.4.

Understanding Point-to-Mul point LSPs

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

This process is illustrated in Figure 2. Device PE1 is configured with a point-to-mul point LSP to
Routers PE2, PE3, and PE4. When Device PE1 sends a packet on the point-to-mul point 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-Mul point LSPs

Following are some of the proper es of point-to-mul point LSPs:

A point-to-mul point LSP allows you to use MPLS for point-to-mul point data distribu on. This
func onality is similar to that provided by IP mul cast.

You can add and remove branch LSPs from a main point-to-mul point LSP without disrup ng
traffic. The unaffected parts of the point-to-mul point LSP con nue to func on 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-mul point LSP.

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

You can configure subpaths either sta cally or dynamically.

You can enable graceful restart on point-to-mul point LSPs.

Point-to-Mul point LSP Configura on Overview

To set up a point-to-mul point LSP:

1. Configure the primary LSP from the ingress router and the branch LSPs that carry traffic to the
egress routers.

2. Specify a pathname on the primary LSP and this same path name on each branch LSP.

NOTE: By default, the branch LSPs are dynamically signaled by means of Constrained
Shortest Path First (CSPF) and require no configura on. You can alterna vely configure the
branch LSPs as sta c paths.

Example: Configuring a Collec on of Paths to Create an RSVP-

Signaled Point-to-Mul point LSP
This example shows how to configure a collec on of paths to create an RSVP-signaled point-to-
mul point label-switched path (LSP).

Requirements

Overview

Configura on
 Verifica on

Requirements
In this example, no special configura on beyond device ini aliza on is required.

Overview
In this example, mul ple rou ng devices serve as the transit, branch, and leaf nodes of a single point-
to-mul point LSP. On the provider edge (PE), Device PE1 is the ingress node. The branches go from
PE1 to PE2, PE1 to PE3, and PE1 to PE4. Sta c unicast routes on the ingress node (PE1) point to the
egress nodes.

This example also demonstrates sta c routes with a next hop that is a point-to-mul point LSP, using
the p2mp-lsp-next-hop statement. This is useful when implemen ng filter-based forwarding.

NOTE: Another op on is to use the lsp-next-hop statement to configure a regular

point-to-point LSP to be the next hop. Though not shown in this example, you can op onally
assign an independent preference and metric to the next hop.

Topology Diagram
Figure 3 shows the topology used in this example.

Figure 3: RSVP-Signaled Point-to-Mul point LSP

Configura on

CLI Quick Configura on

Configuring the Ingress Label-Switched Router (LSR) (Device PE1)

Configuring the Transit and Egress LSRs (Devices P2, P3, P4, PE2, PE3, and PE4)

Configuring Device CE1

Configuring Device CE2

Configuring Device CE3

Configuring Device CE4

CLI Quick Configura on

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 configura on, and then copy
and paste the commands into the CLI at the [edit] hierarchy level.

Device PE1
  

set interfaces ge-2/0/2 unit 0 description PE1-to-CE1

set interfaces ge-2/0/2 unit 0 family inet address 10.0.244.10/30
set interfaces fe-2/0/10 unit 1 description PE1-to-P2
set interfaces fe-2/0/10 unit 1 family inet address 2.2.2.1/24
set interfaces fe-2/0/10 unit 1 family mpls
set interfaces fe-2/0/9 unit 8 description PE1-to-P3
set interfaces fe-2/0/9 unit 8 family inet address 6.6.6.1/24
set interfaces fe-2/0/9 unit 8 family mpls
set interfaces fe-2/0/8 unit 9 description PE1-to-P4
set interfaces fe-2/0/8 unit 9 family inet address 3.3.3.1/24
set interfaces fe-2/0/8 unit 9 family mpls
set interfaces lo0 unit 1 family inet address 100.10.10.10/32
set protocols rsvp interface fe-2/0/10.1
set protocols rsvp interface fe-2/0/9.8
set protocols rsvp interface fe-2/0/8.9
set protocols rsvp interface lo0.1
set protocols mpls traffic-engineering bgp-igp
set protocols mpls label-switched-path PE1-PE2 to 100.50.50.50
set protocols mpls label-switched-path PE1-PE2 link-protection
set protocols mpls label-switched-path PE1-PE2 p2mp p2mp1
set protocols mpls label-switched-path PE1-PE3 to 100.70.70.70
set protocols mpls label-switched-path PE1-PE3 link-protection
set protocols mpls label-switched-path PE1-PE3 p2mp p2mp1
set protocols mpls label-switched-path PE1-PE4 to 100.40.40.40
set protocols mpls label-switched-path PE1-PE4 link-protection
set protocols mpls label-switched-path PE1-PE4 p2mp p2mp1
set protocols mpls interface fe-2/0/10.1
set protocols mpls interface fe-2/0/9.8
set protocols mpls interface fe-2/0/8.9
set protocols mpls interface lo0.1
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface ge-2/0/2.0
set protocols ospf area 0.0.0.0 interface fe-2/0/10.1
set protocols ospf area 0.0.0.0 interface fe-2/0/9.8
set protocols ospf area 0.0.0.0 interface fe-2/0/8.9
set protocols ospf area 0.0.0.0 interface lo0.1
set routing-options static route 5.5.5.0/24 p2mp-lsp-next-hop p2mp1
set routing-options static route 7.7.7.0/24 p2mp-lsp-next-hop p2mp1
set routing-options static route 4.4.4.0/24 p2mp-lsp-next-hop p2mp1
set routing-options router-id 100.10.10.10
Device CE1

 

set interfaces ge-1/3/2 unit 0 family inet address 10.0.244.9/30

set interfaces ge-1/3/2 unit 0 description CE1-to-PE1
set routing-options static route 10.0.104.8/30 next-hop 10.0.244.10
set routing-options static route 10.0.134.8/30 next-hop 10.0.244.10
set routing-options static route 10.0.224.8/30 next-hop 10.0.244.10

Device CE2

 

set interfaces ge-1/3/3 unit 0 family inet address 10.0.224.9/30

set interfaces ge-1/3/3 unit 0 description CE2-to-PE2
set routing-options static route 10.0.244.8/30 next-hop 10.0.224.10

Device CE3

 

set interfaces ge-2/0/1 unit 0 family inet address 10.0.134.9/30

set interfaces ge-2/0/1 unit 0 description CE3-to-PE3
set routing-options static route 10.0.244.8/30 next-hop 10.0.134.10

Device CE4

 

set interfaces ge-3/1/3 unit 0 family inet address 10.0.104.10/30

set interfaces ge-3/1/3 unit 0 description CE4-to-PE4
set routing-options static route 10.0.244.8/30 next-hop 10.0.104.9

Configuring the Ingress Label-Switched Router (LSR) (Device PE1)

Step-by-Step Procedure
To configure Device PE1:

1. Configure the interfaces, interface encapsula on, and protocol families.

 

[edit interfaces]
user@PE1# set ge-2/0/2 unit 0 description PE1-to-CE1
user@PE1# set ge-2/0/2 unit 0 family inet address 10.0.244.10/30
user@PE1# set fe-2/0/10 unit 1 description PE1-to-P2
user@PE1# set fe-2/0/10 unit 1 family inet address 2.2.2.1/24
user@PE1# set fe-2/0/10 unit 1 family mpls
user@PE1# set fe-2/0/9 unit 8 description PE1-to-P3
user@PE1# set fe-2/0/9 unit 8 family inet address 6.6.6.1/24
user@PE1# set fe-2/0/9 unit 8 family mpls
user@PE1# set fe-2/0/8 unit 9 description PE1-to-P4
user@PE1# set fe-2/0/8 unit 9 family inet address 3.3.3.1/24
user@PE1# set fe-2/0/8 unit 9 family mpls
user@PE1# set lo0 unit 1 family inet address 100.10.10.10/32

2. Enable RSVP, MPLS, and OSPF on the interfaces.

 

[edit protocols]
user@PE1# set rsvp interface fe-2/0/10.1
user@PE1# set rsvp interface fe-2/0/9.8
user@PE1# set rsvp interface fe-2/0/8.9
user@PE1# set rsvp interface lo0.1
user@PE1# set mpls interface fe-2/0/10.1
user@PE1# set mpls interface fe-2/0/9.8
user@PE1# set mpls interface fe-2/0/8.9
user@PE1# set mpls interface lo0.1
user@PE1# set ospf area 0.0.0.0 interface ge-2/0/2.0
user@PE1# set ospf area 0.0.0.0 interface fe-2/0/10.1
user@PE1# set ospf area 0.0.0.0 interface fe-2/0/9.8
user@PE1# set ospf area 0.0.0.0 interface fe-2/0/8.9
user@PE1# set ospf area 0.0.0.0 interface lo0.1

3. Configure the MPLS point-to-mul point LSPs.

  

[edit protocols]
user@PE1# set mpls label-switched-path PE1-PE2 to 100.50.50.50
user@PE1# set mpls label-switched-path PE1-PE2 p2mp p2mp1
user@PE1# set mpls label-switched-path PE1-PE3 to 100.70.70.70
user@PE1# set mpls label-switched-path PE1-PE3 p2mp p2mp1
user@PE1# set mpls label-switched-path PE1-PE4 to 100.40.40.40
user@PE1# set mpls label-switched-path PE1-PE4 p2mp p2mp1

4. (Op onal) Enable link protec on on the LSPs.

Link protec on helps to ensure that traffic sent over a specific interface to a neighboring router
can con nue to reach the router if that interface fails.

 

[edit protocols]
user@PE1# set mpls label-switched-path PE1-PE2 link-protection
user@PE1# set mpls label-switched-path PE1-PE3 link-protection
user@PE1# set mpls label-switched-path PE1-PE4 link-protection

5. Enable MPLS to perform traffic engineering for OSPF.

 

[edit protocols]
user@PE1# set mpls traffic-engineering bgp-igp

This causes the ingress routes to be installed in the inet.0 rou ng table. By default, MPLS
performs traffic engineering for BGP only. You need to enable MPLS traffic engineering on the
ingress LSR only.

6. Enable traffic engineering for OSPF.

 

[edit protocols]
user@PE1# set ospf traffic-engineering
 This causes the shortest-path first (SPF) algorithm to take into account the LSPs configured
under MPLS.

7. Configure the router ID.

 

[edit routing-options]
user@PE1# set router-id 100.10.10.10

8. Configure sta c IP unicast routes with the point-to-mul point LSP name as the next hop for each
route.

 

[edit routing-options]
user@PE1# set static route 5.5.5.0/24p2mp-lsp-next-hop p2mp1
user@PE1# set static route 7.7.7.0/24 p2mp-lsp-next-hop p2mp1
user@PE1# set static route 4.4.4.0/24 p2mp-lsp-next-hop p2mp1

9. If you are done configuring the device, commit the configura on.

 

[edit]
user@PE1# commit

Configuring the Transit and Egress LSRs (Devices P2, P3, P4, PE2, PE3, and PE4)

Step-by-Step Procedure

Results

Step-by-Step Procedure
To configure the transit and egress LSRs:

1. Configure the interfaces, interface encapsula on, and protocol families.

  

[edit]
user@P2# set interfaces fe-2/0/10 unit 2 description P2-to-PE1
user@P2# set interfaces fe-2/0/10 unit 2 family inet address 2.2.2.2/24
user@P2# set interfaces fe-2/0/10 unit 2 family mpls
user@P2# set interfaces fe-2/0/9 unit 10 description P2-to-PE2
user@P2# set interfaces fe-2/0/9 unit 10 family inet address 5.5.5.1/24
user@P2# set interfaces fe-2/0/9 unit 10 family mpls
user@P2# set interfaces lo0 unit 2 family inet address 100.20.20.20/32
user@PE2# set interfaces ge-2/0/3 unit 0 description PE2-to-CE2
user@PE2# set interfaces ge-2/0/3 unit 0 family inet address 10.0.224.10/30
user@PE2# set interfaces fe-2/0/10 unit 5 description PE2-to-P2
user@PE2# set interfaces fe-2/0/10 unit 5 family inet address 5.5.5.2/24
user@PE2# set interfaces fe-2/0/10 unit 5 family mpls
user@PE2# set interfaces lo0 unit 5 family inet address 100.50.50.50/32
user@P3# set interfaces fe-2/0/10 unit 6 description P3-to-PE1
user@P3# set interfaces fe-2/0/10 unit 6 family inet address 6.6.6.2/24
user@P3# set interfaces fe-2/0/10 unit 6 family mpls
user@P3# set interfaces fe-2/0/9 unit 11 description P3-to-PE3
user@P3# set interfaces fe-2/0/9 unit 11 family inet address 7.7.7.1/24
user@P3# set interfaces fe-2/0/9 unit 11 family mpls
user@P3# set interfaces lo0 unit 6 family inet address 100.60.60.60/32
user@PE3# set interfaces ge-2/0/1 unit 0 description PE3-to-CE3
user@PE3# set interfaces ge-2/0/1 unit 0 family inet address 10.0.134.10/30
user@PE3# set interfaces fe-2/0/10 unit 7 description PE3-to-P3
user@PE3# set interfaces fe-2/0/10 unit 7 family inet address 7.7.7.2/24
user@PE3# set interfaces fe-2/0/10 unit 7 family mpls
user@PE3# set interfaces lo0 unit 7 family inet address 100.70.70.70/32
user@P4# set interfaces fe-2/0/10 unit 3 description P4-to-PE1
user@P4# set interfaces fe-2/0/10 unit 3 family inet address 3.3.3.2/24
user@P4# set interfaces fe-2/0/10 unit 3 family mpls
user@P4# set interfaces fe-2/0/9 unit 12 description P4-to-PE4
user@P4# set interfaces fe-2/0/9 unit 12 family inet address 4.4.4.1/24
user@P4# set interfaces fe-2/0/9 unit 12 family mpls
user@P4# set interfaces lo0 unit 3 family inet address 100.30.30.30/32
user@PE4# set interfaces ge-2/0/0 unit 0 description PE4-to-CE4
user@PE4# set interfaces ge-2/0/0 unit 0 family inet address 10.0.104.9/30
user@PE4# set interfaces fe-2/0/10 unit 4 description PE4-to-P4
user@PE4# set interfaces fe-2/0/10 unit 4 family inet address 4.4.4.2/24
user@PE4# set interfaces fe-2/0/10 unit 4 family mpls
user@PE4# set interfaces lo0 unit 4 family inet address 100.40.40.40/32
2. Enable RSVP, MPLS, and OSPF on the interfaces.

 

[edit]
user@P2# set protocols rsvp interface fe-2/0/10.2
user@P2# set protocols rsvp interface fe-2/0/9.10
user@P2# set protocols rsvp interface lo0.2
user@P2# set protocols mpls interface fe-2/0/10.2
user@P2# set protocols mpls interface fe-2/0/9.10
user@P2# set protocols mpls interface lo0.2
user@P2# set protocols ospf area 0.0.0.0 interface fe-2/0/10.2
user@P2# set protocols ospf area 0.0.0.0 interface fe-2/0/9.10
user@P2# set protocols ospf area 0.0.0.0 interface lo0.2
user@PE2# set protocols rsvp interface fe-2/0/10.5
user@PE2# set protocols rsvp interface lo0.5
user@PE2# set protocols mpls interface fe-2/0/10.5
user@PE2# set protocols mpls interface lo0.5
user@PE2# set protocols ospf area 0.0.0.0 interface ge-2/0/3.0
user@PE2# set protocols ospf area 0.0.0.0 interface fe-2/0/10.5
user@PE2# set protocols ospf area 0.0.0.0 interface lo0.5
user@P3# set protocols rsvp interface fe-2/0/10.6
user@P3# set protocols rsvp interface fe-2/0/9.11
user@P3# set protocols rsvp interface lo0.6
user@P3# set protocols mpls interface fe-2/0/10.6
user@P3# set protocols mpls interface fe-2/0/9.11
user@P3# set protocols mpls interface lo0.6
user@P3# set protocols ospf area 0.0.0.0 interface fe-2/0/10.6
user@P3# set protocols ospf area 0.0.0.0 interface fe-2/0/9.11
user@P3# set protocols ospf area 0.0.0.0 interface lo0.6
user@PE3# set protocols rsvp interface fe-2/0/10.7
user@PE3# set protocols rsvp interface lo0.7
user@PE3# set protocols mpls interface fe-2/0/10.7
user@PE3# set protocols mpls interface lo0.7
user@PE3# set protocols ospf area 0.0.0.0 interface ge-2/0/1.0
user@PE3# set protocols ospf area 0.0.0.0 interface fe-2/0/10.7
user@PE3# set protocols ospf area 0.0.0.0 interface lo0.7
user@P4# set protocols rsvp interface fe-2/0/10.3
user@P4# set protocols rsvp interface fe-2/0/9.12
user@P4# set protocols rsvp interface lo0.3
user@P4# set protocols mpls interface fe-2/0/10.3
user@P4# set protocols mpls interface fe-2/0/9.12
user@P4# set protocols mpls interface lo0.3
 user@P4# set protocols ospf area 0.0.0.0 interface fe-2/0/10.3
user@P4# set protocols ospf area 0.0.0.0 interface fe-2/0/9.12
user@P4# set protocols ospf area 0.0.0.0 interface lo0.3
user@PE4# set protocols rsvp interface fe-2/0/10.4
user@PE4# set protocols rsvp interface lo0.4
user@PE4# set protocols mpls interface fe-2/0/10.4
user@PE4# set protocols mpls interface lo0.4
user@PE4# set protocols ospf area 0.0.0.0 interface ge-2/0/0.0
user@PE4# set protocols ospf area 0.0.0.0 interface fe-2/0/10.4
user@PE4# set protocols ospf area 0.0.0.0 interface lo0.4

3. Enable traffic engineering for OSPF.

 

[edit]
user@P2# set protocols ospf traffic-engineering
user@P3# set protocols ospf traffic-engineering
user@P4# set protocols ospf traffic-engineering
user@PE2# set protocols ospf traffic-engineering
user@PE3# set protocols ospf traffic-engineering
user@PE4# set protocols ospf traffic-engineering

This causes the shortest-path first (SPF) algorithm to take into account the LSPs configured
under MPLS.

4. Configure the router IDs.

 

[edit]
user@P2# set routing-options router-id 100.20.20.20
user@P3# set routing-options router-id 100.60.60.60
user@P4# set routing-options router-id 100.30.30.30
user@PE2# set routing-options router-id 100.50.50.50
user@PE3# set routing-options router-id 100.70.70.70
user@PE4# set routing-options router-id 100.40.40.40

5. If you are done configuring the devices, commit the configura on.
  

[edit]
user@host# commit

Results
From configura on mode, confirm your configura on by entering the show interfaces, show
protocols, and show routing-options commands. If the output does not display the intended
configura on, repeat the instruc ons in this example to correct the configura on.

Device PE1

 

user@PE1# show interfaces

ge-2/0/2 {
unit 0 {
description R1-to-CE1;
family inet {
address 10.0.244.10/30;
}
}
}
fe-2/0/10 {
unit 1 {
description PE1-to-P2;
family inet {
address 2.2.2.1/24;
}
family mpls;
}
}
fe-2/0/9 {
unit 8 {
description PE1-to-P2;
family inet {
address 6.6.6.1/24;
}
family mpls;
}
}
fe-2/0/8 {
unit 9 {
description PE1-to-P3;
family inet {
address 3.3.3.1/24;
}
family mpls;
}
}
lo0 {
unit 1 {
family inet {
address 100.10.10.10/32;
}
}
}

 

user@PE1# show protocols

rsvp {
interface fe-2/0/10.1;
interface fe-2/0/9.8;
interface fe-2/0/8.9;
interface lo0.1;
}
mpls {
traffic-engineering bgp-igp;
label-switched-path PE1-to-PE2 {
to 100.50.50.50;
link-protection;
p2mp p2mp1;
}
label-switched-path PE1-to-PE3 {
to 100.70.70.70;
link-protection;
p2mp p2mp1;
}
label-switched-path PE1-to-PE4 {
to 100.40.40.40;
link-protection;
 p2mp p2mp1;
}
interface fe-2/0/10.1;
interface fe-2/0/9.8;
interface fe-2/0/8.9;
interface lo0.1;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface ge-2/0/2.0;
interface fe-2/0/10.1;
interface fe-2/0/9.8;
interface fe-2/0/8.9;
interface lo0.1;
}
}

 

user@PE1# show routing-options

static {
route 5.5.5.0/24 {
p2mp-lsp-next-hop p2mp1;
}
route 7.7.7.0/24 {
p2mp-lsp-next-hop p2mp1;
}
route 4.4.4.0/24 {
p2mp-lsp-next-hop p2mp1;
}
}
router-id 100.10.10.10;

Device P2

 

user@P2# show interfaces

fe-2/0/10 {
unit 2 {
 description P2-to-PE1;
family inet {
address 2.2.2.2/24;
}
family mpls;
}
fe-2/0/9 {
unit 10 {
description P2-to-PE2;
family inet {
address 5.5.5.1/24;
}
family mpls;
}
}
lo0 {
unit 2 {
family inet {
address 100.20.20.20/32;
}
}
}

 

user@P2# show protocols

rsvp {
interface fe-2/0/10.2;
interface fe-2/0/9.10;
interface lo0.2;
}
mpls {
interface fe-2/0/10.2;
interface fe-2/0/9.10;
interface lo0.2;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fe-2/0/10.2;
interface fe-2/0/9.10;
interface lo0.2;
 }
}

 

user@P2# show routing-options

router-id 100.20.20.20;

Device P3

 

user@P3# show interfaces

fe-2/0/10 {
unit 6 {
description P3-to-PE1;
family inet {
address 6.6.6.2/24;
}
family mpls;
}
}
fe-2/0/9 {
unit 11 {
description P3-to-PE3;
family inet {
address 7.7.7.1/24;
}
family mpls;
}
}
lo0 {
unit 6 {
family inet {
address 100.60.60.60/32;
}
}
}
  

user@P3# show protocols

rsvp {
interface fe-2/0/10.6;
interface fe-2/0/9.11;
interface lo0.6;
}
mpls {
interface fe-2/0/10.6;
interface fe-2/0/9.11;
interface lo0.6;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fe-2/0/10.6;
interface fe-2/0/9.11;
interface lo0.6;
}
}

 

user@P2# show routing-options

router-id 100.60.60.60;

Device P4

 

user@P4# show interfaces

fe-2/0/10 {
unit 3 {
description P4-to-PE1;
family inet {
address 3.3.3.2/24;
}
family mpls;
}
}
fe-2/0/9 {
unit 12 {
description P4-to-PE4;
family inet {
address 4.4.4.1/24;
}
family mpls;
}
}
lo0 {
unit 3 {
family inet {
address 100.30.30.30/32;
}
}
}

 

user@P4# show protocols

rsvp {
interface fe-2/0/10.3;
interface fe-2/0/9.12;
interface lo0.3;
}
mpls {
interface fe-2/0/10.3;
interface fe-2/0/9.12;
interface lo0.3;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fe-2/0/10.3;
interface fe-2/0/9.12;
interface lo0.3;
}
}

 
 user@P3# show routing-options
router-id 100.30.30.30;

Device PE2

 

user@PE2# show interfaces

ge-2/0/3 {
unit 0 {
description PE2-to-CE2;
family inet {
address 10.0.224.10/30;
}
}
}
fe-2/0/10 {
unit 5 {
description PE2-to-P2;
family inet {
address 5.5.5.2/24;
}
family mpls;
}
}
lo0 {
unit 5 {
family inet {
address 100.50.50.50/32;
}
}
}
}

 

user@PE2# show protocols

rsvp {
interface fe-2/0/10.5;
interface lo0.5;
 }
mpls {
interface fe-2/0/10.5;
interface lo0.5;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface ge-2/0/3.0;
interface fe-2/0/10.5;
interface lo0.5;
}
}

 

user@PE2# show routing-options

router-id 100.50.50.50;

Device PE3

 

user@PE3# show interfaces

ge-2/0/1 {
unit 0 {
description PE3-to-CE3;
family inet {
address 10.0.134.10/30;
}
}
}
fe-2/0/10 {
unit 7 {
description PE3-to-P3;
family inet {
address 7.7.7.2/24;
}
family mpls;
}
}
 lo0 {
unit 7 {
family inet {
address 100.70.70.70/32;
}
}
}
}

 

user@PE3# show protocols

rsvp {
interface fe-2/0/10.7;
interface lo0.7;
}
mpls {
interface fe-2/0/10.7;
interface lo0.7;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface ge-2/0/1.0;
interface fe-2/0/10.7;
interface lo0.7;
}
}

 

user@PE3# show routing-options

router-id 100.70.70.70;

Device PE4

 
user@PE4# show interfaces
ge-2/0/0 {
unit 0 {
description PE4-to-CE4;
family inet {
address 10.0.104.9/30;
}
}
}
fe-2/0/10 {
unit 4 {
description PE4-to-P4;
family inet {
address 4.4.4.2/24;
}
family mpls;
}
}
lo0 {
unit 4 {
family inet {
address 100.40.40.40/32;
}
}
}
}

 

user@PE4# show protocols

rsvp {
interface fe-2/0/10.4;
interface lo0.4;
}
mpls {
interface fe-2/0/10.4;
interface lo0.4;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface ge-2/0/0.0;
 interface fe-2/0/10.4;
interface lo0.4;
}
}

 

user@PE4# show routing-options

router-id 100.40.40.40;

Configuring Device CE1

Step-by-Step Procedure

Results

Step-by-Step Procedure
To configure Device CE1:

1. Configure an interface to Device PE1.

 

[edit interfaces]
user@CE1# set ge-1/3/2 unit 0 family inet address 10.0.244.9/30
user@CE1# set ge-1/3/2 unit 0 description CE1-to-PE1

2. Configure sta c routes from Device CE1 to the three other customer networks, with Device PE1
as the next hop.

 

[edit routing-options]
user@CE1# set static route 10.0.104.8/30 next-hop 10.0.244.10
user@CE1# set static route 10.0.134.8/30 next-hop 10.0.244.10
user@CE1# set static route 10.0.224.8/30 next-hop 10.0.244.10
 3. If you are done configuring the device, commit the configura on.

 

[edit]
user@CE1# commit

Results
From configura on mode, confirm your configura on by entering the show interfaces and show
routing-options commands. If the output does not display the intended configura on, repeat
the instruc ons in this example to correct the configura on.

 

user@CE1# show interfaces

ge-1/3/2 {
unit 0 {
family inet {
address 10.0.244.9/30;
description CE1-to-PE1;
}
}
}

 

user@CE1# show routing-options

static {
route 10.0.104.8/30 next-hop 10.0.244.10;
route 10.0.134.8/30 next-hop 10.0.244.10;
route 10.0.224.8/30 next-hop 10.0.244.10;
}

Configuring Device CE2

Step-by-Step Procedure

Results
Step-by-Step Procedure
To configure Device CE2:

1. Configure an interface to Device PE2.

 

[edit interfaces]
user@CE2# set ge-1/3/3 unit 0 family inet address 10.0.224.9/30
user@CE2# set ge-1/3/3 unit 0 description CE2-to-PE2

2. Configure a sta c route from Device CE2 to CE1, with Device PE2 as the next hop.

 

[edit routing-options]
user@CE2# set static route 10.0.244.8/30 next-hop 10.0.224.10

3. If you are done configuring the device, commit the configura on.

 

[edit]
user@CE2# commit

Results
From configura on mode, confirm your configura on by entering the show interfaces and show
routing-options commands. If the output does not display the intended configura on, repeat
the instruc ons in this example to correct the configura on.

 

user@CE2# show interfaces

ge-1/3/3 {
unit 0 {
 family inet {
address 10.0.224.9/30;
description CE2-to-PE2;
}
}
}

 

user@CE2# show routing-options

static {
route 10.0.244.8/30 next-hop 10.0.224.10;
}

Configuring Device CE3

Step-by-Step Procedure

Results

Step-by-Step Procedure
To configure Device CE3:

1. Configure an interface to Device PE3.

 

[edit interfaces]
user@CE3# set ge-2/0/1 unit 0 family inet address 10.0.134.9/30
user@CE3# set ge-2/0/1 unit 0 description CE3-to-PE3

2. Configure a sta c route from Device CE3 to CE1, with Device PE3 as the next hop.

 

[edit routing-options]
user@CE3# set static route 10.0.244.8/30 next-hop 10.0.134.10
 3. If you are done configuring the device, commit the configura on.

 

[edit]
user@CE3# commit

Results
From configura on mode, confirm your configura on by entering the show interfaces and show
routing-options commands. If the output does not display the intended configura on, repeat
the instruc ons in this example to correct the configura on.

 

user@CE3# show interfaces

ge-2/0/1 {
unit 0 {
family inet {
address 10.0.134.9/30;
description CE3-to-PE3;
}
}
}

 

user@CE3# show routing-options

static {
route 10.0.244.8/30 next-hop 10.0.134.10;
}

Configuring Device CE4

Step-by-Step Procedure

Results
Step-by-Step Procedure
To configure Device CE4:

1. Configure an interface to Device PE4.

 

[edit interfaces]
user@CE4# set ge-3/1/3 unit 0 family inet address 10.0.104.10/30
user@CE4# set ge-3/1/3 unit 0 description CE4-to-PE4

2. Configure a sta c route from Device CE4 to CE1, with Device PE4 as the next hop.

 

[edit routing-options]
user@CE4# set static route 10.0.244.8/30 next-hop 10.0.104.9

3. If you are done configuring the device, commit the configura on.

 

[edit]
user@CE4# commit

Results
From configura on mode, confirm your configura on by entering the show interfaces and show
routing-options commands. If the output does not display the intended configura on, repeat
the instruc ons in this example to correct the configura on.

 

user@CE4# show interfaces

ge-3/1/3 {
unit 0 {
family inet {
 address 10.0.104.10/30;
description CE4-to-PE4;
}
}
}

 

user@CE4# show routing-options

static {
route 10.0.244.8/30 next-hop 10.0.104.9;
}

Verifica on
Confirm that the configura on is working properly.

Verifying Connec vity

Verifying the State of the Point-to-Mul point LSP

Checking the Forwarding Table

Verifying Connec vity

Purpose

Ac on

Purpose
Make sure that the devices can ping each other.

Ac on
Run the ping command from CE1 to the interface on CE2 connec ng to PE2.

 

user@CE1> ping 10.0.224.9

PING 10.0.224.9 (10.0.224.9): 56 data bytes
64 bytes from 10.0.224.9: icmp_seq=0 ttl=61 time=1.387 ms
 64 bytes from 10.0.224.9: icmp_seq=1 ttl=61 time=1.394 ms
64 bytes from 10.0.224.9: icmp_seq=2 ttl=61 time=1.506 ms
^C
--- 10.0.224.9 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.387/1.429/1.506/0.055 ms

Run the ping command from CE1 to the interface on CE3 connec ng to PE3.

 

user@CE1> ping 10.0.134.9

PING 10.0.134.9 (10.0.134.9): 56 data bytes
64 bytes from 10.0.134.9: icmp_seq=0 ttl=61 time=1.068 ms
64 bytes from 10.0.134.9: icmp_seq=1 ttl=61 time=1.062 ms
64 bytes from 10.0.134.9: icmp_seq=2 ttl=61 time=1.053 ms
^C
--- 10.0.134.9 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.053/1.061/1.068/0.006 ms

Run the ping command from CE1 to the interface on CE4 connec ng to PE4.

 

user@CE1> ping 10.0.104.10

PING 10.0.104.10 (10.0.104.10): 56 data bytes
64 bytes from 10.0.104.10: icmp_seq=0 ttl=61 time=1.079 ms
64 bytes from 10.0.104.10: icmp_seq=1 ttl=61 time=1.048 ms
64 bytes from 10.0.104.10: icmp_seq=2 ttl=61 time=1.070 ms
^C
--- 10.0.104.10 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.048/1.066/1.079/0.013 ms

Verifying the State of the Point-to-Mul point LSP

Purpose

Ac on
Purpose
Make sure that the ingress, transit, and egress LSRs are in the Up state.

Ac on
Run the show mpls lsp p2mp command on all of the LSRs. Only the ingress LSR is shown here.

 

user@PE1> show mpls lsp p2mp

Ingress LSP: 1 sessions
P2MP name: p2mp1, P2MP branch count: 3
To From State Rt P ActivePath LSPname
100.40.40.40 100.10.10.10 Up 0 * PE1-PE4
100.70.70.70 100.10.10.10 Up 0 * PE1-PE3
100.50.50.50 100.10.10.10 Up 0 * PE1-PE2
Total 3 displayed, Up 3, Down 0
...

Checking the Forwarding Table

Purpose

Ac on

Purpose
Make sure that the routes are set up as expected by running the show route forwarding-
table command. Only the routes to the remote customer networks are shown here.

Ac on

 

user@PE1> show route forwarding-table

Routing table: default.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
...
10.0.104.8/30 user 0 3.3.3.2 ucst 1006 6 fe-2/0/8.9
10.0.134.8/30 user 0 6.6.6.2 ucst 1010 6 fe-2/0/9.8
 10.0.224.8/30 user 0 2.2.2.2 ucst 1008 6 fe-2/0/10.1
...

Configuring Primary and Branch LSPs for Point-to-Mul point

LSPs
A point-to-mul point MPLS label-switched path (LSP) is an RSVP LSP with mul ple des na ons. By
taking advantage of the MPLS packet replica on capability of the network, point-to-mul point LSPs
avoid unnecessary packet replica on at the ingress router. For more informa on about point-to-
mul point LSPs, see Point-to-Mul point LSPs Overview.

To configure a point-to-mul point 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
sec ons:

Configuring the Primary Point-to-Mul point LSP

Configuring a Branch LSP for Point-to-Mul point LSPs

Configuring the Primary Point-to-Mul point LSP

A point-to-mul point LSP must have a configured primary point-to-mul point LSP to carry traffic
from the ingress router. The configura on of the primary point-to-mul point LSP is similar to a
signaled LSP. See Configuring the Ingress Router for MPLS-Signaled LSPs for more informa on. In
addi on to the conven onal LSP configura on, you need to specify a path name for the primary
point-to-mul point LSP by including the p2mp statement:

 

p2mp p2mp-lsp-name;

You can include this statement 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]
You can enable the op miza on mer for point-to-mul point LSPs. See Op mizing Signaled LSPs for
more informa on.

Configuring a Branch LSP for Point-to-Mul point LSPs

The primary point-to-mul point LSP sends traffic to two or more branch LSPs carrying traffic to each
of the egress provider edge (PE) routers. In the configura on for each of these branch LSPs, the
point-to-mul point LSP path name you specify must be iden cal to the path name configured for the
primary point-to-mul point LSP. See Configuring the Primary Point-to-Mul point LSP for more
informa on.

To associate a branch LSP with the primary point-to-mul point LSP, specify the point-to-mul point
LSP name by including the p2mp statement:

 

p2mp p2mp-lsp-name;

You can include this statement 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]

NOTE: Any change in any of the branch LSPs of a point-to-mul point LSP, either due
to a user ac on or an automa c adjustment made by the router, causes the primary and
branch LSPs to be resignaled. The new point-to-mul point LSP is signaled first before the
old path is taken down.

The following sec ons describe how you can configure the branch LSP as a dynamically signaled path
using Constrained Shortest Path First (CSPF), as a sta c path, or as a combina on of dynamic and
sta c paths:

Configuring the Branch LSP as a Dynamic Path

Configuring the Branch LSP as a Sta c Path

Configuring the Branch LSP as a Dynamic Path
By default, the branch LSP for a point-to-mul point LSP is signaled dynamically using CSPF and
requires no configura on.

When a point-to-mul point LSP is changed, either by the addi on or dele on of new des na ons or
by the recalcula on of the path to exis ng des na ons, certain nodes in the tree might receive data
from more than one incoming interface. This can happen under the following condi ons:

Some of the branch LSPs to des na ons are sta cally configured and might intersect with
sta cally or dynamically calculated paths to other des na ons.

When a dynamically calculated path for a branch LSP results in a change of incoming interface
for one of the nodes in the network, the older path is not immediately torn down a er the new
one has been signaled. This ensures that any data in transit relying on the older path can reach its
des na on. However, network traffic can poten ally use either path to reach the des na on.

A faulty router at the ingress calculates the paths to two different branch des na ons such that
a different incoming interface is chosen for these branch LSPs on a router node common to these
branch LSPs.

Configuring the Branch LSP as a Sta c Path

You can configure the branch LSP for a point-to-mul point LSP as a sta c path. See Configuring
Sta c LSPs for more informa on.

Configuring Inter-Domain Point-to-Mul point LSPs

An inter-domain P2MP LSP is a P2MP LSP that has one or more sub-LSPs (branches) that span
mul ple domains in a network. Examples of such domains include IGP areas and autonomous
systems (ASs). A sub-LSP of an inter-domain P2MP LSP may be intra-area, inter-area, or inter-AS,
depending on the loca on of the egress node (leaf) with respect to the ingress node (source).

On the ingress node, a name is assigned to the inter-domain P2MP LSP and shared by all cons tuent
sub-LSPs. Each sub-LSP is configured separately, with its own egress node and op onally an explicit
path. The loca on of the egress node of the sub-LSP with respect to the ingress node determines
whether the sub-LSP is intra-area, inter-area, or inter-AS.

Inter-domain P2MP LSPs can be used to transport traffic in the following applica ons in a mul -area
or mul -AS network:

Layer 2 broadcast and mul cast over MPLS

 Layer 3 BGP/MPLS VPN

VPLS

On each domain boundary node (ABR or ASBR) along the path of the P2MP LSP, the expand-
loose-hop statement must be configured at the [edit protocols mpls] hierarchy level so
that CSPF can extend a loose-hop ERO (usually the first entry of the ERO list carried by RSVP Path
message) towards the egress node or the next domain boundary node.

CSPF path computa on for inter-domain P2MP LSPs:

CSPF path computa on is supported on each sub-LSP for inter-domain P2MP LSPs. A sub-LSP
may be intra-area, inter-area, or inter-AS. CSPF treats an inter-area or inter-AS sub-LSP in the
same manner as an inter-domain P2P LSP.

On an ingress node or a domain boundary node (ABR or ASBR), CSPF can perform an Explicit
Route Object (ERO) expansion per-RSVP query. The des na on queried could be an egress node
or a received loose-hop ERO. If the des na on resides in a neighboring domain that the node is
connected to, CSPF generates either a sequence of strict-hop EROs towards it or a sequence of
strict-hop EROs towards another domain boundary node that can reach the des na on.

If RSVP fails to signal a path through a previously selected domain bounday node, RSVP a empts
to signal a path through other available domain boundary nodes in a round-robin fashion.

When a sub-LSP is added or removed to or from an inter-domain P2MP LSP, causing its path
(branch) to be merged or pruned with or from the current P2MP tree, the paths being taken by
the other sub-LSPs should not be affected, helping to prevent traffic disrup on on those sub-
LSPs.

Be aware of the following when deploying inter-domain P2MP LSPs in your network:

Periodic path re-op miza on is supported for inter-domain P2MP LSPs on ingress nodes. It can
be turned on for an inter-domain P2MP LSP by configuring the optimize-timer statement at
the [edit protocols mpls label-switched-path lsp-name] hierarchy level with the
same interval for every sub-LSP.

Only link protec on bypass LSPs are supported for inter-domain P2MP LSPs. To enable it for an
inter-domain P2MP LSP, link-protec on must be configured for all sub-LSPs and on all of the
RSVP interfaces that the P2MP LSP might travel through.

Only OSPF areas are supported for inter-domain P2MP LSPs. IS-IS levels are not supported.

Configuring Link Protec on for Point-to-Mul point LSPs

Link protec on helps to ensure that traffic going over a specific interface to a neighboring router can
con nue to reach this router if that interface fails. When link protec on is configured for an interface
and a point-to-mul point 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
des na on.

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

The Internet dra dra -ie -mpls-rsvp-te-p2mp-01.txt, Extensions to RSVP-TE for Point to
Multipoint TE LSPs, describes link protec on for point-to-mul point LSPs.

To enable link protec on on point-to-mul point LSPs, complete the following steps:

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

 

link-protection;

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 protec on for each RSVP interface on each router that the branch LSP traverses.
For informa on about how to configure link protec on on RSVP interfaces, see Configuring Link
Protec on on Interfaces Used by LSPs.

For more informa on on how to configure link protec on, see Configuring Node Protec on or Link
Protec on for LSPs.

Configuring Graceful Restart for Point-to-Mul point LSPs

You can configure graceful restart on point-to-mul point LSPs. Graceful restart allows a router
undergoing a restart to inform its adjacent neighbors of its condi on. The restar ng router requests a
grace period from the neighbor or peer, which can then cooperate with the restar ng router. The
restar ng router can s ll 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 restar ng 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-mul point LSP traffic, include the
graceful-restart statement:

 

graceful-restart;

You can include this statement at the following hierarchy levels:

[edit routing-options]

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

The graceful restart configura on for point-to-mul point LSPs is iden cal to that of point-to-point
LSPs. For more informa on on how to configure graceful restart, see Configuring RSVP Graceful
Restart.

Configuring a Mul cast RPF Check Policy for Point-to-Mul point

LSPs
You can control whether a reverse path forwarding (RPF) check is performed for a source and group
entry before installing a route in the mul cast forwarding cache. This makes it possible to use point-
to-mul point LSPs to distribute mul cast traffic to PIM islands situated downstream from the egress
routers of the point-to-mul point 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-
mul point LSP, because the interface receiving the mul cast traffic on a point-to-mul point LSP
egress router might not always be the RPF interface.

You can also configure a rou ng 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 ac on is
“acceptance.” An accept policy ac on enables RPF checks. A reject policy ac on (applied to all source
and group pairs that are not accepted) disables RPF checks for the pair.
To configure a mul cast RPF check policy for a point-to-mul point LSP, specify the RPF check policy
using the rpf-check-policy statement:

 

rpf-check-policy policy;

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 mul cast RPF check. You configure policies at the [edit
policy-options] hierarchy level. For more informa on, see the Rou ng Policies, Firewall Filters,
and Traffic Policers User Guide.

NOTE: When you configure the rpf-check-policy statement, the Junos OS cannot
perform RPF checks on incoming traffic and therefore cannot detect traffic arriving on the
wrong interface. This might cause rou ng loops to form.

Example: Configuring Mul cast RPF Check Policy for a Point-to-Mul point LSP
Configure a policy to ensure that an RPF check is not performed for sources with prefix 128.83/16
or longer that belong to groups having a prefix of 228/8 or longer:

 

[edit]
policy-options {
policy-statement rpf-sg-policy {
from {
route-filter 228.0.0.0/8 orlonger;
source-address-filter 128.83.0.0/16 orlonger;
}
then {
reject;
}
}
}
 Configuring Ingress PE Router Redundancy for Point-to-
Mul point LSPs
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 informa on.

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

 

backup-pe-group pe-group-name {
backups [addresses];
local-address address;
}

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

A er you configure the ingress PE router redundancy backup group, you must also apply the group
to a sta c route on the PE router. This ensures that the sta c route is ac ve (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 sta c route that also has the p2mp-lsp-next-
hop statement configured. For more informa on, see Configuring Sta c Unicast Routes for Point-to-
Mul point LSPs.

Enabling Point-to-Point LSPs to Monitor Egress PE Routers

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 mul ple 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 des na on PE router is down. The associate-backup-pe-groups statement is not ed
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:

 

associate-backup-pe-groups;

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 informa on 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 mul ple LSPs with the associate-backup-pe-groups statement to the same
des na on PE router, the first LSP configured is used to monitor the forwarding state to that PE
router. If you configure mul ple LSPs to the same des na on, make sure to configure similar
parameters for the LSPs. With this configura on scenario, a failure no fica on might be triggered
even though the remote PE router is s ll up.

Preserving Point-to-Mul point LSP Func oning with Different

Junos OS Releases
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 func oning of point-to-mul point 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 configura on of the devices running Junos 9.2 and later:
  

no-p2mp-sublsp;

You can include this statement at the following hierarchy levels:

[edit protocols rsvp]

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

Re-merge Behavior on Point-to-Mul point LSP Overview

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

Benefits of Controlling the P2MP LSP Re-merge

What is P2MP LSP Re-merge?

Modify the Default P2MP LSP Re-merge Behavior

Benefits of Controlling the P2MP LSP Re-merge

Reduces the RSVP signalling load on the ingress (headend routers) by avoiding path computa on
of sub LSPs which creates a re-merge condi on.

Saves the network bandwidth by rejec ng the P2MP sub LSP re-merge at the transit node.

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 intersec ng the P2MP LSP at another node
down the tree. This may occur due to events such as an error in path calcula on, an error in manual
configura on, 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 detec ng 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
configura on.

Second, the re-merge node ini ates 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 configura on
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 configura on statement when enabled at the ingress (headend) router
avoids the path computa on of P2MP sub LSPs which creates a re-merge condi on. When this
CLI configura on statement is configured at the ingress, then configuring the no-p2mp-re-
merge CLI configura on statement at the transit router is not required.

no-p2mp-re-merge—This CLI configura on statement when enabled at the transit router

changes the default behavior of allowing the P2MP sub LSP sessions re-merge to rejec ng the
re-merge. This CLI configura on 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 condi on 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 configura on statement at the ingress router, or the
no-p2mp-re-merge CLI configura on statement at the transit router.

If you enable the no-re-merge CLI configura on 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 configura on 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) preven ng the ingress router from crea ng the second P2MP LSP re-merge
branch. You can use the show rsvp statistics CLI command to view the path error message.

Modify the Default P2MP LSP Re-merge Behavior

You can modify the default re-merge behavior either at the ingress (headend) node, or at the transit
node in a P2MP RSVP MPLS network.

On the ingress (headend router), disable the default re-merge behavior so that the ingress router
does not do the path computa on of sub LSPs which creates the re-merge condi on. The default
behavior allows the path computa on of sub LSPs.

 

[edit protocols]
user@host#set mpls p2mp-lsp no-re-merge

On the transit router, disable the default re-merge behavior so that the transit router rejects the re-
merge of sub LSPs.

 

[edit protocols]
user@host#set rsvp no-p2mp-re-merge

For inter-area, or inter-domain, or inter-AS RSVP P2MP LSPs, use the single-abr CLI
configura on statement at the ingress (headend router) so that all the P2MP sub LSPs prefer to
select the same exit router (ABR or ASBR), thereby reducing the re-merge condi on.
  

[edit protocols]
user@host#set mpls p2mp-lsp single-abr

RELATED DOCUMENTATION

Basic MPLS Configura on

ward PREVIOUS NEXT 

Mul class LSP Configura on Pop-and-Forward LSP Configura on