Buy a Bundle, Save a Bundle! This weekend IPexpert has 3 incredible deals for CCIE R&S, CCIE Voice and CCIE Security Candidates! We have bundled some of our most requested materials together and are offering them at a significantly reduced price. This package allows students to get started on their CCIE journey and build a solid knowledge base of the complex technologies that you will encounter on the CCIE Lab.
Read Full Entry »

This is an excerpt from the next book in IPexpert’s very popular Protocol Operation and Troubleshooting Series. This volume deals with MPLS by starting at the very foundation and working all the way up to advanced concepts. This section taken from the very first chapter should offer some eye opening insights into how MPLS operates and how to isolate and repair failures affecting its operation…

[Taken from Chapter One: Introduction to MPLS]

The creation of the virtual routing and forwarding instances is the first step in establishing the overall MPLS architecture at the command line interface. This becomes the first component we as administrators have authoritative control over, and defines how an MPLS backbone will build label forwarding tables and actually forward labeled packets. The VRF instances we define on each device directly affect the following MPLS components:

Forward Equivalence Class

A forwarding equivalency class (FEC) is how a group of IP packets that share a specific label will be forwarded. However, it should be pointed out that a more accurate term than “packets” would be IP prefixes or routes due to the fact that these elements can and will more-often-than-not share a particular label. Thus they will be treated equivalent in forwarding. This is not to say that a given FEC cannot reflect treatment for a specific prefix verses a group of prefixes. In fact, a FEC can be as generic or as granular as we as administrators need it to be.

Control Plane

With MPLS, routers determine how to forward a given FEC or labeled packet in the identical fashion employed traditionally to forward IP packets via standard ip routing but the decision is based on the incoming label of a particular packet. This process involves a consultation of the forwarding table to determine the outbound interface that will be used to forward the labeled packet. Then the actual forwarding process will take place. In this discussion routing is the movement of packets (labeled or otherwise) from one network to another, where forwarding is the actual process of migrating a packet (labeled or otherwise) between interfaces on a given device.

The most basic concept that drives the inner workings of MPLS is the dynamic creation of the label forwarding information base (LFIB) from router to router. In a similar fashion as that used by our IGP routing protocols, information exchange takes place between MPLS speakers to create these tables. This process is best described as the formation of the MPLS control plane, and defines the process whereby labels are bound to network prefixes found in the FIB. This process  requires the exchange of label information between devices. We will address the mechanics of this process in depth in the following chapters where we discuss MPLS labels, but at this time we need to understand that MPLS speaking devices will dynamically exchange label information such that they can create their own discreet label information base (LIB). The specific information that is exchanged by this process is the local label assigned by the router itself and the outgoing label that will be used to switch the traffic to a neighboring device.

To summarize, up to this point the router has assigned a label to each prefix found in the RIB. The MPLS process refers to these prefixes as FECs (Forwarding Equivalency Classes), and all prefixes that share the same label will be treated equivalent in how they are forwarded. This information is then advertised to any MPLS peer. The resulting local database of FECs, interfaces and assigned labels is referred to as the LIB.
Read Full Entry »

I love interesting problems that we face when studying for our CCIEs. Especially fun are those that come from an unusual behavior of protocols.
Read Full Entry »

In this ongoing series here at blog.ipexpert.com, we are going to answer the most common questions CCIE instructors hear. Here is the latest:

Question: Am I penalized for over-configuration in the lab exam?

Answer: This is another one of those great questions, especially when you consider the fact that the grading for the lab exam is quite complex. Depending on what track you are discussing, the lab is graded by a computer script, a human, or a combination of both. Given this fact, students begin to suspect that the grading is some mysterious “black art”, that might harshly penalize for the slightest deviation from the proctor’s expectations with a task.

I like to answer this question for students with an example. Say you get the task below:

Sample Task 1 – Switching

1.3 Trunking

Create a standards-based trunk between SW1 and SW4 according to the Layer 2 diagram provided.

2 pts

I recommend that students ask themselves the question here –  how would the proctor write a script to grade this task? I think they would issue the SHOW INTERFACE TRUNK command on each device. In your mind, run through the parameters that must exist.

• Correct two devices
• Correct two interfaces
• UP/UP status
• 802.1Q trunk established

If these parameters are met – you just achieved the 2 pts.

Here are three different configurations (from just one of the two devices) that get the full two points.

Solution 1

switchport trunk encapsulation dot1q
switchport mode trunk

Solution 2

switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate

Solution 3

switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
switchport trunk allowed-vlan 100,200,300,400,500,501,502

Always ask yourself two questions:

1. Could this additional configuration I am about to add help me gain these points?
2. Could this additional configuration I am about to add potentially cost me here or elsewhere in the lab?

If your answers are YES and NO respectively, then you can certainly consider this “additional” configuration. Notice that Solution 3 comes very close to a NO and YES answer respectfully and should be frowned upon as a result.

Another great rule of thumb in this regard – “do what they ask for, nothing more, nothing less!”

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

It is true that one does not need many debug commands in order to survive the CCIE Routing and Switching Lab Exam. Sure, perhaps a debug ip rip command could prove very important for that pathetic little routing protocol, but surely we will not be doing anything near the debugging we tend to do when we are first learning our protocols.

For me another important exception to the “no to little debug rule” in the lab exam is debug ip routing. This powerful debug is part of my plan to solving the lab if we have to do some nasty complex redistribution.

You see in the context of the CCIE R&S Lab Exam, this command will be harmless. Even in the event we do have routing loops or feedback, there will not be enough routes having an issue to cause problems for the console access of our devices. In fact, is there is an issue like this caused by redistribution (or some other mechanism), the command makes this instability very, very obvious.

When something is going awry with your underlying routing table, this command is so powerful for pointing it out to you. Examine the example below where a “flapping” interface is causing problems:

Router#debug ip routing
IP routing debugging is on
Router#*Mar  1 00:02:59.115: RT: delete route to 10.10.10.0 via 1.1.1.2, eigrp metric [90/409600]
*Mar  1 00:02:59.115: RT: no routes to 10.10.10.0
*Mar  1 00:02:59.119: RT: NET-RED 10.10.10.0/24
*Mar  1 00:02:59.119: RT: delete subnet route to 10.10.10.0/24
*Mar  1 00:02:59.119: RT: NET-RED 10.10.10.0/24
*Mar  1 00:02:59.123: RT: delete network route to 10.0.0.0
*Mar  1 00:02:59.123: RT: NET-RED 10.0.0.0/8
*Mar  1 00:03:06.247: RT: add 10.10.10.0/24 via 1.1.1.2, eigrp metric [90/409600]
*Mar  1 00:03:06.251: RT: NET-RED 10.10.10.0/24
*Mar  1 00:03:43.907: RT: delete route to 10.10.10.0 via 1.1.1.2, eigrp metric [90/409600]
*Mar  1 00:03:43.911: RT: no routes to 10.10.10.0
*Mar  1 00:03:43.911: RT: NET-RED 10.10.10.0/24
*Mar  1 00:03:43.911: RT: delete subnet route to 10.10.10.0/24
*Mar  1 00:03:43.915: RT: NET-RED 10.10.10.0/24
*Mar  1 00:03:43.915: RT: delete network route to 10.0.0.0
*Mar  1 00:03:43.915: RT: NET-RED 10.0.0.0/8
*Mar  1 00:03:50.879: RT: add 10.10.10.0/24 via 1.1.1.2, eigrp metric [90/409600]
*Mar  1 00:03:50.883: RT: NET-RED 10.10.10.0/24

If everything is stable with your underlying routing table, you will not have anything like the above output. With certain protocols like BGP, you will see this passive little message pop up periodically that has to do with scanning of the table. It is harmless and can be ignored.

I like to turn this command on all of my devices in the Configuration section before I do any redistribution. I will then leave it on for the remainder of the lab, only removing it at the end of the lab before I do my final saves and leave the testing center for the day. Why leave it on? Well, it will be a nice obvious visual indicator should I break something later in the day - especially during Security configurations.

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv