![[Top]](../images/home.jpg){kind=small}
![[Contents]](../images/contents.jpg){kind=small}
![[Prev]](../images/previous.jpg){kind=small}
![[Next]](../images/next.jpg){kind=small}
![[Last]](../images/index.jpg){kind=small}
This appendix covers these topics:
Overview
Many of the diagnostic commands display raw data. This Primer is designed to assist you in decoding PPP, MP, MP+ and BACP negotiations. The negotiations can be logged with the Diagnostic commands PPPDump, WANDisplay, WANDSess, WANNext or WANOpen. For more detailed information than this guide provides, refer to specific RFCs. A partial list of pertinent RFCs appears at the end of this guide.
Breaking down the raw data
An important concept to keep in mind is that each device negotiates PPP independently, so the options might be identical for each direction of the session.
FF 03 indicating it is a PPP frame.
Following are the packet formats:
RBAD denotes Received BAD:
RBAD-27:: 8712 octets @ 26CFE8
[0000]: fe dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd
[0010]: dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd
[0020]: dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd
[0030]: dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd
Annotated Traces
Use the following traces as guides to help you decode other traces.
XMIT-3:: 29 octets @ 2C2E94This is a second LCP Configure Request from the same device. Everything in the packet is identical to the previous packet, except the ID number has incremented from 01 to 02:
[0000]: ff 03 c0 21 01 01 00 19 00 04 00 00 01 04 05 f4
[0010]: 11 04 05 f4 13 09 03 00 c0 7b 4c e0 4c
XMIT-3:: 29 octets @ 2C2E94LCP Configure Request - CHAP authentication, Magic number
[0000]: ff 03 c0 21 01 02 00 19 00 04 00 00 01 04 05 f4
[0010]: 11 04 05 f4 13 09 03 00 c0 7b 4c e0 4c
RECV-3:: 19 octets @ 2BEB8CLCP Configure Acknowledgment - This device will authenticate using CHAP. The Magic number is also acknowledged:
[0000]: ff 03 c0 21 01 60 00 0f 03 05 c2 23 05 05 06 4e
[0010]: 36 c9 05
XMIT-3:: 19 octets @ 2C2E94LCP Configure Reject - MP+, MRU of 1524, MRRU of 1524 and End Point Discriminator.
[0000]: ff 03 c0 21 02 60 00 0f 03 05 c2 23 05 05 06 4e
[0010]: 36 c9 05
This rejection shows two things. It shows that the remote side does not support MP+ or MP, since MP+ and the MRRU were rejected. This will have to be a PPP connection. Also, since the MRU of 1524 was rejected, the default of 1500 is assumed. There needs to be an MRU, so a rejection of a given value only means to use the default value.
At this point, this device will need to retransmit another LCP Configure Request, removing all the rejected options.
RECV-3:: 29 octets @ 2BF1A4LCP Configure Request - Note all values that were previously rejected are no longer in the packet:
[0000]: ff 03 c0 21 04 02 00 19 00 04 00 00 01 04 05 f4
[0010]: 11 04 05 f4 13 09 03 00 c0 7b 4c e0 4c
XMIT-3:: 8 octets @ 2C2E94LCP Configure Acknowledgment -
[0000]: ff 03 c0 21 01 04 00 04
RECV-3:: 8 octets @ 2BF7BCAt this point, since both sides have transmitted LCP Configure Acknowledgments, LCP is up and the negotiation moves to the authentication phase.
[0000]: ff 03 c0 21 02 04 00 04
This device receives a CHAP challenge from the remote end:
RECV-3:: 21 octets @ 2BFDD4This device transmits its encrypted user name and password:
[0000]: ff 03 c2 23 01 01 00 11 04 4e 36 c9 5e 63 6c 63
[0010]: 72 34 30 30 30
XMIT-3:: 36 octets @ 2C2E94The remote device sends a CHAP Acknowledgment:
[0000]: ff 03 c2 23 02 01 00 20 10 49 b8 e8 54 76 3c 4a
[0010]: 6f 30 16 4e c0 6b 38 ed b9 4c 26 48 5f 53 65 61
[0020]: 74 74 6c 65
RECV-3:: 8 octets @ 2C03ECAt this point, the negotiation moves from authentication to negotiation of Network Control Protocols (NCPs). Ascend supports Bridging Control Protocol (BCP), IPCP, IPXCP and ATCP.
[0000]: ff 03 c2 23 03 01 00 04
IPCP Configure Request - Van Jacobsen Header Compression, IP address of 1.1.1.1
RECV-3:: 20 octets @ 2C0A04BCP Configure Request -
[0000]: ff 03 80 21 01 e3 00 10 02 06 00 2d 0f 00 03 06
[0010]: 01 01 01 01
RECV-3:: 8 octets @ 2C101CIPCP Configure Request - IP address of 2.2.2.2
[0000]: ff 03 80 31 01 55 00 04
XMIT-3:: 14 octets @ 2C2E94IPCP Configure Reject - Van Jacobsen Header Compression. The remote device should send another IPCP Configure Request and remove the request to do VJ Header Compression:
[0000]: ff 03 80 21 01 01 00 0a 03 06 02 02 02 02
XMIT-3:: 14 octets @ 2C2E94BCP - Protocol Reject. This local device is not configured to support bridging.
[0000]: ff 03 80 21 04 e3 00 0a 02 06 00 2d 0f 00
XMIT-3:: 8 octets @ 2C2E94IPCP Configure Acknowledgment
[0000]: ff 03 80 31 08 55 00 04
RECV-3:: 14 octets @ 2C1634IPCP Configure Request - Note VJ Header Compression is not requested this time.
[0000]: ff 03 80 21 02 01 00 0a 03 06 01 01 01 01
RECV-3:: 14 octets @ 2C1C4CIPCP Configure Acknowledgment
[0000]: ff 03 80 21 01 e4 00 0a 03 06 02 02 02 02
XMIT-3:: 14 octets @ 2C2E94At this point, a PPP connection has been successfully negotiated. The caller was successfully authenticated by means of CHAP and IPCP was the only successfully configured NCP. IPX, Appletalk and bridging will not be supported during this session.
[0000]: ff 03 80 21 02 e4 00 0a 03 06 01 01 01 01
Below are two packets used in determining link quality:
LCP Echo request packet
RECV-3:: 16 octets @ 2BEB8CLCP Echo Response
[0000]: ff 03 c0 21 09 01 00 0c 4e 36 c9 05 00 00 00 00
XMIT-3:: 16 octets @ 2C2E94
[0000]: ff 03 c0 21 0a 01 00 0c 00 00 00 00 00 00 00 00
Example of MP+ call negotiation
LCP Configuration Request - MP+, MRU of 1524, MRRU of 1524, End Point Discriminator using the device's MAC address:
XMIT-31:: 29 octets @ D803CLCP Configure Request - MP+, MRU of 1524, PAP authentication is required. MRRU of 1524, End Point Discriminator using the device's MAC address:
[0000]: ff 03 c0 21 01 01 00 19 00 04 00 00 01 04 05 f4
[0010]: 11 04 05 f4 13 09 03 00 c0 7b 5c d3 71
RECV-31:: 33 octets @ D4FBCLCP Configuration Acknowledgment -
[0000]: ff 03 c0 21 01 01 00 1d 00 04 00 00 01 04 05 f4
[0010]: 03 04 c0 23 11 04 05 f4 13 09 03 00 c0 7b 53 f0
[0020]: 7a
RECV-31:: 29 octets @ D55CCLCP Configuration Acknowledgment -
[0000]: ff 03 c0 21 02 01 00 19 00 04 00 00 01 04 05 f4
[0010]: 11 04 05 f4 13 09 03 00 c0 7b 5c d3 71
XMIT-31:: 33 octets @ D803CAt this point, LCP is up. Next is the authentication phase. The local device agreed to authenticate using PAP, so it should transmit its user name and password. Note that it is not encrypted, and user name and password can be decoded very easily:
[0000]: ff 03 c0 21 02 01 00 1d 00 04 00 00 01 04 05 f4
[0010]: 03 04 c0 23 11 04 05 f4 13 09 03 00 c0 7b 53 f0
[0020]: 7a
PAP Authentication Request - User name is shown in hexadecimal and must be converted to ascii. User name is 0x6a 0x73 0x6d 0x69 0x74 0x68 (jsmith) and password is 0x72 0x65 0x64 (red):
XMIT-31:: 20 octets @ D803CPAP Authentication Acknowledgment -
[0000]: ff 03 c0 23 01 01 00 10 06 6a 73 6d 69 74 68 03 72
[0010]: 65 64
RECV-31:: 9 octets @ D5BDCAuthentication is successful. Final negotiation determines protocols to be supported over the link.
[0000]: ff 03 c0 23 02 01 00 05 00
In the following packet,
00 3d is the designation for a Multilink packet. The next byte designates whether this packet is fragmented. The next three bytes are the sequence number. You'll see them increment by one for each packet sent or received.
RECV-31:: 20 octets @ D61ECBCP Configure Request:
[0000]: ff 03 00 3d c0 00 00 00 80 31 01 01 00 0a 03 03
[0010]: 01 07 03 00
XMIT-31:: 20 octets @ D803CBCP Configure Acknowledgment:
[0000]: ff 03 00 3d c0 00 00 00 80 31 01 01 00 0a 03 03
[0010]: 01 07 03 00
XMIT-31:: 20 octets @ D864CBCP Configure Acknowledgment:
[0000]: ff 03 00 3d c0 00 00 01 80 31 02 01 00 0a 03 03
[0010]: 01 07 03 00
RECV-31:: 20 octets @ D67FCBCP is up and the session begins sending bridged traffic. No routed protocols were negotiated.
[0000]: ff 03 00 3d c0 00 00 01 80 31 02 01 00 0a 03 03
[0010]: 01 07 03 00
The following packets are sent as part of the MP+ protocol. They are sent at one-second intervals. These packets are used by each unit to validate the existence of the link. It gives the devices a secure way to determine whether the link is still up, even if there is no data traffic passing between the devices.
RECV-31:: 8 octets @ D5BDCThe following RFCs provide more detail about the subjects listed in their titles:
[0000]: ff 03 00 3d c0 00 00 05
XMIT-31:: 8 octets @ D803C
[0000]: ff 03 00 3d c0 00 00 04
RECV-31:: 8 octets @ D61EC
[0000]: ff 03 00 3d c0 00 00 06
XMIT-31:: 8 octets @ D803C
[0000]: ff 03 00 3d c0 00 00 05
Copyright © 1997, Ascend Communications, Inc. All rights reserved.