MPLS

To understand MPLS there are two questions we need to answer:

• What is MPLS?
• Why do we need MPLS?

I’m going to start this lesson with an explanation of why we need it and how MPLS solves some of the issues of other protocols, this will help you to understand why we use MPLS. In the second part of this lesson you will learn what MPLS is and how it actually works.
When you want to learn MPLS, you need to be very familiar with the following topics before you continue:

• IGPs (like OSPF and EIGRP)
• Tunneling (GRE)
• CEF (Cisco Express Forwarding)
• BGP (Border Gateway Protocol)

Having said that, let’s get started!

Why do we need MPLS?

Take a look at the following picture:

Above we have an example of an ISP with two customers called “A” and “B”. The ISP only offers Internet connectivity and no other services. Each customer uses the ISP to have connectivity between their sites.
To accomplish our goal, the ISP is running eBGP between the CE (Customer Edge) and PE (Provider Edge) to exchange prefixes. This means all internal (P) routers of the ISP have to run iBGP or they don’t know where to forward their packets to.
A full internet routing table currently has > 500.000 prefixes and with 8 ISP routers running iBGP, we need 28 iBGP peerings. We can reduce this number by using route reflectors or a confederation. All routers have to do lookups in the routing table for any possible destination.
Now here’s something to think about…when our goal is to have connectivity between two customer sites, why should all internal P routers know about this? The only routers that need to know how to reach the customer sites are the PE routers of the provider. Why not build a tunnel between the PE routers? Take a look at the picture below:

In the picture above I added two GRE tunnels:

• The two PE routers at the top will use a GRE tunnel for the customer A sites.
• The two PE routers at the bottom will use a GRE tunnel for the customer B sites.

With a solution like this, we can have a BGP free core! There’s only two places where we need BGP:

• eBGP between the PE and CE router.
• iBGP between two PE routers.

Let’s take a closer look at the solution I described above.

Tunnel between PE routers

Let’s take a look at the example above in action. I will use the following topology for this:

The topology above is a smaller version of the topology I showed you before. This is the ISP with only one customer. We’ll use a GRE tunnel between PE1 and PE2 so that we don’t need iBGP on the P router. Let me walk you through the entire configuration…

OSPF Configuration

First we will configure OSPF on all ISP routes so that PE1 and PE2 are able to reach each other. I’ve added some loopback interfaces on the ISP routers that will be advertised as well:

PE1(config)#router ospf 1
PE1(config-router)#network 192.168.23.0 0.0.0.255 area 0
PE1(config-router)#network 2.2.2.2 0.0.0.0 area 0

P(config)#router ospf  1      
P(config-router)#network 192.168.23.0 0.0.0.255 area 0
P(config-router)#network 192.168.34.0 0.0.0.255 area 0
P(config-router)#network 3.3.3.3 0.0.0.0 area 0

PE2(config)#router ospf 1
PE2(config-router)#network 192.168.34.0 0.0.0.255 area 0
PE1(config-router)#network 4.4.4.4 0.0.0.0 area 0

That takes care of all internal routing for the ISP.

eBGP Configuration

Let’s continue by configuring eBGP between the CE and PE routers. We will advertise a loopback on each CE router:

CE1(config)#router bgp 10
CE1(config-router)#neighbor 192.168.12.2 remote-as 1234
CE1(config-router)#network 1.1.1.1 mask 255.255.255.255

PE1(config)#router bgp 1234
PE1(config-router)#neighbor 192.168.12.1 remote-as 10

PE2(config)#router bgp 1234
PE2(config-router)#neighbor 192.168.45.5 remote-as 20

CE2(config)#router bgp 20
CE2(config-router)#neighbor 192.168.45.4 remote-as 1234   
CE2(config-router)#network 5.5.5.5 mask 255.255.255.255

That takes care of eBGP.

GRE Tunnel Configuration

Now we can configure the GRE tunnel between PE1 and PE2. I will use their loopback interfaces as the source and destination. We will use the 192.168.24.0 /24 subnet on the tunnel interfaces:

PE1(config)#interface tunnel 0
PE1(config-if)#tunnel source 2.2.2.2
PE1(config-if)#tunnel destination 4.4.4.4
PE1(config-if)#ip address 192.168.24.2 255.255.255.0

PE2(config)#interface tunnel 0
PE2(config-if)#tunnel source 4.4.4.4
PE2(config-if)#tunnel destination 2.2.2.2
PE2(config-if)#ip address 192.168.24.4 255.255.255.0

Now we have a working GRE tunnel.

iBGP Configuration

With the GRE tunnel up and running, we can configure iBGP between the two PE routers:

PE1(config)#router bgp 1234
PE1(config-router)#neighbor 192.168.24.4 remote-as 1234
PE1(config-router)#neighbor 192.168.24.4 next-hop-self

PE2(config)#router bgp 1234
PE2(config-router)#neighbor 192.168.24.2 remote-as 1234
PE2(config-router)#neighbor 192.168.24.2 next-hop-self

Our PE routers will establish an iBGP peering using the IP addresses on the GRE tunnel.

I also could have established iBGP between the loopback interfaces of PE1 and PE2 instead of the IP addresses of the tunnel interfaces. The advantage is that BGP traffic between PE1 and PE2 wouldn’t be encapsulated by GRE. The downside however is that you will need to configure a route-map that changes the next hop IP address of all prefixes learned through BGP to the IP addresses of the tunnel interfaces.

Our configuration is now complete. Let’s find out if it works shall we?

Verification

I’ll do a trace from CE1 to CE2:

CE1#traceroute 5.5.5.5 source loopback 0
Type escape sequence to abort.
Tracing the route to 5.5.5.5
VRF info: (vrf in name/id, vrf out name/id)
  1 192.168.12.2 0 msec 0 msec 0 msec
  2 192.168.24.4 0 msec 0 msec 4 msec
  3 192.168.45.5 0 msec 0 msec *

Great, it’s working! The ISP has a BGP-free core. Here’s what an IP packet  from CE1 to CE2 looks like to the P router:

The outer IP header has source address 2.2.2.2 and destination address 4.4.4.4, the P router knows how to route these since it learned these addresses through OSPF.

What is MPLS?

In the previous example I used a GRE tunnel but I could have used any tunneling mechanism. Besides GRE, there’s IP-in-IP, Q-in-Q and…
MPLS (Multi Protocol Label Switching).
What does multi protocol label switching mean?

• Multi protocol: besides IP you can tunnel pretty much anything…IP, IPv6, Ethernet, PPP, frame-relay, etc.
• Label switching: forwarding is done based on labels, not by looking up the destination in the routing table.

MPLS can do anything that any of the other tunneling protocols support and it can do a lot more than that.
Let’s start with something simple, let’s replace the GRE tunnel from the previous example with MPLS so I can explain how MPLS uses labels.
First let’s get rid of the GRE tunnel and the BGP peering between PE1 and PE2:

PE1 & PE2
(config)#no interface tunnel 0

PE1(config)#router bgp 1234
PE1(config-router)#no neighbor 192.168.24.4 remote-as 1234

PE2(config)#router bgp 1234
PE2(config-router)#no neighbor 192.168.24.2 remote-as 1234

Now we can start with the MPLS configuration.

iBGP configuration

Once again I will configure iBGP between PE1 and PE2 but this time I will use their loopback interfaces. You will see why in a minute:

PE1(config)#router bgp 1234
PE1(config-router)#neighbor 4.4.4.4 remote-as 1234
PE1(config-router)#neighbor 4.4.4.4 update-source loopback 0
PE1(config-router)#neighbor 4.4.4.4 next-hop-self

PE2(config)#router bgp 1234
PE2(config-router)#neighbor 2.2.2.2 remote-as 1234
PE2(config-router)#neighbor 2.2.2.2 update-source loopback 0
PE2(config-router)#neighbor 2.2.2.2 next-hop-self 

That takes care of iBGP.

MPLS Configuration

This is the exciting part, let’s enable MPLS. We’ll do this on all interfaces that connect PE1, PE2 and the P router:

PE1(config)#interface GigabitEthernet 0/2
PE1(config-if)#mpls ip

P(config)#interface GigabitEthernet 0/1
P(config-if)#mpls ip

P(config)#interface GigabitEthernet 0/2
P(config-if)#mpls ip

PE2(config)#interface GigabitEthernet 0/2
PE2(config-if)#mpls ip

That’s pretty simple…only one command to activate MPLS on our interfaces. In the next lesson I will explain what exactly happens when you use this command, for now I want to focus on the labels.

Verification

Let’s try a quick ping between CE1 and CE2:

CE1#ping 5.5.5.5 source loopback 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Great, it works. Why does it work? Keep in mind there is no iBGP on the P router:

P#show ip cef 5.5.5.5
0.0.0.0/0
  no route

Normally this traffic should be dropped since this router has no idea how it can reach 5.5.5.5. However, since we enabled MPLS we are now using labels for our forwarding decisions. Let me explain how that works.
Let’s start with PE1:

PE1#show ip route 5.5.5.5
Routing entry for 5.5.5.5/32
  Known via "bgp 1234", distance 200, metric 0
  Tag 5, type internal
  Last update from 4.4.4.4 00:20:16 ago
  Routing Descriptor Blocks:
  * 4.4.4.4, from 4.4.4.4, 00:20:16 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 5
      MPLS label: none

To reach 5.5.5.5, we have to use 4.4.4.4 as the next hop. Instead of checking the routing table, let’s take a look at the MPLS forwarding table:

PE1#show mpls forwarding-table 
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop    
Label      Label      or Tunnel Id     Switched      interface              
16         17         4.4.4.4/32       0             Gi0/2      192.168.23.3
17         Pop Label  192.168.34.0/24  0             Gi0/2      192.168.23.3
18         Pop Label  3.3.3.3/32       0             Gi0/2      192.168.23.3

Above you can see the labels that this router uses to reach certain prefixes. In the next lesson we’ll discuss how these labels are generated. To reach 4.4.4.4, this router will add label 17 to the IP packet and forwards it on GigabitEthernet 0/2 (towards the P router). A quicker method to see what labels are used for different prefixes is by checking the CEF table:

PE1#show ip cef 5.5.5.5
5.5.5.5/32
  nexthop 192.168.23.3 GigabitEthernet0/2 label 17

Here’s a capture of the IP packet that PE1 sends to the P router:

You can see that the MPLS header has been added in between the Ethernet and IP header. This is why they call MPLS a layer 2.5 protocol.
So what happens when the P router receives this IP packet? It’s using MPLS for forwarding decisions so let’s take a look at its labels:

P#show mpls forwarding-table 
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop    
Label      Label      or Tunnel Id     Switched      interface              
16         Pop Label  2.2.2.2/32       152492        Gi0/1      192.168.23.2
17         Pop Label  4.4.4.4/32       153234        Gi0/2      192.168.34.4

When the P router receives something that is tagged with label 17, then it has to be forwarded to 4.4.4.4. It’s outgoing label says “pop label” which means to remove the label.
PE2 will receive a regular IP packet (without label) with destination 5.5.5.5 and it will forward it using the routing table towards CE2.
When CE2 receives the packet, it will create an ICMP echo reply which will end up at PE2. Here’s what PE2 will do with it:

PE2#show ip route 1.1.1.1
Routing entry for 1.1.1.1/32
  Known via "bgp 1234", distance 200, metric 0
  Tag 1, type internal
  Last update from 2.2.2.2 00:31:34 ago
  Routing Descriptor Blocks:
  * 2.2.2.2, from 2.2.2.2, 00:31:34 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 1
      MPLS label: none

PE2 knows that it has to use next hop 2.2.2.2 to reach 1.1.1.1. Let’s check what label we will use to reach 2.2.2.2:

PE2#show mpls forwarding-table 
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop    
Label      Label      or Tunnel Id     Switched      interface              
16         16         2.2.2.2/32       0             Gi0/2      192.168.34.3
17         Pop Label  192.168.23.0/24  0             Gi0/2      192.168.34.3
18         Pop Label  3.3.3.3/32       0             Gi0/2      192.168.34.3

PE2 will add label 16 to the IP packet and will forward it out the GigabitEthernet 0/2 interface towards the P router. Looking at the CEF table is a quicker method to find the label for a destination prefix:

PE2#show ip cef 1.1.1.1
1.1.1.1/32
  nexthop 192.168.34.3 GigabitEthernet0/2 label 16

The PE2 router will forward it to the P router. Let’s check what it will do with this packet:

P#show mpls forwarding-table 
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop    
Label      Label      or Tunnel Id     Switched      interface              
16         Pop Label  2.2.2.2/32       154767        Gi0/1      192.168.23.2
17         Pop Label  4.4.4.4/32       155528        Gi0/2      192.168.34.4

Router P sees that anything with label 16 should be forwarded on the GigabitEthernet 0/1 interface. It will remove the label and forwards it to PE1.
PE1 can then forward the IP packet (without label) using its routing table to CE1.
That’s how we use MPLS to tunnel traffic between PE routers, creating a BGP free core.

hostname CE1
!
ip cef
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface GigabitEthernet0/1
 ip address 192.168.12.1 255.255.255.0
!
router bgp 10
 bgp log-neighbor-changes
 network 1.1.1.1 mask 255.255.255.255
 neighbor 192.168.12.2 remote-as 1234
!
end

hostname CE2
!
ip cef
!
interface Loopback0
 ip address 5.5.5.5 255.255.255.255
!
interface GigabitEthernet0/1
 ip address 192.168.45.5 255.255.255.0
!
router bgp 20
 bgp log-neighbor-changes
 network 5.5.5.5 mask 255.255.255.255
 neighbor 192.168.45.4 remote-as 1234
!
end

hostname PE1
!
ip cef
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface GigabitEthernet0/1
 ip address 192.168.12.2 255.255.255.0
!
interface GigabitEthernet0/2
 ip address 192.168.23.2 255.255.255.0
 mpls ip
!
router ospf 1
 network 2.2.2.2 0.0.0.0 area 0
 network 192.168.23.0 0.0.0.255 area 0
!
router bgp 1234
 bgp log-neighbor-changes
 neighbor 4.4.4.4 remote-as 1234
 neighbor 4.4.4.4 update-source Loopback0
 neighbor 4.4.4.4 next-hop-self
 neighbor 192.168.12.1 remote-as 10
!
end

hostname PE2
!
ip cef
!
interface Loopback0
 ip address 4.4.4.4 255.255.255.255
!
interface GigabitEthernet0/1
 ip address 192.168.45.4 255.255.255.0
!
interface GigabitEthernet0/2
 ip address 192.168.34.4 255.255.255.0
 mpls ip
!
router ospf 1
 network 4.4.4.4 0.0.0.0 area 0
 network 192.168.34.0 0.0.0.255 area 0
!
router bgp 1234
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 1234
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 2.2.2.2 next-hop-self
 neighbor 192.168.45.5 remote-as 20
!
end

hostname P
!
ip cef
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface GigabitEthernet0/1
 ip address 192.168.23.3 255.255.255.0
 mpls ip
!
interface GigabitEthernet0/2
 ip address 192.168.34.3 255.255.255.0
 mpls ip
!
router ospf 1
 network 3.3.3.3 0.0.0.0 area 0
 network 192.168.23.0 0.0.0.255 area 0
 network 192.168.34.0 0.0.0.255 area 0
!
end    

Labelları switch eder.

pıldığı ve sadece en kısa yolu tutar sadece.-----

push: etiket ekleme
swap: etiketi değiştirme
pop:etiketi cıkartır

pe: edge lsr =push+pop =fip lfib= hem ip hem etiketle ilgilenir

provider=lsr=swap=lfib

header 4 byte dir.

ldp: 646 tcp ve udp calışır.directly connected udp kullanır , uzak bağlantılarda tcp kullanır.

LIFE Lesson: Never configure a loop back with any other mask other than /32. :)) it took 2 hrs of my time to trouble-shoot.

R2,R3 mean Pe Router
=========
ip cef # must command
mpls label protocol ldp # must command
mpls ldp router-id Loopback0         # create loopback interface to be used as ospf router-id, ldp router-id, bgp router-id

http://ithitman.blogspot.com.tr/2012/05/configuring-mpls-easiest-l3vpn-ever.html

When I used to hear the term MPLS, it would strike fear through my heart. Why? Natural reaction of humans is to fear the unknown or dislike the unknown. In this blogtorial, I will attempt to simplify MPLS as much as possible. And hopefully after going through this blogtorial you'll feel much more comfortable with MPLS and how to configure it.

I will present a brief overview of the router roles involved in MPLS and create a checklist for 'How to configure MPLS L3VPN'. I have browsed various articles and read numerous books on MPLS and none of which gave me what I was looking for -- a basic checklist that went step by step and configured MPLS. Most of them jumped around and wasn't organized in any fashion I liked. So I created my own and I hope you find it as useful as I did. 

Consider this topology and let's get started. 

This will be the checklist for the rest of the blogtorial. 

1. Brief overview on Provider, Provider Edge, and Customer Edge router roles.
2. Basic interface configurations on all the routers including IP address and descriptions.
3. IGP (OSPF) in the SP core (P, PE) routers
4. Enable MPLS and get interfaces configured for MPLS
5. VRF creation on the PE for customers
6. Configure interfaces for the VRFs on the PE
7. OSPF VRF for customers
• Redistribute BGP into VRF OSPF on the PE
8. Configure CE OSPF
9. PE to PE MP-BGP (Multiprotocol BGP) session - VPNv4 and VRF address-family
• Redistribute VRF OSPF into BGP on the PE 
10. Verify everything
11. Conclusion

Now with this checklist, let's get started. 

Brief overview on Provider, Provider Edge, and Customer Edge router roles.

• P Router - Stands for Provider router. A LSR (Label Switch Router) which typically just runs MPLS, and IGP. Completely transparent to the CE routes, does not usually connect directly to CE routers (remember there is an exception to everything :-*) and is considered part of the SP Core infrastructure. 
• PE Router - Stands for Provider Edge Router. A LSR (Label Switch Router) which typically runs MPLS, IGP, and MP-BGP. It usually connects directly to CE routers, and is aware of the customer routes and typically is the edge of the VPN. 
• CE Router - Stands for Customer Edge Router. This is not a LSR (Label Switch Router) and is completely unaware of MPLS. It is usually deployed at the customer site and runs customer services.   

Basic interface configurations on all the routers including IP address and descriptions. 

R7 and R3 Provider (P) Routers

R2 and R4 Provider Edge (PE) Routers

R6 and R5 Customer Edge (CE) Routers

IGP (OSPF) in the SP core (P, PE) routers

OSPF on P Routers

OSPF on PE Routers

Enable MPLS and get interfaces configured for MPLS.

• Notice the LDP neighbor relationship is forming soon as you configure the interface for MPLS. Note: LDP router-id must be reachable or else LDP neighbor relationship will not form. 

R7 P Router

R3 P Router

R2 and R4 PE Routers

VRF creation on the PE for customers

• RD - Stands for Route Distinguisher. It helps BGP with carrying duplicate prefixes. It is a 64bit ID. 
• RT - Stands for Route Target. It helps the PE place the routes in the proper VRF tables. 
• RD and RT theory can get very complex and is outside the scope of this blogtorial. Please read docs if you are still interested. 

Configure interfaces for the VRFs on the PE 

When you enable 'ip vrf forward <VRF>', if there are any IP addresses on that interface it will be removed so watch out!

OSPF VRF for customers
This is a completely separate instance of OSPF and has nothing to do with OSPF process id 1.

Configure CE OSPF 

PE to PE MP-BGP (Multiprotocol BGP) session - VPNv4 and VRF address-family

• First basic BGP configuration with loopback as the update-source.
• Next get the vpnv4 address-family configured and send the community since BGP uses communities to exchange RD (Route Distinguisher) information.
• Finally get vrf address-family configured with redistribution of the VRF OSPF learned routes.   

Verify everything

• First let's see if we can ping the loopback on R6 and R5. 
• Note that you are able to see the PE routers and P routers and everything in the middle during a traceroute. Well there is something called 'MPLS TTL Propogation' which I will post about later. Most ISPs will disable 'mpls ttl propogation'. 

• Next let's check out the BGP tables on the PE routers.
• As you can see all the routes are propagated and placed in the proper VRF. The main routing table has no knowledge of these routes. 

• Few commands to verify the MPLS forwarding-table and the LDP neighbor relationship.
• Labels are outside the scope of this blogtorial. However keep in mind that labels are exchanged using LDP, local labels which the router locally assigns to a prefix and advertises to other LDP neighbors and remote labels which are labels learned from other LDP neighbors. 

Conclusion

MPLS is a fairly complex and an advanced subject. I wish I could have gone more indepth about how labels are distributed and the theory behind local labels, remote labels, bindings, troubleshooting etc. However, I wanted to keep this blogtorial as easy as possible so you can get a topology up and running in little or no time. I hope that this blogtorial has shed some light on MPLS concepts, and configuration.