Figure 1
Classic centralized extranet approach
As you might imagine, life is never so easy, and most of the participants in complex extranets had to use multiple solutions. A commercial bank might need to exchange data with the central bank, the stock exchange (supporting its brokerage division), financial clearinghouses, information services (Reuters) and numerous other sources. All these applications usually have to be accessible from the employee’s desk, not from a dedicated workstation. The results were in most cases spaghetti-like constructions of complex Network Address Translation (NAT) rules, sometimes implemented on multiple NAT devices (see Figure 2) due to routing problems caused by the extranet providers (some of them assumed that they could use default routing from the “dedicated workstations” to the core of their network).
Figure 2
Managing multiple extranets: participant’s perspective
A production-grade solution to this mess (MPLS VPN) has existed for several years, but is rarely used since network engineers believe it’s usable purely in the service provider world. This article describes how you can use the MPLS VPN technology to create flexible extranets that are easily integrated with the existing networks of external partners.
Case Study Description
Throughout the article, we’ll use a simple non-redundant extranet implementation, linking multiple large enterprise networks with a provider of extranet services (Figure 3). The extranet services are offered on a single server with the private IP address 10.17.3.2. This IP address is mapped to the “public” IP address 192.168.0.1 to ensure that all extranet participants can access the server regardless of their internal IP addressing scheme.
Figure 3
Case study topology and addressing
The extranet should allow simple integration of participants with no extra action (apart from provisioning a link to the extranet router) required on the part of the participants. The extranet router (exCore router in Figure 3) should support either static routing or a dynamic routing protocol with each participant’s network.
Note
The case study uses a non-redundant design to simplify the description of the architecture. Readers familiar with NAT and the MPLS VPN technology will easily extend the architecture to redundant scenarios. You can also get consulting, design and deployment help from NIL’s professional services team.
Classic Extranet Challenges
Traditional extranets (IP networks implemented between organizations) usually suffer from IP addressing issues caused by widespread use of private IP addressing. Almost all enterprise networks use private IP addresses internally (due to shortage of public IP addresses, it’s impossible to get them for internal use), resulting in frequent address overlaps (for example, many enterprise networks use the IP subnet 10.0.1.0/24). A classic extranet cannot support hosts with overlapping addresses; the organizer of the extranet is thus forced to give an address range to each participant (Figure 4).
Figure 4
Centrally enforced private IP addressing in an extranet
In most cases, the extranet participants need access to the extranet services from deep within their networks. While you could invent clever routing schemes in which the IP addresses allocated to each participant would be spread around the network, the most common solution involves NAT between the participant’s internal network and the extranet. If the extranet provider uses private IP addresses on the servers offering the extranet services, those addresses might clash with the addresses used in the participant’s network, requiring dual NAT configuration (Figure 5).
Figure 5
Participant-side NAT in an extranet with centralized private IP addressing
MPLS VPN Architecture
A flexible extranet solution has to satisfy two requirements:
Existing networks of the extranet participants have to be integrated seamlessly with the extranet routing.
NAT is inevitable due to widespread use of private IP addresses and resulting address overlap in participants’ networks.
Note
Even though most MPLS documents claim that you can implement extranets with overlapping VPN topology, these texts usually decide to ignore the address overlap issues.
You can achieve maximum flexibility if you isolate each extranet participant in an independent routing instance with its own IP routing table and routing protocol. MPLS VPN technology uses the term virtual routing and forwarding (VRF) table for a routing instance; you would have to create a VRF for each participant on the extranet (exCore) router as shown in Figure 6. The extranet server will be reachable through the global IP routing table.
Figure 6
Virtual routing tables on the exCore router
The exCore router will also perform all NAT functions needed in the extranet. A global NAT rule will define the translation of outside (server’s) addresses. Each VRF will have another rule defining the translation of inside (client’s) addresses, as illustrated in Figure 7.
Figure 7
Network Address Translation in virtual routing tables on exCore router
This architecture ensures that each participant remains completely isolated from all other participants. Please note that this is not the overlapping VPN topology; there is no exchange of routing information between a participant’s network (VRF on the exCore router) and the provider of the extranet services (the global IP routing table on the exCore router). All traffic flows between the VRFs and the global routing table are stitched together with static routing and NAT translations.
Implementation of the Extranet Architecture
Use the following configuration steps on the exCore router to implement the extranet architecture described in the previous section:
Configure the global IP routing.
Configure the NAT of outside IP addresses.
Configure the VRF and the IP routing process for each customer.
Configure the NAT-related routing in the customer VRF.
Configure the NAT pool and NAT in the customer VRF.
Configure the global IP routing
The global IP routing configuration depends on the complexity of the extranet provider’s network. In the case study, we’ll use a very simple network consisting of a single IP subnet linking the extranet server with the exCore router. The IP addresses used by the NAT pools will belong to the same IP subnet to simplify the routing configuration. The global configuration of the exCore router is shown in Listing 1.
Listing 1
Global configuration of the exCore router
service timestamps debug datetime msec
service timestamps log datetime msec
!
hostname exCore
!
logging buffered 4096
!
ip subnet-zero
!
ip cef
!
interface Loopback0
ip address 10.0.1.1 255.255.255.255
!
interface FastEthernet0/0
description LAN link to the Extranet server
ip address 10.17.3.1 255.255.255.0
!
ip classless
!
end
Configure the outside NAT
Before connecting the first customer to the exCore router, you need to configure the global NAT. The customer networks will be configured as inside interfaces and the server LAN as the outside interface.
Note
If you need any-to-any NAT between participants’ networks, you could use the NAT virtual interface feature.
The global ip nat outside source command will define the translation of the server’s private IP address (10.17.3.2) used within the extranet provider’s network to the “public” IP address (192.168.0.1) advertised to the participants. We’ll also configure NAT logging to keep router-level track of participants’ activities (the server logs will provide additional feedback). The configuration of the outside NAT is included in Listing 2.
Listing 2
Outside NAT configuration
interface FastEthernet0/0
description LAN link to the extranet server
ip nat outside
!
ip nat log translations syslog
!
ip nat outside source static 10.17.3.2 192.168.0.1
Configure the VRF and the IP routing process for each customer
When you connect a new participant to the extranet, you have to do the following:
Create a VRF for the participant, specifying unique route distinguisher (RD) and router target (RT).
Note
Private autonomous system (AS) 65000 is used in the RD and RT values. If you want to build a large-scale distributed solution, you should use your public AS number as the high-order part of RD and RT.
Configure the interface that links the exCore router to the participant’s network. Make sure that you’ve configured the VRF to which the interface belongs.
Create a VRF-specific routing process.
A sample configuration for a customer running OSPF with the exCore router is included in Listing 3.
Warning
The capability vrf-lite router configuration command should be used when configuring OSPF in a router using MPLS VPN without the MPLS VPN backbone.
Listing 3
Configuration of a sample customer running OSPF with the exCore router
ip vrf Customer_2
rd 65000:2
route-target export 65000:2
route-target import 65000:2
!
!
router ospf 2 vrf Customer_2
log-adjacency-changes
capability vrf-lite
network 0.0.0.0 255.255.255.255 area 22
!
interface Serial1/1
description Link to Customer_2
ip vrf forwarding Customer_2
ip address 10.0.7.17 255.255.255.252
encapsulation ppp
A security-conscious customer might want to use static routing with the extranet provider. In this case, simply configure a default static route pointing toward the customer’s router (Listing 4).
Listing 4
Static routing in customer VRF
ip vrf Customer_1
rd 65000:1
route-target export 65000:1
route-target import 65000:1
!
ip route vrf Customer_1 0.0.0.0 0.0.0.0 Serial1/0 10.0.7.14
!
interface Serial1/0
description Link to C1A
ip vrf forwarding Customer_1
ip address 10.0.7.13 255.255.255.252
Configure the NAT-related routing in the customer VRF
After you’ve configured static routing or a dynamic routing protocol with an extranet participant, the VRF routing table on the exCore router contains routes for all IP prefixes in the customer network. (The IP routing table resulting from the configuration in Listing 4 is shown in Listing 5.) The return packets (from the extranet server to the hosts in the customer network) will thus be routed properly from the exCore router to the participant’s network.
Listing 5
VRF routing table for a customer using static routing
exCore#show ip route vrf Customer_1 | begin Gateway
Gateway of last resort is 10.0.7.14 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 10.0.7.14, Serial1/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.7.12/30 is directly connected, Serial1/0
L 10.0.7.13/32 is directly connected, Serial1/0
As you can see from Listing 5, the VRF routing table still has no route toward the extranet server. If the exCore router receives a packet sent from a host in the participant’s network to the server’s public IP address 192.168.0.1, the packet will be dropped. To ensure proper propagation of packets sent to the server, you have to configure a static host route in each VRF. The destination address of the static route should be the server’s public IP address (192.168.0.1/32), the outgoing interface is the global LAN interface of the exCore router (Fast Ethernet 0/0) and the next-hop address is the actual (private) IP address of the server (10.17.3.2). The static route configuration for VRF Customer_1 is displayed in Listing 6.
Warning
You have to specify the IP next-hop on VRF static routes pointing to multi-access interfaces. In our design, you must use the global keyword next to the next-hop IP address to indicate that the router should use the global CEF adjacency table to resolve it.
Listing 6
Static host route toward the extranet server in the customer VRF
ip route vrf Customer_1 192.168.0.1 255.255.255.255 →
FastEthernet0/0 10.17.3.2 global
Note
Each VRF is a completely independent instance. The same static route thus has to be configured for each VRF.
If you’re running a participant-specific routing protocol on the exCore router, you have to redistribute the static route into the dynamic routing protocol (Listing 7). If you use static routes toward the customer, the customer has to create a static host route pointing toward the extranet server on its border router and redistribute the static route into its routing protocol (Listing 8).
Listing 7
Redistribution of VRF static route into the VRF routing protocol
ip route vrf Customer_2 192.168.0.1 255.255.255.255 →
FastEthernet0/0 10.17.3.2 global
!
router ospf 2 vrf Customer_2
redistribute static metric 10 subnets
Listing 8
Routing toward the extranet server on the customer’s border router
hostname customerBorderRouter
!
interface Serial1/0
description Link to NAT(ROUTER) S1/0
ip address 10.0.7.14 255.255.255.252
!
router eigrp 33
redistribute static metric 256 100 255 1 1500
network 0.0.0.0
!
ip route 192.168.0.1 255.255.255.255 Serial1/0
Configure the NAT pool and NAT in the customer VRF
The last step in the configuration process links the customer’s VRF with the global IP routing table with a source IP address NAT. For each customer, you have to configure a NAT rule that will tell the router to perform the translations of source IP addresses for all packets sent toward the extranet server.
To support a large number of clients accessing the extranet server from the participant’s network, you should use port address translation (PAT) in combination with a NAT pool. Each NAT pool can be used in a single ip nat inside configuration command; therefore, you need a dedicated pool for each participant VRF. The global IP routing on the exCore router is simplified if you take the IP addresses for the NAT pool from the IP subnet assigned to the global LAN interface of the exCore router. Unless you expect more than approximately 60,000 sessions from a single participant, a single IP address assigned to the participant’s pool should be enough. The pool definitions for the first two extranet participants are shown in Listing 9.
Listing 9
NAT pool definitions on the exCore router
ip nat pool Customer_1 10.17.3.31 10.17.3.31 prefix-length 24
ip nat pool Customer_2 10.17.3.32 10.17.3.32 prefix-length 24
After creating the NAT pool, you can configure NAT for each VRF. I’ve created an access list to limit the address translations to ICMP and Web traffic going toward the extranet server and used it in the ip nat inside source list configuration commands (Listing 10).
Listing 10
Per-VRF NAT configuration on the exCore router
ip nat inside source list xServer pool Customer_1 → vrf Customer_1 overload
ip nat inside source list xServer pool Customer_2 → vrf Customer_2 overload
!
ip access-list extended xServer
permit tcp any host 192.168.0.1 eq www
permit icmp any host 192.168.0.1
Note
You have to use the overload keyword in the NAT configuration to allow multiple clients to use the same global IP address. You also have to specify the customer VRF in the ip nat inside source command; otherwise, the rule will not be applied to packets entering the router through a VRF interface.
Summary
Tight integration of MPLS VPN technology with Network Address Translation available on Cisco routers from IOS release 12.3 enables you to build flexible extranets that are easily integrated with the existing networks of the extranet’s participants. The only provisioning requirements placed on network engineers configuring the participant’s network are the configuration of IP routing toward one (or a few) well-defined external IP addresses, and the implementation of the network’s security policies on the newly configured link.
The MPLS VPN technology significantly simplifies the job of the extranet provider:
Each participant has a unique, completely isolated routing instance.
Participants can use any modern routing protocol.
The solution supports overlapping IP addresses in the participants’ networks.
The extranet server can use a public IP address or a private IP address that is translated into a public address when presented to the extranet participants.
There is no exchange of the routing information between the extranet provider and the participants; traffic flows between the clients and the common server are established solely based on address translation rules.
Questo commento è stato eliminato da un amministratore del blog.
RispondiElimina