Home > Frame Relay Point-to-Point SubInterface GNS3 Lab

Frame Relay Point-to-Point SubInterface GNS3 Lab

April 30th, 2013 in Guide Go to comments

In this lab we will try to run a Frame Relay topology same as the one posted in TSHOOT demo ticket. The logical and physical topologies of this lab are shown below:

Logical topology:


Tasks in this lab:

+ Configure static mappings on R1 and R4.
+ Configure point-to-point subinterface on R2 & R3.
+ All routers must be able to ping themselves.

Physical topology:


IOS used in this lab: c3640-jk9s-mz.124-16.bin

We will use a router (R5) to simulate the Frame Relay switch instead of using a Frame Relay Switch in GNS3. First we will configure the Frame Relay switch with the DLCIs shown above. In fact the DLCIs in the topology are not very logical, especially DLCIs 304 & 403 for the links between R1 & R2, but well… let’s configure them.

Note: If you are not sure about Frame Relay theory, please read my Frame Relay tutorial first.


Configure Frame Relay Switch:

We should change the name of R5 to FRSW (Frame Relay Switch).

R5(config)#hostname FRSW

The very first command to turn on the frame relay switching feature on FRSW:

FRSW(config)#frame-relay switching

FRSW(config)#int s0/0
FRSW(config-if)#encapsulation frame-relay
FRSW(config-if)#frame-relay intf-type dce
FRSW(config-if)#clock rate 64000
FRSW(config-if)#frame-relay route 403 interface serial 0/1 304
FRSW(config-if)#no shutdown
FRSW(config)#int s0/1
FRSW(config-if)#encapsulation frame-relay
FRSW(config-if)#frame-relay intf-type dce
FRSW(config-if)#clock rate 64000
FRSW(config-if)#frame-relay route 304 interface serial 0/0 403
FRSW(config-if)#frame-relay route 302 interface serial 0/2 203
FRSW(config-if)#no shutdown
FRSW(config)#int s0/2
FRSW(config-if)#encapsulation frame-relay
FRSW(config-if)#frame-relay intf-type dce
FRSW(config-if)#clock rate 64000
FRSW(config-if)#frame-relay route 203 interface serial 0/1 302
FRSW(config-if)#frame-relay route 201 interface serial 0/3 102
FRSW(config-if)#no shutdown

FRSW(config)#int s0/3
FRSW(config-if)#encapsulation frame-relay
FRSW(config-if)#frame-relay intf-type dce
FRSW(config-if)#clock rate 64000
FRSW(config-if)#frame-relay route 102 interface serial 0/2 201
FRSW(config-if)#no shutdown

+ The frame-relay intf-type dce command specifies the interface to handle LMI like a Frame Relay DCE device. This command also enables FRSW to function as a switch connected to a router. And the clock rate is necessary on the DCE end of the connection so we have to put it here (but in fact not all IOS versions require this, you can check or verify the DCE and clock rate with the show controller serial x/y command).

+ The frame-relay route 403 interface serial 0/1 304 command means frame-relay traffic comes to FRSW which has a DLCI of 403 will be sent to interface Serial0/1 with a DLCI of 304.

Also please notice that there is no IP address configured on the Frame Relay Switch.

We can verify the configuration of the FRSW with show frame-relay route command:


Note: The output above is taken after all routers have been configured so if you do this command in your lab at this moment the Status would be Inactive because you have not turned on the Serial interfaces on R1, R2, R3, R4.

Configure R1, R2, R3 and R4:

First I show all the configuration but you should type them manually to see how it works instead of pasting all of them at the same time.

interface s0/0
ip address
encapsulation frame-relay
no frame-relay inverse-arp
frame-relay map ip 403 broadcast
frame-relay map ip 403
no shutdown
(good to explain first broadcast: https://learningnetwork.cisco.com/thread/35698)
interface Serial0/0
no ip address
encapsulation frame-relay
no shutdown
interface Serial0/0.12 point-to-point
description Link to R1
ip address
frame-relay interface-dlci 304
interface Serial0/0.23 point-to-point
description Link to R3
ip address
frame-relay interface-dlci 302
interface Serial0/0
no ip address
encapsulation frame-relay
no frame-relay inverse-arp
no shutdown
interface Serial0/0.23 point-to-point
description Link to R2
ip address
frame-relay interface-dlci 203
interface Serial0/0.34 point-to-point
description Link to R4
ip address
frame-relay interface-dlci 201
interface Serial0/0
description Link to R3
ip address
encapsulation frame-relay
frame-relay map ip 102 broadcast
frame-relay map ip 102
no frame-relay inverse-arp
no shutdown

There are somethings I wish to explain. For example on R1 under interface s0/0 we see the command:

frame-relay map ip 403 broadcast

The frame-relay map command performs static addressing mapping and it disables Inverse ARP on the specified DLCI. This command is supported on the physical interface and it should be used when the far end Frame Relay device does not support Inverse ARP. If we choose to disable Inverse ARP, we must perform a static mapping of L2 to L3, as well as associate the DLCI to the interface.

The IP address is the IP address of R1 itself so why do we need this command? The answer is: without this command, you cannot ping from R1 to itself (ping to it own IP address may be a lab requirement, a fun test…) because that IP address does not exist in the Frame Relay map table and Frame Relay does not know which DLCI it should use to send the frames to this destination. You can check this with the “debug frame-relay packet” command to see the error Serial0/0:Encaps failed–no map entry link 7(IP). By adding a static map to the DLCI used for a neighbor, when we ping to itself, the router will send ICMP to that neighbor and the neighbor will reply back to R1.

Now let’s discuss about the broadcast keyword in the above command. First, please notice that the “broadcast” keyword here is used for both multicast and broadcast traffic. By default, Frame Relay is a non-broadcast multiple access (NBMA) network and does not support broadcast or multicast traffic. So without the broadcast keyword, dynamic routing protocols such as EIGRP, OSPF and RIPv2 would not be able to advertise multicast route updates over the corresponding DLCI. Therefore we should always add this keyword in the “frame-relay map” command. But remember this: we only use one broadcast keyword for each DLCI regardless how many IP addresses are used along with. So the commands below:

frame-relay map ip 403 broadcast
frame-relay map ip 403

are same as:

frame-relay map ip 403
frame-relay map ip 403 broadcast

You should never use more then one broadcast keyword for one DLCI like this:

frame-relay map ip 403 broadcast
frame-relay map ip 403 broadcast

or you will end up with multiple copies of the packets being transported and received.

Configuring static map statements (like frame-relay map ip command) automatically disables Inverse ARP so in the configuration of R1, the no frame-relay inverse-arp command is in fact not necessary.

Note: Physical interfaces have Inverse ARP enabled by default

That is all explanation for R1. Next we will discuss about the configuration of R2 and R3 (they are very identical). Under subinterface (like Serial0/0.12 point-to-point on R2) we see the command:

frame-relay interface-dlci 304

We notice that in this command only the DLCI is specified and this command just associates the DLCI with the subinterface. This is because point-to-point network only connects with one remote destination. Therefore this command is mostly used under point-to-point subinterface (but it can be still used on physical interface although it has no effect because all unassigned DLCIs belong to that physical interface by default). On point-to-point subinterface, Inverse ARP requests are not sent out regardless if it is enabled on the physical interface or not. It is also not required to enable or disable Inverse ARP, because there is only a single remote destination on a PVC and discovery is not necessary. Also notice that the frame-relay map command is not allowed on a point-to-point subinterface.

Note: Using subinterface can avoid the split-horizon problem.

We can check which type of mapping was configured with the command “show frame-relay map”:

+ Dynamic means the mapping was done using Inverse ARP.
+ Static means the mapping was done manually.

For example on R1 static mapping is being used:


Let’s check R2:


Hmm, on R2 we don’t see the word “static” or “dynamic”. There are some confusions about the “frame-relay interface-dlci” command if it belongs to dynamic mapping or static mapping. But there is an opinion saying that point-to-point does not use the principle of static or dynamic mapping so it is not listed here. Well, the decision is yours.

Also you can notice that no Layer 3 addresses are shown in above command.

On the “show frame-relay map” outputs above you can see the Frame Relay’s statuses are all active. There are 4 PVC statuses:

+ Active: Both sides of the PVC are up and communicating.
+ Inactive: Local router received status about the DLCI from the frame-switch, the other side is down.
+ Deleted: Indicates a local config problem. The frame-switch has no such mapping and responded with a “deleted message”.
+ Static: Indicates that LMI was turned off with the “no keepalives”.

The outputs of the show frame-relay map command on R3 & R4 are very identical to R1 & R2, I also post here just for your reference:



That’s all I wish to explain, let’s check if the pings work…





So all the pings to the neighbors are working. On R1 you can try pinging itself and it will successful too. If you disable the frame-relay map ip 403 broadcast command (use no frame-relay map ip 403 broadcast), R1 cannot ping itself anymore:


In this Frame Relay lab we only set path for adjacent routers. We can’t ping between R1 to R3 for example. There are two solutions so that R1 can ping R3:

+ Use multipoint subinterfaces on R2 (disable Inverse ARP and set two static frame-relay mappings on both R1 and R3)
+ Enable a routing protocol (static routing, EIGRP, OSPF, RIP…)

The GNS3 initial and final configs can be downloaded here:

Initial Configs:http://www.networktut.com/download/Frame_Relay_TSHOOT_demo_initial.zip
Final Configs: http://www.networktut.com/download/Frame_Relay_TSHOOT_demo_finalConfigs.zip


Some good references:


Next recommended reading: EIGRP over Frame Relay and EIGRP Redistribute Lab

Comments (23) Comments
  1. izakmp
    April 20th, 2013

    wow! kudos to the person who made this. It’s exactly the same topology and configuration i used in re-enacting jeremy’s nbma topology for ccnp route. it’s really a great thing that you configure your own frame relay switch than just using the builtin device in GNS3. I’ll be using this again in practicing for CCIE BGP Lab.

  2. ONIS
    June 26th, 2013

    Well work :)

  3. Makdum
    June 28th, 2013

    Awsome stuff . thanx for the help

  4. Kenji
    June 30th, 2013

    I’m trying same configuration on GNS3, but I cannot make it.
    It is strange problem that more than two routers are in operational then all routers cannot establish neighboring. R1-R2, R2-R3 or R3-R4 are OK. But, R1-R2-R3-R4, R1-R2-R3 or R2-R3-R4 are not!!
    Does your config work with 4 routes in same time? I put FR switch both CISCO router or built in FR switch. I also tried on Core i7 memory 8GB platform. And I tried 2691 and 3640. Every combinations do not work!!

  5. ravi
    August 4th, 2013

    @ kenji,
    just follow the above shown,u’ll be ok, i’m also using core i9, memory 32GB,8GB video,100TB HDD….blah blah

    u need a routing protocol to ping between R1 and R3 or as said above use use point to multipoint sub-intf with static mapping to others

  6. joiyukigj
    October 16th, 2013

    Thank you very much for ((url.mn/h/5a9ca34)) I got passed in my 200-120 exam today .Thanks for providing the latest dump.

  7. carlson
    January 10th, 2014

    hello, please i need help here. how can i download this simulation so that i can practice it using GNS3?

  8. networktut
    January 11th, 2014

    @carlson: Just click on the link (at the bottom of lab on this page) to download it, unzip it and then open it with GNS3.

  9. K@mlesh
    January 29th, 2014

    Wow Awsome stuff ..Great Help…..Keep it UP

  10. fgb
    March 12th, 2014

    Pls, can someone tell me how to get Jeremy’s tshoot vedios?..URGENT PLEASE…

  11. fgb
    March 26th, 2014

    Pls guys, still waiting for ur response on jeremy’s tshoot vedios ..

  12. Anonymous
    April 3rd, 2014


    use google or download it through torrent

  13. carlson
    April 30th, 2014

    ok thanks i would do that

  14. VomitosArcaz
    May 22nd, 2014

    Hi mates!!

    I want to prepare this exam and I have this dumps:

    -74 Cisco.ActualTests.642-832.v2013-04-29.by.Igor.70q
    -33 Cisco.Certkey.642-832.v2014-01-24.by.Toni.14q

    Which is the valid dump?


    May 22nd, 2014

    74 Cisco.ActualTests.642-832.v2013-04-29.by.Igor.70q ONLY!!!

  16. Msizi
    June 17th, 2014

    Guys, what would cause my below routes to be stuck on inactive?

    FRAME_SW#sh frame-relay route
    Input Intf Input Dlci Output Intf Output Dlci Status
    Serial0/0 403 Serial0/1 304 active
    Serial0/1 302 Serial0/2 203 active
    Serial0/1 304 Serial0/0 403 active
    Serial0/2 201 Serial0/3 102 inactive
    Serial0/2 203 Serial0/1 302 inactive
    Serial0/3 102 Serial0/2 201 inactive

  17. Azeem
    July 23rd, 2014

    Can anyone please send me valid dums and tickets of T-shott.
    I will be really thankful to him


  18. isaiah
    September 8th, 2014

    please can you explain this command – frame-relay route 403 interface serial 0/1 304. I seem not to understand the command. the grammar makes me confused. thanks.

  19. jackPip
    January 13th, 2015

    First install the version vce simulator 1.1.7 and then you replace the files with the crack of vce 1.1.6. Thus you can open all vce.

  20. ME@here.com
    March 10th, 2015

    Msizi : your question is a GREAT one…as it covers about 10 practice questions in the CCIE level.

    The issue is either A. you forgot that FR is NBMA and for dynamic Routing to work over them…THERE ARE SPECIFIC SETTINGS to cause them to NOT broadcast (multi-cast) routing advertisements. it requires you to create fixed Neighbors in certain circumstances…read up on how OSPF and EIGRP need special considerations in NBMA networks.

    B. I see often mention of MTU being an underlying cause…..I doubt you f’d with the MT or MSS on these routers / switch-router….but one never knows….maybe you did and did not know you did.

    C. GOOGLE it for an hour or two…the answers to these kinds of questions are EVERYWHERE!

  21. Anonymous
    May 15th, 2016

    thunks for ever
    cont…like this

  22. Krimo
    June 8th, 2016

    Can anyone send me the dumps at krimlakh @ hotmail . com

    Thanks in advance

  23. diego
    July 20th, 2016

    is this lab in the real tshoot exam? i mean is it one of the ticket?