Configure and verify PPP
Exam: 300-101 - Implementing Cisco IP Routing (ROUTE v2.0)
In this chapter we will discuss in details about how to configure and verify the PPP. This is a topic that you will come across in the exam number 300-101 Route in CCNP. We will try to discuss almost all the aspects of the topic that maybe of importance from the exam point of view.
PPP stands for point to point protocol. The PPP can support two type of protocols and these are PAP (password authentication protocol) and the CHAP (challenge handshake authentication protocol).
Both these protocols are clearly specified in the RFC 1334. These two are supported by the synchronous and the asynchronous interfaces. The PPP is a data link protocol that can establish a direct connection between two nodes. The PPP is used in many types of physical networks. It can also be used in internet access connection.
The PPP has a three layered protocol. The first layer is basically an encapsulation component that transmits datagram over the physical layers. The second layer is used to establish and configure test links. The last layer consists of the NCP (network control protocol).
Authentication (PAP, CHAP)
The PAP provides a very simple method for the remote node to understand its identity by using a two way handshake. Once the PPP link establishment phase is completed a password and username is sent to the remote node to the link till the authentication is recognised. It can also go on till the connection is terminated.
However, you must keep in mind that PAP is not recognised as a secure authentication protocol. The passwords are sent as we have already discussed but there is absolutely no protection from the trial-and-error attacks. It is only the remote node that is in control of the timing as well as frequency of the login attempts made.
CHAP on the other hand is considered to be safer. This is because the user password will never be sent across in this connection.
PAP has its drawbacks but it is often used in the following situations:
- If there are incompatibilities between the different vendors who are implementing the CHAP.
- In a situation where the plaintext passwords must be accessible for stimulating a login at the remote host.
- If the client applications do not support the CHAP.
PAP supports for unidirectional and bi-directional authentication. When there is unidirectional authentication only the side that is receiving the call will authenticate the remote side. The remote client will not authenticate the server in this case.
When there is a bi-directional authentication then each of the sides will send authenticate requests and will therefore receive “the authenticate not acknowledge” or “authenticate acknowledge”. Using the debug ppp authentication command one can see these.
You can also use the ppp authentication pap command to configure PAP to understand the identity of the other side or the peer. The peer must present the password and the username to the local driver for verification in this case.
In some cases it is seen that two sides will not agree to the PAP as the authentication protocol. In these cases the two sides can also sometime agree on CHAP. In these cases the PAP connection will fail.
This can also be a username and a password problem. In this situation you must always verify that the calling side uses the command ppp pap sent- username. If there is a two way authentication you must verify that the receiving side uses the command ppp pap sent username username password. This can be used where the username and the password matches the one that was configured in the calling router.
CHAP is a one way authentication method but it can be used as a two way authentication too. If a two way CHAP is established it will automatically initiate a three way handshake in each side. It is necessary that in a CHAP implementation the called party authenticates the calling party. This may not be required if the authentication is switched off.
The calling party can also verify the identity of the called party and this may lead in two way authentication. If you are connecting to a non Cisco device then one way authentication must be used. You will have to use the command ppp authentication chap callin for this purpose on the calling router.
PPPoE (client side only)
PPPoE is the short form of point to point protocol over Ethernet. The PPPoE basically provides an optional point to point link across a shared medium. It provides supports to the clients on the routers. It is mostly used in DSL (digital subscriber lines).
It can provide support even to the servers. From the exam point of view you must be aware only of the PPPoE in the client side. If you want to create a PPPoE for thr client you must ensure that the client has ppp connections that must be set between two end points that are over a serial link or over a virtual circuit.
The PPPoE can also be used to obtain the IP address. It is simple to create a PPPoE in the client side. All that you need to do is to create a dialer interface that will take care of the interface that handles the PPPoE connection. Then tie this to the physical interface that will provide the transport. The ppp header will add upto 8 bytes of overhead to each frame. You can assume that the default Ethernet MTU is 1500 bytes you will have to lower your MTU to say about 1492 in order to ensure that there is no fragmentation. As the last step in the process you will have to assign the ISP facing interface to PPPoE dial group that was just created. At the end you must see the notification that clearly indicates that the PPPoE session was successfully created.
You must authenticate the PPPoE to ensure that the connection is being provided only to the customers that we trust and not to everyone. You can check this by using some low-layer authentication techniques. You must also ensure that the PPPoE sessions do come back after the authentication was completed. Using the debug ppp authentication command you can monitor the CHAP exchange.
The topic of PPP is actually vast but if you prepare on the lines that we have discussed in this chapter you will be able to get a fine score. We hope that this chapter will help you to prepare better for this topic for the CCNP exam.
Related IT Guides
- Configure and verify Cisco NetFlow
- Configure and Verify IP SLA
- Configure and verify IPv4 Network Address Translation (NAT)
- Configure And Verify Manual and Autosummarization With Any Routing Protocol
- Configure and Verify Network Time Protocol (NTP)
- Configure and verify static routing
- Configure And Verify VRF Lite
- Describe IP operations
- Recognize proposed changes to the network
- Troubleshoot passive interfaces