I read that one of the reasons MPLS is used by companies is that they dont have to buy public IP and MPLS provides them this feature by eliminating the need for public IP’s.
My question is, if companies dont have public IP how to they communicate with internet ? Is MPLS just just for connecting 2 remote offices of a company or does it allow a company to connect to internet as well?
Yes, this is indeed the case. But as you have correctly stated, this is true only for the enabling of interconnectivity between remote sites. With MPLS, you don’t need any public IP addresses to interconnect your remote locations.
The primary purpose of MPLS is to enable a low-cost high performance method of interconnecting multiple remote sites. MPLS is not a technology that delivers connectivity to the Internet. Internet connectivity will have to be delivered independently from MPLS, and as you correctly stated, you need public IPs in order to have access to the Internet.
Thanks for the clarification. That makes sense. But there are scenarios where MPLS can provide internet access as well ? I had seen a case where ISP provide a IGW device to facilitate this. Can you shed light on carrier supporting carriers wherein customer of a MPLS VPN service provider is in turn providing those services to end customers?
Yes I understand your concern. MPLS is used to create a scalable infrastructure and configuration for the easy establishment of VPNs between remote sites. Now if one of those sites has connectivity to the Internet, it is possible to route all of your traffic from other sites to that Internet-connected site to connect to the Internet. That way, all remote sites in your organization’s topology can reach the internet from a single connection. In a sense, MPLS is being used indirectly to connect to the Internet. In reality, it is being used to connect to a remote site that has Internet connectivity.
Alternatively, the ISP itself may create a particular MPLS VPN to a “virtual site” of its own that is connected to the Internet. This way, from the customer’s point of view, the ISP is delivering Internet over an MPLS infrastructure. And that would be the case, however, again MPLS is being used to route traffic to a site that has connectivity to the Internet.
Label Distribution Protocol (LDP) is the protocol that generates and exchanges labels between MPLS routers. By enabling MPLS on your routers, you are essentially enabling LDP to operate. As you can see from the lesson, when you use the show mpls forwarding-table command, you are shown the labels that allow MPLS to operate.
For a more in-depth look at how LDP operates, take a look at the following lesson:
Yes, that is correct. If you go over the lessons that cover the whole MPLS course, you will see all of these features in action, and how they work together to allow MPLS to operate.
It depends on what you want to achieve and the purpose of such a configuration. Are you looking to secure MPLS using IPSec or are you looking to tunnel MPLS over an IPSec tunnel?
For example, it is possible to tunnel MPLS packets over a GRE tunnel that has IPSec security features employed. This is useful for situations where you want to tunnel MPLS packets over a non-MPLS network, and you want to secure them. For more info on that, take a look at this CIsco documentation:
Alternatively, you may want to employ IPSec security features within an MPLS implementation. This requires a VRF-aware IPSec implementation about which you can find out more here:
Additional examples can be found here:
I hope this gives you some indication of how these two technologies (MPLS and IPSec) can be used together, so you can make a more informed decision as to what you want to achieve. Let us know if you require additional information about any of these topics.
With an MPLS topology such as the one you describe here, various techniques can and should be used to ensure that redundancy exists between the P routers. Remember that in MPLS, traffic is forwarded through Label Switched Paths (LSPs) which are established between ingress and egress routers (PEs). You can set up multiple LSPs between the same ingress and egress routers to achieve load balancing and redundancy across multiple paths. This can be achieved in one of several ways:
Equal-Cost Multi-Path (ECMP): When multiple paths with equal cost (i.e., equal IGP metric) exist between the ingress and egress routers, the traffic is load balanced across these paths. The traffic is typically divided based on a hashing algorithm that considers parameters such as source and destination IP addresses, protocol, and port numbers. ECMP can also be used in conjunction with MPLS Traffic Engineering (TE) to optimize resource utilization and achieve load balancing.
MPLS Traffic Engineering (TE): MPLS TE (unit 6 in the MPLS course found here) allows network operators to establish LSPs with specific constraints, such as bandwidth or latency requirements. Using MPLS TE, multiple LSPs with diverse paths can be created to distribute traffic across the network effectively. Load balancing in MPLS TE can be achieved by assigning different weights to the LSPs or by using dynamic load-balancing mechanisms, such as flow-based or adaptive load balancing.
LSP Multipathing: In LSP multipathing, multiple LSPs are set up between the same ingress and egress routers using different paths. The ingress router can then distribute the traffic across these LSPs based on various methods, such as per-flow or per-packet load balancing. Per-flow load balancing is preferred because it helps maintain the correct packet order for individual flows, while per-packet load balancing can result in packet reordering and higher latency.
Such redundancy solutions are not limited to your particular MPLS topology. Any MPLS topology that enables multiple paths within its infrastructure is capable of using them. All MPLS infrastructure is composed of dozens and sometimes hundreds of routers, including many P routers which deliver a multitude of redundant paths that ultimately, with the techniques described above, deliver both robustness, redundancy, and efficiency.
Yes, it is necessary to use the next-hop-self feature for the iBGP peering. Why? Well, if CE1 advertises the 220.127.116.11/32 network to PE1 via eBGP with a next-hop address of 192.168.12.1 (the IP address of CE1), then PE1 will take that information and advertise it to PE2. So PE2 would have in its BGP table the prefix 18.104.22.168/32 with a next hop address of 192.168.12.1. However, PE2 has no idea where 192.168.12.1 is! So any packets PE2 receives with a destination address of 22.214.171.124 will be dropped by PE2 because it has no idea where the next hop IP is.
So PE1 must replace the 192.168.12.1 address with its own when it advertises it to PE2 so that routing will not fail.
When using OSPF as the routing protocol in the core of the MPLS network, you can deploy it as a multi-area OSFP topology. There is no requirement to keep a flat OSPF domain. Indeed, the only requirement is that the underlay routing be deployed such that the routers within the MPLS domain can reach each other. MPLS doesn’t “care” if this is via a single or multiple OSPF areas. In fact, MPLS networks maintained by ISPs will be quite large, and as such will require a multi-area OPSF implementation, so it is quite common.
I would just quickly like to ensure that my understanding is correct.
So the purpose of the first half of this article (with the GRE tunnels) was to demonstrate what BGP free core is and how ISPs could potentially provide a private WAN service for their customers without MPLS, correct? Such solution would work but it wouldn’t be very scalable, especially with thousands of customers.
Now, my second question is. Is MPLS a separate infrastructure from the internet? We can use MPLS without an internet connection, right?
ISPs can’t really achieve a BGP free core on the internet infrastructure, right? Every transit router in the ISP must be running BGP in order to properly route traffic to the correct destination. This is not the case with MPLS though, correct? MPLS can achieve the BGP free core which decreases the amount of routes and the burden on the routers within the core of the infrastructure since they basically don’t have to run BGP.
And to close this up, is MPLS also considered a tunneling protocol? Since it encapsulates the packet with additional headers which are then stripped once they reach the destination, which reveals the original packet.
And if I was to decide to purchase the MPLS WAN service from my ISP while also having Internet from them, would I need a separate connection for the Internet and a separate connection for MPLS?
Yes this is correct. The idea was to show how trying to achieve the same thing with GRE tunnels is not practical nor scalable, and this demonstrates the need for a service like MPLS.
Yes, MPLS distinct from the Internet. It is typically a private network infrastructure that is maintained by an ISP for the purpose of intreconnecting its customers’ private networks.
Achieving a BGP-free core on the Internet is not desirable. It is however desirable in a large private network such as an ISP’s MPLS network. MPLS is not there to replace Internet infrastructure. It’s there to create a scalable private network typically managed by an ISP, that can deliver WAN connectivity to multiple remote locations of a large number of distinct and separate customers.
Yes, MPLS is sometimes considered a form of tunneling, even though its primary design isn’t solely for tunnel creation like some other protocols (e.g., GRE, L2TP, or IPsec). This is the case especially when deployed in the manner described in the MPLS L3 VPN lesson.
There are actually a wide range of options for the nature of the actual “last mile” connection when used for MPLS. It can be a dedicated physical link used only for MPLS, or it can be a link that carries both Internet traffic as well as MPLS traffic with some sort of logical separation typically achieved using VLAN tagging, or it can be an MPLS service that is delivered over commercial-grade WAN connections such as cable or xDSL using SD-WAN-like services.