MPLS

You are currently browsing articles tagged MPLS.

So I hope the last three posts got you excited about this technology.  Not only have we used a shared infrastructure for multiple customers without them knowing, but we’ve kept all of the customer routes out of the providers network!  That’s pretty cool!  So let’s take a look at how this works.

VRFs/VPNV4/RDs/RTs
So we already talked about VRFs and VPNV4 route advertisements.  However, I didn’t really dig into the details mostly because it’s a little confusing.  So let’s talk about how RDs and RTs really work in greater detail.

RDs (Route Designators) are 64 bit identifiers that get prepended to your 32 bit route to make a 96 bit VPNv4.  This makes good sense and it’s a perfect way to keep customer A’s 10.0.0.0/8 route distinct from customer B’s 10.0.0.0/8 route when advertising them across the MP-BGP session between PE routers.

RTS (Route Targets) are BGP extended community values.  These get tagged on import and export from a VRF and are what the router actually uses to import and export routes out of certain VRFs.

This is where it’s sort of confusing.  RDs are used to make routes unique but RTs are what are used to import and export routes out of VRFs.  Literally the only thing that an RD is used for is to make the VPNv4 route.  They accomplish the task of making multiple customer’s routes unique when they are being advertised via MP-BGP.  However, that’s where their functionality ends.  RTs make the VRF import/export decision.  Routes are tagged on import and export with an RT.  These get attached to the route updates as extended community strings and are then used by the receiving router to make VRF import decisions.

In the last post, we configured the PEs to do so with this configuration…

ip vrf customer1
rd 65100:100
route-target export 65100:100
route-target import 65100:100

So the RD for customer1’s VRF is 65100:100.  I decided (it was just easier) to use the same value for the RT for this VRF.  So these route’s will get exported with an extended community value of 65100:100.  Let’s look at both of these items on the routers.  In the output of the command shown below you can see that the RD for each VRF is shown.

PE3#show ip bgp vpnv4 all
BGP table version is 9, local router ID is 7.7.7.7
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65100:100 (default for vrf customer1)
*> 10.10.20.0/24    192.168.30.2             0             0 65100 i
Route Distinguisher: 65200:200 (default for vrf customer2)
*> 172.16.2.0/24    192.168.40.2             0             0 65200 i

To see the RT you can look at the actual BGP route to see the extended community string as shown below.

PE3#show ip bgp vpnv4 vrf customer1
BGP table version is 9, local router ID is 7.7.7.7
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65100:100 (default for vrf customer1)
*> 10.10.20.0/24    192.168.30.2             0             0 65100 i
PE3#show ip bgp vpnv4 vrf customer1 10.10.20.0 255.255.255.0
BGP routing table entry for 65100:100:10.10.20.0/24, version 4
Paths: (1 available, best #1, table customer1)
  Not advertised to any peer
  65100
    192.168.30.2 from 192.168.30.2 (10.10.20.1)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Extended Community: RT:65100:100
      mpls labels in/out 31/nolabel

I’m hoping at this point it’s a little clearer how the entire ‘shared provider infrastructure’ works.  In the next section we’ll talk about why there aren’t any customer routers on the P routers.

MPLS Label Stacks
In the last post we showed you a ‘show ip route’  from a P router and we saw that the P routers didn’t know about any of the customer routes.  So how is that possible?  This is where MPLS really begins to shine.

We talked about how MPLS works at a very basic level.  Tags get assigned to prefixes and the traffic is label switched through the network.  Each LSR performs an operation based on the label that it sees when it receives the traffic.  In most cases, the LSR will examine the label on the packet, and swap labels based on what the LFIB entry for that incoming label said to do.  That’s pretty easy to understand but it still doesn’t explain how the P routers don’t need to know any customer routes.  This is where label stacks come into play.

While we knew that MPLS used label switching, you likely dint know that you could have multiple labels on the same MLPS packet.  In the a VPN scenario, there are generally two labels.  The top label is sometimes called the local label and the bottom label is called the VPN label.  When a PE router sends a MPLS packet to another PE router it pushes both labels onto the MPLS label stack for that packet.  First it looks up the packets true destination and pushes the packet for that.  This would be the VPN label.  Next it pushes the local label which is likely the label for the PE router that the destination MPLS VPN packet is towards.  An example should clear up any questions…

PE1#show ip cef vrf customer1 10.10.20.0 255.255.255.0
10.10.20.0/24, version 15, epoch 0, cached adjacency 172.172.172.2
0 packets, 0 bytes
  tag information set
    local tag: VPN-route-head
    fast tag rewrite with Fa0/0.1, 172.172.172.2, tags imposed: {21 31}
  via 7.7.7.7, 0 dependencies, recursive
    next hop 172.172.172.2, FastEthernet0/0.1 via 7.7.7.7/32
    valid cached adjacency
    tag rewrite with Fa0/0.1, 172.172.172.2, tags imposed: {21 31}

If we look for the 10.10.20.0/24 customer1 route in the CEF table we can see the labels that are imposed on the MPLS packet.  In this case, the label 21 is the label that PE1 received from it’s neighbor P1 for the prefix 7.7.7.7/32.  This would be the top or local label.  At each LSR in the LSP the top (local) label is swapped just like in normal MPLS.  The bottom label (31) is the label PE1 received from its MP-BGP neighbor PE3 for the destination prefix 10.10.20.0/24.    So the local label is used to transport the MPLS packet across the provider infrastructure.  The last P router in the path pops the label (the local label with PHP) and PE3 receives a MLPS packet with the VPN label on it.  This way, it knows MPLS VPN the packet belongs to.

In this blog we looked a little deeper at some of the aspect of MPLS VPNs.  While we just touched the surface, I hope it helps give some perspective as to what you can accomplish with MPLS.

Tags:

So at this point, you might be thinking to yourself, “this is cool and all, but why do I need it”.  Great question!  MPLS was initially designed to be faster than normal IP switching.  The idea was that a label lookup was faster than an IP lookup.  These days, that’s no longer the case.  We have 10 gig line rate interfaces that can do a lot of their functions in hardware.  So what else can MPLS do?  In my opinion, the biggest plus you get from MPLS is running it in conjunction with MP-BGP and VRFs.  Rather than spend a lot of time explaining this, let’s just jump into the config so you can see how cool this is.  Another look at our diagram…

image

Shows that we are looking at service provider network with two customers sharing the same provider infrastructure.  That being said, let’s put the finishing touches on the PE routers to allow them to participate in MP-BGP.

PE1
router bgp 65000
no bgp default ipv4-unicast
neighbor 7.7.7.7 remote-as 65000
neighbor 7.7.7.7 update-source l0
neighbor 3.3.3.3 remote-as 65000
neighbor 3.3.3.3 update-source l0
address-family vpnv4
neighbor 7.7.7.7 activate
neighbor 3.3.3.3 activate

PE2
router bgp 65000
no bgp default ipv4-unicast
neighbor 1.1.1.1 remote-as 65000
neighbor 1.1.1.1 update-source l0
neighbor 7.7.7.7 remote-as 65000
neighbor 7.7.7.7 update-source l0
address-family vpnv4
neighbor 1.1.1.1 activate
neighbor 7.7.7.7 activate

PE3
router bgp 65000
no bgp default ipv4-unicast
neighbor 1.1.1.1 remote-as 65000
neighbor 1.1.1.1 update-source l0
neighbor 3.3.3.3 remote-as 65000
neighbor 3.3.3.3 update-source l0
address-family vpnv4
neighbor 1.1.1.1 activate
neighbor 3.3.3.3 activate

So this should look pretty familiar to anyone that’s worked with BGP minus a few of the commands.  Let’s break those down…

no bgp default ipv4-unicast – Tells the router that for this BGP instance, we aren’t interested in normal IPv4 unicast routing.  This being said, take a look at a ‘show ip bgp summary’.  Nothing comes up however a look at ‘show ip protocol’ shows BGP running.  It is running, we just aren’t looking at the right place now.

address-family vpnv4 – This command configures the BGP routing process for MP-BGP and the associate neighbor ‘activate’ commands activate each neighbor for VPNV4 routing.

So now you might be wondering, what is VPNV4.  Before that comes up, we need to discuss a couple of other terms.  VRFs,or Virtual Routing and Forwarding, allow you to make completely separate routing information based on a physical router.  These are commonly used by service providers to keep different customer router segregated within their infrastructure.  Along with VRFs come RDs, or route designators.  Route designators get assigned to a VRF; so for now just think of a route designator as a way to identify a particular VRF.  Also keep in mind that both of these items are locally significant to a router.  The last item is a route target, or RT, and is considered to BGP to be an extended community string.  The RT looks very similar to an RD but is what actually gets attached (exported) with the route when they are shared between MP-BP peers.  So a VPNV4 route is a customers IPv4 router, with a RD attached to it.  By adding the RD to the front of the route advertisement, we can make multiple advertisements for the same IPv4 network unique across common infrastructure.  VRFs, RDs, and RTs are all ways to keep customer routes separate on shared infrastructure.  Hopefully the rest of this config will clear things up for you. 

PE1
ip vrf customer1
rd 65100:100
route-target export 65100:100
route-target import 65100:100

router bgp 65000
address-family ipv4 vrf customer1
neighbor 192.168.10.2 remote-as 65100
neighbor 192.168.10.2 activate
neighbor 192.168.10.2 as-override

int faste0/1
description Interface to CE1 – Customer1
ip vrf forwarding customer1
ip address 192.168.10.1 255.255.255.0
no shut

PE2
ip vrf customer2
rd 65200:200
route-target export 65200:200
route-target import 65200:200

router bgp 65000
address-family ipv4 vrf customer2
neighbor 192.168.20.2 remote-as 65200
neighbor 192.168.20.2 activate
neighbor 192.168.20.2 as-override

int faste0/1
description Interface to CE2 – Customer2
ip vrf forwarding customer2
ip address 192.168.20.1 255.255.255.0
no shut

PE3
ip vrf customer1
rd 65100:100
route-target export 65100:100
route-target import 65100:100

ip vrf customer2
rd 65200:200
route-target export 65200:200
route-target import 65200:200

router bgp 65000
address-family ipv4 vrf customer1
neighbor 192.168.30.2 remote-as 65100
neighbor 192.168.30.2 activate
neighbor 192.168.30.2 as-override
address-family ipv4 vrf customer2
neighbor 192.168.40.2 remote-as 65200
neighbor 192.168.40.2 activate
neighbor 192.168.40.2 as-override

interface FastEthernet0/1.11
description Interface to CE3 – Customer1
encapsulation dot1Q 12
ip vrf forwarding customer1
ip address 192.168.30.1 255.255.255.0

interface FastEthernet0/1.12
description Interface to CE4 – Customer2
encapsulation dot1Q 13
ip vrf forwarding customer2
ip address 192.168.40.1 255.255.255.0

So let’s take a quick look at what we just did…

ip vrf customer1 – Creates a VRF called customer1
rd 65100:100 – Assings RD 65100:100 to that VRF
route-target export 65100:100 – Tells the router to export routes from this VRF with a RT of 65100:100
route-target import 65100:100 – Tells the router to import any VPNV4 routes that have a RT of 65100:100 into this VRF

router bgp 65000
address-family ipv4 vrf customer1 – Create a routing instance for this VRF within BGP
neighbor 192.168.10.2 remote-as 65100 – Configure the peering to the customer (CE) router
neighbor 192.168.10.2 activate – Activate that router for VPNV4
neighbor 192.168.10.2 as-override – The customer is going to use the same AS number at all locations.  I need to tell the BGP process to allow the same AS in multiple locations.  Recall that if the BGP router sees it’s own AS in the AS-PATH of an incoming route, it will drop the route update as part of loop prevention.

int faste0/1
description Interface to CE1 – Customer1
ip vrf forwarding customer1 –
In this case we are assigning a physical interface to the customer1 VRF.  NOTE – When you assign a interface to a VRF, it clears the interface IP so you’ll need to reassign it. 
ip address 192.168.10.1 255.255.255.0 – Configure the IP address that the customer will be peering with
no shut

The only thing left to do at this point is configure the customer CE routers.  That config is pretty easy so let’s rip through that so we can dig into looking at how things are working.

CE1
hostname ce1
ip routing
ip cef

no ip domain-lookup
line vty 0 15
password cisco
login

int faste0/0
ip address 192.168.10.2 255.255.255.0
no shut

int faste0/1
ip address 10.10.10.1 255.255.255.0
no shut

router bgp 65100
neighbor 192.168.10.1 remote-as 65000
network 10.10.10.0 mask 255.255.255.0

CE2
hostname ce2
ip routing
ip cef

no ip domain-lookup
line vty 0 15
password cisco
login

int faste0/0
ip address 192.168.20.2 255.255.255.0
no shut

int l99
ip address 172.16.1.1 255.255.255.0
no shut

ip route 172.16.1.0 255.255.255.0 null0

router bgp 65200
neighbor 192.168.20.1 remote-as 65000
neighbor 192.168.20.1 allowas-in
network 172.16.1.0 mask 255.255.255.0

CE3
hostname ce3
ip routing
ip cef

no ip domain-lookup
line vty 0 15
password cisco
login

int faste0/0
ip address 192.168.30.2 255.255.255.0
no shut

int l99
ip address 10.10.20.1 255.255.255.0
no shut

ip route 10.10.20.0 255.255.255.0 null0

router bgp 65100
neighbor 192.168.30.1 remote-as 65000
neighbor 192.168.30.1 allowas-in
network 10.10.20.0 mask 255.255.255.0

CE4
hostname ce4
ip routing
ip cef

no ip domain-lookup
line vty 0 15
password cisco
login

int faste0/0
ip address 192.168.40.2 255.255.255.0
no shut

int l99
ip address 172.16.2.1 255.255.255.0
no shut

ip route 172.16.2.0 255.255.255.0 null0

router bgp 65200
neighbor 192.168.40.1 remote-as 65000
neighbor 192.168.40.1 allowas-in
network 172.16.2.0 mask 255.255.255.0

Soa s you can see, there’s nothing crazy about the CE config.  Just basic IP and BGP configuration.  We’ve defined a loopback 99 address as part of the larger class C network that we are advertising through BGP.  Taking a look at the routing table of our CE router and we should see…

 

C    192.168.10.0/24 is directly connected, FastEthernet0/0
     10.0.0.0/24 is subnetted, 2 subnets
C       10.10.10.0 is directly connected, FastEthernet0/1
B       10.10.20.0 [20/0] via 192.168.10.1, 00:03:04

Not only do we have our local routes, but we now have our route from our other customer router CE3.  Cool huh?  In addition, take a look at the routing table on a P router….

P1#show ip route
Codes: L – local, C – connected, S – static, R – RIP, M – mobile, B – BGP
       D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area
       N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2
       E1 – OSPF external type 1, E2 – OSPF external type 2
       i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2
       ia – IS-IS inter area, * – candidate default, U – per-user static route
       o – ODR, P – periodic downloaded static route, l – LISP
       + – replicated route

Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
O        1.1.1.1 [110/2] via 172.172.172.1, 05:34:02, FastEthernet0/0.1
      2.0.0.0/32 is subnetted, 1 subnets
C        2.2.2.2 is directly connected, Loopback0
      3.0.0.0/32 is subnetted, 1 subnets
O        3.3.3.3 [110/2] via 172.172.172.5, 05:33:52, FastEthernet0/0.2
      4.0.0.0/32 is subnetted, 1 subnets
O        4.4.4.4 [110/2] via 172.172.172.18, 05:34:29, FastEthernet0/0.5
      5.0.0.0/32 is subnetted, 1 subnets
O        5.5.5.5 [110/2] via 172.172.172.22, 05:34:59, FastEthernet0/0.6
      6.0.0.0/32 is subnetted, 1 subnets
O        6.6.6.6 [110/3] via 172.172.172.22, 05:34:39, FastEthernet0/0.6
                 [110/3] via 172.172.172.18, 05:34:29, FastEthernet0/0.5
      7.0.0.0/32 is subnetted, 1 subnets
O        7.7.7.7 [110/3] via 172.172.172.22, 05:33:32, FastEthernet0/0.6
      172.172.0.0/16 is variably subnetted, 15 subnets, 2 masks
C        172.172.172.0/30 is directly connected, FastEthernet0/0.1
L        172.172.172.2/32 is directly connected, FastEthernet0/0.1
C        172.172.172.4/30 is directly connected, FastEthernet0/0.2
L        172.172.172.6/32 is directly connected, FastEthernet0/0.2
O        172.172.172.8/30
           [110/2] via 172.172.172.18, 05:34:29, FastEthernet0/0.5
           [110/2] via 172.172.172.1, 05:34:02, FastEthernet0/0.1
O        172.172.172.12/30
           [110/2] via 172.172.172.22, 05:34:59, FastEthernet0/0.6
           [110/2] via 172.172.172.5, 05:33:52, FastEthernet0/0.2
C        172.172.172.16/30 is directly connected, FastEthernet0/0.5
L        172.172.172.17/32 is directly connected, FastEthernet0/0.5
C        172.172.172.20/30 is directly connected, FastEthernet0/0.6
L        172.172.172.21/32 is directly connected, FastEthernet0/0.6
O        172.172.172.24/30
           [110/2] via 172.172.172.22, 05:34:59, FastEthernet0/0.6
           [110/2] via 172.172.172.18, 05:34:29, FastEthernet0/0.5
O        172.172.172.28/30
           [110/2] via 172.172.172.18, 05:34:29, FastEthernet0/0.5
O        172.172.172.32/30
           [110/2] via 172.172.172.22, 05:34:59, FastEthernet0/0.6
O        172.172.172.36/30
           [110/3] via 172.172.172.22, 05:33:32, FastEthernet0/0.6
           [110/3] via 172.172.172.18, 05:33:32, FastEthernet0/0.5
O        172.172.172.40/30
           [110/2] via 172.172.172.22, 05:34:59, FastEthernet0/0.6
P1#

Notice anything weird?  No customer routes!  This post is getting a little long so I’m going to kill it here.  In the next post, we’ll talk about how all of this works.

Tags:

Now that we have an IGP running between all of the provider routers, we can enable MPLS on the links connecting all of the routers together.  Before we do that, it’s probably a good time to discuss some MPLS basics.

MPLS is a way of label-switching packets through a network.  The basic idea being that it was faster to look up a label than to look up a destination IP prefix.  When you enable MPLS the router assigns a locally significant label to each prefix.  Let’s take a quick look at a label on a router so you can see what I mean…

P1#show mpls ldp bindings
  lib entry: 1.1.1.1/32, rev 2
        local binding:  label: 16
  lib entry: 2.2.2.2/32, rev 4
        local binding:  label: imp-null
  lib entry: 3.3.3.3/32, rev 6
        local binding:  label: 17
  lib entry: 4.4.4.4/32, rev 8
        local binding:  label: 18
  lib entry: 5.5.5.5/32, rev 10
        local binding:  label: 19
  lib entry: 6.6.6.6/32, rev 12
        local binding:  label: 20
  lib entry: 7.7.7.7/32, rev 14
        local binding:  label: 21
  lib entry: 172.172.172.0/30, rev 16
        local binding:  label: imp-null
  lib entry: 172.172.172.4/30, rev 18
        local binding:  label: imp-null
  lib entry: 172.172.172.8/30, rev 20
        local binding:  label: 22
  lib entry: 172.172.172.12/30, rev 22
        local binding:  label: 23
  lib entry: 172.172.172.16/30, rev 24
        local binding:  label: imp-null
  lib entry: 172.172.172.20/30, rev 26
        local binding:  label: imp-null
  lib entry: 172.172.172.24/30, rev 28
        local binding:  label: 24
  lib entry: 172.172.172.28/30, rev 30
        local binding:  label: 25
  lib entry: 172.172.172.32/30, rev 32
        local binding:  label: 26
  lib entry: 172.172.172.36/30, rev 34
        local binding:  label: 27
  lib entry: 172.172.172.40/30, rev 36
        local binding:  label: 28

In this case, I have enabled MPLS on P1 (don’t worry, we are still going to walk through how to do that).  As you can see, the router has applied a label to each prefix in the routing table.  Pretty straight forward huh?  To confuse the matter, let’s look at the same command output from P2 which I’ve also configured for MPLS.

P2#show mpls ldp bind
  lib entry: 1.1.1.1/32, rev 2
        local binding:  label: 16
        remote binding: lsr: 2.2.2.2:0, label: 16
  lib entry: 2.2.2.2/32, rev 4
        local binding:  label: 17
        remote binding: lsr: 2.2.2.2:0, label: imp-null
  lib entry: 3.3.3.3/32, rev 6
        local binding:  label: 18
        remote binding: lsr: 2.2.2.2:0, label: 17
  lib entry: 4.4.4.4/32, rev 8
        local binding:  label: 19
        remote binding: lsr: 2.2.2.2:0, label: 18
  lib entry: 5.5.5.5/32, rev 10
        local binding:  label: imp-null
        remote binding: lsr: 2.2.2.2:0, label: 19
  lib entry: 6.6.6.6/32, rev 12
        local binding:  label: 20
        remote binding: lsr: 2.2.2.2:0, label: 20
  lib entry: 7.7.7.7/32, rev 14
        local binding:  label: 21
        remote binding: lsr: 2.2.2.2:0, label: 21
  lib entry: 172.172.172.0/30, rev 16
        local binding:  label: 22
        remote binding: lsr: 2.2.2.2:0, label: imp-null
  lib entry: 172.172.172.4/30, rev 18
        local binding:  label: 23
        remote binding: lsr: 2.2.2.2:0, label: imp-null
  lib entry: 172.172.172.8/30, rev 20
        local binding:  label: 24
        remote binding: lsr: 2.2.2.2:0, label: 22
  lib entry: 172.172.172.12/30, rev 22
        local binding:  label: imp-null
        remote binding: lsr: 2.2.2.2:0, label: 23
  lib entry: 172.172.172.16/30, rev 24
        local binding:  label: 25
        remote binding: lsr: 2.2.2.2:0, label: imp-null
  lib entry: 172.172.172.20/30, rev 26
        local binding:  label: imp-null
        remote binding: lsr: 2.2.2.2:0, label: imp-null
  lib entry: 172.172.172.24/30, rev 28
        local binding:  label: imp-null
        remote binding: lsr: 2.2.2.2:0, label: 24
  lib entry: 172.172.172.28/30, rev 30
        local binding:  label: 26
        remote binding: lsr: 2.2.2.2:0, label: 25
  lib entry: 172.172.172.32/30, rev 32
        local binding:  label: imp-null
        remote binding: lsr: 2.2.2.2:0, label: 26
  lib entry: 172.172.172.36/30, rev 34
        local binding:  label: 27
        remote binding: lsr: 2.2.2.2:0, label: 27
  lib entry: 172.172.172.40/30, rev 36
        local binding:  label: imp-null
        remote binding: lsr: 2.2.2.2:0, label: 28

Notice anything odd?  It appears that the labels for each prefix aren’t globally unique.  The labels are in fact, only locally significant to the router.  For the longest time, this just didn’t make sense to me.  For now, just keep in mind that the labels are only locally significant to the router.

It’s also important to know where the labels are being stored.  Labels are stored in the CEF table with the prefix.  Let’s take a quick look at that as well…

P2#  show ip cef 1.1.1.1 detail
1.1.1.1/32, epoch 0, per-destination sharing
  local label info: global/16
  nexthop 172.172.172.21 FastEthernet0/0.6 label 16
  nexthop 172.172.172.26 FastEthernet0/0.7 label 16

As you can see, the router has two equal cost paths (two routes in the FIB) for 1.1.1.1/32.  The prefix itself has been assigned the label of 16.

Now that we know that the router is assigning a label to each router we need a way to distribute these labels to other MPLS enabled routers.  This is where LDP comes in to the picture.  LDP stands for label distribution protocol and it’s the protocol used to distribute labels between all of the routers.  When talking about LDP and MPLS there are a couple of key terms to keep in mind.

General MPLS terminology
FEC – Forwarding Equivalence Class.  The FEC is a set of similar packets which are forwarded the same way and bound to the same label
LSP – Label Switched Path.  The LSP is the path that traffic takes through the MPLS network for a particular FEC
LSR – Label Switching Router.  A router that has MPLS enabled and performs label based operations. 
LIB – Label Information Base.  Similar to the RIB in IP speak, holds all of the labels received.
LFIB – Label Forwarding Information Base.  Similar to the FIB in IP speak.  The label forwarding information that is used to forward traffic.

Label Distribution Modes
Downstream on demand
– In this mode each LSR requests a label for a particular FEC from the next hop router.  Each LSR only receives one binding per FEC from its downstream LSR.  The downstream LSR is the next hop router found in the IP routing table. 
Unsolicited Downstream – In this mode each LSR distributes a binding to all of its adjacent LSRs without those LSRs requesting the label.

Label Retention Modes
Liberal Label Retention Mode
– Only one label binding is put in the LFIB but the rest are kept in the LIB.
Conservative Label Retention Mode – Only the remote binding that is associated with the next-hop LSR is stored in the LIB.

LSP Control Modes
Independent LSP Control Mode
– The LSR created a local binding for a FEC independently from other LSRs.  The binding is created as soon as a new FEC is recognized by the LSR.
Ordered LSP control Mode – The LSR only creates a local binding for the FEC is it recognizes that it is the egress LSR for the FEC or if the LSR has received a label binding from the next hop for the FEC.  In this manner, it would only create bindings for routes that show as connected in the routing table or for IGP prefixes in which it has already received a label binding from the next hop router.

LSP Label operations
Swap – The top label in the label stack is replaced with another
Push – The top label is replaced with another and then on or more additional labels are pushed onto the label stack
Pop – The top label is removed
Untagged/No Label – The stack is remove and the packet is forwarded unlabeled
Aggregate – The stack is removed and an IP lookup is done on the IP packet

Ok, so that was a lot, but I think it’s best just to use the definitions to describe label distribution and some of the general LSP terminology.  So let’s summarize the key parts of those definitions…

-Labels are assigned to FECs
-FECs take the same LSP through the MPLS network
-Labels are distributed between LDP neighbors.  Unsolicited downstream distribution mode is the default distribution method on Cisco IOS.
-LSRs create a local binding for a FEC.  Independent LSP control mode is the default LSP control method on Cisco IOS. 
-LSRs have three main MPLS operations.  Swap, push, and pop.

Configuring MPLS
Alright, well that was a somewhat brief explanation of MPLS with some key term definitions.  Now, let’s take a look at the very complex configuration of MPLS.

P1

interface FastEthernet0/0.1
mpls ip

interface FastEthernet0/0.2
mpls ip

interface FastEthernet0/0.5
mpls ip

interface FastEthernet0/0.6
mpls ip

P2
interface FastEthernet0/0.4
mpls ip

interface FastEthernet0/0.6
mpls ip

interface FastEthernet0/0.7
mpls ip

interface FastEthernet0/0.9
mpls ip

interface FastEthernet0/0.11
mpls ip

P3
interface FastEthernet0/0.8
mpls ip

interface FastEthernet0/0.9
mpls ip

interface FastEthernet0/0.10
mpls ip

P4
interface FastEthernet0/0.3
mpls ip

interface FastEthernet0/0.5
mpls ip

interface FastEthernet0/0.7
mpls ip

interface FastEthernet0/0.8
mpls ip

PE1
interface FastEthernet0/0.1
mpls ip

interface FastEthernet0/0.3
mpls ip

PE2
interface FastEthernet0/0.2
mpls ip

interface FastEthernet0/0.4
mpls ip

PE3
interface FastEthernet0/0.10
mpls ip

interface FastEthernet0/0.11
mpls ip

That’s it!  All you need to do is issue the ‘mpls ip’ command on any interface you want to talk LDP and use MPLS.  Now let’s look at a couple of commands to verify the MPLS configuration.

P1#show mpls ip binding
  1.1.1.1/32
        in label:     16       
        out label:    16        lsr: 5.5.5.5:0      
        out label:    16        lsr: 4.4.4.4:0      
        out label:    imp-null  lsr: 1.1.1.1:0        inuse
        out label:    16        lsr: 3.3.3.3:0      
  2.2.2.2/32
        in label:     imp-null 
        out label:    17        lsr: 5.5.5.5:0      
        out label:    17        lsr: 4.4.4.4:0      
        out label:    16        lsr: 1.1.1.1:0      
        out label:    17        lsr: 3.3.3.3:0      
  3.3.3.3/32
        in label:     17       
        out label:    18        lsr: 5.5.5.5:0      
        out label:    18        lsr: 4.4.4.4:0      
        out label:    17        lsr: 1.1.1.1:0      
        out label:    imp-null  lsr: 3.3.3.3:0        inuse
  4.4.4.4/32
        in label:     18       
        out label:    19        lsr: 5.5.5.5:0      
        out label:    imp-null  lsr: 4.4.4.4:0        inuse
        out label:    18        lsr: 1.1.1.1:0      
        out label:    18        lsr: 3.3.3.3:0      
  5.5.5.5/32
        in label:     19       
        out label:    imp-null  lsr: 5.5.5.5:0        inuse
        out label:    19        lsr: 4.4.4.4:0      
        out label:    19        lsr: 1.1.1.1:0      
        out label:    19        lsr: 3.3.3.3:0     

<Extra output removed…>

As you can see here, this shows the IP to label binding that is configured on P1.  This is where the labels can get confusing.  Let’s take a look at the binding for the prefix 1.1.1.1/32 and another quick copy of our network diagram so that this make’s sense.

image

So in the case of LSR P1 (2.2.2.2) we can see from the output….

  1.1.1.1/32
        in label:     16       
        out label:    16        lsr: 5.5.5.5:0      
        out label:    16        lsr: 4.4.4.4:0      
        out label:    imp-null  lsr: 1.1.1.1:0        inuse
        out label:    16        lsr: 3.3.3.3:0  

That we have three LDP neighbors P2 (5.5.5.5), P4 (4.4.4.4), PE1 (1.1.1.1), and PE2 (3.3.3.3).  By chance, all of these routers also have label ‘16’ as their local binding for the prefix which is denoted by the ‘out’ label’ for that particular ldp neighbor.  The best path to 1.1.1.1/32 is to PE1 since that’s where the loop back lives.  This is denoted by the ‘inuse’ keyword next to that label binding.  It should also be noted that the out label for the best route shows as ‘imp-null’.  Imp-Null actually means implicit null and indicates that the router will actually pop the label off before forwarding the traffic towards PE1.  This is a function of PHP (Penultimate Hop Popping).  PHP pops the MPLS label off before sending the label to the next router.  It does this since it knows that the next router (PE1) owns that IP address.  In order to save PE1 the trouble of doing a label lookup as well as a IP lookup, P1 pops the label off and sends the packet layer 3 so that PE1 just has to process a standard IP packet rather than a label and a IP packet.  This feature is on by default in Cisco IOS.  This can also be confirmed by looking at the LFIB…

P1#show mpls forwarding-table 1.1.1.1 32
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop   
Label      Label      or Tunnel Id     Switched      interface             
16         Pop Label  1.1.1.1/32       0             Fa0/0.1    172.172.172.1

As you can see, P1 will pop the label before sending it on it’s way.  This output also shows that the LFIB knows where to send the traffic once it performs its LSR operations on the packet.  It knows to send it out interface F10/0.1 once it pops the packet.  This also explains how we can have 4 neighbors who all have the same label for the same prefix.  The label is locally significant so once the LSR performs it’s MPLS operations, the traffic is forwarded out the correct interface towards the correct router.

Summary
So I know that was a lot to swallow but I’m hoping that was enough to at least give you a base understanding of MPLS.  In the next post, we’ll be talking about how carriers use MPLS and MP-BGP to carry multiple different customers traffic across the same MPLS core network.

Tags:

« Older entries