design a virtualized enterprise network

8/8/2019 Design a Virtualized Enterprise Network

http://slidepdf.com/reader/full/design-a-virtualized-enterprise-network 1/19

C H A P T E R

3A Basic Virtualized Enterprise

In this chapter, we dene the technical requirements posed by the need to virtualize thenetwork. Based on these requirements, we propose and architectural framework comprisedof the functional areas necessary to successfully support concurrent virtual networks (VNs)over a shared enterprise physical network.

Networks enable users to access services and resources distributed throughout the enterprise.Some of these services and resources are public: those accessed over the Internet, andothers that are private and internal to the enterprise. Every enterprise has unique security andservice level policies that govern the connectivity to the different services, whether these arepublic or private.

One of the basic building blocks behind the virtualized network and, in fact, a key driver issecurity. An important element of an enterprise’s security policy is the denition of anetwork perimeter. In general, the level of trust inside and outside of the network perimeterdiffers, with end stations inside the perimeter being generally trusted and any access fromoutside the perimeter being untrusted by default. Communications between the insideand the outside of the perimeter must happen through a checkpoint. At the checkpoint,rewalls and other security devices ensure that all trafc that enters or leaves the enterpriseis tightly controlled. Therefore, we refer to the point of entry/exit to/from the enterprisenetwork as the network perimeter.

NOTE The network perimeter denes one layer of security and must be complemented with othersecurity mechanisms. It is critical to incorporate mechanisms to protect the network fromattacks initiated inside the perimeter. This functionality is generally provided at the network access/edge and is not impacted by the virtualization of the network.

To provide the required connectivity, create a secure perimeter and enforce the necessarypolicies, it is recommended that an enterprise network be based on certain functional blocks.Figure 3-1 depicts a modular enterprise network and its perimeter. The recommendedfunctional blocks are as follows:

• The LAN/MAN transport (core and distribution)

• The LAN edge or access layer

Presented by:

Reproduced from the book Network Virtualization. Copyright © 2006, Cisco Press . Reproduced by permission of Pearson Education, 800 East 96th Street, Indianapolis, Indiana 46240. Written permission from Pearson Educationis required for all other uses.

http://www.ciscopress.com/bookstore/product.asp?isbn=1587052482&rl=1




http://techrepublic.com.com/



36 Chapter 3: A Basic Virtualized Enterprise

• The Internet access module

• The data center access module

• The WAN aggregation module

• The WAN transport

• The branch

Figure 3-1 The Modular Enterprise Network and Its Perimeter

When a single enterprise network must service many different groups, it is often necessaryto create virtual networks (VNs) so that each group can enjoy

• Private connectivity over a shared infrastructure.

• A dedicated perimeter in which independent policies can be enforced per group.

• User mobility (ubiquitous access to the appropriate virtual network regardless of theuser’s location).

Distribution

LAN Access

BackboneWAN Aggregation

Module

Internet AccessModule

Perimeter

LAN/MANCore

Internet

WAN

Branch

Branch

Mainframe

ServersData CenterModule

RemoteLAN/MAN



The Virtual Enterprise 37

At the risk of oversimplifying, a VN can be seen as a security zone. All devices within thesecurity zone trust each other and communicate freely with each other. Meanwhile, anycommunication with other security zones, or other networks, must happen in a controlledmanner over a highly secured perimeter or checkpoint. Thus, a virtualized enterprisenetwork will simultaneously host many security zones, and their dedicated perimeters, overa shared infrastructure.

The Virtual EnterpriseA virtual enterprise network must provide each group with the same services as a traditionaldedicated enterprise network would. The experience from an end-user perspective should bethat of being connected to a dedicated network that provides connectivity to all the resourcesthe user requires. The experience from the perspective of the network administrator is thatthey can easily create and modify virtual work environments for the different groups of usersand adapt to changing business requirements in a much easier way. The latter derives fromthe ability to create security zones that are governed by policies enforced centrally. Becausepolicies are centrally enforced, adding or removing users and services to or from a VN doesnot require any policy reconguration. Meanwhile, new policies affecting an entire groupcan be deployed centrally at the VN perimeter. To virtualize an enterprise network, the basicfunctional blocks of the modular enterprise must be enhanced to provide the followingfunctionality:

• Dynamically authenticate and authorize users into groups

• Isolate connectivity to guarantee privacy between groups

•Create well-dened and controllable ingress/egress points at the perimeter of each VN

• Enforce independent security policies for each group at the perimeter

• Centralize the enforcement of the perimeter security policies for the differentVNs by

— Allowing secure collaboration mechanisms among groups

— Allowing secure sharing of common resources

• Provide basic networking services for the different groups, either shared or dedicated

• Provide independent routing domains and address spaces to each group

You could use many different technologies to solve the listed challenges. The technologiesavailable and how these can be used to meet the above requirements are the topic of theremaining chapters in the book.

From an architectural perspective, the previous requirements can be addressed bysegmenting the network pervasively into VNs and centralizing the application of network policies at the perimeter of each VN. These are, of course, the policies foringress and egress to the VN or security zone. The formation of a trusted security




zone relies on trafc-isolation mechanisms rather than a distributed policy. Becausetrafc internal to a zone is trusted, policies are required only at the perimeter tocontrol the access to external resources that could in many cases be shared. Figure 3-2illustrates this concept.

Figure 3-2 Virtual Networks with Centralized Policies at the Perimeter

Regardless of where a user is connected, its trafc should always use the same VN and bedirected through a central site of policy enforcement (VN perimeter), should it need to exit

the VN. This makes users mobile and ensures that regardless of their location they willalways be subject to the same policies. To ensure that users are always connected to the rightVN, dynamic authentication and authorization mechanisms are required. These allow theidentication of devices, users, or even applications so that these can be authorized onto thecorrect virtual segment and thus inherit the segment’s policies.

The virtualization architecture described so far can be organized into functional areas.These functional areas provide a framework for the virtualization of networks:

• Transport virtualization

• Edge authorization

• Central services access (VN perimeter)

As you will see throughout the book, this modular framework gives the network architecta wide choice of technologies for each functional area. A key element in achieving thisdegree of exibility is the denition of clear communication interfaces between thedifferent areas.

VLANs provide an example of a communication interface between functional areas.The edge authorization module assigns a user to a VLAN, and the transport module maps

InternetGateway

PerimeterOutside

PerimeterInside

VideoServer

HostedContent

DHCP

IPSecGateway

Firewalland NAT



The Virtual Enterprise 39

that VLAN to a VN. At the destination, the transport module maps the VPN back to aVLAN. If the destination is outside the VN perimeter, the transport module hands off a VLAN to the central services access module, which maps the VLAN to the necessaryvirtual services. As you progress through the book, you learn that the interface betweenmodules could very well be a label or a policy.

NOTE There are, of course, pros and cons to using different types of communication interfaces.These are analyzed as the different technologies are discussed in detail, so read on.

Figure 3-3 shows the functional areas of the virtualized enterprise. As shown, you can usea variety of technologies for each different area.

Figure 3-3 Virtualized Enterprise Network Functional Areas

Mainframe

Servers

MAN/WAN

L3 VRFs

802.1Q + VRFsMPLS VPNs

GRE, L2TPv3

VLANs PartitionServer Farms

Authorize peruser/role VLANs

User identification(802.1x, etc.)

VN Perimeter

EdgeAuthorization

802.1Q + VRFsMPLS VPNs

GRE, L2TPv3,DMVPN, DGVPN

Virtualized Services:FW, CSM

TransportVirtualization

TransportVirtualization




A useful way to look at Figure 3-3 and understand the role of the different functionalareas is to look at it from the top down. Starting at the top, the endpoints connected tothe network are authenticated and as a result of the authentication are authorized onto aspecic VLAN (edge authorization). Each VLAN maintains its trafc separate from otherVLANs and is mapped to a virtual routing and forwarding instance (VRF).

NOTE VRFs are logical routing and forwarding tables with associated interfaces and routingprocesses, what could be thought of as a virtual routing instance. The section on“Control-Plane-Based Segmentation” and Chapter 4 examine the concept of a VRF inmore detail.

Each VRF is connected to other VRFs in its VN and keeps its trafc separate from VRFsthat belong to other VNs (transport virtualization). When trafc is destined to a resourceoutside the VN (for example, the data center), it is routed to the VN perimeter, where virtualservices, such as rewalling and load balancers, are applied to each group (central servicesaccess—VN perimeter). Trafc destined to a subnet over the WAN is kept separate fromtrafc in other VNs through the virtualization of the WAN transport (transportvirtualizaton).

Transport Virtualization—VNsWhen segmenting the network pervasively, all the scalability, resiliency, and securityfunctionality present in a nonsegmented network must be preserved and in many casesimproved. As the number of groups sharing a network increases, the network devices musthandle a much higher number of routes. Any technologies used to achieve virtualizationmust therefore provide the necessary mechanisms to preserve resiliency, enhancescalability, and improve security.

Chapter 2, “Designing Scalable Enterprise Networks,” discussed network designrecommendations that provide high availability and scalability through a hierarchical andmodular design. Much of the hierarchy and modularity discussed relies on the use of arouted core. Nevertheless, some areas of the network continue to benet from the use of Layer 2 technologies, such as VLANs, ATM, or Frame Relay circuits. Thus, a hierarchicalIP network is a combination of Layer 3 (routed) and Layer 2 (switched) domains. Boththe Layer 2 and the Layer 3 domains must be virtualized, and the virtualized domainsmust be mapped to each other to create VNs.



Transport Virtualization—VNs 41

NOTE The term virtual private network is broadly used and might have different connotations todifferent people. To avoid confusion, we use the term virtual network as an implementation-independent concept. In many implementations, a VN is actually a VPN; but as you read,you might want to avoid creating a direct association between your favorite type of VPNimplementation (IPsec, Secure Sockets Layer [SSL], IP-VPN) and the concept of aVN, which we are here introducing.

One key principle in the virtualization of the transport is that it must address thevirtualization of the network devices and their interconnection. Thus, the virtualization of the transport involves two areas of focus:

• Data-path virtualization —Refers to the virtualization of the interconnection betweendevices. This could be a single-hop or multiple-hop interconnection. For example, anEthernet link between two switches provides a single-hop interconnection that can bevirtualized by means of 802.1q VLAN tags; for Frame Relay or ATM transports,separate virtual circuits provide data-path virtualization. An example of a multiple-hopinterconnection would be that provided by an IP cloud between two devices. Thisinterconnection can be virtualized through the use of multiple tunnels ( generic routingencapsulation [GRE] for example) between the two devices.

• Device virtualization —Refers to the virtualization of a networking device or thecreation of logical devices within the physical device. This includes the virtualizationof all processes, databases, tables, and interfaces within a device.

In turn, within each networking device, there are at least two planes to virtualize:• Control plane —Refers to all the protocols, databases, and tables necessary to

make forwarding decisions and maintain a functional network topology free of loopsor unintended blackholes. This plane could be said to draw a clear picture of thetopology for the network device. A virtualized device must posses a unique pictureof each VN it is to handle, hence the requirement to virtualize the control-planecomponents.

• Forwarding plane —Refers to all the processes and tables used to actually forwardtrafc. The forwarding plane builds forwarding tables based on the informationprovided by the control plane. Similar to the control plane, each VN will have a uniqueforwarding table that needs to be virtualized.

Furthermore, the control and forwarding planes can be virtualized at different levels, whichmap directly to different layers of the OSI model. For instance, a device can be VLAN awareand therefore virtualized at Layer 2, but yet have a single routing table, Routing Information

Base (RIB), and Forwarding Information Base (FIB), which means it is not virtualized atLayer 3. The different levels of virtualization come in handy, depending on the technicalrequirements of the deployment. Sometimes Layer 2 virtualization is enough (a wiringcloset, for instance). In other cases, virtualization of other layers might be necessary.




For example, providing virtual rewall services requires Layers 2, 3, and 4 virtualization,plus the ability to dene independent services and management on each virtual rewall,which some may argue is Layer 7 virtualization. We delve into rewall virtualization inChapter 4. For now, we focus on the virtualization of the transport at Layers 2 and 3.

VLANs and ScalabilityTime and experience have proven the scalability benets of limiting the size of Layer 2domains in a network. A large amount of this experience comes from campus networks,where highly resilient topologies with redundant links are possible. This link redundancyintrinsically creates network loops that must be controlled by mechanisms such as spanningtree. The broadcast nature of a Layer 2 domain is the main reason these redundant linksbehave as loops rather than redundant active paths capable of load balancing. Hence, thelack of load balancing and the complexity involved in managing large and highly resilientspanning-tree domains makes a routed infrastructure much more appropriate for large-scalehighly available networks. Thus, experience has taught us that meshed Layer 2 domainshave their role in the network, but they must be kept small in scale. Keep in mind that weare referring to highly meshed resilient Layer 2 domains such as those you would nd in acampus. This type of problem is faced less in the WAN, where point-to-point connectionstend to be at the base of the architecture and are for the most part routed. Nevertheless, theintroduction of technologies that extend Layer 2 domains over an IP infrastructure hasbrought many of the spanning-tree concerns to the table in the metro-area network (MAN)and WAN.

When you are virtualizing a network, it is tempting to revisit ideas such as end-to-endVLANs. After all, mapping a group of users to a specic VLAN to create an isolatedworkgroup was one of the original thoughts behind the creation of VLANs. Should theVLAN traverse the entire enterprise, we could say the transport has been virtualized. Thistype of solution will have all the scalability problems associated with large Layer 2 domainsand is therefore not desirable.

Nevertheless, the use of VLANs has its place as a way of segmenting the Layer 2 portionof the network. In an enterprise campus, this is generally the mesh of links betweenthe access and the distribution. Remember, the recommendation is to reduce the size of thebroadcast domains to something manageable, not necessarily to eliminate the broadcastdomains, because too much IP subnet granularity would also represent a managementchallenge. So, to segment the access portion of the network, VLANs are of much use.

NOTE Later on, in the section “Policy-Based Segmentation,” you will see that there aremechanisms to achieve trafc differentiation by using code points. These techniques do notcreate separate broadcast domains and are effective only after entering the routed core. Theuse of code points will not provide separation between groups that share a broadcastdomain. VLANs are required to provide Layer 2 separation at the access.




The network must preserve its hierarchy and therefore its routed core. As the periphery(access/distribution) continues to be switched (as opposed to routed), VLANs must be usedfor segmentation purposes. Thus, a VLAN in a wiring closet would represent the point of entry into a VN.

Because these VLANs are terminated as they reach the routed core, it is necessary to mapthem to segments created in the routed core. The next section looks into what is necessaryin the core. From the access perspective, the VLANs must map to the correspondingsegments created in the core to achieve an end-to-end VPN that spans both the switched androuted portions of the network.

We focus our analysis on a network with a routed core and a switched access. This modelis widely adopted because it has been proven, optimized, and recommended by Cisco for

many years.

Virtualizing the Routed CoreYou can achieve the virtualization of the routed portion of the network in many ways. Atthe device level, the available trafc separation mechanisms can be broadly classied asfollows:

• Policy-based segmentation

• Control-plane-based virtualization

Policy-Based Segmentation

Policy-based segmentation restricts the forwarding of trafc to specic destinations, basedon a policy and independently of the information provided by the control plane. Thepolicies are applied onto a single IP routing space. A classic example of this uses an accesscontrol list (ACL) to restrict the valid destination addresses to subnets in the VN.

Policy-based segmentation is limited by two main factors:

• Policies must be congured pervasively.

• Locally signicant code points are currently used for policy selection.

The conguration of distributed policies can be a signicant administrative burden, is errorprone, and causes any update in the policy to have widespread impact.

The code point used for policy selection has traditionally been an IP address and thereforelocally signicant. Because of the diverse nature of IP addresses, and because policies mustbe congured pervasively, building policies based on IP addresses does not scale well. Thus,policy-based segmentation using IP addresses as code points has limited applicability.However, other code points could potentially be used. If the code point is independent of the IP addressing and globally signicant (uniformly maintained throughout the network),all policies would look alike throughout the network, making their deployment andmaintenance much simpler.




NOTE An example of globally signicant code points are the differentiated services code points (DSCPs) used for the selection of per-hop behaviors (PHBs) in a DiffServ quality of service (QoS) architecture. Different PHB policies are selected and enforced at each hop based onthe trafc’s DSCP label. The DSCP labels identify types of trafc through the network,regardless of source/destination subnets. DSCP is just one example of a globally signicantcode point; in general, any label could serve the purpose. The use of a label (code point) toidentify types of trafc is a powerful concept and could be leveraged to identify trafc forpolicy application. Thus, if trafc is labeled appropriately, ACLs based on code pointsrather than IP addresses could provide a scalable alternative to policy-based segmentation.

Policy-based segmentation with the tools available today (ACLs) can address the creationof VNs with many-to-one connectivity requirements; it would be hard to provide any-to-any connectivity with such technology. This is the case for segments providing guest accessto the Internet, in which many guests access a single resource in the network. This ismanageable because the policies are identical everywhere in the network (allow Internetaccess, deny all internal access). The policies are usually applied at the edge of the Layer 3domain. Figure 3-4 shows ACL policies applied at the distribution layer to segment acampus network.

Figure 3-4 Hub-and-Spoke Policy-Based Segmentation

Internet

ACL ACL ACL ACL

ACL ACL ACL ACL




As a creativity exercise, you could attempt to design an IP-based policy to provide any-to-any connectivity between guests, while keeping them separate from the rest of the users!

Control-Plane-Based VirtualizationControl-plane-based virtualization restricts the propagation of routing information so thatonly subnets that belong to a VN are included in any VN-specic routing tables and updates.Thus, this type of solution actually creates a separate IP routing space for each VN. To achievecontrol-plane virtualization, a device must have many control/forwarding instances, one foreach VN. An example of control-plane-based device segmentation is a VRF.

A VRF could be looked at as a “virtual routing instance.” Each VRF will have its own RIB,

FIB, interfaces, and routing processes. Figure 3-5 illustrates VRFs.

NOTE A VRF is not strictly a virtual router because it does not have dedicated memory, process-ing, or I/O resources. In Chapter 4, we discuss other levels of device virtualization, such aslogical routers, and proper virtual routers. For now, we use the analogy just to help youunderstand what a VRF is.

Figure 3-5 Virtual Routing and Forwarding

The VRF achieves the virtualization of the networking device at Layer 3. After the deviceshave been virtualized, the virtual instances in the different devices must be interconnectedto form a VN. Thus, a VN is a group of interconnected VRFs. In theory, this interconnectioncould be achieved by using dedicated physical links for each VN (group of interconnectedVRFs). In practice, this would be inefcient and costly. Hence, it is necessary to virtualizethe data path between the VRFs to provide logical interconnectivity between the VRFs thatparticipate in a VN. The type of data-path virtualization will vary depending on how far theVRFs are from each other. If the virtualized devices are directly connected to each other(single hop), link or circuit virtualization is necessary. If the virtualized devices are

802.1q802.1q

IP Switching IP Switching

SVI orSub-Interface

(Layer 3)

SVI orSub-Interface

(Layer 3)

Each VRF Usesa Dedicated

Routing Instance

VRF

VRF

VRF




connected multiple hops apart over an IP network, a tunneling mechanism is necessary.Figure 3-6 illustrates single-hop and multiple-hop data-path virtualization.

Figure 3-6 Single- and Multiple-Hop Data-Path Virtualization

The many technologies that virtualize the data path and interconnect VRFs are discussed in

Chapters 4 and 5. The different technologies have different benets and limitationsdepending on the type of connectivity and services required. For instance, sometechnologies are good at providing hub-and-spoke connectivity, whereas others provideany-to-any connectivity. The support for encryption, multicast, and other services will alsodetermine the choice of technologies to be used for the virtualization of the transport.

NOTE Some technologies leverage the use of labels to “color” routing updates and/or datatrafc. In theory, “coloring” allows the interconnection of virtual devices without theneed for a dedicated virtual data path for each VN. For example, multiprotocol interior

Border Gateway Protocol (MP-iBGP) uses a “coloring” mechanism to differentiaterouting updates for different RFC 2547 VPNs, but the RFC 2547 forwarding plane relieson dedicated logical data paths to forward trafc (tunnels based on label switched paths [LSPs] or Layer 2 Tunnel Protocol Version 3 [L2TPv3]). Other technologies such as

Multi-Topology Routing (MTR) rely on “coloring” for both control-plane updates andforwarding, the latter implemented in a mechanism known as “class-based forwarding.”Control-plane coloring for MTR is done natively in the interior gateway protocols (IGPs)by labeling the routing updates, much like MP-iBGP does. Chapter 4 provides more detailabout the different technologies available to virtualize devices and the data path and about“coloring” for MTR.

802.1q802.1q 802.1q

IP

Tunnels allow multi-hop data-path virtualization

L2-based labeling allows single hop data-path virtualization




The VRFs must also be mapped to the appropriate VLANs at the edge of the network. Thismapping provides continuous virtualization across the Layer 2 and Layer 3 portions of thenetwork. The mapping of VLANs to VRFs is as simple as placing the corresponding VLANinterface at the distribution switch into the appropriate VRF. The same type of mappingmechanism applies to Layer 2 virtual circuits (ATM, Frame Relay) or IP tunnels, which arehandled by the router as a logical interface. The mapping of VLAN logical interfaces(switch virtual interface [SVI]) to VRFs is illustrated in Figure 3-7.

Figure 3-7 VLAN-to-VRF Mapping

So far, we have created a virtualized transport that can keep the trafc from different groupsseparate from each other. The next section introduces the functionality required at the edge

to place or authorize endpoints into the appropriate groups.

The LAN Edge: Authentication and AuthorizationAt the edge of the network, it is necessary to identify the users or devices logging on to thenetwork so that they can be assigned to the right groups.

The process of identifying the users or devices is known as authentication . Two parametersaffect the assignment of a user or devices: the identity of the user or device and the postureof the device. The posture of the device refers to the health of the device, measured by thelevel of software installed, especially operating system patches and antivirus.

When identied, the endpoints must be authorized onto the network. To this effect, the port

on which an endpoint connects is activated and congured with certain characteristics andpolicies. This process is known as authorization . One example of authorization is theconguration of a port’s VLAN membership based on the results of an authenticationprocess. Another example is the dynamic conguration of port ACLs based on theauthentication.

802.1q

interface ethernet 2/0.100ip vrf forwarding greenip address x.x.x.xencapsulation dot1q 100

interface vlan 200ip vrf forwarding blueip address x.x.x.x

VRF

VRF

VRF




NOTE For wireless access, the concept of a “port” is replaced by an “association” between clientand access point. When authorizing a wireless device, the association is customized toreect the policy for the user or device. This customization can take the form of theselection of a different wireless LANs, VLANs, or mobility groups depending on thewireless technology used.

In this two-phased process, authorization is the most relevant to virtualization. When anendpoint is authorized on the network, it can be associated to a specic VN. Thus, it is theauthorization method that will ultimately determine the mapping of the end station to a VN.For example, when a VLAN is part of a VN, a user authorized onto that VLAN willtherefore be authorized onto the VN.

The main authentication scenarios for the enterprise could be summarized as follows:

• Client-based authentication, for endpoints with client software

— 802.1x

— NAC

• Clientless authentication, for endpoints without any client software

— Web-based authentication

— MAC-based machine authentication

Regardless of the authentication method, the authorization could be done in one of the

following ways:• Assigning a port to a specic VLAN

• Uploading a policy to a port, in the form of ACLs, policy maps, or even the modular QoS command-line interface (MQC)

VLANs map into VRFs seamlessly and are the authorization method of choice when usinga VRF-based transport virtualization approach. ACL authorization could be used to achievepolicy-based transport virtualization. For a transport virtualization approach based onclass-based forwarding, the ability to dynamically load a QoS policy onto the access devicecould prove useful.

The current state of the technology provides broad support for VLAN assignment as anauthorization alternative. In the cases where policy changes based on authentication arerequired and there is only VLAN assignment authorization available, a static assignmentof a policy to a VLAN will provide the required linkage between the user authorization andthe necessary policy. The policy will in effect be applied to the VLAN; as users areauthorized onto different VLANs, they are subject to different policies.



Central Services Access: Virtual Network Perimeter 49

Central Services Access: Virtual Network PerimeterThe default state of a VN is to be totally isolated from other VNs. In this respect, VNs couldbe seen as physically separate networks. However, because VNs actually belong to acommon physical network, it is desirable for these VNs to share certain services such asInternet access, management stations, DHCP services, Domain Name System (DNS)services, or server farms. These services will usually be located outside of the different VNsor in a VN of their own. So, it is necessary for these VNs to have a gateway to connect tothe “outside world.” The outside world is basically any network outside the VN such as theInternet or other VNs. Because this is the perimeter of the VN, it is also desirable for thisperimeter to be protected by security devices such as rewalls and intrusion detectionsystems (IDSs). Typically, the perimeter is deployed at a common physical location for

most VNs. Hence, this location is known as the central services site, and the securitydevices here deployed can be shared by many VNs.

The creation of VNs could be seen as the creation of security zones, each of which has aunique and controlled entry/exit point at the VN perimeter. Routing within the VNs shouldbe congured so that trafc is steered to the common services site as required. Figure 3-8illustrates a typical perimeter deployment for multiple VNs accessing common services.Because the services accessed through the VN perimeter are protected by rewalls, we referto these as “protected services.”

Figure 3-8 Central Site Providing VN Perimeter Security

Internet

Internet

CommonServices

VPNRed

VPNBlue

VPNGreen

VPNYellow

VRF Green

VRF Yellow

VRF Blue

VRF Red

PE

Virtualized Network

FusionRouter




As shown in Figure 3-8, each VN is head ended by a dedicated rewall. This allows thecreation of security policies specic to each VN and independent from each other. To accessthe shared services, all rewalls are connected to a “fusion” router. The fusion router canprovide the VNs with connectivity to the common services, the Internet, or even inter-VNconnectivity. The presence of this fusion router should raise two main concerns:

• The potential for trafc leaking between VNs

• The risk of routes from one VN being announced to another VN

The presence of dedicated per-VN rewalls prevents the leaking of trafc between VNsthrough the fusion router by only allowing established connections (connections initiatedfrom “inside” the rewall) to return through the VN perimeter. It is key to congure therouting on the fusion device so that routes from one VN are not advertised to anotherthrough the fusion router. The details of the routing conguration at the central site arediscussed in Chapter 8, “Trafc Steering and Service Centralization.”

Figure 3-8 shows an additional rewall separating the fusion area from the Internet. Thisrewall is optional. Whether to use it or not depends on the need to keep common servicesor transit trafc in the fusion area protected from the Internet.

As mentioned, the common services could exist in a central location or in their own VN andtherefore distributed throughout the enterprise. Depending on where the common servicesare located, the VN perimeter topology will vary. Figure 3-9 illustrates the differentscenarios for common services positioning and the Internet rewall.

When the common services are not present, or are placed in their own VN (and thereforefront-ended by a dedicated rewall context) the additional Internet rewall can be removed,

as shown in scenario B.2 of Figure 3-9. If concern exists about transit trafc (between VNsor between a VN and the shared services area) being on the Internet, the rewall can be kept(see diagram A.2). The common services could be separated from the rest of the network by having their own rewall, yet not be included in a VN; this is shown in scenario B.1 inFigure 3-9.

For scenarios B.1 and B.2 in Figure 3-9, it is important to note that the fusion routeris actually part of the Internet; therefore the Network Address Translation ( NAT) poolused at the rewalls must use valid Internet addresses. The deployment of the optionalInternet rewall should follow standard Internet edge design guidance, which has beenextensively documented across networking literature. The reference designs proposed byCisco and published at http://www.cisco.com/go/srnd are good sources of information.The “Data Center: Internet Edge Design” document contains a comprehensive discussion

on the topic. We use scenario A.1 from Figure 3-9 to illustrate the relevant design anddeployment considerations, but these considerations are applicable to other scenarios.



Central Services Access: Virtual Network Perimeter 51

Figure 3-9 Common Services Positioning

Unprotected ServicesIn contrast with circuit-based technologies such as ATM or Frame Relay, most Layer 3 VPNtechnologies allow enough exibility for trafc to be leaked between VNs in a controlledmanner by importing and exporting routes between VNs to provide IP connectivity betweenthe VNs. Thus, the exchange of trafc between the VNs may happen within the IP core andnot have to pass through the VN perimeter rewalls at the central site. This type of inter-VN connectivity can be used to provide services, such as DHCP or DNS, that do not needto be protected by the central site rewall, or that would represent an unnecessary burdento the VN perimeter rewalls. Because of the any-to-any nature of an IP cloud, there is little

Internet

IP Services

Services VPN

Orange

Yellow

Green

Blue

Red

Fusion

NATNATA.1

Internet

IP ServicesOrange

Yellow

Green

Blue

Red

Fusion

NATB.1

Internet

Fusion

NATA.2

Internet

Fusion

B.2

Orange

Yellow

Green

Blue

Red

NAT

Services VPN

Orange

Yellow

Green

Blue

Red

NAT




chance of controlling inter-VN trafc after the routes have been exchanged. We refer tothese as “unprotected services.” This type of connectivity must be deployed carefullybecause it can potentially create unwanted back doors between VNs and break the conceptof the VN as a “security zone” protected by a robust VN perimeter front end. Anotherconsideration that must be made is the fact that importing and exporting routes betweenVNs precludes the use of overlapping address spaces between the VNs. We discuss the useof route-importing mechanisms for the creation of common services extranet VNs in detailin Chapter 8.

NOTE Although, these services are not protected by the VN perimeter rewalls, the IP segment towhich they belong could potentially be head-ended by a rewall and therefore “protected.”

The deployment of protected services does not preclude the deployment of unprotectedservices and vice versa. In a virtualized network, a combination of protected andunprotected services is usually provided for the different VNs. For example, the DHCP andDNS services for several VNs may be shared and accessed in an unprotected manner, whileall server farms and the Internet are also shared among the different VNs, but their accessmust be controlled by rewall policies and an IDS.

SummaryYou can use many technologies to virtualize the enterprise network. Regardless of thetechnologies of choice, they must provide the functionality required in the three areasdiscussed:

• Transport virtualization

• Edge authorization

• Central services access (VN perimeter)

The network architect should be well aware of how these functional blocks interface witheach other and always keep in mind that virtualizing the network must not come at theexpense of important resiliency and performance characteristics in the network. However,because of the new technologies put in place, there will be an impact in the operations andprocesses for the maintenance of the network. In the long term, this impact is likely to be apositive one as new operational efciencies are gained and operational costs tend to

diminish.



Summary 53

It is also important to remember that when virtualizing a network, not everything must bemigrated onto the VNs created. VN technologies are overlaid onto the existing operationalnetwork infrastructure. Therefore, the network continues to function as it did before thevirtualization, but now has VNs overlaid on top of it. The endpoints using the network couldbelong to the original network or to a VN. This provides a clear path to a phased migrationand support for groups that do not require a dedicated VN.

design a virtualized enterprise network

Documents