Computer Certification

To earn your Cisco CCNA and CCNP certifications
you've got to master ISDN - and despite what some people say
there's still a lot of ISDN out there that needs to be supported. And when it comes to troubleshooting ISDN
there's a lot to look at. Is the correct ISDN switchtype configured? Are the dialer map statements correct? What about the dialer-group and dialer-list commands? And that's just the start.

I always say that all troubleshooting starts at Layer 1
the Physical layer of the OSI model. The usual method of troubleshooting ISDN is sending pings across the link
but the connection can be tested without using pings or even before assigning IP addresses to the BRI interfaces!

It's a good idea to place these test calls before configuring the interfaces - that way
you know you've got a valid connection before beginning the configuration (and there's a lot of config to go along with ISDN!)

To place a test call without using pings
use the isdn call interface command.

R1#isdn call interface bri0 8358662

R1#

03:54:43: BR0 DDR: Attempting to dial 8358662

03:54:43: %LINK-3-UPDOWN: Interface BRI0:1
changed state to up

03:54:44: BR0:1 DDR: dialer protocol up

03:54:45: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1
changed state to up

03:54:49: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8358662 R2

To tear the test call down correctly
use isdn disconnect interface. IOS Help displays the options with this command.

R1#isdn disconnect interface bri 0 ?

all Disconnect the data call(s) on all b channels

b1 Disconnect the data call on b1 channel

b2 Disconnect the data call on b2 channel

R1#isdn disconnect interface bri 0 all

03:58:36: BR0:1 DDR: disconnecting call

03:58:36: BR0:2 DDR: disconnecting call

03:58:36: %ISDN-6-DISCONNECT: Interface BRI0:1 disconnected from 8358662
R2
call lasted 20 seconds

03:58:36: %LINK-3-UPDOWN: Interface BRI0:1
changed state to down

03:58:36: BR0:1 DDR: disconnecting call

03:58:37: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1
changed state to down

I say "correctly" because the one thing you don't want to do to end an ISDN call
test or otherwise
is just shut the interface. Telcos don't like it
and ISDN lab devices like it even less. Always let the d-channel do its work and tear the call down in an orderly fashion - don't just cut it off by shutting the interface down.

To earn your Cisco CCNA and CCNP certifications
you've got to master ISDN - and despite what some people say
there's still a lot of ISDN out there that needs to be supported. And when it comes to troubleshooting ISDN
there's a lot to look at. Is the correct ISDN switchtype configured? Are the dialer map statements correct? What about the dialer-group and dialer-list commands? And that's just the start.

I always say that all troubleshooting starts at Layer 1
the Physical layer of the OSI model. The usual method of troubleshooting ISDN is sending pings across the link
but the connection can be tested without using pings or even before assigning IP addresses to the BRI interfaces!

It's a good idea to place these test calls before configuring the interfaces - that way
you know you've got a valid connection before beginning the configuration (and there's a lot of config to go along with ISDN!)

To place a test call without using pings
use the isdn call interface command.

R1#isdn call interface bri0 8358662

R1#

03:54:43: BR0 DDR: Attempting to dial 8358662

03:54:43: %LINK-3-UPDOWN: Interface BRI0:1
changed state to up

03:54:44: BR0:1 DDR: dialer protocol up

03:54:45: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1
changed state to up

03:54:49: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8358662 R2

To tear the test call down correctly
use isdn disconnect interface. IOS Help displays the options with this command.

R1#isdn disconnect interface bri 0 ?

all Disconnect the data call(s) on all b channels

b1 Disconnect the data call on b1 channel

b2 Disconnect the data call on b2 channel

R1#isdn disconnect interface bri 0 all

03:58:36: BR0:1 DDR: disconnecting call

03:58:36: BR0:2 DDR: disconnecting call

03:58:36: %ISDN-6-DISCONNECT: Interface BRI0:1 disconnected from 8358662
R2
call lasted 20 seconds

03:58:36: %LINK-3-UPDOWN: Interface BRI0:1
changed state to down

03:58:36: BR0:1 DDR: disconnecting call

03:58:37: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1
changed state to down

I say "correctly" because the one thing you don't want to do to end an ISDN call
test or otherwise
is just shut the interface. Telcos don't like it
and ISDN lab devices like it even less. Always let the d-channel do its work and tear the call down in an orderly fashion - don't just cut it off by shutting the interface down.

One of the first things you learned about Frame is that the LMI also serves as a keepalive
or a heartbeat - and if three consecutive LMIs are missed
the line protocol goes down. There's a limitation to LMI as a keepalive
though. The LMI is exchanged only between the DTE and the closest DCE. The LMI is therefore a local keepalive that does not reflect any possible issues on the remote end of the virtual circuit.

Taking the LMI concept to the next logical level
Frame Relay End-To-End Keepalives (FREEK
one of the least-heard Cisco acronyms for some reason) are used to verify that endpoint-to-endpoint communications are functioning properly.

What you have to keep in mind about FREEK is that each and every PVC needs two separate keepalive processes. Remember
with a PVC
there's no guarantee that the path taking through the frame relay cloud to get from R1 to R2 is going to be the same path taken to go back from R2 to R1. One process will be used to send requests for information and handle the responses to these requests; this is the send side. When the send side transmits a keepalive request
a response is expected in a certain number of seconds. If one is not received
an error event is noted. If enough error events are recorded
the VC's keepalive status is marked as down.

The process that responds to the other side's requests is the receive side.

This being Cisco
we've got to have some modes
right? FREEK has four operational modes.

Bidirectional mode enables both the send and receive process enabled on the router
meaning that the router will send requests and process responses (send side) and will also respond to remote requests for information (receive side).

Request mode enables only the send process. The router will send requests and process responses to those requests
but will not answer requests from other routers.

Reply mode enables only the receive process. The router will respond to requests from other routers but will initiate no requests of its own.

Finally
passive reply mode allows the router to respond to requests
but no timers are set and no events are tracked.

Frame Relay End-To-End Keepalive defaults:

Two send or receive errors must be registered in order for the VC to be considered down.

The event window size is three. The event window is the number of events considered by the router when determining the status of the VC. Therefore
using the defaults
two send or receive errors would have to be received within the event window of three events for the VC to be considered down.

The timer mentioned earlier - the amount of time a router waits for a response - is set to 10 seconds

Working with Frame Relay end-to-end keepalives is just one Frame skill you’ll need to pass the CCNP exams – and I wouldn’t be surprised to see them on a CCIE exam. Know the details and you’re on your way to Cisco certification exam success!

You may run into situations where a router in a remote location needs to dial in to a central router
but the toll charges are much higher if the remote router makes the call. This scenario is perfect for PPP Callback
where the callback client places a call to a callback server
authentication takes place
and the server then hangs up on the client! This ensures that the client isn't charged for the call. The server then calls the client back.


In the following example
R2 has been configured as the client and R1 is the callback server. Let's look at both configurations and the unique commands PPP Callback requires.

Client:

username R1 password CCIE

interface BRI0

ip address 172.12.12.2 255.255.255.0

encapsulation ppp

dialer map ip 172.12.12.1 name R1 broadcast 5557777

dialer-group 1

isdn switch-type basic-ni

ppp callback request

ppp authentication chap

Most of that configuration will look familiar to you
but the ppp callback request command might not. This command enables the BRI interface to request the callback.

Simple enough
right? The PPP Callback Server config requires more configuration and an additional map-class as well.

Server:

username R2 password CCIE
interface BRI0

ip address 172.12.12.1 255.255.255.0

encapsulation ppp

dialer callback-secure

dialer map ip 172.12.12.2 name R2 class CALL_R2_BACK broadcast 5558888

dialer-group 1

isdn switch-type basic-ni

ppp callback accept

ppp authentication chap

map-class dialer CALL_R2_BACK

dialer callback-server username


Examining the PPP Callback Server command from the top down...


dialer callback-secure enables security on the callback. If the remote router cannot be authenticated for callback
the incoming call will be disconnected.


The dialer map statement now calls the class CALL_R2_BACK
shown at the bottom of the config excerpt.


ppp callback accept enables PPP callback on this router.


dialer callback-server username tells the callback server that the device referenced in the dialer map statement is a callback client.


The only way to find out if the config works is to test it
so let's send a ping from R2 to R1 and see if the callback takes place.


R2#ping 172.12.12.1


Type escape sequence to abort.

Sending 5
100
ICMP Echos to 172.12.12.1
timeout is 2 seconds:

02:45:42: BR0 DDR: Dialing cause ip (s=172.12.12.2
d=172.12.12.1)

02:45:42: BR0 DDR: Attempting to dial 5557777

02:45:42: %LINK-3-UPDOWN: Interface BRI0:1
changed state to up

02:45:42: BR0:1 DDR: Callback negotiated - Disconnecting now

02:45:42: BR0:1 DDR: disconnecting call

02:45:42: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 5557777 R1

02:45:42: %LINK-3-UPDOWN: Interface BRI0:1
changed state to down

02:45:42: DDR: Callback client for R1 5557777 created

02:45:42: BR0:1 DDR: disconnecting call.....

Success rate is 0 percent (0/5)

R2#

02:45:57: %LINK-3-UPDOWN: Interface BRI0:1
changed state to up

R2#

02:45:57: BR0:1 DDR: Callback received from R1 5557777

02:45:57: DDR: Freeing callback to R1 5557777

02:45:57: BR0:1 DDR: dialer protocol up

02:45:58: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1
changed state to up

The callback was successfully negotiated
and the call then disconnected. R1 then called R2 back
and show dialer on R1 confirms the purpose of the call.

R1#show dialer

BRI0 - dialer type = ISDN

Dial String Successes Failures Last DNIS Last status

5558888 2 4 00:00:20 successful

0 incoming call(s) have been screened.

0 incoming call(s) rejected for callback.

BRI0:1 - dialer type = ISDN

Idle timer (120 secs)
Fast idle timer (20 secs)

Wait for carrier (30 secs)
Re-enable (15 secs)

Dialer state is data link layer up

Dial reason: Callback return call

Time until disconnect 99 secs

Connected to 5558888 (R2)

Pretty cool! PPP Callback isn’t just important for passing your CCNA and CCNP exams – in circumstances such as shown in this example
it can save your organization quite a bit of money!

ISDN is a huge topic on both your Cisco CCNA and BCRAN CCNP exams. While many ISDN topics seem straightforward
it’s the details that make the difference in the exam room and working with ISDN in production networks. Configuring and troubleshooting multilink PPP is just one of the skills you’ll need to pass both of these demanding exams.

With BRI
we've got two B-channels to carry data
and both of them have a 64-kbps capacity. You might think it would be a good idea to have both channels in operation before one reaches capacity
and it is a great idea Problem is
it's not a default behavior of ISDN. The second b-channel will not begin to carry traffic until the first one reaches capacity.

With Multilink PPP (MLP)
a bandwidth capacity can be set that will allow the second b-channel to bear data before the first channel reaches capacity. The configuration for MLP is simple
but often misconfigured. We'll use our good friend IOS Help to verify the measurement this command uses.

Enabling MLP is a three-step process:

Enable PPP on the link

Enable MLP with the command ppp multilink

Define the threshold at which the second b-channel should start carrying data with the dialer load-threshold command.

Let's say you wanted the second b-channel to start carrying data when the first channel reaches 75% of capacity. It would make sense that the command to do so would be dialer load-threshold 75... but it's not.

R1(config)#int bri0

R1(config-if)#ppp multilink

R1(config-if)#dialer load-threshold ?

<1-255> Load threshold to place another call

The dialer load-threshold value is based on 255
not 100. To have this command bring the line up at a certain percentage
multiply that percentage in decimal format by 255. Below
I multiplied 255 by .75 (75%) to arrive at 191.

R1(config-if)#dialer load-threshold 191 ?

either Threshold decision based on max of inbound and outbound traffic

inbound Threshold decision based on inbound traffic only

outbound Threshold decision based on outbound traffic only



R1(config-if)#dialer load-threshold 191 either

As illustrated by IOS Help in the above configuration
dialer load-threshold has additional options as well. You can configure the interface to consider only incoming
outgoing
or all traffic when calculating when to bring the next channel up.

Configuring Multilink PPP is just one of the skills you’ll need to earn your CCNA and pass the CCNP BCRAN exam. Don’t underestimate ISDN on Cisco’s certification exams!

To earn your Cisco CCNA certification and pass the BSCI CCNP exam
you have to know your protocol basics like the back of your hand! To help you review these important concepts
here's a quick look at the basics of RIPv1
RIPv2
IGRP
and EIGRP.

RIPv1: Broadcasts updates every 30 seconds to the address 255.255.255.255. RIPv1 is a classful protocol
and it does not recognize VLSM
nor does it carry subnet masking information in its routing updates. Update contains entire RIP routing table. Uses Bellman-Ford algorithm. Allows equal-cost load-balancing by default. Max hop count is 15. Does not support clear-text or MD5 authentication of routing updates. Updates carry 25 routes maximum.

RIPv2: Multicasts updates every 30 seconds to the address 224.0.0.9. RIPv2 is a classless protocol
allowing the use of subnet masks. Update contains entire RIP routing table. Uses Bellman-Ford algorithm. Allows equal-cost load-balancing by default. Max hop count is 15. Supports clear-text and MD5 authentication of routing updates. Updates carry 25 routes maximum.

IGRP: Broadcasts updates every 90 seconds to the address 255.255.255.255. IGRP is a Cisco-proprietary protocol
and is also a classful protocol and does not recognize subnet masking. Update contains entire routing table. Uses Bellman-Ford algorithm. Equal-cost load-balancing on by default; unequal-cost load-sharing can be used with the variance command. Max hop count is 100.

EIGRP: Multicasts full routing table only when an adjacency is first formed. Multicasts updates only when there is a change in the network topology
and then only advertises the change. Multicasts to 224.0.0.10 and allows the use of subnet masks. Uses DUAL routing algorithm. Unequal-cost load-sharing available with the variance command.

By mastering the basics of these protocols
you're laying the foundation for success in the exam room and when working on production networks. Pay attention to the details and the payoff is "CCNA" and "CCNP" behind your name!

Earning your Cisco CCNA and CCNP is a tough proposition
and part of that is the fact that you quickly learn that there’s usually more than one way to do things with Cisco routers – and while that’s generally a good thing
you better know the ins and outs of all options when it comes to test day and working on production networks. Working with Frame Relay subinterfaces and split horizon is just one such situation.

One reason for the use of subinterfaces is to circumvent the rule of split horizon. You recall from your CCNA studies that split horizon dictates that a route cannot be advertised out the same interface upon which it was learned in the first place. In the following example
R1 is the hub and R2 and R3 are the spokes. All three routers are using their physical interfaces for frame relay connectivity
and they are also running RIPv2 172.12.123.0 /24. Each router is also advertising a loopback interface
using the router number for each octet.

R1(config)#int s0

R1(config-if)#ip address 172.12.123.1 255.255.255.0

R1(config-if)#no frame inverse

R1(config-if)#frame map ip 172.12.123.2 122 broadcast

R1(config-if)#frame map ip 172.12.123.3 123 broadcast

R1(config-if)#no shut

R2(config)#int s0

R2(config-if)#encap frame

R2(config-if)#no frame inver

R2(config-if)#frame map ip 172.12.123.1 221 broadcast

R2(config-if)#frame map ip 172.12.123.3 221 broadcast

R2(config-if)#ip address 172.12.123.2 255.255.255.0

R3(config)#int s0

R3(config-if)#encap frame

R3(config-if)#no frame inver

R3(config-if)#frame map ip 172.12.123.1 321 broadcast

R3(config-if)#frame map ip 172.12.123.2 321 broadcast

R3(config-if)#ip address 172.12.123.3 255.255.255.0


R1#show ip route rip

2.0.0.0/32 is subnetted
1
subnets

R 2.2.2.2 [120/1] via 172.12.123.2
0
Serial0

3.0.0.0/32 is subnetted
1
subnets

R 3.3.3.3 [120/1] via 172.12.123.3
0
Serial0

R2#show ip route rip

1.0.0.0/32 is subnetted
1
subnets

R 1.1.1.1 [120/1] via 172.12.123.1
0
Serial0

R3#show ip route rip

1.0.0.0/32 is subnetted
1
subnets

R 1.1.1.1 [120/1] via 172.12.123.1
0
Serial0

The hub router R1 has a route to both loopbacks
but neither spoke has a route to the other spoke's loopback. That's because split horizon prevents R1 from advertising a network via Serial0 if the route was learned on Serial0 to begin with.

We've got two options here
one of which is to disable spilt horizon on the interface. While doing so will have the desired effect in our little network
disabling split horizon is not a good idea and should be avoided whenever possible. We’re not going to do it in this lab
but here is the syntax to do so:

R1(config)#interface serial0

R1(config-if)#no ip split-horizon

A better solution is to configure subinterfaces on R1. The IP addressing will have to be revisited
but that's no problem here. R1 and R2 will use 172.12.123.0 /24 to communicate
while R1 and R3 will use 172.12.13.0 /24. R3's serial0 interface will need to be renumbered
so let's look at all three router configurations:

R1(config)#interface serial0

R1(config-if)#encap frame

R1(config-if)#no frame inverse-arp

R1(config-if)#no ip address


R1(config-if)#interface serial0.12 multipoint

R1(config-subif)#ip address 172.12.123.1 255.255.255.0

R1(config-subif)#frame map ip 172.12.123.2 122 broadcast


R1(config-subif)#interface serial0.31 point-to-point

R1(config-subif)#ip address 172.12.13.1 255.255.255.0

R1(config-subif)#frame interface-dlci 123


R2(config)#int s0

R2(config-if)#ip address 172.12.123.2 255.255.255.0

R2(config-if)#encap frame

R2(config-if)#frame map ip 172.12.13.3 221 broadcast

R2(config-if)#frame map ip 172.12.123.1 221 broadcast

R3(config)#int s0

R3(config-if)#ip address 172.12.13.3 255.255.255.0

R3(config-if)#encap frame

R3(config-if)#frame map ip 172.12.13.1 321 broadcast

R3(config-if)#frame map ip 172.12.123.2 321 broadcast

A frame map statement always names the REMOTE IP address and the LOCAL DLCI. Don't forget the broadcast option!

Show frame map shows us that all the static mappings on R1 are up and running. Note the "static" output
which indicates these mappings are a result of using the frame map command. Pings are not shown
but all three routers can ping each other at this point.

R1#show frame map

Serial0 (up): ip 172.12.123.2 dlci 122(0x7A
0
static


broadcast
CISCO
status defined
active

Serial0 (up): ip 172.12.13.3 dlci 123(0x7B
0
static


broadcast
CISCO
status defined
active

After the 172.12.13.0 /24 network is added to R1 and R3’s RIP configuration
R2 and R3 now have each other's loopback network in their RIP routing tables.

R2#show ip route rip

1.0.0.0/32 is subnetted
1
subnets

R 1.1.1.1 [120/1] via 172.12.123.1
0
Serial0


3.0.0.0/32 is subnetted
1
subnets

R 3.3.3.3 [120/1] via 172.12.123.1
0
Serial0

R3#show ip route rip

1.0.0.0/32 is subnetted
1
subnets

R 1.1.1.1 [120/1] via 172.12.13.1
0
Serial0

2.0.0.0/32 is subnetted
1
subnets

R 2.2.2.2 [120/1] via 172.12.13.1
0
Serial0

While turning split horizon off is one way to achieve total IP connectivity
doing so can have other unintended results. The use of subinterfaces is a more effective way of allowing the spokes to see the hub's loopback network.

BECNs and FECNs aren't just important to know for your Cisco CCNA and CCNP certification exams - they're an important part of detecting congestion on a Frame Relay network and allowing the network to dynamically adjust its transmission rate when congestion is encountered.

The Forward Explicit Congestion Notification (FECN
pronounced "feckon") bit is set to zero by default
and will be set to 1 if congestion was experienced by the frame in the direction in which the frame was traveling. A DCE (frame relay switch) will set this bit
and a DTE (router) will receive it
and see that congestion was encountered along the frame's path.

If network congestion exists in the opposite direction in which the frame was traveling
the Backward Explicit Congestion Notification (BECN
pronounced "beckon") will be set to 1 by a DCE.

If this is your first time working with BECNs and FECNs
you might wonder why the BECN even exists - after all
why send a "backwards" notification? The BECN is actually the most important part of this entire process
since it's the BECN bit that indicates to the sender that it needs to slow down!

For example
frames sent from Kansas City to Green Bay encounter congestion in the FR cloud. A Frame Switch sets the FECN bit to 1. In order to alert KC that it's sending data too fast
GB will send return frames with the BECN bit set. When KC sees the BECN bit is set to 1
the KC router knows that the congestion occurred when frames were sent from KC to GB.

Frame Relay BECN Adaptive Shaping allows a router to dynamically throttle back on its transmission rate if it receives frames from the remote host with the BECN bit set. In this case
KC sees that the traffic it's sending to GB is encountering congestion
because the traffic coming back from GB has the BECN bit set. If BECN Adaptive Shaping is running on KC
that router will adjust to this congestion by slowing its transmission rate. When the BECNs stop coming in from GB
KC will begin to send at a faster rate.

BECN Adaptive Shaping is configured as follows:

KC(config)#int s0

KC(config-if)#frame-relay adaptive-shaping becn

To see how many frames are coming in and going out with the BECN and FECN bits set
run show frame pvc.

R3#show frame pvc

<>

input pkts 306 output pkts 609 in bytes 45566

out bytes 79364 dropped pkts 0 in FECN pkts 0

in BECN pkts 0 out FECN pkts 0 out BECN pkts 0

in DE pkts 0 out DE pkts 0

out bcast pkts 568 out bcast bytes 75128

pvc create time 01:26:27
last time pvc status changed 01:26:27

Just watch the "in"s and "out"s of BECN
FECN
and DE in both the exam room and your production networks!

Whether you're just starting to think about passing the CCNA or CCNP exams
or you've been on the certification track for a while
you've got to have a plan for success. If you wanted to drive your car from Florida to California
you'd create a plan to get there. You'd get a map and decide how far you wanted to drive per day
and maybe even make some hotel reservations in advance. You certainly wouldn't get in your car
just drive it randomly down the nearest highway
and hope you ended up in California
would you?

Certainly not. Earning your CCNA certification is the same way. It's not enough to just study a few minutes "when you feel like it"
or tell yourself that you'll start studying for the exams "when I get such-and-such done". The perfect time to start on the road to Cisco certification is not tomorrow
and it's not next week. It's today.

You're much better off with one hour of solid study than three hours of interrupted
unfocused study. Here are a few ways to go about getting the kind of quality study time that will get you to the CCNA or CCNP (or any Cisco certification
for that matter!).

Schedule your study time
and regard this study time as you would an appointment with a client. If you were to meet a customer at 10:00 to discuss a network install
would you just decide not to show up and watch television instead? Not if you wanted the job. The same goes for your study time. That's an appointment with the most important customer of all - YOU.

Turn your cell
iPod
TV
instant messenger
and all other electronic collars off for the duration of your study time. I know those of us in information technology don't like to say this
but we can actually exist without being in touch with the world for a little while. You may even get to like it! Having uninterrupted study time is key to CCNA and CCNP exam success.

Finally
schedule your exam before you start studying. Contrary to what many people think
deadline
is not a dirty word. We do our best work when we have a deadline and a schedule to keep. Make out your study schedule
schedule your exam
and get to work just as you would a network project for a customer. The project you're working on is your career and your life
and by following these simple steps you can make it a highly successful project - by passing your CCNA and CCNP exam!

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!