28.06.2014 Views

Discussion

Discussion

Discussion

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

The first line of the output shows that the LDP session is up and running—this is<br />

essentially the same information as the basic show ldp session command. The second<br />

line reports the LDP session ID, which is a concatenation of the LDP IDs for the local<br />

router and its LDP neighbor. Each router creates a 6-byte LDP ID. The first four<br />

bytes are the router ID or IP address of the router itself. The next two bytes define<br />

the type of labels that LDP is allocating. The value 0 is the default and means that<br />

LDP assigns labels on a per-router basis rather than on a per-interface basis.<br />

The Next keepalive field shows how long before the LDP sends a keepalive message<br />

to its neighbors. A couple of lines down, you see that keepalive messages are sent<br />

every 10 seconds, which is the LDP default. The fourth line indicates that the session<br />

is active and can carry packets up to 4,096 bytes long. The last two fields show the<br />

default hold time and how many neighbors are participating in this LDP session.<br />

The next several lines provide information about the session to the LDP peer, including<br />

the IP addresses and how long the session has been up. The Local, Remote, and<br />

Local maximum recovery time lines report provide information about graceful restart<br />

(see Recipe 8.12). The last section lists the next-hop addresses that the router has<br />

learned from the LDP session. You see that the router has learned the address to<br />

interface t1-4/0/0, the address of the subnet to the neighbor (10.0.0.2), and the<br />

address of the subnet between the neighbor and the egress router (10.0.8.1).<br />

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

aviva@RouterG> show route protocol ldp table inet.3<br />

inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)<br />

+ = Active Route, - = Last Active, * = Both<br />

192.168.16.1/32 *[LDP/9] 1d 21:53:52, metric 1<br />

> via t1-4/0/0.0, Push 100000<br />

192.168.17.1/32 *[LDP/9] 1d 21:53:52, metric 1<br />

> via t1-4/0/0.0<br />

These two routes are the LDP FECs, and there is one for each LDP neighbor. By<br />

default, the JUNOS LDP software advertises an FEC for its loopback address. The<br />

first FEC is to the LSP’s egress point, 192.168.16.1/32, through the t1-4/0/0/0 interface.<br />

The second line also shows the label value and operation associated with this<br />

FEC. The label value is 100000, and LDP pushes this label onto the label stack of all<br />

packets destined for 192.168.16.1/32. Recipe 14.2 describes the contents of the<br />

inet.3 and mpls.0 routing tables.<br />

LDP also keeps track of its FECs in a database. Here are the entries on the egress<br />

router:<br />

aviva@RouterF> show ldp database<br />

Input label database, 192.168.16.1:0--192.168.17.1:0<br />

Label Prefix<br />

100000 192.168.16.1/32<br />

3 192.168.17.1/32<br />

100032 192.168.19.1/32<br />

Output label database, 192.168.16.1:0--192.168.17.1:0<br />

Label Prefix<br />

Configuring LSPs Using LDP as the Signaling Protocol | 491<br />

This is the Title of the Book, eMatter Edition<br />

Copyright © 2008 O’Reilly & Associates, Inc. All rights reserved.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!