RFC 2547 VPNs over L2TPv3 Tunnels
L2TPv3 tunnels provide a transport alternative to GRE. You can use them to create a Layer 3 tunnel overlay similar to that created with GRE tunnels in the previous section. An L2TPv3 mesh supports 2547 over L2TPv3; however, MPLS over L2TPv3 is not an option to date because, as discussed in the previous section, 2547 over L2TPv3 and MPLS over L2TPv3 offer two different types of functionality.
To aggregate segmented branches, L2TPv3 must be implemented on the hub router and every branch router having segmentation requirements. The extension of the segmentation into the campus network at the headend can be achieved by h2h VRFs or even by pushing the PE and L2TPv3 tunnel termination functionality all the way into the distribution layer of the campus.
In this case, the solution is simple: It is basically a tunnel overlay using VPN labels to mux/demux traffic in and out of the tunnels for the different VPNs, which is similar to the 2547 over GRE solution described in the previous section. Figure 7-15 illustrates the forwarding of packets in an L2TPv3-based 2547 VPN deployment.
Figure 7-15. RFC 2547 VPNs over L2TPv3 Packet Flow
The packet flow is similar to that discussed for 2547 over GRE. There are, however, two differences in the solution:
The use of dynamic multipoint tunnels requires some configuration subtleties. However, these details are the same whether we use mGRE tunnels or L2TPv3 tunnels. The following discussion focuses on L2TPv3 tunnels, but keep in mind that the exact same considerations, and even the same configuration, apply to an mGRE-based approach.
The main consideration when configuring dynamic multipoint tunnels is that they need to reside in their own address space. To this effect, you must configure a dedicated VRF for the resolution of
ip vrf my_riv rd 1:1
The multipoint tunnel interfaces must be included in the RiV VRF. The following table details the commands to create the tunnel for both the mGRE and the L2TPv3 configurations. As you can see, there is only one configuration difference between the two types of encapsulation.
You must configure a route map to ensure that the next hop is resolved within the RiV VRF:
route-map SELECT_UPDATES_FOR_L3VPN_OVER_TUNNEL permit 10 set ip next-hop in-vrf my_riv
A static route within the VRF ensures that all traffic is sent over the tunnel interface:
ip route vrf my_riv 0.0.0.0 0.0.0.0 Tunnel1
You must configure MP-iBGP to peer between the PE and the RRs. To ensure that the next hop for these updates is resolved in the RiV VRF, you now apply the previously created route map to incoming updates:
router bgp 100 network 22.214.171.124 neighbor 126.96.36.199 remote-as 100 neighbor 188.8.131.52 update-source Loopback0 ! address-family vpnv4 neighbor 184.108.40.206 activate neighbor 220.127.116.11 route-map SELECT_UPDATES_FOR_L3VPN_OVER_TUNNEL in !
One significant benefit of using a tunnel overlay and extending it end to end (pushing the PE routers all the way to the edges of the IP cloud) is that the entire IP network (including campuses, branches, MANs, and the WAN) can
Figure 7-16. RFC 2547 VPNs over L2TPv3 Across Autonomous System Boundaries
In the figure, the enterprise provides IP connectivity through many autonomous systems. L2TPv3
This is true for 2547 over L2TPv3 and 2547 over mGRE deployments. Because no LDP or LSP formation occurs between the PEs, you can actually distribute them across different autonomous systems without breaking the RFC 2547 VPN. However, the same is not true for a service such as MPLS over GRE. In this case, it is not possible to circumvent the inter-autonomous system communication requirements posed by the LDP-based LSP establishment required in an MPLS over X solution.
On the other hand, if the campus network or MAN is already segmented with MPLS VPNs and this MPLS deployment is to be preserved, the enterprise is faced with managing an inter-autonomous system exchange point to integrate the MPLS campus/MAN networks with the non-MPLS L2TPv3 WAN network.
The most straightforward solution to this problem is to provide CsC services over the L2TPv3-based VPN cloud. The L2TPv3 portion of the network will be the backbone carrier, whereas the MPLS portion of the network will be the customer carrier. Figure 7-17 shows the packet flow for this CsC scenario.
Figure 7-17. RFC 2547 VPNs over L2TPv3 as CsC Backbone Carrier
This CsC solution has the same
In this case, the enterprise owns and controls both the backbone carrier and the customer carrier portions of the network. Therefore, the limitation on service offerings is no longer present.
To configure this CsC solution, you configure the "backbone carrier" portion of the network for 2547 over L2TPv3 as described previously and enable MPLS on the "customer"-
Inter-autonomous system communication models provide alternative approaches to solving this problem. We introduced the different inter-autonomous system models in the section "MPLS over Layer 2 Circuits." These are
Benefits and Drawbacks
Deploying RFC 2547 VPNs over IP tunnels does eliminate the need for label switching in the
The benefits of this solution include the following:
The drawbacks include the following: