Basics of understanding and troubleshooting PPP compression features

David Damerjian · ‎04-09-2012

discusses configuring PPP data and IP header compression, sample trace, 
monitoring and counting compression sessions

PPP IP header compression and PPP data compression are both configured in the PDSN in the subscriber profile and are both negotiated during call setup.

PPP IP header compression is configured as follows:

ppp ip-header-compression negotiate force
ppp ip-header-compression negotiate vj compress-slot-id receive

This can also be returned by radius via the Framed-Compression attribute. Add the “no” keyword as follows to turn off IP header compression: “no ip-header-compression”

For PPP data compression, any combination of data compression types can be specified by adding them to the configuration line, for example:

ppp data-compression protocols {stac | mppc | deflate}

This can also be returned by radius via the SN-PPP-Data-Compression attribute which also allows specifying various combinations of compression types. Add the “no” keyword as follows to turn off PPP data compression: “no ppp data-compression protocols”.

During PPP negotiation, the PDSN advertises the compression types it can support, and the mobile device will choose the compression type it wants, and PDSN will ensue to do the same. Below is an example of the protocol exchange for both IP header and data compression types. For PPP data compression, the bold black shows the PDSN-initiated negotiation while the red shows the mobile-initiated negotiation. Some of the remaining lines cover the IP Header compression negotiation. The accounting request confirms that MPPC data compression and VJ Header compression were negotiated in this case:

<<<<OUTBOUND 19:59:31:581 Eventid:25001(0)
PPP Tx PDU (28)
LCP 28: Conf-Req(1), ACCM=00000000, Auth-Prot PAP, Magic-Num=c4031010, PFC, ACFC

INBOUND>>>>> 19:59:31:583 Eventid:25000(0)
PPP Rx PDU (24)
LCP 24: Conf-Req(1), ACCM=00000000, Magic-Num=9481e7a8, PFC, ACFC

<<<<OUTBOUND 19:59:31:583 Eventid:25001(0)
PPP Tx PDU (24)
LCP 24: Conf-Ack(1), ACCM=00000000, Magic-Num=9481e7a8, PFC, ACFC

INBOUND>>>>> 19:59:31:583 Eventid:25000(0)
PPP Rx PDU (28)
LCP 28: Conf-Ack(1), ACCM=00000000, Auth-Prot PAP, Magic-Num=c4031010, PFC, ACFC

INBOUND>>>>> 19:59:31:584 Eventid:25000(0)
PPP Rx PDU (20)
PAP 20: Auth-Req(1), Name=dave, Passwd=secret

<<<<OUTBOUND 19:59:31:592 Eventid:25001(0)
PPP Tx PDU (9)
PAP 9: Auth-Ack(1), Msg=

<<<<OUTBOUND 19:59:31:593 Eventid:25001(0)
PPP Tx PDU (20)
IPCP 20: Conf-Req(1), IP-Comp VJ-Comp, IP-Addr=192.168.51.150

<<<<OUTBOUND 19:59:31:593 Eventid:25001(0)
PPP Tx PDU (23)
CCP 23: Conf-Req(1), MPPC, Stac-LZS, Deflate

INBOUND>>>>> 19:59:31:609 Eventid:25000(0)
PPP Rx PDU (32)
IPCP 32: Conf-Req(1), IP-Comp VJ-Comp, IP-Addr=0.0.0.0, Pri-DNS=0.0.0.0, Sec-DNS=0.0.0.0

<<<<OUTBOUND 19:59:31:609 Eventid:25001(0)
PPP Tx PDU (20)
IPCP 20: Conf-Rej(1), Pri-DNS=0.0.0.0, Sec-DNS=0.0.0.0

INBOUND>>>>> 19:59:31:609 Eventid:25000(0)
PPP Rx PDU (14)
CCP 14: Conf-Req(1), MPPC

<<<<OUTBOUND 19:59:31:609 Eventid:25001(0)
PPP Tx PDU (14)
CCP 14: Conf-Ack(1), MPPC

INBOUND>>>>> 19:59:31:610 Eventid:25000(0)
PPP Rx PDU (20)
IPCP 20: Conf-Ack(1), IP-Comp VJ-Comp, IP-Addr=192.168.51.150

INBOUND>>>>> 19:59:31:610 Eventid:25000(0)
PPP Rx PDU (17)
CCP 17: Conf-Rej(1), Stac-LZS, Deflate

<<<<OUTBOUND 19:59:31:610 Eventid:25001(0)
PPP Tx PDU (14)
CCP 14: Conf-Req(2), MPPC

INBOUND>>>>> 19:59:31:611 Eventid:25000(0)
PPP Rx PDU (20)
IPCP 20: Conf-Req(2), IP-Comp VJ-Comp, IP-Addr=0.0.0.0

<<<<OUTBOUND 19:59:31:611 Eventid:25001(0)
PPP Tx PDU (14)
IPCP 14: Conf-Nak(2), IP-Addr=20.20.20.85

INBOUND>>>>> 19:59:31:611 Eventid:25000(0)
PPP Rx PDU (14)
CCP 14: Conf-Ack(2), MPPC

INBOUND>>>>> 19:59:31:612 Eventid:25000(0)
PPP Rx PDU (20)
IPCP 20: Conf-Req(3), IP-Comp VJ-Comp, IP-Addr=20.20.20.85

<<<<OUTBOUND 19:59:31:612 Eventid:25001(0)
PPP Tx PDU (20)
IPCP 20: Conf-Ack(3), IP-Comp VJ-Comp, IP-Addr=20.20.20.85

<<<<OUTBOUND 19:59:31:617 Eventid:24901(6)
RADIUS ACCOUNTING Tx PDU, from 192.168.50.151:32793 to 192.168.50.200:1813 (666) PDU-dict=starent-vsa1
Code: 4 (Accounting-Request)
Id: 3
Length: 666
Authenticator: CB B9 D4 E1 8B EC FA 56 73 F2 C8 15 C4 7A DF D9
      User-Name = dave
      Calling-Station-Id = 0000012345
      NAS-IP-Address = 192.168.50.151
      Acct-Status-Type = Start
      Acct-Session-Id = 0BD18679
      3GPP2-Correlation-Id = 3roxTbis
      NAS-Identifier = source
      3GPP2-MEID =
      3GPP2-BSID = 00000000CCCC
      3GPP2-RP-Session-ID = 0
      3GPP2-Service-Option = HSPD
      3GPP2-User-Zone = 5
      Service-Type = Framed
      Framed-Protocol = PPP
      NAS-Port-Type = Wireless_Other
      3GPP2-Serving-PCF = 192.168.50.200
      Acct-Authentic = Local
      SN1-Local-IP-Address = 192.168.51.150
      SN1-Primary-DNS-Server = 0.0.0.0
      SN1-Secondary-DNS-Server = 0.0.0.0
      SN1-Primary-NBNS-Server = 0.0.0.0
      SN1-Secondary-NBNS-Server = 0.0.0.0
      3GPP2-Always-On = Inactive
      Framed-MTU = 1500
      Framed-Compression = VJ_TCP_IP_header_compression
      SN1-PPP-Data-Compression = MPPC
      SN1-PPP-Data-Compression-Mode = Normal
      SN1-VPN-Name = destination
      SN1-Rulebase = default
      SN1-Proxy-MIP = Disabled
      SN1-VPN-ID = 3
      3GPP2-IP-Technology = Simple-IP
      3GPP2-Comp-Tunnel-Indicator = No-Tunnel
      3GPP2-Forward-Mux-Option = 5
      3GPP2-Reverse-Mux-Option = 5
      3GPP2-Forward-Fundamental-Rate = 5
      3GPP2-Reverse-Fundamental-Rate = 5
      3GPP2-Forward-Traffic-Type = Primary
      3GPP2-Reverse-Traffic-Type = Primary
      3GPP2-Fundamental-Frame-Size = None
      3GPP2-Forward-Fundamental-RC = 5
      3GPP2-Reverse-Fundamental-RC = 5
      3GPP2-Air-QOS = 7
      3GPP2-Airlink-Sequence-Number = 1
      3GPP2-Airlink-Record-Type = Active-Start
      3GPP2-Number-Active-Transitions = 0
      3GPP2-SDB-Input-Octets = 0
      3GPP2-SDB-Output-Octets = 0
      3GPP2-Num-SDB-Input = 0
      3GPP2-Num-SDB-Output = 0
      3GPP2-Num-Bytes-Received-Total = 0
      3GPP2-Beginning-Session = True
      Event-Timestamp = 1244678371
      3GPP2-Service-Reference-ID = 01 04 00 01 02 04 00 01
                SR-ID = 1
                Main-SI-Indicator = Main-SI
      Framed-IP-Address = 20.20.20.85
      Framed-IP-Netmask = 255.255.255.255
      SN1-Service-Type = PDSN
      SN1-IP-Header-Compression = None
      NAS-Port = 98321

INBOUND>>>>> 19:59:31:619 Eventid:24900(6)
RADIUS ACCOUNTING Rx PDU, from 192.168.50.200:1813 to 192.168.50.151:32793 (20) PDU-dict=starent-vsa1
Code: 5 (Accounting-Response)
Id: 3
Length: 20
Authenticator: 6B C1 C5 D7 3D 6A 51 CD 62 32 24 67 58 34 B9 A5

In the case of PPP data compression for MPPC and STAC, not all PPP packets will be compressed, but only packets greater than a specific size. The minimum compression size can be specified as follows in the subscriber profile:

ppp min-compression-size <size>

(For Deflate, all packets are compressed.) In the case where packet size meets the minimum size for compression, the source and destination addresses of the packets will NOT be displayed by default in monitor subscriber traces, because the data is still compressed. In order to display them, turn on “19 User L3”, which will show output from the sessmgr process uncompressing them. This is the only situation where this option will give you more data than you would otherwise already get by default. You will see the same packets displayed twice, and one of the instances (depending on direction) will have the complete data. Here is an example of this for ICMP request and response packets that were large enough to be compressed:

INBOUND>>>>> 08:03:54:126 Eventid:25000(0)
PPP Rx PDU (57)
COMP 57:

INBOUND>>>>> 08:03:54:126 Eventid:51000(0)
IPv4 Rx PDU
20.20.20.89 > 192.168.51.200: icmp: echo request (ttl 64, id 1, len 148)

<<<<OUTBOUND 08:03:54:130 Eventid:51001(0)
IPv4 Tx PDU
192.168.51.200 > 20.20.20.89: icmp: echo reply (ttl 64, id 31163, len 148)

<<<<OUTBOUND 08:03:54:130 Eventid:25001(0)
PPP Tx PDU (57)
COMP 57:

Once a subscriber is connected, the compression types for the subscriber are viewable using the following commands.

For IP header compression, use “show subscriber full” and look for “ip header compression: (loc to rem) vj, (rem to loc) vj”.

For both ppp ip header and data compression types, use “show ppp username <username>” or the like, to view a specific subscriber’s settings, for example:

[local]CSE2# show ppp username dave
PPP Summary:
1 PPP Sessions In Progress

Layer Info:
1 LCP Up 1 IPCP Up 0 IPv6CP Up 1 CCP Up

Compression:
         1 VJ Compressed Sessions (loc to rem)
         1 VJ Compressed Sessions (rem to loc)
         0 ROHC Compressed Sessions (loc to rem)
         0 ROHC Compressed Sessions (rem to loc)
         1 Normal PPP Compressed Sessions
         0 Stateless PPP Compressed Sessions
         0 NONE 0 STAC 1 MPPC 0 DEFLATE (loc to rem)
         0 NONE 0 STAC 1 MPPC 0 DEFLATE (rem to loc)

In this example there is one PPP session with both IP header and data compression types enabled.

Or, for totals of compression types for all active subscribers, run the command “show ppp summary”.

Finally, the command “show ppp statistics” will indicate the total number of PPP sessions to date (active or ended) with the various types of compression. For example:

Session Data Compression
sessions negotiated comp: 25            STAC Compression:          4
MPPC compression:          18            Deflate Compression:       3
CCP negotiation failures: 0
Session Header Compression
VJ compression:            57
ROHC compression:          0

It should be noted that PPP data compression should be used with care. Some mobile devices are not the robust in implementing data compression. Also, data compression uses lots of CPU resources, so if many subscribers are doing it, the chassis CPU usage should be monitored with “show cpu table”.

Imported from Starent Networks Knowledgebase Article # 10500