Chapter 8. Traffic Steering and Service Centralization

One main advantage of a virtualized enterprise network is the ability to create tightly controlled and flexible communication interfaces between the different virtual networks (VNs). This capability also allows the deployment of services that are centrally accessible and common to many VNs. An example of such a service is access to the Internet. The centralization of the access to these services provides a common point of policy enforcement and control for all VNs.

This chapter focuses on the different alternatives that you can use to provide shared services in a virtual enterprise network. Both the central site access alternatives and the routing adjustments necessary to steer traffic to these policy enforcement points are discussed in detail.

Shared Services: Protected vs. Unprotected

We begin our discussion by broadly categorizing services that are shared by many VNs. As discussed in Chapter 3 "A Basic Virtualized Enterprise," these services can be grouped into protected or unprotected categories, depending on how they are accessed.

Unprotected Services

A service that can be accessed openly without subjecting the traffic to any sort of security check is considered an unprotected service. An unprotected service is reachable from one or more VNs without having a policy enforcement point between the service and the requesting host. The best- path routes to reach an unprotected service may be present in the different VNs that can access the service. In general, this type of access is used to provide shared Dynamic Host Configuration Protocol (DHCP) or Domain Name System (DNS) services to the different VNs without adding unnecessary load to the firewalls that are used to control access to other shared services that must be protected.

Protected Services

Some services must be accessible from the VNs only after certain security policies are enforced. We will see these as protected services. To be able to enforce the necessary security policies in a manageable way, access to these services must happen through a common policy enforcement point. At this policy enforcement point, traffic from the VNs could be subject to dedicated per-VN policies or to a shared policy. When the policies are dedicated, each VN has its own perimeter, and all VN perimeters are collocated. When the policies are shared, all VNs use the same perimeter. The perimeter could be defined by the presence of a firewall or a series of security devices. Firewalls and other security devices can be virtualized to create multiple logical devices, allowing a single physical device to host multiple perimeters for multiple VNs. Clearly, when the VN perimeters are implemented with logical devices, the perimeters for the different VNs will be collocated in a common point of policy enforcement.

Because all traffic reaching the services must be routed through a common point of policy enforcement, the routing between a requesting host and a service could potentially be suboptimal. However, significant inefficiencies occur only in specific scenarios, such as when the shared services themselves are part of a VN and therefore physically remote to the common point of policy enforcement. This leads to the potential "tromboning" of traffic that must travel to the central point of policy enforcement and back just to hop between VNs. In general, because shared services that are to be protected are centrally located, they will most likely be accessed optimally.

Note

We use the analogy of the trombone shape to see traffic patterns that travel a long distance to hit a policy enforcement point and return over roughly the same path. These traffic patterns resemble the physical characteristics of the tubes in a trombone.

Examples of protected services include server farms and Internet access. When regulating access to the Internet, it becomes evident that not only is it necessary to control access to the service from the VNs, but it is also critical to control access initiated from the service area toward the VNs. In general, it is not desirable for any VN to be accessed from the Internet; thus, access into the VNs from the services area is generally prohibited .

When VNs must communicate with each other in a controlled manner, you can change the policies at each VN perimeter to provide such access. In this particular inter-VN connectivity application, the policies must be open enough to allow externally initiated communication into the VNs.