Archive
MPLS tunneling in SROS
I wrote this post ages ago but I have been putting all my time in to CCIE SP labbing and work has been mental so no time for dossing.
Next up I want to look at the basics of MPLS and RSVP configuration. This is an expansive topic and provides a huge amount of flexibility in what you want to achieve with it. This post will cover the basics of setting up interfaces, configuring paths and LSPs.
Let’s get started!
First off we need to know that MPLS and RSVP have a large dependency on each other. Signalling for MPLS tunnels requires RSVP for the path/resv message propagation. We need to configure our interfaces in to the MPLS process and then enable it. Creating an interface in the MPLS context also places it in RSVP, the only thing we need to do is unshut RSVP.
I already have these protocols running so enabling them wont impact anything, it’s simple to configure though
config router mpls no shut
config router rsvp no shut
Below we see how to add an interface in and that it is placed in to RSVP automatically. By simply creating the interface in MPLS we are capable of originating, transiting and terminating LSPs.
Once we enable this at all interfaces in the network then we are good to go for end to end LSPs. If you don’t enable it on all interfaces then your tunnels may fail to come up, or worse fail in a live environment should there be some convergence. Next let’s create a path from r5 to r1. For now we will create it as a loose path with a single hop to the system address of r1.
Now we need to create the LSP and bind the path to it. We will also enable cspf for future use. This allows the use of constraints to be placed against the LSP such as affinities, SRLG. We need to configure the ‘to’ address as the same as the ultimate endpoint of the path. ‘primary’ gives us the ability to assign the path as the preferred path. You can also assign a ‘secondary’, or multiple secondaries, to the LSP but there isnt much point when using loose paths and no constraints. Maybe just in case you shut down the primary path by mistake.
As we can see from the above screenshot the LSP is now up, only in one direction of course. We have an equivalent path in the opposite direction. Lets have a look at the best troubleshooting command you can use for this, well in my experience.
So above we can see the path the LSP is actually taking in the network goes through r5’s egress interface to r3, r3 ingress from r5 and then terminates at r1. We can also see the labels that have been allocated to the tunnel. If there is an @ beside a hop that means there is a detour available which changes to a # when the detour is in use.
If you want to see the detour path that will be further down the detailed information:
The DetourAvoid will show the interface you must not transit and everything is done automatically, no need to manually build detours yourself.
That’s all I got on this, gotta get back on the Ciscos… Next I will be looking at affinities and how you can control your forwarding path with link colouring, cos that’s kinda cool.
Configuring LDP in SROS
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…
iamjeffvader's studymotron and rantatorium 