ccnp

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.

About the Author:

Filed under Internet & Online by Richard Hijinx

Permalink Print

May 11, 2009

Frame Mode Multiprotocol Label Switching – MPLS Part 2


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.

About the Author:

Filed under Certification-Tests by Richard Hijinx

Permalink Print

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.

About the Author:

Filed under Internet & Online by CiscoKits

Permalink Print