Dial Design Solutions

In the design part of this chapter, some design components remain constant. Dial (in, out, or on-demand) is generally served out of an access server that is connected to the network. Usually, there is an authentication server of some kind to offload the authentication processing from the router, making it centrally manageable.

Design considerations need to also include the backbone architecture. If dial is a component of a remote access solution for your company, it is a small part of the overall network and should tie into the backbone accordingly. Large service provider dial networks should be designed accordingly as well. Going into greater detail is not practical because of the wide variety of existing services. However, the best way to manage dial networks is to use a hub and spoke design. The hub is a gateway that ties the spokes (dial routers) into the backbone. This gateway is usually a Layer 3 switching device.

In cases where the dial routers are just components of a remote access solution, not a large service provider network, it might be appropriate to include all remote access services as spokes behind the hub. These services can include home Frame Relay, ISDN, xDSL, and perhaps Virtual Private Network (VPN). This approach works well because backbone networks change frequently because of the rapid advancements of local-area network/ wide-area network (LAN/WAN) equipment. Remote access devices generally do not increase speeds as dramatically because the WAN piece of remote access solutions is slowly evolving by comparison. An example of the hub and spoke design for an enterprise is shown in Figure 6-1.

Figure 6-1. Hub and Spoke Backbone Design for Remote Access Services, Including Dial, Frame Relay, ISDN, and a xDSL Gateway

Text Dial-In Network

Text-based dial-in networks are generally for support purposes. Typically, modems are attached to the aux port of a router and set up as a console. If you want to add text-based authentication to PPP dial-in services, go to the section, "PPP Dial-In Network."

The text dial-in design used for remote consoles is relatively simple and the architecture only varies slightly from one implementation to the next . Figure 6-2 shows a modem connected to the aux port of a router. In most cases, this is done using a rolled cable and an RJ45 to DB15 connector. The modem is connected to the telephone company by using a POTS line.

Figure 6-2. Text Dial-In Network Used as a Remote Console

PPP Dial-In Network

PPP dial-in networks can vary significantly from situation to situation; however, the hardware and way it is connected into each network is similar in all cases. Each dial-in router has either a number of async interfaces or group -async interfaces and connects back into the network by an Ethernet or a serial connection. To facilitate centrally managed authentication, an authentication server should also exist on the network. If not, local authentication can be configured on the router, but at the cost of not having the service centrally managed, which can also be difficult to maintain.

Figure 6-3 shows an AS5300, an AS5400, or an AS5800 router configured for PPP dial-in. This router has eight Primary Rate Interfaces (PRIs) to the telephone company (telco), which can take in 23 calls each. These PRIs are connected to the Controller T1 ports of the router. The router processes, authenticates, and routes the traffic back into the corporate network through a Fast Ethernet connection. In Figure 6-3, only one PRI is shown; the other seven are connected in exactly the same way.

Figure 6-3. PPP Dial-In Network Diagram of an Access Server Connected to the Telephone Company and the Network

In the case of text-based authentication, the architecture does not change but the configuration changes slightly to allow for text authentication. These configuration changes are noted later in this chapter.

Text Dial-Out Network

Dial-out networks are commonly used for support purposes. They are used in conjunction with routers that are configured for text dial-in as remote consoles, and for access to these routers when their primary links are down. They can also be used as a way to script dial-out for polling pieces of equipment that are attached to modems in any geographic location. This includes using a dial-out system to test the functionality of dial-in servers.

Cisco's Technical Assistance Center (TAC) uses a text-based dial-out service to dial into customer equipment and perform troubleshooting. This is a key resource that the TAC uses and relies upon to do its job daily. This is one way that a TAC can gain access to your equipment.

A text-based dial-out server makes quick connections to modems from a place on the network where an analog line does not exist. The typical user -base of a text-based dial-out server must know modem AT commands, or at least the basic AT commands to dial-out, break, and hang-up.

The network itself is straightforward. You can use the same network as described in the previous section, "PPP Dial-In Network." Figure 6-4 shows an alternate network that you can also use. This figure includes a router with external modems, connected to Async ports through rolled cables, and separate analog lines rather than PRI.

Figure 6-4. Text Dial-Out Network Using a 2500 Series Router and External Modems

PPP Dial-Out Network

Two types of PPP dial-out solutions exist, depending on the user requirement: on net dial-out using a software client versus off net dial-out using a router.

On Net Dial-Out

The first type of dial-out service involves setting up a text-based dial-out server and using a software client to virtually attach a modem from that server to a PC via a LAN. This type of PPP dial-out uses the same configuration as the text dial-out service mentioned earlier. The only difference is that a user of a PPP dial-out service has a software client installed on their machine that emulates a modem connected to a virtual COM port. This client uses the resources of a dial-out server as a directly connected virtual modem, even for fax use.

No additional configuration lines are required to set up this service, but you must purchase a software client that can do this. The solution is recommended for companies who frequently use PPP dial-out, potentially saving a significant amount of money rather than purchasing separate analog lines for everyone that requires them.

For the current TAC recommended dial-out software, search Cisco.com by using the keyword CiscoDialOut. Consult the software documentation for the recommended IOS version.

Off Net Dial-Out

The second kind of PPP dial-out service connects to an Internet service provider (ISP) using a router as the connecting device. This network design is typical for a home network, when you want more than one PC to access the Internet. It is also similar to a home ISDN design.

The setup consists of a modem hanging off of an async interface or an aux port, which dials into a service provider. On the other side of the router is an Ethernet interface where a home computer is connected. The router most likely takes care of Network Address Translation (NAT) to serve each of the computers behind it. It is also possible to set up routing of a subnet through this connection but only if it is set up by your service provider in advance. Figure 6-5 shows the typical network design for this type of connection.

Figure 6-5. PPP Dial-Out Design for Off Net

Large-Scale Dial-Out Network

Large-scale dial-out places many calls to multiple locations, mostly for polling purposes. In this scenario, you can do one of two things: include all the phone numbers and locations on the router in the form of dialer maps or place them on a Terminal Access Controller Access Control System (TACACS+) or Remote Authentication Dial-In User Service (RADIUS) server to pass to the dial-out server during the router's boot sequence. Both situations are covered later in this chapter.

Figure 6-6 demonstrates that the network design is identical to the text dial-out network. The only difference is in the configuration. The configuration changes are covered in the section, "Large-Scale Dial-Out Configuration" later in this chapter. In many cases, you can use the same router for both purposes, which saves hardware and circuit costs by sharing the same set of circuits.

Figure 6-6. Large-Scale Dial-Out Network Using an AS5300 Configured to Place Calls over PRI Circuits

Dial-On-Demand Backup Network

Dial-on demand backup routing is similar to the second form of PPP dial-out covered previously. The section, "PPP Dial-Out Network" did not cover routing, how to bring up the line when a primary circuit fails, and how to tear it down again when the primary circuit comes back up. There are three different ways to configure DDR:

• Using a backup interface

• Using a floating static route

• Using a dialer watch

All three options have advantages and disadvantages. Each option is explained here.

Backup Interface

A backup interface's main advantage is that it is independent of routing protocols, which means that it is not affected by route convergence or stability. The most common use for a backup interface is on a WAN router at a remote site where the only route is a static route back to headquarters. When the primary WAN interface protocol changes its state to down, the backup interface takes over. The router then dials, connects, and passes traffic over the backup.

A backup interface's major downfall is that it is dependent on an interface's physical state or protocol to change the state to down before the backup link is activated. In the case of Frame Relay, the permanent virtual circuit (PVC) can go down while the circuit is still up, and the backup link is not activated. Using a backup interface also requires interesting traffic to bring up a connection. It can also back up only a single interface on a router, which means that, if one site is connected to two locations, you need a backup interface for each main connection, excluding interfaces from other uses.

Floating Static Route

Floating static routes are weighted heavier than the routes that are normally used. It does require a routing protocol, but it does not rely on the physical state or line protocol dropping to trigger a backup connection. For the floating static route to trigger the backup connection, the routing protocol must remove the primary route from the routing table. The speed at which the routing table converges determines how fast the backup connection is triggered. A route showing as possibly down does not trigger the call. Floating static routes still rely on interesting traffic to bring up the line when the primary connection is lost.

A good example of a floating static route is on a WAN router running Enhanced Interior Gateway Routing Protocol (EIGRP). In most cases, the floating static route is a default route. When the primary WAN link goes down, the default route is lost, and the floating static default route sends traffic through the backup connection.

Dialer Watch

Dialer watch provides backup connectivity without relying on interesting traffic. With dialer watch, the router monitors the existence of a specified route, and if that route is not present, it initiates dialing on the backup link. It is more difficult to configure and requires either the EIGRP or Open Shortest Path First (OSPF) routing protocol. The main advantage of this solution is that the router dials immediately when the primary route is lost. Dialer watch does not depend on line protocol, encapsulation type, or interesting traffic. The backup dial link stays active until the primary link comes back up, and can be configured to stay up longer in case of flapping routes. The details required to configure Dialer Watch are covered in a later section of this chapter, "Dial-On-Demand Backup Configuration."

Summary of Each Backup Solution

Table 6-1 summarizes each backup solution.

Table 6-1. Summary of Each Type of Backup Solution and Relevant Information on Each One

Factor	Backup Interface	Floating Static Route	Dialer Watch
Determination of when to place the backup call	Dependent on the line protocol status of primary interface and requires that the primary interface go down.	Employs static routes with a higher administrative distance to trigger a dial-on-demand routing (DDR) call.	Watches specific routes in the routing table and initiates a backup link if the route is missing.
Encapsulation	Encapsulation is a factor, for example, a Frame Relay backup might not work correctly with a backup interface.	Encapsulation independent.	Encapsulation independent.
Limitations of determining when to place the backup call	Does not consider end-to-end connectivity. Problems with end-to-end connectivity, such as routing errors, do not trigger backup links.	Evaluates the status of primary links based on the existence of routes to the peer. Hence, it considers primary link status based on the ability to pass traffic to the peer.	Evaluates the status of primary links based on the existence of routes to the peer. Hence, it considers primary link status based on the ability to pass traffic to the peer.
Backup triggers	Needs interesting traffic to trigger dialing the backup link.	Needs interesting traffic to trigger dialing the backup link, even after the route to the peer is lost.	Does not rely on interesting packets to trigger dialing. Dialing the backup link is done immediately when the primary route is lost.
Routing protocol dependence	Does not depend on the routing protocol.	Dependent on the routing protocol convergence time.	Dependent on the routing protocol convergence time.
Supported routing protocols	Routing protocol independent.	All routing protocols supported.	EIGRP/OSPF supported.
Interface/router limitations	Limited to one router, one interface.	Typically limited to single router, but with multiple interface/networks.	Supports multiple router backup scenario. For example, one router monitors the link between two other routers and starts the backup if that link fails.
Bandwidth on demand	Can be used to provide bandwidth on demand. The backup interface can be set up to activate when the primary link reaches a specified threshold.	Bandwidth on demand is not possible because the route to the peer exists regardless of the load on the primary link.	Bandwidth on demand is not possible because the route to the peer exists regardless of the load on the primary link.