Microsoft is in the middle of a major push to overhaul its certification program. Last year, they announced the new Microsoft Certified Architect (MCA) certification, which is not a written exam but rather a practical exam that will be graded by a board of examiners. Just applying for the certification will require 10 years' experience in IT as well as three years of practical experience as a network architect.
For those of us not quite ready for that, Microsoft has announced that it's also going to revise other certifications. The MCSE that we've all come to know and love is going to be a thing of the past. In its place will be a series of specialization exams and IP Professional certification tracks.
If you're currently an MCSE or working it, don't worry, you have plenty of time to adapt to the new tracks. Microsoft's official word is that the new certification structure will be implemented when the next Windows server/client version is released. For those holding MCDBAs, your current certification will remain valid and you'll have a chance to upgrade to the new certification with SQL Server 2005.
Those of us who have been on the certification track for a while remember the outcry when Microsoft planned to phase out the much-maligned NT 4.0 certification in the move to Windows 2000. There was quite an outcry from many certified individuals who felt MS was being unreasonable in their timetable and planned lack of support for the 4.0 certification. Whether you agree with Microsoft's planned changes, I urge you to visit Microsoft's certification site regularly to keep up with these changes.
Whether you choose to pursue any of these new tracks is your decision, but you owe it to yourself and your career to know about the new tracks. Change is inevitable in IT and the IT certification world, and you must be aware of these changes!
Showing posts with label server. Show all posts
Showing posts with label server. Show all posts
Friday, December 26, 2008
Computer Certification: Become A Utility Player
In baseball, a "utility player" is one who plays more than one position. These players are usually backups, but they have a job in the major leagues because of their value to the team; since they can play more than one position, they have that much more value to their employer.
Too often in IT, workers become either LAN or WAN engineers, knowing little if anything about the other side. Many LAN administrators I worked with knew little about routing and switching, while many WAN engineers I knew not only didn't know much about the LAN side of their network, but they didn't want to know anything about the servers!
In today's IT world, it's a bad idea to specialize in only one thing and not know how to do anything else. Not only does it limit your future career prospects, but it limits your current prospects as well. Employers don't want to hire someone and have them get up to speed on the job - they want someone who can walk right in and do the job. The more you know, the better your chance of getting a better job - or quickly being able to get another job if you were laid off tomorrow.
A term often heard on Wall Street is "diversification", meaning that investors should not invest heavily or totally in only one stock; if that stock plummets, they're in big trouble. Your career is the most important stock you will ever own, and you're 100% in charge of it. Diversify. If you're working primarily with servers, learn some routing and switching. If you know the routing protocols your company uses on its WAN, learn something about that protocol. (If you don't know the protocol, ask!)
While you’re adding these skills, get certified while you’re at it! Adding a CCNA, MCSE, or other computer certification looks great on your resume while signaling to employers that you’re constantly adding to your skills.
Adding more skills and knowledge to your IT skill set is always a good idea. Don't limit yourself to the technologies you work with every day. Make an investment in yourself and become a well-rounded network engineer. This will help you keep the job you have - and open doors in the future that might otherwise have remained closed.
Too often in IT, workers become either LAN or WAN engineers, knowing little if anything about the other side. Many LAN administrators I worked with knew little about routing and switching, while many WAN engineers I knew not only didn't know much about the LAN side of their network, but they didn't want to know anything about the servers!
In today's IT world, it's a bad idea to specialize in only one thing and not know how to do anything else. Not only does it limit your future career prospects, but it limits your current prospects as well. Employers don't want to hire someone and have them get up to speed on the job - they want someone who can walk right in and do the job. The more you know, the better your chance of getting a better job - or quickly being able to get another job if you were laid off tomorrow.
A term often heard on Wall Street is "diversification", meaning that investors should not invest heavily or totally in only one stock; if that stock plummets, they're in big trouble. Your career is the most important stock you will ever own, and you're 100% in charge of it. Diversify. If you're working primarily with servers, learn some routing and switching. If you know the routing protocols your company uses on its WAN, learn something about that protocol. (If you don't know the protocol, ask!)
While you’re adding these skills, get certified while you’re at it! Adding a CCNA, MCSE, or other computer certification looks great on your resume while signaling to employers that you’re constantly adding to your skills.
Adding more skills and knowledge to your IT skill set is always a good idea. Don't limit yourself to the technologies you work with every day. Make an investment in yourself and become a well-rounded network engineer. This will help you keep the job you have - and open doors in the future that might otherwise have remained closed.
Wednesday, December 24, 2008
Cisco CCNA Certification Exam Tutorial: DNS And The IP Name-Server Command
DNS behaviors of a Cisco router are important topics for both the CCNA exam and real-world production networks, and you probably didn't know there were so many DNS details before you began studying for the exam! In this tutorial, we'll look at the ip name-server command and its proper usage.
When a command is mistyped on a Cisco router, the default behavior of the router is to attempt to resolve it via DNS. First, the router looks for an IP Host table on the local router to perform this resolution – that’s what the “translating” word in the output is referring to. If there’s no IP Host table or the IP Host table doesn’t contain an entry for what you typed, the router will send a broadcast in an attempt to resolve this name through a remote DNS server. To prevent this broadcast, enter the global command no ip domain-lookup. Of course, to use DNS to resolve hostnames, ip domain-lookup would have to be reenabled if it’s been turned off.
R2#contin
Translating "contin"...domain server (255.255.255.255)
% Unknown command or computer name, or unable to find computer address
A command is mistyped as “contin”. The Cisco router’s default behavior is to resolve this entry locally via an IP Host table, which isn't present on the router. A broadcast is then sent out to find a DNS server to perform the name resolution. The DNS lookup attempt must time out before the configuration can continue.
R2#conf t
R2(config)#no ip domain-lookup
R2#contin
Translating "contin"
% Unknown command or computer name, or unable to find computer address
With “no ip domain-lookup” configured, the router doesn’t attempt to find a remote DNS server. It sees there is no local resolution configured and almost immediately sends a message to the console that the name can’t be resolved.
R2#conf t
R2(config)#ip domain-lookup
R2(config)#ip name-server 10.1.1.1
R2#contin
Translating "contin"...domain server (10.1.1.1)
A DNS server is installed on the network with the IP address 10.1.1.1. DNS lookup is reenabled with the command ip domain-lookup, and the IP address of the DNS server is specified with the ip name-server command.
It's just that easy to tell a Cisco router exactly where the DNS server is!
When a command is mistyped on a Cisco router, the default behavior of the router is to attempt to resolve it via DNS. First, the router looks for an IP Host table on the local router to perform this resolution – that’s what the “translating” word in the output is referring to. If there’s no IP Host table or the IP Host table doesn’t contain an entry for what you typed, the router will send a broadcast in an attempt to resolve this name through a remote DNS server. To prevent this broadcast, enter the global command no ip domain-lookup. Of course, to use DNS to resolve hostnames, ip domain-lookup would have to be reenabled if it’s been turned off.
R2#contin
Translating "contin"...domain server (255.255.255.255)
% Unknown command or computer name, or unable to find computer address
A command is mistyped as “contin”. The Cisco router’s default behavior is to resolve this entry locally via an IP Host table, which isn't present on the router. A broadcast is then sent out to find a DNS server to perform the name resolution. The DNS lookup attempt must time out before the configuration can continue.
R2#conf t
R2(config)#no ip domain-lookup
R2#contin
Translating "contin"
% Unknown command or computer name, or unable to find computer address
With “no ip domain-lookup” configured, the router doesn’t attempt to find a remote DNS server. It sees there is no local resolution configured and almost immediately sends a message to the console that the name can’t be resolved.
R2#conf t
R2(config)#ip domain-lookup
R2(config)#ip name-server 10.1.1.1
R2#contin
Translating "contin"...domain server (10.1.1.1)
A DNS server is installed on the network with the IP address 10.1.1.1. DNS lookup is reenabled with the command ip domain-lookup, and the IP address of the DNS server is specified with the ip name-server command.
It's just that easy to tell a Cisco router exactly where the DNS server is!
Cisco CCNA / CCNP Tutorial: Home Lab Assembly Case Study
Part of your CCNA / CCNP education is deciding what network topology to use when you're putting together your home lab. Some of you are starting with one or two routers or switches, while others are starting with more. A customer recently sent me a list of his Cisco routers and switches that he has available for a home lab and asked for my help in coming up with the best way to use them.
There is no "right" or "wrong" answer to this question; again, part of the learning process is configuring and reconfiguring the physical topology of your lab. Let's look at the routers and switches he has available, including the interfaces on each, and come up with one possible CCNA / CCNP home lab setup.
The equipment list:
Two 3620 routers. Each has 1 serial port and 2 ethernet ports.
One 3640 router. This has two ethernet cards, each with two ports, and two AUI ports.
Three 2503s, my personal favorite for home labs! These have 1 AUI port, 2 serial interfaces, and one BRI interface apiece.
One 2524 router. This has one serial port, 1 ethernet port, and one BRI interface.
One 4500 router. This has eight BRI ports, 2 ethernet ports, and more importantly, four serial ports.
He also has a 5200 access server, an ISDN simulator, one 2924 switch, and one 1924 switch.
Now, if you don't have this much equipment to work with, don't panic! Most CCNA / CCNP candidates don't; this is more of an exercise in looking at what you do have and using it to the utmost.
As I've mentioned in many of my CCNA / CCNP home lab articles, an access server is a great thing to have. All he needs is an octal cable to connect his AS to the other devices we choose to use, and he's all set. (If you need an access server sample configuration, there is one on my website in the Home Lab section.)
A frame relay switch is also great to have, and the 4500 will make a great FR switch. Having a frame relay cloud in your CCNA / CCNP home lab is a great way to get experience configuring and troubleshooting frame relay, an essential skill for CCNA success.
I would put both of the 3620s on the frame relay cloud via the Serial interface, as well as two of the 2503s. That gives you four routers that will be using frame relay to communicate, and that's the most we can have since the 4500 has four serial ports. The 4500 will need to be configured as a frame relay switch and connected to the other routers via a DTE/DCE cable. (Again, if you need a frame relay switch configuration, the one I use in my pods is on the website in the same place as the access server configuration.)
The two 2503s that are on the frame relay cloud should also be connected via their BRI interfaces. The home lab also includes an ISDN simulator, which is necessary to allow routers to communicate via their BRI interfaces. Just get a couple of straight-through cables to connect those two routers to the ISDN simulator and that segment is ready to go. (Remember that you can't connect Cisco routers directly via their BRI interfaces.)
All of the routers in this lab have at least one ethernet or AUI port, so we can connect them all to either one of the switches. The switches should be connected via at least two crossover cables to allow practice with trunking, root bridge election, and VLANs. Having two switches really does add quite a bit to a CCNA / CCNP home lab's capabilities. You can experiment with different subnets and vlans with as well. Don't be afraid to dive in - that's what a home lab is all about!
So now we've got four routers connected via frame relay, two via ISDN, and the others via ethernet segments. Two of the routers that are not using their serial interfaces should be connected directly via their serial ports. For this, you'll just need another DTE/DCE cable. Knowing how to bring up the line between two directly connected serial ports is an important CCNA skill, and so is troubleshooting it. You should be able to bring such a connection up with your eyes closed, and once you work with your own CCNA / CCNP home lab, you'll be able to!
Also, don't forget to add a loopback interface to each one of your routers. I like to use 1.1.1.1 for R1, 2.2.2.2 for R2, and so on. Advertising loopbacks is another great way to get practice with RIP, OSPF, EIGRP, IGRP, and static routing.
We've taken a pile of routers and switches and turned them into a fantastic CCNA / CCNP home lab. Whether you're working with two Cisco devices or ten, coming up with your own home lab topology is a great learning experience and the beginning of developing your analytical and troubleshooting skills.
There is no "right" or "wrong" answer to this question; again, part of the learning process is configuring and reconfiguring the physical topology of your lab. Let's look at the routers and switches he has available, including the interfaces on each, and come up with one possible CCNA / CCNP home lab setup.
The equipment list:
Two 3620 routers. Each has 1 serial port and 2 ethernet ports.
One 3640 router. This has two ethernet cards, each with two ports, and two AUI ports.
Three 2503s, my personal favorite for home labs! These have 1 AUI port, 2 serial interfaces, and one BRI interface apiece.
One 2524 router. This has one serial port, 1 ethernet port, and one BRI interface.
One 4500 router. This has eight BRI ports, 2 ethernet ports, and more importantly, four serial ports.
He also has a 5200 access server, an ISDN simulator, one 2924 switch, and one 1924 switch.
Now, if you don't have this much equipment to work with, don't panic! Most CCNA / CCNP candidates don't; this is more of an exercise in looking at what you do have and using it to the utmost.
As I've mentioned in many of my CCNA / CCNP home lab articles, an access server is a great thing to have. All he needs is an octal cable to connect his AS to the other devices we choose to use, and he's all set. (If you need an access server sample configuration, there is one on my website in the Home Lab section.)
A frame relay switch is also great to have, and the 4500 will make a great FR switch. Having a frame relay cloud in your CCNA / CCNP home lab is a great way to get experience configuring and troubleshooting frame relay, an essential skill for CCNA success.
I would put both of the 3620s on the frame relay cloud via the Serial interface, as well as two of the 2503s. That gives you four routers that will be using frame relay to communicate, and that's the most we can have since the 4500 has four serial ports. The 4500 will need to be configured as a frame relay switch and connected to the other routers via a DTE/DCE cable. (Again, if you need a frame relay switch configuration, the one I use in my pods is on the website in the same place as the access server configuration.)
The two 2503s that are on the frame relay cloud should also be connected via their BRI interfaces. The home lab also includes an ISDN simulator, which is necessary to allow routers to communicate via their BRI interfaces. Just get a couple of straight-through cables to connect those two routers to the ISDN simulator and that segment is ready to go. (Remember that you can't connect Cisco routers directly via their BRI interfaces.)
All of the routers in this lab have at least one ethernet or AUI port, so we can connect them all to either one of the switches. The switches should be connected via at least two crossover cables to allow practice with trunking, root bridge election, and VLANs. Having two switches really does add quite a bit to a CCNA / CCNP home lab's capabilities. You can experiment with different subnets and vlans with as well. Don't be afraid to dive in - that's what a home lab is all about!
So now we've got four routers connected via frame relay, two via ISDN, and the others via ethernet segments. Two of the routers that are not using their serial interfaces should be connected directly via their serial ports. For this, you'll just need another DTE/DCE cable. Knowing how to bring up the line between two directly connected serial ports is an important CCNA skill, and so is troubleshooting it. You should be able to bring such a connection up with your eyes closed, and once you work with your own CCNA / CCNP home lab, you'll be able to!
Also, don't forget to add a loopback interface to each one of your routers. I like to use 1.1.1.1 for R1, 2.2.2.2 for R2, and so on. Advertising loopbacks is another great way to get practice with RIP, OSPF, EIGRP, IGRP, and static routing.
We've taken a pile of routers and switches and turned them into a fantastic CCNA / CCNP home lab. Whether you're working with two Cisco devices or ten, coming up with your own home lab topology is a great learning experience and the beginning of developing your analytical and troubleshooting skills.
Cisco CCNA / CCNP Home Labs: Developing Troubleshooting Skills
CCNA / CCNP candidates are going to be drilled by Cisco when it comes to troubleshooting questions. You're going to have to be able to analyze configurations to see what the problem is (and if there is a problem in the first place), determine the meaning of different debug outputs, and show the ability not just to configure a router or switch, but troubleshoot one.
That's just as it should be, because CCNAs and CCNPs will find themselves doing a lot of troubleshooting in their careers. Troubleshooting isn't something that can just be learned from a book; you've got to have some experience working with routers and switches. The only real way to learn how to troubleshoot is to develop that ability while working on live equipment.
Of course, your company or client is going to take a very dim view of you developing this skill on their live network. So what can you do?
Assemble a Cisco home lab. When you start working with real Cisco equipment, you're doing yourself a lot of favors. First, you're going to be amazed at how well you retain information that will become second nature to you before exam day. But more importantly, both for the exam room and your career, you're developing invaluable troubleshooting skills.
Don't get me wrong, I'm not saying knowing the theory of how routers and switches work is unimportant. Quite the opposite - if you don't know networking theory, you're not going to become a CCNA or CCNP. But the ability to apply that knowledge is vital - and the only way you can get that is to work on real Cisco routers and switches. As for these "router simulators" on the market today, ask yourself this simple question: "When I walk into a server room, how many router simulators do I see?"
I often tell students that they'll do their best learning when they screw something up. I've had many a student tell me later that I was right - when they misconfigured frame relay, ISDN, or another CCNA / CCNP technology and then had to fix it themselves, it not only gave them the opportunity to apply their knowledge, but it gave them the confidence to know they could do it.
And you can't put a price on confidence - in the exam room or in the network center!
That's just as it should be, because CCNAs and CCNPs will find themselves doing a lot of troubleshooting in their careers. Troubleshooting isn't something that can just be learned from a book; you've got to have some experience working with routers and switches. The only real way to learn how to troubleshoot is to develop that ability while working on live equipment.
Of course, your company or client is going to take a very dim view of you developing this skill on their live network. So what can you do?
Assemble a Cisco home lab. When you start working with real Cisco equipment, you're doing yourself a lot of favors. First, you're going to be amazed at how well you retain information that will become second nature to you before exam day. But more importantly, both for the exam room and your career, you're developing invaluable troubleshooting skills.
Don't get me wrong, I'm not saying knowing the theory of how routers and switches work is unimportant. Quite the opposite - if you don't know networking theory, you're not going to become a CCNA or CCNP. But the ability to apply that knowledge is vital - and the only way you can get that is to work on real Cisco routers and switches. As for these "router simulators" on the market today, ask yourself this simple question: "When I walk into a server room, how many router simulators do I see?"
I often tell students that they'll do their best learning when they screw something up. I've had many a student tell me later that I was right - when they misconfigured frame relay, ISDN, or another CCNA / CCNP technology and then had to fix it themselves, it not only gave them the opportunity to apply their knowledge, but it gave them the confidence to know they could do it.
And you can't put a price on confidence - in the exam room or in the network center!
Cisco CCNA / CCNP Home Lab Tutorial: Configuring An Access Server
As your CCNA / CCNP home lab expands, an access server such as the Cisco 2509 or 2511 is one of the best investments you can make. In this article, we'll look at the basic configuration for an access server and discuss how to connect to the other routers and switches in your pod through the AS.
Here's part of a configuration from one of my access servers:
ip host FRS 2006 100.1.1.1
ip host SW2 2005 100.1.1.1
ip host SW1 2004 100.1.1.1
ip host R2 2002 100.1.1.1
ip host R1 2001 100.1.1.1
ip host R3 2003 100.1.1.1
interface Loopback0
ip address 100.1.1.1 255.255.255.255
no ip directed-broadcast
This is an IP Host table, and this is what makes the entire AS setup work. Your PC will connect to the access server, and the access server is in turn physically connected to your other routers and switches via an octal cable. One end of the octal cable splices off into eight separate cables, each terminated with an Rj-45 connector. That connector will be placed into the console port of one of your home lab devices. In this configuration, I have connector 1 connected to the console port of R1, connector 2 to R2, connector 3 to R3, connector 4 to Sw1, and so forth. (The connectors are physically numbered as well.)
The IP Host table entries here are linked to the loopback address shown. The loopback can be any address, but it must match the address in the IP Host table. This allows you to create reverse telnet sessions to the routers and switches.
To open the reverse telnet sessions upon opening a connection to the AS, type the entire name of the device and press the enter key twice. A connection to that device will now be visible, as shown here:
Access_Server#r1
Trying R1 (100.1.1.1, 2001)... Open
R1#
To get back to the access server, use the key combination followed by pressing the "x" key. Keep doing this until you've opened a connection to every router and switch in your pod.
Once you've opened the lines, you will not use the full device name to connect to the home lab devices. You should press only the number corresponding to the reverse telnet session you opened. For instance, in this configuration I opened telnet session 1 to R1, session 2 to R2, and session 3 to R3. Once I opened those sessions, I just use those numbers to reconnect to the devices, as shown here:
Access_server#1
[Resuming connection 1 to r1 ... ]
R1#
Access_server#2
[Resuming connection 2 to r2 ... ]
R2#
Access_server#3
[Resuming connection 3 to r3 ... ]
R3#
If you type the full hostname again after initially opening the connection, you will see this message:
Access_server#r1
Trying R1 (100.1.1.1, 2001)...
% Connection refused by remote host
The connection is refused because you already have an open connection to that router.
There's one more important part of an access server config your CCNA / CCNP home lab will need:
line 1 8
no exec
transport input all
The line numbers may differ according to your access server, but "no exec" is very important here. This will stop rogue EXEC sessions from refusing connections that it shouldn't be refusing. Without this command, you'll commonly see "connection refused by remote host" when you shouldn't be. That message is the most common error you'll see on an access server, and it's there because you already have an open connection or you left "no exec" out of your configuration. "No exec" isn't mandatory, but it will help you keep your sanity!
Here's part of a configuration from one of my access servers:
ip host FRS 2006 100.1.1.1
ip host SW2 2005 100.1.1.1
ip host SW1 2004 100.1.1.1
ip host R2 2002 100.1.1.1
ip host R1 2001 100.1.1.1
ip host R3 2003 100.1.1.1
interface Loopback0
ip address 100.1.1.1 255.255.255.255
no ip directed-broadcast
This is an IP Host table, and this is what makes the entire AS setup work. Your PC will connect to the access server, and the access server is in turn physically connected to your other routers and switches via an octal cable. One end of the octal cable splices off into eight separate cables, each terminated with an Rj-45 connector. That connector will be placed into the console port of one of your home lab devices. In this configuration, I have connector 1 connected to the console port of R1, connector 2 to R2, connector 3 to R3, connector 4 to Sw1, and so forth. (The connectors are physically numbered as well.)
The IP Host table entries here are linked to the loopback address shown. The loopback can be any address, but it must match the address in the IP Host table. This allows you to create reverse telnet sessions to the routers and switches.
To open the reverse telnet sessions upon opening a connection to the AS, type the entire name of the device and press the enter key twice. A connection to that device will now be visible, as shown here:
Access_Server#r1
Trying R1 (100.1.1.1, 2001)... Open
R1#
To get back to the access server, use the key combination
Once you've opened the lines, you will not use the full device name to connect to the home lab devices. You should press only the number corresponding to the reverse telnet session you opened. For instance, in this configuration I opened telnet session 1 to R1, session 2 to R2, and session 3 to R3. Once I opened those sessions, I just use those numbers to reconnect to the devices, as shown here:
Access_server#1
[Resuming connection 1 to r1 ... ]
R1#
Access_server#2
[Resuming connection 2 to r2 ... ]
R2#
Access_server#3
[Resuming connection 3 to r3 ... ]
R3#
If you type the full hostname again after initially opening the connection, you will see this message:
Access_server#r1
Trying R1 (100.1.1.1, 2001)...
% Connection refused by remote host
The connection is refused because you already have an open connection to that router.
There's one more important part of an access server config your CCNA / CCNP home lab will need:
line 1 8
no exec
transport input all
The line numbers may differ according to your access server, but "no exec" is very important here. This will stop rogue EXEC sessions from refusing connections that it shouldn't be refusing. Without this command, you'll commonly see "connection refused by remote host" when you shouldn't be. That message is the most common error you'll see on an access server, and it's there because you already have an open connection or you left "no exec" out of your configuration. "No exec" isn't mandatory, but it will help you keep your sanity!
Cisco CCNA / CCNP Home Lab Tutorial: Cabling Your Access Server
A Cisco home lab is an invaluable study tool when you're preparing for CCNA and CCNP exam success. Once you've gotten a couple of routers and switches, you'll quickly get tired of moving that blue console cable every time you want to configure a different device. The solution to this problem is purchasing and configuring an access server (AS).
For those of you new to access servers, note that these are not white boxes running Microsoft operating systems. These are Cisco routers that allow you to connect to all the routers and switches in your home lab without moving a cable. You can physically or logically connect to the access server and work with all your devices from there.
When you're pricing access servers, please remember that you do NOT need an expensive AS. Right now on ebay there are access servers costing up to $5000 - this is NOT what you want to buy. What you're looking for is something like a 2509 or 2511, which is going to run you anywhere from $100 - $200. It's money well spent, because once you get an AS, you'll really wonder how you ever did without it.
The only additional hardware you need is the cable that will physically connect your AS to the other routers and switches in your home lab. The cable you need is called an octal cable, so named because one end of this cable is actually eight ends, all terminated with a numbered RJ-45 connector.
The large end of the cable is going to be connected to the AS itself. The cable will connect to a port on the AS that will have "async 1-8" directly above the physical port. It is this port that makes an AS different from other Cisco routers.
Once you've got your AS and this cable, you're ready to configure your AS. Connect the cable to the AS as described above, and then you will connect one of the RJ-45 connectors to the console port of each one of your routers and switches. Make sure to note the number that's on the cable itself right below the connector, because that's very important. In the next part of this home lab tutorial, I'll tell you exactly how to configure your access server for best results, along with a few troubleshooting tips.
For those of you new to access servers, note that these are not white boxes running Microsoft operating systems. These are Cisco routers that allow you to connect to all the routers and switches in your home lab without moving a cable. You can physically or logically connect to the access server and work with all your devices from there.
When you're pricing access servers, please remember that you do NOT need an expensive AS. Right now on ebay there are access servers costing up to $5000 - this is NOT what you want to buy. What you're looking for is something like a 2509 or 2511, which is going to run you anywhere from $100 - $200. It's money well spent, because once you get an AS, you'll really wonder how you ever did without it.
The only additional hardware you need is the cable that will physically connect your AS to the other routers and switches in your home lab. The cable you need is called an octal cable, so named because one end of this cable is actually eight ends, all terminated with a numbered RJ-45 connector.
The large end of the cable is going to be connected to the AS itself. The cable will connect to a port on the AS that will have "async 1-8" directly above the physical port. It is this port that makes an AS different from other Cisco routers.
Once you've got your AS and this cable, you're ready to configure your AS. Connect the cable to the AS as described above, and then you will connect one of the RJ-45 connectors to the console port of each one of your routers and switches. Make sure to note the number that's on the cable itself right below the connector, because that's very important. In the next part of this home lab tutorial, I'll tell you exactly how to configure your access server for best results, along with a few troubleshooting tips.
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!
Tuesday, December 23, 2008
Cisco CCNA / CCNP Certification Exam Tutorial: Configuring PPP Callback
You may run into situations where a router in a remote location needs to dial in to a central router, but the toll charges are much higher if the remote router makes the call. This scenario is perfect for PPP Callback, where the callback client places a call to a callback server, authentication takes place, and the server then hangs up on the client! This ensures that the client isn't charged for the call. The server then calls the client back.
In the following example, R2 has been configured as the client and R1 is the callback server. Let's look at both configurations and the unique commands PPP Callback requires.
Client:
username R1 password CCIE
interface BRI0
ip address 172.12.12.2 255.255.255.0
encapsulation ppp
dialer map ip 172.12.12.1 name R1 broadcast 5557777
dialer-group 1
isdn switch-type basic-ni
ppp callback request
ppp authentication chap
Most of that configuration will look familiar to you, but the ppp callback request command might not. This command enables the BRI interface to request the callback.
Simple enough, right? The PPP Callback Server config requires more configuration and an additional map-class as well.
Server:
username R2 password CCIE
interface BRI0
ip address 172.12.12.1 255.255.255.0
encapsulation ppp
dialer callback-secure
dialer map ip 172.12.12.2 name R2 class CALL_R2_BACK broadcast 5558888
dialer-group 1
isdn switch-type basic-ni
ppp callback accept
ppp authentication chap
map-class dialer CALL_R2_BACK
dialer callback-server username
Examining the PPP Callback Server command from the top down...
dialer callback-secure enables security on the callback. If the remote router cannot be authenticated for callback, the incoming call will be disconnected.
The dialer map statement now calls the class CALL_R2_BACK, shown at the bottom of the config excerpt.
ppp callback accept enables PPP callback on this router.
dialer callback-server username tells the callback server that the device referenced in the dialer map statement is a callback client.
The only way to find out if the config works is to test it, so let's send a ping from R2 to R1 and see if the callback takes place.
R2#ping 172.12.12.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.12.12.1, timeout is 2 seconds:
02:45:42: BR0 DDR: Dialing cause ip (s=172.12.12.2, d=172.12.12.1)
02:45:42: BR0 DDR: Attempting to dial 5557777
02:45:42: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
02:45:42: BR0:1 DDR: Callback negotiated - Disconnecting now
02:45:42: BR0:1 DDR: disconnecting call
02:45:42: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 5557777 R1
02:45:42: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
02:45:42: DDR: Callback client for R1 5557777 created
02:45:42: BR0:1 DDR: disconnecting call.....
Success rate is 0 percent (0/5)
R2#
02:45:57: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
R2#
02:45:57: BR0:1 DDR: Callback received from R1 5557777
02:45:57: DDR: Freeing callback to R1 5557777
02:45:57: BR0:1 DDR: dialer protocol up
02:45:58: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up
The callback was successfully negotiated, and the call then disconnected. R1 then called R2 back, and show dialer on R1 confirms the purpose of the call.
R1#show dialer
BRI0 - dialer type = ISDN
Dial String Successes Failures Last DNIS Last status
5558888 2 4 00:00:20 successful
0 incoming call(s) have been screened.
0 incoming call(s) rejected for callback.
BRI0:1 - dialer type = ISDN
Idle timer (120 secs), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (15 secs)
Dialer state is data link layer up
Dial reason: Callback return call
Time until disconnect 99 secs
Connected to 5558888 (R2)
Pretty cool! PPP Callback isn’t just important for passing your CCNA and CCNP exams – in circumstances such as shown in this example, it can save your organization quite a bit of money!
In the following example, R2 has been configured as the client and R1 is the callback server. Let's look at both configurations and the unique commands PPP Callback requires.
Client:
username R1 password CCIE
interface BRI0
ip address 172.12.12.2 255.255.255.0
encapsulation ppp
dialer map ip 172.12.12.1 name R1 broadcast 5557777
dialer-group 1
isdn switch-type basic-ni
ppp callback request
ppp authentication chap
Most of that configuration will look familiar to you, but the ppp callback request command might not. This command enables the BRI interface to request the callback.
Simple enough, right? The PPP Callback Server config requires more configuration and an additional map-class as well.
Server:
username R2 password CCIE
interface BRI0
ip address 172.12.12.1 255.255.255.0
encapsulation ppp
dialer callback-secure
dialer map ip 172.12.12.2 name R2 class CALL_R2_BACK broadcast 5558888
dialer-group 1
isdn switch-type basic-ni
ppp callback accept
ppp authentication chap
map-class dialer CALL_R2_BACK
dialer callback-server username
Examining the PPP Callback Server command from the top down...
dialer callback-secure enables security on the callback. If the remote router cannot be authenticated for callback, the incoming call will be disconnected.
The dialer map statement now calls the class CALL_R2_BACK, shown at the bottom of the config excerpt.
ppp callback accept enables PPP callback on this router.
dialer callback-server username tells the callback server that the device referenced in the dialer map statement is a callback client.
The only way to find out if the config works is to test it, so let's send a ping from R2 to R1 and see if the callback takes place.
R2#ping 172.12.12.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.12.12.1, timeout is 2 seconds:
02:45:42: BR0 DDR: Dialing cause ip (s=172.12.12.2, d=172.12.12.1)
02:45:42: BR0 DDR: Attempting to dial 5557777
02:45:42: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
02:45:42: BR0:1 DDR: Callback negotiated - Disconnecting now
02:45:42: BR0:1 DDR: disconnecting call
02:45:42: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 5557777 R1
02:45:42: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
02:45:42: DDR: Callback client for R1 5557777 created
02:45:42: BR0:1 DDR: disconnecting call.....
Success rate is 0 percent (0/5)
R2#
02:45:57: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
R2#
02:45:57: BR0:1 DDR: Callback received from R1 5557777
02:45:57: DDR: Freeing callback to R1 5557777
02:45:57: BR0:1 DDR: dialer protocol up
02:45:58: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up
The callback was successfully negotiated, and the call then disconnected. R1 then called R2 back, and show dialer on R1 confirms the purpose of the call.
R1#show dialer
BRI0 - dialer type = ISDN
Dial String Successes Failures Last DNIS Last status
5558888 2 4 00:00:20 successful
0 incoming call(s) have been screened.
0 incoming call(s) rejected for callback.
BRI0:1 - dialer type = ISDN
Idle timer (120 secs), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (15 secs)
Dialer state is data link layer up
Dial reason: Callback return call
Time until disconnect 99 secs
Connected to 5558888 (R2)
Pretty cool! PPP Callback isn’t just important for passing your CCNA and CCNP exams – in circumstances such as shown in this example, it can save your organization quite a bit of money!
Monday, December 22, 2008
CCNP Certification / BCMSN Exam Tutorial: Server Load Balancing (SLB)
When you're working on your BCMSN exam on your way to CCNP certification, you'll read at length about how Cisco routers and multilayer switches can work to provide router redundancy - but there's another helpful service, Server Load Balancing, that does the same for servers. While HSRP, VRRP, and CLBP all represent multiple physical routers to hosts as a single virtual router, SLB represents multiple physical servers to hosts as a single virtual server.
In the following example, three physical servers have been placed into the SRB group ServFarm. They're represented to the hosts as the virtual server 210.1.1.14.
The hosts will seek to communicate with the server at 210.1.1.14, not knowing that they're actually communicating with the routers in ServFarm. This allows quick cutover if one of the physical servers goes down, and also serves to hide the actual IP addresses of the servers in ServFarm.
The basic operations of SLB involves creating the server farm, followed by creating the virtual server. We'll first add 210.1.1.11 to the server farm:
MLS(config)# ip slb serverfarm ServFarm
MLS(config-slb-sfarm)# real 210.1.1.11
MLS(config-slb-real)# inservice
The first command creates the server farm, with the real command specifying the IP address of the real server. The inservice command is required by SLB to consider the server as ready to handle the server farm's workload. The real and inservice commands should be repeated for each server in the server farm.
To create the virtual server:
MLS(config)# ip slb vserver VIRTUAL_SERVER
MLS(config-slb-vserver)# serverfarm ServFarm
MLS(config-slb-vserver)# virtual 210.1.1.14
MLS(config-slb-vserver)# inservice
From the top down, the vserver was named VIRTUAL_SERVER, which represents the server farm ServFarm. The virtual server is assigned the IP address 210.1.1.14, and connections are allowed once the inservice command is applied.
You may also want to control which of your network hosts can connect to the virtual server. If hosts or subnets are named with the client command, those will be the only clients that can connect to the virtual server. Note that this command uses wildcard masks. The following configuration would allow only the hosts on the subnet 210.1.1.0 /24 to connect to the virtual server.
MLS(config-slb-vserver)# client 210.1.1.0 0.0.0.255
SLB is the server end's answer to HSRP, VRRP, and GLBP - but you still need to know it to become a CCNP! Knowing redundancy strategies and protocols is vital in today's networks, so make sure you're comfortable with SLB before taking on the exam.
In the following example, three physical servers have been placed into the SRB group ServFarm. They're represented to the hosts as the virtual server 210.1.1.14.
The hosts will seek to communicate with the server at 210.1.1.14, not knowing that they're actually communicating with the routers in ServFarm. This allows quick cutover if one of the physical servers goes down, and also serves to hide the actual IP addresses of the servers in ServFarm.
The basic operations of SLB involves creating the server farm, followed by creating the virtual server. We'll first add 210.1.1.11 to the server farm:
MLS(config)# ip slb serverfarm ServFarm
MLS(config-slb-sfarm)# real 210.1.1.11
MLS(config-slb-real)# inservice
The first command creates the server farm, with the real command specifying the IP address of the real server. The inservice command is required by SLB to consider the server as ready to handle the server farm's workload. The real and inservice commands should be repeated for each server in the server farm.
To create the virtual server:
MLS(config)# ip slb vserver VIRTUAL_SERVER
MLS(config-slb-vserver)# serverfarm ServFarm
MLS(config-slb-vserver)# virtual 210.1.1.14
MLS(config-slb-vserver)# inservice
From the top down, the vserver was named VIRTUAL_SERVER, which represents the server farm ServFarm. The virtual server is assigned the IP address 210.1.1.14, and connections are allowed once the inservice command is applied.
You may also want to control which of your network hosts can connect to the virtual server. If hosts or subnets are named with the client command, those will be the only clients that can connect to the virtual server. Note that this command uses wildcard masks. The following configuration would allow only the hosts on the subnet 210.1.1.0 /24 to connect to the virtual server.
MLS(config-slb-vserver)# client 210.1.1.0 0.0.0.255
SLB is the server end's answer to HSRP, VRRP, and GLBP - but you still need to know it to become a CCNP! Knowing redundancy strategies and protocols is vital in today's networks, so make sure you're comfortable with SLB before taking on the exam.
CCNP / BCMSN Exam Tutorial: VLAN Trunking Protocol (VTP)
Passing the BCMSN exam and getting one step closer to the CCNP certification means learning and noticing details that you were not presented with in your CCNA studies. (Yes, I know – you had more than enough details then, right?) One protocol you’ve got to learn more details about is VTP, which seemed simple enough in your CCNA studies! Part of learning the details is mastering the fundamentals, so in this tutorial we’ll review the basics of VTP.
In show vtp status readouts, the "VTP Operating Mode" is set to "Server" by default. The more familiar term for VTP Operating Mode is simply VTP Mode, and Server is the default. It's through the usage of VTP modes that we can place limits on which switches can delete and create VLANs.
In Server mode, a VTP switch can be used to create, modify, and delete VLANs. This means that a VTP deployment has to have at least one switch in Server mode, or VLAN creation will not be possible. Again, this is the default setting for Cisco switches.
Switches running in Client mode cannot be used to create, modify, or delete VLANs. Clients do listen for VTP advertisements and act accordingly when VTP advertisements notify the Client of VLAN changes.
VTP Transparent mode actually means that the switch isn't participating in the VTP domain as Servers and Clients do. (Bear with me here.) Transparent VTP switches don't synchronize their VTP databases with other VTP speakers. They don't even advertise their own VLAN information! Therefore, any VLANs created on a Transparent VTP switch will not be advertised to other VTP speakers in the domain, making them locally significant only. (I know you remember that phrase from your CCNA studies!)
Devices running VTP Transparent mode do have a little something to do with the other switches in the VTP domain, though. When a switch running in Transparent mode receives a VTP advertisement, that switch will forward that advertisement to other switches in that VTP domain.
Configuring switches as VTP Clients is a great way to “tie down” VLAN creation capabilities to switches that are under your physical control. However, this occasionally leads to a situation where only the VTP clients will have ports that belong to a given VLAN, but the VLAN still has to be created on the VTP server. (VLANs can be created and deleted in transparent mode, but those changes aren't advertised to other switches in the VTP domain.)
In the next BCMSN tutorial, we’ll take a look at the details of VTP.
In show vtp status readouts, the "VTP Operating Mode" is set to "Server" by default. The more familiar term for VTP Operating Mode is simply VTP Mode, and Server is the default. It's through the usage of VTP modes that we can place limits on which switches can delete and create VLANs.
In Server mode, a VTP switch can be used to create, modify, and delete VLANs. This means that a VTP deployment has to have at least one switch in Server mode, or VLAN creation will not be possible. Again, this is the default setting for Cisco switches.
Switches running in Client mode cannot be used to create, modify, or delete VLANs. Clients do listen for VTP advertisements and act accordingly when VTP advertisements notify the Client of VLAN changes.
VTP Transparent mode actually means that the switch isn't participating in the VTP domain as Servers and Clients do. (Bear with me here.) Transparent VTP switches don't synchronize their VTP databases with other VTP speakers. They don't even advertise their own VLAN information! Therefore, any VLANs created on a Transparent VTP switch will not be advertised to other VTP speakers in the domain, making them locally significant only. (I know you remember that phrase from your CCNA studies!)
Devices running VTP Transparent mode do have a little something to do with the other switches in the VTP domain, though. When a switch running in Transparent mode receives a VTP advertisement, that switch will forward that advertisement to other switches in that VTP domain.
Configuring switches as VTP Clients is a great way to “tie down” VLAN creation capabilities to switches that are under your physical control. However, this occasionally leads to a situation where only the VTP clients will have ports that belong to a given VLAN, but the VLAN still has to be created on the VTP server. (VLANs can be created and deleted in transparent mode, but those changes aren't advertised to other switches in the VTP domain.)
In the next BCMSN tutorial, we’ll take a look at the details of VTP.
CCNA / CCNP Home Lab Tutorial: Assembling Your Cisco Home Lab
A CCNA or CCNP candidate who wants to be totally prepared for their exams is going to put together a home lab to practice on. With used Cisco routers and switches more affordable and plentiful then ever before, there's really no excuse to not have one!
With the many different models available, there is some understandable confusion among future CCNAs and CCNPs about which routers to buy and which ones to avoid. You can take almost any set of Cisco routers and put together a home lab; part of the learning process is taking what equipment you have available and putting together your own lab! For those of you preparing to start your home lab or add to your existing one, this article will list the routers I use in my Cisco pods. You certainly don't have to have all this equipment, but this will give you some good ideas on how to get started.
The most versatile router you can get for your CCNA / CCNP home lab is a 2520. These routers come with four serial ports, one ethernet port, and one BRI interface for ISDN practice. This mix of interfaces means you can actually use it as a frame relay switch while using the ethernet and BRI ports for routing. (There is no problem with using a lab router as both your frame relay switch and a practice router; for a frame relay switch sample configuration, visit my website!)
My pods consist of five routers and two switches, and three of the five routers are 2520s, due to their versatility. A recent ebay search showed these routers selling for $99 - $125, an outstanding value for the practice you're going to get.
I also use 2501s in my home labs. These have fewer interfaces, but the combination of two serial interfaces and one ethernet interface allows you to get plenty of practice.
A combination that works very well is using three 2520s; one as my dedicated frame relay switch, one as R1, and another as R2. Add a 2501 as R3, and you can have a frame cloud connecting R1, R2, and R3, a direct serial connection between R1 and R3, an Ethernet segment that includes all three routers, and an ISDN connection between R1 and R2 if you have an ISDN simulator. That combination will allow you to get a tremendous amount of practice for the exams, and you can always sell it when you're done!
2501s are very affordable, with many in the $50 range on ebay. It's quite possible to get three 2520s and one 2501 for less than $500 total, and you can get most of that money back if you choose to sell it when you're done.
With four routers to work with, you're probably going to get tired of moving that console cable around. An access server (actually a Cisco router, not the white boxes we tend to think of when we hear "server") will help you out with that. An access server allows you to set up a connection with each of your other routers via an octal cable, which prevents you from moving that console cable around continually. For an example of an access server configuration, just visit my website and look in the "Free Training" section.
Access server prices vary quite a bit; don't panic if you do an ebay search and see them costing thousands of dollars. You do NOT need an expensive access server for your CCNA / CCNP home lab. 2511s are great routers to get for your access server.
One question I get often from CCNA / CCNP candidates is "What routers should I buy that I can still use when I'm ready to study for the CCNP?" The CCIE lab changes regularly and sometimes drastically when it comes to the equipment you'll need. During my CCIE lab studies, I found that renting time from online rack rental providers was actually the best way to go. Don't hesitate when putting your CCNA / CCNP home lab together, wondering what will be acceptable for the CCIE lab a year or so from now. None of us know what's going to be on that equipment list, so get the CCNA and CCNP first - by building your own Cisco home lab!
With the many different models available, there is some understandable confusion among future CCNAs and CCNPs about which routers to buy and which ones to avoid. You can take almost any set of Cisco routers and put together a home lab; part of the learning process is taking what equipment you have available and putting together your own lab! For those of you preparing to start your home lab or add to your existing one, this article will list the routers I use in my Cisco pods. You certainly don't have to have all this equipment, but this will give you some good ideas on how to get started.
The most versatile router you can get for your CCNA / CCNP home lab is a 2520. These routers come with four serial ports, one ethernet port, and one BRI interface for ISDN practice. This mix of interfaces means you can actually use it as a frame relay switch while using the ethernet and BRI ports for routing. (There is no problem with using a lab router as both your frame relay switch and a practice router; for a frame relay switch sample configuration, visit my website!)
My pods consist of five routers and two switches, and three of the five routers are 2520s, due to their versatility. A recent ebay search showed these routers selling for $99 - $125, an outstanding value for the practice you're going to get.
I also use 2501s in my home labs. These have fewer interfaces, but the combination of two serial interfaces and one ethernet interface allows you to get plenty of practice.
A combination that works very well is using three 2520s; one as my dedicated frame relay switch, one as R1, and another as R2. Add a 2501 as R3, and you can have a frame cloud connecting R1, R2, and R3, a direct serial connection between R1 and R3, an Ethernet segment that includes all three routers, and an ISDN connection between R1 and R2 if you have an ISDN simulator. That combination will allow you to get a tremendous amount of practice for the exams, and you can always sell it when you're done!
2501s are very affordable, with many in the $50 range on ebay. It's quite possible to get three 2520s and one 2501 for less than $500 total, and you can get most of that money back if you choose to sell it when you're done.
With four routers to work with, you're probably going to get tired of moving that console cable around. An access server (actually a Cisco router, not the white boxes we tend to think of when we hear "server") will help you out with that. An access server allows you to set up a connection with each of your other routers via an octal cable, which prevents you from moving that console cable around continually. For an example of an access server configuration, just visit my website and look in the "Free Training" section.
Access server prices vary quite a bit; don't panic if you do an ebay search and see them costing thousands of dollars. You do NOT need an expensive access server for your CCNA / CCNP home lab. 2511s are great routers to get for your access server.
One question I get often from CCNA / CCNP candidates is "What routers should I buy that I can still use when I'm ready to study for the CCNP?" The CCIE lab changes regularly and sometimes drastically when it comes to the equipment you'll need. During my CCIE lab studies, I found that renting time from online rack rental providers was actually the best way to go. Don't hesitate when putting your CCNA / CCNP home lab together, wondering what will be acceptable for the CCIE lab a year or so from now. None of us know what's going to be on that equipment list, so get the CCNA and CCNP first - by building your own Cisco home lab!
Subscribe to:
Posts (Atom)
