In this post, we will examine the steps required to ensure full reachability over a Serial interface between two Cisco routers. Here is the network diagram that presents the topology used in this scenario:

Network Diagram

When we are in a lab environment, we can simulate a wide area connection (WAN) between two routers using a simple crossover cable designed for our router interfaces. One end of the cable is the DTE (Data Terminal Equipment), and the other is the DCE (Data Circuit-terminating Equipment). The DTE end synchronizes the connection to the clock rate of the link that is provided by the DCE. Notice that C does not stand for Clock in DCE, but it is a nice way to remember what that function does! Think of the clock on the line like a metronome, setting the “tempo” of communications.

For our first task, we want to determine which router has the DCE connection. We will use the show controllers serial 0/0 command to do this.

R2#show controllers serial 0/0
Interface Serial0/0
Hardware is GT96K
DCE 530, clock rate 2000000
idb at 0x652EE7AC, driver data structure at 0x652F5ED0
wic_info 0x652F64D4
Physical Port 1, SCC Num 1
MPSC Registers:

The R2 device has the DCE end connected as we can see in the output from this command. Notice there is a bunch of output from this command we do not need, so I omitted it here in the blog.

Now that we know which interface is which, we are ready to begin configurations. I will start right here on R2 for convenience. Because it is the DCE interface, I will set the clock rate, the bandwidth for the interface, and set the IP address. I want to use PPP (Point-to-Point Protocol), often jokingly called the Planet’s Most Popular Protocol, so I will set that on the interface as well. The default protocol for a Serial link in Cisco networking is Cisco’s version of HDLC (High-Level Data Link Control). Finally, I will enable the interface with the no shutdown command.

Please note that the bandwidth command is not actually setting the bandwidth, it is responsible for “reporting” the bandwidth to processes like routing protocols.

R2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#interface serial0/0
R2(config-if)#clock rate 64000
R2(config-if)#bandwidth 64
R2(config-if)#ip address
R2(config-if)#encapsulation ppp
R2(config-if)#no shutdown
*Mar  1 02:20:51.291: %LINK-3-UPDOWN: Interface Serial0/0, changed state to up
*Mar  1 02:20:51.615: %SYS-5-CONFIG_I: Configured from console by console

Notice when I set the clock rate I set a real slow speed (64 Kbps). This is to ensure that the interfaces can easily support it in my lab environment. You should also notice the status message received after the configuration. The interface has come up at Layer 1, but has no chance to come up at Layer 2, as we are sure to have an encapsulation mismatch with the other end of the link (running the default HDLC).

Now it is time to configure R1. Notice it is very nearly a mirror of the configuration, the only difference is the IP address and the lack of the clock rate command.

Also, notice the verification steps. We see Layer 1 and Layer 2 come up, and we can ping the far side link IP address.

R1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#interface serial 0/0
R1(config-if)#bandwidth 64
R1(config-if)#ip address
R1(config-if)#encapsulation ppp
R1(config-if)#no shutdown
*Mar  1 02:22:26.343: %LINK-3-UPDOWN: Interface Serial0/0, changed state to up
*Mar  1 02:22:27.031: %SYS-5-CONFIG_I: Configured from console by console
*Mar  1 02:22:27.375: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to up
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/8/20 ms

Thanks for reading and enjoy your studies!

You can leave a response, or trackback from your own site.

12 Responses to “CCENT Basic Serial Interface Connectivity”

  1. Deepak Arora says:

    Hi Guys,

    I am big fan of you and your IE workbooks and COD for routing and switching labs. Can you please help me with following query:

    Why we cannot ping our own serial interface ip address until we put ip address on other serial interface to which we are connected to through back to back dce/dte cable. I know serial interfaces don’t have mac addresses, maybe some sort of layer 3 to layer 2 resolution issue which comes. Also when we ping our own serial interface ip address the response time is double as compare to ping the other connected serial interface ip address so that means request first go to other interface and then comes back, why does it happen so. My question might look stupid and I am really interested to know this stuff.

    Kindly help me understanding this

    Deepak Arora

  2. Rack00 says:


    Sorry to interject here, I know the question was posed to IEX, but my question to you would be a simple one. Have you tried doing a debug ip packet detail or a debug ip icmp to see why you cannot ping yourself till the far end is configured? You mentioned resolution from L3->L2, so I wonder what result you will yield if you try those simple debugs – see what happens when you do that ping.

    Just a thought.


  3. Deepak says:


    Here is the output of debug ip pack when I put on serial of R1 and tried to ping myself. On r2 (point to point link) I just run no shtdown on serial and didn’t put any ip address.


    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:

    *Mar 1 00:05:05.067: IP: tableid=0, s= (local), d= (Serial0/0), r
    outed via RIB
    *Mar 1 00:05:05.067: IP: s= (local), d= (Serial0/0), len 100, sen
    *Mar 1 00:05:07.067: IP: tableid=0, s= (local), d= (Serial0/0), r
    outed via RIB
    *Mar 1 00:05:07.067: IP: s= (local), d= (Serial0/0), len 100, sen
    *Mar 1 00:05:09.067: IP: tableid=0, s= (local), d= (Serial0/0), r
    outed via RIB
    *Mar 1 00:05:09.067: IP: s= (local), d= (Serial0/0), len 100, sen
    *Mar 1 00:05:11.067: IP: tableid=0, s= (local), d= (Serial0/0), r

  4. Deepak says:

    After that I configured R2 with Ip add and again tried to ping myself sitting on R1 and this time following output appeared in debug.


    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
    Success rate is 100 percent (5/5), round-trip min/avg/max = 72/111/244
    *Mar 1 00:21:00.463: ICMP: bogus redirect from – for u
    *Mar 1 00:21:00.463: gateway address is one of our addresses
    *Mar 1 00:21:00.467: ICMP: echo reply sent, src, dst
    *Mar 1 00:21:00.535: ICMP: echo reply rcvd, src, dst
    *Mar 1 00:21:00.583: ICMP: echo reply sent, src, dst
    *Mar 1 00:21:00.607: ICMP: echo reply rcvd, src, dst
    *Mar 1 00:21:00.655: ICMP: echo reply sent, src, dst
    *Mar 1 00:21:00.679: ICMP: echo reply rcvd, src, dst
    *Mar 1 00:21:00.727: ICMP: echo reply sent, src, dst
    *Mar 1 00:21:00.775: ICMP: echo reply rcvd, src, dst
    *Mar 1 00:21:00.823: ICMP: echo reply sent, src, dst
    *Mar 1 00:21:00.847: ICMP: echo reply rcvd, src, dst

  5. Hi Deepak!

    What you are experiencing is normal behavior for testing a Serial interface.

    This behavior is because of how the link loops back. Let’s say you have a T1 end to end, and you’re trying to troubleshoot a circuit problem. The provider can loop the circuit back at different points. The shortest loopback is the local loop, or last mile, it means the CE (Customer Edge) to PE (Provider Edge), so when you test the “loopback”, the easiest way is with a ping. If you ping your own IP address and the link is looped back at the local loop, a response indicates the local loop is good! A provider will then move the loopback further and further out to isolate the link failure.

    So in this back to back lab config – we are actually sending the ping to the remote end which loops it back. Without an IP address on the remote end – the TCP/IP stack is not there to perform the function.

    Thanks for reading our blog and participating in this site!

  6. Deepak Arora says:


    Thanks for your help.

    Just a quick question – I am just wondering why the link loops back when pinging its own ip address. I mean even if router knows that the IP belongs to it’s own interface (connected subnet) then why it sends that echo request to other end. Why this behavior is even there.

    Let me take an example – Say R1 is connected to R2 with back to back DCE/DTE cable (P2P). On R1′s serial 0 I assign an ip address and run no shut later. On R2 serial interface Interface now which is connected to R1, I just run no shut command without assigning Ip address.

    Now I hop back to R1 and try to ping ; Now why R1 sends this ICMP echo to R2 and also how does this behavior gets changed when I assign Ip address on R2′s Serial interface.

    Can you please elaborate this thing with an example.

    :-) Just curious to know how resolution L3/L2 happens in this case.

    Thanks in advance and off-course thanks for spending time on my query.

  7. I think this article will help you understand the loopback behavior of serial interface testing.

    What is happening in your back to back lab environment is the automatic looping of traffic out the interface to the other side. If you do not have TCP/IP configured on the remote link – the loopback test fails.

  8. Divya says:


    If i will create 3 subinterfaces then how the bandwith allocation will take place there?

    can i assign more bandwidth to 1 subinterface and remain bandwidth can be allocated to other 2 interfaces equally?

  9. Check out our forum This is the perfect place to post questions like these. You will get even more help that I am providing below.

    Remember that when you use the bandwidth command, you are not actually controlling the bandwidth used by the interface, you are reporting the bandwidth with the command to things like routing protocols and Quality of Service mechanisms.

  10. Mustafa says:

    It might be a little late answer but here it is any way!

    The router looks up the routing table to find out that this subnet is connected to interface s0/0.
    When it comes to L2 to L3 resolution for a point to point interface, the router just use the remote L2 address associate with the outgoing interface, regardless the remote IP, as there is only one device connected to this interface (Remember it is point to point).

    By the time the packet reach the other end of the circuit, the remote router will look up the IP, encapsulate (L2 address) and send it back – so far we are talking about the Echo message.
    Echo reply go the other way arround.

    so it is like R1 —–> R2 —–> R1 echo,
    then R1 —–> R2 —–> R1 Echo reply,

    Then the ping is successful!

    Hope this helps.

  11. faisu says:

    i am ccna,ccnp(doing)holder,i am installed packet trace from cisco; configured routers( R1= & R2 is routing protocol- EIGRP) and working fine…but if i configure two routers are as two different ip (R1 & R2 routing protocol -EIGRP) but never communicate between routers ; can’t ping with two..
    what is the problem…may i want to configure anything more to adding routing than same ip range routing configurations ?



Leave a Reply


CCIE Bloggers