Addressing Is Much More Interesting on Frame Relay Than on Serial Links

Addressing Is Much More Interesting on Frame Relay Than on Serial Links The last big concept I'll cover for Frame Relay relates to a dilemma that should be familiar because it happens with Ethernet as well. When R1 needs to build the Frame Relay header, it must put something in the DLCI field102 in this most recent example. You know that R1 should use DLCI 102 because that's what the telco told you would work. The router, however, doesn't have a copy of the documentation from the Frame Relay provider, so it needs more help. To see why, take a close look at the routing table entry for subnet 150.1.3.0 in Figure 15-8. Note that it lists next-hop router of 150.1.2.2, which is R2's IP address, and outgoing interface S0. It does not list which DLCI to use to get to 150.1.2.2. R1 knows the outgoing interface and the next-hop IP address, but it doesn't know which DLCI to use. If there were an Ethernet between R1 and R2, and R1 was faced with this same dilemma, R1 would use IP ARP. R1 would send an IP ARP broadcast that listed the next-hop IP address (150.1.2.2), expecting that R2 would hear the broadcast and send an ARP reply. The reply would include R2's Ethernet MAC address. Frame Relay solves the same problem, but in a different way. As soon as the PVC starts working, R2 announces its IP address to R1, using the VC between the two routers. R1 also announces its IP address to R2, using that same VC. By doing so, both routers learn the other router's IP address that is used on that VC. The message used to announce the IP address and DLCI is called an Inverse ARP message. An Inverse ARP is like an ARP, in that it helps you correlate an IP address to a data link address, but it's different in terms of how the process works. To distinguish between the two, the Frame Relay version uses the word "inverse" in the name.