Implement High-Level Data Link Control (HDLC) and PPP

HDLC (High-Level Data Link Control)


HDLC is a layer 2 protocol used for WAN connectivity. HDLC uses keepalives to monitor connectivity with the remote end device. The DCE side of the connection sends the DTE side a keepalive packet containing a sequence number. The DTE side echos this sequence number back to the DCE proving connectivity. If three consecutive packets are not received, the link is declared down.

You can monitor the keepalives on a HDLC link with the following debug command;

Router#debug serial interface

*Mar  1 00:15:23.251: Serial0/1: HDLC myseq 90, mineseen 90*, yourseen 91, line up
*Mar  1 00:15:24.707: Serial0/0(out): StEnq, myseq 87, yourseen 86, DTE up
*Mar  1 00:15:24.711: Serial0/0(in): Status, myseq 87, pak size 14
*Mar  1 00:15:33.251: Serial0/1: HDLC myseq 91, mineseen 91*, yourseen 92, line up
*Mar  1 00:15:34.707: Serial0/0(out): StEnq, myseq 88, yourseen 87, DTE up
*Mar  1 00:15:34.707: Serial0/0(in): Status, myseq 88, pak size 14

Although HDLC is a widely used protocol Cisco has created their own proprietary version of the protocol, the ISO standard for the much older HDLC does not include a Type field, so the Cisco HDLC implementation adds a Cisco-proprietary 2-byte Type field to support multiple protocols over an HDLC link. If you are connecting a Cisco device to a non-Cisco device you may not be able to use it, HDLC is on by default on Cisco serial interfaces.

You can configure HDLC encapsulation under your interface with the following command;

Router(config)#interface serial 0/0
Router(config-if)#encapsulation hdlc

You can check your interface protocol settings by using the following command;

Router#show interface serial 0/0 | in Encapsulation

Encapsulation HDLC, loopback not set

HDLC and PPP Comparisons;

Feature HDLC PPP
Error Detection Yes Yes
Error Recovery No Yes
Standard Protocol Type Field No Yes
Default on IOS Serial Links Yes No
Support Synchronous and Asynchronous Links No Yes

PPP will add the Protocol field and optional Padding field to the original HDLC framing. This Padding field allows PPP to ensure that the frame has an even number of bytes.

PPP (Point to Point Protocol)

The PPP protocol is designed for simple links which transport packets between two peers. These links provide full-duplex simultaneous bi-directional operation and are assumed to deliver packets in order. It is intended that PPP provide a common solution for easy connection of a wide variety of hosts, bridges and routers.

The PPP encapsulation provides for multiplexing of different network-layer protocols simultaneously over the same link. The PPP encapsulation has been carefully designed to retain compatibility with most commonly used supporting hardware.

To support high speed implementations, the default encapsulation uses only simple fields, only one of which needs to be examined for demultiplexing. The default header and information fields fall on 32-bit boundaries and the trailer may be padded to an arbitrary boundary.

PPP’s popularity is due to the fact it can work over many different connection types, including synchronous (clocks on both sides agree), asynchronous (clocks differ), ISDN, Digital Subscriber Line (DSL), and High Speed Serial Interface (HSSI) links.

PPP is made up of two main components, NCPs and LCP:

  • Network Control Protocol (NCPs) – A family of independent protocols that encapsulate network layer protocols, such as TCP/IP.
  • Link Control Protocol (LCP) – Negotiates, sets up, and tears down control options for the data-link connection to the WAN.

In order to establish communications over a point-to-point link, each end of the PPP link MUST first send LCP packets to configure and test the data link. After the link has been established, the peer MAY be authenticated. Then, PPP MUST send NCP packets to choose and configure one or more network-layer protocols. Once each of the chosen network-layer protocols has been configured, datagrams from each network-layer protocol can be sent over the link. The link will remain configured for communications until explicit LCP or NCP packets close the link down.

PPP Link Control Protocol

The PPP Link Control Protocol (LCP) controls the features independent of any specific Layer 3 protocol. For each Layer 3 protocol supported by PPP, PPP defines a Network Control Protocol (NCP). For instance, the PPP IPCP protocol defines PPP features for IP, such as dynamic address assignment. When a PPP serial link first comes up—for example, when a router senses the CTS, DSR, and DCD leads come up at the physical layer—LCP begins parameter negotiation with the other end of the link. LCP controls the negotiation of which authentication
methods to attempt, and in what order, and then allows the authentication protocol to complete its work. Once all LCP negotiation has completed successfully, LCP is considered to be “up.” At that point, PPP begins each Layer 3 Control Protocol.

There are three classes of LCP packets;

  1. Link Configuration packets used to establish and configure a link (Configure-Request, Configure-Ack, Configure-Nak and Configure-Reject).
  2. Link Termination packets used to terminate a link (Terminate-Rest and Terminate-Ack).
  3. Link Maintenance packets used to manage and debug a link (Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply, and Discard-Request).

LCP packet formats;

  • Configure-Request – Is sent by the router wishing to open a connection.
  • Configure-Ack – Indicates acknowledgment if every configuration option received in a Configure-Request was recognized and agreed on.
  • Configure-Nak – Indicates that some of the configuration options received in a Configure-Request were not agreed on (not acknowledged).
  • Configure-Reject – Indicates that some of the configuration options received in a Configure-Request were not recognized.
  • Terminate-Request – Is used by the router wishing to close a connection.
  • Terminate-Ack – Is sent in response to a Terminate-Request to close a connection.

PPP LCP has the following features;

  • Link Quality Monitoring (LQM) – LCP exchanges statistics about the percentage of frames received without any errors, if the percentage falls below a configured value, the link is dropped.
  • Looped link detection – Each router generates and sends a randomly chosen magic  number. If a router receives its own magic number, the link is looped and may be taken
    down.
  • Layer 2 load balancing – Multilink PPP (MLP) balances traffic by fragmenting each frame into one fragment per link, and sending one fragment over each link.
  • Authentication – Supports PAP, CHAP and EAP.

LCP/PPP Configuration

The following is a simple PPP with CHAP authentication and LQM precentage configuration between two routers;

Router1(config-if)#encapsulation ppp

Router1(config-if)#ppp quality 80

Router1(config-if)#ppp authentication chap

Router1(config)#username Router2 password 0 Cisco

Now for router 2,

Router2(config-if)#encapsulation ppp

Router2(config-if)#ppp quality 70

Router2(config-if)#ppp authentication chap

Router2(config)#username Router1 password Cisco

To verify if the link has come up and LCP have completed its negotiations apply the following show command;

Router1#show interface serial 0/1 | in LCP
Encapsulation PPP, LCP Open, loopback not set

PPP Network Control Protocol

Point-to-Point links tend to exacerbate many problems with the current family of network protocols. For instance, assignment and management of IP addresses, which is a problem even in LAN environments, is especially difficult over circuit-switched point-to-point links (such as dial-up modem servers). These problems are handled by a family of Network Control Protocols  (NCPs), which each manage the specific needs required by their respective network-layer protocols. NCP will work with one of the following network protocols, IP (this is the most common layer 3 protocol found today), IPX or AppleTalk. After a NCP has reached the Opened state, PPP will carry the corresponding network-layer protocol packets. Any supported network-layer protocol packets received when the corresponding NCP is not in the Opened state MUST be silently discarded. During this phase, link traffic consists of any possible combination of LCP, NCP, and network-layer protocol packets.

MLP (Multilink PPP)

MLP defines a method to combine multiple parallel serial links at Layer 2. The original motivation for MLP was to combine multiple ISDN B-channels without requiring any Layer 3 load balancing; however, MLP can be used to load balance traffic across any type of point-to-point serial link. MLP balances traffic by fragmenting each data link layer frame, either based on the number of parallel links or on a configured fragmentation delay. MLP then sends the fragments over different links, to the same remote address. The multiple physical links come up in response to a user-defined load threshold. This load can be measured on just inbound traffic, on just outbound traffic, or on either; however, it cannot be measured on the combined load of both inbound and outbound traffic.To allow for reassembly on the receiving end, over these different links, MLP adds a header (either 4 or 2 bytes) to each fragment. The header includes a Sequence Number field as well as Flag bits designating the beginning and ending fragments.

MLP can be configured using either multilink interfaces or virtual templates. All Layer 3 parameters are configured on the multilink interface. The serial links are associated with the multilink interface using the ppp multilink group commands;

Router1(config)#interface Multilink1
Router1(config-if)#ip address 192.168.100.1 255.255.255.0
Router1(config-if)#encapsulation ppp
Router1(config-if)#ppp multilink
Router1(config-if)#ppp multilink group 1

Router1(config)#interface Serial0/0
Router1(config-if)#no ip address
Router1(config-if)#encapsulation ppp
Router1(config-if)#ppp multilink group 1

Router1(config)#interface Serial0/1
Router1(config-if)#no ip address
Router1(config-if)#encapsulation ppp
Router1(config-if)#ppp multilink group 1

MLP Link Fragmentation and Interleaving

The term Link Fragmentation and Interleaving (LFI) refers to a type of Cisco IOS QoS tool
that prevents small, delay-sensitive packets from having to wait on longer, delay-insensitive
packets to be completely serialized out an interface. The Cisco IOS LFI feature reduces delay on slower-speed links by breaking up large datagrams and interleaving low-delay traffic packets with the smaller packets resulting from the fragmented datagram. LFI allows reserve queues to be set up so that Real-Time Protocol (RTP) streams can be mapped into a higher priority queue in the configured weighted fair queue set.

MLP provides a method of splitting, recombining, and sequencing datagrams across multiple logical data links. The LFI scheme is relatively simple: Large datagrams are multilink encapsulated and fragmented to packets of a size small enough to satisfy the delay requirements of the delay-sensitive traffic; small delay-sensitive packets are not multilink encapsulated, but are interleaved between fragments of the large datagram.

The following are parameters to take into account when setting up LFI on MLP;

  • The ppp multilink interleave interface subcommand tells the router to allow interleaving
  • The ppp multilink fragment-delay x command defines the fragment size indirectly, based on the following formula; size = x * bandwidth. You must remember that the unit for the delay parameter is in milliseconds, so the interface bandwidth units must be the same!
  • MLP LFI can be used with only one link or with multiple links.
  • The queuing scheduler on the multilink interface determines the next packet to send;
    as a result, many implementations use LLQ to always interleave delay-sensitive traffic
    between fragments.

Apply MLP LFI with LLQ to you links, use the following commands under the Multilink interface;

Router1(config-if)#ppp multilink fragment-delay 10
Router1(config-if)#ppp multilink interleave
Router1(config-if)#service-policy output queue-on-dscp

PPP Compression

With PPP compression you have two types of compression, Layer 2 payload compression and TCP header compression. When comparing payload compression with header compression. payload works best with longer packet lengths and header works better with shorter packet lengths. Header compression will take advantage of the predictability of the headers. When the data inside the packet is much larger that the header, saving on bytes with the header compression might be only a small reduction in the overall bandwidth required, this will make payload compression more appealing.

With PPP layer 2 payload compression there are three options that can be found, Lempel-Ziv Stacker (LZS), Microsoft Point-to-Point Compression (MPPC), and Predictor. Stacker and MPPC both use the same compression algorithm, Lempel-Ziv (LZ). With Predictor this uses a algorithm called Predictor. There are some defining factors between the two algorithms but the main differences would be, LZ uses more CPU and less memory in comparison to Predictor, and LZ typically results in a better compression ratio.

Feature Stacker MPPC Predictor
Uses LZ algorithm Yes Yes No
Uses Predictor algorithm No No Yes
Support on HDLC Yes No No
Support on PPP Yes Yes Yes
Support on Frame Relay Yes No No
Support ATM, ATM-to-Frame Relay
service Internetworking (using MLP)
Yes Yes Yes

Configuring payload compression simply requires a matching compress command under each interface on each end of the link(s), with matching parameters for the type of compression. Once compression is configured, PPP starts the Compression Control Protocol (CCP), which is another NCP, to perform the compression negotiations and manage the compression process.

With PPP you get two styles of IP header compression, TCP header compression and RTP header compression,

  • RTP (Real Time Protocol) encapsulation for Voice and Video flows. Voice flows, particularly for low-bitrate codecs, have very small data fields, with G.729 the packet is typically 60bytes, with 40bytes of the 60bytes being the IP/UDP/RTP headers. With RTP header compression it will compress the IP/UDP/RTP headers, 40bytes, into 2 or 4 bytes. With G.729 RTP header compression reduces the required bandwidth by more than 50%.
  • TCP header compression compresses the combined IP and TCP headers, a combined
    40 bytes, into 3 or 5 bytes. For TCP packets with small payloads, the saving can be
    significant. TCP header compression might not be worth the CPU and memory expense for larger packets, 1500-byte packet, compressing the 40 bytes of header into 3 bytes reduces the packet size by only about 2%

Header compression can be configured by applying any of the following command sets,

Legacy;

Router(config-if)#ip tcp header-compression [passive]

Router(config-if)#ip rtp header-compression [passive]

MQC;

policy-map cb-compression
class voice
bandwidth 82
compress header ip rtp
class critical
bandwidth 110
compress header ip tcp

Router(config)#interface Multilink1
Router(config-if)#bandwidth 256
Router(config-if)#service-policy output cb-compression

PPP authentication

PPP offers optional authentication and has three ways of authenticating the calling router – PAP, CHAP and EAP.

Password authentication protocol (PAP) uses something called a two way handshake allowing the remote host to authenticate itself. PAP supports unidirectional (one-way) and bi-directional (two-way) authentication. With unidirectional authentication, only the side (authenticator) receiving the Auth-Req authenticates the remote side (peer). The peer does not authenticate the authenticator. With bi-directional authentication, each side independently sends an Auth-Req packet. Both sides respond with either an Auth-Ack or Auth-Nak. It could happen that only one directions authentication was successful and the reverse direction not.The password is sent in clear text so it can easily be captured and read. There are three different types of PAP packets;

  • Authenticate-Request (Auth-Req) – The peer transmits the Authenticate-Request packet during the Authentication Phase.
    – Auth-Req is used to start the PAP authentication and is transmitted/accepted only during the Authentication Phase.
    -The Authenticate-Request packets are repeatedly sent until a valid reply packet is received.
  • Authenticate-ACK (Auth-Ack) – If the username/password pair received in an Authenticate-Request packet is acceptable, the authenticator replies with an Authenticate-ACK packet.
  • Authenticate-NAK (Auth-Nak) – If the username/password pair received are not acceptable, the authenticator replies with an Authenticate-NAK packet.

Challenge handshake authentication protocol (CHAP) uses a three-way handshake and never sends the password over the link in clear text. Instead a hashed value made from the password is sent. This hashed value can only be read by a host with the appropriate key to the MD5 algorithm.

The PPP Extensible Authentication Protocol (EAP) is a general protocol for PPP authentication which supports multiple authentication mechanisms. EAP does not select a specific authentication mechanism at Link Control Phase, but rather postpones this until the Authentication Phase. This allows the authenticator to request more information before determining the specific authentication mechanism. This also permits the use of a “back-end” server which actually implements the various mechanisms while the PPP authenticator merely passes through the authentication exchange.

PAP and CHAP configuration

Create a username and password to verify the incoming username and password pair;

Router1(config)#username Router2 password Cisco

Router2(config)#username Router1 password Cisco

Configure the interface settings;

Router1(config)#ppp authentication pap

Router1(config)#ppp pap sent-username Router1 password Cisco

Router1(config)#ppp pap refuse

The peer does not authenticate the authenticator.