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.
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!
There are three ranges of 1918 Private Addresses, one in each major network class.
Class A: 10.0.0.0 /8
Class B: 172.16.0.0 /12
Class C: 192.168.0.0 /16
Be careful - these masks are not the classful network masks you're familiar with!
The need for private address ranges arose when we started running out of IP addresses. (A lot of us never thought that would happen, but a lot of us used to think we'd never need storage units bigger than floppy disks, too.) You can imagine that as networks began to be installed in offices and schools worldwide, the finite number of IP addresses became a restrictive factor.
Many devices that were using these precious IP addresses did not need to communicate with any device outside its own local area network (LAN). Therefore, these devices could be assigned an IP address that could be used on another device in another LAN - but these devices would not be able to communicate across the Internet.
It was decided to create network address ranges that would be used exclusively for such devices. That's why when you go from one local area network to another, you'll usually see hosts with IP addresses from the above three ranges.
Of course, as time went on, more and more of these devices did need to reach hosts across the Internet. That's where NAT - Network Address Translation - comes into play. But that is a subject for another tutorial!
Chris Bryant has sinced written about articles on various topics from CISCO CCNA, Personal Desktop and Cisco CCNP. Chris Bryant, CCIE #12933, is the owner of The Bryant Advantage , home of free and CCNP tutorials! Pass the. Chris Bryant's top article generates over 27100 views. to your Favourites.