How to configure Frame-Relay

Point-to-Multipoint

Posted on February 19, 2013

by Rene Molenaar
in CCNA R&S, Cisco, Frame-Relay
This time well take a look at the configuration of frame-relay point-to-multipoint. If you have no idea what framerelay is or what a PVC, DLCI or LMI is you should start with my introduction to frame-relay first. Having said that
lets have some fun with frame-relay! This is the topology well use:

Above is the topology that well use. 3 routers in a hub and spoke model. There are two PVCs and you can see the
DLCI numbers in the picture. Im using a single subnet (192.168.123.0 /24) so we will start with frame-relay pointto-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.
Lets 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

Well change the encapsulation type to frame-relay for all interfaces. Lets verify if our PVCs are working first:

Hub#show frame-relay pvc

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

Active
2
0
0

Inactive
0
0
0

Deleted
0
0
0

Static
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
doesnt matter which one you use as long as its the same on all routers.
Since layer 2 is working well 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
Lets 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
broadcast,, status
Serial0/0 (up): ip 192.168.123.3
broadcast,, status
Spoke1#show frame-relay map
Serial0/0 (up): ip 192.168.123.1
broadcast,, status
Spoke2#show frame-relay map
Serial0/0 (up): ip 192.168.123.1
broadcast,, status

dlci 102(0x66,0x1860), dynamic,

defined, active
dlci 103(0x67,0x1870), dynamic,
defined, active
dlci 201(0xC9,0x3090), dynamic,
defined, active
dlci 301(0x12D,0x48D0), dynamic,
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. Lets disable Inverse ARP and
create some mappings ourselves:
Hub(config)#interface serial 0/0
Hub(config-if)#no frame-relay inverse-arp
Spoke1(config)#interface serial 0/0
Spoke1(config-if)#no frame-relay inverse-arp
Spoke2(config)#interface serial 0/0
Spoke2(config-if)#no frame-relay inverse-arp
Use no frame-relay inverse-arp to disable it.
Hub#clear frame-relay inarp

Spoke1#clear frame-relay inarp

Spoke2#clear frame-relay inarp
And well use clear frame-relay inarp to get rid of the current frame-relay maps that were created using inverse
ARP.
Youll see that connectivity is now impossible:

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 0 percent (0/5)
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 0 percent (0/5)
The router has no idea where to send its IP packets to since we dont have any frame-relay maps.
Lets create them ourselves:

Hub(config)#interface serial 0/0

Hub(config-if)#frame-relay map ip 192.168.123.2 102 broadcast
Hub(config-if)#frame-relay map ip 192.168.123.3 103 broadcast
Spoke1(config)#interface serial 0/0
Spoke1(config-if)#frame-relay map ip 192.168.123.1 201
Spoke2(config)#interface serial 0/0
Spoke2(config-if)#frame-relay map ip 192.168.123.1 301
Use the frame-relay map command to map the IP address of your neighbor to your own DLCI number. The
keyword broadcast is optional. We require it on the hub router if you want to run a routing protocol like RIP, OSPF
or EIGRP over your frame-relay network.
Routing protocols like OSPF, EIGRP or RIPv2 use multicast so thats why you require the broadcast keyword. Its
also possible to configure these routing protocols to use unicast traffic using the neighbor command in your RIP,
OSPF or EIGRP configuration.
Lets see if we have any frame-relay maps now:

Hub#show frame-relay map

Serial0/0 (up): ip 192.168.123.2 dlci 102(0x66,0x1860), static,
broadcast,
CISCO, status defined, active
Serial0/0 (up): ip 192.168.123.3 dlci 103(0x67,0x1870), static,
broadcast,
CISCO, status defined, active
Above you can see that they are still there. The word static tells us that this is a frame-relay map that we configured
ourselves.
So can we ping again now?

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
No issues heregreat! So now you have seen how to configure frame-relay point-to-multipoint, how to check
PVCs, LMI and the frame-relay maps with or without Inverse ARP.
I showed you this using the physical interfaces but we can also use sub-interfaces, let me show you how this works:

Hub(config)#default interface serial 0/0

Building configuration...
Interface Serial0/0 set to default configuration
Spoke1(config)#default interface serial 0/0
Building configuration...
Interface Serial0/0 set to default configuration
Spoke2(config)#default interface serial 0/0
Building configuration...
Interface Serial0/0 set to default configuration
The default interface command is nice to reset your interface configuration. Now lets configure 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
On the physical interfaces I still have to configure that we are using frame-relay.
Now I can create sub-interfaces:

Hub(config)#interface serial 0/0.123 multipoint

Hub(config-subif)#ip address 192.168.123.1 255.255.255.0
Hub(config-subif)#frame-relay map ip 192.168.123.2 102 broadcast
Hub(config-subif)#frame-relay map ip 192.168.123.3 103 broadcast
Spoke1(config)#interface serial 0/0.201 multipoint
Spoke1(config-subif)#ip address 192.168.123.2 255.255.255.0
Spoke1(config-subif)#frame-relay map ip 192.168.123.1 201

Spoke2(config)#interface serial 0/0.301 multipoint

Spoke2(config-subif)#ip address 192.168.123.3 255.255.255.0
Spoke2(config-subif)#frame-relay map ip 192.168.123.1 301
You can use any sub-interface number you want. I like to use the DLCI number for the sub-interface number but I
cant do this on the hub router since it has two DLCI numbers. Theres no way for your router to tell which DLCI
number belongs to which sub-interface so we need to tell it using the frame-relay map command.
So does our configuration work? Lets send a ping

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
Excellent this is working! Are you following me so far?
Next step is to configure a distance vector routing protocol so I can demonstrate how to deal with split-horizon. Ill
use RIP but you can also use EIGRP:

Hub(config)#router rip
Hub(config-router)#no auto-summary
Hub(config-router)#version 2
Hub(config-router)#network 192.168.123.0
Spoke1(config)#interface loopback 0
Spoke1(config-if)#ip address 2.2.2.2 255.255.255.0
Spoke1(config)#router rip
Spoke1(config-router)#version 2
Spoke1(config-router)#no auto-summary
Spoke1(config-router)#network 192.168.123.0
Spoke1(config-router)#network 2.0.0.0
Spoke2(config)#router rip
Spoke2(config-router)#version 2
Spoke2(config-router)#no auto-summary
Spoke2(config-router)#network 192.168.123.0
As you can see I have enabled RIP version 2 and created a loopback interface on router Spoke1 so that we have
something to advertise. Lets take a look at our routing tables:

Hub#show ip route rip

2.0.0.0/24 is subnetted, 1 subnets
R
2.2.2.0 [120/1] via 192.168.123.2, 00:00:09, Serial0/0.123

The hub router has learned network 2.2.2.0 /24 from Spoke1. What about Spoke2?

Spoke2#show ip route rip

Theres nothing there. This is because split horizon on the Hub router is blocking the advertisement.
Lets solve it:

Hub(config)#interface serial 0/0.123

Hub(config-subif)#no ip split-horizon ?
eigrp Enhanced Interior Gateway Routing Protocol (EIGRP)
<cr>
Hub(config-subif)#no ip split-horizon
When Im using RIP you can use no ip split-horizon to disable it. Theres a separate command for EIGRP as you
can see above. Lets check spoke2 again:
Spoke2#show ip route rip
2.0.0.0/24 is subnetted, 1 subnets
R
2.2.2.0 [120/2] via 192.168.123.2, 00:00:03, Serial0/0.301
Problem solved! We can now see the entry in the routing table. So is it reachable?

Spoke2#ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Even though its in the routing table Im unable to ping it. This is happening because the next hop IP address
(192.168.123.2) is unreachable for Spoke2. I only created a frame-relay map to reach the Hub router, not spoke1.
Lets create two additional mappings so that spoke1 and spoke2 can reach each other:

Spoke1(config)#interface serial 0/0.201

Spoke1(config-subif)#frame-relay map ip 192.168.123.3 201
Spoke2(config)#interface serial 0/0.301
Spoke2(config-subif)#frame-relay map ip 192.168.123.2 301
The frame-relay maps above will ensure that the spoke routers can reach each other. Lets try that ping again:

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

Thats all there is to it. You now know how to configure frame-relay point-to-multipoint on physical and subinterfaces. You have also seen how split horizon can cause trouble and how to solve this by disabling split horizon.
In another article well take a look at how to configure frame-relay point-to-point networks.

Read more: http://networklessons.com/frame-relay/how-to-configure-frame-relay-point-tomultipoint/#ixzz3CgJxUYbM