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.
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
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.
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.
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
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.
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.
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.
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.
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).
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?
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 !
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?
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.
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?
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.