More CCNA and CCNP candidates than ever before are putting together their own home practice labs. It's more affordable than it ever has been, and I receive emails daily from new CCNAs and CCNPs who say it's the best thing they could have done to improve their studies.
There are some commands you can configure on your lab routers that won't necessarily be on your CCNA or CCNP exams, but they will make life a lot easier for you. Let's take a look at just a few of these.
The command "no exec" is short, yet powerful. Occasionally you'll have what is referred to as a "rogue EXEC" process tie up a line, and you end up having to continually clear lines, which disrupts your practice. If you have an access server, I highly recommend you configure this command on your lines, as shown here:
ACCESS_SERVER(con)#line 1 8
ACCESS_SERVER(con)#no exec
From your CCNA studies, you know that the command "no ip domain-lookup" prevents a Cisco router from sending a broadcast to find a DNS server anytime you enter something that is not an IOS command - and that includes mistyped commands, which happens to all of us sooner or later. Make sure to run that command in global configuration mode on all your practice routers.
There are two commands I like to configure on the console line on all my practice routers and switches. The first is "exec-timeout 0 0", which prevents you from being kicked out of enable mode and back into user exec after a few minutes of inactivity. (This doesn't sound like much, but you'll get pretty tired of typing "enable" after a while.) The first zero refers to minutes, the second zero to seconds. Setting them both to zero disables the exec-timeout function.
The second command prevents the router from interrupting the command you're typing with a console message. If you've ever been in the middle of typing a router command and suddenly you're interrupted with a logging message, you know that can be pretty annoying. We don't want the router to not display the message, but we do want the router to wait until we're done entering data. The command to perform this is "logging synchronous".
R1(config)#line console 0
R1(config-line)#exec-timeout 0 0
R1(config-line)#logging synchronous
You won't see many of these commands on your exams, but after you configure them on your home lab devices, you'll wonder how you did without them!
Showing posts with label show. Show all posts
Showing posts with label show. Show all posts
Friday, December 26, 2008
Thursday, December 25, 2008
Cisco CCNP / BSCI Exam Tutorial: Introduction To Policy Routing
Policy routing is a major topic on your BSCI exam, and you'll find quite a bit of policy routing going on in today's production networks. But what exactly is policy routing?
Policy-based routing, generally referred to as "policy routing", is the use of route maps to determine the path a packet will take to get to its final destination. As you progress through your CCNP studies and go on to the CCIE (or to a Cisco Quality Of Service certification), you'll find that traffic can be "marked" by policy routing in order to give different levels of service to various classes of traffic. (This is done by marking the traffic and placing the different classes of traffic in different queues in the router, allowing the administrator to give some traffic higher priority for transmission.)
There are some basic policy routing rules you should know:
Policy routing doesn't affect the destination of the packet, but does affect the path that is taken to get there.
Policy routing can forward traffic based on the source IP address or the destination IP address (with the use of an extended ACL).
Policy routing can be configured at the interface level, or globally.
Applying policy routing on an interface affects only packets arriving on that interface:
R2(config)#int s0
R2(config-if)#ip policy route-map CHANGE_NEXT_HOP
Applying the policy globally applies the route map to packets generated on the router, not on all packets received on all interfaces.
Whether you're running policy routing at the interface level, on packets created locally, or both, always run the command show ip policy to make sure you've got the right route maps on the proper interfaces.
R2#show ip policy
Interface Route map
local CHANGE_NEXT_HOP
Serial0 CHANGE_NEXT_HOP
And here's the big rule to remember....
If a packet doesn't match any of the specific criteria in a route map, or does match a line that has an explicit deny statement, the data is sent to the routing process and will be processed normally. If you don't want to route packets that do not meet any route map criteria, the set command must be used to send those packets to the null0 interface. This set command should be the final set command in the route map.
There are four possibilities for an incoming packet when route maps are in use. The following example illustrates all of them.
R2(config)#access-list 29 permit host 20.1.1.1
R2(config)#access-list 30 permit host 20.2.2.2
R2(config)#access-list 31 permit host 20.3.3.3
R2(config)#access-list 32 permit host 20.4.4.4
R2(config)#route-map EXAMPLE permit 10
R2(config-route-map)#match ip address 29
R2(config-route-map)#set ip next-hop 40.1.1.1
R2(config-route-map)#route-map EXAMPLE permit 20
R2(config-route-map)#match ip address 30
Assuming the route map has been applied to the router's ethernet0 interface, a packet sourced from 20.1.1.1 would meet the first line of the route map and have its next-hop IP address set to 40.1.1.1.
A packet sourced from 20.2.2.2 would match the next permit statement (sequence number 20). Since there is no action listed, this packet would return to the routing engine to undergo the normal routing procedure. All traffic that did not match these two addresses would also be routed normally - there would be no action taken by the route map.
Perhaps we want to specifically block traffic sourced from 20.3.3.3 or 20.4.4.4. We can use multiple match statements in one single route map, and have packets matching those two addresses sent to the bit bucket - the interface null0.
R2(config)#route-map EXAMPLE permit 30
R2(config-route-map)#match ip address 31
R2(config-route-map)#match ip address 32
R2(config-route-map)#set ?
as-path Prepend string for a BGP AS-path attribute
automatic-tag Automatically compute TAG value
comm-list set BGP community list (for deletion)
community BGP community attribute
dampening Set BGP route flap dampening parameters
default Set default information
extcommunity BGP extended community attribute
interface Output interface
ip IP specific information
level Where to import route
local-preference BGP local preference path attribute
metric Metric value for destination routing protocol
metric-type Type of metric for destination routing protocol
origin BGP origin code
tag Tag value for destination routing protocol
weight BGP weight for routing table
R2(config-route-map)#set interface null0
Any traffic matching ACLs 31 or 32 will be sent to null0, resulting in its being discarded by the router. Any traffic that didn't match any of the route map statements will be returned to the routing engine for normal processing.
Knowing policy routing and how to apply it are essential skills for passing the BSCI exam, earning your CCNP, and becoming more valuable in today's job market. Get some hands-on practice in a CCNA / CCNP home lab or rack rental to go along with learning the theory, and you'll be writing and applying policy routing in no time at all.
Policy-based routing, generally referred to as "policy routing", is the use of route maps to determine the path a packet will take to get to its final destination. As you progress through your CCNP studies and go on to the CCIE (or to a Cisco Quality Of Service certification), you'll find that traffic can be "marked" by policy routing in order to give different levels of service to various classes of traffic. (This is done by marking the traffic and placing the different classes of traffic in different queues in the router, allowing the administrator to give some traffic higher priority for transmission.)
There are some basic policy routing rules you should know:
Policy routing doesn't affect the destination of the packet, but does affect the path that is taken to get there.
Policy routing can forward traffic based on the source IP address or the destination IP address (with the use of an extended ACL).
Policy routing can be configured at the interface level, or globally.
Applying policy routing on an interface affects only packets arriving on that interface:
R2(config)#int s0
R2(config-if)#ip policy route-map CHANGE_NEXT_HOP
Applying the policy globally applies the route map to packets generated on the router, not on all packets received on all interfaces.
Whether you're running policy routing at the interface level, on packets created locally, or both, always run the command show ip policy to make sure you've got the right route maps on the proper interfaces.
R2#show ip policy
Interface Route map
local CHANGE_NEXT_HOP
Serial0 CHANGE_NEXT_HOP
And here's the big rule to remember....
If a packet doesn't match any of the specific criteria in a route map, or does match a line that has an explicit deny statement, the data is sent to the routing process and will be processed normally. If you don't want to route packets that do not meet any route map criteria, the set command must be used to send those packets to the null0 interface. This set command should be the final set command in the route map.
There are four possibilities for an incoming packet when route maps are in use. The following example illustrates all of them.
R2(config)#access-list 29 permit host 20.1.1.1
R2(config)#access-list 30 permit host 20.2.2.2
R2(config)#access-list 31 permit host 20.3.3.3
R2(config)#access-list 32 permit host 20.4.4.4
R2(config)#route-map EXAMPLE permit 10
R2(config-route-map)#match ip address 29
R2(config-route-map)#set ip next-hop 40.1.1.1
R2(config-route-map)#route-map EXAMPLE permit 20
R2(config-route-map)#match ip address 30
Assuming the route map has been applied to the router's ethernet0 interface, a packet sourced from 20.1.1.1 would meet the first line of the route map and have its next-hop IP address set to 40.1.1.1.
A packet sourced from 20.2.2.2 would match the next permit statement (sequence number 20). Since there is no action listed, this packet would return to the routing engine to undergo the normal routing procedure. All traffic that did not match these two addresses would also be routed normally - there would be no action taken by the route map.
Perhaps we want to specifically block traffic sourced from 20.3.3.3 or 20.4.4.4. We can use multiple match statements in one single route map, and have packets matching those two addresses sent to the bit bucket - the interface null0.
R2(config)#route-map EXAMPLE permit 30
R2(config-route-map)#match ip address 31
R2(config-route-map)#match ip address 32
R2(config-route-map)#set ?
as-path Prepend string for a BGP AS-path attribute
automatic-tag Automatically compute TAG value
comm-list set BGP community list (for deletion)
community BGP community attribute
dampening Set BGP route flap dampening parameters
default Set default information
extcommunity BGP extended community attribute
interface Output interface
ip IP specific information
level Where to import route
local-preference BGP local preference path attribute
metric Metric value for destination routing protocol
metric-type Type of metric for destination routing protocol
origin BGP origin code
tag Tag value for destination routing protocol
weight BGP weight for routing table
R2(config-route-map)#set interface null0
Any traffic matching ACLs 31 or 32 will be sent to null0, resulting in its being discarded by the router. Any traffic that didn't match any of the route map statements will be returned to the routing engine for normal processing.
Knowing policy routing and how to apply it are essential skills for passing the BSCI exam, earning your CCNP, and becoming more valuable in today's job market. Get some hands-on practice in a CCNA / CCNP home lab or rack rental to go along with learning the theory, and you'll be writing and applying policy routing in no time at all.
Cisco CCNP / BSCI Certification: Troubleshooting Route Redistribution, Part I
If there's one CCNP / BSCI topic that looks so easy but can lead to a real headache, it's route redistribution. I'm not even talking about the routing loops and suboptimal routing that can result when route redistribution is done without proper planning - I'm talking about the basic commands themselves. Leaving out one single command option, or forgetting what else needs to be redistributed when redistributing dynamically discovered routes, can leave you with a routing table that looks complete but does not result in full IP connectivity.
In this free CCNP / BSCI tutorial series, we'll take a look at three common errors in route redistribution configurations, and how to fix them. We'll use three routers, R1, R3, and R5. R1 and R5 are in a RIPv2 domain and R1 and R3 are in an OSPF domain. R1 will be performing two-way route redistribution.
R5 is advertising its loopback, 5.5.5.5/24, into the RIPv2 domain. R1 sees this route in its RIP routing table:
R1#show ip route rip
5.0.0.0/24 is subnetted, 1 subnets
R 5.5.5.0 [120/1] via 100.1.1.5, 00:00:01, Ethernet0
For R3 to see this route, route redistribution must be configured on R1. We'll use the redistribute rip command to do so.
R1(config)#router ospf 1
R1(config-router)#redistribute rip
% Only classful networks will be redistributed
The router immediately gives us a message that "only classful networks will be redistributed". What does this mean? Let's go to R3 and see if that router is receiving this route.
R3#show ip route ospf
< no output >
When we get no result from a show command, that means there's nothing to show. The only routes that will be successfully redistributed with the current configuration on R1 are classful networks, and 5.5.5.0/24 is a subnet.
To further illustrate the point, a classful network has been added to R5. This network is 16.0.0.0 /8, and is now being advertised by RIP. R1 sees this network as classful...
R1#show ip route rip
R 16.0.0.0/8 [120/1] via 100.1.1.5, 00:00:00, Ethernet0
5.0.0.0/24 is subnetted, 1 subnets
R 5.5.5.0 [120/1] via 100.1.1.5, 00:00:00, Ethernet0
... and R3 is receiving the route through redistribution.
R3#show ip route ospf
O E2 16.0.0.0/8 [110/20] via 172.12.123.1, 00:00:08, Serial0.31
To redistribute both classful and classless networks, the option "subnets" must be added to the redistribute command on R1.
R1(config)#router ospf 1
R1(config-router)#no redistribute rip
R1(config-router)#redistribute rip subnets
R3 will now see both the classful and classless networks being redistributed into OSPF. (100.1.1.0 is the network connecting R1 and R5.)
R3#show ip route ospf
O E2 16.0.0.0/8 [110/20] via 172.12.123.1, 00:00:20, Serial0.31
100.0.0.0/24 is subnetted, 1 subnets
O E2 100.1.1.0 [110/20] via 172.12.123.1, 00:00:20, Serial0.31
5.0.0.0/24 is subnetted, 1 subnets
O E2 5.5.5.0 [110/20] via 172.12.123.1, 00:00:20, Serial0.31
This is one of the most common errors made during route redistribution, but now you know what to look out for! In the next part of this free CCNP / BSCI tutorial, we'll take a look at another such error.
In this free CCNP / BSCI tutorial series, we'll take a look at three common errors in route redistribution configurations, and how to fix them. We'll use three routers, R1, R3, and R5. R1 and R5 are in a RIPv2 domain and R1 and R3 are in an OSPF domain. R1 will be performing two-way route redistribution.
R5 is advertising its loopback, 5.5.5.5/24, into the RIPv2 domain. R1 sees this route in its RIP routing table:
R1#show ip route rip
5.0.0.0/24 is subnetted, 1 subnets
R 5.5.5.0 [120/1] via 100.1.1.5, 00:00:01, Ethernet0
For R3 to see this route, route redistribution must be configured on R1. We'll use the redistribute rip command to do so.
R1(config)#router ospf 1
R1(config-router)#redistribute rip
% Only classful networks will be redistributed
The router immediately gives us a message that "only classful networks will be redistributed". What does this mean? Let's go to R3 and see if that router is receiving this route.
R3#show ip route ospf
< no output >
When we get no result from a show command, that means there's nothing to show. The only routes that will be successfully redistributed with the current configuration on R1 are classful networks, and 5.5.5.0/24 is a subnet.
To further illustrate the point, a classful network has been added to R5. This network is 16.0.0.0 /8, and is now being advertised by RIP. R1 sees this network as classful...
R1#show ip route rip
R 16.0.0.0/8 [120/1] via 100.1.1.5, 00:00:00, Ethernet0
5.0.0.0/24 is subnetted, 1 subnets
R 5.5.5.0 [120/1] via 100.1.1.5, 00:00:00, Ethernet0
... and R3 is receiving the route through redistribution.
R3#show ip route ospf
O E2 16.0.0.0/8 [110/20] via 172.12.123.1, 00:00:08, Serial0.31
To redistribute both classful and classless networks, the option "subnets" must be added to the redistribute command on R1.
R1(config)#router ospf 1
R1(config-router)#no redistribute rip
R1(config-router)#redistribute rip subnets
R3 will now see both the classful and classless networks being redistributed into OSPF. (100.1.1.0 is the network connecting R1 and R5.)
R3#show ip route ospf
O E2 16.0.0.0/8 [110/20] via 172.12.123.1, 00:00:20, Serial0.31
100.0.0.0/24 is subnetted, 1 subnets
O E2 100.1.1.0 [110/20] via 172.12.123.1, 00:00:20, Serial0.31
5.0.0.0/24 is subnetted, 1 subnets
O E2 5.5.5.0 [110/20] via 172.12.123.1, 00:00:20, Serial0.31
This is one of the most common errors made during route redistribution, but now you know what to look out for! In the next part of this free CCNP / BSCI tutorial, we'll take a look at another such error.
Cisco CCNA Exam Tutorial: Troubleshooting Directly Connected Serial Interfaces
CCNA exam success depends largely on noticing the details, and this is especially true of configurations involving directly connected serial interfaces. And of course, it's not enough to notice these details - you've got to know what to do about them!
A Cisco router is a DTE by default, but directly connecting two DTEs with a DCE/DTE cable is not enough. In the following example, R1 and R3 are directly connected at their Serial1 interfaces. The line goes up briefly after being opened, but the line protocol goes down after about 30 seconds.
R3(config-if)#int s1
R3(config-if)#ip address 172.12.13.3 255.255.255.0
R3(config-if)#no shutdown
2d18h: %LINK-3-UPDOWN: Interface Serial1, changed state to up
2d18h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
R3(config-if)#
2d18h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down
The problem is that one of the routers needs to act as the DCE in order for the line protocol to come up and stay up. If this were your CCNA / CCNP home lab, you could just go over and look at the DTE/DCE cable to see which router had the DCE end of the cable attached. In this example, though, we don't have physical access to the routers. How can we tell which router has the DCE end of the cable attached?
R3#show controller serial 1
HD unit 1, idb = 0x1C44E8, driver structure at 0x1CBAC8
buffer size 1524 HD unit 1, V.35 DCE cable
The show controller command gives us this information. (There's a lot more output that this with this command, but it's unimportant for our purposes.) The router with the DCE end of the cable needs to supply a clock rate to the DTE, and we'll do just that with the interface-level clockrate command.
R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#int serial1
R3(config-if)#clockrate 56000
2d18h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
In just a few seconds, the line protocol goes up and stays up.
When troubleshooting a connection, always run show interface first. If you see the combination shown below, the connection is physically fine but logically down. That's generally the result of a needed keepalive not being present. With Frame Relay, it's probably an LMI issue, but with directly connected serial interfaces the issue is most likely the DCE end of the connection not supplying clockrate.
R3#show interface serial 1
Serial1 is up, line protocol is down
Troubleshooting is a big part of the job, and it's a big part of the Cisco CCNA and CCNP programs as well. Know your show and debug commands and you're on your way to passing the CCNA!
A Cisco router is a DTE by default, but directly connecting two DTEs with a DCE/DTE cable is not enough. In the following example, R1 and R3 are directly connected at their Serial1 interfaces. The line goes up briefly after being opened, but the line protocol goes down after about 30 seconds.
R3(config-if)#int s1
R3(config-if)#ip address 172.12.13.3 255.255.255.0
R3(config-if)#no shutdown
2d18h: %LINK-3-UPDOWN: Interface Serial1, changed state to up
2d18h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
R3(config-if)#
2d18h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down
The problem is that one of the routers needs to act as the DCE in order for the line protocol to come up and stay up. If this were your CCNA / CCNP home lab, you could just go over and look at the DTE/DCE cable to see which router had the DCE end of the cable attached. In this example, though, we don't have physical access to the routers. How can we tell which router has the DCE end of the cable attached?
R3#show controller serial 1
HD unit 1, idb = 0x1C44E8, driver structure at 0x1CBAC8
buffer size 1524 HD unit 1, V.35 DCE cable
The show controller command gives us this information. (There's a lot more output that this with this command, but it's unimportant for our purposes.) The router with the DCE end of the cable needs to supply a clock rate to the DTE, and we'll do just that with the interface-level clockrate command.
R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#int serial1
R3(config-if)#clockrate 56000
2d18h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
In just a few seconds, the line protocol goes up and stays up.
When troubleshooting a connection, always run show interface first. If you see the combination shown below, the connection is physically fine but logically down. That's generally the result of a needed keepalive not being present. With Frame Relay, it's probably an LMI issue, but with directly connected serial interfaces the issue is most likely the DCE end of the connection not supplying clockrate.
R3#show interface serial 1
Serial1 is up, line protocol is down
Troubleshooting is a big part of the job, and it's a big part of the Cisco CCNA and CCNP programs as well. Know your show and debug commands and you're on your way to passing the CCNA!
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 Certification Exam: Five Frame Relay Details You Must Know
When you're studying for your CCNA exam on the way to earning this coveted Cisco certification, the details can seem overwhelming! In this article, I'll point out five Frame Relay details that you must keep in mind when you're on your way to the CCNA exam!
Inverse ARP starts working as soon as you open the serial interface. This protocol performs dynamic Frame Relay mapping, but you don't have to enable it - it's already enabled as soon as you enter the command "encapsulation frame-relay".
When you're configuring Frame Relay map statements manually, remember that you're mapping the local DLCI to the remote IP address.
When you run "show frame map", the word "dynamic" indicates mappings created by Inverse ARP, and "static" indicates it was manually created.
To spot possible LMI type mismatches, run "show frame lmi". A large number of Status Timeouts indicates that there may be an LMI problem between your router and the frame relay switch.
This last one is for the many of you building CCNA home labs. A frame relay switch is a great addition to your lab! While you're busy putting the configuration together, don't forget the global command "frame-relay switching" - it's this command that allows a Cisco router to act as a frame relay switch!
Inverse ARP starts working as soon as you open the serial interface. This protocol performs dynamic Frame Relay mapping, but you don't have to enable it - it's already enabled as soon as you enter the command "encapsulation frame-relay".
When you're configuring Frame Relay map statements manually, remember that you're mapping the local DLCI to the remote IP address.
When you run "show frame map", the word "dynamic" indicates mappings created by Inverse ARP, and "static" indicates it was manually created.
To spot possible LMI type mismatches, run "show frame lmi". A large number of Status Timeouts indicates that there may be an LMI problem between your router and the frame relay switch.
This last one is for the many of you building CCNA home labs. A frame relay switch is a great addition to your lab! While you're busy putting the configuration together, don't forget the global command "frame-relay switching" - it's this command that allows a Cisco router to act as a frame relay switch!
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!
Subscribe to:
Posts (Atom)
