Once you get your CCNA and CCNP, you can't just rest on your accomplishment. You've got to continue to study and add to your skill set - and then prove to Cisco you've been doing just that by recertifying.
Recertification sounds like a pain, but it's actually one of the best things to ever happen to computer certification, and it helps your career as well. One trap many LAN and WAN personnel fall into is that they fail to keep up with changes in technology, and if they happen to be laid off or want to change jobs, they're unable to because they didn't keep their skill set up.
Cisco's recertification policies ensure that if you want to keep your CCNA, CCNP, or one of the other valuable Cisco certifications, you've got to take a recertification exam.
As of November 2005, to recertify as a CCNA, you need to pass either the current CCNA exam, ICND exam, or any 642 professional level or Cisco Qualified Specialist exam. (This does not include Sales Specialist exams.) Passing a CCIE written qualification exam also recertifies you as a CCNA. CCNAs are valid for three years.
For the CCNP, you need to pass the 642-891 Composite exam, a CCIE written qualification exam, or BOTH the BSCI and BCMSN exams (642-801 and 642-811, respectively.) CCNP certifications are valid for three years.
As you can see, you've got quite a few options either way. The one classic mistake you must not make is waiting too long to begin preparing for the exams, and give yourself a little leeway just in case you don't recertify the first time around. Once the deadline passes, your certification is gone, and in the case of the CCNP that means taking all the exams again.
As a professional, it's your responsibility to keep up with changes in the Cisco certification world, and this includes changes in the recertification program. Make a point of visiting the "Learning And Events" section of Cisco's website regularly to look for changes in the certification program. And while you're there, you just might see another cert that catches your eye!
Showing posts with label ebook. Show all posts
Showing posts with label ebook. Show all posts
Friday, December 26, 2008
Wednesday, December 24, 2008
Cisco CCNA Certification: How And Why Switches Trunk
Your CCNA studies are going to include quite a bit of information about switches, and for good reason. if you don't understand basic switching theory, you can't configure and troubleshoot Cisco switches, either on the CCNA exam or in the real world. That goes double for trunking!
Trunking is simply enabling two or more switches to communicate and send frames to each other for transmission to remote hosts. There are two major trunking protocols that we need to know the details of for exam success and real-world success, but before we get to the protocols, let's discuss the cables we need.
Connecting two Cisco switches requires a crossover cable. As you know, there are eight wires inside an ethernet cable. In a crossover cable, four of the cables "cross over" from one pin to another. For many newer Cisco switches, all you need to do to create a trunk is connect the switches with a crossover cable. For instance, 2950 switches dynamically trunk once you connect them with the right cable. If you use the wrong cable, you'll be there a while!
There are two different trunking protocols in use on today's Cisco switches, ISL and IEEE 802.1Q, generally referred to as "dot1q". There are three main differences between the two. First, ISL is a Cisco-proprietary trunking protocol, where dot1q is the industry standard. (Those of you new to Cisco testing should get used to the phrases "Cisco-proprietary" and "industry standard".) If you're working in a multivendor environment, ISL may not be a good choice. And even though ISL is Cisco's own trunking protocol, some Cisco switches run only dot1q.
ISL also encapsulates the entire frame, increasing the network overhead. Dot1q only places a header on the frame, and in some circumstances, doesn't even do that. There is much less overhead with dot1q as compared to ISL. That leads to the third major difference, the way the protocols work with the native vlan.
The native vlan is simply the default vlan that switch ports are placed into if they are not expressly placed into another vlan. On Cisco switches, the native vlan is vlan 1. (This can be changed.) If dot1q is running, frames that are going to be sent across the trunk line don't even have a header placed on them; the remote switch will assume that any frame that has no header is destined for the native vlan.
The problem with ISL is that is doesn't understand what a native vlan is. Every single frame will be encapsulated, regardless of the vlan it's destined for.
Switching theory is a big part of your CCNA studies, and it can seem overwhelming at first. Just break your studies down into smaller, more manageable parts, and soon you'll see the magic letters "CCNA" behind your name!
Trunking is simply enabling two or more switches to communicate and send frames to each other for transmission to remote hosts. There are two major trunking protocols that we need to know the details of for exam success and real-world success, but before we get to the protocols, let's discuss the cables we need.
Connecting two Cisco switches requires a crossover cable. As you know, there are eight wires inside an ethernet cable. In a crossover cable, four of the cables "cross over" from one pin to another. For many newer Cisco switches, all you need to do to create a trunk is connect the switches with a crossover cable. For instance, 2950 switches dynamically trunk once you connect them with the right cable. If you use the wrong cable, you'll be there a while!
There are two different trunking protocols in use on today's Cisco switches, ISL and IEEE 802.1Q, generally referred to as "dot1q". There are three main differences between the two. First, ISL is a Cisco-proprietary trunking protocol, where dot1q is the industry standard. (Those of you new to Cisco testing should get used to the phrases "Cisco-proprietary" and "industry standard".) If you're working in a multivendor environment, ISL may not be a good choice. And even though ISL is Cisco's own trunking protocol, some Cisco switches run only dot1q.
ISL also encapsulates the entire frame, increasing the network overhead. Dot1q only places a header on the frame, and in some circumstances, doesn't even do that. There is much less overhead with dot1q as compared to ISL. That leads to the third major difference, the way the protocols work with the native vlan.
The native vlan is simply the default vlan that switch ports are placed into if they are not expressly placed into another vlan. On Cisco switches, the native vlan is vlan 1. (This can be changed.) If dot1q is running, frames that are going to be sent across the trunk line don't even have a header placed on them; the remote switch will assume that any frame that has no header is destined for the native vlan.
The problem with ISL is that is doesn't understand what a native vlan is. Every single frame will be encapsulated, regardless of the vlan it's destined for.
Switching theory is a big part of your CCNA studies, and it can seem overwhelming at first. Just break your studies down into smaller, more manageable parts, and soon you'll see the magic letters "CCNA" behind your name!
Cisco CCNA / CCNP Home Lab Setup: How To Configure Reverse Telnet
Occasionally, during your CCNA and CCNP studies, you'll run into a term that just doesn't quite make sense to you. (Okay, more than occasionally!) One such term is "reverse telnet". As a Cisco certification candidate, you know that telnet is simply a protocol that allows you to remotely connect to a networking device such as a router or switch. But what is "reverse telnet", and why is it so important to a Cisco CCNA / CCNP home lab setup?
Where a telnet session is started by a remote user who wants to remotely control a router or switch, a reverse telnet session is started when the host device itself imitates the telnet session.
In a CCNA / CCNP home lab, reverse telnet is configured and used on the access server. The access server isn't a white box server like most of us are used to; an access server is a Cisco router that allows you to connect to multiple routers and switches with one session without having to move a rollover cable from device to device.
Your access server will use an octal cable to connect to the other routers and switches in your home lab. The octal cable has one large serial connector that will connect to the access server, and eight rj-45 connectors that will connect to your other home lab devices. Your access server then needs an IP Host table in order to perform reverse telnet.
An IP Host table is easy to put together (and you better know how to write one to pass the CCNA!). The IP Host table is used for local name resolution, taking the place of a DNS server. A typical access server IP Host table looks like this:
ip host FRS 2007 100.1.1.1
ip host R3 2003 100.1.1.1
ip host R1 2001 100.1.1.1
ip host R2 2002 100.1.1.1
ip host R4 2004 100.1.1.1
ip host R5 2005 100.1.1.1
ip host SW1 2006 100.1.1.1
interface Loopback0
ip address 100.1.1.1 255.255.255.255
no ip directed-broadcast
This configuration will allow you to use your access server to connect to five routers, a frame relay switch, and a switch without ever moving a cable. When you type "R1" at the console line, for example, you'll be connected to R1 via reverse telnet. If you have a smaller lab, an access server is still a real timesaver and an excellent investment. And by getting a static IP address to put on your access server, you can even connect to your home lab from remote locations!
Where a telnet session is started by a remote user who wants to remotely control a router or switch, a reverse telnet session is started when the host device itself imitates the telnet session.
In a CCNA / CCNP home lab, reverse telnet is configured and used on the access server. The access server isn't a white box server like most of us are used to; an access server is a Cisco router that allows you to connect to multiple routers and switches with one session without having to move a rollover cable from device to device.
Your access server will use an octal cable to connect to the other routers and switches in your home lab. The octal cable has one large serial connector that will connect to the access server, and eight rj-45 connectors that will connect to your other home lab devices. Your access server then needs an IP Host table in order to perform reverse telnet.
An IP Host table is easy to put together (and you better know how to write one to pass the CCNA!). The IP Host table is used for local name resolution, taking the place of a DNS server. A typical access server IP Host table looks like this:
ip host FRS 2007 100.1.1.1
ip host R3 2003 100.1.1.1
ip host R1 2001 100.1.1.1
ip host R2 2002 100.1.1.1
ip host R4 2004 100.1.1.1
ip host R5 2005 100.1.1.1
ip host SW1 2006 100.1.1.1
interface Loopback0
ip address 100.1.1.1 255.255.255.255
no ip directed-broadcast
This configuration will allow you to use your access server to connect to five routers, a frame relay switch, and a switch without ever moving a cable. When you type "R1" at the console line, for example, you'll be connected to R1 via reverse telnet. If you have a smaller lab, an access server is still a real timesaver and an excellent investment. And by getting a static IP address to put on your access server, you can even connect to your home lab from remote locations!
Cisco CCNA / CCNP Home Lab Setup: How To Configure Reverse Telnet
Occasionally, during your CCNA and CCNP studies, you'll run into a term that just doesn't quite make sense to you. (Okay, more than occasionally!) One such term is "reverse telnet". As a Cisco certification candidate, you know that telnet is simply a protocol that allows you to remotely connect to a networking device such as a router or switch. But what is "reverse telnet", and why is it so important to a Cisco CCNA / CCNP home lab setup?
Where a telnet session is started by a remote user who wants to remotely control a router or switch, a reverse telnet session is started when the host device itself imitates the telnet session.
In a CCNA / CCNP home lab, reverse telnet is configured and used on the access server. The access server isn't a white box server like most of us are used to; an access server is a Cisco router that allows you to connect to multiple routers and switches with one session without having to move a rollover cable from device to device.
Your access server will use an octal cable to connect to the other routers and switches in your home lab. The octal cable has one large serial connector that will connect to the access server, and eight rj-45 connectors that will connect to your other home lab devices. Your access server then needs an IP Host table in order to perform reverse telnet.
An IP Host table is easy to put together (and you better know how to write one to pass the CCNA!). The IP Host table is used for local name resolution, taking the place of a DNS server. A typical access server IP Host table looks like this:
ip host FRS 2007 100.1.1.1
ip host R3 2003 100.1.1.1
ip host R1 2001 100.1.1.1
ip host R2 2002 100.1.1.1
ip host R4 2004 100.1.1.1
ip host R5 2005 100.1.1.1
ip host SW1 2006 100.1.1.1
interface Loopback0
ip address 100.1.1.1 255.255.255.255
no ip directed-broadcast
This configuration will allow you to use your access server to connect to five routers, a frame relay switch, and a switch without ever moving a cable. When you type "R1" at the console line, for example, you'll be connected to R1 via reverse telnet. If you have a smaller lab, an access server is still a real timesaver and an excellent investment. And by getting a static IP address to put on your access server, you can even connect to your home lab from remote locations!
Where a telnet session is started by a remote user who wants to remotely control a router or switch, a reverse telnet session is started when the host device itself imitates the telnet session.
In a CCNA / CCNP home lab, reverse telnet is configured and used on the access server. The access server isn't a white box server like most of us are used to; an access server is a Cisco router that allows you to connect to multiple routers and switches with one session without having to move a rollover cable from device to device.
Your access server will use an octal cable to connect to the other routers and switches in your home lab. The octal cable has one large serial connector that will connect to the access server, and eight rj-45 connectors that will connect to your other home lab devices. Your access server then needs an IP Host table in order to perform reverse telnet.
An IP Host table is easy to put together (and you better know how to write one to pass the CCNA!). The IP Host table is used for local name resolution, taking the place of a DNS server. A typical access server IP Host table looks like this:
ip host FRS 2007 100.1.1.1
ip host R3 2003 100.1.1.1
ip host R1 2001 100.1.1.1
ip host R2 2002 100.1.1.1
ip host R4 2004 100.1.1.1
ip host R5 2005 100.1.1.1
ip host SW1 2006 100.1.1.1
interface Loopback0
ip address 100.1.1.1 255.255.255.255
no ip directed-broadcast
This configuration will allow you to use your access server to connect to five routers, a frame relay switch, and a switch without ever moving a cable. When you type "R1" at the console line, for example, you'll be connected to R1 via reverse telnet. If you have a smaller lab, an access server is still a real timesaver and an excellent investment. And by getting a static IP address to put on your access server, you can even connect to your home lab from remote locations!
Monday, December 22, 2008
Cisco CCNA / CCNP Certification: Introduction To BGP Attributes
BGP is one of the most complex topics you'll study when pursuing your CCNP, if not the most complex. I know from personal experience that when I was earning my CCNP, BGP is the topic that gave me the most trouble at first. One thing I keep reminding today's CCNP candidates about, though, is that no Cisco technology is impossible to understand if you just break it down and understand the basics before you start trying to understand the more complex configurations.
BGP attributes are one such topic. You've got well-known mandatory, well-known discretionary, transitive, and non-transitive. Then you've got each individual BGP attribute to remember, and the order in which BGP considers attributes, and what attributes even are... and a lot more! As with any other Cisco topic, we have to walk before we can run. Let's take a look at what attributes are and what they do in BGP.
BGP attributes are much like what metrics are to OSPF, RIP, IGRP, and EIGRP. You won't see them listed in a routing table, but attributes are what BGP considers when choosing the best path to a destination when multiple valid (loop-free) paths exist.
When BGP has to decide between such paths, there is an order in which BGP considers the path attributes. For success on the CCNP exams, you need to know this order. BGP looks at path attributes in this order:
Highest weight (Cisco-proprietary BGP value)
Highest local preference (LOCAL_PREF)
Prefer locally originated route.
Shortest AS_PATH is preferred.
Choose route with lowest origin code. Internal paths are preferred over external paths, and external paths are preferred over paths with an origin of "incomplete".
Lowest multi-exit discriminator (MED)
External BGP routes preferred over Internal BGP routes.
If no external route, select path with lowest IGP cost to the next-hop router for iBGP.
Choose most recent route.
Choose lowest BGP RID (Router ID).
If you don't know what these values are, or how they're configured, don't panic! The next several parts of this BGP tutorial will explain it all. So spend some time studying this order, and in part II of this free BGP tutorial, we'll look at each of these values in detail. Keep studying!
BGP attributes are one such topic. You've got well-known mandatory, well-known discretionary, transitive, and non-transitive. Then you've got each individual BGP attribute to remember, and the order in which BGP considers attributes, and what attributes even are... and a lot more! As with any other Cisco topic, we have to walk before we can run. Let's take a look at what attributes are and what they do in BGP.
BGP attributes are much like what metrics are to OSPF, RIP, IGRP, and EIGRP. You won't see them listed in a routing table, but attributes are what BGP considers when choosing the best path to a destination when multiple valid (loop-free) paths exist.
When BGP has to decide between such paths, there is an order in which BGP considers the path attributes. For success on the CCNP exams, you need to know this order. BGP looks at path attributes in this order:
Highest weight (Cisco-proprietary BGP value)
Highest local preference (LOCAL_PREF)
Prefer locally originated route.
Shortest AS_PATH is preferred.
Choose route with lowest origin code. Internal paths are preferred over external paths, and external paths are preferred over paths with an origin of "incomplete".
Lowest multi-exit discriminator (MED)
External BGP routes preferred over Internal BGP routes.
If no external route, select path with lowest IGP cost to the next-hop router for iBGP.
Choose most recent route.
Choose lowest BGP RID (Router ID).
If you don't know what these values are, or how they're configured, don't panic! The next several parts of this BGP tutorial will explain it all. So spend some time studying this order, and in part II of this free BGP tutorial, we'll look at each of these values in detail. Keep studying!
Subscribe to:
Posts (Atom)
