PPP 101
PPP is an open-standard, media-independent Layer 2 protocol that can provide such features as authentication, multilink, compression, reliability.
PPP uses 2 negotiation phases. First, LCP (Link Control Protocol) is used to set up the link and to negotiate authentication, compression mechanisms, available MTU size, and so on, and then there’s a NCP phase (Network Control Protocol) specific for each network layer protocol. There’s IPCP – for IPv4, IPv6CP – for IPv6 or CDPCP – for CDP (CDP is a actually a Layer 2 protocol that works over PPP)
For example, after LCP phase is over, the IPCP protocol will be used to exchange IP related information, like getting the IP address of the interface.
For back to back connections between 2 routers, the easiest way is to use PPP encapsulation on the physical interfaces connecting them:
R(config-if)# encapsulation ppp
R(config-if)# no shut
In other environments, you can define the server’s physical interface to use PPP encapsulation as above, and use a Dialer Interface on the client.
R(config)# interface DIALER-INT
R(config-if)# encapsulation ppp
! By default, dialer interfaces use HDLC encapsulation
R(config-if)# dialer-pool POOL-ID
The connection between the Dialer interface and physical interfaces is done via a Dialer Pool
PPP Dialer
To configure the physical interface to be a member of a Dialer Pool, use:
R(config)# interface SERIAL-INT
R(config)# encapsulation ppp
R(config)# dialer in-line
R(config-if)# dialer pool-memeber POOL-ID
From now on, all PPP configuration is done on the Dialer interface, which acts as a PPP Profile that is applied on the physical interfaces.
A Dial interfaces is activated whenever interesting traffic is sent over it. To define the interesting traffic you will have to configure the Dial interface to be part of a Dial Group.
R(config-if)# dialer-group DIALER-LIST
Then, the Dial Group will reference a Dial List, which will define interesting traffic. This configuration is done globally:
R(config)# dialer-list DIALER-LIST protocol PROTOCOL {list ACL|permit|deny}
! PROTOCOL - ip, ipv6, bridge, etc
! permit - will define all PROTOCOL traffic as interesting traffic
! deny - will remove all PROTOCOL traffic from the interesting traffic
! list ACL - will define interesting traffic based on ACL
Whenever there is interesting traffic to be sent over the Dial interface, it will generate a Dial Call.
You can configure the Dial interface to be always up if you use:
R(config-if)# dialer persistent
! To keep the interface up/up even if there is no interesting traffic
! This command will auto-generate:
R(config-if)# dialer idle-timeout 0
You can verify the status of a Dialer interface using:
R# show dialer
PPP uses keepalives to monitor the link state. By default, keepalives are sent and expected every 10 seconds. Unlike most protocols, five missed keepalives will move the interface protocol to a “down” status.
R(config-if)#keepalive ?
< 0-32767> Keepalive period (default 10 seconds)
< cr>
Hitting enter will set the default value of 10 seconds. To disable keepalives completly use:
R1(config-if)# no keepalive
To verify keepalives, use:
R1# show interface serial0/0 | i alive
Keepalive set (10 sec)
A PPP client can manually set its IP address with
R(config-if)# ip address IP-ADDR NETMASK [secondary]
But it can also use IPCP to discover the IP address it should use. To enable the use of IPCP for address assginement, use:
R(config-if)# ip address negotiated [previous]
If the previous keyword is used, then the client will attempt to get the previously assigned address from the server. The server can ignore this request if it uses:
R(config-if)# peer ip address forced
Addresses assigned using IPCP are always /32 addresses. Additional information may be requested by the client if it is explicitly configured:
R(config-if)# ppp ipcp dns request
R(config-if)# ppp ipcp mask request
! While this is not used by PPP, it may be used by other functions like DHCP ODAP
R(config-if)# ppp ipcp wins request
In order to reply to these requests, the server must be explicitly configured to send them. See next section.
When a PPP client requests its IP Address from the PPP Dial-in server, the latter will send by default an IP address from a local pool. This default mechanism can be overridden globally or on the interface,
Globally:
R(config)# ip address-pool {local|dhcp-pool|dhcp-proxy-client}
! local - Uses the default local pool (Default)
! dhcp-pool - Uses a local DHCP pool
! dhcp-proxy-client - Proxies the request to a DHCP server
Per interface:
R(config-if)# peer default ip address {CLIENT-IP | pool [IP-POOL]| dhcp-pool [DHCP-POOL] |dhcp}
! CLIENT-IP: assigns the configured address to clients on this interface
! pool [IP-POOL]: Sets a local-pool as default mechanism on this interface.
! dhcp-pool [DHCP-POOL]: Uses a local DHCP Pool as the default mechanism on this interface
! dhcp: Acts a a DHCP Proxy Client and forwards requests to a remote DHCP Server
To define a local IP-POOL, then use:
R(config)# ip local pool {IP-POOL|default} START-IP [END-IP] ...
To define a DHCP-POOL and enter DHCP Pool Configuration Mode, use:
R(config)# ip dhcp pool DHCP-POOL
For DHCP Proxy client, configure the remote DHCP Server, using:
R(config)# ip dhcp-server IP-ADDR
! Optionally, allow DNS and Netbios discovery:
R(config)# ip dhcp-client network-discovery informs INFORMS discovers DISCOVERS period SEC
There is a problem when using the DHCP client. The router will forward the request sourced from the PPP interface. The DHCP server will send the reply unicast to this address. But since the negotiation is not completed until the other side receives an address (or renounces after too many fails – which will be too late anyway), the interface will have an up/down status. This means that it won’t be advertised by routing protocols, so probably the DHCP server doesn’t have a route back to it. This can be resolved by using static routes on the path from the server to our router, or in a more dynamic way, by using a loopback address and setting the address on the PPP interface as unnumbered from that loopback. This will let the prefix to be advertised by routing protocols.
When an IPCP client requests additional information, the router has to explicitly define them with:
R(config-if)# ppp ipcp dns SERVER1 [SERVER2...]
R(config-if)# ppp ipcp netmask MASK
R(config-if)# ppp ipcp wins SERVER1 [SERVER2...]
When a PPP link is up, it will add a /32 route to that points to the IP address on the other end of the PPP link. This makes it possible for hosts with IP addresses in different subnets to be directly connected over a PPP link.
R2#sh ip route
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Serial1/1
2.0.0.0/24 is subnetted, 1 subnets
C 2.2.2.0 is directly connected, Serial1/1
This feature can be disabled using the command:
R2(config-if)# no peer neighbor-route
PPP can be configured to use a software compression algortithm. Compared to HDLC, PPP supports more compression algorithms and can be configured with different algorithms on each end. PPP LCP phase will take care of the negotiation.
To see the available compression algorithms use:
R(config-if)#compress ?
lzs lzs compression type
mppc MPPC compression type
predictor predictor compression type
stac stac compression algorithm
< cr>
To see compression statistics use:
R1#sh compress details
Serial1/3
Software compression enabled
uncompressed bytes xmt/rcv 15627/15729
compressed bytes xmt/rcv 3868/4258
Compressed bytes sent: 3868 bytes 0 Kbits/sec ratio: 4.040
Compressed bytes recv: 4258 bytes 0 Kbits/sec ratio: 3.693
1 min avg ratio xmt/rcv 0.130/0.131
5 min avg ratio xmt/rcv 0.061/0.062
10 min avg ratio xmt/rcv 0.061/0.062
no bufs xmt 0 no bufs rcv 0
resyncs 0
Compression Protocol used: PPP Stac LZS
Check Mode = 3
Decompression Protocol used: Predictor 1
Notice the compression ratio and that different protocols are used for compression (TX) and decompression (RX)
Last modified 1yr ago