8

Virtual Private Networks (VPNs)

Traditionally, organizations wishing to build a communications network between various remote sites were forced to build a private network from leased lines. This was an expensive and somewhat inflexible method of providing communications between sites. However, then there was no real alternative. Now, there is a viable alternative. Virtual Private Networks are intended to provide a means to provision connections between remote sites with the same characteristics as private leased lines but at a fraction of the price to the customer.

The first virtual private networks were based on Frame Relay and ATM. These two transport media permit carriers to provide virtual circuits between customer sites over a shared core infrastructure. It was possible for carriers to flexibly provision services allocating bandwidth to individual virtual circuits with fine granularity and to allow customers to send more traffic than was guaranteed when the network was lightly loaded.

However, as carriers also became ISPs, they found they were operating several networks in parallel. They wanted to reduce the administrative and operational costs of operating all their networks by converging all their services onto a single IP-based network. If such a move was to work, then VPNs would be one of the main services that would have to be transferred from ATM and Frame Relay onto the new converged network. Below, we look at the various mechanisms used to implement VPNs over an IP-based core.

8.1 VPNS AT LAYER 3

8.1.1LAYER 3 VPN (RFC 2547BIS)

L3VPN is a mechanism whereby a provider can create a virtual private network at Layer 3. In an L3VPN, the CE ‘peers’ with and exchanges routing information with the Provider

Designing and Developing Scalable IP Networks G. Davies

2004 Guy Davies ISBN: 0-470-86739-6

110	VIRTUAL PRIVATE NETWORKS (VPNs)

Edge LSR (PE). The PE routers on the service provider’s network have knowledge of the customers’ routing information. The routing information exchange between CE and PE can achieved using one of a number of protocols. Those most commonly implemented are RIP, OSPF and BGP. It is also possible to use static routing on the PE and a static default on the CE. This information is redistributed at the PE into multiprotocol BGP and is exchanged with all other PEs in the same VPN. The label information is carried in extended BGP communities (draft-idr-bgp-ext-communities-06.txt).

Each PE must maintain a virtual routing and forwarding table (VRF) for each of the VPNs connected to any PE in the entire network. This VRF contains all the routing information for all sites in the VPN. The consequence of this is that all the PEs will contain the complete routing information for all sites in all VPNs. Herein lies the first major scaling challenge with L3VPN. As the total number of VPNs grows, so does the requirement placed upon all the PEs, even if they are not attached to any sites in the new VPN. In Figure 8.1 there are four PEs, each with one or more of the Red, Green and Blue VPNs attached. However, all four PEs must maintain routing state for all three VPNs, even though three of the four have no need for all that state. In addition, as the number of prefixes in each VPN grows, that growth is spread to all PEs, again irrespective of the need for that PE to maintain those routes.

One mechanism to reduce the burden on the PEs is to use route reflectors. If you use route reflectors, only the reflectors need to maintain state for all VPNs. Each PE (assuming it is not one of the route reflectors) only needs to maintain state for those VPNs of which its adjacent CEs are members. In Figure 8.2, the P1 router from the previous figure has been configured as a route reflector and each of the PEs only has a single BGP neighbour. Only RR and PE2 require all the state. Each of the other PEs has a reduced load.

Cisco and Juniper have slightly different recommendations on the best practice with respect to route reflection. Cisco strongly recommends installing separate devices attached in a central location in the core of the network specifically to perform the route reflection function. These devices do not need huge forwarding capabilities since they are not in the forwarding path of any major flows. The only data going to them is routing

Red		Blue
PE1	P1	PE4
Blue		Green
Red
PE2		PE3
Blue	Red Green Green	Red

Figure 8.1 MPLS Layer 3 VPN example

8.1 VPNS AT LAYER 3		111
Red		Blue
PE1	RR	PE4
Blue		Green
Red
PE2		PE3
Blue	Red Green Green	Red

Figure 8.2 MPLS Layer 3 VPN example using route reflection

protocol updates. However, in order to maintain and update the vast amount of state, they do require very large amounts of memory and powerful processors. On the other hand, Juniper generally suggests that it is unnecessary to use a separate device with the inherent extra financial and administrative cost. Instead, Juniper suggests using existing core devices since their core routers all use powerful processors and all have lots of memory. In addition, their architecture suffers minimal degradation in performance as services are added.

As you can see, L3VPN can be somewhat complex. Provisioning new VPNs can be complex and so can adding new sites into existing VPNs. However, the complexity of provisioning is overshadowed by the complexity of troubleshooting these networks. Label stacking means that the PEs must push multiple labels (one for the VPN and one for the path across the network). If, in addition, you are also tunnelling LDP through RSVP-TE LSPs in your core, then you could end up with three levels of label stacking. When there is a failure, it can be immensely difficult to identify which LSR should be advertising labels to which other LSRs using which label distribution protocol. Scaling networks running L3VPN is indeed a major challenge.

8.1.2GENERIC ROUTER ENCAPSULATION (GRE)

GRE is a mechanism for the encapsulation of arbitrary packets over an existing IP network. GRE does not require any MPLS functionality so it can be used to build tunnels through networks without MPLS functionality. This removes the requirement for the P routers in a carrier’s network to have any MPLS functionality at all since all MPLS frames are encapsulated inside the GRE tunnel right across the core. Therefore, it has been proposed that the outer MPLS label of a L3VPN could be replaced by a GRE tunnel.

The use of GRE (actually IP+GRE) encapsulated MPLS frames means that the VPN might be more vulnerable to the spoofing of packets into the VPN than if the outer tunnel were MPLS-based. In order to protect against the spoofing of the outer tunnel, it would