Frame Relay Overview
Objective:
- Describe different methods for connecting to a WAN
Frame Relay is by far the most conceptually complex topic in the CCNA-level material. Much as with subnetting, though, after you get it, you’ll think it’s the greatest thing since sliced bread. However, until you get to that point, you’ll probably think people that use Frame Relay are insane. Unfortunately (or fortunately, depending on your perspective), Frame Relay is one of the more popular WAN connection types in use in production networks. It offers the high speed demanded by the networks of today at cut-rate prices that managers love. Frame Relay connections work quite differently than the typical WAN connections discussed thus far.
Rather than have a single connection from a location to another location (also known as point-to-point), you might have a connection going from one location to five other locations out a single, physical serial interface. You start to get the feel that this is an ethernet-style connection where any device connected to a hub can reach any other device plugged into the same hub. Depending on your Frame Relay configuration, this may not be far from the truth. Rather than connect sites together through individual physical interfaces, Frame Relay connects sites together with virtual circuits.
Virtual Circuits
Objective:
- Describe different methods for connecting to a WAN
Virtual circuits are logical links through service provider networks that give routers the impression that they are linked directly together. Take a look at Figure 23.1. You have a router on each side of the service provider cloud, connected through a virtual circuit, signified by a dotted line through the cloud. These routers believe they are connected directly together (as if the cloud weren’t there). You could even do a traceroute command between these routers and it would show only a single hop. However, if you peeled back that cloud, you would find that these routers are nowhere near directly connected.
They would be going through many service provider routers, through many different networks. Truth be told, the technology underneath that Frame Relay cloud probably isn’t even Frame Relay. When a frame gets sent through that cloud, its headers are most likely stripped and replaced many times; it’s shaken, stirred, and spun around. But by the time it reaches the other end of the virtual circuit, the original Frame Relay headers are placed back on and a dazed and confused packet walks out of the cloud reporting that it traveled only a single hop between the source and the destination. For now, it’s best to say that what happens in the cloud, stays in the cloud. Unless you’re a service provider, this is how most network administrators prefer to leave it.
Although you aren’t concerned with what happens within the cloud, you do need to understand the circuits that ride over the cloud. These virtual circuits define the devices you are able to reach. The more virtual circuits you purchase to connect your various locations, the more redundant the connections will be; at the same time, the monthly cost will rise significantly. Therefore, there are three major design strategies to provisioning Frame Relay virtual circuits.
Hub and Spoke Design
Every network looks for cost efficiency. Redundancy is often sacrificed on the altar of monthly cost. Thus, the hub and spoke Frame Relay network design is one of the more common. In this configuration, you pick a centralized location (most likely, your largest, most connected office) as the “hub” of the network. All other locations are considered “spokes” and have a single virtual circuit connection back to the hub. Figure 23.2 gives a visual of what this looks like.
Initially, it appears as though the spoke offices will be unable to reach each other. However, you can configure them to traverse through the hub location if they ever need to communicate. Typically, in this network design, the spoke offices rarely communicate with each other.
Rather, they access servers, store information, send email, and so on through the hub office. The major advantage of this configuration is the cost. It offers the cheapest monthly price tag, which cost-cutting corporations enjoy. The disadvantages are beginning to mount against this design, however. The redundancy is sorely lacking. If a single router (the central router) loses connectivity for any reason (if the router crashes, if a trenching company cuts through the line), your entire WAN goes down. The other disadvantage of this design is beginning to eclipse even redundancy.
It is the disadvantage of tandem switching. Any time the spoke offices need to reach each other, they must go through the hub office. This is considered a tandem switch. Tandem switching takes time and adds delay for the end-to-end connection. Up until modern times, this was no big deal; file transfers between spoke offices would just move a little slower. One technology has pushed tandem switching from a priority level of “No big deal” to “Heaven help us, the sky is falling.” That technology is Voice over IP (VoIP).
VoIP technology involves moving the telephone system from running on its own network to using the data network as a backbone for communication. VoIP has very strict delay requirements that can be easily exceeded anytime sources of delay (such as a tandem switch) are introduced. Now, anytime employees working in the spoke offices call each other (which happens quite a bit more frequently than file transfer), the call quality may sound like a bad cell phone call. Therefore, most companies that are looking to move into a VoIP environment typically redesign their Frame Relay network to minimize the number of tandem switches that occur.
Partial Mesh Design
You can think of the partial mesh Frame Relay design as the compromise between network administrators and cost-saving managers. In this configuration, key sites have redundant virtual circuit connections through the cloud, as shown in Figure 23.3.
FIGURE 23.3 Partial mesh Frame Relay design.
This gives them a level of redundancy and minimizes the number of tandem switches required for them to communicate. Less critical locations have fewer virtual circuit connections, which keeps the cost lower.
Full Mesh Design
If the partial mesh design is a compromise between the network administrators and managers, then the full mesh design implies that the network administrators won. This design is every Cisco network administrator’s picture of perfection over a Frame Relay cloud. It gives every site a direct virtual circuit to every other site, as shown in Figure 23.4. This design gives maximum redundancy and minimum packet latency (latency describes how long it takes a packet to reach each location). Of course, this type of service comes at a cost, the highest cost of all Frame Relay network designs.
