When you're getting started on your CCNA studies, learning the different router modes is key to passing your Intro and ICND exams. But keeping those modes straight can be very difficult. (At least it was for me!) Let's take a look at the various router modes you'll need to know about to pass your CCNA, and use IOS Help to illustrate the different uses of each mode.
The first mode you'll see on a router (if the person before you logged off as they should have) is user exec mode. This is also the default mode a user is placed into when using Telnet to connect to a router. The prompt will look like this:
R1>
You can't write or add to a configuration in this mode, but you can run quite a few show commands. This is a good mode to have users in who need to see the configuration, but shouldn't be allowed to change it.
To get to the next level, type enable at the user exec prompt:
R1>enable
R1#
Notice that the prompt changed. This mode has two names, the official one being privileged exec mode. It's more commonly referred to as enable mode, since "enable" is what you type to get into this mode.
This mode gives you more options for show and other commands, but you still can't configure anything. To configure global commands, use "configure terminal", or "conf t", to enter global configuration mode.
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#
The prompt has changed again, and now global configuration commands such as hostname and no ip domain-lookup can be entered.
From here, you've got a lot of options, but we'll look at three you need to know for your CCNA exams. To apply configuration commands to an interface, enter interface configuration mode, as shown here:
R1(config)#interface serial0
R1(config-if)#
You must be in global config mode to get into interface config mode you cannot go from enable mode straight to interface configuration mode.
R1#interface serial0
^
% Invalid input detected at '^' marker.
Interface configuration mode allows you to apply an IP address to the interface, as well as many other commands related to frame relay, ISDN, and dynamic routing protocols.
For the CCNA, you need to know about two other configuration modes. To configure console commands (such as password protection), enter line configuration mode as shown here:
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#line console 0
R1(config-line)#password cisco
R1(config-line)#login
The prompt "(config-line)" indicates that you're in line configuration mode. Your console line is not the only line you'll be configuring for the CCNA, though your vty lines are used for incoming telnet connections and must be configured in a similar fashion.
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#line console 0
R1(config-line)#password cisco
R1(config-line)#login
R1(config-line)#line vty 0 4
R1(config-line)#password cisco
R1(config-line)#login
Notice that you do not have to exit one interface mode to go to another one. Let's say that you've configured your vty lines and now want to put an IP address on your Ethernet interface. You don't have to go out with ctrl-z and then start again you can go straight to interface config mode from line config mode. Just make sure you see the prompt change!
R1(config-line)#line vty 0 4
R1(config-line)#password cisco
R1(config-line)#login
R1(config-line)#interface ethernet0
R1(config-if)#ip address 15.1.1.1 255.255.255.0
When you're preparing for CCNA exam success, there's a lot to absorb. Just take it one piece at a time, get some hands-on experience to go with your theory, and before you know it you're moving around in the different Cisco router configuration modes without giving it a second thought. Keep studying and your CCNA exam success is assured!
Showing posts with label interface. Show all posts
Showing posts with label interface. Show all posts
Saturday, December 27, 2008
Thursday, December 25, 2008
Cisco CCNP Certification / BCMSN Exam Tutorial: Writing QoS Policy
QoS - Quality of Service - is a huge topic on both the BCMSN exam and real-world networks. QoS is so big today that Cisco's created separate specialist certifications that cover nothing but QoS! It can be an overwhelming topic at first, but master the fundamentals and you're on your way to exam and job success.
If you work with QoS at any level - and sooner or later, you will - you've got to know how to write and apply QoS policies.
Creating and applying such a policy is a three-step process.
1. Create a QoS class to identify the traffic that will be affected by the policy.
2. Create a QoS policy containing the actions to be taken by traffic identified by the class.
3. Apply the policy to the appropriate interfaces.
If the phrase "identify the traffic" sounds like it's time to write an access-list, you're right! Writing an ACL is one of two ways to classify traffic, and is the more common of the two. Before we get to the less-common method, let's take a look at how to use an ACL to classify traffic.
You can use either a standard or extended ACL with QoS policies. The ACL will be written separately, and then called from the class map.
SW1(config)#access-list 105 permit tcp any any eq 80
SW1(config)#class-map WEBTRAFFIC
SW1(config-cmap)#match access-group 105
Now that we've identified the traffic to be affected by the policy, we better get around to writing the policy! QoS policies are configured with the policy-map command, and each clause of the policy will contain an action to be taken to traffic matching that clause.
SW1(config)#policy-map LIMIT_WEBTRAFFIC_BANDWIDTH
SW1(config-pmap)#class WEBTRAFFIC
SW1(config-pmap-c)#police 5000000 exceed-action drop
SW1(config-pmap-c)#exit
This is a simple policy, but it illustrates the logic of QoS policies. The policy map LIMIT_WEBTRAFFIC_BANDWIDTH calls the map-class WEBTRAFFIC. We already know that all WWW traffic will match that map class, so any WWW traffic that exceeds the stated bandwidth limitation will be dropped.
Finally, apply the policy to the appropriate interface.
SW1(config-if)#service-policy LIMIT_WEBTRAFFIC_BANDWIDTH in
Getting your CCNP is a great way to boost your career, and learning QoS is a tremendous addition to your skill set. Like I said, learn the fundamentals, don't get overwhelmed by looking at QoS as a whole, and you're on your way to success!
If you work with QoS at any level - and sooner or later, you will - you've got to know how to write and apply QoS policies.
Creating and applying such a policy is a three-step process.
1. Create a QoS class to identify the traffic that will be affected by the policy.
2. Create a QoS policy containing the actions to be taken by traffic identified by the class.
3. Apply the policy to the appropriate interfaces.
If the phrase "identify the traffic" sounds like it's time to write an access-list, you're right! Writing an ACL is one of two ways to classify traffic, and is the more common of the two. Before we get to the less-common method, let's take a look at how to use an ACL to classify traffic.
You can use either a standard or extended ACL with QoS policies. The ACL will be written separately, and then called from the class map.
SW1(config)#access-list 105 permit tcp any any eq 80
SW1(config)#class-map WEBTRAFFIC
SW1(config-cmap)#match access-group 105
Now that we've identified the traffic to be affected by the policy, we better get around to writing the policy! QoS policies are configured with the policy-map command, and each clause of the policy will contain an action to be taken to traffic matching that clause.
SW1(config)#policy-map LIMIT_WEBTRAFFIC_BANDWIDTH
SW1(config-pmap)#class WEBTRAFFIC
SW1(config-pmap-c)#police 5000000 exceed-action drop
SW1(config-pmap-c)#exit
This is a simple policy, but it illustrates the logic of QoS policies. The policy map LIMIT_WEBTRAFFIC_BANDWIDTH calls the map-class WEBTRAFFIC. We already know that all WWW traffic will match that map class, so any WWW traffic that exceeds the stated bandwidth limitation will be dropped.
Finally, apply the policy to the appropriate interface.
SW1(config-if)#service-policy LIMIT_WEBTRAFFIC_BANDWIDTH in
Getting your CCNP is a great way to boost your career, and learning QoS is a tremendous addition to your skill set. Like I said, learn the fundamentals, don't get overwhelmed by looking at QoS as a whole, and you're on your way to success!
Cisco CCNP / BSCI Exam Tutorial: The Passive Interface Command And OSPF
To pass the BSCI exam and become a CCNP, you have to be aware of the proper use of passive interfaces. You learned about passive interfaces in your CCNA studies, but here we’ll review the basic concept and clear up one misconception regarding passive interfaces and OSPF.
Configuring an interface as passive will still allow the interface to receive routing updates, but the interface will no longer transmit them. While the command itself would make you think this command will be applied at the interface level, that is not the case. Below, we’ll configure ethernet0 as a RIP passive interface.
R1(config)#router rip
R1(config-router)#passive-interface ethernet0
Ethernet0 will no longer send RIP routing updates, but will accept them.
The passive interface concept is clear enough with RIP, IGRP, and EIGRP – all protocols that send routing update packets. But OSPF doesn’t send routing update packets – OSPF sends link state advertisements. It’s the inability of the passive interface command to stop LSAs that lead many to think that passive interfaces cannot be used with OSPF.
Even though OSPF does not sent "routing updates" in the form that RIP, IGRP, and EIGRP do, you can still configure an OSPF-enabled interface as passive in order to prevent OSPF traffic from exiting or entering that interface. No OSPF adjacency can be formed if one of the interfaces involved is a passive interface, and if you configure an OSPF-enabled interface as passive where an adjacency already exists, the adjacency will drop almost immediately.
Let's see that in action. R1 and R2 have an existing OSPF adjacency over their Ethernet interfaces. In an effort to reduce routing traffic, R1's e0 interface is configured as passive. The adjacency drops right away.
R1(config)#router ospf 1
R1(config-router)#passive-interface ethernet0
18:31:11: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Ethernet0 from FULL to DOWN, Neighbor Down: Interface down or detached
Knowing how to use the passive interface command is a vital part of being a CCNP, and of being a master networker. Good luck to you in both of these pursuits!
Configuring an interface as passive will still allow the interface to receive routing updates, but the interface will no longer transmit them. While the command itself would make you think this command will be applied at the interface level, that is not the case. Below, we’ll configure ethernet0 as a RIP passive interface.
R1(config)#router rip
R1(config-router)#passive-interface ethernet0
Ethernet0 will no longer send RIP routing updates, but will accept them.
The passive interface concept is clear enough with RIP, IGRP, and EIGRP – all protocols that send routing update packets. But OSPF doesn’t send routing update packets – OSPF sends link state advertisements. It’s the inability of the passive interface command to stop LSAs that lead many to think that passive interfaces cannot be used with OSPF.
Even though OSPF does not sent "routing updates" in the form that RIP, IGRP, and EIGRP do, you can still configure an OSPF-enabled interface as passive in order to prevent OSPF traffic from exiting or entering that interface. No OSPF adjacency can be formed if one of the interfaces involved is a passive interface, and if you configure an OSPF-enabled interface as passive where an adjacency already exists, the adjacency will drop almost immediately.
Let's see that in action. R1 and R2 have an existing OSPF adjacency over their Ethernet interfaces. In an effort to reduce routing traffic, R1's e0 interface is configured as passive. The adjacency drops right away.
R1(config)#router ospf 1
R1(config-router)#passive-interface ethernet0
18:31:11: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Ethernet0 from FULL to DOWN, Neighbor Down: Interface down or detached
Knowing how to use the passive interface command is a vital part of being a CCNP, and of being a master networker. Good luck to you in both of these pursuits!
Cisco CCNP / BSCI Exam Tutorial: RIP Update Packet Authentication
When you earned your CCNA, you thought you learned everything there is to know about RIP. Close, but not quite! There are some additional details you need to know to pass the BSCI exam and get one step closer to the CCNP exam, and one of those involves RIP update packet authentication.
You're familiar with some advantages of using RIPv2 over RIPv1, support for VLSM chief among them. But one advantage that you're not introduced to in your CCNA studies is the ability to configure routing update packet authentication.
You have two options, clear text and MD5. Clear text is just that - a clear text password that is visible by anyone who can pick a packet off the wire. If you're going to go to the trouble of configuring update authentication, you should use MD5. The MD stands for "Message Digest", and this is the algorithm that produces the hash value for the password that will be contained in the update packets.
Not only must the routers agree on the password, they must agree on the authentication method. If one router sends an MD5-hashed password to another router that is configured for clear-text authentication, the update will not be accepted. debug ip rip is a great command for troubleshooting authenticated updates.
R1, R2, and R3 are running RIP over a frame relay cloud. Here is how RIP authentication would be configured on these three routers.
R1#conf t
R1(config)#key chain RIP
< The key chain can have any name. >
R1(config-keychain)#key 1
< Key chains can have multiple keys. Number them carefully when using multiples. >
R1(config-keychain-key)#key-string CISCO
< This is the text string the key will use for authentication. >
R1(config)#int s0
R1(config-if)#ip rip authentication mode text
< The interface will use clear-text mode. >
R1(config-if)#ip rip authentication key-chain RIP
< The interface is using key chain RIP, configured earlier. >
R2#conf t
R2(config)#key chain RIP
R2(config-keychain)#key 1
R2(config-keychain-key)#key-string CISCO
R2(config)#int s0.123
R2(config-subif)#ip rip authentication mode text
R2(config-subif)#ip rip authentication key-chain RIP
R3#conf t
R3(config)#key chain RIP
R3(config-keychain)#key 1
R3(config-keychain-key)#key-string CISCO
R3(config)#int s0.31
R3(config-subif)#ip rip authentication mode text
R3(config-subif)#ip rip authentication key-chain RIP
To use MD5 authentication rather than clear-text, simply replace the word "text" in the ip rip authentication mode command with md5.
Here's what a successfully authentication RIPv2 packet looks like, courtesy of debug ip rip. Clear-text authentication is in effect and the password is "cisco".
3d04h: RIP: received packet with text authentication cisco
3d04h: RIP: received v2 update from 150.1.1.3 on Ethernet0
3d04h: 100.0.0.0/8 via 0.0.0.0 in 1 hops
3d04h: 150.1.2.0/24 via 0.0.0.0 in 1 hops
Here's what it looks like when the remote device is set for MD5 authentication and the local router is set for clear-text. You'll also see this message if the password itself is incorrect.
3d04h: RIP: ignored v2 packet from 150.1.1.3 (invalid authentication)
"Debug ip rip" may be a simple command as compared to the debugs for other protocols. but it's also a very powerful debug. Start using debugs as early as possible in your Cisco studies to learn how router commands really work!
You're familiar with some advantages of using RIPv2 over RIPv1, support for VLSM chief among them. But one advantage that you're not introduced to in your CCNA studies is the ability to configure routing update packet authentication.
You have two options, clear text and MD5. Clear text is just that - a clear text password that is visible by anyone who can pick a packet off the wire. If you're going to go to the trouble of configuring update authentication, you should use MD5. The MD stands for "Message Digest", and this is the algorithm that produces the hash value for the password that will be contained in the update packets.
Not only must the routers agree on the password, they must agree on the authentication method. If one router sends an MD5-hashed password to another router that is configured for clear-text authentication, the update will not be accepted. debug ip rip is a great command for troubleshooting authenticated updates.
R1, R2, and R3 are running RIP over a frame relay cloud. Here is how RIP authentication would be configured on these three routers.
R1#conf t
R1(config)#key chain RIP
< The key chain can have any name. >
R1(config-keychain)#key 1
< Key chains can have multiple keys. Number them carefully when using multiples. >
R1(config-keychain-key)#key-string CISCO
< This is the text string the key will use for authentication. >
R1(config)#int s0
R1(config-if)#ip rip authentication mode text
< The interface will use clear-text mode. >
R1(config-if)#ip rip authentication key-chain RIP
< The interface is using key chain RIP, configured earlier. >
R2#conf t
R2(config)#key chain RIP
R2(config-keychain)#key 1
R2(config-keychain-key)#key-string CISCO
R2(config)#int s0.123
R2(config-subif)#ip rip authentication mode text
R2(config-subif)#ip rip authentication key-chain RIP
R3#conf t
R3(config)#key chain RIP
R3(config-keychain)#key 1
R3(config-keychain-key)#key-string CISCO
R3(config)#int s0.31
R3(config-subif)#ip rip authentication mode text
R3(config-subif)#ip rip authentication key-chain RIP
To use MD5 authentication rather than clear-text, simply replace the word "text" in the ip rip authentication mode command with md5.
Here's what a successfully authentication RIPv2 packet looks like, courtesy of debug ip rip. Clear-text authentication is in effect and the password is "cisco".
3d04h: RIP: received packet with text authentication cisco
3d04h: RIP: received v2 update from 150.1.1.3 on Ethernet0
3d04h: 100.0.0.0/8 via 0.0.0.0 in 1 hops
3d04h: 150.1.2.0/24 via 0.0.0.0 in 1 hops
Here's what it looks like when the remote device is set for MD5 authentication and the local router is set for clear-text. You'll also see this message if the password itself is incorrect.
3d04h: RIP: ignored v2 packet from 150.1.1.3 (invalid authentication)
"Debug ip rip" may be a simple command as compared to the debugs for other protocols. but it's also a very powerful debug. Start using debugs as early as possible in your Cisco studies to learn how router commands really work!
Cisco CCNP / BSCI Exam Tutorial: Not All Static Routes Are Created Equal
As a CCNP candidate, as a CCNA, and in getting ready to pass the BSCI exam, you may be tempted to breeze through your static route studies, or even skip them! That's because static routes are easy enough to configure, and as long as you remember the syntax of the ip route command, you're in good shape.
But there's one vital detail regarding static routes that many exam candidates miss. That's because many CCNA and CCNP books say "the administrative distance of a static route is 1", but that is not quite accurate.
You know from your CCNA studies that the ip route command is used to create a static route, and that you have the option of configuring a local exit interface or a next-hop IP address at the end of the command. However, the administrative distances are not the same. The AD of a static route that uses a local exit interface is zero! (That's because the router considers a static route with a local exit interface to actually be a directly connected network.) The AD of a static route with a next-hop IP address is 1.
Therefore, if the router has the following two ip route statements to consider...
Router(config)#ip route 172.1.1.1 255.255.255.255 fast0
Router(config)#ip route 172.1.1.1 255.255.255.255 210.1.1.1
... the prefix lengths are the same, so the static route using the local exit interface fastethernet0 will be preferred due to its lower AD, and will be installed into the routing table.
Keep the details in mind on the job and in the exam room, and you’re on your way to CCNP exam success!
But there's one vital detail regarding static routes that many exam candidates miss. That's because many CCNA and CCNP books say "the administrative distance of a static route is 1", but that is not quite accurate.
You know from your CCNA studies that the ip route command is used to create a static route, and that you have the option of configuring a local exit interface or a next-hop IP address at the end of the command. However, the administrative distances are not the same. The AD of a static route that uses a local exit interface is zero! (That's because the router considers a static route with a local exit interface to actually be a directly connected network.) The AD of a static route with a next-hop IP address is 1.
Therefore, if the router has the following two ip route statements to consider...
Router(config)#ip route 172.1.1.1 255.255.255.255 fast0
Router(config)#ip route 172.1.1.1 255.255.255.255 210.1.1.1
... the prefix lengths are the same, so the static route using the local exit interface fastethernet0 will be preferred due to its lower AD, and will be installed into the routing table.
Keep the details in mind on the job and in the exam room, and you’re on your way to CCNP exam success!
Cisco CCNP / BCSI Exam Tutorial: Configuring EIGRP Packet
Configuring RIPv2 and EIGRP authentication with key chains can be tricky at first, and the syntax isn't exactly easy to remember. But for BSCI and CCNP exam success, we've got to be able to perform this task.
In a previous tutorial, we saw how to configure RIPv2 packet authentication, with both clear-text and MD5 authentication schemes. EIGRP authentication is much the same, and has the text and MD5 authentication options as well. But EIGRP being EIGRP, the command just has to be a little more detailed!
As with RIPv2, the authentication mode must be agreed upon by the EIGRP neighbors. If one router's interface is configured for MD5 authentication and the remote router's interface is configured for text authentication, the adjacency will fail even if the two interfaces in question are configured to use the same password.
We'll now configure link authentication on the adjacency over an Ethernet segment. Below, you'll see how to configure a key chain called EIGRP on both routers, use key number 1, and use the key-string BSCI. Run show key chain on a router to see all key chains.
R2(config)#key chain EIGRP
R2(config-keychain)#key 1
R2(config-keychain-key)#key-string BSCI
R2#show key chain
Key-chain EIGRP:
key 1 -- text "BSCI"
accept lifetime (always valid) - (always valid) [valid now]
send lifetime (always valid) - (always valid) [valid now]
R3(config)#key chain EIGRP
R3(config-keychain)#key 1
R3(config-keychain-key)#key-string BSCI
R3#show key chain
Key-chain EIGRP:
key 1 -- text "BSCI"
accept lifetime (always valid) - (always valid) [valid now]
send lifetime (always valid) - (always valid) [valid now]
The EIGRP command to apply the key chain is a bit of a pain to remember, because the protocol and AS number is identified in the middle of the command, not the beginning. Also note that two commands are needed - one to name the key chain, another to define the authentication mode in use.
R2(config)#interface ethernet0
R2(config-if)#ip authentication key-chain eigrp 100 EIGRP
R2(config-if)#ip authentication mode eigrp 100 md5
5d07h: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.23.3 (Ethernet0) is down: keychain changed
R3(config)#interface ethernet0
R3(config-if)#ip authentication key-chain eigrp 100 EIGRP
R3(config-if)#ip authentication mode eigrp 100 md5
5d07h: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.23.2 (Ethernet0) is up:
As with RIPv2, the existing adjacency was torn down when one side was configured with authentication. If the key chain is correctly defined and applied on both sides, the adjacency will come back up. Always run show ip eigrp neighbor to make sure the adjacency is present. Learn the details of EIGRP key chains by configuring them on your home lab equipment, and you'll be more than ready for BSCI exam success!
In a previous tutorial, we saw how to configure RIPv2 packet authentication, with both clear-text and MD5 authentication schemes. EIGRP authentication is much the same, and has the text and MD5 authentication options as well. But EIGRP being EIGRP, the command just has to be a little more detailed!
As with RIPv2, the authentication mode must be agreed upon by the EIGRP neighbors. If one router's interface is configured for MD5 authentication and the remote router's interface is configured for text authentication, the adjacency will fail even if the two interfaces in question are configured to use the same password.
We'll now configure link authentication on the adjacency over an Ethernet segment. Below, you'll see how to configure a key chain called EIGRP on both routers, use key number 1, and use the key-string BSCI. Run show key chain on a router to see all key chains.
R2(config)#key chain EIGRP
R2(config-keychain)#key 1
R2(config-keychain-key)#key-string BSCI
R2#show key chain
Key-chain EIGRP:
key 1 -- text "BSCI"
accept lifetime (always valid) - (always valid) [valid now]
send lifetime (always valid) - (always valid) [valid now]
R3(config)#key chain EIGRP
R3(config-keychain)#key 1
R3(config-keychain-key)#key-string BSCI
R3#show key chain
Key-chain EIGRP:
key 1 -- text "BSCI"
accept lifetime (always valid) - (always valid) [valid now]
send lifetime (always valid) - (always valid) [valid now]
The EIGRP command to apply the key chain is a bit of a pain to remember, because the protocol and AS number is identified in the middle of the command, not the beginning. Also note that two commands are needed - one to name the key chain, another to define the authentication mode in use.
R2(config)#interface ethernet0
R2(config-if)#ip authentication key-chain eigrp 100 EIGRP
R2(config-if)#ip authentication mode eigrp 100 md5
5d07h: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.23.3 (Ethernet0) is down: keychain changed
R3(config)#interface ethernet0
R3(config-if)#ip authentication key-chain eigrp 100 EIGRP
R3(config-if)#ip authentication mode eigrp 100 md5
5d07h: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.23.2 (Ethernet0) is up:
As with RIPv2, the existing adjacency was torn down when one side was configured with authentication. If the key chain is correctly defined and applied on both sides, the adjacency will come back up. Always run show ip eigrp neighbor to make sure the adjacency is present. Learn the details of EIGRP key chains by configuring them on your home lab equipment, and you'll be more than ready for BSCI exam success!
Cisco CCNA Exam Tutorial: Split Horizon And Hub-And-Spoke Networks
For CCNA exam success, you had better know what split horizon is, how to turn it off, and when to turn it off. Knowing when to turn split horizon off is also important in production networks, because it can cause a hub-and-spoke network to have incomplete routing tables on the spokes.
Split horizon exists for a very good reason - routing loop prevention. The rule of split horizon states that a router cannot send an advertisement for a route out the same interface that it came in on. Split horizon is on by default on all interfaces running RIP, IGRP, and EIGRP.
In this CCNA tutorial, R1 will serve, as the hub and R2 and R3 will be the spokes. We'll first configure EIGRP over the 172.16.123.0 /24 network, the network connecting the three routers.
R1#conf t
R1(config)#router eigrp 100
R1(config-router)#no auto-summary
R1(config-router)#network 172.12.123.0 0.0.0.255
R2#conf t
R2(config)#router eigrp 100
R2(config-router)#no auto-summary
R2(config-router)#network 172.12.123.0 0.0.0.255
R3#conf t
R3(config)#router eigrp 100
R3(config-router)#no auto-summary
R3(config-router)#network 172.12.123.0 0.0.0.255
Running show ip eigrp neighbor on R1 shows that adjacencies to R2 and R3 are up.
R1#show ip eigrp neighbor
IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO Q Seq Type
(sec) (ms) Cnt Num
1 172.12.123.3 Se0/0 11 00:02:45 1 5000 0 1
0 172.12.123.2 Se0/0 161 00:03:01 1 5000 0 1
Each router will now advertise its loopback address via EIGRP.
R1#conf t
R1(config)#router eigrp 100
R1(config-router)#network 1.1.1.0 0.0.0.255
R2#conf t
R2(config)#router eigrp 100
R2(config-router)#network 2.2.2.0 0.0.0.255
R3#conf t
R3(config)#router eigrp 100
R3(config-router)#network 3.3.3.0 0.0.0.255
Running show ip eigrp route on each router shows that R1 has a route for both R2’s and R3’s loopback. R2 and R3 will only see R1’s loopback address, and not each other’s. Why?
R1#show ip route eigrp
2.0.0.0/24 is subnetted, 1 subnets
D 2.2.2.0 [90/2297856] via 172.12.123.2, 00:03:19, Serial0/0
3.0.0.0/24 is subnetted, 1 subnets
D 3.3.3.0 [90/2297856] via 172.12.123.3, 00:03:04, Serial0/0
R2#show ip route eigrp
1.0.0.0/24 is subnetted, 1 subnets
D 1.1.1.0 [90/2297856] via 172.12.123.1, 00:03:40, Serial0/0.123
R3#show ip route eigrp
1.0.0.0/24 is subnetted, 1 subnets
D 1.1.1.0 [90/2297856] via 172.12.123.1, 00:05:17, Serial0/0.31
EIGRP uses Split Horizon by default to prevent routing loops. In this lab, though, it prevents full network reachability. R2 and R3 both form neighbor relationships with R1’s Serial physical interface. R2 advertises its loopback address to R1’s Serial interface, as does R3. Split Horizon does not allow a route to be advertised back out the same interface it was received on. This prevents R1 from advertising R2’s loopback to R3, or R3’s loopback to R2.
Split Horizon must be disabled to allow full network reachability in this lab. To do so, run no ip split-horizon eigrp 100 on R1’s Serial interface. When Split Horizon is disabled, that will cause the neighbor
relationships to fail, and then reestablish. Run show ip route eigrp 100 on both R2 and R3. The appropriate route to the remote loopback address will now appear.
R1#conf t
R1(config)#int serial0
R1(config-if)#no ip split-horizon eigrp 100
10:02:23: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.123.2 (Serial0/0) down: split horizon changed
10:02:23: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.123.3 (Serial0/0) down: split horizon changed
10:02:27: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.123.3 (Serial0/0) ip: new adjacency
10:02:54: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.123.2 (Serial0/0) ip: new adjacency
R2#show ip route eigrp
1.0.0.0/24 is subnetted, 1 subnets
D 1.1.1.0 [90/2297856] via 172.12.123.1, 00:00:06, Serial0/0.123
3.0.0.0/24 is subnetted, 1 subnets
D 3.3.3.0 [90/2809856] via 172.12.123.1, 00:00:06, Serial0/0.123
R3#show ip route eigrp
1.0.0.0/24 is subnetted, 1 subnets
D 1.1.1.0 [90/2297856] via 172.12.123.1, 00:00:12, Serial0/0.31
2.0.0.0/24 is subnetted, 1 subnets
D 2.2.2.0 [90/2809856] via 172.12.123.1, 00:00:12, Serial0/0.31
Disabling split horizon should be done with care, but knowing when and where to do so shows that you truly understand how this technology works - and that's a big step on the way to earning your CCNA!
Split horizon exists for a very good reason - routing loop prevention. The rule of split horizon states that a router cannot send an advertisement for a route out the same interface that it came in on. Split horizon is on by default on all interfaces running RIP, IGRP, and EIGRP.
In this CCNA tutorial, R1 will serve, as the hub and R2 and R3 will be the spokes. We'll first configure EIGRP over the 172.16.123.0 /24 network, the network connecting the three routers.
R1#conf t
R1(config)#router eigrp 100
R1(config-router)#no auto-summary
R1(config-router)#network 172.12.123.0 0.0.0.255
R2#conf t
R2(config)#router eigrp 100
R2(config-router)#no auto-summary
R2(config-router)#network 172.12.123.0 0.0.0.255
R3#conf t
R3(config)#router eigrp 100
R3(config-router)#no auto-summary
R3(config-router)#network 172.12.123.0 0.0.0.255
Running show ip eigrp neighbor on R1 shows that adjacencies to R2 and R3 are up.
R1#show ip eigrp neighbor
IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO Q Seq Type
(sec) (ms) Cnt Num
1 172.12.123.3 Se0/0 11 00:02:45 1 5000 0 1
0 172.12.123.2 Se0/0 161 00:03:01 1 5000 0 1
Each router will now advertise its loopback address via EIGRP.
R1#conf t
R1(config)#router eigrp 100
R1(config-router)#network 1.1.1.0 0.0.0.255
R2#conf t
R2(config)#router eigrp 100
R2(config-router)#network 2.2.2.0 0.0.0.255
R3#conf t
R3(config)#router eigrp 100
R3(config-router)#network 3.3.3.0 0.0.0.255
Running show ip eigrp route on each router shows that R1 has a route for both R2’s and R3’s loopback. R2 and R3 will only see R1’s loopback address, and not each other’s. Why?
R1#show ip route eigrp
2.0.0.0/24 is subnetted, 1 subnets
D 2.2.2.0 [90/2297856] via 172.12.123.2, 00:03:19, Serial0/0
3.0.0.0/24 is subnetted, 1 subnets
D 3.3.3.0 [90/2297856] via 172.12.123.3, 00:03:04, Serial0/0
R2#show ip route eigrp
1.0.0.0/24 is subnetted, 1 subnets
D 1.1.1.0 [90/2297856] via 172.12.123.1, 00:03:40, Serial0/0.123
R3#show ip route eigrp
1.0.0.0/24 is subnetted, 1 subnets
D 1.1.1.0 [90/2297856] via 172.12.123.1, 00:05:17, Serial0/0.31
EIGRP uses Split Horizon by default to prevent routing loops. In this lab, though, it prevents full network reachability. R2 and R3 both form neighbor relationships with R1’s Serial physical interface. R2 advertises its loopback address to R1’s Serial interface, as does R3. Split Horizon does not allow a route to be advertised back out the same interface it was received on. This prevents R1 from advertising R2’s loopback to R3, or R3’s loopback to R2.
Split Horizon must be disabled to allow full network reachability in this lab. To do so, run no ip split-horizon eigrp 100 on R1’s Serial interface. When Split Horizon is disabled, that will cause the neighbor
relationships to fail, and then reestablish. Run show ip route eigrp 100 on both R2 and R3. The appropriate route to the remote loopback address will now appear.
R1#conf t
R1(config)#int serial0
R1(config-if)#no ip split-horizon eigrp 100
10:02:23: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.123.2 (Serial0/0) down: split horizon changed
10:02:23: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.123.3 (Serial0/0) down: split horizon changed
10:02:27: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.123.3 (Serial0/0) ip: new adjacency
10:02:54: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.123.2 (Serial0/0) ip: new adjacency
R2#show ip route eigrp
1.0.0.0/24 is subnetted, 1 subnets
D 1.1.1.0 [90/2297856] via 172.12.123.1, 00:00:06, Serial0/0.123
3.0.0.0/24 is subnetted, 1 subnets
D 3.3.3.0 [90/2809856] via 172.12.123.1, 00:00:06, Serial0/0.123
R3#show ip route eigrp
1.0.0.0/24 is subnetted, 1 subnets
D 1.1.1.0 [90/2297856] via 172.12.123.1, 00:00:12, Serial0/0.31
2.0.0.0/24 is subnetted, 1 subnets
D 2.2.2.0 [90/2809856] via 172.12.123.1, 00:00:12, Serial0/0.31
Disabling split horizon should be done with care, but knowing when and where to do so shows that you truly understand how this technology works - and that's a big step on the way to earning your CCNA!
Cisco CCNA Exam Tutorial: Loopback Interfaces
As a CCNA candidate, you most likely have some background in PC hardware and workstation support. If so, you're already familiar with loopback interfaces, particularly 127.0.0.1, the loopback address assigned to a PC.
When you're learning all about the different physical interfaces for your CCNA exam - serial, ethernet, and BRI, among others - there's one logical interface you need to know about, and that is - you guessed it! - the loopback interface.
What isn't as immediately apparent is why we use loopback interfaces on routers and switches to begin with. Many of the Cisco router features that can use loopbacks are intermediate and advanced features that you'll learn about in your CCNP and CCIE studies, but these features all come back to one basic concept: If the loopback interface on a router is down, that means the router is unavailable as a whole.
In contrast, a physical interface being down does not mean the router itself is out of commission. A router's ethernet port can go down, but the other physical interfaces on that router are still operational. Since a loopback interface is logical, there's nothing physical that can go wrong with it.
As I mentioned, you'll learn different Cisco router and switch features that utilize loopback interfaces as you climb the Cisco certification ladder. There's one misconception about Cisco loopback interfaces that you want to get clear on now, though. You’re probably familiar with loopback interfaces on a PC, and may even know that the address range 127.0.0.0 is reserved for loopback addressing.
Note that this reserved address range does not apply to loopbacks on Cisco devices, however. If you attempt to assign an address from this range to a Cisco loopback interface, you get this result:
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#interface loopback0
R1(config-if)#ip address 127.0.0.2 255.255.255.0
Not a valid host address - 127.0.0.2
R1(config-if)#ip address 127.1.1.1 255.255.255.0
Not a valid host address - 127.1.1.1
The range 127.0.0.0 is reserved for host loopbacks (such as PCs), not routers or switches. The most commonly used address from this range is 127.0.0.1 – if you can’t ping that on a workstation, that means you can’t ping yourself, which means there’s a problem with the TCP/IP install itself.
Keep these details in mind on the exam and in the workplace, and you’re on your way to CCNA exam success!
When you're learning all about the different physical interfaces for your CCNA exam - serial, ethernet, and BRI, among others - there's one logical interface you need to know about, and that is - you guessed it! - the loopback interface.
What isn't as immediately apparent is why we use loopback interfaces on routers and switches to begin with. Many of the Cisco router features that can use loopbacks are intermediate and advanced features that you'll learn about in your CCNP and CCIE studies, but these features all come back to one basic concept: If the loopback interface on a router is down, that means the router is unavailable as a whole.
In contrast, a physical interface being down does not mean the router itself is out of commission. A router's ethernet port can go down, but the other physical interfaces on that router are still operational. Since a loopback interface is logical, there's nothing physical that can go wrong with it.
As I mentioned, you'll learn different Cisco router and switch features that utilize loopback interfaces as you climb the Cisco certification ladder. There's one misconception about Cisco loopback interfaces that you want to get clear on now, though. You’re probably familiar with loopback interfaces on a PC, and may even know that the address range 127.0.0.0 is reserved for loopback addressing.
Note that this reserved address range does not apply to loopbacks on Cisco devices, however. If you attempt to assign an address from this range to a Cisco loopback interface, you get this result:
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#interface loopback0
R1(config-if)#ip address 127.0.0.2 255.255.255.0
Not a valid host address - 127.0.0.2
R1(config-if)#ip address 127.1.1.1 255.255.255.0
Not a valid host address - 127.1.1.1
The range 127.0.0.0 is reserved for host loopbacks (such as PCs), not routers or switches. The most commonly used address from this range is 127.0.0.1 – if you can’t ping that on a workstation, that means you can’t ping yourself, which means there’s a problem with the TCP/IP install itself.
Keep these details in mind on the exam and in the workplace, and you’re on your way to CCNA exam success!
Cisco CCNA Exam Tutorial: Five ISDN Details To Remember
CCNA exam success depends on mastering many technologies that are new to you, and few exam topics have more details than ISDN. ISDN isn't just for your CCNA exam studies, though. While ISDN is dismissed by many, the fact is that there are many small and mid-size networks out there that use ISDN as their backup to frame relay. Some of these companies have spoke networks that use ISDN to connect to their hub as well, so it's a great idea to know ISDN configuration and troubleshooting for your real-world career as well as passing the CCNA. With that in mind, let's take a look at five common ISDN errors and how to avoid them.
With dialer map statements, remember that the phone number you put in the dialer map is the phone number of the remote router, not the local one. Look at it this way - if you want to call a friend on your cell, you don't pick up your cell and dial your own number!
Speaking of dialer map statements, don't forget the all-important broadcast option at the end of the command:
R1(config-if)#dialer map ip 172.12.21.1 name R2 broadcast 5555555
The router will accept that command without the "broadcast" option, but routing protocol updates and hellos would not be able to travel across the line. (This command is also needed in frame relay map statements to allow broadcasts and multicasts to be transmitted.)
PAP is PPP's clear-text authentication scheme, and clear text is a really bad idea. But if you do have to configure it, don't forget that PAP requires additional configuration -the ppp pap sent-username command.
R1(config-if)#ppp pap sent-username R1 password CISCO
Must set encapsulation to PPP before using PPP subcommands
R1(config-if)#
The error message we got while configuring the sent-username command is another important reminder - by default, a BRI line is running HDLC, not PPP. Since HDLC doesn't allow us to use either PAP or CHAP, we'll need to set the link to PPP with the encapsulation ppp command.
R1(config-if)#encapsulation ppp
R1(config-if)#ppp authentication pap
R1(config-if)#ppp pap sent-username R1 password CISCO
But before we configure any of this information, we should configure the ISDN switch-type. Why? Because without the switch-type configuration, it doesn't matter that we avoid the other four errors - the line will not come up. Configure the switch-type with the "isdn switch-type" command, and then verify it with "show isdn status".
R1(config)#isdn switch-type basic-ni
R1#show isdn status
Global ISDN Switchtype = basic-ni (output of this command cut here for clarity)
If you forget this part of the configuration, the output of show isdn status wastes no time in reminding you!
R1#show isdn status
**** No Global ISDN Switchtype currently defined ****
ISDN is an important part of your CCNA studies, and this knowledge still comes in handy in production networks as well. Keep studying, notice the details, run those debugs, and you'll be a CCNA before you know it!
With dialer map statements, remember that the phone number you put in the dialer map is the phone number of the remote router, not the local one. Look at it this way - if you want to call a friend on your cell, you don't pick up your cell and dial your own number!
Speaking of dialer map statements, don't forget the all-important broadcast option at the end of the command:
R1(config-if)#dialer map ip 172.12.21.1 name R2 broadcast 5555555
The router will accept that command without the "broadcast" option, but routing protocol updates and hellos would not be able to travel across the line. (This command is also needed in frame relay map statements to allow broadcasts and multicasts to be transmitted.)
PAP is PPP's clear-text authentication scheme, and clear text is a really bad idea. But if you do have to configure it, don't forget that PAP requires additional configuration -the ppp pap sent-username command.
R1(config-if)#ppp pap sent-username R1 password CISCO
Must set encapsulation to PPP before using PPP subcommands
R1(config-if)#
The error message we got while configuring the sent-username command is another important reminder - by default, a BRI line is running HDLC, not PPP. Since HDLC doesn't allow us to use either PAP or CHAP, we'll need to set the link to PPP with the encapsulation ppp command.
R1(config-if)#encapsulation ppp
R1(config-if)#ppp authentication pap
R1(config-if)#ppp pap sent-username R1 password CISCO
But before we configure any of this information, we should configure the ISDN switch-type. Why? Because without the switch-type configuration, it doesn't matter that we avoid the other four errors - the line will not come up. Configure the switch-type with the "isdn switch-type" command, and then verify it with "show isdn status".
R1(config)#isdn switch-type basic-ni
R1#show isdn status
Global ISDN Switchtype = basic-ni (output of this command cut here for clarity)
If you forget this part of the configuration, the output of show isdn status wastes no time in reminding you!
R1#show isdn status
**** No Global ISDN Switchtype currently defined ****
ISDN is an important part of your CCNA studies, and this knowledge still comes in handy in production networks as well. Keep studying, notice the details, run those debugs, and you'll be a CCNA before you know it!
Cisco CCNA Exam Tutorial: Directly Connected Serial Interfaces
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.
R3(config)#int s1
R3(config-if)#clockrate 56000
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!
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.
R3(config)#int s1
R3(config-if)#clockrate 56000
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!
Wednesday, December 24, 2008
Cisco CCNA / CCNP Home Lab Tutorial: Using 2520 Routers
I know from experience that part of the excitement and anxiety of putting together your own CCNA / CCNP home lab is deciding what to buy! While you can make a workable home lab out of almost any combination of Cisco routers and switches, some routers are better suited for home lab work than others because they can fill multiple roles.
My personal favorite is the Cisco 2520. This router has four serial interfaces, making it an ideal frame relay switch. Don't forget that just because you're using a router as a frame switch, you can still use its routing capabilities. One setup I use is to use three of the four serial interfaces for frame switching and the fourth interface as a point-to-point network with another router. All you need is some DTE/DCE cables and you're all set.
The 2520 also comes with one ethernet interface and an ISDN interface, so that gives you even more options. Even if you're not planning to run ISDN in your home lab right now, you may choose to do so in the future - and with a 2520, you've already got the right router to do so. Keep in mind that if you are going to run ISDN in your home lab, you’ll need an ISDN device such as an ISDN simulator in your lab. (ISDN simulators are physical devices and are plentiful on ebay – they’re no relation to “router simulators”.)
Again, I want to reiterate that you can work any Cisco router into a CCNA / CCNP home lab - there's no "right" or "wrong" combination of equipment. But as with anything else, some combinations are better than others, so consider adding some 2520s to your home lab! This router gives you a great combination of interfaces and capabilities, plus the most important factor of all - real hands-on experience during your CCNA and CCNP exam preparation!
My personal favorite is the Cisco 2520. This router has four serial interfaces, making it an ideal frame relay switch. Don't forget that just because you're using a router as a frame switch, you can still use its routing capabilities. One setup I use is to use three of the four serial interfaces for frame switching and the fourth interface as a point-to-point network with another router. All you need is some DTE/DCE cables and you're all set.
The 2520 also comes with one ethernet interface and an ISDN interface, so that gives you even more options. Even if you're not planning to run ISDN in your home lab right now, you may choose to do so in the future - and with a 2520, you've already got the right router to do so. Keep in mind that if you are going to run ISDN in your home lab, you’ll need an ISDN device such as an ISDN simulator in your lab. (ISDN simulators are physical devices and are plentiful on ebay – they’re no relation to “router simulators”.)
Again, I want to reiterate that you can work any Cisco router into a CCNA / CCNP home lab - there's no "right" or "wrong" combination of equipment. But as with anything else, some combinations are better than others, so consider adding some 2520s to your home lab! This router gives you a great combination of interfaces and capabilities, plus the most important factor of all - real hands-on experience during your CCNA and CCNP exam preparation!
Cisco CCNA / CCNP Home Lab Tutorial: The 2503 Router
I know from experience that part of the excitement and anxiety of putting together your own CCNA / CCNP home lab is deciding what to buy! While you can make a workable home lab out of almost any combination of Cisco routers and switches, some routers are better suited for home lab work than others because they can fill multiple roles.
When you buy CCNA or CCNP "lab kits" - bundles of routers and switches - you can get a little confused about whether you're getting a good deal. One router I get asked about quite a bit is the 2503.
2503 routers are fantastic for CCNA and CCNP home labs. They come with two serial interfaces, allowing you to connect one interface directly to another router (you'll need a DTE/DCE cable for that, too) while connecting another to a frame relay switch if you like. If you don't have a frame relay switch, you can connect a 2503 directly to two other routers via the serial interfaces.
You also have an AUI port, which requires a transceiver to operate as your Ethernet interface. Transceivers are pretty cheap and readily available from Cisco resellers and ebay vendors, so pick one up for each 2503 you decide to buy.
2503 routers also come with a BRI interface. Even though you may not have an ISDN simulator right now, you may choose to add one later. That makes a 2503 a great bet for future lab expansion.
All in all, 2503 routers are great for your CCNA / CCNP home lab. They run about $125 each on ebay, or less, so they're also very affordable. There's no better training than training on your own CCNA or CCNP home lab, and you can always sell the equipment later if you like. Basically, you're renting the routers and switches, and the experience you get by working with the real deal is invaluable.
When you buy CCNA or CCNP "lab kits" - bundles of routers and switches - you can get a little confused about whether you're getting a good deal. One router I get asked about quite a bit is the 2503.
2503 routers are fantastic for CCNA and CCNP home labs. They come with two serial interfaces, allowing you to connect one interface directly to another router (you'll need a DTE/DCE cable for that, too) while connecting another to a frame relay switch if you like. If you don't have a frame relay switch, you can connect a 2503 directly to two other routers via the serial interfaces.
You also have an AUI port, which requires a transceiver to operate as your Ethernet interface. Transceivers are pretty cheap and readily available from Cisco resellers and ebay vendors, so pick one up for each 2503 you decide to buy.
2503 routers also come with a BRI interface. Even though you may not have an ISDN simulator right now, you may choose to add one later. That makes a 2503 a great bet for future lab expansion.
All in all, 2503 routers are great for your CCNA / CCNP home lab. They run about $125 each on ebay, or less, so they're also very affordable. There's no better training than training on your own CCNA or CCNP home lab, and you can always sell the equipment later if you like. Basically, you're renting the routers and switches, and the experience you get by working with the real deal is invaluable.
Cisco CCNA / CCNP Home Lab Tutorial: The 2503 Router
I know from experience that part of the excitement and anxiety of putting together your own CCNA / CCNP home lab is deciding what to buy! While you can make a workable home lab out of almost any combination of Cisco routers and switches, some routers are better suited for home lab work than others because they can fill multiple roles.
When you buy CCNA or CCNP "lab kits" - bundles of routers and switches - you can get a little confused about whether you're getting a good deal. One router I get asked about quite a bit is the 2503.
2503 routers are fantastic for CCNA and CCNP home labs. They come with two serial interfaces, allowing you to connect one interface directly to another router (you'll need a DTE/DCE cable for that, too) while connecting another to a frame relay switch if you like. If you don't have a frame relay switch, you can connect a 2503 directly to two other routers via the serial interfaces.
You also have an AUI port, which requires a transceiver to operate as your Ethernet interface. Transceivers are pretty cheap and readily available from Cisco resellers and ebay vendors, so pick one up for each 2503 you decide to buy.
2503 routers also come with a BRI interface. Even though you may not have an ISDN simulator right now, you may choose to add one later. That makes a 2503 a great bet for future lab expansion.
All in all, 2503 routers are great for your CCNA / CCNP home lab. They run about $125 each on ebay, or less, so they're also very affordable. There's no better training than training on your own CCNA or CCNP home lab, and you can always sell the equipment later if you like. Basically, you're renting the routers and switches, and the experience you get by working with the real deal is invaluable.
When you buy CCNA or CCNP "lab kits" - bundles of routers and switches - you can get a little confused about whether you're getting a good deal. One router I get asked about quite a bit is the 2503.
2503 routers are fantastic for CCNA and CCNP home labs. They come with two serial interfaces, allowing you to connect one interface directly to another router (you'll need a DTE/DCE cable for that, too) while connecting another to a frame relay switch if you like. If you don't have a frame relay switch, you can connect a 2503 directly to two other routers via the serial interfaces.
You also have an AUI port, which requires a transceiver to operate as your Ethernet interface. Transceivers are pretty cheap and readily available from Cisco resellers and ebay vendors, so pick one up for each 2503 you decide to buy.
2503 routers also come with a BRI interface. Even though you may not have an ISDN simulator right now, you may choose to add one later. That makes a 2503 a great bet for future lab expansion.
All in all, 2503 routers are great for your CCNA / CCNP home lab. They run about $125 each on ebay, or less, so they're also very affordable. There's no better training than training on your own CCNA or CCNP home lab, and you can always sell the equipment later if you like. Basically, you're renting the routers and switches, and the experience you get by working with the real deal is invaluable.
Cisco CCNA / CCNP Home Lab Tutorial: Planning Ahead For IE Study
Candidates preparing to pass the CCNP exams are putting together Cisco home labs like never before. With CCNA and CCNP home lab equipment more affordable than ever, candidates have realized the importance of working on real Cisco routers and switches on the way to earning their certifications.
One question I get often from CCNP candidates is goes something like this: "I'm planning on pursuing the CCIE after I get my CCNP. What kind of routers and switches should I buy now in order to use the same equipment in my CCIE home lab?"
This is going to sound strange coming from me, because I'm the #1 proponent of CCNA and CCNP candidates buying their own home labs. When it comes to the CCIE, though, I have to say that you're probably better off using rack rentals instead of investing big money now to buy more expensive equipment with which to earn your CCNP.
There are plenty of 2500 and 2600 routers out there that you can buy to prepare fully for your CCNA and CCNP exams that may not have the capability needed for IE preparation. (For instance, while 2500 routers are fantastic for CCNA and NP study, they shouldn't be used for IE study.) The issue with buying more expensive equipment is that Cisco rightfully updates the CCIE lab equipment list twice a year, and these moves can prove very costly for those who get caught in the middle of these changes.
Let me give you an example that I lived through myself. When I began pursuing the CCIE, Catalyst switches were in use in the lab. I had a Cat 5000 that I used for practice. When I was in the middle of my preparation, Cisco introduced L3 switched to the lab in the form of TWO 3550 switches. Not only was the Cat now almost useless for IE study, the new switches went for about $5500 apiece, so if I wanted to keep up with the new lab changes, it was going to cost me $11,000.
Again, I know that it's vitally important for today's CCNA and CCNP candidates to get hands-on experience with home labs. It's also great to think ahead when you're earning your CCNP, and pursuing the CCIE is one of the best decisions you'll ever make. Just keep this regular CCIE lab update in mind. I recommend that you keep your CCNP budget down while not investing in more expensive routers with the IE in mind, and wait until you have passed the CCNP and are actively engaged in CCIE study before making the decision between rack rentals and putting together your own IE lab.
One question I get often from CCNP candidates is goes something like this: "I'm planning on pursuing the CCIE after I get my CCNP. What kind of routers and switches should I buy now in order to use the same equipment in my CCIE home lab?"
This is going to sound strange coming from me, because I'm the #1 proponent of CCNA and CCNP candidates buying their own home labs. When it comes to the CCIE, though, I have to say that you're probably better off using rack rentals instead of investing big money now to buy more expensive equipment with which to earn your CCNP.
There are plenty of 2500 and 2600 routers out there that you can buy to prepare fully for your CCNA and CCNP exams that may not have the capability needed for IE preparation. (For instance, while 2500 routers are fantastic for CCNA and NP study, they shouldn't be used for IE study.) The issue with buying more expensive equipment is that Cisco rightfully updates the CCIE lab equipment list twice a year, and these moves can prove very costly for those who get caught in the middle of these changes.
Let me give you an example that I lived through myself. When I began pursuing the CCIE, Catalyst switches were in use in the lab. I had a Cat 5000 that I used for practice. When I was in the middle of my preparation, Cisco introduced L3 switched to the lab in the form of TWO 3550 switches. Not only was the Cat now almost useless for IE study, the new switches went for about $5500 apiece, so if I wanted to keep up with the new lab changes, it was going to cost me $11,000.
Again, I know that it's vitally important for today's CCNA and CCNP candidates to get hands-on experience with home labs. It's also great to think ahead when you're earning your CCNP, and pursuing the CCIE is one of the best decisions you'll ever make. Just keep this regular CCIE lab update in mind. I recommend that you keep your CCNP budget down while not investing in more expensive routers with the IE in mind, and wait until you have passed the CCNP and are actively engaged in CCIE study before making the decision between rack rentals and putting together your own IE lab.
Tuesday, December 23, 2008
Cisco CCNA / CCNP Certification Exam: Troubleshooting Direct Serial Connections
A prime topic of your CCNA and CCNP CIT exams will be connecting Cisco routers directly via their Serial interfaces, and while the configuration is straightforward, there are some vital details and show commands you must know in order to pass the exams and configure this successfully in production and home lab networks. Let's take a look at a sample configuration.
Connecting Cisco routers directly via their Serial interfaces works really well once you get it running - and getting such a connection up and running is easy enough. You can use show controller serial x to find out which endpoint is acting as the DCE, and it's the DCE that must be configured with the clockrate command.
R3#show controller serial 1
HD unit 1, idb = 0x11B4DC, driver structure at 0x121868
buffer size 1524 HD unit 1, V.35 DCE cable
R3(config)#int serial1
R3(config-if)#ip address 172.12.13.3 255.255.255.0
R3(config-if)#clockrate 56000
R3(config-if)#no shut
Failure to configure the clockrate has some interesting effects regarding the physical and logical state of the interfaces. Let's remove the clockrate from R3 and see what happens.
R3(config)#int s1
R3(config-if)#no clockrate 56000
R3(config-if)#
18:02:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down
The line protocol doesn't drop immediately, but it does drop. Let's run show interface serial1 to compare the physical and logical interface states.
R3#show int serial1
Serial1 is up, line protocol is down
Physically, the interface is fine, so the physical interface is up. It's only the logical part of the interface - the line protocol - that is down. It's the same situation on R1.
R1#show inter serial1
Serial1 is up, line protocol is down
While a router misconfiguration is the most likely cause of a serial connection issue, that's not the only reason for clocking issues. Cisco's website documentation mentions CSU/DSU misconfiguration, out-of-spec cables, bad patch panel connections, and connecting too many cables together as other reasons for clocking problems. Still, the number one reason for clocking problems in my experience is simply forgetting to configure the clockrate command!
Connecting Cisco routers directly via their Serial interfaces works really well once you get it running - and getting such a connection up and running is easy enough. You can use show controller serial x to find out which endpoint is acting as the DCE, and it's the DCE that must be configured with the clockrate command.
R3#show controller serial 1
HD unit 1, idb = 0x11B4DC, driver structure at 0x121868
buffer size 1524 HD unit 1, V.35 DCE cable
R3(config)#int serial1
R3(config-if)#ip address 172.12.13.3 255.255.255.0
R3(config-if)#clockrate 56000
R3(config-if)#no shut
Failure to configure the clockrate has some interesting effects regarding the physical and logical state of the interfaces. Let's remove the clockrate from R3 and see what happens.
R3(config)#int s1
R3(config-if)#no clockrate 56000
R3(config-if)#
18:02:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down
The line protocol doesn't drop immediately, but it does drop. Let's run show interface serial1 to compare the physical and logical interface states.
R3#show int serial1
Serial1 is up, line protocol is down
Physically, the interface is fine, so the physical interface is up. It's only the logical part of the interface - the line protocol - that is down. It's the same situation on R1.
R1#show inter serial1
Serial1 is up, line protocol is down
While a router misconfiguration is the most likely cause of a serial connection issue, that's not the only reason for clocking issues. Cisco's website documentation mentions CSU/DSU misconfiguration, out-of-spec cables, bad patch panel connections, and connecting too many cables together as other reasons for clocking problems. Still, the number one reason for clocking problems in my experience is simply forgetting to configure the clockrate command!
Cisco CCNA / CCNP Certification Exam: Frame Relay Encapsulation Types
When you're studying to pass the Cisco CCNA and CCNP certification exams, you quickly learn that there's always something else to learn. (You'll really pick up on this in your CCIE studies, trust me!) Today we'll take a look at an often-overlooked topic in Frame Relay, the encapsulation type. You don't exactly change this on a daily basis in production networks (not if you want to stay employed, anyway!), but it's an important exam topic that you must be familiar with.
The DCE and DTE must agree on the LMI type, but there's another value that must be agreed upon by the two DTEs serving as the endpoints of the VC. The Frame encapsulation can be left at the default of Cisco (which is Cisco-proprietary), or it can be changed to the industry-standard IETF, as shown below. If a non-Cisco router is the remote endpoint, IETF encapsulation must be used. Note that the default of Cisco isn't listed as an option by IOS Help, so you better know that one by heart!
R1(config)#int s0
R1(config-if)#encap frame ?
ietf Use RFC1490/RFC2427 encapsulation
R1(config-if)#encap frame ietf
What if a physical interface is in use and some remote hosts require Cisco encapsulation and others require IETF? The encapsulation type can be configured on a per-PVC basis as well. One encap type can be used on the interface, and any map statements that require a different encap type can have that specified in the appropriate map statement. In the following example, all PVCs will use the default Cisco encapsulation type except for PVC 115. The frame map statement using that PVC has ietf specified.
R1(config)#int s0/0
R1(config-if)#encap frame
R1(config-if)#frame map ip 172.12.123.3 123 broadcast
R1(config-if)#frame map ip 172.12.123.2 122 ietf broadcast
show frame map shows us that the mapping to DLCI 123 is using Cisco encapsulation, and DLCI 122 is using IETF.
R1#show frame map
Serial0 (up): ip 172.12.123.3 dlci 123(0x7B,0x1CB0), static
broadcast, CISCO, status defined, active
Serial0 (up): ip 172.12.123.2 dlci 122(0x7B,0x1CB0), static
broadcast, ietf, status defined, active
Just remember that Cisco is the default, and all PVCs will use Cisco unless you specify IETF in the frame map statement itself. You could also change the entire interface to use IETF for all mappings with the frame-relay encapsulation IETF command. For Cisco exams, as well as work on production networks, it's always a good idea to know more than one way to do something!
The DCE and DTE must agree on the LMI type, but there's another value that must be agreed upon by the two DTEs serving as the endpoints of the VC. The Frame encapsulation can be left at the default of Cisco (which is Cisco-proprietary), or it can be changed to the industry-standard IETF, as shown below. If a non-Cisco router is the remote endpoint, IETF encapsulation must be used. Note that the default of Cisco isn't listed as an option by IOS Help, so you better know that one by heart!
R1(config)#int s0
R1(config-if)#encap frame ?
ietf Use RFC1490/RFC2427 encapsulation
R1(config-if)#encap frame ietf
What if a physical interface is in use and some remote hosts require Cisco encapsulation and others require IETF? The encapsulation type can be configured on a per-PVC basis as well. One encap type can be used on the interface, and any map statements that require a different encap type can have that specified in the appropriate map statement. In the following example, all PVCs will use the default Cisco encapsulation type except for PVC 115. The frame map statement using that PVC has ietf specified.
R1(config)#int s0/0
R1(config-if)#encap frame
R1(config-if)#frame map ip 172.12.123.3 123 broadcast
R1(config-if)#frame map ip 172.12.123.2 122 ietf broadcast
show frame map shows us that the mapping to DLCI 123 is using Cisco encapsulation, and DLCI 122 is using IETF.
R1#show frame map
Serial0 (up): ip 172.12.123.3 dlci 123(0x7B,0x1CB0), static
broadcast, CISCO, status defined, active
Serial0 (up): ip 172.12.123.2 dlci 122(0x7B,0x1CB0), static
broadcast, ietf, status defined, active
Just remember that Cisco is the default, and all PVCs will use Cisco unless you specify IETF in the frame map statement itself. You could also change the entire interface to use IETF for all mappings with the frame-relay encapsulation IETF command. For Cisco exams, as well as work on production networks, it's always a good idea to know more than one way to do something!
Monday, December 22, 2008
CCNP / BSCI Exam Tutorial: Route Summarization And The OSPF Null Interface
CCNP exam success, particularly on the BSCI exam, demands you understand the details of route summarization. This skill not only requires that you have a comfort level with binary conversions, but you have to know how and where to apply route summarization with each individual protocol.
You also have to know the "side effects" of route summarization. With OSPF, there will actually be an extra interface created at the point of summarization, and this catches a lot of CCNP candidates by surprise. Let's take a look at the null0 interface and how it relates to OSPF summarization.
On R1, the following networks are redistributed into OSPF, and then summarized.
interface Loopback16
ip address 16.16.16.16 255.0.0.0
interface Loopback17
ip address 17.17.17.17 255.0.0.0
interface Loopback18
ip address 18.18.18.18 255.0.0.0
interface Loopback19
ip address 19.19.19.19 255.0.0.0
R1(config)#router ospf 1
R1(config-router)#redistribute connected subnets
R1(config-router)#summary-address 16.0.0.0 252.0.0.0
The summary address appears on R2, a downstream router.
R2#show ip route ospf
O E2 16.0.0.0/6 [110/20] via 172.12.123.1, 00:00:05, Serial0
Let's go back to R1 and look at its OSPF table.
R1#show ip route ospf
O 16.0.0.0/6 is a summary, 00:01:51, Null0
Where did the null0 interface come from, and why is it there? Packets sent to the null interface are dropped, and in this case, that's a good thing.
When you configure summary routes in OSPF, a route to null0 will be installed into the OSPF routing table. This helps to prevent routing loops. Any packets destined for the routes that have been summarized will have a longer match in the routing table, as shown below...
C 17.0.0.0/8 is directly connected, Loopback17
C 16.0.0.0/8 is directly connected, Loopback16
C 19.0.0.0/8 is directly connected, Loopback19
C 18.0.0.0/8 is directly connected, Loopback18
O 16.0.0.0/6 is a summary, 00:01:51, Null0
.. and packets that do not match one of the summarized routes but do match the summary route will be dropped.
Preventing routing loops when performing route redistribution and summarization is vital. OSPF gives us a little help in that regard in this situation, and as you study more complex redistribution scenarios on your way to the CCNP and CCIE, you'll realize that we'll take all the help we can get!
You also have to know the "side effects" of route summarization. With OSPF, there will actually be an extra interface created at the point of summarization, and this catches a lot of CCNP candidates by surprise. Let's take a look at the null0 interface and how it relates to OSPF summarization.
On R1, the following networks are redistributed into OSPF, and then summarized.
interface Loopback16
ip address 16.16.16.16 255.0.0.0
interface Loopback17
ip address 17.17.17.17 255.0.0.0
interface Loopback18
ip address 18.18.18.18 255.0.0.0
interface Loopback19
ip address 19.19.19.19 255.0.0.0
R1(config)#router ospf 1
R1(config-router)#redistribute connected subnets
R1(config-router)#summary-address 16.0.0.0 252.0.0.0
The summary address appears on R2, a downstream router.
R2#show ip route ospf
O E2 16.0.0.0/6 [110/20] via 172.12.123.1, 00:00:05, Serial0
Let's go back to R1 and look at its OSPF table.
R1#show ip route ospf
O 16.0.0.0/6 is a summary, 00:01:51, Null0
Where did the null0 interface come from, and why is it there? Packets sent to the null interface are dropped, and in this case, that's a good thing.
When you configure summary routes in OSPF, a route to null0 will be installed into the OSPF routing table. This helps to prevent routing loops. Any packets destined for the routes that have been summarized will have a longer match in the routing table, as shown below...
C 17.0.0.0/8 is directly connected, Loopback17
C 16.0.0.0/8 is directly connected, Loopback16
C 19.0.0.0/8 is directly connected, Loopback19
C 18.0.0.0/8 is directly connected, Loopback18
O 16.0.0.0/6 is a summary, 00:01:51, Null0
.. and packets that do not match one of the summarized routes but do match the summary route will be dropped.
Preventing routing loops when performing route redistribution and summarization is vital. OSPF gives us a little help in that regard in this situation, and as you study more complex redistribution scenarios on your way to the CCNP and CCIE, you'll realize that we'll take all the help we can get!
Cisco CCNP / BSCI Exam Tutorial: Not All Static Routes Are Created Equal
As a CCNP candidate, as a CCNA, and in getting ready to pass the BSCI exam, you may be tempted to breeze through your static route studies, or even skip them! That's because static routes are easy enough to configure, and as long as you remember the syntax of the ip route command, you're in good shape.
But there's one vital detail regarding static routes that many exam candidates miss. That's because many CCNA and CCNP books say "the administrative distance of a static route is 1", but that is not quite accurate.
You know from your CCNA studies that the ip route command is used to create a static route, and that you have the option of configuring a local exit interface or a next-hop IP address at the end of the command. However, the administrative distances are not the same. The AD of a static route that uses a local exit interface is zero! (That's because the router considers a static route with a local exit interface to actually be a directly connected network.) The AD of a static route with a next-hop IP address is 1.
Therefore, if the router has the following two ip route statements to consider...
Router(config)#ip route 172.1.1.1 255.255.255.255 fast0
Router(config)#ip route 172.1.1.1 255.255.255.255 210.1.1.1
... the prefix lengths are the same, so the static route using the local exit interface fastethernet0 will be preferred due to its lower AD, and will be installed into the routing table.
Keep the details in mind on the job and in the exam room, and you’re on your way to CCNP exam success!
But there's one vital detail regarding static routes that many exam candidates miss. That's because many CCNA and CCNP books say "the administrative distance of a static route is 1", but that is not quite accurate.
You know from your CCNA studies that the ip route command is used to create a static route, and that you have the option of configuring a local exit interface or a next-hop IP address at the end of the command. However, the administrative distances are not the same. The AD of a static route that uses a local exit interface is zero! (That's because the router considers a static route with a local exit interface to actually be a directly connected network.) The AD of a static route with a next-hop IP address is 1.
Therefore, if the router has the following two ip route statements to consider...
Router(config)#ip route 172.1.1.1 255.255.255.255 fast0
Router(config)#ip route 172.1.1.1 255.255.255.255 210.1.1.1
... the prefix lengths are the same, so the static route using the local exit interface fastethernet0 will be preferred due to its lower AD, and will be installed into the routing table.
Keep the details in mind on the job and in the exam room, and you’re on your way to CCNP exam success!
Subscribe to:
Posts (Atom)
