Introduction to MPLS


(Arindom N) #83

Hi Rene,
If you don’t mind I am asking you one question regarding MPLS…Why u didn’t add anything regarding MPLS TE ? traffic engineering is an important topic of MPLS so why u didn’t add because it’s not on the CCIE RS syllabus, it’s from CCIE SP that’s why?

Or have you added it anywhere ? Maybe I made a mistake to find it.

Thanks & Regards,
Arindom
India


(Rene Molenaar) #84

Hi Arindom,

The main reason is because it’s not on the CCIE R&S blueprint. It’s an interesting (and important) topic so I still want to add it sometime, it’s just not high on the priority list since there is some stuff that I do have to add first :smile:

Rene


(Arindom N) #85

Hi Rene,
Thank for reply…
Yes yes its not the CCIE R&S Blue print but really important for service provider network…
We will wait for your MPLS te lesson:smiley: but before that we should go through the entire lesson of MPLS which you written.

Thanks & Regards,
Arindom


(Houtan L) #86

Hey mate,

I think the configuration you provided for P router is missing "network 3.3.3.3 0.0.0.0 area 0 " under router ospf 1.
LDP was not coming up in my lab:

PE1#sh mpls ldp disc
 Local LDP Identifier:
    2.2.2.2:0
    Discovery Sources:
    Interfaces:
        FastEthernet0/0 (ldp): xmit/recv
            **LDP Id: 3.3.3.3:0; no route**

Once i added that it came up.


(Lazaros Agapides) #87

Hello Houtan

Thanks for the comment. Looking over the lesson, I notice that the command is indeed on the P router. Take a look at this screenshot:

Looking at the configs at the end of the lesson, the command is included there as well.

I hope this has been helpful!

Laz


(David W) #88

Love all these lessons! I think in the Intro to MPLS it would be more helpful to use an MPLS tunnel in the example and config instead of a GRE tunnel. I understand that they are the same concept, but as we are talking about MPLS, not sure why we would want a GRE tunnel example instead.

Thanks,

Dave W.


(MARKOS A) #89

Hello Networklessons Team

I try to ping 5.5.5.5 from CE1 but it is only pingable if I choose as source the loopback IP. Same if I try to ping 1.1.1.1 from CE2 (For the GRE case). For the MPLS case I can ping from CE1 to 5.5.5.5 but I have to use the loopback IP as source to ping from CE2 to 1.1.1.1. Could you please explain why this is happening? Thank you

Markos


(Lazaros Agapides) #90

Hello David

Great to hear that you’re enjoying the lessons! The lesson starts out with a GRE example in order to compare its operation with that of using MPLS. It’s an opportunity to compare the two technologies and see how each implements the solution with the advantages of each.

I hope this has been helpful!

Laz


(Lazaros Agapides) #91

Hello Markos

In both cases, it is only the 1.1.1.1 and 5.5.5.5 networks that are being advertised via BGP. This means that when you ping directly from CE1, it is using the 192.168.12.1 address of the Gi0/1 interface as the source. This means that the ping may reach the 5.5.5.5 IP address, but the return trip does not take place because the routers do not know the 192.168.12.0/24 network and how to get to it. The same is true of the reverse.

I hope this has been helpful!

Laz


(Rahul D) #92

Hi Rene/Team,
Could you provide some assistance with this query?


As I have the same concern. I think it is as stuart mentioned that recursive lookup is checking MPLS forwarding as well and delivering the packet to 4.4.4.4 based on MPLS label binding.
Regards.


(Rene Molenaar) #93

Hello Rahul,

The P router doesn’t know about 1.1.1.1/32 or 5.5.5.5/32, which is what we want (BGP free core). The LSP is between PE1 and PE2. The P router only needs to know how to reach these two routers.

In the Introduction to MPLS lesson, you can see how it works.

When PE1 wants to reach 5.5.5.5, it uses 4.4.4.4 as the next hop. It looks in its MPLS forwarding table to figure out how to get to 4.4.4.4:

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

When the P router receives the packet, it checks its own MPLS forwarding table:

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

To get to 4.4.4.4/32, it uses the GigabitEthernet0/2 interface (and pops the label too). This is how the P router forwards packets without knowing what’s inside them (source 1.1.1.1 and destination 5.5.5.5).

Rene


(Dan C) #94

ON my P router I get this

Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop    
Label      Label      or Tunnel Id     Switched      interface              
16         Pop Label  2.2.2.2/32       0             Gi0/1      192.168.23.2
17         No Label   4.4.4.4/32       1887          Gi0/2      192.168.34.4

This no label is bothering me as I can’t ping 5.5.5.5 of CE1 sourced on loopback0…and to top it iff:

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


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

I have no idea what is wrong with my simulation…what is missing here?


(Dan C) #95

Please disregard my previous post, I am working on a GNS 3 simulator using Cisco IOS Software, IOSv Software (VIOS-ADVENTERPRISEK9-M), Version 15.6(2)T, RELEASE SOFTWARE (fc2)
I had to reboot PE2 to get mpls ip going correctly…guess this one good trick to use in under extreme circumstances.
Thank you !


(Lazaros Agapides) #96

Hello Dan

Thanks for providing that clarification, Let us know if you need any other help!

Laz


(Cecil B) #97

Hello Team,
I really enjoyed this lesson on introduction to mpls. After i did a lab on everything i noticed that the gre tunnel was more efficent in getting from ce1 to ce2.

With gre tunnel configured:

CE-1#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 1 msec 1 msec 1 msec
 2 192.168.24.4 2 msec 2 msec 1 msec
 3 192.168.45.5 2 msec 2 msec * 
CE-1

With mpls ip configured:

CE-1#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 1 msec 1 msec 1 msec
 2  *  *  * 
 3 192.168.34.4 1 msec 1 msec 1 msec
  4 192.168.45.5 2 msec 2 msec * 
CE-1#

Is this because it is a lab environment and a real world scenario is different?

Thanks again for the education,
Cecil


(Lazaros Agapides) #98

Hello Cecil

The results you get are to be expected. It seems at first glance to indicate that there are fewer hops traversed with the GRE tunnel giving the impression that it is more efficient. However, even with the GRE tunnel, there are the same number of hops taking place, but traceroute does not show them all.

The GRE tunnel allows PE1 to send packets to PE2 “as if” they were directly connected. Physically however, the packets are still traversing the P router within the tunnel. Because the traceroute packets are also sent within this tunnel, when they traverse the P router, they are not handled by it. They are simply the payload of the GRE tunnel packets and are not actually processed.

The tracroute of the MPLS scenario shows the hop of the P router because MPLS as it is configured here, allows the P router to take part in the process. This is why it responds to the traceroute.

The efficiency provided by MPLS resides within the method of routing rather than in the number of hops. MPLS uses short path labels rather than long network addresses avoiding complex lookups in a routing table thus speeding up traffic flows.

I hope this has been helpful!

Laz


(Cecil B) #99

Hello Laz,
Thanks for replying. Just to clear things up a bit, with a gre tunnel, you said that the traffic still traverse the P router, but it is not handling any of the tunel traffic, so it just forwards it on to PE2. Should there still not be some slow down with MPLS since the P router has to read the lablel and then check the routing table to see where to send the traffic? What do you mean when you say MPLS uses short path labels. i know this is a small lab, but how long can a label be? I am sure it gets to more than 2 digits. Does the length of the label affect traffic flow?

Thanks,
Cecil


(Lazaros Agapides) #100

Hello Cecil

Yes that is correct. The router doesn’t route traffic based on the IP addresses of the traffic INSIDE the tunnel, that’s why you don’t see it as a hop in the traceroute. However, the P router still performs routing on the GRE packet, that which is carrying the internal tunneled traffic. So routing is still performed. The advantage of GRE is that you don’t need to know about the internal network of the carrier or ISP, but only the traffic that goes between the edge routers of your locations, the CE routers.

In both the GRE and the MPLS cases, the traffic must traverse the P router. There is no physical link between the two CE routers otherwise. The efficiency that MPLS provides over GRE is that the route lookup process is much more efficient. If you have a large ISP network with hundreds of routers, you can have routing tables that are thousands of entries long. Every time a packet arrives, the routing table lookup can get very resource intensive (CPU, memory etc). MPLS provides a more efficient lookup process using labels.

In short, when using MPLS, the first device does a routing lookup, just like before, but instead of finding the next hop, it finds the final destination router. Once it finds that, it then finds a predetermined path to that final router. The router then applies a label to that packet based on the above information. Routers downstream read this label and use it to route the traffic without needing to perform any additional IP lookups. Once it reaches the final destination, the last router removes the label and the packet is delivered using normal IP routing for the last hop.

So MPLS essentially provides a whole new way of routing, more efficient, and independent of the protocol (in this case IP) that is being used between the two endpoints.

I hope this has been helpful!

Laz


(Cecil B) #101

Thanks for the reply Laz. That cleared it up for me.


(Rahul B) #102

Hi Rene,

Could you please explain between MPLS Layer 2 VPN and Layer 3 VPN.

Regards
Rahul