haps the most important to us at the time, though, was that each branch could directly connect to both HQ locations without the need for an additional PVC. Not only that, but due to the nature of MPLS, every branch could communicate directly with every other branch without traversing the HQ locations. This would be- come important, since we were looking to implement a VoIP solution later on as well. Figure 24-2 shows the design using MPLS. Notice that the overall design has not really changed. Each branch and each HQ location still connects to the cloud. The difference is that there are no VCs from the customer's point of view. Each site truly connects to Chapter 24: MPLS Branch 010 Branch 020 HQ Office-1 Branch 030 10.0.0.0/16 Branch 040 Branch 050 HQ Office-2 10.1.0.0/16 Frame Relay Branch 060 Branch 070 Branch 080 2xDS3 Various Frame Relay T1 Aggregate Speed 90 Mbps Aggregate Port Speed: ~100 Mbps Aggregate CIR Speed: ~50 Mbps Figure 24-1. Multisite Frame Relay Branch 010 Branch 020 HQ Office-1 Branch 030 10.0.0.0/16 Branch 040 HQ Office-2 Branch 050 10.1.0.0/16 No VCs - MPLS cloud Branch 060 allows all sites to connect to all sites Branch 070 Branch 080 2x0C3 All Full T1 Aggregate Speed 360 Mbps Aggregate Port Speed: 368.6 Mbps Figure 24-2. MPLS allows full-mesh topology a cloud with no direct configured or learned virtual links to other locations. Notice that there are MPLS paths within the cloud and, indeed, this can get pretty complicated, but from the customer's point of view, there are no virtual circuits to configure, main- tain, or monitor. So how do the branches communicate if there are no links connecting them? There are two answers-the "how MPLS really works" answer, which involves switching in the cloud based on labels, and the "what you need to know" answer, which is much simpler. From each location's point of view, an IP routing protocol provides a next hop for the destination IP address. Hold the phone! Didn't I say that IP routing tables weren't needed anymore? Yes, I did. At the level where th