Hello Peter,

I am using GNS3 (Cisco Hardware Emulator)

The device is 3725, as you can see:

Mcbo#
Mcbo#
Mcbo#sh ver
Cisco IOS Software, 3700 Software (C3725-ADVENTERPRISEK9-M), Version 12.4(15)T11, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2009 by Cisco Systems, Inc.
Compiled Wed 28-Oct-09 22:57 by prod_rel_team

ROM: ROMMON Emulation Microcode
ROM: 3700 Software (C3725-ADVENTERPRISEK9-M), Version 12.4(15)T11, RELEASE SOFTWARE (fc2)

Mcbo uptime is 4 hours, 3 minutes
System returned to ROM by unknown reload cause - suspect boot_data[BOOT_COUNT] 0x0, BOOT_COUNT 0, BOOTDATA 19
System restarted at 14:57:56 CCS Mon Dec 21 2009
System image file is "tftp://255.255.255.255/unknown"

This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export@cisco.com.

Cisco 3725 (R7000) processor (revision 0.1) with 124928K/6144K bytes of memory.
Processor board ID XXXXXXXXXXX
R7000 CPU at 240MHz, Implementation 39, Rev 2.1, 256KB L2, 512KB L3 Cache
18 FastEthernet interfaces
2 Serial(sync/async) interfaces
DRAM configuration is 64 bits wide with parity enabled.
55K bytes of NVRAM.
16384K bytes of ATA System CompactFlash (Read/Write)

Configuration register is 0x2102

Mcbo#
Mcbo#
Mcbo#sh run int s0/0
Building configuration...

Current configuration : 123 bytes
!
interface Serial0/0
no ip address
encapsulation frame-relay
logging event dlci-status-change
clock rate 2000000
end

Mcbo#sh run int s0/0.150
Building configuration...

Current configuration : 223 bytes
!
interface Serial0/0.150 multipoint
ip address 192.168.0.5 255.255.255.252
ip rip authentication mode md5
ip rip authentication key-chain RIP-AUTH
snmp trap link-status
cdp enable
frame-relay interface-dlci 150
end

Mcbo#
Mcbo#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Mcbo(config)#int s0/0.150
Mcbo(config-subif)#fram
Mcbo(config-subif)#frame-relay in
Mcbo(config-subif)#frame-relay inver
Mcbo(config-subif)#frame-relay inverse-arp ?
  appletalk  AppleTalk
  decnet     DECnet
  ip         IP
  ipx        Novell IPX
 

Mcbo(config-subif)#frame-relay inverse-arp ip ?
  <16-1007>  Set DLCI for inverse ARP
  vc-bundle  vc-bundle

Mcbo(config-subif)#frame-relay inverse-arp ip

Don't have the option interval at sub-interface configuration level.

But a physical interface level, I have it:

Mcbo(config)#int s0/0
Mcbo(config-if)#fram
Mcbo(config-if)#frame-relay in
Mcbo(config-if)#frame-relay inver
Mcbo(config-if)#frame-relay inverse-arp ?
  appletalk  AppleTalk
  decnet     DECnet
  interval   Set inarp time interval on an interface
  ip         IP
  ipx        Novell IPX
 

Mcbo(config-if)#frame-relay inverse-arp

PLC(config-if)#frame-relay inverse-arp in
PLC(config-if)#frame-relay inverse-arp interval ?
  <15-300>  Set interval for inverse ARP

How I can do to verify the default value? It's possible or not? there options are 15-300? Why 7xx seconds on my lab?

I was find  the teorical information about InARP interval on Cisco Press Material "Cisco Frame Relay Solutions Guide" but was unsuccesful.

Hello, Peter

- LMI PVC status messages triggered inverse arp. After receiving and LMI PVC Up message, each router announcesits own IP address over the VC, using inverse ARP,as defined in RFC 1293.

Then of every 6 LMI messages are sent a "Full Status" LMI messages (include PVC IE)  with the default value of keepalive equal 10 seconds is very logical that the Frame-Relay Map Refreshing Interval is 60 Second.

The interface command "frame-relay inverse-arp interval" is not recognize

by GNS3 due when I tried to configured it and use the ? option, It don't appear but is possible to configured it.

Is very probably that GNS3 Emulation Hardware tool has a bug about that particular issue.

I will try to do a frame-relay debug with real routers.

Thank again for your assistance.

Hello David,

Yes, you are correct - a Frame Relay DTE device (such as router) sends its LMI Status Inquiry messages every 10 seconds, and every 6th message is the Full Status Request.

However, I personally do not believe that the interval of 60 seconds in the InverseARP is directly bound to the frequency of Full Status Requests. It might be initially aligned to this interval but whether the arrival of LMI Status Inquiry Report triggers also the InverseARP remains a question to me. Frankly, I can imagine both options - that it does, and again, that it does not. This does not seem to be any "hard" protocol requirement and in fact, I can imagine that it is a pure implementation choice and that a different IOS or perhaps a different vendor uses other events as triggers to InverseARP request/reply.

Regarding the GNS3 - I don't think it is its "bug" that you do not see the frame-relay inverse-arp interval command. The GNS3 is basically a wrapper around dynamips, and the dynamips is a virtual machine for selected IOS versions, just like VMWare is a virtual machine for Windows. You run real-life IOS inside dynamips and the dynamips has no effect on which command are available in that IOS, just as VMWare cannot influence whether the Windows running inside it has the Minesweeper installed or not. The command may be missing or hidden just because it is missing or hidden in the particular IOS version you are using in GNS3.

Best regards,

Peter

Hello Peter,

Thanks for your reply, here you can see the IOS Version that I use with GNS3 Hardware Emulator.

Mcbo>
Mcbo>sh ver
Cisco IOS Software, 3700 Software (C3725-ADVENTERPRISEK9-M), Version 12.4(15)T11, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2009 by Cisco Systems, Inc.
Compiled Wed 28-Oct-09 22:57 by prod_rel_team

ROM: ROMMON Emulation Microcode
ROM: 3700 Software (C3725-ADVENTERPRISEK9-M), Version 12.4(15)T11, RELEASE SOFTWARE (fc2)

Mcbo uptime is 0 minutes
System returned to ROM by unknown reload cause - suspect boot_data[BOOT_COUNT] 0x0, BOOT_COUNT 0, BOOTDATA 19
System image file is "tftp://255.255.255.255/unknown"

This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export@cisco.com.

Cisco 3725 (R7000) processor (revision 0.1) with 124928K/6144K bytes of memory.
Processor board ID XXXXXXXXXXX
R7000 CPU at 240MHz, Implementation 39, Rev 2.1, 256KB L2, 512KB L3 Cache
18 FastEthernet interfaces
2 Serial(sync/async) interfaces
DRAM configuration is 64 bits wide with parity enabled.
55K bytes of NVRAM.
16384K bytes of ATA System CompactFlash (Read/Write)

Configuration register is 0x2102

Mcbo>

I think the same thing about this tool. since I'm using a real IOS, their behavior should be the same. Given the IOS don't be care  if is running on real hardware or Dynamips VM . However, this tool does not escape have faults that might be corrected by the great team that developed it.

But take the time to ask a question:

CEF is implemented in hardware using application specific integrated circuits (ASIC) could then GNS3 to emulate the work of these circuits without having them in hardware?

So previously I had the idea of a possible failure of the excellent tool GNS3.

Sorry that I retake the point on frame-relay inverse arp, but as you can see below I set the command frame-relay inverse-arp interval 120 (2 minutes) this value can be set between 15 and 300 seconds (5 minutes). After enabling the debug frame-relay events can see that the refresh frame-relay inverse arp will still perform every 10 minutes.

Mcbo#sh run int s0/0   
Building configuration...

Current configuration : 161 bytes
!
interface Serial0/0
no ip address
encapsulation frame-relay
logging event dlci-status-change
clock rate 2000000
frame-relay inverse-arp interval 120
end

Mcbo#

Mcbo#
Mcbo#sh run int s0/0.150
Building configuration...

Current configuration : 223 bytes
!
interface Serial0/0.150 multipoint
ip address 192.168.0.5 255.255.255.252
ip rip authentication mode md5
ip rip authentication key-chain RIP-AUTH
snmp trap link-status
cdp enable
frame-relay interface-dlci 150
end

000101: *Feb 28 19:35:49: Serial0/0.150: preparing IP inarp on 150
000102: *Feb 28 19:35:49: Serial0/0.150: FR ARP input
000103: *Feb 28 19:35:49: Serial0/0.150: inarp received on 150
000104: *Feb 28 19:35:49: datagramstart = 0x7A0070E, datagramsize = 34
000105: *Feb 28 19:35:49: FR encap = 0x24610300
000106: *Feb 28 19:35:49: 80 00 00 00 08 06 00 0F 08 00 02 04 00 09 00 00
000107: *Feb 28 19:35:49: C0 A8 00 06 24 61 C0 A8 00 05 01 02 00 00
000108: *Feb 28 19:35:49:
000109: *Feb 28 19:45:09: Refresh needed for FR map: 192.168.0.6 on Serial0/0.150 DLCI 150
000110: *Feb 28 19:45:09: Serial0/0.150: preparing IP inarp on 150
000111: *Feb 28 19:45:09: Serial0/0.150: FR ARP input
000112: *Feb 28 19:45:09: Serial0/0.150: inarp received on 150
000113: *Feb 28 19:45:09: datagramstart = 0x7A0188E, datagramsize = 34
000114: *Feb 28 19:45:09: FR encap = 0x24610300
000115: *Feb 28 19:45:09: 80 00 00 00 08 06 00 0F 08 00 02 04 00 09 00 00
000116: *Feb 28 19:45:09: C0 A8 00 06 24 61 C0 A8 00 05 01 02 00 00
000117: *Feb 28 19:45:09:
000118: *Feb 28 19:55:09: Refresh needed for FR map: 192.168.0.6 on Serial0/0.150 DLCI 150
000119: *Feb 28 19:55:09: Serial0/0.150: preparing IP inarp on 150
000120: *Feb 28 19:55:09: Serial0/0.150: FR ARP input
000121: *Feb 28 19:55:09: Serial0/0.150: inarp received on 150
000122: *Feb 28 19:55:09: datagramstart = 0x7A01B0E, datagramsize = 34
000123: *Feb 28 19:55:09: FR encap = 0x24610300
000124: *Feb 28 19:55:09: 80 00 00 00 08 06 00 0F 08 00 02 04 00 09 00 00
000125: *Feb 28 19:55:09: C0 A8 00 06 24 61 C0 A8 00 05 01 02 00 00
000126: *Feb 28 19:55:09:
Mcbo#
Mcbo#

With respect to commands not available in the IOS was my mistake because the command is not available subinterface level but if available at interface level. As shown below:

Mcbo#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Mcbo(config)#int s0/0
Mcbo(config-if)#frame-relay inverse-arp interval ?
  <15-300>  Set interval for inverse ARP

Mcbo(config-if)#frame-relay inverse-arp interval ^Z
% Incomplete command.

Mcbo#
Mcbo#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Mcbo(config)#int s0/0.150
Mcbo(config-subif)#frame-relay inverse-arp ?
  appletalk  AppleTalk
  decnet     DECnet
  ip         IP
  ipx        Novell IPX
 

Mcbo(config-subif)#frame-relay inverse-arp ^Z
Mcbo#

To clarify the point on the full status message triggers the Inverse ARP. I quote verbatim from the manual CCIE Routing and Switching Certification Guide. 3rd Edition or 4th Edition. Chapter 6 - IP Forwarding (Rounting). Topic IP Forwarding. Sub Topic - Building Adjacency Information: ARP and Inverse ARP. - Frame Relay Inverse ARP. Paragraph following the figure 6-2 (I attach a screenshot of the page above the book).

"Unlike on LANs, a packet does not need to arrive at the router to trigger the InARP protocol; instead, an LMI status message triggers InARP. After receiving an LMI PVC Up message, each router announces its own IP address over the VC, using an InARP message, as defined in RFC 1293. Interestingly, if you disable LMI, then the InARP process no longer works, Because nothing triggers on the router to send an InARP message."

I then proceeded to modify the configuration, explicitly the keepalive Parameters as show below to see if the results varied. As shown below:

Mcbo#sh run int s0/0
Building configuration...

Current configuration : 175 bytes
!
interface Serial0/0
no ip address
encapsulation frame-relay
logging event dlci-status-change
keepalive 20
clock rate 2000000
frame-relay inverse-arp interval 120
end

Mcbo#sh run int s0/0.150
Building configuration...

Current configuration : 237 bytes
!
interface Serial0/0.150 multipoint
ip address 192.168.0.5 255.255.255.252
ip rip authentication mode md5
ip rip authentication key-chain RIP-AUTH
snmp trap link-status
keepalive 20
cdp enable
frame-relay interface-dlci 150
end

Mcbo#

Certainly the State Enquiry LMI begin to send every 20 seconds as shown below:

000163: *Feb 28 20:18:09: Serial0/0(out): StEnq, myseq 1, yourseen 255, DTE up
000164: *Feb 28 20:18:09: datagramstart = 0x7F1AB54, datagramsize = 14
000165: *Feb 28 20:18:09: FR encap = 0x00010308
000166: *Feb 28 20:18:09: 00 75 95 01 01 01 03 02 01 FF
000167: *Feb 28 20:18:09:
000168: *Feb 28 20:18:09: Serial0/0(in): Status, myseq 1, pak size 14
000169: *Feb 28 20:18:09: RT IE 1, length 1, type 1
000170: *Feb 28 20:18:09: KA IE 3, length 2, yourseq 1 , myseq 1
000171: *Feb 28 20:18:29: Serial0/0(out): StEnq, myseq 2, yourseen 1, DTE up
000172: *Feb 28 20:18:29: datagramstart = 0x7F1A654, datagramsize = 14
000173: *Feb 28 20:18:29: FR encap = 0x00010308
000174: *Feb 28 20:18:29: 00 75 95 01 01 01 03 02 02 01
000175: *Feb 28 20:18:29:
000176: *Feb 28 20:18:29: Serial0/0(in): Status, myseq 2, pak size 14
000177: *Feb 28 20:18:29: RT IE 1, length 1, type 1
000178: *Feb 28 20:18:29: KA IE 3, length 2, yourseq 2 , myseq 2
000179: *Feb 28 20:18:49: Serial0/0(out): StEnq, myseq 3, yourseen 2, DTE up
000180: *Feb 28 20:18:49: datagramstart = 0x7A00354, datagramsize = 14
000181: *Feb 28 20:18:49: FR encap = 0x00010308
000182: *Feb 28 20:18:49: 00 75 95 01 01 01 03 02 03 02
000183: *Feb 28 20:18:49:
000184: *Feb 28 20:18:49: Serial0/0(in): Status, myseq 3, pak size 14
000185: *Feb 28 20:18:49: RT IE 1, length 1, type 1
000186: *Feb 28 20:18:49: KA IE 3, length 2, yourseq 3 , myseq 3

But the Frame-Relay MAP refresh interval of 10 minutes remains, as shown below:

Mcbo#sh log | include Refresh 
000337: *Feb 28 20:25:09: Refresh needed for FR map: 192.168.0.6 on Serial0/0.150 DLCI 150
000596: *Feb 28 20:35:09: Refresh needed for FR map: 192.168.0.6 on Serial0/0.150 DLCI 150
000855: *Feb 28 20:45:09: Refresh needed for FR map: 192.168.0.6 on Serial0/0.150 DLCI 150
001116: *Feb 28 20:55:09: Refresh needed for FR map: 192.168.0.6 on Serial0/0.150 DLCI 150
001411: *Feb 28 21:05:09: Refresh needed for FR map: 192.168.0.6 on Serial0/0.150 DLCI 150
Mcbo#

Would have to take the test in a real laboratory to find out. Or could be a very particular point of the implementation of frame-relay on Cisco IOS. But it definitely seems to have no relation with the interval of sending LMI Status Enquiry messages (keepalive) or the Frame-relay inverse-arp interval configuration command.

Again I am grateful for your support and time. I think this swap by discussions of various topics of a technical nature is really valuable for people who want to learn, and we apologize again if the subject seems so annoying to stress upon a technicality that may seem trivial.

I only want to learn and improve every day at the technical level and am trying to implement the advice of Scott Morris IPExpert during which cites the great Albert Einstein who said the phrase "Any fool can know. The point is to understand."

Hello David,

You have raised a number of issues in your last reply so let's go over them one by one.

Regarding the CEF - actually, there are hardware-based CEF and software-based CEF implementations. Sometimes the literature is not clear enough on this. Router platforms, such as ISR, ISR G2 or older 2600/3600 series support only software-based CEF operation and they have no specialized ASICs for CEF acceleration. The hardware-based CEF operation is present on multilayer Catalyst switches (3560, 3750, 4500, 6500) and high-end routers such as 7600 and higher that have the TCAMs available for prefix lookups. As the dynamips emulates platforms with a software-based CEF, it does not have to (nor is able to) emulate the CEF ASIC circuitry whose design is most probably protected and not documented publicly.

Regarding the InverseARP interval, well, I am slightly surprised that changing the interval using the command frame-relay inverse-arp interval did not have any effect. Can you make yet one more experiment and put the entire configuration on your Serial0/0 interface only? Let's remove those subinterfaces and have all the configuration put together on the physical interface.

Regarding the CCIE R&S Certification Guide quote - yes, that is true but it is slightly open to interpretation. After you bring up your serial interface, it will request the full status report from the nearest FR switch. After you receive the reply together with the individual DLCIs and their status, you know which DLCIs are being switched to you and whether they are operational. Afterwards, you known through which DLCIs you can send your InverseARP Request and expect an answer. So it is logical to send the InverseARP Request after you receive your first full status report, and you can say that its arrival has triggered the InverseARP. But what is not clear from the description is whether this repeats every time the full status report is received or only the first time you brought up the interface. Actually, the full status report shall be received every 60 seconds so also the InverseARP messages should be sent every 60 seconds which is clearly not your case. And as you have confirmed yourself, changing the keepalive time did not have any effect on the InverseARP interval so it really seems that the LMI Status Enquiry Response triggers the InverseARP only the first time after the interface is brought up (or after a new DLCI is declared operational).

Please do not apologize for anything. Sometimes, the most trivial-looking technical details can prove to be most confusing in their explanation, and this discussion is very much welcome. We all enjoy discussing these issues with you - please, come back any time with any questions you might have. We both learn by discussing.

Best regards,

Peter