How to configure Frame-Relay Point-to-Multipoint

This time we’ll take a look at the configuration of frame-relay point-to-multipoint. If you have no idea what frame-relay is or what a PVC, DLCI or LMI is you should start with my introduction to frame-relay first. Having said that let’s have some fun with frame-relay! This is the topology we’ll use:

frame relay hub and spoke lab

Above is the topology that we’ll use. 3 routers in a hub and spoke model. There are two PVCs and you can see the DLCI numbers in the picture. I’m using a single subnet (192.168.123.0 /24) so we will start with frame-relay point-to-multipoint.

Configuring a frame-relay switch is outside the scope of the CCNA, CCNP and even the CCIE exam. If you use GNS3 you can use the simple-to-configure frame-relay switch emulator.

Let’s prepare the interfaces:

Hub(config)#interface serial 0/0
Hub(config-if)#encapsulation frame-relay
Spoke1(config)#interface serial 0/0
Spoke1(config-if)#encapsulation frame-relay
Spoke2(config)#interface serial 0/0
Spoke2(config-if)#encapsulation frame-relay

We’ll change the encapsulation type to frame-relay for all interfaces. Let’s verify if our PVCs are working first:

Hub#show frame-relay pvc   

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          2            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0

  input pkts 12            output pkts 11           in bytes 1108      
  out bytes 1074           dropped pkts 0           in pkts dropped 0         
  out pkts dropped 0                out bytes dropped 0         
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0         
  out BECN pkts 0          in DE pkts 0             out DE pkts 0         
  out bcast pkts 1         out bcast bytes 34        
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 00:15:37, last time pvc status changed 00:15:37

DLCI = 103, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0

  input pkts 12            output pkts 11           in bytes 1108      
  out bytes 1074           dropped pkts 0           in pkts dropped 0         
  out pkts dropped 0                out bytes dropped 0         
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0         
  out BECN pkts 0          in DE pkts 0             out DE pkts 0         
  out bcast pkts 1         out bcast bytes 34        
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 00:15:41, last time pvc status changed 00:15:41

The show frame-relay pvc command tells us that the PVCs are active. You can also see the DLCI numbers this way. This tells us that layer 2 of our frame-relay is working. In case of trouble it might be a good idea to verify LMI:

Hub#show frame-relay lmi 

LMI Statistics for interface Serial0/0 (Frame Relay DTE) LMI TYPE = ANSI
  Invalid Unnumbered info 0		Invalid Prot Disc 0
  Invalid dummy Call Ref 0		Invalid Msg Type 0
  Invalid Status Message 0		Invalid Lock Shift 0
  Invalid Information ID 0		Invalid Report IE Len 0
  Invalid Report Request 0		Invalid Keep IE Len 0
  Num Status Enq. Sent 147		Num Status msgs Rcvd 148
  Num Update Status Rcvd 0		Num Status Timeouts 0
  Last Full Status Req 00:00:35		Last Full Status Rcvd 00:00:35

Use show frame-relay lmi to see the LMI information. It tells us that we are currently using the ANSI type. It doesn’t matter which one you use as long as it’s the same on all routers.

Since layer 2 is working we’ll configure some IP addresses and see if we can get layer 3 working:

Hub(config)#interface serial 0/0
Hub(config-if)#ip address 192.168.123.1
Spoke1(config)#interface serial 0/0
Spoke1(config-if)#ip address 192.168.123.2
Spoke2(config)#interface serial 0/0
Spoke2(config-if)#ip address 192.168.123.3

Let’s see if we can reach the other side:

Hub#ping 192.168.123.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.123.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/8/24 ms
Hub#ping 192.168.123.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.123.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/8 ms

As you can see the hub router can reach both spoke routers. This is because Inverse ARP is enabled by default.

We can check the frame-relay maps to confirm this:

Hub#show frame-relay map 
Serial0/0 (up): ip 192.168.123.2 dlci 102(0x66,0x1860), dynamic,
              broadcast,, status defined, active
Serial0/0 (up): ip 192.168.123.3 dlci 103(0x67,0x1870), dynamic,
              broadcast,, status defined, active
Spoke1#show frame-relay map 
Serial0/0 (up): ip 192.168.123.1 dlci 201(0xC9,0x3090), dynamic,
              broadcast,, status defined, active
Spoke2#show frame-relay map 
Serial0/0 (up): ip 192.168.123.1 dlci 301(0x12D,0x48D0), dynamic,
              broadcast,, status defined, active

Above you see the mappings between the IP address and the DLCI number. There are two other interesting things to see here. The keyword dynamic means that the entry was learned because of inverse ARP. The keyword broadcast means that we can send broadcast or multicast through our PVC.

Configurations

Want to take a look for yourself? Here you will find the configuration of each device.

Hub

hostname Hub
!
interface Serial0/0
 ip address 192.168.123.1 255.255.255.0
 encapsulation frame-relay
!
end

Spoke1

hostname Spoke1
!
interface Serial0/0
 ip address 192.168.123.2 255.255.255.0
 encapsulation frame-relay
!
end

Spoke2

hostname Spoke2
!
interface Serial0/0
 ip address 192.168.123.3 255.255.255.0
 encapsulation frame-relay
!
end


Let’s disable Inverse ARP and create some mappings ourselves:
We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 651 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

567 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Forum Replies

  1. many thanks for the article; however the spoke-spoke mappings at the end of the article are not correct and we need a new DLCI mapping other than the one already used

    If I use the mappings defined here, when pinging from Spoke1-Spoke2 (and vice verca) I get UUUUU. Changing the mappings to 2:221-3:321 on the switch and the spoke configs solved the problem

    Spoke1 - frame-relay map ip 192.168.123.3 221
    Spoke 2 - frame-relay map ip 192.168.123.2 321

  2. Hi,

    Here is my configuration

    **R2-spoke2**
    -----
    interface Serial2/2
    ip address 192.168.123.2 255.255.255.0
    encapsulation frame-relay
    serial restart-delay 0

    **R1-hub**

    interface Serial2/1
     ip address 192.168.123.1 255.255.255.0
     encapsulation frame-relay
     serial restart-delay 0
    

    ---

    **R3-SPOKE2**

    interface Serial2/3
     ip address 192.168.123.3 255.255.255.0
     encapsulation frame-relay
     serial restart-delay 0
    !
    

    **FR-switch**
    -----
    interface Serial2/1
    description R1
    no ip address
    encapsulation frame-relay
    serial restart-delay 0
    frame-relay intf-type dce
    frame-relay

    ... Continue reading in our forum

  3. Disregard. Thanks. I figured out what I did wrong.

  4. Hello Sergei

    There are several ways to get a Frame Relay PVC working correctly. One is to use the frame-relay interface-dlci 102 command. However, this would not apply here as it is only used on subinterfaces. It is not common to use, although it does have its uses. When applied, it will assign a DLCI to the subinterface. When the subinterface already has a DLCI assigned and an IP address has been configured on it, Inverse-ARP requests can now be sent to acquire the IP addresses of the neighbor devices.

    Alternatively, the command used on the subinterfaces i

    ... Continue reading in our forum

  5. Hello Sergei

    Sorry Sergei, what I mentioned in the previous post was not entirely correct. Let me clarify:

    When configuring point to point Frame Relay with subinterfaces, you can use the following command:

    frame-relay interface-dlci XXX

    This command configures the DLCI of the subinterface. It also keeps Inverse ARP active to be able to find the DLCI of the other end of the circuit, assuming the IP address has also been configured on the subinterface. Now this command is typically used for subinterfaces, but can also be applied to the main physical interfaces

    ... Continue reading in our forum

37 more replies! Ask a question or join the discussion by visiting our Community Forum