Managed Central Services

We stated that VRFs are used for storing VPN routes. Packets coming from a VPN are looked up in a VRF and forwarded to the destination PE. We also briefly discussed how Internet access can be provided to the VPN customers. We also learned that a protocol, such as NAT, can be made VRF-aware to understand the VRF context. This enables the automatic performance of address translation from private to public addresses without compromising security or connectivity. The concept was to make a protocol or service (address translation) so that it could be used to offer the same service to any VPN.

This is called managed central or shared service. A number of SPs who have deployed MPLS VPNs and are growing their networks each day are also interested in what is next with MPLS VPNs. Managed central services includes any service that is deployed centrally and offered as a value add to all the VPNs.

Now let us consider a few services that service providers might be interested in offering to enterprise customers or that large enterprises might be interested in offering to the VPN clients:

• Managed hosting

• Content distribution

• IP address management

• Redundancy solutionshot standby solutions

• Managed security

• Managed Internet access

• Subscriber self-management

• On-demand QoS for VPNs

Each of the previously listed service types is designed to create a centralized service that can be configured and hosted at a central location and can easily be shared across the VRFs and VPNs. In this case, by simply making them VRF-aware, a single service can be shared across the different VPNs.

Making Applications and Services VRF-Aware

Protocols and services running on a network element must be VRF-aware and must be able to distinguish between requests from VPN A and VPN B. Otherwise, packets will be forwarded on the wrong paths and to the wrong destinations. For example, suppose a network element, in this case a router, has voice ports and supports voice over IP (VoIP). The router also supports a VoIP signaling protocol, such as H.323 or SIP. When this router is used in a VPN context to offer VPNs services to multiple customers and voice services are being targeted towards these customers; the router must be able to distinguish between a VoIP signaling request from VPN A and one from VPN B; perform a correct routing table lookup; and then forward the signaling requests. Note the distinction in function between voice signal differentiation and VPN instantiation. If the VoIP signaling protocol is not VRF-aware, the voice call requests from the VPNs would be looked up in the global routing table and either sent to the wrong voice gateways or dropped. Dropping the requests does less damage than forwarding the requests to incorrect destinations.

To make protocols or features VRF-aware, the protocols or features must be implemented to look beyond the global routing table for information into VRFs. Internally a VRF can be implemented as an additional routing table that is handled by the routing protocol. In the case of Layer 3 VPNs, we have seen how the VRF is handled by BGP. The following are some examples of protocols that are or can be made VRF-aware:

• VRF-aware address management (NAT, DHCP, ODAP, and DHCP Relay)

• VRF-aware NAT

• VRF-aware firewall

• VRF-aware HSRP/VRRP (Virtual Router Redundancy Protocol)

• VRF-aware SIP/H.323/MGCP (Media Gateway Control Protocol)

• VRF-aware management tools (Ping and SNMP)

• VRF-aware policy routing

To illustrate the point further, let us now discuss one of these in detail.

VRF-Aware Address Management

Let us assume that address management is offered as a service to the end customers. This is frequently the case when the ISP offers DHCP service to broadband users. In this context, let us also assume that an L3VPN provider is planning to offer address management service to small enterprises that have a few sites per VPN and a small number of IP devices per site. Now an SP can develop an attractive service for this small enterprise and offer IP address management by offering DHCP and NAT service as part of the bundled package of VPN connectivity.

A corresponding cost is associated with IP address management that comes with offering DHCP and NAT services to enterprise customers. For each enterprise customer to which the SP sells this service, a dedicated gateway and server must be deployed to avoid the confusion of a 10.1/16 address from VPN A versus a 10.1/16 from VPN B. This can be cumbersome to implement and manage. Let us now see how this would change if we had VRF-aware NAT and VRF-aware DHCP/DCHP Relay.

The SP can deploy VRF-aware NAT and DHCP Relay at the PE router itself without a dedicated gateway or external server. So, the PE is now enabled with VRF-aware DHCP and NAT function. When a client in the VPN sends a DHCP request, the PE now understands the DHCP request, appends the VPN name in the options field, and sends the DHCP request to a centrally located DHCP server. The DHCP server recognizes the VPN name, allocates a new address in the VPN A address pool, and sends a DHCP reply. The DHCP reply reaches the PE, and the PE then forwards the DHCP reply to the VPN client on the correct interface to the VPN client.

In this manner, instead of replicating DHCP servers and NAT gateways, by making DHCP and NAT VRF-aware, a cost-effective, alternative deploying address management system is found. The same principle can be extended to other protocols and services. Refer to Figures 5-6 and 5-7 for before and after scenarios.

Figure 5-6. Managed ServicesBefore

Figure 5-7. Managed ServicesAfter VRF-Aware Services

Managed shared/central services is an excellent way for a service provider to add value and move beyond plain IP VPN connectivity for a better bottom line. In this section, you have seen how MPLS makes that possible.