Cisco CCIE CCIP CCNP CCNA Certification

8 Tips to become a relevant network engineer

2011-08-23T21:46:00.004-05:00

Over the last few years I've had the opportunity to work with many great engineers and I've also had the displeasure of working with many not so great engineers. I worked a contract at the Sprint World Headquarters in Kansas City where I was in a room with 8 to 10 extremely skilled network engineers who may or may not have been CCIEs and/or JNCIEs. These were the kind of engineers that literally spoke routing protocols as a first language, throwing around the more advanced concepts without thinking about it, much like a book worm uses big words all the time, wondering why everyone else "doesn't get it." These were the engineers who never spoke of their certifications because their extreme skill spoke for itself. Network technologies radiated from their pores and you never once questioned their judgement, their knowledge, or their certifications (if they even had any). At the same time I've had the displeasure of working with newly minted CCNAs who failed to grasp the concept behind drawing physical layer diagrams of not-so-complex networks using CDP. These were the kinds of engineers - and I use the term engineers loosely - who were quite frankly lazy. These are the kind of people who got into IT because of the promise of a big paycheck, nice cars, big fancy homes, huge salaries, never ending vacation time, and so on. These were the people who rambled on and one about how they're a CCNA and they've made the big time. They managed to get hired into a room full of contractors at Sprint and they think they are hot stuff.

It is time to set the record straight people. The economy sucks. Finding a way to pass the CCNA exam is NOT going to land you that dream job you have been searching for. You are going to get run through a technical interview, and I can tell you for fact 95% of you will fail. I have been going through resume after resume after resume for the past 3 weeks trying to find competent engineers. Many resumes looked amazing and I had high hopes of finally striking some golden talent, only to be disappointed time after time. People are CCNAs, CCNA Security, CCNPs, and on and on and on. Tell me, what study methods are people with these types of certifications using that they can't tell me on a phone interview how to create a freaking VLAN. I am extremely annoyed at the lack of talent I am finding in the majority of people I am interviewing.

And this annoyance is what you can thank for this article. My top 10 tips to becoming a relevant network engineer, with or without certification.

1. Drop the brain dumps. I know, you are in a big hurry to get certified because as soon as you get that paper you won't be able to keep track of all the interviews you will be getting. WRONG. I've get 10 telephone interview questions that will weed you out of the candidate pool faster than can hit your #1 speed dial.

2. Build your own lab. I know, it is expensive and you can't afford it. WRONG. You can't afford NOT to build a lab. When you are in my lab doing the break/fix portion of my interview process I will know almost instantly if you've logged in to live equipment. Something as simple as knowing how to work a PuTTy session when you have a console connection to racked equipment will give you away. Another dead giveaway is how clumsy you are at the CLI. Build a lab already. You aren't doing yourself any favors memorizing commands from a book.

3. Put it to use. What do I mean? I mean, when you read about a technology in your exam certification guides, or whatever it is you read to study, put it to use. Find a way to use it. Reading about spanning-tree doesn't help you "get it." It may give you ideas, but nothing solidifies concepts better than putting them to use. If you read about spanning tree, create bridging loop. How can you identify a bridging loop under pressure in production if you've never seen one? How can you have confidence in your spanning tree configurations if you've never seen all the variations of how it can be configured?

4. Get creative. When you are going through your lab exercises change stuff around, mix things up, give yourself different topologies to work with. If you do the same lab over and over and over again, you are certain to miss out on learning opportunities presented by different scenarios. No two networks are ever the same. There are common design principles and expected ways of deploying services, but I promise you, no two networks are the same. Mix it up and it will pay off big.

5. High availability. When I have my rack fired up and I am working with new technology I don't spend too much time on the "simple configurations." Don't get me wrong, I make sure I have the basics down, but if you want to REALLY learn something, you need redundancy. Building high availability lab topologies will bring a whole new set of issues to your door, and with that, you will build a whole new set of skills. I used to frequent a certification exam forum that was pretty good about keeping brain dumpers out, but every once in a while some troll would come knocking asking all the wrong questions. For example, "Why use two links?" My answer, "Why NOT use two links?" "Why NOT have redundant paths?" "I want my network to be available to the business."

6. That lead nicely into number 6. Ask the RIGHT questions. Be a contrarian at times and defend your designs. As you become more skilled you will realize more and more just how unskilled so many people actually are and with that you will come across people who are unsuccessful because they ask the wrong questions. They do this because they are lazy and they just don't get it. They don't know why they have jobs and as a result never ask the right questions, and frankly can't do the job.

7. Teach someone else how to do it and/or find a lab partner. I have to tell you, some of my strongest learning experiences have come from teaching someone else what I know (or thought I knew) and bouncing ideas off someone else. The reason this is so great is because the person you are teaching will inevitably ask questions that you are not prepared to answer in a way that will make you question yourself, and what you know. Getting an answer to the question will cause you to learn, and because you are engaged in an exchange with another human being providing constant feedback and questions, it will be that much more difficult to forget what you have learned. A great sounding board is an invaluable learning tool.

8. Figure out how it works. Always find out how it works, whether it is a PING from host A to host B on the same switch, or a routing update produced by a topology change in EIGRP, always find out how it works. When you are on a production network with things going wrong, you can't even begin to provide effective troubleshooting if you don't know how stuff works. Break things in your lab to test your thesis. Put workstation with wireshark in between two routers and watch the traffic flow. Telnet to port 80 on web server and watch what happens. Overflow the CAM table on your Catalyst and observe unicast flooding in action.

To sum it all up - don't be lazy in your studies. Doing your due diligence up front will pay huge dividends. I'm not a highly certified individual, but I outperform many highly certified individuals. I once had an extremely technical phone interview with a large company here in town who told me I gave them the best presentation of routing protocol knowledge they had ever seen. The certification is not the reward folks. It is the journey that pays the dividends. The certification is just a piece of paper. Don't believe me? Ask the 14 "network engineers" who couldn't answer "How do you create a VLAN on a Cisco Catalyst 2960?"

Simplify Cisco ASA access-list Administration with Object-Groups

2011-05-26T23:36:00.003-05:00

Any network administrator or network engineer is often tasked with auditing access-lists and modifying them according to business requirements that are often quite volatile. With regulatory organizations bearing down and compliance with those regulations become more and more difficult the amount of access-list auditing, modification, and deployment can quickly get out of control. Even with all the regulations to deal with access-list maintenance doesn't have to be the nightmare many network administrators and network engineers have come to know. This is where object-groups come in to play. While they are not new, being introduced in PIX code 6.2, many veteran engineers have just not caught on as they are set in their ways.

In the Cisco ASA, an object-group allows you to group hosts, protocols, networks, and services, into logical units that you can use to build access-lists that reference every object within the object-groups that are defined and placed within the ACL. Using strong object-group methodologies you can create an access-list that is 100 lines long in your running-config but is several hundred, or even thousands, of lines long once the object-groups are expanded to the full access-list - the access list as it would appear without the use of object-groups.

Let's start by defining a few different object groups.

Using an object-group of the network type you can groups hosts and/or networks into one logical group. Here is an example:

object-group network EMAIL-SERVERS
network-object host 1.2.3.4
network-object 5.0.0.0 255.255.0.0

object-group network INSIDE_SUBNETS
network 10.20.0.0 255.255.0.0
network 10.30.0.0 255.255.0.0

Using an object-group of the protocol type you can group different protocols into one logical group. Here is an example I occasionally use:

object-group protocol TCP-UDP
protocol-object tcp
protocol-object udp

Using an object-group of the service type you can group different service ports into one logical group of services. Here is a good example:

object-group service EMAIL-SERVICES
port-object eq 25
port-object eq 110
port-object eq 143
port-object eq 465
port-object eq 587
port-object eq 993
port-object eq 995

Now that we have a few object-groups defined we can demonstrate the configuration of a couple access-lists. Here is a couple examples:

access-list Outside_access_in extended permit tcp any object-group EMAIL-SERVERS object-group EMAIL-SERVICES

access-list Inside_access_in extended permit object-group TCP-UDP object-group INSIDE-SUBNETS any eq 53

The above configurations demonstrate the way the access-list is defined, and also the way it will be shown in the running-config and startup-config. Now that you have seen how these access-lists are defined it is time to see what the expanded view looks like so you can realize the full potential of utilizing object-groups in your access-lists.

#show access-list Outside_access_in
access-list Outside_access_in extended permit tcp any object-group EMAIL-SERVERS object-group EMAIL-SERVICES
access-list Outside_access_in line 1 extended permit tcp any host 1.2.3.4 eq 25
access-list Outside_access_in line 1 extended permit tcp any 5.0.0.0 255.255.0.0 eq 25
access-list Outside_access_in line 1 extended permit tcp any host 1.2.3.4 eq 110
access-list Outside_access_in line 1 extended permit tcp any 5.0.0.0 255.255.0.0 eq 110
access-list Outside_access_in line 1 extended permit tcp any host 1.2.3.4 eq 143
access-list Outside_access_in line 1 extended permit tcp any 5.0.0.0 255.255.0.0 eq 143
access-list Outside_access_in line 1 extended permit tcp any host 1.2.3.4 eq 465
access-list Outside_access_in line 1 extended permit tcp any 5.0.0.0 255.255.0.0 eq 465
access-list Outside_access_in line 1 extended permit tcp any host 1.2.3.4 eq 587
access-list Outside_access_in line 1 extended permit tcp any 5.0.0.0 255.255.0.0 eq 587
access-list Outside_access_in line 1 extended permit tcp any host 1.2.3.4 eq 993
access-list Outside_access_in line 1 extended permit tcp any 5.0.0.0 255.255.0.0 eq 993
access-list Outside_access_in line 1 extended permit tcp any host 1.2.3.4 eq 995
access-list Outside_access_in line 1 extended permit tcp any 5.0.0.0 255.255.0.0 eq 995

#show access-list Inside_access_in
access-list Inside_access_in extended permit object-group TCP-UDP object-group INSIDE-SUBNETS any eq 53
access-list Inside_access_in line 1 extended permit tcp 10.20.0.0 255.255.0.0 any eq 53
access-list Inside_access_in line 1 extended permit udp 10.20.0.0 255.255.0.0 any eq 53
access-list Inside_access_in line 1 extended permit tcp 10.30.0.0 255.255.0.0 any eq 53
access-list Inside_access_in line 1 extended permit udp 10.30.0.0 255.255.0.0 any eq 53

As you can see, the object groups easily allow you to create access-lists that can scale with your changing business needs. If we now decide to deploy a new email server, all we have to do is add that host, or subnet, to the appropriate object group and the rest of the work will be performed by the Cisco ASA. The access-list will automatically be expanded to include the new hosts, all with one simple addition.

That about sums it up.

APNIC Stage 3 IPv4 Exhaustion

2011-04-19T23:47:00.003-05:00

APNIC has reached IPv4 Stage 3 exhaustion. Stage 3 IPv4 exhaustion at APNIC means that they have reached their final /8 IPv4 allocation. According to APNIC, each account holder can now receive only one /22 IPv4 allocation and only if they meet the current IPv4 allocation guidelines. APNIC is the first of the five Regional Internet Registries to reach their final /8 IPv4 allocation.

Have you been planning for IPv6?

Bogons Part III - IPv4 is exhausted

2011-02-03T23:04:00.004-06:00

So, IANA allocated two more /8 IP blocks out of the IPv4 free pool a few days ago, leaving only five /8 IP blocks remaining in the IPv4 free pool unallocated. That being said, according to global allocation policy one of the remaining five blocks must be allocated to each of the RIRs. That day has come folks, leaving the IPv4 free pool EMPTY. That's right, there are NO remaining /8s in the IPv4 free pool. IPv4 address management is now going to come down to those IP blocks that are left to be distributed by the five RIRs: ARIN, APNIC, LACNIC, AfriNIC, and RIPE.

This day has been coming for a LONG time now, yet when trying to procure IPv6 services, the services are scarce or incomplete. I wonder when ISPs are going to start paying attention to the service offerings their customers are requesting.

Anyway, for those of you looking for a decent BOGON filter, your filters should now look like this aggregated list:

0.0.0.0/8 <- RFC 1122
10.0.0.0/8 <- RFC 1918
127.0.0.0/8 <- RFC 1122
169.254.0.0/16 <- RFC 3927
172.16.0.0/12 <- RFC 1918
192.0.0.0/24 <- RFC 5736
192.0.2.0/24 <- RFC 5737
192.168.0.0/16 <- RFC 1918
198.18.0.0/15 <- RFC 2544
198.51.100.0/24 <- RFC 5737
203.0.113.0/24 <- RFC 5737
224.0.0.0/3 <- RFC 3171 and RFC 1112

If anyone is having trouble denying 224.0.0.0/3 because your IOS software won't take it, check out the ip multicast boundary interface configuration option. ;)

BOGONs Part II

2010-12-04T00:53:00.006-06:00

IANA has allocated several new blocks of IPv4 space over the last few months. Rather than provide you with individual updates I'm going to provide an aggregated list of IP space you should be filtering at the ingress points in your network. Recall from the previous article that BOGON filtering filters traffic originating from IP space that should NOT be seen on the internet. The aggregated list is below:

0.0.0.0/8 <- RFC 1122
10.0.0.0/8 <- RFC 1918
39.0.0.0/8 <- UNALLOCATED
102.0.0.0/7 <- UNALLOCATED
104.0.0.0/8 <- UNALLOCATED
106.0.0.0/8 <- UNALLOCATED
127.0.0.0/8 <- RFC 1122
169.254.0.0/16 <- RFC 3927
172.16.0.0/12 <- RFC 1918
179.0.0.0/8 <- UNALLOCATED
185.0.0.0/8 <- UNALLOCATED
192.0.0.0/24 <- RFC 5736
192.0.2.0/24 <- RFC 5737
192.168.0.0/16 <- RFC 1918
198.18.0.0/15 <- RFC 2544
198.51.100.0/24 <- RFC 5737
203.0.113.0/24 <- RFC 5737
224.0.0.0/3 <- RFC 3171 and RFC 1112

Make sure you update your BOGON filters on a regular basis as they regularly change. It is important to note that their are only SEVEN /8 allocations remaining. This means only TWO more /8 allocations will be handed out before the remaining FIVE /8 allocations will be allocated to each of the FIVE Regional Internet Registries according to global allocation policy. What this means is that IPv4 exhaustion with IANA will be here VERY VERY soon. I hope you all have been planning for IPv6. :)

New network allocations from IANA - Update your BOGON Filters

2010-01-19T14:13:00.004-06:00

For all you network administrators and network engineers out there, it is time to update your Bogon filters to allow for IANA's recent IP address allocations. IANA allocated blocks 1.0.0.0/8 and 27.0.0.0/8 and placed in reservation 198.51.100.0/24 and 203.0.113.0/24. For those of you who don't know what I am talking about, a BOGON is an IP packet that "claims" to be from a portion of the IP address space that has not been allocated by IANA for public use. Such packets are often the result of misconfigurations of network equipment, or sometimes even used intentionally in various types of internet based attacks. There are a couple ways to filter for bogon traffic entering and leaving your network. The first way involves the creation of ACLs applied on your border router's ingress and egress interfaces. The second way is a bit more elaborate and automated but requires a little more technical skill and trust and this is by establishing a BGP session with organizations such as Team Cymru such that you receive routes from them that black hole bogon traffic. For more information visit Team Cymru and protect your network from this illegitimate traffic.

Multi-Site MPLS VPNs

2009-11-20T00:21:00.002-06:00

This is just a quick blurb to alert you of the upcoming plans. In this next article or two we are going to tackle MPLS VPNs, VPN Routing and Forwarding, and MP-BGP. Now is the time to go back over the last few articles introducing you to MPLS, Frame-Mode MPLS Configuration, and MPLS Traffic Engineering. Stay tuned for some extremely efficient and extremely powerful VPN solutions that scale. You won't be disappointed.

Multiprotocol Label Switching (MPLS) Traffic Engineering (TE)

2009-05-21T18:04:00.005-05:00

In this MPLS article we are going to look at MPLS Traffic Engineering. Before we get too far into this I want to point out that MPLS traffic engineering is not supported by all routing protocols. If you plan on deploying MPLS traffic engineering you are going to be limited to using OSPF, or ISIS. That being said, we have to depart from the routing protocol implementation used in MPLS part II, which was mistakenly EIGRP.

Let's go ahead and jump right in, but be sure you have grabbed the MPLS Lab Topology and IP Address Scheme. If you have been following through from MPLS Parts I and II, you will want to modify your routing protocol to be OSPF, as that is what will be demonstrated in this article. I won't be going over the details of OSPF configuration here, as they are quite simple. The 2nd change we are going to make to all the routers in our MPLS topology is the addition of Loopback addresses in order to support consistent OSPF router-id configuration and also 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

Be sure to advertise these addresses via OSPF, as they will need to be globally routable for the tunnels that we are creating, and to support future MPLS labs as they become available. Now that all that is done, we are going to begin the configuration of MPLS Traffic Engineering. As stated in MPLS Part II, you will need to make sure Cisco Express Forwarding - CEF is 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 MPLS device participating in MPLS Traffic Engineering you will need to enable MPLS 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 three 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 going to do the same thing on MPLS7. The relevant portion of the running config of MPLS7 is shown below:


ip explicit-path name GCA enable
 next-address 172.16.37.3
 next-address 172.16.13.3
 next-address 172.16.13.1
 next-address 10.0.0.1
!
ip explicit-path name GFDBA enable
 next-address 172.16.67.6
 next-address 172.16.46.6
 next-address 172.16.46.4
 next-address 172.16.24.4
 next-address 172.16.24.2
 next-address 172.16.12.2
 next-address 172.16.12.1
 next-address 10.0.0.1
!
ip explicit-path name GEA enable
 next-address 172.16.57.5
 next-address 172.16.15.5
 next-address 172.16.15.1
 next-address 10.0.0.1

Ok. So far we have enabled MPLS Traffic Engineering support for all of our devices. We have configured OSPF support for MPLS 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 MPLS 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 is the running configuration of the tunnel interfaces created on MPLS7, since that is where the endpoint of the tunnel is terminated:


interface Tunnel1
 ip unnumbered Loopback0
 tunnel destination 10.0.0.1
 tunnel mode mpls traffic-eng
 tunnel mpls traffic-eng priority 7 7
 tunnel mpls traffic-eng bandwidth  100
 tunnel mpls traffic-eng path-option 1 explicit name GCA
 tunnel mpls traffic-eng load-share 10
 no routing dynamic
!
interface Tunnel102
 ip unnumbered Loopback0
 tunnel destination 10.0.0.1
 tunnel mode mpls traffic-eng
 tunnel mpls traffic-eng priority 7 7
 tunnel mpls traffic-eng bandwidth  100
 tunnel mpls traffic-eng path-option 1 explicit name GFDBA
 tunnel mpls traffic-eng load-share 10
 no routing dynamic
!
interface Tunnel103
 ip unnumbered Loopback0
 tunnel destination 10.0.0.1
 tunnel mode mpls traffic-eng
 tunnel mpls traffic-eng priority 7 7
 tunnel mpls traffic-eng bandwidth  100
 tunnel mpls traffic-eng path-option 1 explicit name GEA
 tunnel mpls traffic-eng load-share 10
 no routing dynamic

So now we move on to verifying our tunnels have come up as we expected. We do that with the following command:

MPLS1#show mpls traffic-eng tunnels brief


Signalling Summary:
    LSP Tunnels Process:            running
    RSVP Process:                   running
    Forwarding:                     enabled
    Periodic reoptimization:        every 3600 seconds, next in 125 seconds
    Periodic auto-bw collection:    disabled
TUNNEL NAME                      DESTINATION      UP IF     DOWN IF   STATE/PROT
MPLS1_t7                         10.0.0.7         -         Fa1/0     up/up
MPLS1_t702                       10.0.0.7         -         Fa1/1     up/up
MPLS1_t703                       10.0.0.7         -         Fa2/0     up/up
MPLS7_t1                         10.0.0.1         Fa1/0     -         up/up
MPLS7_t102                       10.0.0.1         Fa1/1     -         up/up
MPLS7_t103                       10.0.0.1         Fa2/0     -         up/up
Displayed 3 (of 3) heads, 0 (of 0) midpoints, 3 (of 3) tails

It looks like all THREE of our tunnels are up. Now is the time I throw a small little wrench into the situation. We'll start by looking at the MPLS Forwarding Table, also known as the Label Forwarding Information Base or LFIB for the tunnel's destination endpoint. This is shown below:

MPLS1#sho mpls forwarding-table 10.0.0.7


Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
32     32          10.0.0.7/32       0          Fa2/0      172.16.15.5
       32          10.0.0.7/32       0          Fa1/0      172.16.13.3

What? Where is the third tunnel path? Well, since the LFIB relies on the FIB, let's look at the FIB. Again, this is below:

MPLS1#show ip cef 10.0.0.7 detail


10.0.0.7/32, version 58, epoch 0, per-destination sharing
0 packets, 0 bytes
  tag information set
    local tag: 32
  via 172.16.15.5, FastEthernet2/0, 0 dependencies
    traffic share 1
    next hop 172.16.15.5, FastEthernet2/0
    valid adjacency
    tag rewrite with Fa2/0, 172.16.15.5, tags imposed: {32}
  via 172.16.13.3, FastEthernet1/0, 0 dependencies
    traffic share 1
    next hop 172.16.13.3, FastEthernet1/0
    valid adjacency
    tag rewrite with Fa1/0, 172.16.13.3, tags imposed: {32}
  0 packets, 0 bytes switched through the prefix
  tmstats: external 0 packets, 0 bytes
           internal 0 packets, 0 bytes

Ok. That does it. 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#show ip route 10.0.0.7


Routing entry for 10.0.0.7/32
  Known via "ospf 1", distance 110, metric 3, type intra area
  Last update from 172.16.15.5 on FastEthernet2/0, 00:22:54 ago
  Routing Descriptor Blocks:
  * 172.16.15.5, from 10.0.0.7, 00:22:54 ago, via FastEthernet2/0
      Route metric is 3, traffic share count is 1
    172.16.13.3, from 10.0.0.7, 00:22:54 ago, via FastEthernet1/0
      Route metric is 3, traffic share count is 1

Well, shux, that didn't do me much good, other than to demonstrate the dependence of the LFIB on the FIB, and the FIB 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#

NNOOWW let's verify our configurations as we did earlier. Again, let's start by viewing the LFIB:

MPLS1#sho mpls forwarding-table 10.0.0.7


Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
32     Pop tag [T] 10.0.0.7/32       0          Tu7        point2point
       Pop tag [T] 10.0.0.7/32       0          Tu702      point2point
       Pop tag [T] 10.0.0.7/32       0          Tu703      point2point

[T]     Forwarding through a TSP tunnel.
        View additional tagging info with the 'detail' option

Awesome! We have three paths now to the destination endpoint. To take a closer look, I'm opting now to see the detailed view:

MPLS1#sho mpls forwarding-table 10.0.0.7 detail


Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
32     Pop tag     10.0.0.7/32       0          Tu7        point2point
        MAC/Encaps=14/18, MRU=1512, Tag Stack{30}, via Fa1/0
        CA020ADC001CCA000ADC001C8847 0001E000
        No output feature configured
    Per-destination load-sharing, slots: 0 3 6 9 12
       Pop tag     10.0.0.7/32       0          Tu702      point2point
        MAC/Encaps=14/18, MRU=1512, Tag Stack{32}, via Fa1/1
        CA010ADC001CCA000ADC001D8847 00020000
        No output feature configured
    Per-destination load-sharing, slots: 1 4 7 10 13
       Pop tag     10.0.0.7/32       0          Tu703      point2point
        MAC/Encaps=14/18, MRU=1512, Tag Stack{31}, via Fa2/0
        CA040ADC001CCA000ADC00388847 0001F000
        No output feature configured
    Per-destination load-sharing, slots: 2 5 8 11 14

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 LFIB and the FIB. The FIB is shown below:

MPLS1#show ip cef 10.0.0.7 detail


10.0.0.7/32, version 63, epoch 0, per-destination sharing
0 packets, 0 bytes
  tag information set
    local tag: 32
  via 10.0.0.7, Tunnel7, 0 dependencies
    traffic share 1
    next hop 10.0.0.7, Tunnel7
    valid adjacency
    tag rewrite with Tu7, point2point, tags imposed: {30}
  via 10.0.0.7, Tunnel702, 0 dependencies
    traffic share 1
    next hop 10.0.0.7, Tunnel702
    valid adjacency
    tag rewrite with Tu702, point2point, tags imposed: {32}
  via 10.0.0.7, Tunnel703, 0 dependencies
    traffic share 1
    next hop 10.0.0.7, Tunnel703
    valid adjacency
    tag rewrite with Tu703, point2point, tags imposed: {31}
  0 packets, 0 bytes switched through the prefix
  tmstats: external 0 packets, 0 bytes
           internal 0 packets, 0 bytes

And finally we view the routing table, which shows the relationship between the FIB and the Layer 3 Engine below:

MPLS1#show ip route 10.0.0.7


Routing entry for 10.0.0.7/32
  Known via "ospf 1", distance 110, metric 3, type intra area
  Last update from 10.0.0.7 on Tunnel703, 00:09:26 ago
  Routing Descriptor Blocks:
  * 10.0.0.7, from 10.0.0.7, 00:09:26 ago, via Tunnel7
      Route metric is 3, traffic share count is 1
    10.0.0.7, from 10.0.0.7, 00:09:26 ago, via Tunnel702
      Route metric is 3, traffic share count is 1
    10.0.0.7, from 10.0.0.7, 00:09:26 ago, via Tunnel703
      Route metric is 3, traffic share count is 1

The final thing we are going 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. I'm not giving the answer to this away here, but keep it in mind. This topology was chosen to bring different potential issues to your attention. Check it out:

MPLS1#traceroute 10.0.0.7 probe 3


Type escape sequence to abort.
Tracing the route to 10.0.0.7

  1 172.16.12.2 [MPLS: Label 32 Exp 0] 112 msec
    172.16.15.5 [MPLS: Label 31 Exp 0] 96 msec
    172.16.13.3 [MPLS: Label 30 Exp 0] 96 msec
  2 172.16.24.4 [MPLS: Label 32 Exp 0] 88 msec
    172.16.57.7 92 msec
    172.16.37.7 96 msec

I hope you've enjoyed all that has been provided here. If you deal with MPLS, I'm sure you will find it useful. Thanks, and goodnight.

Intro to Cisco Multi Layer Switching and Cisco Express Forwarding

2009-05-15T22:52:00.013-05:00

This article is intended for those new to Cisco Express Forwarding (CEF) and its impact on the way Multilayer Switching (MLS) is done in Cisco hardware. Of course, this article can also serve as a review for those familiar with the concepts but are looking for a refresher. In this first article we are going to go over the components that make up this switching architecture followed by some fundamental examples to illustrate these components and concepts at work. Before we get started be sure to download the topology we are going to be using in the lab examples for clarity.

Modern Catalyst Multilayer switches utilize CEF-based MLS. The terminology and architecture of this switching model can be tough to understand at first, but trust me, it really isn't that difficult to grasp after you start working with it.

There are two distinguished functions provided by a CEF-based Multilayer Switch. The first function is building routing information. This routing information is built by the Layer 3 engine within the control plane. The second function provided is hardware switching of packets. Hardware switching of packets is done by the Layer 3 Forwarding Engine within the data plane. The data plane is where CEF works its magic. The control plane is where layer 3 decisions are made, when those layer 3 packets can NOT be switched in hardware.

Since CEFs magic is provided in the data plane, we will start with it. It is the most fun anyway. The Layer 3 Forwarding Engine within the data plane has two components of its own.

The first component is the CEF Forwarding Information Base, and the second is the CEF Adjacency table. The CEF Forwarding Information Base (FIB) is basically just a reformatted routing table ordered such that the most specific routes are found first. The FIB contains next hop information for each prefix. The routing and next-hop information is built in software in the control plane, and then passed to the Layer 3 forwarding engine and placed in the FIB. I can't stress enough how important it is to understand that this is basically a reordered routing table with some additional entries in it. When a packet enters the switch, the switch consults the FIB and finds the longest match prefix and obtains the next hop address. I know this doesn't sound like magic yet, but stay with me, there is more and this stuff is slick. This stuff is why Cisco rules.

The second component, the adjacency table, contains and maintains layer 2 addresses for every entry in the FIB. This table is built the same way the FIB is built. It is built from the ARP table that is built with the Layer 3 engine in the control plane and then passed to the Layer 3 Forwarding Engine and placed in the CEF Adjacency table. If you know how packets are encapsulated and rewritten as they make their way across a layer 3 network, you are probably beginning to develop an idea of what is going to happen with the adjacency table.

Since the FIB and Adjacency tables are both handled in hardware, we're beginning to see how CEF can dramatically improve the performance of layer 3 forwarding operations. It copies the work the Layer 3 Engine does in software, and the Layer 3 Forwarding Engine uses it to make multilayer switching decisions in hardware. Between the FIB having next hop layer 3 information, and the adjacency table having both the layer 3 and layer 2 information, CEF has at its disposal everything it needs to forward packets without consulting a routing table running in software, and without the need to do an ARP for layer 2 header rewrite. It is all in hardware and it all happens at line speed. Don't you love it when tidbits of information all come together? I sure do.

Now, let's take a look at two scenarios to see the paths packets take through a CEF-enabled multilayer switch. In scenario 1, we have a valid FIB entry and associated adjacency table entry. A packet comes in the ingress interface, the FIB is consulted and an entry is found. The FIB is matched on the longest prefix. The layer 2 information is retrieved from the adjacency table and the packet is then forwarded through the packet rewrite engine, which rewrites the appropriate packet and frame header information at line speed and sends the packet out the egress interface. Notice that no ARP requests are made, no software based processing is performed, and frame information is written in hardware.

In scenario 2, a packet comes ingress on an interface, the FIB is consulted and is not able to be CEF switched because of one of several different reasons. At this point the packet is punted to the Layer 3 engine for further processing. We aren't going to cover all the scenarios in which a CEF Punt occurs here. We'll save those for Part II.

It should be apparent, but it is worth mentioning here for clarity. When changes happen in the routing and ARP tables that are maintained by the Layer 3 Engine, those changes are automatically propogated to the Layer 3 Forwarding Engine. This updates the FIB and the Adjacency tables instantaneously.

Now that ALL of that is out of the way, let's start looking at the relationship between the routing table, arp table, the cef fib table, and the cef adjacency table. Let's start by having a look at the IP addresses of the connected interfaces of the two devices used in these demonstrations.

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

Loopback0                  10.0.0.1        YES NVRAM  up                    up

Tunnel7                    10.0.0.1        YES TFTP   up                    down

Tunnel702                  10.0.0.1        YES TFTP   up                    down

Tunnel703                  10.0.0.1        YES TFTP   up                    down

MPLS2#show ip interface brief

Interface                  IP-Address      OK? Method Status                Protocol

FastEthernet0/0            unassigned      YES NVRAM  administratively down down

FastEthernet1/0            172.16.12.2     YES NVRAM  up                    up

FastEthernet1/1            172.16.23.2     YES NVRAM  up                    up

FastEthernet2/0            172.16.24.2     YES NVRAM  up                    up

FastEthernet2/1            172.16.25.2     YES NVRAM  up                    up

FastEthernet3/0            unassigned      YES NVRAM  administratively down down

FastEthernet3/1            unassigned      YES NVRAM  administratively down down

Loopback0                  10.0.0.2        YES NVRAM  up                    up

Now we are going to look at the routing table on MPLS1:

MPLS1#show ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     172.16.0.0/28 is subnetted, 6 subnets

O       172.16.24.0 [110/2] via 172.16.12.2, 01:12:32, FastEthernet1/1

O       172.16.25.0 [110/2] via 172.16.12.2, 01:12:32, FastEthernet1/1

O       172.16.23.0 [110/2] via 172.16.12.2, 01:12:32, FastEthernet1/1

C       172.16.12.0 is directly connected, FastEthernet1/1

C       172.16.13.0 is directly connected, FastEthernet1/0

C       172.16.15.0 is directly connected, FastEthernet2/0

     10.0.0.0/32 is subnetted, 2 subnets

O       10.0.0.2 [110/2] via 172.16.12.2, 01:12:32, FastEthernet1/1

C       10.0.0.1 is directly connected, Loopback0

...And now the FIB on MPLS1. Take note of the similarities and in particular the next hop addresses.

MPLS1#show ip cef

Prefix              Next Hop             Interface

0.0.0.0/0           drop                 Null0 (default route handler entry)

0.0.0.0/8           drop

0.0.0.0/32          receive

10.0.0.1/32         receive

10.0.0.2/32         172.16.12.2          FastEthernet1/1

127.0.0.0/8         drop

172.16.12.0/28      attached             FastEthernet1/1

172.16.12.0/32      receive

172.16.12.1/32      receive

172.16.12.2/32      172.16.12.2          FastEthernet1/1

172.16.12.15/32     receive

172.16.13.0/28      attached             FastEthernet1/0

172.16.13.0/32      receive

172.16.13.1/32      receive

172.16.13.15/32     receive

172.16.15.0/28      attached             FastEthernet2/0

172.16.15.0/32      receive

172.16.15.1/32      receive

172.16.15.15/32     receive

172.16.23.0/28      172.16.12.2          FastEthernet1/1

172.16.24.0/28      172.16.12.2          FastEthernet1/1

172.16.25.0/28      172.16.12.2          FastEthernet1/1

224.0.0.0/4         drop

224.0.0.0/24        receive

240.0.0.0/4         drop

255.255.255.255/32  receive

Now we are going to look at the ARP table on MPLS1..followed by the CEF Adjacency table.

MPLS1#show ip arp

Protocol  Address          Age (min)  Hardware Addr   Type   Interface

Internet  172.16.13.1             -   ca00.0bd0.001c  ARPA   FastEthernet1/0

Internet  172.16.12.1             -   ca00.0bd0.001d  ARPA   FastEthernet1/1

Internet  172.16.12.2            73   ca01.0bd0.001c  ARPA   FastEthernet1/1

Internet  172.16.15.1             -   ca00.0bd0.0038  ARPA   FastEthernet2/0

MPLS1#show adjacency detail

Protocol Interface                 Address

TAG      FastEthernet1/1           172.16.12.2(7)

                                   0 packets, 0 bytes

                                   CA010BD0001C

                                   CA000BD0001D8847

                                   TFIB       02:48:53

                                   Epoch: 0

IP       FastEthernet1/1           172.16.12.2(17)

                                   0 packets, 0 bytes

                                   CA010BD0001C

                                   CA000BD0001D0800

                                   ARP        02:48:53

                                   Epoch: 0

The correlations here should all be apparent. Notice the last 4 digits on the line under the bolded MAC addresses. These are ethertype codes. 8847 is MPLS-IP. 0800 is Ethernet.

That about brings Cisco Express Forwarding Part I to a conclusion. That should provide you with a foundational knowledge of what CEF does and how it works. There are quite a few more details to be covered in later articles. Right now I just to get this introduction out there because we will be needing it for MPLS Part III.

Multiprotocol Label Switching Part II - Frame Mode MPLS Configuration

2009-05-04T21:25:00.024-05:00

Multiprotocol Label Switching Part I provided a quick overview of MPLS 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 MPLS 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 MPLS, such as MPLS Traffic Engineering.

First off, let's get the nitty gritty terminology out of the way. This terminology is directly out of RFC 3031, which defines the MPLS Architecture.

forwarding equivalence class - a group of IP packets which are forwarded in the same manner (e.g., over the same path, with the same forwarding treatment)

label - a short fixed length physically contiguous identifier which is used to identify a FEC, usually of local significance.

label swap - the basic forwarding operation consisting of looking up an incoming label to determine the outgoing label, encapsulation, 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 MPLS nodes, on which forwarding is done using labels.

label switched path - The path through one or more LSRs at one level of the hierarchy followed by a packets in a particular FEC.

label switching router - an MPLS node which is capable of forwarding native L3 packets

label stack - an ordered set of labels

MPLS domain - a contiguous set of nodes which operate MPLS routing and forwarding and which are also in one Routing or Administrative Domain

MPLS edge node - an MPLS node that connects an MPLS domain with a node which is outside of the domain, either because it does not run MPLS, and/or because it is in a different domain. Note that if an LSR has a neighboring host which is not running MPLS, that that LSR is an MPLS edge node.

MPLS egress node - an MPLS edge node in its role in handling traffic as it leaves an MPLS domain.

MPLS ingress node - an MPLS edge node in its role in handling traffic as it enters an MPLS domain.

Now, that we've got some important terminology out of the way, let's start off by downloading the lab topology and cabling and IP addressing schemes we will be working with, and then begin by prepping all our devices for the MPLS portion of the lab. The first thing we have to do is get all these interfaces configured.

On MPLS1, I have three interfaces, with one F1/0 connected to MPLS3, F1/1 connected to MPLS2, and F2/0 connected 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 you can see below, the interface configuration on these is simple.

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

We need to continue configuring the interfaces on the remaining devices in the same manner. One of the requirements of MPLS is that Cisco Express Forwarding (CEF) be enabled, which it should be enabled by default on most modern IOS releases, but enabling it is simple enough with the following command:

MPLS1(config)#ip cef

MPLS1(config)#^Z

MPLS1#

Cisco Express Forwarding will need to be enabled on every MPLS device. We will get more into the specifics of MPLS reliance on CEF in later labs/lessons. 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 IGP. In this case I'm choosing to use EIGRP becuase 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 EIGRP 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 devices, 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

Now that we have prepped our lab for 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. The first thing we need to consider with MPLS is the way in which it "labels" packets. The MPLS label lies right between the layer 2 frame header, and the layer 3 packet header. With an MPLS label being 4 bytes long, it is possible that we can cause MTU violations (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 bump the MTU even further to 1508 or 1512. I'm going to go ahead and have you use 1512 so we can play with stacked labels in later labs.

The 2nd thing to consider in this lab is the MPLS label binding protocol we are going to 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 is functionally equivalent as far as I know.

Armed with those two little pieces of knowledge we are ready to get these interfaces talking MPLS. To make this happen, 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#

You'll notice here that I caught some LDP console output. The LDP protocol formed an adjacency with another MPLS device. There are several commands we can use now to verify that we've go MPLS working. Since this post is starting to get rather lengthy I'm just going to rattle them off real quick, and more detail can follow in Part III.

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.

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

The second command simply shows the local interfaces involved in MPLS 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 third and final command for MPLS Part II shows the mpls ip bindings. The "imp-null" is another instance of Penultimate Hop Popping at work. The "inuse" indicator shows that the outgoing label is in use and it is isntalled in the MPLS 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

I had hoped to provide more details in this lab, but I'm getting tired, so I look forward to seeing you in MPLS Part III soon.

Introduction to Multiprotocol Label Switching

2009-04-30T22:42:00.006-05:00

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

2009-04-27T20:14:00.014-05:00

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.

Cisco CCIE Certification here I come!!

2008-12-24T22:51:00.004-06:00

Welcome to my blog. This blog will detail my journey toward the prestigous and sought after Cisco CCIE Certification. For those interesting in joining me, this journey will not be for the faint of heart. I have a history of over-preparing for exams. I tend to lab and lab and then lab some more - creating any relevant topology I can dream up and then implementing it with my new found knowledge. If your wish is to become an absolute expert in Cisco technologies, then this is the place for you. If your wish is to find answers to Cisco exams, then I suggest you look elsewhere. True engineers like to know how and why things work, and this blog will embrace that position and push you to your limits. Now, grab some coffee and get ready to rock because I will be including detailed labs and explanations, as well as tips and "gotchas." In addition to Cisco CCIE Certification topics, I will outline other technical discussions as I see fit.