After trying to start with this for the past few weeks I managed to hit the keyboard for the first lab on the workbook, particularly the one that goes through with creating a FR hub and spoke topology using R1 as hub and R2, 3 and 4 as spokes. This is quite easy imho, on the hub you go like this:


int s1/0
ip add 192.168.234.1 255.255.255.0
encap frame

Since most labs are connected in a full mesh topology the most common thing is that they ask you to disable inverse-arp, hence you also do:


no frame inv

Because inverse-arp is now disabled you will have to go with manual entries to each of the spokes:


 frame-relay map ip 192.168.234.2 102 broadcast
 frame-relay map ip 192.168.234.3 103 broadcast
 frame-relay map ip 192.168.234.4 104 broadcast

Also note that without the broadcast word at the end it will not be possible to run routing protocols on the interface. There’s usually a requirement on vendor workbooks that requires that pings from the router to itself work just as remote ones, for this all that has to be done is to add an entry with any active DLCI pointing to the interface address, this will make your self pings work flawlessly. To finish on the hub all you have to do now is to enable the interface with the “no shutdown” command. So on the hub it ends looking like this:


interface Serial1/0
 ip address 192.168.234.1 255.255.255.0
 encapsulation frame-relay
 frame-relay map ip 192.168.234.1 102
 frame-relay map ip 192.168.234.2 102 broadcast
 frame-relay map ip 192.168.234.3 103 broadcast
 frame-relay map ip 192.168.234.4 104 broadcast
 no frame-relay inverse-arp

Now onto the spokes:


interface Serial1/0
 ip address 192.168.234.2 255.255.255.0
 encapsulation frame-relay
 frame-relay map ip 192.168.234.1 201 broadcast
 frame-relay map ip 192.168.234.2 201
 frame-relay map ip 192.168.234.3 201
 frame-relay map ip 192.168.234.4 201
 no frame-relay inverse-arp

The difference here is that since all communications including from spoke to spoke have to go through the hub the additional maps use the same DLCI, the hub will take care of forwarding the required packets. Note that it is also unnecessary to use the broadcast keyword at the end of every map statement because this will avoid unnecessary broadcast from the spokes, yes, with just one entry with broadcast will be enough to allow your IGP to work appropriately.


R1#ping 192.168.234.2Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.234.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/27/92 ms
R1#ping 192.168.234.1 Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.234.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/30/68 ms
R1#

Troubleshooting + Diagnostics

This is a very straight forward exercise, if you have configured your frame relay cloud appropriately (being GNS3 which is what I’m using or real gear connected with serial cables) and your interfaces are coming up most likely you will see this:


R1#sh frame map
Serial1/0 (up): ip 192.168.234.1 dlci 102(0x66,0x1860), static,
  CISCO, status defined, active
Serial1/0 (up): ip 192.168.234.2 dlci 102(0x66,0x1860), static,
  broadcast,
  CISCO, status defined, active
Serial1/0 (up): ip 192.168.234.3 dlci 103(0x67,0x1870), static,
  broadcast,
  CISCO, status defined, active
Serial1/0 (up): ip 192.168.234.4 dlci 104(0x68,0x1880), static,
  broadcast,
  CISCO, status defined, active

In my old P4 system it takes about a minute for every spoke to become fully functional, if you issue this command and see the inactive status instead of active it means it’s still not ready, it should come up in time. If you see deleted then probably you did not map your DLCIs appropriately, again, verify your frame relay maps on the cloud.