iamjeffvader's studymotron and rantatorium

OK so we have configured our IGP and we have full reachability within the core network. In order to provide MPLS VPN services we are going to need some protocol that will signal labels for both the transport addresses and the services. For the transport we can use LDP or RSVP and for services we can use BGP as well. This post will focus on LDP only.

Label Distribution Protocol is pretty much the awesomest protocol you can have. It’s very easy to configure, easy enough to troubleshoot and is scalable. I love it cos it’s difficult to mess up which means less of a mess for me to clean up when someone does!

LDP is the standardized version of Ciscos Tag Distribution Protocol, a.k.a TDP. It was developed by the IETF and is covered in a multitude of RFCs but the basics can be found in RFC5036, LDP Specification. For neighbour discovery (link local), LDP uses UDP port 646 and multicasts to 224.0.0.2. Once discovered, neighbours are maintained through TCP port 646. Targeted peers use the same function except the destination address is explicitly specified and unicast. Have a read of the RFC, it’s not the worst.

Anyway on to the 7750s and how we enable LDP.

Like the majority of protocol happenings the LDP configuration section is within the config router context. Entering the LDP subconfig admin enables the protocol on the router.

A:r2# configure router ldp

Once we have enabled LDP we need to put specific entities in to say where we want LDP to run, what variables we want to attach to each interface and if we want to specify targeted parameters.
First we will put our interfaces in to the process, the interface to r5 is used here:

*A:r2>config>router>ldp# interface-parameters
*A:r2>config>router>ldp>if-params# interface "tor5"
*A:r2>config>router>ldp>if-params>if# exit

Next we will want to specify some peers so that we can do authentication and neighbour specific parameters.

*A:r2>config>router>ldp# peer-parameters
*A:r2>config>router>ldp>peer-params# peer 1.1.1.1
*A:r2>config>router>ldp>peer-params>peer$ authentication-key labldp

Now by far the most useful command with LDP is show router ldp session, it will tell you who you have an adjacency with and if its link local or link local and targeted, displayed as both, and you will want both for services.

Now if we look at our peers we will see nothing to 1.1.1.1 even though we just configured it, wtf!? That’s because you need a reason to signal a targeted session as 1.1.1.1 is not directly connected to r2. You can do this in a couple of ways either by creating an explicit targeted relationship or creating a SDP. We will use targeted here as SDPs will be covered when I get on to services.

*A:r2>config>router>ldp# targeted-session peer 1.1.1.1

Of course we configure the equivalent on the remote side at r1. What is the result?  r1 becomes a targeted peer:

*A:r2# show router ldp session


==============================================================================
LDP Sessions
==============================================================================
Peer LDP Id Adj Type State Msg Sent Msg Recv Up Time
------------------------------------------------------------------------------
1.1.1.1:0 Targeted Established 36 35 0d 00:02:56
3.3.3.3:0 Both Established 171473 171428 4d 14:31:48
4.4.4.4:0 Both Established 171551 171613 4d 14:34:36
5.5.5.5:0 Both Established 171369 172009 4d 14:27:47
------------------------------------------------------------------------------
No. of Sessions: 4

So what else can you do to tweak LDP? Interestingly you can enable fast reroute on it but since I only just saw it I have never tried it, maybe give that a go when I get on to RSVP FRR:

*A:r2>config>router>ldp# info detail | match fast
no fast-reroute

Under interface config you can change a few things, nothing really fancy. You can alter the local keepalive timers here but I dont set them away from default as I use the IGP and BFD to determine when something has failed. If you want to its hello # or keepalive #.

You can also bind BFD to the LDP interface by simply typing bfd-enable under the interface.

You can change the transport address away from the system address by setting it to use the interface address itself:

*A:r2>config>router>ldp>if-params>if# transport-address interface


There are lots of other things like tunnel in tunnel, or LDP over RSVP, that you configure here but I will leave those more advanced things for another time. I will finish up with import/export policies and controlling label propagation.

First off I am going to put a loopback interface of 44.44.44.44/32 on r4 and advertise it in to OSPF. This will cause a label to be allocated, or will it? No it won’t, not on a SROS box. On a Cisco router it would but the 7750s (and other SROS routers) will only advertise the system addresses by default. We need to use a policy to cause a label binding.

*A:r4# configure router interface loo44
*A:r4>config>router>if$ address 44.44.44.44/32
*A:r4>config>router>if$ loopback
*A:r4>config>router>if$ back
*A:r4>config>router# ospf area 0 interface "loo44"
*A:r4>config>router>ospf>area>if$ passive

OK so we should have the route in OSPF now but no label associated:

*A:r2# show router route-table | match 44.44.44.44
44.44.44.44/32 Remote OSPF 00h03m41s 10

*A:r2# show router ldp bindings prefix 44.44.44.44/32 | match Match
No Matching Entries Found

So now we create the policy to match our prefix and export it in to LDP:

*A:r4>config>router>policy-options# prefix-list 44
*A:r4>config>router>policy-options>prefix-list$ prefix 44.44.44.44/32 exact
*A:r4>config>router>policy-options>prefix-list$ back
*A:r4>config>router>policy-options# policy-statement add_label
*A:r4>config>router>policy-options>policy-statement$ entry 10
*A:r4>config>router>policy-options>policy-statement>entry$ from prefix-list "44"
*A:r4>config>router>policy-options>policy-statement>entry$ action accept
*A:r4>config>router>policy-options>policy-statement>entry>action$ back
*A:r4>config>router>policy-options>policy-statement>entry$ back
*A:r4>config>router>policy-options>policy-statement$ default-action accept
*A:r4>config>router>policy-options>policy-statement>default-action$ back
*A:r4>config>router>policy-options>policy-statement$ back
*A:r4>config>router>policy-options# commit
*A:r4>config>router>policy-options# /configure router ldp export "add_label"
*A:r4>config>router>policy-options#

We should now see a label for our loopback

*A:r2# show router ldp bindings prefix 44.44.44.44/32
===============================================================================
LDP LSR ID: 2.2.2.2
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
WP - Label Withdraw Pending, BU - Alternate Next-hop for Fast Re-Route
===============================================================================
LDP Prefix Bindings
===============================================================================
Prefix IngLbl EgrLbl EgrIntf EgrNextHop
Peer
-------------------------------------------------------------------------------
44.44.44.44/32 131041U 131042 -- --
3.3.3.3
44.44.44.44/32 -- 131038 1/1/4:24 24.24.24.4
4.4.4.4
44.44.44.44/32 131041U 131049 -- --
5.5.5.5
-------------------------------------------------------------------------------
No. of Prefix Bindings: 3

Huzzah!

Now lets look at import policies, this is sooo not a real world example but it gets the point across.

In this example I am using r2 again. It is receiving a label for r4’s system address and allocating one for downstream distribution to r5, nothing unusual with that.

*A:r2# show router ldp bindings prefix 4.4.4.4/32


===============================================================================
LDP LSR ID: 2.2.2.2
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
WP - Label Withdraw Pending, BU - Alternate Next-hop for Fast Re-Route
===============================================================================
LDP Prefix Bindings
===============================================================================
Prefix IngLbl EgrLbl EgrIntf EgrNextHop
Peer
-------------------------------------------------------------------------------
4.4.4.4/32 131069U 131069 -- --
3.3.3.3
4.4.4.4/32 -- 131069 1/1/4:24 24.24.24.4
4.4.4.4
4.4.4.4/32 131069U 131066 -- --
5.5.5.5
-------------------------------------------------------------------------------
No. of Prefix Bindings: 3

So here we see we have selected the label of 131069 directly from r4 as this is our IGP shortest path to 4.4.4.4. I am going to create a policy that will deny 4.4.4.4 from the peering to r4. You might think that forces us to use the label from r3 or r5 but as they are not on the IGP best path they wont be active label bindings. The policy will use a prefix list to match 4.4.4.4/32 and deny it, breaking any LSP going to or through r4. OK caveat time, I am only showing this so you see the danger of filtering labels and so this can be avoided. Breaking the LSP is going to get you in lots of trouble, don’t do it unless you have a good reason.

The import policy is configured as follows:

*A:r2# show router policy admin
prefix-list "r4"
prefix 4.4.4.4/32 exact
exit
policy-statement "ldp_import"
entry 10
from
prefix-list "r4"
exit
action reject
exit
default-action accept
exit
exit
*A:r2#

Here we go, successfully broken:

*A:r2# configure router ldp peer-parameters peer 4.4.4.4 import-prefixes "ldp_import"
*A:r2# show router ldp bindings prefix 4.4.4.4/32
===============================================================================
LDP LSR ID: 2.2.2.2
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
WP - Label Withdraw Pending, BU - Alternate Next-hop for Fast Re-Route
===============================================================================
LDP Prefix Bindings
===============================================================================
Prefix IngLbl EgrLbl EgrIntf EgrNextHop
Peer
-------------------------------------------------------------------------------
4.4.4.4/32 -- 131069 -- --
3.3.3.3
4.4.4.4/32 -- 131069 -- --
4.4.4.4
-------------------------------------------------------------------------------
No. of Prefix Bindings: 2
===============================================================================
*A:r2#
*A:r2# show router ldp bindings active prefix 4.4.4.4/32
===============================================================================
Legend: (S) - Static (M) - Multi-homed Secondary Support
(B) - BGP Next Hop (BU) - Alternate Next-hop for Fast Re-Route
===============================================================================
LDP Prefix Bindings (Active)
===============================================================================
Prefix Op IngLbl EgrLbl EgrIntf/LspId EgrNextHop
-------------------------------------------------------------------------------
No Matching Entries Found

Finally lets cost out the path to r4 and see the labels over another path working. The excitement is almost too much…

*A:r2# configure router ospf area 0 int tor4 met 65534
*A:r2# show router ldp bindings active prefix 4.4.4.4/32
===============================================================================
Legend: (S) - Static (M) - Multi-homed Secondary Support
(B) - BGP Next Hop (BU) - Alternate Next-hop for Fast Re-Route
===============================================================================
LDP Prefix Bindings (Active)
===============================================================================
Prefix Op IngLbl EgrLbl EgrIntf/LspId EgrNextHop
-------------------------------------------------------------------------------
4.4.4.4/32 Push -- 131069 1/1/3:23 23.23.23.3
4.4.4.4/32 Swap 131069 131069 1/1/3:23 23.23.23.3
-------------------------------------------------------------------------------
No. of Prefix Active Bindings: 2
*A:r2#

OK that’s all I got for this one, next up, hmm, mpls/rsvp maybe? Let’s see…