Definitive MPLS Network Designs [Electronic resources] نسخه متنی

Layer 3 MPLS VPN Service Design

EuroBank adopted Layer 3 MPLS VPN technology to provide a scalable method of separating its different subsidiaries into its own VPN. It also wanted to provide multiple "departmental" VPNs within one of its subsidiaries without having to maintain separate logical connections in the core network. Before this technology was available, it was typical for an Enterprise to use Ethernet VLANs and/or Frame Relay PVCs to achieve the same goal. Clearly this method was less flexible for connectivity across the WAN and less cost-efficient than that offered by the Layer 3 MPLS VPN solution. Also, this approach in general required physically separate routers per VPN, or the use of complex filters to provide the necessary separation.

EuroBank enabled MPLS on all its core links and within every POP, including any P routers and the interfaces facing the core network at the PE routers. There was no requirement to run label switching within the office sites or the data centers, except on the interfaces that face the core network. MPLS labels are distributed using Label Distribution Protocol (LDP). Figure 6-8 shows the core network and where the LDP protocol is deployed.

Intersubsidiary and DataCenter Connectivity Requirements

As previously mentioned, the EuroBank holding company consists of five subsidiaries: MainBank, EnterBank, UKI, GerBank, and SpainBank. Isolation across subsidiaries was an important aspect of the design. This meant that direct connectivity between subsidiaries had to be prevented. The MainBank subsidiary was split even further into three separate departments: Accounting, Brokerage, and Branch.

Within each subsidiary other than MainBank, as well as within each MainBank department, every device must be able to communicate with every other device.

As well as the branch and office locations, the EuroBank group has four data centers that house various servers running multiple applications. Some of these applications belong to a specific subsidiary (or department) and must be accessible only to devices from that subsidiary (or department). Every subsidiary in the EuroBank group has at least one such centralized subsidiary/department-specific application hosted on one or more dedicated servers accessible via the data centers. Other applications running in the data centers are shared and must be accessible across all the subsidiaries.

Office Location Requirements

In the UK, an office location supports staff from multiple subsidiaries. Within the MainBank subsidiary, multiple departments are supported. Therefore, multiple VPNs are necessary in the UK office locations.

For office locations outside the UK, only employees from a single subsidiary are supported, so only a single VPN is necessary.

All offices and branches need access to the shared applications in the data centers.

EuroBank Group VPN Definitions

To achieve all the necessary communication and isolation requirements just described, EuroBank defined a number of VPNs:

EnterBank EnterBank VPN

UK Insurance UKI VPN

GerBank GerBank VPN

SpainBank SpainBank VPN

MainBank Accounting VPN

MainBank Brokerage VPN

MainBank Branch VPN

Shared Applications EuroBank Shared VPN (or Shared VPN for short)

With the exception of the Shared VPN, each VPN contains routing information from the branches, offices, and subsidiary/department-specific data center application of that specific subsidiary/department, as well as any shared data center application. The Shared VPN contains routes from all the shared applications hosted in data centers and supports connectivity among those, such as for backup purposes. This model allows for easy advertisement of routes to and from private VPNs into a common VPN with shared access.

Within the Brokerage VPN, EuroBank runs sensitive applications that need their data encrypted as it passes between different brokerage locations. EuroBank used [IPSEC-ARCH] to achieve this. The details are explained in the section "EuroBank Brokerage Encryption Deployment and Design."

Route Target and Route Distinguisher Allocation

EuroBank chose to use a private autonomous system number, 65001, to support the allocation of route target and route distinguisher values. This same autonomous system number is used for EuroBank's MP-BGP process as well as for BGP-4 peering with regional MPLS VPN service providers that provide connectivity on behalf of the branch locations. The VPNs have no specific load-balancing requirements. Therefore, the same route distinguisher is used for all the VRFs in a given subsidiary/department VPN.

Table 6-2 shows the chosen values for each VPN.

Data Center Layer 3 MPLS VPN Design

Each of the data centers in the EuroBank group houses subsidiary/department-specific servers from each of the previously defined VPNs. Access to these servers from within a VPN is direct. In other words, there is no requirement to pass through a firewall or Network Address Translation (NAT) device. Each server that belongs to a given subsidiary/department VPN is configured at the switch to belong to the relevant VLAN, as defined in Table 6-2.

Each VPN that accesses the data centers does so via a VRF connection at the data center PE routers. Example 6-1 shows the data center PE router configuration (with only two VRF definitions).

Example 6-1. Data Center PE Router VRF Configuration Template

ip vrf Accounting
rd 65001:10
route-target export 65001:11
route-target import 65001:11
!
ip vrf Brokerage
rd 65001:20
route-target export 65001:21
route-target import 65001:21
!
interface GigabitEthernet 1/0.1
encapsulation dot1q 11
ip vrf forwarding Accounting
ip address address-from-/24-subnet-for-the-Accounting-VPN
!
interface GigabitEthernet 1/0.2
encapsulation dot1q 12
ip vrf forwarding Brokerage
ip address address-from-/24-subnet-for-the-Brokerage-VPN
!

Description of the Data Centers." Figure 6-9 shows how each VPN is separated at the data centers using the various VLANs. It also highlights that access to the shared applications from each subsidiary is controlled via a firewall. The firewall is necessary so that the EuroBank groups can closely control who can access the shared applications.

[PRIVATE]). In this case NAT functionality is necessary before the shared applications are accessed so as to avoid any address conflicts.

Access between subsidiary/department VPNs and the shared servers is restricted through the use of a virtual firewall instance for each subsidiary/department VPN. Traffic entering the data center switch that is destined for one of the shared servers is sent to the virtual firewall instance for the specific VPN. Then it is bridged onto a VLAN that attaches to routing and NAT functionality for access into the shared server VLAN. This is achieved using transparent mode on the firewall, which allows for the definition of virtual firewalls that have only two ports where traffic is transparently bridged between these two ports. Figure 6-10 shows the virtual firewall instances and how they interconnect, as well as the inside/outside interfaces for NAT.

Each server that hosts shared applications must have reachability information for its IP address injected into each of the subsidiaries/department VPNs. The shared servers are housed on the same /24 Ethernet segment. Therefore, only the subnet address needs to be advertised rather than all the specific shared server /32 addresses. In addition, to allow for successful routing of return traffic coming from the shared servers, the pool of "outside" addresses used by the NAT function at the switch is injected into the shared VPN.

Advertisement of this routing information is achieved through the use of Routing Information Protocol (RIP), which is configured to run between the routers inside the Shared VPN and the virtual firewalls. Each shared server uses a default gateway address that, through the use of HSRP, sends traffic to either of the exit routers in the shared VPN. Figure 6-11 shows how this routing is achieved for shared servers located on subnet 164.27.23/24.

Using this infrastructure, EuroBank can maintain the use of IP addresses from the [PRIVATE] range and still keep separation between subsidiaries/departments. Figure 6-12 shows how packets can flow between the Accounting VPN in an office site and the shared server with address 167.27.23.1, which belongs to the Shared VPN and is located in one of the data centers.

POP Layer 3 MPLS VPN Design

The branches of each of the subsidiary banks attach to either a Layer 3 MPLS VPN service provider or, as in the case of Spain, a Frame Relay provider.

As previously described, if the branch attaches to the EuroBank POP via Frame Relay, the circuit terminates on routers that are managed by the Frame Relay service provider. These are attached directly to a EuroBank PE router via a point-to-point Gigabit Ethernet interface that is associated with the relevant VRF. However, for branches that connect via a Layer 3 MPLS VPN service provider, EuroBank decided to use Inter-AS Option "A" (back-to-back VRFs) and present itself as a CE router to each service provider. This way, EuroBank could learn routes from branches attached to these service providers and also advertise routes from the relevant VPNs into the service provider MPLS VPN network. Figure 6-13 shows this connectivity.

The number of back-to-back VRF connections between the MPLS VPN service provider and EuroBank differs, depending on whether the connection is from a UK or German POP. In the case of the UK, three separate VPNs are needed: UKI, EnterBank, and MainBank Branch. However, in the case of Germany and Spain, only one VPN is necessary for the GerBank and SpainBank subsidiaries.

EuroBank runs BGP-4 on the inter-AS links to exchange the necessary routes with the MPLS VPN service provider. The connectivity from branch offices to the MPLS VPN backbone is via static routes, with floating static routes providing backup through ISDN.

Figure 6-14 shows how the shared server subnet is advertised into the UKI and MainBank Branch VPNs at a UK POP and then subsequently is advertised across the Inter-AS links.

Core MP-BGP Design

With nine POPs and four data centers, EuroBank has a total of 26 PE routers (two in each location). With just over 1100 VPN routes (which consist of branch and office location subnets) and a small number of PE routers, EuroBank decided that it was not necessary to deploy MP-BGP route reflectors in its initial deployment. Instead, EuroBank ran direct MP-BGP sessions in a full mesh between all PE routers.

UK Office Location Layer 3 MPLS VPN Design

As described earlier, EuroBank chose to use multi-VRF functionality in its UK office locations. This technology provides a cost-effective option for the deployment of multiple VPNs using a single CE router. In this case a CE router that is located at the UK office location can provide independent routing and forwarding tables (through the use of VRFs), as illustrated in Figure 6-15.

The use of multi-VRF functionality lets EuroBank reduce its acquisition costs as compared to other implementation options by not having to deploy multiple CE routers in the office locations (one CE router for every subsidiary). Instead, two multi-VRF-capable CE routers (which are necessary for redundancy in case one of the routers fails) are deployed and can support all the necessary VPNs.

As mentioned, the connectivity of an office location to a EuroBank POP depends on size and where the office is located. In some cases Ethernet technology is used, and in other cases, leased lines are used.

When Ethernet technology is used, each subsidiary VPN has a VLAN connection between the POP PE routers and the office CE routers, as shown in Figure 6-16.

 hostname office-PE1  
!
ip vrf Accounting
rd 65001:10
route-target export 65001:11
route-target import 65001:11
!
ip vrf Brokerage
rd 65001:20
route-target export 65001:21
route-target import 65001:21
!
router bgp 65001
!
address-family ipv4 vrf Accounting
neighbor multi-vrf-CE-address remote-as 65002
neighbor multi-vrf-CE-address as-override
!
address-family ipv4 vrf Brokerage
neighbor multi-vrf-CE-address remote-as 65002
neighbor multi-vrf-CE-address as-override
 hostname multivrf-CE1  
!
ip vrf Accounting
rd 65001:10
!
ip vrf Brokerage
rd 65001:20
!
router bgp 65002
!
address-family ipv4 vrf Accounting
redistribute ospf 100
neighbor PE-router-address remote-as 65001
!
address-family ipv4 vrf Brokerage
redistribute ospf 200
neighbor PE-router-address remote-as 65001