This involves manipulating the router´s configuration register, and that is enough to make some CCNA candidates and network administrators really nervous!
It´s true that setting the configuration register to the wrong value can damage the router, but if you do the proper research before starting the password recovery process, you´ll be fine.
Despite what some books say, there is no “one size fits all” approach to Cisco password recovery. What works on a 2500 router may not work on other routers and switches. There is a great master Cisco document out on the Web that you should bookmark today. Just put “cisco password recovery” in your favorite search engine and you should find it quickly.
The following procedure describes the process in recovering from a lost password on a Cisco 2500 router. As always, don´t practice this at home. It is a good idea to get some practice with this technique in your CCNA / CCNP home lab, though!
The password recovery method examined here is for 2500 routers.
An engineer who finds themselves locked out of a router can view and change the password by changing the configuration register.
The router must first be rebooted and a “break” performed within the first 60 seconds of the boot process. This break sequence can also vary depending on what program is used to access the router, but is the usual key combination.
The router will now be in ROM Monitor mode. From the rom monitor prompt, change the default configuration register of 0x2102 to 0x2142 with the o/r 0x2142 command. Reload the router with the letter i. (As you can see, ROM Monitor mode is a lot different than working with the IOS!)
This particular config register setting will cause the router to ignore the contents of NVRAM. Your startup configuration is still there, but it will be ignored on reload.
When the router reloads, you’ll be prompted to enter Setup mode. Answer “N”, and type enable at the router> prompt.
Be careful here. Type configure memory or copy start run. Do NOT type write memory or copy run start!
Enter the command show running-config. You’ll see the passwords in either their encrypted or unencrypted format.
Type config t, then use the appropriate command to set a new enable secret or enable password.
Don’t forget to change the configuration register setting back to the original value! The command config-register 0x2102 will do the job. Save this change with write memory or copy run start, and then run reload one more time to restart the router.
This process sounds hard, but it´s really not. You just have to be careful, particularly when you´re copying the startup config over the running config. You don´t want to get that backwards! So take your time, check the online Cisco documentation before starting, get some practice with this procedure with lab equipment, and you´ll be ready for success on the CCNA exam and in your production network.
When you´re studying for the BSCI exam on the way to earning your CCNP certification, it´s safe to say that BGP is like nothing you’ve studied to this point.
BGP is an external routing protocol used primarily by Internet Service Providers (ISPs). Unless you work for an ISP today or in the future, you may have little or no prior exposure to BGP. Understanding BGP is a great addition to your skill set – and you have to know the basics well to pass the BSCI exam.
Note that I said “the basics”. BGP is a very complex protocol, and when you pursue your CCIE, you’ll see what I’m talking about. As with all things Cisco, though, when broken down into smaller pieces, BGP becomes quite understandable. You will need to know the basics of BGP as presented in this chapter to pass your BSCI exam – so let’s get started.
“An Internet protocol that enables groups of routers (called autonomous systems) to share routing information so that efficient, loop-free routes can be established. BGP is commonly used within and between Internet Service Providers (ISPs).”
There are a couple of terms in there that apply to the protocols you’ve mastered so far in your studies. The term “autonomous system” applies to IGRP and EIGRP as well as BGP; you’ll be indicating a BGP AS in your configurations just as you did with IGRP and EIGRP. And we’re always looking for efficient, loop-free routes, right? As it did with IGRP and EIGRP, “autonomous system” simply refers to a group of routers that is managed by a single administrative body. An autonomous system will use an Interior Gateway Protocol (IGP) such as OSPF or EIGRP to route packets inside the AS; outside the AS, an Exterior Gateway Protocol (EGP) such as BGP will be used.
BGP shares some characteristics with some routing protocols you’ve already studied. BGP supports VLSM, summarization, and CIDR. Like EIGRP, BGP will send full updates when two routers initially become neighbors and will send only partial updates after that. BGP does create and maintain neighbor relationships before exchanging routes, and keepalives are sent to keep this relationship alive.
BGP has some major differences from the IGPs we’ve studied to this point. You’ll hear BGP referred to as a path-vector protocol. As opposed to distance-vector protocols that exchange relatively simple information about available routes, BGP routers will exchange extensive information about networks to allow the routers to make more intelligent routing decisions. This additional BGP path information comes in the form of attributes, and these path attributes are contained in the updates sent by BGP routers. Attributes themselves are broken up into two classes, well-known and optional.
BGP also keeps a routing table separate from the IP routing table.
We´ll take a look at BGP attributes in future BSCI tutorials. In the meantime, keep studying!
In my last ISIS tutorial, I mentioned that while ISIS and OSPF are both link state protocols, their actual operation differs greatly.
To pass the BSCI exam and earn your CCNP, you´ll need to know these differences! Today, we´ll take a look at ISIS Hello types and the adjacency types that form through the use of these Hellos.
Hello packets have been mentioned several times with ISIS, and with good reason. Hello packets are the heartbeat of OSPF and ISIS when heartbeats are no longer heard from a neighbor, that adjacency will be dropped. A major difference between OSPF and ISIS is that OSPF has one type of Hello packet, where ISIS actually has three!
An ES Hello (ESH) is send by all End Systems, and all IS devices listen for this Hello. This is how a router (IS) discovers a host (ES).
An IS Hello (ISH) announces the presence of an IS. An IS Hello is sent by all IS devices, and End Systems listen for these hellos.
An IS-to-IS Hello (IIH) is used by an IS to discover other ISes and to form adjacencies with them.
An interesting side note: A router will send an IIH to another router on the link to form or maintain an adjacency, but it will still send an ISH as well in case there are end systems located on that segment.
ISIS and OSPF both create and maintain adjacencies with the Hello packet. Let´s take a look at the rules regarding ISIS adjacencies as well as the adjacency types.
L1 and L2 Hellos are different messages, so an L1 router must exchange Hellos with another L1 router to form an adjacency, just as L2 routers form adjacencies with L2 routers. L1 routers can only form an adjacency with an L2 router if one of the two routers involved is actually an L1/L2 router.
L1 routers must be in the same area in order to form an adjacency. The Hello timers, as well as the MTU, must match between the interfaces used to form the adjacency.
That´s a lot of L1, L2, and L1/L2, isn´t it? Let´s review the adjacencies each router type can form:
L1: Can form adjacency with any L1 in the same area and any L1/L2 in the same area.
L2: Can form adjacency with any L2 in any area, and with an L1/L2 in any area.
L1/L2: Can form adjacency with any L1 in the same area, L1/L2 in any area, and L2 in any area.
Knowing the similarities and differences regarding ISIS and OSPF is vital for CCNP exam success. Take your time, master the fundamentals, and before long the magic letters “CCNP” are behind your name and on your resume!
To pass the CCNA exam, you’ve got to master quite a few services and routing protocols that may be new to you.
Between RIP, IGRP, EIGRP, OSPF, and switching, there are hundreds of details you’ve got to absorb! It’s easy to spend all your time on those topics and not pay proper attention to “easier” technologies, and then all of a sudden on exam day you can’t quite remember the details of those particular services.
One setup you’ve got to be more than familiar with is directly connecting serial interfaces on Cisco routers. This is also a valuable skill to have in your home lab, since it allows you to add segments to your network setup.
A Cisco serial interface is operating as a DTE by default. The problem is that when you take a cable and connect two routers directly by their serial interfaces (with a DTE/DCE cable, that is!), they’re both waiting for the other to send them a clock rate. One of the interfaces must act as the DCE and that interface must send the clock rate.
If you can see the DTE/DCE cable, you can tell by looking which router has the DCE interface connected to it – the letters “DTE” or “DCE” will either be molded into the connector itself, or if it’s an older cable there should be a little piece of tape on the cable that tells you what the interface type is. But what if you have no access to the cable, or there are other cables all around it and you can’t see what type it is?
Run the command “show controller serial x”, with x representing the interface number the cable’s connected to. There will be quite a bit of output from this command, but the information you need is right at the top:
R1#show controller serial 1
HD unit 1, idb = 0x1DBFEC, driver structure at 0x1E35D0
buffer size 1524 HD unit 1, V.35 DTE cable
I left off the 16 or so rows of information that comes after this, but this is the information we need right now. If R1’s got the DTE cable end, the other router should have the DCE end:
R3#show controller serial 1
HD unit 1, idb = 0x1C44E8, driver structure at 0x1CBAC8
buffer size 1524 HD unit 1, V.35 DCE cable
We know now that R3 needs to supply a clock rate to R1. There’s a hint of a problem in just that little bit of command output – do you see what it is? Let’s run show interface serial1 to get more information.
R3#show int s1
Serial1 is up, line protocol is down
The line protocol is down because there is no clockrate being supplied by R3. If there has been, we would have seen that in the output of show controllers serial 1.
This is simple enough to fix, though! We’ll use the command clockrate 56000 on R3’s serial1 interface, and the line protocol will soon come up.
1w2d: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
This is a simple concept, but there are a few details you must keep in mind! For a home lab configuration, you’ll need a DTE/DCE cable to make this work. If you cannot see the cable connectors, run show controllers serial x to see if the router has the DTE or DCE end of the cable attached. On the interface with the DCE attached, use the clockrate command to bring the line protocol up. It’s just that simple!