Introduction to Multiprotocol Label Switching

Multiprotocol Label Switching (MPLS) is a relatively new technology as far as WAN technologies are concerned. MPLS offers a paradigm shift in the way we think about forwarding packets across the WAN. Where traditional WAN technologies such as Frame-Relay are predominantly Layer 2 architectures, MPLS can extend Layer 3 functionality across the WAN, effectively extending the enterprise network across the WAN.

There are two main components to the Multiprotocol Label Switching architecture. The forwarding component uses a label-switching database to forward packets based on labels carried by packets. The control component is responsible for creating and maintaining label-forwarding information (bindings) among a group of connected label switches.

Multiprotocol Label Switching prepends labels to packets as they enter the MPLS WAN. The labels applied to the packets are determined by classifying the packets into a Forwarding Equivalence Class (FEC). Each Forwarding Equivalence Class is mapped to a next hop. Once a FEC is assigned to a packet, no further layer 3 analysis needs to be performed while in the MPLS domain. All packets belonging to a FEC will follow the same path (or in some cases the same set of paths) through the MPLS network.

When these packets are forwarded through the Multiprotocol Label Switch network, forwarding decisions can be made upon the encoded label rather than the network layer headers. It is the use of these labels that allow Multiprotocol Label Switching to maintain the strong and fast characteristics of traditional WAN technologies, while providing the robust traffic engineering policies afforded layer 3 routing protocols.

Conventional packet forwarding has to rely on network layer information to make forwarding decisions. MPLS can classify packets into FECs using ANY information available about the packet, including the interface in which the packet entered the network. This can be done even if no network information can be retrieved from existing layer 3 headers. This allows packets destined for the same network to be assigned different labels which can then be used for complex traffic engineering and routing policies. That being said, it goes without saying that these strong FEC classification abilities allow MPLS to classify packets based upon the ingress router, supporting routing policies that depend on the ingress router.

That is the very brief overview of Multiprotocol Label Switching. In MPLS Part II we'll get some important terminology out of the way, before we dive into Label Switch Routers (LSR) and the types of LSRs you're likely to encounter in the realm of MPLS, followed by an exciting and informative lab detailing the configuration of a Frame Mode MPLS network.

Adding Frame Relay to your Cisco Cert Studies

Getting back into the swing of Cisco CCIE Certification, the first thing I want to talk about is adding a custom frame relay switch. None of those silly little pre-configured doo-hickies you can get in dynamips or in simulation programs. This is a fully operational frame relay switch you can use to build some extremely scalable labs. You can build a physical frame-relay switch using something as simple as a Cisco 2520, or you can go the dynamips route and configure your own using actual IOS software (you must have your own software, I will not provide it).

The depth of routing knowledge required to be successful in the Cisco CCIE Routing and Switching Certification track is a pretty good reason to be interested in this. You need to be intimately familiar with how routing protocols behave over all sorts of LAN and WAN media including NBMA networks such as frame-relay. Are you ready? Let's get started.

First, the following example was built using the C7200-JS-MZ.124-18.bin image. I won't get into the details of configuring dynamips if that is what you are using. There is a great tutorial that comes with the download. If you're too lazy to read that, then you're too lazy to read the following.

If you are familiar with frame-relay at all you already know it is useful to have a DLCI mapping table. This will aid in configuration of both your frame-relay switch, but also the configuration of the devices utilizing it. The mappings I'm using in this example are below:

Input Intf Input Dlci Output Intf Output Dlci
Serial1/1     115          Serial1/5     151
Serial1/1     217          Serial1/7     271
Serial1/3     135          Serial1/5     153
Serial1/3     237          Serial1/7     273
Serial1/5     151          Serial1/1     115
Serial1/5     153          Serial1/3     135
Serial1/7     271          Serial1/1     217
Serial1/7     273          Serial1/3     237

The DLCI values are the values coming into the frame-relay switch from other devices. For example, when DLCI 115 enters interface Serial1/1, it will be forwarded out interface Serial1/5 with a DLCI of 151. I like to draw these out to have in front of me when working a particular topology, but once you get used to the whole DLCI idea, it isn't really necessary. You can set the DLCIs to whatever you like since this is your very own Frame Relay switch. I like to use a system whereby the DLCIs reflect an input and output interface, and in this example, the first number happened to represent a network in which I was using the PVC, but that is not important to you at this point.

With that out of the way, I think you'll find the actual configuration of the frame-relay switch to be pretty straightforward. First you need to enable frame-switching. You can do that with the following command from global configuration mode:

FrSw(config)#frame-relay switching

Next, you are going to configure your interfaces. In this particular example I have serial interfaces. I have specified them as the DCE since this device is acting as the switch. So what we have for interface Serial1/1, according to the DLCI map outlined above, is this:

FrSw(config)#int serial1/1
FrSw(config-if)#no ip address

Next we will specify the frame-relay encapsulation:
FrSw(config-if)#encapsulation frame-relay

The clock rate required by serial interfaces:
FrSw(config-if)#clock rate 4032000

Set the interface to treat LMI like a DCE device:
FrSw(config-if)#frame-relay intf-type dce

Per our DLCI map we are going to Route DLCI 115 out Serial 1/5 with DLCI 151:
FrSw(config-if)#frame-relay route 115 interface Serial1/5 151

Per our DLCI map we are going to route DLCI 217 out Serial 1/7 with DLCI 271:
FrSw(config-if)#frame-relay route 217 interface Serial1/7 271

The remaining interfaces on our Frame-Relay switch follow the same configuration guidlines:

!
interface Serial1/3
no ip address
encapsulation frame-relay
serial restart-delay 0
clock rate 4032000
frame-relay intf-type dce
frame-relay route 135 interface Serial1/5 153
frame-relay route 237 interface Serial1/7 273
!
interface Serial1/5
no ip address
encapsulation frame-relay
serial restart-delay 0
clock rate 4032000
frame-relay intf-type dce
frame-relay route 151 interface Serial1/1 115
frame-relay route 153 interface Serial1/3 135
!
interface Serial1/7
no ip address
encapsulation frame-relay
serial restart-delay 0
clock rate 4032000
frame-relay intf-type dce
frame-relay route 271 interface Serial1/1 217
frame-relay route 273 interface Serial1/3 237
!

To verify your configuration you can use a few show commands:

FrSw#show frame-relay lmi
FrSw#show frame-relay pvc
FrSw#show frame-relay route

And, that is all there is to it. You now have your own Frame-Relay switch, and using the information above you can easily expand this into a complete full mesh topology for a quick way to add robust frame-relay features to any of your Cisco CCIE Certification labs. That's my thought of the day from my Journey toward Cisco CCIE Certification.