This chapter is from the book
This chapter is from the book
This chapter is from the book
2.11 Case Studies
So far we defined and clarified VRRP concepts using simple configurations to keep the focus on the understanding of the protocol. Now that we have covered enough ground as an overview, we consider some typical VRRP deployment cases and call attention to some economic, risk-management aspect of the specific configuration. To do that we'll use different portions of the enterprise network we introduced at the beginning of this chapter in Figure 2-1. For the sake of facilitating the discussions, we use some made-up product names (MRM 100, MRM 5000, etc.) to create a context in which we can cover the trade-off considerations within a product line or a product category. With the same motivation, we also attribute some features to the products under discussion (support for dial-on-demand, filtering capabilities, etc.) so that the rationales for the described configurations become clearer.
){kind=link}
2.11.1 Dial Backup and No Load Sharing
The first standard configuration in the branch offices of the enterprise network under study consists of three routers: one high-end model and two low-end models of the same product line. The high-end model is connected to the cloud through a Data Service Unit/Customer Service Unit (DSU/CSU) using leased lines: T1 or T3. The router MRM 5000 shown in Figure 2-14 represents such a configuration.
)
FIGURE
2-14. Dial backup without load sharing
MRM5000 is the gateway of the branch office to the cloud and through the cloud to the Corporate Center. If it were not backed up, the failure of MRM 5000 would cause the branch office to lose all its network connectivity to the external world and thus to become almost unoperational, since all parts numbers and sales prices are stored in the Corporate Data Center. The economics of the company do not permit the purchase of another high-end router in addition to the lease of another T1 line for typical branch offices. For that reason, two MRM 100s, the lower-end models of the same product line with built-in dial backup modems, are used as backup equipment. Given that MRM 100s are lower-end models, their reliability and internal redundancy features may not be as strong as the higher-end models. For that reason, using not one but two backups with a 1-to-2 cardinality appears to be a sensible risk-management strategy. Of course, this configuration is most effective only in conjunction with an availability software such as VRRP. With some commercial products, VRRP may come as a feature of the standard software. In some others, it may require a special purchase or be part of a special software bundle. In the configuration discussed, we define MRM 5000 as the default router for all the workstations, PCs and laptops in the office, that is, all traffic that cannot be routed directly gets directed to MRM 5000 as long as it is operational. We configure the MRM 100s as two backups of MRM 5000, one with priority 5, the other with priority 250, to avoid any race condition that may occur because of closeness of priorities. MRM 100's dial backup features are also configured for dial-on-demand, so that when the router becomes the master, a trigger event activates the modem to dial into the modem bank of the Corporate Office. Although MRM 100 supports a simple agent that can detect the state change in VRRP and activate the modem when the router becomes the master, we prefer the use of the dial-on-demand feature of the MRM 100 to handle also cases that are not related to VRRP failover situations. With this feature enabled, the presence of the packets in the router destined toward the cloud activates the modem.
MRM 100s have built-in policy agents that can be configured to suppress a specified type of traffic. This is particularly useful to suppress nonessential traffic while the MRM 100s are acting as masters since they are connected over a low-bandwidth dial-up link. For example, when the MRM 5000 fails and MRM 100 takes over as the master, the policy filters could be set up only to pass through essential traffic between corporate network and the home network such as intranet network, database, and firewall server connectivity. It is good practice to program the filters to suppress email and Internet/Web traffic to alleviate the degradation of service after the VRRP switchover.
2.11.2 Load Sharing in the Branch
Some branches of the enterprise network have different networking and availability requirements. Because of their special criticality to the business and their special impact on the bottom line, different budgets are allocated to such organizations. If we were to call the configuration we discuss in Figure 2-14 small branch network, big branch network would be a proper label for the solution depicted in Figure 2-15. This configuration consists of two MRM5005s connected to the cloud through leased lines and mutually backing each other up by establishing two VRRP virtual routers. Since MRM 5005s have built-in DSU/CSU capability, we don't represent this equipment explicitly in Figure 2-15.
)
FIGURE
2-15. Load sharing in a branch
In the big branch configuration, we define two virtual routers and assign one MRM 5005s as master to a virtual router respectively. Keeping in mind the large amount of computer equipment in the office, we place intelligent hubs BSM 10 on the LAN. We group the default router assignments accordingly. We assign MRM 5005 on the left as the default for the hosts attached to the BSM 10 on the left, and we designate MRM 5005 on the right as the default router for the hosts attached to the BSM 100 on the right.
When both MRM 5005s are operational, they act as the master of their virtual routers and share the burden of handling the traffic originating from the office network. When one of the MRM 5005s fails, the other becomes the default router for all the hosts in the network. Given the hardware-based forwarding engines of the routers and the relatively higher capacity of the leased lines (T3), we assume that the service degradation should not be noticeable. Given this assumption, we enable the policy agents conditionally to suppress nonessential messages only when the traffic demands a certain level of bandwidth.
Although there might be some concerns about the impact of the BSM 100 devices on availability, given the simplicity of these devices, they have lesser chances of being additional points of failure in the network.