June 21, 2009
MPLS Traffic Engineering
In this Multiprotocol Label Switching article we want to look at MPLS Traffic Engineering. Before we start getting too far into this I want to make sure we understand that Multiprotocol Label Switching traffic engineering is not supported by all routing protocols. Deploying MPLS traffic engineering you are going to be limited to using OSPF, or ISIS.
Let’s jump right in, but be sure you have grabbed the Multiprotocol Label Switching Lab Topology and IP Address Scheme. If you have followed through from MPLS Parts I and II, you will want to modify your routing protocol to be OSPF, as we will be using OSPF in this article. I won’t be going over the details of OSPF configuration here, as they are quite simple. The 2nd change we have to make to all the routers in our MPLS topology is the addition of Loopback addresses to support consistent OSPF router-id configuration and also in order to support the end points of our MPLS traffic engineering tunnels. The IP scheme for the Loopback addresses is as follows:
MPLS1: 10.0.0.1/32
MPLS2: 10.0.0.2/32
MPLS3: 10.0.0.3/32
MPLS4: 10.0.0.4/32
MPLS5: 10.0.0.5/32
MPLS6: 10.0.0.6/32
MPLS7: 10.0.0.7/32
We will need to be sure to advertise these addresses via OSPF, as they will need to be globally routable for the tunnels that we are creating, and in support of future MPLS labs as they become available. With that being done, we are going to begin the configuration of MPLS Traffic Engineering. As stated in MPLS Part II, it is important to have Cisco Express Forwarding enabled. It can be enabled as follows:
MPLS1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
MPLS1(config)#ip cef
MPLS1(config)#^Z
MPLS1#
On each Multiprotocol Label Switching router participating in Multiprotocol Label Switching Traffic Engineering you will need to enable Multiprotocol Label Switching Traffic Engineering support as follows:
MPLS1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
MPLS1(config)#mpls traffic-eng tunnels
MPLS1(config)#^Z
MPLS1#
The next step we are going to take in this demonstration is to enable each MPLS device’s interface to support an RSVP-based MPLS Traffic Engineering Tunnel, which is done as follows:
MPLS1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
MPLS1(config)#int fa1/0
MPLS1(config-if)#mpls traffic-eng tunnels
MPLS1(config-if)#ip rsvp bandwidth 100
MPLS1(config-if)#^Z
MPLS1#
Now that the devices have been configured to support MPLS Traffic Engineering, we need to make sure our routing protocol is ready also. We are using OSPF in this example, so that is what we will show here:
MPLS1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
MPLS1(config)#router ospf 1
MPLS1(config-router)#mpls traffic-eng router-id Loopback0
MPLS1(config-router)#mpls traffic-eng area 0
MPLS1(config-router)#^Z
MPLS1#
The next thing we are going to do is define the paths that we want our traffic to take through the network. I am going to show the configuration of three different paths here. I will make a point about these later, so please do all 3 of them for clarity later on.
MPLS1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
MPLS1(config)#ip explicit-path name ACG enable
MPLS1(cfg-ip-expl-path)#next-address 172.16.13.3
MPLS1(cfg-ip-expl-path)#next-address 172.16.37.3
MPLS1(cfg-ip-expl-path)#next-address 172.16.37.7
MPLS1(cfg-ip-expl-path)#next-address 10.0.0.7
MPLS1(cfg-ip-expl-path)#^Z
MPLS1#
MPLS1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
MPLS1(config)#ip explicit-path name ABDFG enable
MPLS1(cfg-ip-expl-path)#next-address 172.16.12.2
MPLS1(cfg-ip-expl-path)#next-address 172.16.24.2
MPLS1(cfg-ip-expl-path)#next-address 172.16.24.4
MPLS1(cfg-ip-expl-path)#next-address 172.16.46.4
MPLS1(cfg-ip-expl-path)#next-address 172.16.46.6
MPLS1(cfg-ip-expl-path)#next-address 172.16.67.6
MPLS1(cfg-ip-expl-path)#next-address 172.16.67.7
MPLS1(cfg-ip-expl-path)#next-address 10.0.0.7
MPLS1(cfg-ip-expl-path)#^Z
MPLS1#
MPLS1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
MPLS1(config)#ip explicit-path name AEG enable
MPLS1(cfg-ip-expl-path)#next-address 172.16.15.5
MPLS1(cfg-ip-expl-path)#next-address 172.16.57.5
MPLS1(cfg-ip-expl-path)#next-address 172.16.57.7
MPLS1(cfg-ip-expl-path)#next-address 10.0.0.7
MPLS1(cfg-ip-expl-path)#^Z
MPLS1#
We are doing the same thing on MPLS7. The relevant portion of the running config of MPLS7 is shown below:
ipexplicit-pathnameGCAenable
next-address172.16.37.3
next-address172.16.13.3
next-address172.16.13.1
next-address10.0.0.1
ipexplicit-pathnameGFDBAenable
next-address172.16.67.6
next-address172.16.46.6
next-address172.16.46.4
next-address172.16.24.4
next-address172.16.24.2
next-address172.16.12.2
next-address172.16.12.1
next-address10.0.0.1
ipexplicit-pathnameGEAenable
next-address172.16.57.5
next-address172.16.15.5
next-address172.16.15.1
next-address10.0.0.1
Ok. So far we have enabled MPLS Traffic Engineering support for all of our routers. We have configured OSPF support for Multiprotocol Label Switching Traffic Engineering, and now we have defined the traffic engineering paths through the MPLS network. Now, it is time for us to begin building the tunnels. This is really pretty simple, but it is also a very powerful tool to use in controlling the flow of traffic through your network. We begin by creating a tunnel interface, setting the destination, encapsulation, defining an Multiprotocol Label Switching path, and specifying the relative load each path will take, as shown here (note we are creating three tunnels, one for each of our paths):
MPLS1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
MPLS1(config)#interface Tunnel7
MPLS1(config-if)#ip unnumbered Loopback0
MPLS1(config-if)#tunnel destination 10.0.0.7
MPLS1(config-if)#tunnel mode mpls traffic-eng
MPLS1(config-if)#tunnel mpls traffic-eng priority 7 7
MPLS1(config-if)#tunnel mpls traffic-eng bandwidth 100
MPLS1(config-if)#tunnel mpls traffic-eng path-option 1 explicit name ACG
MPLS1(config-if)#tunnel mpls traffic-eng load-share 10
MPLS1(config-if)#^Z
MPLS1#
MPLS1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
MPLS1(config)#interface Tunnel702
MPLS1(config-if)#ip unnumbered Loopback0
MPLS1(config-if)#tunnel destination 10.0.0.7
MPLS1(config-if)#tunnel mode mpls traffic-eng
MPLS1(config-if)#tunnel mpls traffic-eng priority 7 7
MPLS1(config-if)#tunnel mpls traffic-eng bandwidth 100
MPLS1(config-if)#tunnel mpls traffic-eng path-option 1 explicit name ABDFG
MPLS1(config-if)#tunnel mpls traffic-eng load-share 10
MPLS1(config-if)#^Z
MPLS1#
MPLS1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
MPLS1(config)#interface Tunnel703
MPLS1(config-if)#ip unnumbered Loopback0
MPLS1(config-if)#tunnel destination 10.0.0.7
MPLS1(config-if)#tunnel mode mpls traffic-eng
MPLS1(config-if)#tunnel mpls traffic-eng priority 7 7
MPLS1(config-if)#tunnel mpls traffic-eng bandwidth 100
MPLS1(config-if)#tunnel mpls traffic-eng path-option 1 explicit name AEG
MPLS1(config-if)#tunnel mpls traffic-eng load-share 10
MPLS1(config-if)#^Z
MPLS1#
Here I present the running configuration of the tunnel interfaces created on MPLS7, since that is where the endpoint of the tunnel is terminated:
interfaceTunnel1
ipunnumberedLoopback0
tunneldestination10.0.0.1
tunnelmodemplstraffic-eng
tunnelmplstraffic-engpriority77
tunnelmplstraffic-engbandwidth100
tunnelmplstraffic-engpath-option1explicitnameGCA
tunnelmplstraffic-engload-share10
noroutingdynamic
interfaceTunnel102
ipunnumberedLoopback0
tunneldestination10.0.0.1
tunnelmodemplstraffic-eng
tunnelmplstraffic-engpriority77
tunnelmplstraffic-engbandwidth100
tunnelmplstraffic-engpath-option1explicitnameGFDBA
tunnelmplstraffic-engload-share10
noroutingdynamic
interfaceTunnel103
ipunnumberedLoopback0
tunneldestination10.0.0.1
tunnelmodemplstraffic-eng
tunnelmplstraffic-engpriority77
tunnelmplstraffic-engbandwidth100
tunnelmplstraffic-engpath-option1explicitnameGEA
tunnelmplstraffic-engload-share10
noroutingdynamic
Let’s check to see if those tunnels have come up as we expected. We do that with the following command:
MPLS1#showmplstraffic-engtunnelsbrief
SignallingSummary:
LSPTunnelsProcess:running
RSVPProcess:running
Forwarding:enabled
Periodicreoptimization:every3600seconds,nextin125seconds
Periodicauto-bwcollection:disabled
TUNNELNAMEDESTINATIONUPIFDOWNIFSTATE/PROT
MPLS1_t710.0.0.7-Fa1/0up/up
MPLS1_t70210.0.0.7-Fa1/1up/up
MPLS1_t70310.0.0.7-Fa2/0up/up
MPLS7_t110.0.0.1Fa1/0-up/up
MPLS7_t10210.0.0.1Fa1/1-up/up
MPLS7_t10310.0.0.1Fa2/0-up/up
Displayed3(of3)heads,0(of0)midpoints,3(of3)tails
It looks like all THREE of our tunnels are up. But there is still one little problem. We’ll start by looking at the MPLS Forwarding Table, also known as the LFIB for the tunnel’s destination endpoint. This is shown below:
MPLS1#shomplsforwarding-table10.0.0.7
LocalOutgoingPrefixBytestagOutgoingNextHop
tagtagorVCorTunnelIdswitchedinterface
323210.0.0.7/320Fa2/0172.16.15.5
3210.0.0.7/320Fa1/0172.16.13.3
Weird. Where is the third tunnel path? Well, since the Label Forwarding Information Base relies on the Forwarding Information Base, let’s look at the Forwarding Information Base. Again, this is below:
MPLS1#showipcef10.0.0.7detail
10.0.0.7/32,version58,epoch0,per-destinationsharing
0packets,0bytes
taginformationset
localtag:32
via172.16.15.5,FastEthernet2/0,0dependencies
trafficshare1
nexthop172.16.15.5,FastEthernet2/0
validadjacency
tagrewritewithFa2/0,172.16.15.5,tagsimposed:32
via172.16.13.3,FastEthernet1/0,0dependencies
trafficshare1
nexthop172.16.13.3,FastEthernet1/0
validadjacency
tagrewritewithFa1/0,172.16.13.3,tagsimposed:32
0packets,0bytesswitchedthroughtheprefix
tmstats:external0packets,0bytes
internal0packets,0bytes
Alright, what is going on? The FIB is received from the Layer 3 Engine in the control plane. Let’s have a look at the routing table to see what on earth is going on.
MPLS1#showiproute10.0.0.7
Routingentryfor10.0.0.7/32
Knownvia”ospf1″,distance110,metric3,typeintraarea
Lastupdatefrom172.16.15.5onFastEthernet2/0,00:22:54ago
RoutingDescriptorBlocks:
*172.16.15.5,from10.0.0.7,00:22:54ago,viaFastEthernet2/0
Routemetricis3,trafficsharecountis1
172.16.13.3,from10.0.0.7,00:22:54ago,viaFastEthernet1/0
Routemetricis3,trafficsharecountis1
Well, shux, that didn’t do me much good, other than to demonstrate the dependence of the LFIB on the Forwarding Information Base, and the Forwarding Information Base on the routing table. You will notice in all of the above commands that these are all physical interfaces – none of them are the tunnel interfaces. We have to cause OSPF to use the tunnel interfaces in its calculations. We can do THAT by creating the following configuration on each tunnel interface:
MPLS1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
MPLS1(config)#int tunnel 7
MPLS1(config-if)#tunnel mpls traffic-eng autoroute announce
MPLS1(config-if)#^Z
MPLS1#
MPLS1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
MPLS1(config)#int tunnel 702
MPLS1(config-if)#tunnel mpls traffic-eng autoroute announce
MPLS1(config-if)#^Z
MPLS1#
MPLS1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
MPLS1(config)#int tunnel 703
MPLS1(config-if)#tunnel mpls traffic-eng autoroute announce
MPLS1(config-if)#^Z
MPLS1#
MPLS7#conf t
Enter configuration commands, one per line. End with CNTL/Z.
MPLS7(config)#int tunnel 1
MPLS7(config-if)#tunnel mpls traffic-eng autoroute announce
MPLS7(config-if)#^Z
MPLS7#
MPLS7#conf t
Enter configuration commands, one per line. End with CNTL/Z.
MPLS7(config)#int tunnel 102
MPLS7(config-if)#tunnel mpls traffic-eng autoroute announce
MPLS7(config-if)#^Z
MPLS7#
MPLS7#conf t
Enter configuration commands, one per line. End with CNTL/Z.
MPLS7(config)#int tunnel 103
MPLS7(config-if)#tunnel mpls traffic-eng autoroute announce
MPLS7(config-if)#^Z
MPLS7#
Now! It’s time to verify our configurations as we did earlier. Again, let’s start by viewing the LFIB:
MPLS1#shomplsforwarding-table10.0.0.7
LocalOutgoingPrefixBytestagOutgoingNextHop
tagtagorVCorTunnelIdswitchedinterface
32Poptag[T]10.0.0.7/320Tu7point2point
Poptag[T]10.0.0.7/320Tu702point2point
Poptag[T]10.0.0.7/320Tu703point2point
[T]ForwardingthroughaTSPtunnel.
Viewadditionaltagginginfowiththe’detail’option
Super! We have three paths now to the destination endpoint. Taking a closer look now I’m opting now to see the detailed view:
MPLS1#shomplsforwarding-table10.0.0.7detail
LocalOutgoingPrefixBytestagOutgoingNextHop
tagtagorVCorTunnelIdswitchedinterface
32Poptag10.0.0.7/320Tu7point2point
MAC/Encaps=14/18,MRU=1512,TagStack30,viaFa1/0
CA020ADC001CCA000ADC001C88470001E000
Nooutputfeatureconfigured
Per-destinationload-sharing,slots:036912
Poptag10.0.0.7/320Tu702point2point
MAC/Encaps=14/18,MRU=1512,TagStack32,viaFa1/1
CA010ADC001CCA000ADC001D884700020000
Nooutputfeatureconfigured
Per-destinationload-sharing,slots:1471013
Poptag10.0.0.7/320Tu703point2point
MAC/Encaps=14/18,MRU=1512,TagStack31,viaFa2/0
CA040ADC001CCA000ADC003888470001F000
Nooutputfeatureconfigured
Per-destinationload-sharing,slots:2581114
This view offers information about the physical interfaces used, and which slots are used in each tunnel for traffic distribution among the tunnels. Now THAT is some good stuff. We know it is working now, but we are going to go ahead and view the FIB to solidify our understanding of the relationship between the Label Forwarding Information Base and the Forwarding Information Base. The Forwarding Information Base is shown below:
MPLS1#showipcef10.0.0.7detail
10.0.0.7/32,version63,epoch0,per-destinationsharing
0packets,0bytes
taginformationset
localtag:32
via10.0.0.7,Tunnel7,0dependencies
trafficshare1
nexthop10.0.0.7,Tunnel7
validadjacency
tagrewritewithTu7,point2point,tagsimposed:30
via10.0.0.7,Tunnel702,0dependencies
trafficshare1
nexthop10.0.0.7,Tunnel702
validadjacency
tagrewritewithTu702,point2point,tagsimposed:32
via10.0.0.7,Tunnel703,0dependencies
trafficshare1
nexthop10.0.0.7,Tunnel703
validadjacency
tagrewritewithTu703,point2point,tagsimposed:31
0packets,0bytesswitchedthroughtheprefix
tmstats:external0packets,0bytes
internal0packets,0bytes
Now we view the routing table, which shows the relationship between the Forwarding Information Base and the Layer 3 Engine below:
MPLS1#showiproute10.0.0.7
Routingentryfor10.0.0.7/32
Knownvia”ospf1″,distance110,metric3,typeintraarea
Lastupdatefrom10.0.0.7onTunnel703,00:09:26ago
RoutingDescriptorBlocks:
*10.0.0.7,from10.0.0.7,00:09:26ago,viaTunnel7
Routemetricis3,trafficsharecountis1
10.0.0.7,from10.0.0.7,00:09:26ago,viaTunnel702
Routemetricis3,trafficsharecountis1
10.0.0.7,from10.0.0.7,00:09:26ago,viaTunnel703
Routemetricis3,trafficsharecountis1
And now we finally get to do here is a traceroute with the probe option set to 3, since we have 3 paths. Notice the results, and do some reflection. It’s not difficult to see and I’m not giving the answer to this away here, but keep it in mind. This topology was chosen to bring some potential issues to your attention. Check it out:
MPLS1#traceroute10.0.0.7probe3
Typeescapesequencetoabort.
Tracingtherouteto10.0.0.7
1172.16.12.2[MPLS:Label32Exp0]112msec
172.16.15.5[MPLS:Label31Exp0]96msec
172.16.13.3[MPLS:Label30Exp0]96msec
2172.16.24.4[MPLS:Label32Exp0]88msec
172.16.57.792msec
172.16.37.796msec
I hope you have enjoyed all that has been provided here. If you deal with MPLS, I’m sure you will find it useful. Thanks, and goodnight.
Filed under Internet & Online by Richard Hijinx
Multiprotocol Label Switching Part I provided a quick overview of Multiprotocol Label Switching and the strength it provides as a WAN switching service. In Part II, we are going to quickly go over some more terminology and then dive into a simple Frame Mode Multiprotocol Label Switching lab configuration. This part is going to be a little repetitive because we are going to be configuring several of these devices for Frame Mode MPLS. This is going to come in handy when we move on to more advanced labs where we delve into some pretty slick configurations offered by Multiprotocol Label Switching, such as MPLS Traffic Engineering.
To start, we will get that Multiprotocol Label Switching terminology outlined. This terminology is sourced directly out of RFC 3031, which defines the Multiprotocol Label Switching Architecture.
forwarding equivalence class – a collection of IP packets which are forwarded in the same manner (over the same path, with the same forwarding treatment)
label – a short fixed length physically contiguous identifier which is used to identify a FEC, typically of local significance.
label swap – the forwarding operation that consists of looking up an incoming label and determining the outgoing label, the encapsulation, the port, and other data handling information.
label swapping – a forwarding paradigm allowing streamlined forwarding of data by using labels to identify classes of data packets which are treated indistinguishably when forwarding.
label switched hop – the hop between two Multiprotocol Label Switched nodes, where forwarding is done using labels.
label switched path – The path through one or more Label Switch Routers at one level of the hierarchy followed by a packet in a particular forwarding equivalence class.
LSR – a Multiprotocol Label Switch node capable of forwarding native layer 3 packets.
label stack – an ordered set of labels
Multiprotocol Label Switch domain – a contiguous group of nodes that operate Multiprotocol Label Switch routing and forwarding and are also in one Routing or Administrative Domain
MPLS edge node – an Multiprotocol Label Switch node connecting a MPLS domain with a node which is outside of the domain, either because it does not run MPLS, or because it is in a different MPLS domain. Note that if a LSR has a neighboring host which is not running MPLS, that that LSR is an MPLS edge node.
Multiprotocol Label Switch egress node – an MPLS edge node in its role in handling traffic as it leaves an Multiprotocol Label Switch domain.
MPLS ingress node – an MPLS edge node in its role in handling traffic as it enters an Multiprotocol Label Switch domain.
Now that we’ve got some important terminology out of the way, let’s start off by downloading the Multiprotocol Label Switching topology and Multiprotocol Label Switching cabling and IP addressing schemes we will be working with, and then begin by prepping all our devices for the MPLS configuration portion of the lab. The first thing we have to do is get all these interfaces configured.
On MPLS1, I have three interfaces, with F1/0 connected to MPLS3, F1/1 connected to MPLS2, and F2/0 attached to MPLS5. Per the cabling scheme provided, you can see that these subnets are in 172.16.13.0/28, 172.16.12.0/28, and 172.16.15.0/28, respectively. Here’s a quick run down of the local IP addresses:
MPLS1#show ip interface brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES NVRAM administratively down down
FastEthernet1/0 172.16.13.1 YES NVRAM up up
FastEthernet1/1 172.16.12.1 YES NVRAM up up
FastEthernet2/0 172.16.15.1 YES NVRAM up up
FastEthernet2/1 unassigned YES NVRAM administratively down down
FastEthernet3/0 unassigned YES NVRAM administratively down down
FastEthernet3/1 unassigned YES NVRAM administratively down down
As shown below, the interface configuration on these is pretty easy.
MPLS1#sho run int fa1/0
Building configuration…
Current configuration : 147 bytes
!
interface FastEthernet1/0
ip address 172.16.13.1 255.255.255.240
duplex auto
speed auto
end
MPLS1#sho run int fa1/1
Building configuration…
Current configuration : 147 bytes
!
interface FastEthernet1/1
ip address 172.16.12.1 255.255.255.240
duplex auto
speed auto end
MPLS1#sho run int fa2/0
Building configuration…
Current configuration : 147 bytes
!
interface FastEthernet2/0
ip address 172.16.15.1 255.255.255.240
duplex auto
speed auto
end
Continue configuring the rest of the interfaces on the devices in the same manner. One important requirement of MPLS is that CEF be enabled, which is the default on most modern IOS releases, but enabling it is simple with the following command:
MPLS1(config)#ip cef
MPLS1(config)#^Z
MPLS1#
Cisco Express Forwarding will need to be enabled on every Multiprotocol Label Switching device. We will get more into the specifics of Multiprotocol Label Switching reliance on CEF in later labs. Right now we are just excited to get an MPLS network rocking and rolling. After we have all our interfaces configured we are going to enable an interior gateway protocol. In this case I’m choosing to use EIGRP because of its support for unequal cost load-balancing, which we are going to use in some of our more advanced MPLS labs. For the scenarios I have provided here, you can enable Enhanced Interior Gateway Routing Protocol on each MPLS device with these very simple commands:
MPLS1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
MPLS1(config)#router eigrp 100
MPLS1(config-router)#no auto-summary
MPLS1(config-router)#network 172.16.0.0
MPLS1(config-router)#^Z
MPLS1#
Once you have done that on each of your MPLS routers, let’s take a couple minutes to verify our routing tables with this command:
MPLS1#show ip route eigrp 100
172.16.0.0/28 is subnetted, 14 subnets
D 172.16.56.0 [90/30720] via 172.16.15.5, 00:00:35, FastEthernet2/0
D 172.16.57.0 [90/30720] via 172.16.15.5, 00:00:28, FastEthernet2/0
D 172.16.45.0 [90/30720] via 172.16.15.5, 00:00:38, FastEthernet2/0
D 172.16.46.0 [90/33280] via 172.16.15.5, 00:00:36, FastEthernet2/0
[90/33280] via 172.16.13.3, 00:00:36, FastEthernet1/0
[90/33280] via 172.16.12.2, 00:00:36, FastEthernet1/1
D 172.16.36.0 [90/30720] via 172.16.13.3, 00:00:32, FastEthernet1/0
D 172.16.37.0 [90/30720] via 172.16.13.3, 00:00:28, FastEthernet1/0
D 172.16.34.0 [90/30720] via 172.16.13.3, 00:00:36, FastEthernet1/0
D 172.16.24.0 [90/30720] via 172.16.12.2, 00:00:37, FastEthernet1/1
D 172.16.25.0 [90/30720] via 172.16.15.5, 00:00:38, FastEthernet2/0
[90/30720] via 172.16.12.2, 00:00:38, FastEthernet1/1
D 172.16.23.0 [90/30720] via 172.16.13.3, 00:00:37, FastEthernet1/0
[90/30720] via 172.16.12.2, 00:00:37, FastEthernet1/1
D 172.16.67.0 [90/33280] via 172.16.15.5, 00:00:32, FastEthernet2/0
[90/33280] via 172.16.13.3, 00:00:32, FastEthernet1/0
Notice there are several load-balanced paths for some of the subnets. When we get to our advanced labs, we will manipulate some of the routing metrics so that these don’t have the same FD and then enable unequal cost load balancing so we can see how Multiprotocol Label Switching interacts with Cisco Express Forwarding.
With our lab prepped and ready for action with MPLS it is the moment we have all been waiting for. It is time to get MPLS running through this network, and it is easier than you would ever believe. It is important to understand how Multiprotocol Label Switching “labels” packets. The MPLS label sits right between the layer 2 header, and the layer 3 header. With an MPLS label being 4 bytes long, we can cause Maximum Transmission Unit violations (..and consequently fragmentation) on traditional ethernet networks such as the one we are using in this lab. With that being said, we need to increase the MTU by at least 4 bytes if we are using only a single label. In MPLS stacked label environments you may want to go even further with an MTU of 1508 or even 1512. I am going to have you use 1512 so we can play with stacked labels in later labs.
The second point to ponder in this lesson is the Multiprotocol Label Switching label binding protocol we will use for label exchange. I am going to keep it simple here and just tell you we are going to use the standards-based Label Distribution Protocol (LDP), although Cisco offers the Tag Distribution Protocol (TDP) which are both functionally the same as far as I know.
These two little details are going to be important for our interface configurations. To get these interfaces talking MPLS, all we need to do from interface configuration mode on each of our interfaces:
MPLS1(config)#int fa1/0
MPLS1(config-if)#mpls label protocol ldp
MPLS1(config-if)#mpls mtu 1512
MPLS1(config-if)#mpls ip
MPLS1(config-if)#^Z
*May 4 23:12:30.687: %LDP-5-NBRCHG: LDP Neighbor 172.16.37.3:0 (2) is UP
MPLS1#
Notice here that I caught some LDP console output. The Label Distribution Protocol formed an adjacency with another Multiprotocol Label Switching router. There are several commands we can use now to verify that we’ve got Multiprotocol Label Switching working.
The first command shows the MPLS forwarding table. You’ll see the incoming label, the outgoing label(s), the destination prefix, and the next hop IP. This is a pretty self-explanatory table, with the exception of the Outgoing label entry of “Pop tag.” The is the indication of the infamous penultimate hop popping (yes that’s a real term), but the details behind it are for later discussion. Right now we’re just really exciting to see Multiprotocol Label Switching labels working in our network.
MPLS1#show mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Pop tag 172.16.23.0/28 0 Fa1/0 172.16.13.3
Pop tag 172.16.23.0/28 0 Fa1/1 172.16.12.2
17 Pop tag 172.16.24.0/28 0 Fa1/1 172.16.12.2
18 Pop tag 172.16.25.0/28 0 Fa2/0 172.16.15.5
Pop tag 172.16.25.0/28 0 Fa1/1 172.16.12.2
19 Pop tag 172.16.34.0/28 0 Fa1/0 172.16.13.3
20 Pop tag 172.16.36.0/28 0 Fa1/0 172.16.13.3
21 Pop tag 172.16.37.0/28 0 Fa1/0 172.16.13.3
22 Pop tag 172.16.45.0/28 0 Fa2/0 172.16.15.5
23 23 172.16.46.0/28 0 Fa2/0 172.16.15.5
21 172.16.46.0/28 0 Fa1/0 172.16.13.3
22 172.16.46.0/28 0 Fa1/1 172.16.12.2
24 Pop tag 172.16.56.0/28 0 Fa2/0 172.16.15.5
25 Pop tag 172.16.57.0/28 0 Fa2/0 172.16.15.5
26 24 172.16.67.0/28 0 Fa2/0 172.16.15.5
24 172.16.67.0/28 0 Fa1/0 172.16.13.3
Our second show command just shows us the local interfaces involved in Multiprotocol Label Switching operations:
MPLS1#show mpls interfaces
Interface IP Tunnel Operational
FastEthernet1/0 Yes (ldp) No Yes
FastEthernet1/1 Yes (ldp) No Yes
FastEthernet2/0 Yes (ldp) No Yes
The final command for Multiprotocol Label Switching Part 2 shows the multiprotocol label switching ip bindings. The “imp-null” is another way of seeing Penultimate Hop Popping at work. The “inuse” indicator shows that the outgoing label is isntalled in the Multiprotocol Label Switching forwarding table.
MPLS1#show mpls ip binding
172.16.12.0/28
in label: imp-null
out label: imp-null lsr: 172.16.25.2:0
out label: 17 lsr: 172.16.57.5:0
out label: 16 lsr: 172.16.37.3:0
172.16.13.0/28
in label: imp-null
out label: 16 lsr: 172.16.25.2:0
out label: 16 lsr: 172.16.57.5:0
out label: imp-null lsr: 172.16.37.3:0
172.16.15.0/28
in label: imp-null
out label: 17 lsr: 172.16.25.2:0
out label: imp-null lsr: 172.16.57.5:0
out label: 17 lsr: 172.16.37.3:0
172.16.23.0/28
in label: 16
out label: imp-null lsr: 172.16.25.2:0 inuse
out label: 19 lsr: 172.16.57.5:0
out label: imp-null lsr: 172.16.37.3:0 inuse
172.16.24.0/28
in label: 17
out label: imp-null lsr: 172.16.25.2:0 inuse
out label: 18 lsr: 172.16.57.5:0
out label: 18 lsr: 172.16.37.3:0
172.16.25.0/28
in label: 18
out label: imp-null lsr: 172.16.25.2:0 inuse
out label: imp-null lsr: 172.16.57.5:0 inuse
out label: 19 lsr: 172.16.37.3:0
172.16.34.0/28
in label: 19
out label: 18 lsr: 172.16.25.2:0
out label: 20 lsr: 172.16.57.5:0
out label: imp-null lsr: 172.16.37.3:0 inuse
172.16.36.0/28
in label: 20
out label: 19 lsr: 172.16.25.2:0
out label: 21 lsr: 172.16.57.5:0
out label: imp-null lsr: 172.16.37.3:0 inuse
172.16.37.0/28
in label: 21
out label: 20 lsr: 172.16.25.2:0
out label: 22 lsr: 172.16.57.5:0
out label: imp-null lsr: 172.16.37.3:0 inuse
172.16.45.0/28
in label: 22
out label: 21 lsr: 172.16.25.2:0
out label: imp-null lsr: 172.16.57.5:0 inuse
out label: 20 lsr: 172.16.37.3:0
172.16.46.0/28
in label: 23
out label: 22 lsr: 172.16.25.2:0 inuse
out label: 23 lsr: 172.16.57.5:0 inuse
out label: 21 lsr: 172.16.37.3:0 inuse
172.16.56.0/28
in label: 24
out label: imp-null lsr: 172.16.57.5:0 inuse
out label: 23 lsr: 172.16.25.2:0
out label: 22 lsr: 172.16.37.3:0
172.16.57.0/28
in label: 25
out label: imp-null lsr: 172.16.57.5:0 inuse
out label: 24 lsr: 172.16.25.2:0
out label: 23 lsr: 172.16.37.3:0
172.16.67.0/28
in label: 26
out label: 24 lsr: 172.16.57.5:0 inuse
out label: 25 lsr: 172.16.25.2:0
out label: 24 lsr: 172.16.37.3:0 inuse
That wraps up Multiprotocol Label Switching Part II. I look forward to seeing you in Multiprotocol Label Switching Part 3 soon.
Filed under Certification-Tests by Richard Hijinx
April 15, 2009
Cisco CCNA Exam and Certification
Taking the CCNA Exam
CCNA Certification is necessary to validate to employers that the holder has demonstrated an understanding of the foundation of networking using Cisco devices; basic routing and switching, TCP/IP, the Open Systems Interconnect model, WANs, and more. In preparing for the CCNA exam, its important that candidates are adequately prepared for the environment they will be testing in and make the most of their study time and subsequent attempts at the exam.
Since the programs inception in April of 1998, Cisco has managed to maintain the difficulty of its exams by changing the requirements every so often. This, combined with Ciscos strong policy on disclosing exam content (those found in violation of this policy can a face lifetime ban from even attempting the exam and obtaining certification), proves passing the exam to be a formidable task for even the most prepared candidate. Not all applicants will pass the exam on the first try. Often the test has required multiple attempts by professionals before achieving success. At $125 for each portion of the two-part CCNA exam (640-822 ICND1 and 640-816 ICND2) or $250 for the full program in one test (640-802 CCNA), not passing on the first attempt can prove to be very costly and frustrating. Cisco also requires a minimum of 5 calendar days before a second or subsequent attempt at passing the exam. For these reasons, those seeking this certification should go to any length to familiarize themselves with the material and how it will be presented to them before spending valuable time and money on certification.
This article will not focus on the specific material found on the test, rather the nature of questioning, some guidelines of what to expect, and some information on how to properly prepare oneself for the actual day of the examination. As stated earlier, the nature and expense of this test makes it very important to be prepared so as not to require multiple attempts before successfully completing the exam. Also, once the exam is successfully passed, the certificate holder is required every three years to either re-take the exam or upgrade their certification to one of Ciscos other levels, such as CCNP (Cisco Certified Network Professional) or CCIE (Cisco Certified Internetwork Expert).
As a candidate for CCNA certification, one is expected to have abilities in the following areas of network service using Cisco products:
Planning and design Implementation and operation Troubleshooting and technology Configuration and administration
It is expected that some months of studying and training will precede the actual exam. It is often recommended that applicants take a two-pronged approach to preparing for test day. This includes two forms of self-study: primary and secondary. Primary study is the core learning portion of the preparation process, where a foundation is built around a solid understanding of the topics to be found on the exam. This is the candidates initial learning of all topics to be mastered. It will be achieved through extensive reading, research, and whenever possible, actual lab work. Once this has been accomplished, it will be necessary to stimulate solidify these concepts in the memory. This is the secondary part of the process, and it usually necessitates some kind of randomized, birds eye view of the material learned in primary study. Most programs recommend that this type of learning be put into use some 30-60 days prior to the day of examination.
Once the candidate has adequately prepared themselves mentally, they must make arrangements with Pearson VUE or another approved testing center for a testing appointment. Once an appointment has been made, finally comes the ugly task of actually going into the testing center and taking the 90-minute (75 minutes for the ICND2) exam.
Pearson VUE, Ciscos primary test delivery partner, expects that applicants arrive at the testing center a full 30 minutes prior to the time of the test. This, as with any test, is very important. It is not only key in assuring that traffic, detours, or unclear directions do not make the applicant late to the test, but it also allows some time to relax and prepare the mind for the examination about to take place. After the time, effort, and money put into preparing for this test, it would be a waste to rush and stress the morning of the exam.
The test will be administered by a proctor, and will be timed. For this reason, it is imperative that time is managed responsibly. This in mind, however, all answers on the exam are final. The test engine will prompt the user to proceed following each question. Take time to answer each question as accurately as recollection will allow, however its important not to allow one particularly challenging question to dominate too much time. There are 50-60 questions on each exam, 90 minutes to answer them, and later questions may demand more time. Be sure to answer all questions, even when uncertain as to the correct answer. No points are removed for incorrect answers or blank answers, so its best to at least attempt to answer the question when unsure.
Keeping all these things in mind, lets look at the 7 different types of questions that will be found on the test:
Single answer multiple choice -These are multiple choice questions where there is only one correct answer. A question will be posed, and a radio button will allow the user to select the proper answer to the question.
Multiple answer multiple choice -These are multiple choice questions where there are multiple correct answers. A question will be posed, and checkboxes will allow the user to select the proper answer to the question.
Drag and Drop (DND) -A green list of options will be provided on the left side of the screen, prompting the user to drag each of these to the correct yellow category box on the right side. The items can be removed from the chosen category and rearranged before submitting a final answer using the Submit button.
Fill in the Blank -The user will fill in the correct answer to a question or complete an existing sentence, making an accurate statement.
Router Simulation -Individual real-world scenarios are given, and the user is prompted to negotiate the proper network arrangement or perform the functions necessary using a simulated hyperterminal screen.
Testlet -The user is provided with a real-world scenario, and 3 or more questions are posed with regard to the scenario given.
Simlet -This is similar to a testlet question, however each sub-question is offered in the form of a router simulation.
All that said, by the day of the test the candidate should have a pretty good idea of what to expect on the test. The important thing is that he or she has worked hard and prepared themselves sufficiently so as not to panic the day of the exam. This is not a test that requires memorization; its a test that requires the test taker to understand concepts and how to properly use the functions of the equipment. Cramming, or excessive studying immediately or the night prior to the test, will be more of a hindrance than a help in preparing for this exam. It is absolutely vital that the applicant comes to the testing center the morning of the exam with a good, clear head on their shoulders. Remembering these things will help to ensure first-attempt success, and will also prevent an awful lot of test-day anxiety that will undoubtedly bolster the final score of the test taker a great deal.
Filed under Internet & Online by CiscoKits


