Verifying PPP
Objectives:
- Configure and verify a basic WAN serial connection
- Configure and verify a PPP connection between Cisco routers
To ensure your PPP connection came up successfully, you can always use the ol’ faithful show ip interface brief command.
Pigeon#show ip interface brief Interface IP-Address OK? Method Status Protocol FastEthernet0 10.1.1.2 YES NVRAM up up Serial0 10.2.2.2 YES manual up up
In this case, all is well with the Serial 0 PPP connection between the routers because the Protocol is stated as up. Remember, the Status column generally dictates the Physical layer connectivity, whereas the Protocol column focuses on the Data Link connectivity. If you want to get a little more in depth with the PPP negotiation on the interface, issue the show interface <interface> command as follows:
Pigeon#show interface serial 0 Serial0 is up, line protocol is up Hardware is PowerQUICC Serial Internet address is 10.2.2.2/24 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation PPP, loopback not set Keepalive set (10 sec) LCP Open Open: IPCP, CCP, CDPCP Last input 00:00:51, output 00:00:01, output hang never Last clearing of “show interface” counters 05:07:30 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: weighted fair Output queue: 0/1000/64/0 (size/max total/threshold/drops) Conversations 0/1/256 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) Available Bandwidth 1158 kilobits/sec 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 4127 packets input, 168000 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 84 input errors, 0 CRC, 84 frame, 0 overrun, 0 ignored, 0 abort 8196 packets output, 404090 bytes, 0 underruns 0 output errors, 0 collisions, 163 interface resets 0 output buffer failures, 0 output buffers swapped out 326 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up
As you can see from the output above, the router has negotiated Link Control Protocol (LCP) options, which is indicated by the LCP Open state. If the LCP negotiations had failed (most likely because of an authentication problem), the LCP state would rotate between Listen, ACKSent, or TERMSent. This is the Cisco router trying to go through the negotiation of the LCP options.
In the line below LCP Open, you can verify all the Network layer communication occurring across the PPP link. In this case, you can see IPCP (indicates the TCP/IP protocol), CCP (Indicates compression is in effect—compressed control protocol [CCP]), and CDPCP (indicates the Cisco Discovery Protocol [CDP]). Technically, CDP is a Data Link protocol; however, Cisco adopted it to connect into the PPP options as a Layer 3 protocol.
EXAM ALERT
Be able to interpret the show interface command output as it relates to the PPP options. Finally, if you would like to see how your PPP compression is working out, you can type the command show compress. This gives you the compression statistics for the line:
Pigeon#show compress Serial0 Software compression enabled uncompressed bytes xmt/rcv 4215/4956 compressed bytes xmt/rcv 0/0 1 min avg ratio xmt/rcv 0.223/4.621 5 min avg ratio xmt/rcv 0.284/4.621 10 min avg ratio xmt/rcv 0.270/1.372 no bufs xmt 0 no bufs rcv 0 resyncs 0
In this case, you have no compressed bytes because all the traffic sent over the PPP link was generated by the routers themselves (this traffic is exempt from compression).
Troubleshooting PPP
Objectives:
- Configure and verify a basic WAN serial connection
- Configure and verify a PPP connection between Cisco routers
- Troubleshoot WAN implementation issues
Whenever you reach the troubleshooting section for any topic, you can be guaranteed some debug output. In this case, the debug commands for PPP are pretty darn useful: Most of the output is easy to understand. The most useful command that I have found to troubleshoot a PPP link is the debug ppp negotiation command. Check out this output:
Pigeon#debug ppp negotiation 1d02h: Se0 PPP: Using default call direction 1d02h: Se0 PPP: Treating connection as a dedicated line 1d02h: Se0 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load] 1d02h: Se0 LCP: O CONFREQ [Closed] id 157 len 15 1d02h: Se0 LCP: AuthProto CHAP (0x0305C22305) 1d02h: Se0 LCP: MagicNumber 0x0709760C (0x05060709760C) 1d02h: Se0 LCP: I CONFREQ [REQsent] id 208 len 15 1d02h: Se0 LCP: AuthProto CHAP (0x0305C22305) 1d02h: Se0 LCP: MagicNumber 0x22D5B7B3 (0x050622D5B7B3) 1d02h: Se0 LCP: O CONFACK [REQsent] id 208 len 15 1d02h: Se0 LCP: AuthProto CHAP (0x0305C22305) 1d02h: Se0 LCP: MagicNumber 0x22D5B7B3 (0x050622D5B7B3) 1d02h: Se0 LCP: TIMEout: State ACKsent 1d02h: Se0 LCP: O CONFREQ [ACKsent] id 158 len 15 1d02h: Se0 LCP: AuthProto CHAP (0x0305C22305) 1d02h: Se0 LCP: MagicNumber 0x0709760C (0x05060709760C) 1d02h: Se0 LCP: I CONFACK [ACKsent] id 158 len 15 1d02h: Se0 LCP: AuthProto CHAP (0x0305C22305) 1d02h: Se0 LCP: MagicNumber 0x0709760C (0x05060709760C) 1d02h: Se0 LCP: State is Open 1d02h: Se0 PPP: Phase is AUTHENTICATING, by both [0 sess, 1 load] 1d02h: Se0 CHAP: O CHALLENGE id 156 len 27 from “Pigeon” 1d02h: Se0 CHAP: I CHALLENGE id 2 len 26 from “Robin” 1d02h: Se0 CHAP: O RESPONSE id 2 len 27 from “Pigeon” 1d02h: Se0 CHAP: I RESPONSE id 156 len 26 from “Robin” 1d02h: Se0 CHAP: O SUCCESS id 156 len 4 1d02h: Se0 CHAP: I SUCCESS id 2 len 4 1d02h: Se0 PPP: Phase is UP [0 sess, 1 load] 1d02h: Se0 IPCP: O CONFREQ [Closed] id 4 len 10 1d02h: Se0 IPCP: Address 10.2.2.2 (0x03060A020202) 1d02h: Se0 CCP: O CONFREQ [Closed] id 4 len 6 1d02h: Se0 CCP: Predictor1 (0x0102) 1d02h: Se0 CDPCP: O CONFREQ [Closed] id 4 len 4 1d02h: Se0 IPCP: I CONFREQ [REQsent] id 5 len 10 1d02h: Se0 IPCP: Address 10.2.2.1 (0x03060A020201) 1d02h: Se0 IPCP: O CONFACK [REQsent] id 5 len 10 1d02h: Se0 IPCP: Address 10.2.2.1 (0x03060A020201) 1d02h: Se0 CCP: I CONFREQ [REQsent] id 2 len 6 1d02h: Se0 CCP: Predictor1 (0x0102) 1d02h: Se0 CCP: O CONFACK [REQsent] id 2 len 6 1d02h: Se0 CCP: Predictor1 (0x0102) 1d02h: Se0 CDPCP: I CONFREQ [REQsent] id 5 len 4 1d02h: Se0 CDPCP: O CONFACK [REQsent] id 5 len 4 1d02h: Se0 IPCP: I CONFACK [ACKsent] id 4 len 10 1d02h: Se0 IPCP: Address 10.2.2.2 (0x03060A020202) 1d02h: Se0 IPCP: State is Open 1d02h: Se0 CCP: I CONFACK [ACKsent] id 4 len 6 1d02h: Se0 CCP: Predictor1 (0x0102) 1d02h: Se0 CCP: State is Open 1d02h: Se0 CDPCP: I CONFACK [ACKsent] id 4 len 4 1d02h: Se0 CDPCP: State is Open 1d02h: Se0 IPCP: Install route to 10.2.2.1 1d02h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, 3changed state to up
Isn’t that some great stuff?!? Okay, it does take a little bit of screening through all the output, but if you look about halfway through, you can see the exchange of the Robin and Pigeon hostnames. This shows the challenge/response action of the CHAP protocol.
Thankfully, you can see a SUCCESS message to finish it off, showing the Pigeon and Robin routers have successfully authenticated each other. Near the bottom of the output, you see the CCP (compression negotiation) negotiate the Predictor algorithm between the two routers. Finally, at the end of the output, you see the link come up.
If your PPP connection is failing, this debug command will definitely show you the cause (as long as the failure is related to PPP). Another popular command is debug ppp authentication, which gives the same output, but slims it down to just the authentication information (because this is where many failures occur).