CCNA and CCNP candidates need to know all about Setup Mode, why a router goes into that mode, and as you'll see, how to get out of that mode. Practicing Setup Mode at work is a good way to get fired, though, so you need to practice this on your CCNA / CCNP home lab or rack rental. In this article, we'll take a look at a Cisco 2500 router going into setup mode and a few tips that will help you pass the exams and excel at your job.
First, why does a router go into Setup Mode in the first place? When a Cisco router boots up, the router looks into Non-Volatile RAM (NVRAM) for the startup configuration file. If such a file is not found, and the router has not been programmed to look to a TFTP server for this file, the router enters setup mode.
The most common reason for a router not to have a startup configuration file is that the file's been erased. We will now erase this file on our 2500 router. As you'll see, the Cisco router warns us about erasing NVRAM and makes us confirm this choice, which it acknowledges with the OK message.
R1#write erase
Erasing the nvram filesystem will remove all files! Continue? [confirm]
[OK]
Erase of nvram: complete
R1#
The router will now be reloaded. There is a slightly misleading message displayed during reboot:
R1#reload
Proceed with reload? [confirm]
00:15:21: %SYS-5-RELOAD: Reload requested
System Bootstrap, Version 11.0(10c)XB1, PLATFORM SPECIFIC RELEASE SOFTWARE (fc1)
Copyright (c) 1986-1997 by cisco Systems
2500 processor with 14336 Kbytes of main memory
Notice: NVRAM invalid, possibly due to write erase.
That notice doesn't mean the NVRAM is corrupt or unusable; this message means the NVRAM doesn't have a startup configuration file.
The router will continue to boot and finally present you with this prompt:
--- System Configuration Dialog ---
Would you like to enter the initial configuration dialog? [yes/no]:
Almost every WAN engineer I know answers "no" to this question, because Setup Mode is a long, clumsy way to set up a router (in my humble opinion). We will answer "yes" in order to see this mode in action.
--- System Configuration Dialog ---
Would you like to enter the initial configuration dialog? [yes/no]: y
At any point you may enter a question mark '?' for help.
Use ctrl-c to abort configuration dialog at any prompt.
Default settings are in square brackets '[]'.
Basic management setup configures only enough connectivity
for management of the system, extended setup will ask you
to configure each interface on the system
Would you like to enter basic management setup? [yes/no]: y
Configuring global parameters:
Enter host name [Router]: R1
The enable secret is a password used to protect access to
privileged EXEC and configuration modes. This password, after
entered, becomes encrypted in the configuration.
Enter enable secret:
% No defaulting allowed
Enter enable secret:
Already, there's something about Setup Mode that you might not like. This mode forces you to set an enable password and an enable secret password. As you continue in this mode, you'll see this mode ask you questions about every single interface on the router, even if you're not planning to use that interface. Using Setup Mode really does get quite old after a while, again in my opinion.
One of the most important things about Setup Mode is knowing how to get out of it without saving the configuration. One way is at the very end of this mode, where you can answer "no" to "Do you want to save this configuration?" I personally never make it that far! Instead of waiting until the end of Setup Mode, we can use the CTRL-C key combination to abort this mode and ignore the changes.
Configuration aborted, no changes made.
Press RETURN to get started!
Setup Mode is not a mode that CCNA and CCNP candidates get a great deal of practice with, but you will be tested on your knowledge about it both in the exam room and on the job. And once you start configuring a router with this mode, you'll be glad you know how to get out of it!
Showing posts with label bcran. Show all posts
Showing posts with label bcran. Show all posts
Saturday, December 27, 2008
Friday, December 26, 2008
Passing Cisco's CCNA and CCNP Exams: Five Tips For Exam Day Success
As you get ready to pass the CCNA or CCNP exams, you can feel quite a bit of stress as you enter your last week of study. Let's take a look at a few ways to reduce that stress.
1. Do not stay up late cramming. The CCNA and CCNP are not exams you're going to pass by cramming. "Cramming" is a study technique best left behind in junior high school. The CCNA can't be passed by memorization - you've got to know how Cisco technologies work. That leads us to the second point...
2. Get lots of rest. By far, this is the most overlooked factor on exam day. The CCNA and CCNP exams are going to demand your best. You're going to be performing subnetting, binary and hex conversions, analyzing network diagrams for troubleshooting, and much more. You've got to be mentally sharp. You can add 100 points to your exam score just by showing up well-rested. And let's be realistic - if you don't know something at 11 PM the night before your exam, you're not going to learn it overnight. Get some sleep!
3. Get everything together the night before the exam. You don't want to be running around the house the morning of the exam looking for your keys. Make sure you have your keys and your ID the night before the exam.
4. Know where the testing center is. If you've never been to the center you'll be passing the CCNA in before, go there before the morning of the exam. Do not rely on Mapquest or a friend's directions. You don't want to be late for your exam.
5. Allow for traffic. Many CCNA and CCNP candidates prefer to take their exams in the morning. Again, if you haven't been to the exam center before, you should drive there during morning rush hour traffic before your exam date to make sure you have enough time to get there. You don't want to be sitting in traffic when you should be sitting in the exam room!
1. Do not stay up late cramming. The CCNA and CCNP are not exams you're going to pass by cramming. "Cramming" is a study technique best left behind in junior high school. The CCNA can't be passed by memorization - you've got to know how Cisco technologies work. That leads us to the second point...
2. Get lots of rest. By far, this is the most overlooked factor on exam day. The CCNA and CCNP exams are going to demand your best. You're going to be performing subnetting, binary and hex conversions, analyzing network diagrams for troubleshooting, and much more. You've got to be mentally sharp. You can add 100 points to your exam score just by showing up well-rested. And let's be realistic - if you don't know something at 11 PM the night before your exam, you're not going to learn it overnight. Get some sleep!
3. Get everything together the night before the exam. You don't want to be running around the house the morning of the exam looking for your keys. Make sure you have your keys and your ID the night before the exam.
4. Know where the testing center is. If you've never been to the center you'll be passing the CCNA in before, go there before the morning of the exam. Do not rely on Mapquest or a friend's directions. You don't want to be late for your exam.
5. Allow for traffic. Many CCNA and CCNP candidates prefer to take their exams in the morning. Again, if you haven't been to the exam center before, you should drive there during morning rush hour traffic before your exam date to make sure you have enough time to get there. You don't want to be sitting in traffic when you should be sitting in the exam room!
How To Become a Cisco CCNP
Congratulations on your decision to earn your CCNP certification! As a CCIE, I can tell you that Cisco certifications are both financially and personally rewarding.
To earn your CCNP, you first have to earn your CCNA certification. Then you're faced with a decision - take the three-exam CCNP path, or the four-exam path? They're both quite demanding, so let's take a look at each path.
The four-exam CCNP path includes the Building Scalable Cisco Internetworks exam (BSCI), Building Cisco Multilayer Switched Networks exam (BCMSN), Building Cisco Remote Access Networks (BCRAN), and Cisco Internetwork Troubleshooting (CIT) exam.
The three-exam path combines the BSCI and BCMSN exams into a single exam, called the Composite exam.
I'm often asked what order I recommend taking the exams in. After earning your CCNA, I recommend you begin studying for the BSCI exam immediately. You will find the fundamentals you learned in your CCNA studies will help you a great deal with this exam. You're going to add to your CCNA knowledgebase quite a bit when it comes to OSPF and EIGRP, as well as being introduced to BGP.
I don't have a preference between the BCMSN and BCRAN exams, but I do recommend you take the CIT exam last. You'll be using all the skills you learned in the first three exams to pass the CIT. It's a very demanding exam, and it's a little hard to troubleshoot technologies that you haven't learned yet!
The CCNP is both financially and personally fulfilling. Once you complete your CCNA studies, take a little breather and then get started on your CCNP studies. The more you know, the more valuable you are in today's ever-changing IT job market.
To earn your CCNP, you first have to earn your CCNA certification. Then you're faced with a decision - take the three-exam CCNP path, or the four-exam path? They're both quite demanding, so let's take a look at each path.
The four-exam CCNP path includes the Building Scalable Cisco Internetworks exam (BSCI), Building Cisco Multilayer Switched Networks exam (BCMSN), Building Cisco Remote Access Networks (BCRAN), and Cisco Internetwork Troubleshooting (CIT) exam.
The three-exam path combines the BSCI and BCMSN exams into a single exam, called the Composite exam.
I'm often asked what order I recommend taking the exams in. After earning your CCNA, I recommend you begin studying for the BSCI exam immediately. You will find the fundamentals you learned in your CCNA studies will help you a great deal with this exam. You're going to add to your CCNA knowledgebase quite a bit when it comes to OSPF and EIGRP, as well as being introduced to BGP.
I don't have a preference between the BCMSN and BCRAN exams, but I do recommend you take the CIT exam last. You'll be using all the skills you learned in the first three exams to pass the CIT. It's a very demanding exam, and it's a little hard to troubleshoot technologies that you haven't learned yet!
The CCNP is both financially and personally fulfilling. Once you complete your CCNA studies, take a little breather and then get started on your CCNP studies. The more you know, the more valuable you are in today's ever-changing IT job market.
Four Important Commands For Your CCNA / CCNP Home Lab
More CCNA and CCNP candidates than ever before are putting together their own home practice labs. It's more affordable than it ever has been, and I receive emails daily from new CCNAs and CCNPs who say it's the best thing they could have done to improve their studies.
There are some commands you can configure on your lab routers that won't necessarily be on your CCNA or CCNP exams, but they will make life a lot easier for you. Let's take a look at just a few of these.
The command "no exec" is short, yet powerful. Occasionally you'll have what is referred to as a "rogue EXEC" process tie up a line, and you end up having to continually clear lines, which disrupts your practice. If you have an access server, I highly recommend you configure this command on your lines, as shown here:
ACCESS_SERVER(con)#line 1 8
ACCESS_SERVER(con)#no exec
From your CCNA studies, you know that the command "no ip domain-lookup" prevents a Cisco router from sending a broadcast to find a DNS server anytime you enter something that is not an IOS command - and that includes mistyped commands, which happens to all of us sooner or later. Make sure to run that command in global configuration mode on all your practice routers.
There are two commands I like to configure on the console line on all my practice routers and switches. The first is "exec-timeout 0 0", which prevents you from being kicked out of enable mode and back into user exec after a few minutes of inactivity. (This doesn't sound like much, but you'll get pretty tired of typing "enable" after a while.) The first zero refers to minutes, the second zero to seconds. Setting them both to zero disables the exec-timeout function.
The second command prevents the router from interrupting the command you're typing with a console message. If you've ever been in the middle of typing a router command and suddenly you're interrupted with a logging message, you know that can be pretty annoying. We don't want the router to not display the message, but we do want the router to wait until we're done entering data. The command to perform this is "logging synchronous".
R1(config)#line console 0
R1(config-line)#exec-timeout 0 0
R1(config-line)#logging synchronous
You won't see many of these commands on your exams, but after you configure them on your home lab devices, you'll wonder how you did without them!
There are some commands you can configure on your lab routers that won't necessarily be on your CCNA or CCNP exams, but they will make life a lot easier for you. Let's take a look at just a few of these.
The command "no exec" is short, yet powerful. Occasionally you'll have what is referred to as a "rogue EXEC" process tie up a line, and you end up having to continually clear lines, which disrupts your practice. If you have an access server, I highly recommend you configure this command on your lines, as shown here:
ACCESS_SERVER(con)#line 1 8
ACCESS_SERVER(con)#no exec
From your CCNA studies, you know that the command "no ip domain-lookup" prevents a Cisco router from sending a broadcast to find a DNS server anytime you enter something that is not an IOS command - and that includes mistyped commands, which happens to all of us sooner or later. Make sure to run that command in global configuration mode on all your practice routers.
There are two commands I like to configure on the console line on all my practice routers and switches. The first is "exec-timeout 0 0", which prevents you from being kicked out of enable mode and back into user exec after a few minutes of inactivity. (This doesn't sound like much, but you'll get pretty tired of typing "enable" after a while.) The first zero refers to minutes, the second zero to seconds. Setting them both to zero disables the exec-timeout function.
The second command prevents the router from interrupting the command you're typing with a console message. If you've ever been in the middle of typing a router command and suddenly you're interrupted with a logging message, you know that can be pretty annoying. We don't want the router to not display the message, but we do want the router to wait until we're done entering data. The command to perform this is "logging synchronous".
R1(config)#line console 0
R1(config-line)#exec-timeout 0 0
R1(config-line)#logging synchronous
You won't see many of these commands on your exams, but after you configure them on your home lab devices, you'll wonder how you did without them!
Cisco Certification: Recertifying Your CCNA and CCNP
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!
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!
Thursday, December 25, 2008
Cisco Certification: In What Order Should You Take Your CCNP Exams ?
When you choose to pursue your Cisco Certified Network Professional certification, you've got some decisions to make right at the beginning. Cisco offers a three-exam path and a four-exam path, and you select the order in which you'll take and pass the exams.
While every CCNP candidate has to make their own decision, I'd like to share some thoughts based on my personal experience and the experiences of CCNPs worldwide.
The solid foundation of networking knowledge you built as a CCNA will help you a great deal on your BSCI (Building Scalable Cisco Internetworks, 642-801) exam. This is the most common exam to take first, and I'd recommend you do so as well. While there are some topics that will be new to you, such as BGP, many of the BSCI topics will be familiar to you from your CCNA studies.
The "middle" exams are the BCMSN (Building Cisco Multilayer Switched Networks, 642-811) and BCRAN (Building Cisco Remote Access Networks, 642-821). There is no real advantage in taking one of these before the other, although most candidates take the switching exam, then the remote access exam.
I do recommend you take the CIT (Cisco Internetwork Troubleshooting) exam last. This exam will demand you put into action the skills you have learned while earning your CCNA and passing the first three exams. Again, it's not written in stone and there are always exceptions, but CCNP candidates do seem to have more success on this exam when they take it last.
Should you choose the three-exam path, you'll be taking a Composite exam (642-891). This exam combines the BSCI and BCMSN exams, and it's best to take this one first. It builds nicely with your CCNA skills.
Again, I would take the BCRAN exam after the Composite, and t
he Troubleshooting exam last.
Whichever path you choose, you've chosen wisely in which certification to pursue. The CCNP is a true test of your networking skills, and when you make the decision to go after the CCIE, you'll be glad to have the solid foundation of networking skills your CCNA and CCNP studies gave you.
While every CCNP candidate has to make their own decision, I'd like to share some thoughts based on my personal experience and the experiences of CCNPs worldwide.
The solid foundation of networking knowledge you built as a CCNA will help you a great deal on your BSCI (Building Scalable Cisco Internetworks, 642-801) exam. This is the most common exam to take first, and I'd recommend you do so as well. While there are some topics that will be new to you, such as BGP, many of the BSCI topics will be familiar to you from your CCNA studies.
The "middle" exams are the BCMSN (Building Cisco Multilayer Switched Networks, 642-811) and BCRAN (Building Cisco Remote Access Networks, 642-821). There is no real advantage in taking one of these before the other, although most candidates take the switching exam, then the remote access exam.
I do recommend you take the CIT (Cisco Internetwork Troubleshooting) exam last. This exam will demand you put into action the skills you have learned while earning your CCNA and passing the first three exams. Again, it's not written in stone and there are always exceptions, but CCNP candidates do seem to have more success on this exam when they take it last.
Should you choose the three-exam path, you'll be taking a Composite exam (642-891). This exam combines the BSCI and BCMSN exams, and it's best to take this one first. It builds nicely with your CCNA skills.
Again, I would take the BCRAN exam after the Composite, and t
he Troubleshooting exam last.
Whichever path you choose, you've chosen wisely in which certification to pursue. The CCNP is a true test of your networking skills, and when you make the decision to go after the CCIE, you'll be glad to have the solid foundation of networking skills your CCNA and CCNP studies gave you.
Cisco CCNP Certification FAQ
To earn your CCNP, you've got to pass some very rigorous Cisco exams, and you also need to know the rules regarding this important certification. In this article, I'll answer some of the most commonly asked questions regarding the CCNP.
Q: What exams do I need to pass to get my CCNP?
A: You have two options, a three-exam path and a four-exam path. Currently, the four-exam path consists of rigorous exams on advanced routing techniques (BSCI), advanced switching (BCMSN), remote access methods (BCRAN), and advanced troubleshooting techniques (CIT). The three-exam path combines the BCMSN and BSCI exams into a single exam, the Composite exam.
Q: Do I have to take them in any order?
A: No, the order is up to the candidate. Most CCNP candidates take the BSCI exam first and the CIT exam last, but again this is up to the candidate.
Q: What else do I have to do to get the CCNP?
A: You must earn your CCNA before you can be CCNP certified (as well as passing the exams, of course).
Q: Is there a recertification requirement?
A: Cisco CCNP certifications are valid for three years. During that time, you must either pass the Composite exam, the BSCI and BCMSN exams, or pass any CCIE written exam.
Q: What if I don't recertify within the three-year period?
A: You must then meet whatever CCNP requirements there are at that time, from the beginning. It's easier to make sure you recertify!
Becoming CCNP certified is a great boost to your career and your confidence, and as with any Cisco certification, it's up to you to stay current with the CCNA and CCNP requirements. Visit the Career Certification section of Cisco's website regularly to learn about the program's requirements and changes.
Q: What exams do I need to pass to get my CCNP?
A: You have two options, a three-exam path and a four-exam path. Currently, the four-exam path consists of rigorous exams on advanced routing techniques (BSCI), advanced switching (BCMSN), remote access methods (BCRAN), and advanced troubleshooting techniques (CIT). The three-exam path combines the BCMSN and BSCI exams into a single exam, the Composite exam.
Q: Do I have to take them in any order?
A: No, the order is up to the candidate. Most CCNP candidates take the BSCI exam first and the CIT exam last, but again this is up to the candidate.
Q: What else do I have to do to get the CCNP?
A: You must earn your CCNA before you can be CCNP certified (as well as passing the exams, of course).
Q: Is there a recertification requirement?
A: Cisco CCNP certifications are valid for three years. During that time, you must either pass the Composite exam, the BSCI and BCMSN exams, or pass any CCIE written exam.
Q: What if I don't recertify within the three-year period?
A: You must then meet whatever CCNP requirements there are at that time, from the beginning. It's easier to make sure you recertify!
Becoming CCNP certified is a great boost to your career and your confidence, and as with any Cisco certification, it's up to you to stay current with the CCNA and CCNP requirements. Visit the Career Certification section of Cisco's website regularly to learn about the program's requirements and changes.
Cisco CCNP Certification: Using The BGP Command “Update-Source”
When you start preparing for your CCNP exam, particularly the BSCI exam, you're introduced to Border Gateway Protocol (BGP) configurations. BGP is unlike any protocol you learned during your CCNA studies, and even the similarities are a little bit different!
BGP forms neighbor relationships, much like EIGRP and OSPF do. The interesting thing with BGP is that potential neighbors, or "peers", do not need to be directly connected and can use their loopback interfaces to form the peer relationships.
It may well be to your advantage to use loopbacks to form peer relationships rather than the actual interface facing the potential neighbor. This can be done because BGP uses static neighbor statements rather than any kind of dynamic neighbor discovery process.
Consider a router that has two paths to a BGP speaker. The interfaces are numbered like this:
Router1: Serial0, 172.1.1.1 /24, Serial2, 179.1.1.1 /24, loopback0, 1.1.1.1 /32.
Router2: Serial0, 172.1.1.2/24, Serial2 179.1.1.2/24, loopback0, 2.2.2.2 /32.
We could configure Router1 like this:
router bgp 200
neighbor 172.1.1.2 remote-as 200
In this case, BGP would automatically use 172.1.1.1 as the source for the TCP connection that has to be set up with the neighbor before updates can be exchanged; this address is known as the best local address. However, if the remote peer's serial0 interface is shut down or goes down for another reason, the peer relationship would be lost even though Router2 is still available.
Instead of using one of the physical interfaces, we can use the loopbacks on each router to establish the TCP-based peer connection. The configurations would look like this:
Router1:
router bgp 200
neighbor 2.2.2.2 remote-as 200
neighbor 2.2.2.2 update-source loopback0
Router2:
router bgp 200
neighbor 1.1.1.1 remote-as 200
neighbor 1.1.1.1 update-source loopback0
In this case, losing one of the physical connections does not necessarily mean the BGP peering is lost; as long as the routers have a valid path to each other's loopback addresses, the BGP peer relationship will stay in place. And better yet, we avoid the dreaded “single point of failure
BGP forms neighbor relationships, much like EIGRP and OSPF do. The interesting thing with BGP is that potential neighbors, or "peers", do not need to be directly connected and can use their loopback interfaces to form the peer relationships.
It may well be to your advantage to use loopbacks to form peer relationships rather than the actual interface facing the potential neighbor. This can be done because BGP uses static neighbor statements rather than any kind of dynamic neighbor discovery process.
Consider a router that has two paths to a BGP speaker. The interfaces are numbered like this:
Router1: Serial0, 172.1.1.1 /24, Serial2, 179.1.1.1 /24, loopback0, 1.1.1.1 /32.
Router2: Serial0, 172.1.1.2/24, Serial2 179.1.1.2/24, loopback0, 2.2.2.2 /32.
We could configure Router1 like this:
router bgp 200
neighbor 172.1.1.2 remote-as 200
In this case, BGP would automatically use 172.1.1.1 as the source for the TCP connection that has to be set up with the neighbor before updates can be exchanged; this address is known as the best local address. However, if the remote peer's serial0 interface is shut down or goes down for another reason, the peer relationship would be lost even though Router2 is still available.
Instead of using one of the physical interfaces, we can use the loopbacks on each router to establish the TCP-based peer connection. The configurations would look like this:
Router1:
router bgp 200
neighbor 2.2.2.2 remote-as 200
neighbor 2.2.2.2 update-source loopback0
Router2:
router bgp 200
neighbor 1.1.1.1 remote-as 200
neighbor 1.1.1.1 update-source loopback0
In this case, losing one of the physical connections does not necessarily mean the BGP peering is lost; as long as the routers have a valid path to each other's loopback addresses, the BGP peer relationship will stay in place. And better yet, we avoid the dreaded “single point of failure
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!
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!
Cisco CCNA / CCNP Certification Exam Tutorial: ISDN And Multilink PPP
ISDN is a huge topic on both your Cisco CCNA and BCRAN CCNP exams. While many ISDN topics seem straightforward, it’s the details that make the difference in the exam room and working with ISDN in production networks. Configuring and troubleshooting multilink PPP is just one of the skills you’ll need to pass both of these demanding exams.
With BRI, we've got two B-channels to carry data, and both of them have a 64-kbps capacity. You might think it would be a good idea to have both channels in operation before one reaches capacity, and it is a great idea Problem is, it's not a default behavior of ISDN. The second b-channel will not begin to carry traffic until the first one reaches capacity.
With Multilink PPP (MLP), a bandwidth capacity can be set that will allow the second b-channel to bear data before the first channel reaches capacity. The configuration for MLP is simple, but often misconfigured. We'll use our good friend IOS Help to verify the measurement this command uses.
Enabling MLP is a three-step process:
Enable PPP on the link
Enable MLP with the command ppp multilink
Define the threshold at which the second b-channel should start carrying data with the dialer load-threshold command.
Let's say you wanted the second b-channel to start carrying data when the first channel reaches 75% of capacity. It would make sense that the command to do so would be dialer load-threshold 75... but it's not.
R1(config)#int bri0
R1(config-if)#ppp multilink
R1(config-if)#dialer load-threshold ?
<1-255> Load threshold to place another call
The dialer load-threshold value is based on 255, not 100. To have this command bring the line up at a certain percentage, multiply that percentage in decimal format by 255. Below, I multiplied 255 by .75 (75%) to arrive at 191.
R1(config-if)#dialer load-threshold 191 ?
either Threshold decision based on max of inbound and outbound traffic
inbound Threshold decision based on inbound traffic only
outbound Threshold decision based on outbound traffic only
R1(config-if)#dialer load-threshold 191 either
As illustrated by IOS Help in the above configuration, dialer load-threshold has additional options as well. You can configure the interface to consider only incoming, outgoing, or all traffic when calculating when to bring the next channel up.
Configuring Multilink PPP is just one of the skills you’ll need to earn your CCNA and pass the CCNP BCRAN exam. Don’t underestimate ISDN on Cisco’s certification exams!
With BRI, we've got two B-channels to carry data, and both of them have a 64-kbps capacity. You might think it would be a good idea to have both channels in operation before one reaches capacity, and it is a great idea Problem is, it's not a default behavior of ISDN. The second b-channel will not begin to carry traffic until the first one reaches capacity.
With Multilink PPP (MLP), a bandwidth capacity can be set that will allow the second b-channel to bear data before the first channel reaches capacity. The configuration for MLP is simple, but often misconfigured. We'll use our good friend IOS Help to verify the measurement this command uses.
Enabling MLP is a three-step process:
Enable PPP on the link
Enable MLP with the command ppp multilink
Define the threshold at which the second b-channel should start carrying data with the dialer load-threshold command.
Let's say you wanted the second b-channel to start carrying data when the first channel reaches 75% of capacity. It would make sense that the command to do so would be dialer load-threshold 75... but it's not.
R1(config)#int bri0
R1(config-if)#ppp multilink
R1(config-if)#dialer load-threshold ?
<1-255> Load threshold to place another call
The dialer load-threshold value is based on 255, not 100. To have this command bring the line up at a certain percentage, multiply that percentage in decimal format by 255. Below, I multiplied 255 by .75 (75%) to arrive at 191.
R1(config-if)#dialer load-threshold 191 ?
either Threshold decision based on max of inbound and outbound traffic
inbound Threshold decision based on inbound traffic only
outbound Threshold decision based on outbound traffic only
R1(config-if)#dialer load-threshold 191 either
As illustrated by IOS Help in the above configuration, dialer load-threshold has additional options as well. You can configure the interface to consider only incoming, outgoing, or all traffic when calculating when to bring the next channel up.
Configuring Multilink PPP is just one of the skills you’ll need to earn your CCNA and pass the CCNP BCRAN exam. Don’t underestimate ISDN on Cisco’s certification exams!
Cisco CCNA / CCNP Certification Exam: Same Command, Different Results
As a CCNA or CCNP, one thing you've got to get used to is that change is constant. Cisco regularly issues new IOS versions, not to mention the many different kinds of hardware they produce! While it's always nice to have "the latest and the greatest" when it comes to routers, switches, firewalls, etc., we have to be prepared for the fact that not all our clients are going to have that latest and greatest!
For instance, there are still quite a few Catalyst 5000 switches out there humming away, and if you're used to working on IOS-driven switches like the 2950, the same command can have dramatically different results.
Let's say you're going to examine the spanning tree protocol (STP) setup of a new client. You're used to working with newer 2950 switches, and you've always run show span on those switches to display spanning-tree information. Then, you run show span on a Catalyst 5000 - and something like this shows:
switch (enable) show span
Destination : Port 6/1
Admin Source : Port 6/2
Oper Source : Port 6/2
Direction : transmit/receive
Incoming Packets: disabled
Learning : enabled
Multicast : enabled
Filter : -
Status : active
Total local span sessions: 1
What's going on here?
The command show span on a 5000 will not show spanning tree stats - instead, what you're going to see are statistics relating to Switched Port ANalyzer (SPAN). Surprise!
Consider an example where you're used to running show span on 5000 switches to see SPAN information. When you run that on a 2950, you know now what you're going to get - spanning tree information! On a 2950, you'll need to run show monitor session, followed by the SPAN session number.
SW1#show monitor session 1
Session 1
---------
Type : Local Session
Source Ports :
Both : Fa0/1
Destination Ports : Fa0/2
Encapsulation : Native
Ingress: Disabled
As a CCNA and CCNP, this is one of those things you just have to get used to. Commands are going to be different, sometimes radically so, between models. That's why you need to be adept with both IOS Help and Cisco's online documentation site. IOS Help is easy, but the online doc site take a little getting used to. Once you learn how to navigate that site, a world of Cisco knowledge is at your fingertips.
Besides, when you sit for the CCIE lab exam, that will be the only friend you have! And a valuable friend it can be - you're just going to have to trust me on that one. :)
For instance, there are still quite a few Catalyst 5000 switches out there humming away, and if you're used to working on IOS-driven switches like the 2950, the same command can have dramatically different results.
Let's say you're going to examine the spanning tree protocol (STP) setup of a new client. You're used to working with newer 2950 switches, and you've always run show span on those switches to display spanning-tree information. Then, you run show span on a Catalyst 5000 - and something like this shows:
switch (enable) show span
Destination : Port 6/1
Admin Source : Port 6/2
Oper Source : Port 6/2
Direction : transmit/receive
Incoming Packets: disabled
Learning : enabled
Multicast : enabled
Filter : -
Status : active
Total local span sessions: 1
What's going on here?
The command show span on a 5000 will not show spanning tree stats - instead, what you're going to see are statistics relating to Switched Port ANalyzer (SPAN). Surprise!
Consider an example where you're used to running show span on 5000 switches to see SPAN information. When you run that on a 2950, you know now what you're going to get - spanning tree information! On a 2950, you'll need to run show monitor session, followed by the SPAN session number.
SW1#show monitor session 1
Session 1
---------
Type : Local Session
Source Ports :
Both : Fa0/1
Destination Ports : Fa0/2
Encapsulation : Native
Ingress: Disabled
As a CCNA and CCNP, this is one of those things you just have to get used to. Commands are going to be different, sometimes radically so, between models. That's why you need to be adept with both IOS Help and Cisco's online documentation site. IOS Help is easy, but the online doc site take a little getting used to. Once you learn how to navigate that site, a world of Cisco knowledge is at your fingertips.
Besides, when you sit for the CCIE lab exam, that will be the only friend you have! And a valuable friend it can be - you're just going to have to trust me on that one. :)
Cisco CCNA / CCNP Certification Exam: Caller ID Screening And Callback
As a CCNA and/or CCNP candidate, you've got to be able to spot situations where Cisco router features can save your client money and time. For example, if a spoke router is calling a hub router and the toll charges at the spoke site are higher than that of the hub router, having the hub router hang up initially and then call the spoke router back can save the client money (and make you look good!)
A popular method of doing this is using PPP callback, but as we all know, it's a good idea to know more than one way to do things in Cisco World! A lesser-known but still effective method of callback is Caller ID Screening & Callback. Before we look at the callback feature, though, we need to know what Caller ID Screening is in the first place!
This feature is often referred to simply as "Caller ID", which can be a little misleading if you've never seen this service in operation before. To most of us, Caller ID is a phone service that displays the source phone number of an incoming call. Caller ID Screening has a different meaning, though. Caller ID Screening on a Cisco router is really another kind of password - it defines the phone numbers that are allowed to call the router.
The list of acceptable source phone numbers is created with the isdn caller command. Luckily for us, this command allows the use of x to specify a wildcard number. The command isdn caller 555xxxx results in calls being accepted from any 7-digit phone number beginning with 555, and rejected in all other cases. We'll configure R2 to do just that and then send a ping from R1 to R2. To see the results of the Caller ID Screening, debug dialer will be run on R1 before sending the ping. I’ve edited this output, since the output you see here will be repeated fire times – once for each ping packet.
R2(config-if)#isdn caller 555xxxx
R1#debug dialer
Dial on demand events debugging is on
R1#ping 172.12.12.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.12.12.2, timeout is 2 seconds:
03:30:25: BR0 DDR: Dialing cause ip (s=172.12.12.1, d=172.12.12.2)
03:30:25: BR0 DDR: Attempting to dial 8358662.
Success rate is 0 percent (0/5)
R1 doesn't give us any hints as to what the problem is, but we can see that the pings definitely aren't going through. On R2, show dialer displays the number of screened calls.
R2#show dialer
BRI0 - dialer type = ISDN
Dial String Successes Failures Last DNIS Last status
8358661 1 0 00:03:16 successful
7 incoming call(s) have been screened.
0 incoming call(s) rejected for callback.
The callback option mentioned in the last line shown above enables the router to reject a phone call, and then call that router back seconds later.
R2 will now be configured to initially hang up on R1, and then call R1 back.
R2(config-if)#isdn caller 8358661 callback
R1 will now ping R2. The pings aren't returned, but seconds later R2 calls R1 back.
R1#ping 172.12.12.2
Success rate is 0 percent (0/5)
R1#
03:48:12: BRI0: wait for isdn carrier timeout, call id=0x8023
R1#
03:48:18: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
R1#
03:48:18: BR0:1 DDR: dialer protocol up
R1#
03:48:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up
R1#
03:48:24: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8358662 R2
show dialer on R2 shows the reason for the call to R1 is a callback return call.
R2#show dialer
BRI0 - dialer type = ISDN
Dial String Successes Failures Last DNIS Last status
8358661 3 0 00:00:48 successful
7 incoming call(s) have been screened.
10 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 71 secs
Connected to 8358661 (R1)
The drawback to Caller ID Callback is that not all telco switches support it, so if you have the choice between this and PPP Callback, you're probably better off with PPP Callback. However, it's always a good idea to know more than one way to get things done with Cisco!
A popular method of doing this is using PPP callback, but as we all know, it's a good idea to know more than one way to do things in Cisco World! A lesser-known but still effective method of callback is Caller ID Screening & Callback. Before we look at the callback feature, though, we need to know what Caller ID Screening is in the first place!
This feature is often referred to simply as "Caller ID", which can be a little misleading if you've never seen this service in operation before. To most of us, Caller ID is a phone service that displays the source phone number of an incoming call. Caller ID Screening has a different meaning, though. Caller ID Screening on a Cisco router is really another kind of password - it defines the phone numbers that are allowed to call the router.
The list of acceptable source phone numbers is created with the isdn caller command. Luckily for us, this command allows the use of x to specify a wildcard number. The command isdn caller 555xxxx results in calls being accepted from any 7-digit phone number beginning with 555, and rejected in all other cases. We'll configure R2 to do just that and then send a ping from R1 to R2. To see the results of the Caller ID Screening, debug dialer will be run on R1 before sending the ping. I’ve edited this output, since the output you see here will be repeated fire times – once for each ping packet.
R2(config-if)#isdn caller 555xxxx
R1#debug dialer
Dial on demand events debugging is on
R1#ping 172.12.12.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.12.12.2, timeout is 2 seconds:
03:30:25: BR0 DDR: Dialing cause ip (s=172.12.12.1, d=172.12.12.2)
03:30:25: BR0 DDR: Attempting to dial 8358662.
Success rate is 0 percent (0/5)
R1 doesn't give us any hints as to what the problem is, but we can see that the pings definitely aren't going through. On R2, show dialer displays the number of screened calls.
R2#show dialer
BRI0 - dialer type = ISDN
Dial String Successes Failures Last DNIS Last status
8358661 1 0 00:03:16 successful
7 incoming call(s) have been screened.
0 incoming call(s) rejected for callback.
The callback option mentioned in the last line shown above enables the router to reject a phone call, and then call that router back seconds later.
R2 will now be configured to initially hang up on R1, and then call R1 back.
R2(config-if)#isdn caller 8358661 callback
R1 will now ping R2. The pings aren't returned, but seconds later R2 calls R1 back.
R1#ping 172.12.12.2
Success rate is 0 percent (0/5)
R1#
03:48:12: BRI0: wait for isdn carrier timeout, call id=0x8023
R1#
03:48:18: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
R1#
03:48:18: BR0:1 DDR: dialer protocol up
R1#
03:48:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up
R1#
03:48:24: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8358662 R2
show dialer on R2 shows the reason for the call to R1 is a callback return call.
R2#show dialer
BRI0 - dialer type = ISDN
Dial String Successes Failures Last DNIS Last status
8358661 3 0 00:00:48 successful
7 incoming call(s) have been screened.
10 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 71 secs
Connected to 8358661 (R1)
The drawback to Caller ID Callback is that not all telco switches support it, so if you have the choice between this and PPP Callback, you're probably better off with PPP Callback. However, it's always a good idea to know more than one way to get things done with Cisco!
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!
Cisco CCNA / CCNP Certification Exam Tutorial: Floating Static Routes
To pass the Cisco CCNA and CCNP certification exams, as well as becoming a world-class networker, you've got to know how and when to use floating static routes. And if you're wondering what makes them "float" -- read on!
In this example, R1 and R2 are running OSPF over a Frame Relay network, 172.12.123.0 /24. They're also connected by a BRI ISDN link, 172.12.12.0 /24. R1 is advertising a loopback network, 1.1.1.1 /32, via OSPF. We want R2 to have a route to that loopback even if the frame goes down - and here, we'll use a floating static route to make that happen.
R2 sees the route to the loopback interface via OSPF, and can ping that interface successfully.
R2#show ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/65] via 172.12.123.1, 00:00:02, Serial0
R2#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/68 ms
This is when it's important to know your administrative distances.... or at least know where to look to see them! The AD of OSPF is 110, which means we can configure a static route to 1.1.1.1 /32, and as long as the AD of the static route is higher than 110, it won't be used unless the OSPF route leaves the routing table. That's why this kind of route is called a "floating" static route - the route "floats" in the routing table and isn't seen unless the primary route leaves the table.
You learned how to write a static route in your CCNA studies, but you also remember that the default AD of a static route is either 1 or 0... and both of those values are less than 110! To change the AD of a static route, configure the desired distance at the end of the ip route command.
R2(config)#ip route 1.1.1.1 255.255.255.255 bri0 ?
<1-255> Distance metric for this route
A.B.C.D Forwarding router's address
name Specify name of the next hop
permanent permanent route
tag Set tag for this route
R2(config)#ip route 1.1.1.1 255.255.255.255 bri0 111
The static route has an AD that's only one higher than that of the OSPF route, but that's enough to make the route "float" and not yet be seen in the routing table.
R2#show ip route
1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/65] via 172.12.123.1, 00:06:44, Serial0
172.12.0.0/24 is subnetted, 2 subnets
C 172.12.12.0 is directly connected, BRI0
C 172.12.123.0 is directly connected, Serial0
Let's see the effect on the routing table when the Serial0 interface is closed.
R2(config)#int s0
R2(config-if)#shutdown
12:04:53: %OSPF-5-ADJCHG: Process 1, Nbr 172.12.123.1 on Serial0 from FULL to DOWN, Neighbor Down: Interface down or detached
12:04:55: %SYS-5-CONFIG_I: Configured from console by console
12:04:55: %LINK-5-CHANGED: Interface Serial0, changed state to administratively down
12:04:56: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state to down
R2#show ip route
1.0.0.0/32 is subnetted, 1 subnets
S 1.1.1.1 is directly connected, BRI0
172.12.0.0/24 is subnetted, 1 subnets
C 172.12.12.0 is directly connected, BRI0
The floating static route appears in the table, but the ISDN link will not come up until the BRI interface has traffic to send. Let's ping 1.1.1.1 and see what happens. debug dialer was configured on R2 before sending the ping.
R2#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
12:16:01: BR0 DDR: Dialing cause ip (s=172.12.12.2, d=1.1.1.1)
12:16:01: BR0 DDR: Attempting to dial 8358661
12:16:01: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up.!!
12:16:01: BR0:1 DDR: dialer protocol up!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 36/37/40 ms
The link comes up and traffic can still reach 1.1.1.1. Once R2 becomes an OSPF neighbor of R1 again, the OSPF route will again become the primary path and the floating static route leaves the routing table.
R2(config)#int s0
R2(config-if)#no shut
R2#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
172.12.123.1 1 FULL/DR 00:01:57 172.12.123.1 Serial0
R2#show ip route
1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/65] via 172.12.123.1, 00:00:16, Serial0
172.12.0.0/24 is subnetted, 2 subnets
C 172.12.12.0 is directly connected, BRI0
C 172.12.123.0 is directly connected, Serial0
A floating static route is an excellent "back door" that will keep the ISDN link down while allowing that link to serve as a backup route. Just make sure the ISDN link comes down when you expect it to - always check that with show isdn status!
In this example, R1 and R2 are running OSPF over a Frame Relay network, 172.12.123.0 /24. They're also connected by a BRI ISDN link, 172.12.12.0 /24. R1 is advertising a loopback network, 1.1.1.1 /32, via OSPF. We want R2 to have a route to that loopback even if the frame goes down - and here, we'll use a floating static route to make that happen.
R2 sees the route to the loopback interface via OSPF, and can ping that interface successfully.
R2#show ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/65] via 172.12.123.1, 00:00:02, Serial0
R2#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/68 ms
This is when it's important to know your administrative distances.... or at least know where to look to see them! The AD of OSPF is 110, which means we can configure a static route to 1.1.1.1 /32, and as long as the AD of the static route is higher than 110, it won't be used unless the OSPF route leaves the routing table. That's why this kind of route is called a "floating" static route - the route "floats" in the routing table and isn't seen unless the primary route leaves the table.
You learned how to write a static route in your CCNA studies, but you also remember that the default AD of a static route is either 1 or 0... and both of those values are less than 110! To change the AD of a static route, configure the desired distance at the end of the ip route command.
R2(config)#ip route 1.1.1.1 255.255.255.255 bri0 ?
<1-255> Distance metric for this route
A.B.C.D Forwarding router's address
name Specify name of the next hop
permanent permanent route
tag Set tag for this route
R2(config)#ip route 1.1.1.1 255.255.255.255 bri0 111
The static route has an AD that's only one higher than that of the OSPF route, but that's enough to make the route "float" and not yet be seen in the routing table.
R2#show ip route
1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/65] via 172.12.123.1, 00:06:44, Serial0
172.12.0.0/24 is subnetted, 2 subnets
C 172.12.12.0 is directly connected, BRI0
C 172.12.123.0 is directly connected, Serial0
Let's see the effect on the routing table when the Serial0 interface is closed.
R2(config)#int s0
R2(config-if)#shutdown
12:04:53: %OSPF-5-ADJCHG: Process 1, Nbr 172.12.123.1 on Serial0 from FULL to DOWN, Neighbor Down: Interface down or detached
12:04:55: %SYS-5-CONFIG_I: Configured from console by console
12:04:55: %LINK-5-CHANGED: Interface Serial0, changed state to administratively down
12:04:56: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state to down
R2#show ip route
1.0.0.0/32 is subnetted, 1 subnets
S 1.1.1.1 is directly connected, BRI0
172.12.0.0/24 is subnetted, 1 subnets
C 172.12.12.0 is directly connected, BRI0
The floating static route appears in the table, but the ISDN link will not come up until the BRI interface has traffic to send. Let's ping 1.1.1.1 and see what happens. debug dialer was configured on R2 before sending the ping.
R2#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
12:16:01: BR0 DDR: Dialing cause ip (s=172.12.12.2, d=1.1.1.1)
12:16:01: BR0 DDR: Attempting to dial 8358661
12:16:01: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up.!!
12:16:01: BR0:1 DDR: dialer protocol up!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 36/37/40 ms
The link comes up and traffic can still reach 1.1.1.1. Once R2 becomes an OSPF neighbor of R1 again, the OSPF route will again become the primary path and the floating static route leaves the routing table.
R2(config)#int s0
R2(config-if)#no shut
R2#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
172.12.123.1 1 FULL/DR 00:01:57 172.12.123.1 Serial0
R2#show ip route
1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/65] via 172.12.123.1, 00:00:16, Serial0
172.12.0.0/24 is subnetted, 2 subnets
C 172.12.12.0 is directly connected, BRI0
C 172.12.123.0 is directly connected, Serial0
A floating static route is an excellent "back door" that will keep the ISDN link down while allowing that link to serve as a backup route. Just make sure the ISDN link comes down when you expect it to - always check that with show isdn status!
Subscribe to:
Posts (Atom)
