Configuring LSPs Using LDP as the Signaling Protocol

Problem

You want to set up an LSP path through an IP network. Instead of setting up the path manually, you want to use LDP as the signaling protocol to establish and maintain the path.

Solution

For each LDP-signaled LSP, configure the ingress, transit, and egress routers on the path. On the ingress router, first configure the interface to support the MPLS address family:

	
	[edit interfaces]
	aviva@RouterG# set t1-4/0/0 unit 0 family mpls

Then enable the MPLS protocol on the interface:

	[edit protocols]
	aviva@RouterG# set mpls interface t1-4/0/0

Finally, turn on LDP as the signaling protocol:

	[edit protocols]
	aviva@RouterG# set ldp interface t1-4/0/0

On the transit and egress routers, turn on MPLS and LDP in a similar fashion. RouterF is the egress router:

	[edit interfaces]
	aviva@RouterF# set fe-0/0/1 unit 0 family mpls

	[edit protocols]
	aviva@RouterF# set mpls interface fe-0/0/1
	aviva@RouterF# set ldp interface fe-0/0/1

RouterJ is the transit router:

	[edit interfaces]
	aviva@RouterJ# set fe-1/0/1 unit 0 family mpls
	aviva@RouterJ# set t1-5/0/0 unit 0 family mpls

	[edit protocols]
	aviva@RouterJ# set mpls interface t1-5/0/0
	aviva@RouterJ# set mpls interface fe-1/0/1
	aviva@RouterJ# set ldp interface t1-5/0/0
	aviva@RouterJ# set ldp interface fe-1/0/1

Discussion

For MPLS to run on the routers in your network, you configure MPLS and a signaling protocol. This recipe uses LDP as the signaling protocol and the topology shown in Figure 14-5. Because LDP depends on an IGP when creating LSPs, interfaces running MPLS must also be running either IS-IS or OSPF.

Figure 14-5. MPLS with LDP topology

The first step in the configuration is to enable the MPLS address family on the logical interfaces of all the interfaces that are running MPLS. This family allows the interface to process labeled packets. On the ingress router, RouterG, add the MPLS family to the t1-4/0/0 interface; on the transit router, RouterJ, add it to the t1-5/0/0 and fe-1/0/1 interfaces; and on the egress router, RouterF, add it to the fe-0/0/1 interface. The interface configuration now has two families, IPv4 (inet) and MPLS:

	aviva@RouterG> show configuration interfaces
	t1-4/0/0 {
	 unit 0 {
	 family inet {
	 address 10.0.0.1/24;
	 }
	 family mpls;
	 }
	}
	lo0 {
	 unit 0 {
	 family inet {
	 address 192.168.19.1/32;
	 }
	 }
	}

The output shows the MPLS family on the t1-4/0/0 interface on the ingress router but not on the loopback interface. Because the loopback interface isn a transit interface and never carries labeled packets, you don need to configure it for the MPLS family.

Use the show interfaces terse command to verify that the MPLS family is configured on all expected interfaces. Heres the output for the transit router:

	aviva@RouterJ> show interfaces terse
	Interface Admin Link Proto Local Remote
	fe-0/0/0 up up
	fe-0/0/0.0 up up inet 172.19.121.117/24
	fe-1/0/1 up up
	 fe-1/0/1.0 up up inet 10.0.8.1/24
	 mpls
	t1-5/0/0 up up
	t1-5/0/0.0 up up inet 10.0.0.2/24
	 mpls
	lo0 up up
	lo0.0 up up inet 192.168.17.1 --> 0/0
	lo0.16385 up up inet 10.0.0.1 --> 0/0
	 10.0.0.16 --> 0/0

This output confirms that the two MPLS interfaces, fe-1/0/1 and t1-5/0/0, are configured with the MPLS family and have IPv4 addresses, and that the loopback interface, lo0.0, has only an IPv4 address and is not configured for the MPLS family.

Next, configure the router to run the MPLS protocol. The basic configuration is very simple. In the [edit protocols mpls] section of the configuration hierarchy, list the router interfaces on which MPLS will run. For the ingress router, configure MPLS on the interface that leads toward the far end of the LSP:

	[edit protocols]
	aviva@RouterG# set mpls interface t1-4/0/0

If you are configuring MPLS on all the routers interfaces, use the following shortcut:

	[edit protocols]
	aviva@RouterG# set mpls interface all

For M-series and T-series routers, its also considered good practice to disable MPLS on the fxp0 interface. This is true in particular for configurations where you configure MPLS on all interfaces instead of enabling it interface by interface.

	[edit protocols]
	aviva@router1# set mpls interface fxp0.0 disable

For J-series routers, you can disable MPLS on the equivalent interface, the fe-0/0/0 out-of-band interface:

	[edit protocols]
	aviva@routerJ# set mpls interface fe-0/0/0 disable

After configuring MPLS, confirm the configuration:

	aviva@RouterG> show mpls interface
	Interface State Administrative groups
	t1-4/0/0.0 Up 

The output shows that MPLS is up and running on interface t1-4/0/0 on the ingress router, RouterG. If you don see the interface, make sure that the MPLS address family is configured on the interface:

	aviva@RouterGshow interfaces terse t1-4/0/0
	Interface Admin Link Proto Local Remote
	t1-4/0/0 up up
	t1-4/0/0.0 up up inet 10.0.0.1/24

This output shows that the interface is configured for the IPv4 address, but not for the MPLS family. Use the set family mpls command to configure this family:

	[edit interfaces]
	aviva@RouterG# set t1-4/0/0 unit 0 family mpls
	aviva@RouterG# commit and-quit

Then verify the configuration:

	aviva@RouterG> show configuration interfaces t1-4/0/0
	unit 0 {
	 family inet {
	 address 10.0.0.1/24;
	 }
	 family mpls
	}

The show interfaces terse output now indicates that the interfaces recognize the MPLS family:

	aviva@RouterG> show interfaces terse t1-4/0/0
	Interface Admin Link Proto Local Remote
	t1-4/0/0 up up
	t1-4/0/0.0 up up inet 10.0.0.1/24
	 mpls

Also verify the MPLS-enabled interfaces on the other routers. The transit router has two, one each to the ingress and egress routers:

	aviva@RouterJ>  
show mpls interface
	Interface State Administrative groups
	t1-5/0/0.0 Up 
	fe-1/0/1.0 Up 

The egress router has one MPLS-enabled interface:

	aviva@RouterF> show mpls interface
	Interface State Administrative groups
	fe-0/0/1.0 Up 

If you misconfigure MPLS, either by forgetting to include the interface in the [edit protocols mpls] hierarchy or omitting the MPLS family from the interface, the show mpls interface output doesn list the interface. If MPLS and the interface are configured properly but the interface is not operational for some reason, the State column shows that the MPLS interface is down:

	aviva@RouterG> show mpls interface
	Interface State Administrative groups
	t1-4/0/0.0 Dn 

As the next configuration step, set up LDP as the signaling protocol. As with MPLS, just list all the router interfaces that will be running LDP. These are the same interfaces that run MPLS. Use the set ldp interface command to configure these interfaces in the [edit protocols] hierarchy. As with MPLS, you don include the lo0 loopback interface in the list of interfaces running LDP because it is not a transit interface for labeled traffic. (LDP does use the lo0 interface, however, when sending targeted Hello messages to discover LDP peers that are not directly connected to the local router. LDP depends on these Hello messages to set up and maintain its sessions.)

Again, you are configuring LDP on all interfaces, so you can use the following shortcut:

	[edit protocols]
	aviva@RouterG# set ldp interface all

Its also considered good practice to disable LDP on the fxp0 interface on M-series and T-series routers. This is true in particular for configurations where you configure LDP on all interfaces instead of enabling it interface by interface.

	[edit protocols]
	aviva@router1# set ldp interface fxp0.0 disable

For J-series routers, you can disable LDP on the equivalent interfacethe fe-0/0/0 out-of-band interface:

	[edit protocols]
	aviva@routerJ# set mpls interface fe-0/0/0 disable

Once LDP is turned on on all the routers, the protocol automatically builds multipoint-to-point LSPs, each ending on a different router in the network.

Use the show ldp interface command to check that LDP is up and running on the expected interfaces:

	aviva@RouterG> show ldp interface
	Interface Label space ID Nbr count Next hello
	t1-4/0/0.0 192.168.19.1:0 1 2

	aviva@RouterF> show ldp interface
	Interface Label space ID Nbr count Next hello
	fe-0/0/1.0 192.168.16.1:0 1 3

The output of these two show commands indicates that LDP is running on one interface on the ingress and egress routers. On the transit router, LDP is running on the two interfaces connected to the ingress and egress routers:

	aviva@RouterJ> show ldp interface
	Interface Label space ID Nbr count Next hello
	fe-1/0/1.0 192.168.17.1:0 1 1
	t1-5/0/0.0 192.168.17.1:0 1 2

You see that each LDP interface is operational and has learned about one neighbor.

The LDP session between two routers runs over TCP, so after LDP is running on an interface, you expect to see that the TCP connection is established and operational:

	aviva@RouterG> show ldp session
	 Address State Connection Hold time
	192.168.17.1 Operational Open 26

The session information for the ingress router shows that the session to RouterJ at 192.168.17.1 is operational and the connection is open. The session hold time is how long LDP should wait to receive keepalive messages from its peer before closing the session. (LDP considers any LDP message to be a keepalive.) The JUNOS default hold time is 30 seconds, and the output shows that 26 seconds remain on this timer. Use the detail form of this command to see the session parameters:

	aviva@RouterG> show ldp session detail
	Address: 192.168.17.1, State: Operational, Connection: Open, Hold time: 23
	 Session ID: 192.168.19.1:0--192.168.17.1:0
	 Next keepalive in 3 seconds
	 Active, Maximum PDU: 4096, Hold time: 30, Neighbor count: 1
	 Keepalive interval: 10, Connect retry interval: 1
	 Local address: 192.168.19.1, Remote address: 192.168.17.1
	 Up for 1d 21:52:42
	 Local - Restart: disabled, Helper mode: enabled
	 Remote - Restart: disabled, Helper mode: enabled
	 Local maximum recovery time: 240000 msec
	 Next-hop addresses received:
	 t1-4/0/0.0
	 10.0.8.1
	 10.0.0.2

The first line of the output shows that the LDP session is up and runningthis is essentially the same information as the basic show ldp session command. The second line reports the LDP session ID, which is a concatenation of the LDP IDs for the local router and its LDP neighbor. Each router creates a 6-byte LDP ID. The first four bytes are the router ID or IP address of the router itself. The next two bytes define the type of labels that LDP is allocating. The value 0 is the default and means that LDP assigns labels on a per-router basis rather than on a per-interface basis.

The Next keepalive field shows how long before the LDP sends a keepalive message to its neighbors. A couple of lines down, you see that keepalive messages are sent every 10 seconds, which is the LDP default. The fourth line indicates that the session is active and can carry packets up to 4,096 bytes long. The last two fields show the default hold time and how many neighbors are participating in this LDP session.

The next several lines provide information about the session to the LDP peer, including the IP addresses and how long the session has been up. The Local, Remote, and Local maximum recovery time lines report provide information about graceful restart (see Recipe 8.12). The last section lists the next-hop addresses that the router has learned from the LDP session. You see that the router has learned the address to interface t1-4/0/0, the address of the subnet to the neighbor (10.0.0.2), and the address of the subnet between the neighbor and the egress router (10.0.8.1).

A reliable way to check that the LSP is up is to look for a route for the FEC:

	aviva@RouterG> show route protocol ldp table inet.3
	inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
	+ = Active Route, - = Last Active, * = Both
	192.168.16.1/32 *[LDP/9] 1d 21:53:52, metric 1
	 > via t1-4/0/0.0, Push 100000
	192.168.17.1/32 *[LDP/9] 1d 21:53:52, metric 1
	 > via t1-4/0/0.0

These two routes are the LDP FECs, and there is one for each LDP neighbor. By default, the JUNOS LDP software advertises an FEC for its loopback address. The first FEC is to the LSPs egress point, 192.168.16.1/32, through the t1-4/0/0/0 interface. The second line also shows the label value and operation associated with this FEC. The label value is 100000, and LDP pushes this label onto the label stack of all packets destined for 192.168.16.1/32. Recipe 14.2 describes the contents of the inet.3 and mpls.0 routing tables.

LDP also keeps track of its FECs in a database. Here are the entries on the egress router:

	aviva@RouterF> show ldp database
	Input label database, 192.168.16.1:0--192.168.17.1:0
	 Label Prefix
	 100000 192.168.16.1/32
	 3 192.168.17.1/32
	 100032 192.168.19.1/32
	Output label database, 192.168.16.1:0--192.168.17.1:0
	 Label Prefix
	 3 192.168.16.1/32
	 100000 192.168.17.1/32
	 100032 192.168.19.1/32

The Input label database section shows the labels received from the LDP peers, and the Output label database section shows the labels that this router has advertised. Here, RouterF has advertised a label value of 3 to RouterJ. This reserved label indicates that RouterF has signaled RouterJ to perform penultimate-hop popping to remove the top label on the stack before forwarding packets to RouterF.

To verify correct forwarding along the LSP, ping the egress router from the ingress router. For this to work, you need to configure a loopback address of 127.0.0.1 on the egress router:

	[edit]
	aviva@RouterF# set interfaces lo0 unit 0 family inet address 127.0.0.1/32

The egress router uses this address to send echo replies to echo requests sent by the ping command. Then send an MPLS ping request from the ingress router along the LSP:

	aviva@RouterG>  
ping mpls ldp 192.168.16.1
	!!!!!
	--- lsping statistics ---
	5 packets transmitted, 5 packets received, 0% packet loss

The ping echo replies include the label that the ingress router added to the packet when putting it into the LSP. The ping mpls command uses port 3503 for MPLS echo requests instead of the UDP port 7, which is used by the standard ping command.

This recipe shows only the commands you need to set up MPLS and LDP. Because LDP depends on the routing information provided by an IGP, the routers must be running either IS-IS or OSPF and IPv4 addresses must be configured on all interfaces running LDP and the IGP. For the ingress router in this recipe, here are the parts of the configuration related to setting up the LDP-signaled LSP:

	aviva@RouterG> show configuration interfaces
	t1-4/0/0 {
	 unit 0 {
	 family inet {
	 address 10.0.0.1/24;
	 }
	 family mpls;
	 }
	}
	lo0 {
	 unit 0 {
	 family inet {
	 address 192.168.19.1/32;
	 }
	 }
	}

	aviva@RouterG> show configuration routing-options
	router-id 192.168.19.1;
	aviva@RouterG> show configuration protocols
	mpls {
	 interface t1-4/0/0.0;
	}
	ospf {
	 area 0.0.0.0 {
	 interface lo0.0 {
	 passive;
	 }
	 interface t1-4/0/0.0;
	 }
	}
	 
ldp {
	 interface t1-4/0/0.0;
	}

See Also

Recipes 8.12 and 14.2