Response Time

Response time is a measure of the time between a client user request and a response from the server host. An end user will be satisfied with a certain level of delay in response time. However, there is a limit to how long the user will wait. This amount of time can be measured and serves as a basis for future application response times. Users perceive the network communication in terms of how quickly the server returns the requested information and how fast the screen updates. Some applications, such as a request for an HTML web page, require short response times. On the other hand, a large FTP transfer might take a while, but this is generally acceptable.

Throughput

In network communications, throughput is a measure of data transferred from one host to another in a given amount of time. Bandwidth-intensive applications have a greater impact on a network’s throughput than does interactive traffic such as a Telnet session. Most high-throughput applications involve some type of file-transfer activity. Because throughput-intensive applications have longer response times, you can usually schedule them when time-sensitive traffic volumes are lower, such as after hours.

Reliability

Reliability is a measure of a given application’s availability to its users. Some organizations require rock-solid application reliability, such as five nines (99.999%); this level of reliability has a higher price than most other applications. For example, financial and security exchange commissions require nearly 100% uptime for their applications. These types of networks are built with a large amount of physical and logical redundancy. It is important to ascertain the level of reliability needed for a network that you are designing. Reliability goes further than availability by measuring not only whether the service is there but whether it is performing as it should.

Bandwidth Considerations

Table 9-4 compares several WAN technologies in terms of speeds and media types.

A WAN designer must engineer the network with enough bandwidth to support the needs of the users and applications that will use the network. How much bandwidth a network needs depends on the services and applications that will require network bandwidth. For example, VoIP requires more bandwidth than interactive Secure Shell (SSH) traffic. A large number of graphics or CAD drawings require an extensive amount of bandwidth compared to file or print sharing information being transferred on the network. A big driver in increasing demand for bandwidth is the expanded use of collaboration applications that utilize video interactively.

When designing bandwidth for a WAN, remember that implementation and recurring costs are important factors. It is best to begin planning for WAN capacity early. When the link utilization reaches around 50% to 60%, you should consider increases and closely monitor the capacity. When the link utilization reaches around 75%, immediate attention is required to avoid congestion problems and packet loss that will occur when the utilization nears full capacity.

QoS techniques become increasingly important when delay-sensitive traffic such as VoIP is using the limited bandwidth available on the WAN. LAN bandwidth, on the other hand, is generally inexpensive and plentiful; in the age of robust real-time applications, however, QoS can be necessary. To provide connectivity on the LAN, you typically need to be concerned only with hardware and implementation costs.

Defining Availability

System availability is a ratio of the expected uptime to the amount of downtime over the same period of time. Let’s take an example of 4 hours of downtime per year. There are 365 days in a year, which equals 8760 hours (365 × 24 = 8760). Now, if we subtract 4 hours from the annual total of 8760 hours, we get 8756. Then, if we figure 8756 / 8760 × 100, we get the amount of availability percentage, which in this case is 99.95%.

Table 9-5 shows the availability percentages from 99% to 99.999999%, along with amounts of downtime per year.

Figure 9-1 illustrates WAN router paths and the impacts to availability depending on the level of redundancy used.

Deployment Models

There are three common deployment models for WAN connectivity, each with pros and cons:

• MPLS WAN: Single- or dual-router MPLS VPN

• Hybrid WAN: MPLS VPN and Internet VPN

• Internet WAN: Single- or dual-router Internet VPN

An MPLS WAN involves single or dual routers for the MPLS VPN connections. It provides for the highest in SLA guarantees for both QoS capabilities and network availability. However, this option is the most expensive, and it ties the organization to the service provider.

A hybrid WAN combines an MPLS VPN and an Internet VPN on a single router or on a pair of routers. This deployment model offers a balanced cost option between the higher-cost MPLS VPN connection and the lower-cost Internet VPN for backup. With a hybrid WAN, traffic can be split between the MPLS VPN for higher-priority-based traffic and Internet VPN for lower-priority-based traffic. Newer WAN designs are also using SDWAN with both MPLS and Internet-based transports.

An Internet WAN includes a single router or dual routers using Internet-based VPN only. This deployment model is the lowest-cost option but lacks the SLAs and QoS capabilities offered by carriers. The enterprise would be responsible for providing SLAs to the end users.

Redundancy Options

Depending on the cost of downtime for an organization, different levels of redundancy can be implemented for a remote site. The more critical WAN sites will use higher levels of redundancy. With any of the deployment options—MPLS WAN, hybrid WAN, or Internet WAN—you can design redundant links with redundant routers, a single router with redundant links, or a single router with a single link.

For the most critical WAN sites, you typically want to eliminate single points of failure by designing with dual routers and dual WAN links along with dual power supplies. However, this highly available option comes with a higher price tag and is more complex to manage; however, it offers failover capabilities. Another option available to reduce cost is to use a single router with dual power supplies and multiple WAN links providing power and link redundancy. Non-redundant, single-homed sites are the lowest cost, but they have multiple single points of failure inherent with the design, such as the WAN carrier or WAN link.

Single-Homed Versus Multi-Homed WANs

The advantages of working with a single WAN carrier are that you only have one vendor to manage, and you can work out a common QoS model that can be used throughout your WAN. The major drawback with a single carrier is that if the carrier has an outage, it can be catastrophic to your overall WAN connectivity. This also makes it difficult to transition to a new carrier because all your WAN connectivity is with a single carrier.

On the other hand, if you have dual WAN carriers, the fault domains are segmented, and there are typically more WAN offerings to choose from because you are working with two different carriers. This also allows for greater failover capabilities with routing and software redundancy features. The disadvantages with dual WAN carriers are that the overall design is more complex to manage, and there will be higher recurring WAN costs.

Single-Homed MPLS WANs

In a single-MPLS-carrier design, each site is connected to a single MPLS VPN from one provider. For example, you might have some sites that are single-homed and some sites that are dual-homed to the MPLS VPN. Each site will consist of CE routers peering with the provider using eBGP, and iBGP will be used for any CE-to-CE peering. Each CE will advertise any local prefixes to the provider with BGP and redistribute any learned BGP routes from the provider into the IGP or use default routing. Common IGPs are standard-based OSPF and EIGRP.

Figure 9-2 illustrates a single-MPLS-carrier design with single- and dual-homed sites.

Multi-Homed MPLS WANs

In a dual-MPLS-carrier design, each site is connected to both provider A and provider B. Some sites might have two routers for high availability, and others might have only a single router but with two links for link and provider redundancy. For example, each CE router would redistribute local routes from EIGRP into BGP. Routes from other sites would be redistributed from BGP into EIGRP as external routes. For sites that have two routers, filtering or tagging of the routes in and out of BGP would be needed to prevent routing loops.

Figure 9-3 illustrates a dual-MPLS-carrier design with single and dual routers.

Hybrid WANs: Layer 3 VPN with Internet Tunnels

Hybrid WAN designs involve using an MPLS VPN for the primary connection and an Internet tunnel for the backup connection. In this design, eBGP would be used to peer with the MPLS VPN provider, and EIGRP would be used for routing for the IGP internally. At each site, the CE router would learn routes from the MPLS VPN via BGP and redistribute the routes from BGP into EIGRP. Then each site would redistribute EIGRP routes into BGP and use EIGRP to peer with other local routers at each site. The Internet tunnel routers would use EIGRP to exchange routes inside the VPN tunnels, and they would not need to redistribute routing information because they would run only EIGRP. On the MPLS VPN router, BGP-learned routes would be preferred because the BGP routes that would be redistributed into EIGRP routes would have a lower administrative distance. In this case, if you want the MPLS VPN router to be the primary path, you need to run an FHRP between the dual-homed routers, with the active router being the MPLS VPN-connected router. That way, it would choose the MPLS VPN path as the primary path and use the Internet tunnel path as the backup path for failover. Another option would be to modify the routing protocol metrics so that the MPLS VPN path is preferred.

Figure 9-4 illustrates a hybrid WAN design with an MPLS VPN and an Internet VPN.

Internet for Remote Sites

When designing the Internet traffic flows for remote site locations, you have two main options to consider. One option, referred to as centralized Internet access, involves tunneling all the Internet traffic back to the data center or main site. With this option, you have more control over the Internet traffic with centralized security services such as URL filtering, firewalling, and intrusion prevention. However, there are some drawbacks with this approach because the bandwidth requirements and cost will be higher for your WAN links to the branch locations, and it increases the delay for any Internet-based traffic. Another option is to allow Internet-destined traffic at each branch to use the dedicated local Internet connection or VPN split tunneling. There are some advantages with this approach; your bandwidth requirements and the cost for your MPLS VPN links will be lower for your branch locations because you do not need to transport Internet traffic on them. This approach does have some drawbacks, however, because the local Internet access may violate your security policy by exposing more Internet points within your organization that need protection with security services.

Here are some pros and cons of each of these options:

• Centralized Internet for each remote site: Higher bandwidth is available, and security policies are centralized, but traffic flows are suboptimal. This option might require additional redundancy at the Internet edge, which may or may not be present.

• Direct Internet for remote site: Traffic flows are optimal, but it is more difficult to manage distributed security policies. This option also has a higher risk of Internet attacks due to the greater number of attachment points.

High Availability for the Internet Edge

When you have decided to have two Internet routers, each with a link to two different Internet service providers, you need to think about the logical design for the routers, including failover options. Logical Internet high availability design considerations include the following:

• Use a public BGP AS number for eBGP connections to the ISPs.

• Use provider-independent IP address space to allow for advertisement to both ISPs.

• Receive full or partial Internet routing tables to optimize forwarding outbound.

• Use HSRP/GLBP or an IGP such as EIGRP or OSPF internally.

Failover

An option for network connectivity failover is to use the Internet as the failover transport between sites. However, keep in mind that this type of connection does not support bandwidth guarantees. The enterprise also needs to set up the tunnels and advertise the company’s networks internally so that remote offices have reachable IP destinations. IP SLA monitoring can be leveraged along with a floating static route to provide failover.

Security is of great importance when you rely on the Internet for network connectivity, so a secure tunnel using IPsec needs to be deployed to protect the data during transport.

Figure 9-6 illustrates connectivity between the headend or central site and a remote site using traditional MPLS Layer 3 VPN IP connections for the primary WAN link. The IPsec tunnel is a failover tunnel that provides redundancy for the site if the primary WAN link fails.

IPsec tunnels are configured between the source and destination routers using tunnel interfaces. Packets that are destined for the tunnel have the standard formatted IP header. IP packets that are forwarded across the tunnel need an additional GRE/IPsec header placed on them, as well. As soon as the packets have the required headers, they are placed in the tunnel with the tunnel endpoint as the destination address. After the packets cross the tunnel and arrive on the far end, the GRE/IPsec headers are removed. The packets are then forwarded normally, using the original IP packet headers. An important design consideration to keep in mind is that you might need to modify the MTU sizes between the source and destination of the tunnel endpoints to account for the larger header sizes of the additional GRE/IPsec headers.

Best-Effort QoS

The best-effort (BE) QoS model is typically the default QoS model and does not implement any QoS behaviors to prioritize traffic before other QoS traffic classes. This is the easiest of the three models because there is nothing you really need to do for it to work. You would not want to use best-effort QoS for any real-time applications such as voice or video traffic. It is a last-resort QoS model that you use after you have already prioritized all other important traffic classes that are sensitive to delay, jitter, and/or bandwidth within the network.

DiffServ

The DiffServ QoS model separates traffic into multiple classes that can be used to satisfy varying QoS requirements. A packet’s class can be marked directly inside the packet that classifies packets into different treatment categories.

With the DiffServ model, packets are classified and marked to receive a per-hop behavior (PHB) at the edge of the network. Then the rest of the network along the path to the destination uses the DSCP value to provide proper treatment. Each network device then treats the packets according to the defined PHB. The PHB can be specified in different ways, such as by using the 6-bit Differentiated Services Code Point (DSCP) setting in IP packets or by using ACLs with source and destination addresses.

Priorities are marked in each packet using DSCP values to classify the traffic according to the specified QoS policy for the traffic class. Typically, the marking is performed per packet at the QoS domain boundaries within the network. Additional policing and shaping operations can be implemented to enable greater scalability.

Table 9-6 maps applications to DSCP and decimal values.

IntServ

The IntServ QoS model was designed for the needs of real-time applications such as video, multimedia conferencing, and virtual reality. It provides end-to-end QoS treatment that real-time applications require by explicitly reserving network resources and giving QoS treatment to user packet flows. The IntServ model applications ask the network for an explicit resource reservation per flow and use admission control mechanisms as key building blocks to establish end-to-end QoS throughout the network.

IntServ uses Resource Reservation Protocol (RSVP) to explicitly request QoS for the application along the end-to-end path through devices in the network. Before an application begins transmitting, it requests that each network device reserve the necessary bandwidth along the path. The network, in turn, accepts or rejects the reservation per flow based on available network resources.

IntServ requires several functions on each of the routers and switches between the source and destination of the packet flow:

• Admission control: Determines whether the requested flows can be accepted without impacting existing reservations

• Classification: Identifies traffic that requires different levels of QoS

• Policing: Allows or drops packets when traffic does not conform to the QoS policy

• Queuing and Scheduling: Forwards traffic for permitted QoS reservations

Classification and Marking

For a flow to have priority, it must be classified and marked. Classification is the process of identifying the type of traffic. Marking is the process of setting a value in the IP header based on the classification. The following are examples of technologies that support classification:

• Network-based application recognition (NBAR): This technology uses deep packet content inspection to identify network applications. An advantage of NBAR is that it can recognize applications even when they do not use standard network ports. Furthermore, it matches fields at the application layer. Before NBAR, classification was limited to Layer 4 TCP and User Datagram Protocol (UDP) port numbers.

• Committed access rate (CAR): CAR uses a rate limit to set precedence and allows customization of the precedence assignment by user, source or destination IP address, and application type.

Shaping

Traffic shaping and policing are mechanisms that inspect traffic and take action based on the traffic’s characteristics, such as DSCP or IP precedence bits set in the IP header.

Traffic shaping involves slowing down the rate at which packets are sent out an interface (egress) by matching certain criteria. Traffic shaping uses a token bucket technique to release the packets into the output queue at a preconfigured rate. Traffic shaping helps eliminate potential bottlenecks by throttling back the traffic rate at the source. In enterprise environments, traffic shaping is used to smooth the flow of traffic going out to the provider. This is desirable for several reasons. For example, in provider networks, it prevents the provider from dropping traffic that exceeds the contracted rate.

Policing

Policing involves tagging or dropping traffic, depending on the match criteria. Generally, policing is used to set the limit of traffic coming into an interface (ingress) and uses a “leaky bucket mechanism.” Policing can be used to forward traffic based on conforming traffic and to drop traffic that violates the policy. Policing is also referred to as committed access rate (CAR). One example of using policing is giving preferential treatment to critical application traffic by elevating to a higher class and reducing best-effort traffic to a lower-priority class.

When you contrast traffic shaping with policing, remember that traffic shaping buffers packets, while policing can be configured to drop packets. In addition, policing propagates bursts, but traffic shaping does not.

Queuing

Queuing refers to the buffering process used by routers and switches when they receive traffic faster than it can be transmitted. Different queuing mechanisms can be implemented to influence the order in which the different queues are serviced (that is, how different types of traffic are emptied from the queues).

QoS is an effective tool for managing a WAN’s available bandwidth. Keep in mind that QoS does not add bandwidth; it only helps you make better use of the existing bandwidth. For chronic congestion problems, QoS is not the answer; in such situations, you need to add more bandwidth. However, by prioritizing traffic, you can make sure that your most critical traffic gets the best treatment and available bandwidth in times of congestion. One popular QoS technique is to classify your traffic based on a protocol type or a matching access control list (ACL) and then give policy treatment to the class. You can define many classes to match or identify your most important traffic classes. The remaining unmatched traffic then uses a default class in which the traffic can be treated as best-effort.

Table 9-7 describes QoS options for optimizing bandwidth.

Link Efficiency

With Cisco IOS, several link-efficiency mechanisms are available. Link fragmentation and interleaving (LFI), Multilink PPP (MLP), and Real-Time Transport Protocol (RTP) header compression can provide for more efficient use of bandwidth.

Table 9-8 describes Cisco IOS link-efficiency mechanisms.

Mechanisms	Description
Link fragmentation and interleaving (LFI)	Reduces delay and jitter on slower-speed links by breaking up large packet flows and inserting smaller data packets (Telnet, VoIP) in between them.
Multilink PPP (MLP)	Bonds multiple links between two nodes, which increases the available bandwidth. MLP can be used on analog or digital links and is based on RFC 1990.
Real-Time Transport (RTP) header compression	Provides increased efficiency for applications that take advantage of RTP on slow links. Compresses RTP/UDP/IP headers from 40 bytes down to 2–5 bytes.