Enterprise Segmentation Requirements

Why segment the enterprise network? The main driver is security to mitigate worms and provide virus containment that reduces global service impact. There are three types of VPNs:

• Server VPNs for business-critical applications

• User VPNs for standard production

• Global VPNs for guest access and VoIP

Enterprise virtualized network services for Acme includes firewalls, intrusion detection, and VPN service modules such as IPsec and load balancers. VLAN "awareness" also comprises an enterprise virtualized network service. So when exploring enterprise segmentation requirements, it is important to note what capabilities will be applied to the designated service segments, as shown in Figure 3-1.

Figure 3-1. End-to-End Enterprise

Traditionally, the most common approach to designing campus networks has been one that is both hierarchical and modular. Hierarchy is defined by network roles assigned from the center of the network toward the edge: core, distribution, and access. Modularity is defined by grouping distribution switches to provide modular access to the core for entire physical network areas. Additionally, some smaller enterprises have collapsed distribution and core layers to a single core/edge layer.

One key element of providing scalability and high availability in a campus network is restraining the reach of Layer 2 failure domains by deploying a Layer 3 (routed) core and distribution, which keeps the surrounding Layer 2 domains isolated from each other in terms of failure propagation. The net result of this type of design is a network that leverages IP routing in its core and bridging toward its edge. The size of the Layer 2 and Layer 3 domains is debatable. Some engineers advocate the use of Layer 3 switching everywhere (even in the wiring closet), and others preach the benefits of using Layer 2 switching over most of the network, except for the core.

There is an option to use virtual routing/forwarding (VRF) to extend VPNs in cases where the platform at the edge of the Layer 3 domain does not support Multiprotocol Label Switching (MPLS). This is discussed at Cisco.com under the heading of multi-vrf CE. All the points discussed so far for VLAN-to-VPN mapping still apply. In this case, the edge of the Layer 3 domain acts as a CE, so two issues need to be addressed. One is the segmentation of the PE-CE link to transport the traffic for the different VPNs separately, and the other is the updating of the routing information between PE and CE, or PE-CE routing. The first issue is handled in the campus by means of 802.1Q trunking over an Ethernet link.

Whatever the case, any segmentation of traffic achieved over the Layer 2 switching domain by means of VLANs is lost in the routed Layer 3 core. In many cases, it is desirable to preserve such segmentation over the routed core and create closed user groups while centralizing network services (Internet access, DHCP, and server farms) and enforcing security policies. MPLS VPNs provide a scalable manner of segmenting the routed portion of the network to achieve the desired result.

Deploying MPLS VPNs in the campus should be approached as a nondisruptive enhancement to the existing routed infrastructure. This is largely because MPLS VPNs are simply overlaid onto the routed domain, thus preserving existing services and scalability while adding the benefits and versatility of a network virtualized by means of Layer 3 VPNs.

Overlaying MPLS Layer 3 VPNs onto a hierarchical campus network involves expanding the roles of the access, distribution, and core switches to include the VPN responsibilities of provider (P), PE, and, in some cases, CE. For this discussion, assume that the switch that is the first Layer 3 hop (where VLANs are terminated and IP routing starts) plays the PE role. Thus, in this example, the distribution switches play the role of PE routers, and the core switches play the role of P routers from the VPN perspective. Because the access switches are Layer 2 devices, no CE role is to be played in this network.

Mapping VLANs to VPNs in the Campus

Because virtualization is achieved by means of VLANs in the Layer 2 portion of the network, although MPLS VPNs virtualize the routed portion of the network, you must map the VLANs to the VPNs and vice versa to obtain end-to-end virtual networks.

Mapping of VLANs to VPNs happens in the PE router for full MPLS VPN deployments or on the CE router for VRF-lite extended deployments. To achieve a mapping, it is sufficient to include a Layer 3 interface that belongs to the VLAN in the VRF corresponding to the desired VPN. Thus, no specific commands are necessary to map VLANs into VPNs. A VLAN is mapped into the VPN after it is made a subnet within the corresponding VRF at the edge of the routed domain. The VLAN acts as a logical interface associated with a given VRF. Therefore, any attribute learned from that interface becomes part of the VPN.

A switched virtual interface (SVI) can be used as the Layer 3 interface for VLAN 100, for example. The use of SVIs as the point of routing for a given VLAN (default gateway) is a well- established practice in campus switching deployments. This approach allows the aggregation of traffic from many wiring closets onto a single virtual Layer 3 interface.

Note

Aggregating traffic from different wiring closets connected to a VLAN and forwarding that aggregated traffic to an SVI is called local switching.

Because any given VLAN cannot be associated to multiple Layer 3 interfaces, you can only cater to traffic from a single switch connected to the PE router by a dot1q trunk. For example, if multiple (Layer 2) switches with VLAN 100 traffic are connected to the PE router, you must insert an aggregation switch in front of the PE to be able to map all traffic onto the red VPN with the preceding configuration. Alternatively, the network engineer could choose to use several separate VLAN IDs and map them to a single VPN. Managing this scheme becomes more complex as the number of subnets and VLAN IDs increases. The main advantage of such an approach is that it can potentially eliminate the use of spanning tree.

In general, the best practice is to use SVIs and rely on local switching to aggregate the different switches. This approach has the advantage of being able to map a single VLAN to a VPN. Care must be used when designing the access redundancy in this scenario. This is the well-studied situation in which a common VLAN exists on many access switches. To provide effective redundancy, the topology must include a Layer 2 link between the distribution switches, which are acting as PEs or multilite VRF CEs. Such links allow spanning tree and HSRP (Hot Standby Router Protocol) to operate together properly. Without this alteration in the topology, the convergence times of spanning tree could put HSRP in a state that will cause packets to be black-holed.

One of the most important aspects of deploying MPLS VPNs in a campus is that it allows every VPN to use services and policies that are centrally available, yet private to each VPN. Thus, by defining the VPN routing such that there is a single point of access into and out of the VPN, security policies that used to be distributed across the campus and were therefore hard to manage can now be enforced at this single point of access and are much simpler. This method also allows different VPNs to share a common firewall appliance that provides individualized policies by associating a separate virtual firewall to each VPN.

The key to centralizing services in the campus is to provision the routing within each VPN in such a way that there is a single, common point of ingress and egress among all of them. In service provider terms, this equates to the Internet. In campus terms, this could or could not be associated to the Internet (though it generally is). Thus, the Internet is a transit zone for VPNs to communicate with each other. To reach this transit zone, all traffic must go through a firewall in which security policies are enforced. Services could reside in the transit zone. However, if the transit zone is actually the Internet, an extra firewall is required, and services are better off placed in a Services VPN.

Note

Firewalls are actually inserted outside of each VPN (on the VLAN that is mapped to the VPN). So at this point, this is equivalent to a problem of traditional IP routing between different networks that have a firewall at the headend.