Mpls VPN

Layer 3 MPLS VPN Service Design Page 1 of 13
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.
Figure 6-8. EuroBank LDP Deployment

[View full size image]
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.
mk:@MSITStore:L:\Cisco.Press.Definitive.MPLS.Network.Designs.Mar.2005.eBook-LiB\... 8/6/2019
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:
l EnterBank EnterBank VPN
l UK Insurance UKI VPN
l GerBank GerBank VPN
l SpainBank SpainBank VPN
l MainBank Accounting VPN
l MainBank Brokerage VPN
l MainBank Branch VPN
l 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.
Table 6-2. Route Target and Route Distinguisher

Allocation
VPN Route Target Route Distinguisher
MainBank Accounting 65001:11 65001:10
MainBank Brokerage 65001:21 65001:20
MainBank Branch 65001:31 65001:30
EnterBank 65001:41 65001:40
UKI 65001:51 65001:50
SpainBank 65001:61 65001:60
GerBank 65001:71 65001:70
EuroBank Shared VPN 65001:1 65001:1
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
!
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
!
As shown in Example 6-1, each VPN attaches to a local switch in the data center using Gigabit
Ethernet VLANs. The VLAN assignments for each VPN are shown in Table 6-3.
Table 6-3. VPN VLAN Allocation

Subsidiary VLAN
MainBank Accounting 11
MainBank Brokerage 12
MainBank Branch 13
EnterBank 14
UKI 15
SpainBank 16
GerBank 17
EuroBank Shared VPN 1
The physical layout of each data center is as presented in the earlier section "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.
Figure 6-9. Data Center Physical Connectivity to VPN and Shared

Applications
In an environment of mergers and acquisitions, it is not unusual for one or more

subsidiaries/departments of the same holding company to use private IP addresses (see
[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.
Figure 6-10. NAT and Virtual Firewall Connectivity

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.
Figure 6-11. Routing Between the PE Router and Shared Servers
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.
Figure 6-12. Traffic Flow Between the Office and the Shared Server
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.
Figure 6-13. InterAS Option "A" with MPLS VPN Service Providers
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.
Figure 6-14. Advertising VPN Routes Across 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.
Figure 6-15. CE Router FIB/RIB Separation Using Multi-VRF

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.
Figure 6-16. PE Router-to-CE Router Connectivity with Multi-VRF

If leased-line access is used, Frame Relay encapsulation is used on the link between the PE router
and the multi-VRF-capable CE routers to separate the different VPNs. Each VPN is allocated a
separate Data Link Connection Identifier (DLCI). Within the office location, VLANs are still used.
The configuration of a multi-VRF-capable router contains a number of significant differences from

the usual configuration of a [2547bis] PE router:
l Multi-VRF capability does not require the configuration of MPLS forwarding on its outbound
interfaces facing the core network. This is because labels are not imposed when packets are
sent from the multi-VRF CE router toward the PE router in the POP.
l The multi-VRF CE router does not need MP-BGP configured. It simply uses a standard routing
protocol (such as BGP-4, OSPF, RIP, and so on) on the link with the PE router.
l The incoming interface at the CE router is associated with a VRF, as is the CE router-to-PE
router link. A normal PE router does not associate any upstream links with a particular VRF.
Routing Within Each Multi-VRF VRF

EuroBank decided to run external BGP on the multi-VRF CE router-to-PE router links and use the
same BGP autonomous system number for all the VPNs. The use of a single autonomous system
number was possible because each VPN is placed in a separate BGP VRF context, one for each VPN
accessible via the multi-VRF CE routers. Furthermore, EuroBank had no requirement to leak routes
between different VPNs. Therefore, it was not possible to have a routing conflict (such as an AS-
path mismatch) between VPNs.
Within each office and data center site, a separate OSPF process was configured for each VPN so
that all subnets for that VPN could be learned from the site. Example 6-2 provides the configuration
of an office PE router (with only two of the VPNs shown) and the corresponding multi-VRF CE
router.
Example 6-2. Office PE Router/CE Router VRF Configuration Template

with BGP
hostname office-PE1
!
ip vrf Accounting
rd 65001:10
!
ip vrf Brokerage
rd 65001:20
!
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
EuroBank Multicast Deployment and Design

EuroBank currently runs only Multicast traffic in its large office sites in the UK. This is restricted to
run within the EnterBank subsidiary only. EuroBank has no requirement for Multicast applications
at the branch offices of any subsidiary and does not deploy it in Germany or Spain either.
Because its Multicast deployment is limited to the EnterBank VPN in large UK offices only, EuroBank
chose to run Multicast in the EnterBank routing instance (as opposed to in all VPNs). At the multi-
VRF CEs, EuroBank deploys the Multicast VPN (mVPN) solution (which you read about in previous
chapters) to isolate the multicast from other subsidiary VPNs. Having said this, EuroBank is
beginning to see some signs that isolated Multicast might be necessary between its different
subsidiaries. If this happens, it will consider deploying mVPN inside other subsidiary VPNs.
EuroBank Brokerage Encryption Deployment and Design

The brokerage location in MainBank and the New York brokerage office must be able to exchange
information that, based on its sensitivity, must be encrypted. To provide this service, EuroBank
chose to use [IPSEC-ARCH] tunnel mode between the CE routers in a brokerage location to which
any servers and clients that need encryption are attached.
Because of the relatively small number of endpoints that need encryption, the configuration of
[IPSEC-ARCH] is statically defined with relevant source/destination prefixes that may be matched
using a crypto-map. If a packet matches one of the destinations configured in the crypto-map, it is
encrypted using the information exchanged with the gateway attached to that destination.
Figure 6-17 shows how a host with address 10.7.1.1 sends traffic across an IPSec tunnel if it is
destined for any host on remote subnet 10.8.1/24.
Figure 6-17. IPSec Between the New York Office and MainBank Brokerage
VPN

Mpls VPN

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Mpls VPN

Caricato da

Copyright:

Formati disponibili

Layer 3 MPLS VPN Service Design Page 1 of 13

Layer 3 MPLS VPN Service Design

Figure 6-8. EuroBank LDP Deployment

Intersubsidiary and DataCenter Connectivity Requirements

Office Location Requirements

EuroBank Group VPN Definitions

l EnterBank EnterBank VPN

l UK Insurance UKI VPN

l GerBank GerBank VPN

l SpainBank SpainBank VPN

l MainBank Accounting VPN

l MainBank Brokerage VPN

l MainBank Branch VPN

Route Target and Route Distinguisher Allocation

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

Table 6-2. Route Target and Route Distinguisher

Data Center Layer 3 MPLS VPN Design

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

Table 6-3. VPN VLAN Allocation

Figure 6-9. Data Center Physical Connectivity to VPN and Shared

In an environment of mergers and acquisitions, it is not unusual for one or more

Figure 6-10. NAT and Virtual Firewall Connectivity

Figure 6-11. Routing Between the PE Router and Shared Servers

POP Layer 3 MPLS VPN Design

Figure 6-14. Advertising VPN Routes Across Inter-AS Links

Core MP-BGP Design

UK Office Location Layer 3 MPLS VPN Design

Figure 6-15. CE Router FIB/RIB Separation Using Multi-VRF

Figure 6-16. PE Router-to-CE Router Connectivity with Multi-VRF

The configuration of a multi-VRF-capable router contains a number of significant differences from

Routing Within Each Multi-VRF VRF

Example 6-2. Office PE Router/CE Router VRF Configuration Template

EuroBank Multicast Deployment and Design

EuroBank Brokerage Encryption Deployment and Design

Potrebbero piacerti anche