LDP


The Label Distribution Protocol (LDP) is a protocol for distributing labels in nontraffic-engineered applications. LDP allows routers to establish LSPs through a network by mapping network-layer routing information directly to data link layer-switched paths.

LDP is described in Label Distribution Protocol (LDP) ”Version 1 Functional Specification , Internet draft draft-ietf-mpls-ldp-06.txt.

These LSPs might have an end point at a directly attached neighbor (comparable to IP hop-by-hop forwarding), or they might have an end point at a network egress node, enabling switching through all intermediary nodes. LSPs established by LDP can also traverse traffic-engineered LSPs created by RSVP.

LDP associates a set of destinations (route prefixes and router addresses) with each data link LSP. This set of destinations is called the forwarding equivalence class (FEC). These destinations all share a common data LSP path egress and a common unicast routing path . Each router chooses the label advertised by the next hop for the FEC and splices it to the label it advertises to all other routers. This forms a tree of LSPs that converge on the egress router.

See Chapter 12, "Layer 2 and Layer 3 VPNs," on page 613.

You can implement Virtual Private Networks (VPNs) using MPLS for tunneling. This allows the use of overlapping address spaces by different VPNs. Some MPLS-based approaches to VPNs support only LDP for signaling. With the JUNOS implementation of LDP, and Juniper Networks routers at the core of a network, you can implement edge devices that support VPNs using LDP signaling for MPLS.

The JUNOS implementation of LDP supports LDP Version 1. The JUNOS software supports a simple mechanism for tunneling between routers in an IGP, to eliminate the required distribution of external routes within the core. The JUNOS software allows an MPLS tunnel next hop to all egress routers in the network, with only an IGP running in the core to distribute routes to egress routers. Edge routers run BGP but do not distribute external routes to the core. Instead, the recursive route lookup at the edge resolves to an LSP switched to the egress router. No external routes are necessary.

You must configure LDP for each interface on which you want LDP to run. LDP creates LSP trees rooted at each egress router for the router ID address that is the subsequent BGP next hop. The ingress point is at every router running LDP. This process provides an inet.3 route to every egress router. If BGP is running, it attempts to resolve next hops by using the inet.3 table first, which binds most, if not all, of the BGP routes to MPLS tunnel next hops.

Two adjacent routers running LDP become neighbors. If the two routers are connected by more than one interface, they become neighbors on each interface. When LDP routers become neighbors, they establish an LDP session to exchange label information. If per-router labels are in use on both routers, only one LDP session is established between them, even if they are neighbors on multiple interfaces. For this reason, an LDP session is not related to a particular interface.

For LDP to run on an interface, MPLS must be enabled on a logical inter-face on that interface.

LDP operates in conjunction with a unicast routing protocol. LDP installs LSPs only when both LDP and the routing protocol are enabled. For this reason, you must enable both LDP and the routing protocol on the same set of interfaces. If this is not done, LSPs might not be established between each egress router and all ingress routers, which might result in loss of BGP-routed traffic.

You can apply policy filters to labels received from and distributed to other routers through LDP. Policy filters provide you with a mechanism to control the establishment of LSPs.

If you are using RSVP for traffic engineering, you can run LDP simultaneously to eliminate the distribution of external routes in the core. The LSPs established by LDP are tunneled through the LSPs established by RSVP. LDP effectively treats the traffic-engineered LSPs as single hops.

When you configure the router to run LDP across RSVP-established LSPs, LDP automatically establishes sessions with the router at the other end of the LSP. LDP control packets are routed hop-by-hop, rather than carried through the LSP. This allows you to use simplex (one-way) traffic-engineered LSPs. Traffic in the opposite direction flows through LDP-established LSPs that follow unicast routing rather than through traffic-engineered tunnels.

Figure 11.14 depicts an LDP LSP being tunneled through an RSVP LSP. The shaded inner oval represents the RSVP domain, while the outer oval depicts the LDP domain. RSVP establishes an LSP through routers B, C, D, and E, with the sequence of labels L3, L4. LDP establishes an LSP through Routers A, B, E, F, and G, with the sequence of labels L1, L2, L5. LDP views the RSVP LSP between routers B and E as a single hop.

Figure 11.14. Swap and Push Label Operation when Tunneling LDP LSPs through RSVP LSPs

graphics/11fig14.gif

For more details about label operations, see "Labels," on page 527.

When the packet arrives at Router A, it enters the LSP established by LDP, and a label (L1) is pushed onto the packet. When the packet arrives at Router B, the label (L1) is swapped with another label (L2). Because the packet is entering the traffic-engineered LSP established by RSVP, a second label (L3) is pushed onto the packet.

This outer label (L3) is swapped with a new label (L4) at the intermediate router (Router C) within the RSVP LSP tunnel, and when the penultimate router (Router D) is reached, the top label is popped. Router E swaps the label (L2) with a new label (L5), and the penultimate router for the LDP-established LSP (Router F) pops the last label.

Figure 11.15 depicts double push label operation (L1L2), which is used when the ingress router (Router A) of the LDP and the RSVP are the same router. Note that Router D is the penultimate hop for the LDP-established LSP, so L2 is popped from the packet by Router D.

Figure 11.15. Double Push Label Operation when Tunneling LDP LSPs through RSVP LSPs

graphics/11fig15.gif

You cannot use RIP as an IGP for shortcuts.

The IGP shortcut computation imposes some restrictions on the network topology allowed. All the routers in the traffic-engineered core and in the surrounding LDP cloud must belong to the same OSPF area or IS-IS level. Using multiple areas or levels prevents the IGP shortcut computation from finding an RSVP LSP next hop. As a result, you cannot use a label from a remote LDP session for this router.

If all the routers do not belong to the same area or level, traffic engineering shortcuts must be explicitly enabled in the IGP.

LDP uses several types of messages to establish and remove mappings and to report errors. All LDP messages have a common structure that uses a type-length-value (TLV) encoding scheme (see Table 11.5).

Table 11.5. LDP Message Types
Message Type Description
Discovery Announces and maintains the presence of a router in a network. Routers indicate their presence in a network by sending the hello message periodically. This hello message is transmitted as a UDP packet to the LDP port at the group multicast address for all routers on the subnet.
Session Establishes, maintains, and terminates sessions between LDP peers. When a router establishes a session with another router learned through the hello message, it uses the LDP initialization procedure over TCP transport. When the initialization procedure completes successfully, the two routers are LDP peers and can exchange advertisement messages.
Advertisement Creates, changes, and deletes label mappings for forwarding equivalence classes (FECs). Requesting a label or advertising a label mapping to a peer is a decision made by the local router. In general, the router requests a label mapping from a neighboring router when it needs one and advertises a label mapping to a neighboring router when it wants the neighbor to use a label.
Notification

Provides advisory information and signal error information. LDP sends notification messages to report errors and other events of interest. There are two kinds of LDP notification messages:

  • Error notifications signal fatal errors. If a router receives an error notification from a peer for an LDP session, it terminates the LDP session by closing the TCP transport connection for the session and discarding all label mappings learned through the session.

  • Advisory notifications pass a router information about the LDP session or the status of some previous message received from the peer.

Enabling LDP

To enable LDP on all interfaces, include the following statement in the configuration file. To enable LDP on a specific interface, specify an interface name in the interface statement. All other LDP configuration statements are optional.

 [edit]  protocols {   ldp {     interface all;   } } 

Configuring the LDP Hello Interval

LDP hello messages enable LDP nodes to discover one another and to detect the failure of a neighbor or of the link to the neighbor. Hello messages are sent periodically on all interfaces where LDP is enabled. By default, LDP sends hello messages every 5 seconds. To modify how often LDP sends hello packets, include the hello-interval statement:

 [edit protocols ldp interface  interface-name  ]  hello-interval  seconds  ; 

Configuring the LDP Hold Time

The hold time determines how long an LDP node should wait for a hello message before declaring a neighbor to be down. This value is sent as part of a hello message so that each LDP node tells its neighbors how long to wait. The values sent by each neighbor do not have to match. The hold time should be at least three times the hello interval. The default is 15 seconds. To modify the hold time, include the hold-time statement:

 [edit protocols ldp interface  interface-name  ]  hold-time  seconds  ; 

Configuring the LDP Keepalive Interval

The keepalive interval determines how often a message is sent over the session to ensure that the keepalive timeout is not exceeded. If no other LDP traffic is sent over the session in this much time, a keep-alive message is sent. The default is 10 seconds. To modify the keep- alive interval, include the keepalive-interval statement:

 [edit protocols ldp interface  interface-name  ]  keepalive-interval  seconds  ; 

Configuring the LDP Keepalive Timeout

After an LDP session is established, messages must be exchanged periodically to ensure that the session is still working. The keepalive timeout defines the amount of time that the neighbor LDP node waits before deciding that the session has failed. This value is usually set to at least three times the keepalive interval. The default is 30 seconds. To modify the keepalive interval, include the keepalive-timeout statement:

 [edit protocols ldp interface  interface-name  ]  keepalive-timeout  seconds  ; 

Configuring LDP Route Preferences

When several protocols calculate routes to the same destination, route preferences are used to select which route is installed in the forwarding table. The route with the lowest preference value is selected. The preference value can be a number in the range 0 through 255. By default, LDP routes have a preference value of 9. To modify the route preferences, include the preference statement:

 [edit protocols ldp]  preference  preference  ; 

Popping the LDP Ultimate-Hop Router

You can control the label value advertised on the egress router of an LSP. The default advertised label is label 3 (implicit null label). If label 3 is advertised, the penultimate hop router removes the label and sends the packet to the egress router. By enabling ultimate-hop popping, label 0 (IPv4 explicit null label) is advertised. Ultimate-hop popping ensures that any packets traversing an MPLS network include a label. To configure ultimate-hop popping, include the explicit-null statement:

 [edit protocols ldp]  explicit-null; 

Juniper Networks routers queue packets based on the incoming label. Routers from other vendors might queue packets differently. Keep this in mind when working with networks containing routers from multiple vendors .

Filtering Inbound and Outbound LDP Labels

You can filter received LDP label bindings, applying policies to accept or deny bindings advertised by neighboring routers. To configure received label-filtering, include the import statement:

 [edit protocols ldp]  import [  policy-names  ]; 

See Chapter 8, "Routing Policy and Firewall Filters," on page 301.

The named policy (configured at the [edit policy-options] hierarchy level) is applied to all label bindings received from all LDP neighbors. All filtering is done using from statements. Table 11.6 lists the only operators that apply when filtering LDP labels.

Table 11.6. from Operators for LDP Received Label Filtering
from Operator Matches

interface

Bindings received from a neighbor that is adjacent over the specified interface
neighbor Bindings received from the specified LDP router ID
next hop Bindings received from a neighbor advertising the specified interface address
route-filter Bindings with the specified prefix

You can configure export policies to filter LDP outbound labels. You can filter outbound label bindings by applying routing policies to block bindings from being advertised to neighboring routers. To configure outbound label-filtering, include the export statement:

 [edit protocols ldp]  export [  policy-names  ]; 

The named export policy (configured at the [edit policy-options] hierarchy level) is applied to all label bindings transmitted to all LDP neighbors. The only from operator that applies to LDP outbound label-filtering is route-filter , which matches bindings with the specified prefix. Table 11.7 lists the only to operators that apply to outbound label filtering.

Table 11.7. to Operators for LDP Outbound Label Filtering
to Operator Matches
interface Bindings sent to a neighbor that is adjacent over the specified interface
neighbor Bindings sent to the specified LDP router ID
next hop Bindings sent to a neighbor advertising the specified interface address

If a binding is filtered, the binding is not advertised to the neighboring router, but it can be installed as part of an LSP on the local router. You can apply policies in LDP to block the establishment of LSPs but not to control their routing. The path an LSP follows is determined by unicast routing, not by LDP.

However, when there are multiple equal-cost paths to the destination through different neighbors, you can use LDP filtering to exclude some of the possible next hops from consideration. Otherwise, LDP randomly chooses one of the possible next hops.

LDP sessions are not bound to interfaces or interface addresses. LDP advertises only per-router (not per-interface) labels. If multiple parallel links exist between two routers, only one LDP session is established, and it is not bound to a single interface.

Do not use the next-hop and interface operators when a router has multiple adjacencies to the same neighbor.

Filtered labels are marked in the database:

 user@host>  show ldp database  Input label database, 10.10.255.1:0-10.10.255.3:0 Label Prefix 100007 10.10.255.2/32 3 10.10.255.3/32 Output label database, 10.10.255.1:0-10.10.255.3:0 Label Prefix 3 10.10.255.1/32 100001 10.10.255.6/32 (Filtered) 

Enabling LDP over LSPs Established by RSVP

See "Enabling LDP," on page 598.

You can run LDP over LSPs established by RSVP, effectively tunneling the LSP established by LDP through the one established by RSVP. To do so, you must enable LDP on the lo0.0 interface. Additionally, you must configure the LSPs over which you want LDP to operate by including the ldp-tunneling statement:

 [edit protocols mpls]  label-switched-path  lsp-path-name  {   from  source;  to  destination;  ldp-tunneling; } 

Configuring the Transport Address Used by LDP

You can control the transport address used by LDP. The transport address is the address used for the TCP session over which LDP is running. To configure transport address control, include the transport-address statement:

 [edit protocols ldp] or  [edit protocols ldp interface  interface-name  ] transport-address ( loopback  interface ); 

If you specify loopback , the address of the loopback interface is used as the transport address. If you specify interface , the interface address is used as the transport address for any LDP sessions to neighbors reachable over that interface.

You cannot use the interface option when there are multiple parallel links to the same LDP neighbor, because the LDP specification requires that the same transport address be advertised on all interfaces to the same neighbor. If LDP detects multiple parallel links to the same neighbor, it disables interfaces to that neighbor one by one until the condition is cleared, either by disconnecting the neighbor on an interface or by configuring the address of the loopback interface.

Configuring LDP Egress Policy

You can control the set of prefixes that are advertised into LDP and cause the router to be the egress router for those prefixes. By default, only the loopback address is advertised into LDP. To configure the set of prefixes from the routing table to be advertised into LDP, include the egress-policy statement:

 [edit protocols ldp]  egress-policy  policy-name  ; 

See Chapter 8, "Routing Policy and Firewall Filters," on page 301.

Juniper Networks routers queue packets based on the incoming label. Routers from other vendors might queue packets differently. Keep this in mind when working with networks containing routers from multiple vendors.

The named policy (configured at the [edit policy-options] hierarchy level) is applied to all routes in the routing table. Those routes that match the policy are advertised into LDP. You can control the set of neighbors to which those prefixes are advertised using the export statement. Only from operators are considered ; you can use any valid from operator.

Configuring FEC Deaggregation

When an LDP egress router advertises multiple prefixes, the prefixes are bound to a single label and aggregated into a single forwarding equivalence class (FEC). By default, LDP maintains this aggregation as the advertisement traverses the network.

By default, because an LSP cannot be split across multiple next hops and all the prefixes are bound into a single LSP, you cannot load-balance across equal-cost paths. It also allows the resulting multiple LSPs to be distributed across multiple equal-cost paths and distributes LSPs across the multiple next hops on the egress segments but installs only one next hop per LSP.

To change the default to load-balance across equal-cost paths, deag-gregate FECs. Deaggregating FECs causes each prefix to be bound to a separate label and become a separate LSP.

To configure deaggregated FECs, include the deaggregate statement. You can configure deaggregated FECs globally only, for all LDP sessions.

 [edit protocols ldp]  deaggregate; 

Configuring LDP to Use the IGP Route Metric

To use the IGP route metric for the LDP routes instead of the default LDP route metric, which is 1, include the track-igp-metric statement. Note that whenever you change the metric used, the LDP connection is reset.

 [edit protocols ldp]  track-igp-metric; 

Tracing LDP Protocol Traffic

To trace LDP protocol traffic, include the traceoptions statement:

 [edit protocols ldp]  traceoptions {   file  filename  <replace> <size  size  > <files  number  > <no-stamp>     <(world-readable  no-world-readable)>;   flag  flag  <  flag-modifier  > <disable>; } 

You can specify the following LDP-specific flags in the LDP traceoptions statement:

  • address ” Address and address withdrawal messages

  • binding ” Label-binding operations

  • error ” Error conditions

  • event ” Protocol events

  • initialization ” Initialization messages

  • label ” Label request, label map, label withdrawal, and label release messages

  • notification ” Notification messages

  • packet ” address, address withdrawal, initialization, label request, label map, label withdrawal, label release, notification, and periodic messages; equivalent to setting the address , initialization , label , notification , and periodic flags

  • packet-dump ” Contents of the messages selected with the message operation flags

  • path ” Label-switched paths

  • periodic ” Hello and keepalive messages

  • state ” Protocol state transitions



Juniper Networks Field Guide and Reference
Juniper Networks Field Guide and Reference
ISBN: 0321122445
EAN: 2147483647
Year: 2002
Pages: 185

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net