Frame relay - debug frame events during inverse arp

I was curious about the output of this debugging command so I decided to dive a little further. Here is what I found.

R1#debug frame-relay events

LMI status received about which DLCIs are active:

*Mar 1 00:11:23.903: Serial1/0: preparing IP inarp on 102
*Mar 1 00:11:23.903: Serial1/0: preparing IP inarp on 105
*Mar 1 00:11:23.907: Serial1/0: preparing IP inarp on 104

I received an INARP:

*Mar 1 00:11:24.015: Serial1/0: FR ARP input
*Mar 1 00:11:24.019: datagramstart = 0x7A0124E, datagramsize = 34

*Mar 1 00:11:24.019: FR encap = 0x18610300

*Mar 1 00:11:24.019: 80 00 00 00 08 06 00 0F 08 00 02 04 00 09 00 00

*Mar 1 00:11:24.023: 0A 00 00 02 18 61 0A 00 00 01 01 02 00 00

*Mar 1 00:11:24.023:
*Mar 1 00:11:24.023: Serial1/0: inarp received on 102
R1#
R1#show frame-relay map Serial1/0 (up): ip 10.0.0.2 dlci 102(0x66,0x1860), dynamic, broadcast,, status defined, active

Analysis:

Datagram size: 34 bytes. The total size of this frame packet is 34 bytes. In Wireshark this be the "bytes on the wire"

FR Encap: FR encap = 0x18610300. The 1861 is the upper (0x18) and lower (0x61) DLCI values. The 0x18 is hex which in binary is 00011000 or 24 in decimal. But remember in this octet only the first 6 bits are used for the DLCI and the rest are in the 2nd octet. That means 000110XXXX will be our DLCI value where XXXX is filled in by the first 4 bits of the 2nd octet. So far we have 000110XXXX = 96 (not 24 or 6!). The 2nd octet is 0x61 which is 01100001 in binary. We are concerned with the first 4 bits and we replace the XXXX with 0110 which leaves us with 0001100110 or 102. 102 is what we have in our show frame-relay map output.

The second half of the FR Encap line is 0300 which is the control code and some padding.

In the next 2 lines we have the hex output of our packet. Below is a screenshot of the packet: