Frame-Relay Basics

In this post we are going to check some of the basics of the CCIE Lab:  the Frame-Relay world. You will find in the CCIE some Frame-Relay configuration for sure, so it worths to spend some time on it, in order to master it.

This is the lab we will follow:

Frame Relay Topology


The router learns through LMI all DLCIs provisioned by the service provider, and these DLCIs are automatically assigned to the main interface if not configured in a different way. We can see this behaviour at R1 by droping the command show frame-relay pvc:

R1#show frame-relay pvc
PVC Statistics for interface Serial0/0 (Frame Relay DTE)
 Active     Inactive      Deleted       Static
 Local          1            0            0            0
 Switched       0            0            0            0
 Unused         1            0            0            0
DLCI = 103, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
...
DLCI = 104, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
...

The first thing we must remember about Frame-Relay is that it’s a technology based on a non-broadcast multi-access (NBMA) media, which means that there is no layer 2 address that maps to all devices in the network.
In Ethernet, for example, we have the address FFFF:FFFF:FFFF that maps to “all the devices connected to the Ethernet segment”. Since there is not a similar address in Frame-Relay, we need some kind of layer 3 to layer 2 resolution in order to get connectivity between multiple layer 2 destinations. This resolution can be performed either manually with the frame-relay map command or automatically through Frame-Relay Inverse-ARP (InARP). When InARP is used, requests are automatically send out all DLCIs learned via LMI, so the other end of the link can reply with its layer 3 address assigned to that DLCI. That way layer 3 to layer 2 resolution is achieved.

R1#show frame-relay map
Serial0/0 (up): ip 100.100.100.3 dlci 103(0x67,0x1870), dynamic,
 broadcast,, status defined, active
Serial0/0 (up): ip 100.100.100.4 dlci 104(0x68,0x1880), dynamic,
 broadcast,, status defined, active
R1#

So we could say that when using the main interfaces, LMI and InARP do all the job and everything goes perfect. Main interfaces work as multipoint interfaces, so via LMI and InARP, a complete mapping is done for the remote IP addresses and the DLCIs in use.
I’d like to recall the difference between point-to-point interfaces and multipoint interfaces. Point-to-point interfaces are used for communication between two devices. In this communication you expect to find only one device on the other side of the link. It’s a one-to-one communication, and anything beyond the other end is reached through the other point of the link. In this kind of interfaces you don’t require layer 3 to layer 2 resolution because there is only one possible layer 2 destination reachable out the link, you just need to know which DLCI to use, and that’s all. In a point-to-point link, both ends should share the same IP subnet (there are some exceptions to this rule, but forget about that by now). An example of point-to-point communications is the old famous “red phone”, between Washington and Moscow. It wasnt necessary to dial any number when Jimmy Carter wanted to talk with the Kremlin, since there was only one person at the other side!
However, a multipoint link represents a communication one-to-many. The end acting as the “one” (usually called the “hub”) needs to know which DLCI is mapped to an specific IP address. The hub shares the same IP subnet with the other ends (usually called “the spokes”), and it uses the same interface to reach all of them, but through different DLCIs. From the spoke’s point of view, the communication is point-to-point, but from the hub’s point of view, it’s multipoint indeed. If we continue with the phone communication example, it’s like when you send at the same time the same sms to two of your contacts (just add two numbers to the field “to:” when sending the sms). In this case, the device is the same one (the phone) but you need to map each of your friends to one phone number. From your friend’s point of view, they have a point-to-point communication with you, but you indeed have a multipoint communication with them (you are “the hub”).

Coming back to our lab, let’s imagine that in the CCIE Lab we get a statement that requires the use of the main interfaces but disabling InARP. In that case, because there is not an automatic mechanism that provide the mapping for IP addresses and DLCIs, we can use static mapping.
Because we are using main interfaces and, by default, they are multipoint interfaces, we need to map every DLCI to every IP address we want to reach:

R1# show run interface ser0/0
 interface Serial0/0
  ip address 100.100.100.1 255.255.255.0
  encapsulation frame-relay
  frame-relay map ip 100.100.100.3 103 broadcast
  frame-relay map ip 100.100.100.4 104 broadcast
  no frame-relay inverse-arp
R1#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 = 103, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
...
DLCI = 104, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
...
R1#
R1#show frame-relay map
Serial0/0 (up): ip 100.100.100.3 dlci 103(0x67,0x1870), static,
              broadcast,
              CISCO, status defined, active
Serial0/0 (up): ip 100.100.100.4 dlci 104(0x68,0x1880), static,
              broadcast,
              CISCO, status defined, active

Now, let’s change a little bit the scenario. Instead of using the main interfaces, we’re going to use subinterfaces, so we reconfigure the routers as follows:

R1(config)#
interface Serial0/0
  no ip address
  encapsulation frame-relay
interface Serial0/0.100 multipoint
  ip address 100.100.100.1 255.255.255.0
R3(config)#
interface Serial0/0
  no ip address
  encapsulation frame-relay
interface Serial0/0.301 multipoint
  ip address 100.100.100.3 255.255.255.0
R4(config)#
interface Serial0/0
  no ip address
  encapsulation frame-relay
interface Serial0/0.401 multipoint
  ip address 100.100.100.4 255.255.255.0

If we check now the commands show frame-relay pvc and show frame-relay map, we’ll get the following results:

R1#sh 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         1            0            0            0
DLCI = 103, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
...
DLCI = 104, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
...
R1#
R1#sh frame-relay map 

R1#

There is no layer 3 to layer 2 resolution! Why is that? As we saw above, LMI assignes PVCs to the main interfaces, not to subinterfaces, so in our case InARP can’t send requests through the DLCIs, because they are assigned to the main interfaces. What can we do? There are two possible solutions for this scenario, depending if we want to keep using dynamip resolution (InARP) or static resolution.

Let’s try first with InARP. As mentioned above, LMI assignes DLCIs to main interfaces, and InARP need to know the DLCIs in order to send request through them. Since we are working with subinterfaces and we want InARP, we can “move” the DLCIs to the subinterfaces with the next configuration (we have to move all the DLCIs needed for the communications):

R1(config)#
interface Serial0/0.100 multipoint
  ip address 100.100.100.1 255.255.255.0
  frame-relay interface-dlci 103
  frame-relay interface-dlci 104
R3(config)#
interface Serial0/0.301 multipoint
  ip address 100.100.100.3 255.255.255.0
  frame-relay interface-dlci 301
R4(config)#
interface Serial0/0.401 multipoint
  ip address 100.100.100.4 255.255.255.0
  frame-relay interface-dlci 401

Doing so, now there is resolution:

R1#sh frame-relay map
Serial0/0.100 (up): ip 100.100.100.3 dlci 103 (0x67,0x1870), dynamic,
              broadcast,, status defined, active
Serial0/0.100 (up): ip 100.100.100.4 dlci 104 (0x68,0x1880), dynamic,
              broadcast,, status defined, active

As you can see, moving the DLCIs to the subinterfaces, InARP can now work properly.

Now let’s try with static resolution (InARP will not be used). Let’s make the following changes (similar config is inserted in R3 and R4):

R1(config)#
interface Serial0/0.100 multipoint
  ip address 100.100.100.1 255.255.255.0
  frame-relay map ip 100.100.100.3 103 broadcast
  frame-relay map ip 100.100.100.4 104 broadcast

If we check the resolution, we are going to see the mappings correctly done:

R1#show frame-relay map
Serial0/0.100 (up): ip 100.100.100.3 dlci 103(0x67,0x1870), static,
              broadcast,
              CISCO, status defined, active
Serial0/0.100 (up): ip 100.100.100.4 dlci 104(0x68,0x1880), static,
              broadcast,
              CISCO, status defined, active

Something that worths to be explained in here: the broadcast keyword. The broadcast key must be configured when doing static mapping in order to encapsulate broadcast and multicast packets over the DLCI. Keep in mind that we are setting up the Layer 2 network, and on the top there will be a Layer 3 IGP. That IGP may, or may not, send multicast or broadcast packets. The thing is that the Frame-Relay solution and the IGP design are very related, so before choosing any solution during the CCIE Lab, read carefully all the sections so you don’t find later any requirement  that may lead you to do some reconfiguration.

We’ve been working with multipoint interfaces and subinterfaces so far. What happens with point-to-point interfaces? As I mentioned above, in point-to-point interfaces it’s not necessary to do a layer 3 to layer 2 mapping, since there is only one device in the other side of the link. When working with point-to-point subinterfaces the only thing we have to do is to “move” the DLCI from the main interface to the subinterface. That’s done with the command frame-relay interface-dlci:

R1(config)#
interface Serial0/0
  ip address 100.100.100.1 255.255.255.0
  encapsulation frame-relay
  frame-relay map ip 100.100.100.3 103 broadcast
  frame-relay map ip 100.100.100.4 104 broadcast
R4(config)#
interface Serial0/0.401 point-to-point
  ip address 100.100.100.4 255.255.255.0
  frame-relay interface-dlci 401
R4#sh frame-relay map
Serial0/0.401 (up): point-to-point dlci, dlci 401(0x191,0x6410), broadcast
          status defined, active
R4#
R4#ping 100.100.100.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.100.100.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/43/88 ms
R4#

As you can see, it doesnt matter if we mix main interfaces, with multipoint subinterfaces, with point-to-point subinterfaces. The thing is to map somehow the DLCIs to the correct interface, and IP addresses to the DLCIs.

Sumarizing:

  • LMI learns all provisioned DLCIs and assigns them to the main interface
  • InARP makes the layer 3 to layer 2 resolution using the DLCIs leart through LMI
  • Main interfaces act as multipoint interfaces (they can work with InARP or with static mapping)
  • When main interfaces are used:
    • By default, InARP works fine (DLCI are assigned to the main interfaces and InARP sends out requests)
    • Static mapping can be done (frame-relay map)
  • When subinterfaces are used:
    • if point-to-point subinterfaces, then it’s necessary to use the command frame-relay interface-dlci
    • if multipoint subinterfaces, then layer 3 to layer 2 resolution is required. This can be achieved dynamically (InARP and
      the command frame-relay interface-dlci) or statically (frame-relay map command).
    • When static mapping is used, it’s necessary to indicate the IP and the DLCI used to reach the IP’s. If broadcast/multicast
      packets can be used, it’s also indicated (keyword “broadcast”)

In following posts we’ll discuss about the conditions that a Frame-Relay architecture imposes on the IGP design.

Stay tuned to our CCIE Blog, folks!!!

Jose Miguel Huertas

Jomi has been working in the networking industry for the last 9 years. Nowadays, he works as a Consultant Engineer at Telindus Spain. He holds the following certifications: CCIE R&S (#27028), CCNP, CCIP and JNCIS. In addition to networking and technological stuff, he loves playing funky music, and he's trying to learn to play trombone (hard stuff, man!!)

More Posts

Creative Commons License
The Frame-Relay Basics by CCIE Blog, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

Tags: , , ,

3 Responses to "Frame-Relay Basics"

  • Arjun says:
  • nikhil says:
Leave a Comment

*

Notify me of followup comments via e-mail. You can also subscribe without commenting.