Branch offices have always presented a special challenge from a connectivity standpoint. This is because branch offices are almost always far enough away from the main office that you can’t just run an Ethernet cable between the main office and the branch office. Instead, a wide area network connection is usually required for providing connectivity between the branch office and the main office. In the past, this usually meant using an expensive leased line. Today, virtual private network connections have become the connectivity option of choice because they are so much less expensive than using a dedicated leased line.
In either case though, there is still one major issue that plagues branch offices. If the leased line or the VPN connection fail, or if a router malfunctions, that branch office is completely cut off from the rest of the company. It is therefore important to have some sort of redundant routing mechanism in place so that even if the primary connection between the branch office and the main office fails, communications can still continue.
There are many different ways of providing redundancy for wide area network connections. For companies that rely on leased lines and that have multiple branch offices, a common solution has always been to use a ring topology. For example, suppose for a moment that your company had a main office and three branch offices. The main office would have leased line connections to offices A and C. A would connect to B, B would connect to C, and C would of course connect back to the main office
The advantage to this type of topology is that if a link were to fail, then communications could continue because each office has a connection to two different facilities within the organization. If one of the links were to fail, any facility could still maintain communications with every other facility by using the remaining links.
Although this is a good solution overall, there are some issues that you have to consider before implementing such a design. For starters, if you are using leased lines for communications, then this design will be more expensive than a non redundant design. If the fictitious company that I just described were to use a non redundant star topology (main office has a connection to A, B, and C), then a total of three leased lines would be required. In contrast, the redundant ring topology that I described earlier would require four leased lines. Given the cost of leased lines, the difference in cost between the two designs could be substantial.
Like I said earlier though, because of the cost of leased lines, many companies have chosen to use VPN connections as an alternative to leased lines. You could easily create the same topologies that I have already discussed by using VPN connections rather than leased lines. The problem is that the ring topology might not give you any redundancy if VPN is being used.
The reason behind this is that VPN treats a public network connection (usually the Internet) as a private connection. You could deploy two separate Internet connections into each facility so that you could have two separate VPN connections, one to each facility. The problem is that this only gives you partial redundancy. If one of the lines used for the Internet connection were damaged, then you’ve got the other to fall back on. However, if your ISP were to have problems, then there is a really good chance that both connections would fail and the office would lose the ability to communicate with your company’s other facilities.
Another consideration that you need to take into account when planning a redundant topology is the routers that you use. I have seen ring topology deployments in which both of a facility’s WAN connections connect to a single router. This type of configuration will provide you with redundancy if one of the lines were to fail, but it won’t protect you against a router malfunction. If the router were to be hit by lightning, then neither WAN connection would work and the facility would be cut off from the rest of the organization.
I’m personally a big believer in redundant routs, but as you can see there are plenty of circumstances that can cause even facilities with redundant connections to be cut off from the rest of the organization. There is something that you can do to hedge your bets though and help to insure that connectivity is maintained during even the worst circumstances. It’s called Demand Dial Routing.
The idea behind demand dial routing is that if your network detects that no route is available from your office to another facility, then a router establishes a dial up connection to a remote facility so that traffic can continue to flow. I know what you are thinking right now, and yes, demand dial routing is slow. However, I tend to think that it’s better to have a slow connection than no connection. Besides, it’s not like the demand dial route is going to be your organization’s primary communications mechanism, it is basically a backup to a backup. The demand dial route will not be used unless all other communication paths fail.
I realize that in some organizations the slow speed of a demand dial route can be a huge problem, even in an emergency. Fortunately, there are some things that you can do to make a demand dial route faster. One option is to use multilink. Multilink is a technology that distributes packets across multiple modems and multiple phone lines to achieve higher throughput than could normally be achieved through a dial up connection. Another option is to use an ISDN connection. ISDN (Integrated Service Digital Network) is a digital phone line that can establish dial up sessions at up to 128 Kbps.
The nice thing about demand dial routing is that even if your router doesn’t support it, it is still available to you. You can configure a Windows 2000 or a Windows 2003 Server to act as a demand dial router. If you choose this route, you will need a server on each end of the WAN connection. One server will act as the dialing router and the other will act as the answering router.
Configuring the Dialing Router
Now that I have talked a bit about the benefits of demand dial routing, I want to take a moment and show you how to configure Windows Server 2003 to act as a demand dial router. Let’s start by setting up the calling router.
To configure the calling router, open the Windows Server 2003 Routing and Remote Access (RRAS) console by selecting it from the server’s Administrative Tools menu. What you will do next really just depends on whether RRAS is currently active on the server or not. For the purpose of this article, I will assume that RRAS is not currently being used.
When the RRAS console opens, you will see your server listed beneath the Server Status section. Right click on your server and select the Configure and Enable Routing and Remote Access option from the shortcut menu. Windows will now launch the RRAS Setup Wizard. Click Next to bypass the wizard’s Setup screen. You will now see a screen asking what role you would like the wizard to configure RRAS for. Demand dial routing is not listed on this screen, so select the Custom Configuration option instead and click Next. You will now see another screen asking which services you want to set up on the server. Select the Demand Dial Connection check box and click Next followed by Finish. You will now see a message indicating that RRAS has been installed. The message goes on to ask if you want to start the RRAS service. Click Yes and you are in business.
Now that the initial installation is finished, you must configure a demand dial interface. To do so, navigate through the console tree to the Network Interfaces container beneath your server. Right click on the Network Interfaces container and select the New Demand Dial Interface command from the resulting shortcut menu. When you do, Windows will launch the Demand Dial Interface Wizard. Click Next to bypass the introductory screen.
The first question that the Wizard will ask you is the name for the demand dial interface. It’s common to name the interface something that reflects the path that the interface will service. Once you’ve named the interface, click Next to continue.
At this point, the wizard will ask you whether you want to connect using a modem (or other physical device), a VPN link, or a PPPoE connection. Since we are configuring a dial up interface, select the modem option and click Next.
The next screen will ask you to select which device you want to use for your connection. Select the modem that you want to use and click Next. You’ll now be prompted to enter the phone number that the router should dial. You can also supply a list of alternate phone numbers for the server to try, should the primary number be unavailable.
Click Next and you will see a screen that asks you which tasks you want to perform in order to complete the configuration. At the very least, you must select the Route IP Packets on This Interface option. I also recommend using the plain text password option. Yes, I know that plain text passwords present a security risk, but Windows won’t use a plain text password unless it is unable to connect any other way. In my opinion, if a failure situation is serious enough that a demand dial route is being established, then the last thing in the world you want is for the demand dial route to fail just because of an incompatible password format.
At this point, you will see a screen that asks you for the IP address of the router that you will be dialing into. Click Next after entering this information and you will be prompted to enter a set of dial out credentials. The reason why dial out credentials are necessary is because the answering router is nothing more than a remote access server. As you may know, Windows requires users dialing into a remote access server to have permissions to dial into that server. A demand dial router is not exactly a typical Windows client, but the answering router doesn’t know that. It is going to require the demand dial router to provide a set of authentication credentials just like it would for any other user. My advice is to create a special account whose only permissions are that it is allowed to log into a remote access server. You can then use that account for the demand dial router. Just be sure to set the account up so that its password never expires or you could be in for a rude surprise one day when the router needs to establish a connection. Click Next followed by Finish, and the Demand Dial interface is ready to go.
Conclusion
As you can see, circumstances can occur that cause remote offices to be cut off from the rest of the network even if redundant routs exist. As a contingency plan, you can implement demand dial routing. Demand dial routing will establish a temporary dial up connection to the remote network until the primary route becomes available again.
