Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

Silver

frame relay inverse arp

hello

i am trying to simulate a frame relay connection with GNS3

when trying to capture frame relay traffic to see how inverse arp works, i can see my router sending the inverse arp query:

in the ARP header the sender hardware address is 0000 and the target hardware address is 0410

i wonder how did the router find these values, especially the 0410?

notes:

1- the local dlci = 16 and remote dlci =16

2- if i add another remote site with local dlci=17 and remote dlci=16  then the target address will be 0411

thanks

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

frame relay inverse arp

Hello,

I believe the value should be 0x0401, not 0x0410.

What you see is caused by the actual format of the address in Frame Relay that corresponds to the ITU-T recommendation Q.922. The address field does not hold only the DLCI value but it also contains the C/R, FECN, BECN and DE bits (the C/R, Command/Response, is unused in Frame Relay to my best knowledge).

The RFC 2390 describing the InverseARP explains it quite nicely. The address field in Frame Relay is formatted as follows:

                8   7   6   5   4   3    2   1
              +------------------------+---+--+
              |  DLCI (high order)     |C/R|EA|
              +--------------+----+----+---+--+
              | DLCI (lower) |FECN|BECN|DE |EA|
              +--------------+----+----+---+--+

This field is two octets long. The leftmost six bits from the first octet contain the high order bits of the DLCI value. The C/R bit (Command/Response) bit is unused in Frame Relay (it is retaken from the HDLC by which many other frame formats were inspired). The EA bit stands for Extended Address, and signifies that the address continues into the next octet. EA=0 means another address octet follows; EA=1 means that this is the last address octet. In the first octet, EA=0.

The leftmost four bits from the second octet contain the low order bits of the DLCI value. The FECN/BECN/DE bits have the usual meaning (in the InverseARP message, they are all set to 0), and the EA in the second octet is set to 1.

So when you take the value 0x0401 and split it into bits, you get:

0000 0100

0000 0001

The bold bits are the ones that correspond to the DLCI value. Now when you concatenate them, you get 0000010000, or simply 10000 which is indeed 16 in decimal.

The value 0x0411 can be written as

0000 0100

0001 0001

The resulting value now is (omitting the starting zeros) 10001, or 17 in decimal.

You should be aware also of the show frame-relay map command output:

Serial1/0 (up): ip 10.0.0.2 dlci 16(0x10,0x400), dynamic,

              broadcast,, status defined, active

Note that the highlighted value of 0x400 for DLCI corresponds to the value 0x0401 with the EA bit zeroed for clarity. It is there to indicate how would the entire address field (with the non-DLCI bits zeroed) look like.

Best regards,

Peter

3 REPLIES
Cisco Employee

frame relay inverse arp

Hello,

I believe the value should be 0x0401, not 0x0410.

What you see is caused by the actual format of the address in Frame Relay that corresponds to the ITU-T recommendation Q.922. The address field does not hold only the DLCI value but it also contains the C/R, FECN, BECN and DE bits (the C/R, Command/Response, is unused in Frame Relay to my best knowledge).

The RFC 2390 describing the InverseARP explains it quite nicely. The address field in Frame Relay is formatted as follows:

                8   7   6   5   4   3    2   1
              +------------------------+---+--+
              |  DLCI (high order)     |C/R|EA|
              +--------------+----+----+---+--+
              | DLCI (lower) |FECN|BECN|DE |EA|
              +--------------+----+----+---+--+

This field is two octets long. The leftmost six bits from the first octet contain the high order bits of the DLCI value. The C/R bit (Command/Response) bit is unused in Frame Relay (it is retaken from the HDLC by which many other frame formats were inspired). The EA bit stands for Extended Address, and signifies that the address continues into the next octet. EA=0 means another address octet follows; EA=1 means that this is the last address octet. In the first octet, EA=0.

The leftmost four bits from the second octet contain the low order bits of the DLCI value. The FECN/BECN/DE bits have the usual meaning (in the InverseARP message, they are all set to 0), and the EA in the second octet is set to 1.

So when you take the value 0x0401 and split it into bits, you get:

0000 0100

0000 0001

The bold bits are the ones that correspond to the DLCI value. Now when you concatenate them, you get 0000010000, or simply 10000 which is indeed 16 in decimal.

The value 0x0411 can be written as

0000 0100

0001 0001

The resulting value now is (omitting the starting zeros) 10001, or 17 in decimal.

You should be aware also of the show frame-relay map command output:

Serial1/0 (up): ip 10.0.0.2 dlci 16(0x10,0x400), dynamic,

              broadcast,, status defined, active

Note that the highlighted value of 0x400 for DLCI corresponds to the value 0x0401 with the EA bit zeroed for clarity. It is there to indicate how would the entire address field (with the non-DLCI bits zeroed) look like.

Best regards,

Peter

Silver

frame relay inverse arp

thanks peter

greate explanation !

in fact it is 0401 and not 0410

Silver

frame relay inverse arp

Peter

i have one more question if you mind

ok i understand that 17 is equivalent to 0411

now the HQ router is sending an inverse ARP request saying : i want to know the IP address of remote router with target hardware address 0411.

however in the remote router the dlci is 16 and not 17

so why does the remote router answer ? the target hardware address (0411) is not the one it has (0401)

i think the remote router does not know the dlci id from HQ side.it is not provided by LMI status message!

504
Views
0
Helpful
3
Replies