Computer Software

When studying for your BSCI exam for the CCNP, you get your first taste of BGP. One of the major differences between BGP and the other protocols you’ve studied to date is that BGP uses attributes to describe paths, and to influence the selection of one path over the other.

In this free tutorial, we’re going to take a look at the Local Preference attribute and compare it to the Cisco-proprietary BGP attribute “weight”.

The Local Preference (LOCAL_PREF) attribute is used to influence how traffic will flow from one Autonomous System (AS) to another when multiple paths exist. For example, if AS 100 has two different paths to a destination network in AS 200, the LOCAL_PREF attribute can be used to influence the path selection.

The major difference between the Weight and LOCAL_PREF attributes is that when the LOCAL_PREF attribute is changed, that change is reflected throughout the AS. The new LOCAL_PREF value will be advertised to all other routers in the AS, as compared to the Weight attribute, which is locally significant only. If you change the Weight for a path on one router in an AS, the other routers in the AS will not learn of the change.

A route-map can be used to change a local preference value. For example, if you want to change the local preference value to 200 for the path advertisement 10.2.2.0/24 coming in from neighbor 10.1.1.1, there are three steps involved. First, write an ACL matching the remote network you want to change the local preference for.

R1(config)#access-list 5 permit 10.2.2.0 0.0.0.255

Second, write a route-map setting the local preference to 200. This will double the default value of 100, and the path with the highest local preference will be the preferred path.

R1(config)#route-map PREFER_PATH permit 10

R1(config-route-map)#match ip address 5

R1(config-route-map)#set local-pref 200

Finally, apply the route-map to routes that are being received from 10.1.1.1.

R1(config)#router bgp 100

R1(config-router)#network 10.1.1.1 route-map PREFER_PATH in

R1 will then advertise this new local preference value to all other routers in AS 100 – all of its iBGP neighbors.

Passing the CCNA, Intro, and ICND exam is all about knowing and noticing the details. (Which makes perfect sense, since becoming a master networking administrator or engineer is also about noticing the details!) One such detail knows the difference between error detection and error recovery. While the terms are sometimes used interchangeably, they are not the same thing.

Error detection is just that – error detection only. Two common error detection methods are found at the Data Link layer of the OSI model, the FCS (Frame Check Sequence) and CRC (Cyclical Redundancy Check). A mathematical equation is run against the data in the frame, and the result is sent along with the data. The receiver runs the equation again, but this time. If the result is the same, the frame is considered valid; if the result is different, the frame is considered corrupt and is discarded.

Note that the FCS and CRC do nothing in regards to retransmission. They are strictly error detection schemes.

For an example of error recovery, we look to the Transport layer, where TCP runs. TCP performs reliable delivery, and the reason we call it “reliable” is that TCP uses sequence numbers to detect missing segments. If the sender determines from the sequence numbers that the remote host did not receive transmitted segments, the sender will retransmit the missing segments.

The key to keeping the terms straight in your head is to remember that while both error detection and error recovery both detect problems, only error recovery does anything about it. It’s also worth reading an exam question twice when you see either term!

There’s nothing I enjoy more than teaching Cisco technologies, especially CCNA candidates. Whether it’s in-person or online, everyone’s excited to be there. There’s a sense of anticipation in the air, and everyone is ready to work hard, get their hands on the racks of Cisco routers and switches I
have available…

… and then I break out the OSI model chart. Chins slump. People sigh, or at least wish they hadn’t ordered decaf that morning.

Okay, it’s not that bad. But it does temper the excitement a little. I always get a sense of “why can’t we just hurry up and get on the routers and switches? Why do we have to learn this dry stuff?”

One reason is that Cisco demands you know the OSI model inside and out for both the Intro and ICND exams. You have to admit that’s a pretty good reason, but still, students find the OSI model information to be very dry.

I understand that, because I’ve been there. My first exposure to the OSI model was actually in a Novell “Networking Technologies” class, and man, was that chart ever dry. They crammed every known protocol (and some unknown ones, I think) into the OSI model. It looked like a giant jigsaw puzzle, and the real problem is that I didn’t know what the heck most of that stuff was.

So I dutifully attempted to memorize this massive chart. I managed to pass the exam, but I wondered what all that effort had really been for. It’s not like you sit around in a server room or wiring closet and discuss the OSI model.

As a CCNA candidate, you don’t have to worry about all the protocols I memorized way back when, but you do have to know what happens at each layer. Which leads to this question:

“If I work with routers and switches, why do I have to know about all the other layers? Don’t routers and switches just work at layer 2 and 3?”

Yes, switches work at Layer 2 and routers at Layer 3. But to truly understand networking, you’ve got to understand what happens at the other layers. Why?

Most network administrators and engineers are going to spend a lot more time troubleshooting than installing. That’s just the way it is. And to troubleshoot effectively, you’ve got to know what’s going on at all layers of the OSI model, not just layers 2 and 3.

As someone who’s done a lot of hiring and conducted a great many job interviews, I can tell you that the ability to troubleshoot is the number one quality I look for. That’s why I tell CCNA and CCNP candidates that they’ve got to get all the hands-on practice they can while I understand the importance of theory, the only way to develop troubleshooting ability is to work on the real deal. No simulator program
is going to teach you how to troubleshoot.

Additionally, the only way to truly develop your troubleshooting abilities is to know what’s going on over the entire network, not just the routers and switches. Troubleshooting always starts at Layer 1 if you don’t find a problem at the Physical layer, and everything’s fine with your routers and switches, how are you going to continue troubleshooting if you don’t know what the next steps are as data moves closer to the end user?

So when it comes to the OSI model, don’t just give it a quick once-over and move on to the fun stuff in your CCNA studies. The tangible benefit of passing your exams is great, but it’s the hidden benefit of developing your own troubleshooting methodology that makes mastering the OSI model worthwhile.

CCNA and CCNP candidates hear it all the time: “you have to get some hands-on experience to pass the exams”.

Candidates tend to think that’s just so they can solve the simulator problems, but that’s only the more obvious reason.

First, I want to make it clear that I’m not bashing learning from books you have to learn theory before you can really know what’s going on in the first place. The key is that to truly understand routing and switching processes, you’ve got to have that hands-on experience.

So if the simulator questions are the more obvious reason to get hands-on experience, what are the less obvious reasons?

Glad you asked!

You see what happens when things don’t go according to the script. One of the biggest problems with learning your skills on software programs such as “router simulators” is that with simulators, things go pretty much as planned.

I have news for you: that doesn’t always happen in the real world. While Cisco routers and switches are highly reliable devices, every once in a while you’re going to get an unexpected result from a command. Maybe it didn’t work after you typed it in maybe it has an effect on your prior configuration that you didn’t expect. Maybe you don’t know what happened – you just typed in that command and the router went nuts!

Sooner or later, that’s going to happen to you in the real world. And as I tell my students, it’s actually a good thing to have happen to you in a lab.

You don’t learn to troubleshoot or fine-tune a configuration when everything works perfectly. You don’t learn much at all when things go perfectly. And you’re practicing to learn!

I often say that great chefs don’t learn to cook on cooking simulators they learn in the kitchen, and they burn a lot of meals on the way to greatness. You need to screw up some configs on the way to greatness, and you can’t do that on a computer program. You have to be on the real thing.

You build confidence by working with real Cisco routers and switches. Would you want the Super Bowl to be the first football game you ever really played in? Of course not. Then why would you take router configuration exams and be nervous about having to create a VLAN, or troubleshoot an OSPF configuration?

You cannot walk into the testing room a nervous wreck. You must have the attitude that you are already a CCNA or CCNP, and you’re just there to make it official. I can tell you from firsthand experience with many students that the way you develop than confidence is to work with the real deal.

You can’t buy that confidence, and you can’t simulate your way to it. You’ve got to work with real Cisco routers and switches. By working with the real equipment, you develop the real skills and real confidence you need to pass the CCNA and CCNP exams.