CloudEngine S3700, S5700, and S6700 V600R023C00 Configuration Guide - VPN
Understanding IPv4 L3VPN over MPLS
Definition
IPv4 L3VPN over MPLS uses BGP to advertise VPN routes and uses MPLS to forward VPN packets on the SP backbone network.
Figure 3-9 shows the basic IPv4 L3VPN model.
The basic IPv4 L3VPN model consists of three parts:
Customer edge (CE): edge device on the customer network. A CE provides interfaces to directly connect to the SP network. A CE can be a device, switch, or host. Generally, a CE is unaware of VPNs and does not need to support MPLS.
Provider edge (PE): edge device on the SP network. A PE directly connects to CEs. On an MPLS network, PEs process all VPN services and must have high performance.
Provider device (P): backbone device on the SP network. A P does not directly connect to CEs. Ps only need to possess basic MPLS forwarding capabilities and do not maintain VPN information.
Generally, PEs and Ps are managed by SPs, and CEs are managed by users. Users can also delegate CE management to SPs.
A PE can connect to multiple CEs. A CE can connect to multiple PEs of the same SP or of different SPs.
IPv4 L3VPN Route Advertisement
Route advertisement from the local CE to the ingress PE
After a peer relationship is established between a CE and the directly connected PE, the CE advertises the local IPv4 routes to the PE. Static routes or a routing protocol (RIP, OSPF, IS-IS, or BGP) can be used between the CE and PE. Routes advertised by the CE to the PE are standard IPv4 routes, regardless of which routing protocol is used.
VPN instances on a PE are isolated from each other and independent of the public routing and forwarding table, to prevent problems caused by VPN address space overlapping. After learning routes from a CE, a PE needs to determine to which routing and forwarding table the routes should be installed. Common routing protocols, however, do not have this capability, and manual configuration is required.
Route advertisement from the ingress PE to the egress PE
Route advertisement from the ingress PE to the egress PE further consists of the following phases:
After learning VPN routes from a CE, a PE stores these routes in the corresponding VPN instances and adds RDs to these standard IPv4 routes. VPN-IPv4 routes are then generated.
The ingress PE advertises VPN-IPv4 routes to the egress PE by sending MP-BGP Update messages. The Update messages also contain VPN targets and MPLS labels.
Before the next-hop PE receives the VPN-IPv4 routes, the routes are first filtered by BGP route-policies, including the VRF export policy and peer export policy.
After these routes arrive at the egress PE, if they match the BGP peer import policy and their next hops are reachable or they can perform recursion, the egress PE performs local route leaking and filters these routes based on a VRF import policy. The egress PE then decides which routes are to be added to its VPN routing tables. Routes received from other PEs are added to a VPN routing table based on VPN targets. The egress PE stores the following information for subsequent packet forwarding:
Values of MPLS labels contained in MP-BGP Update messages
Tunnel IDs generated after recursion to tunnels is successful
Route advertisement from the egress PE to the remote CE
A remote CE can learn VPN routes from an egress PE over static routes or routes established using RIP, OSPF, IS-IS, or BGP. Route advertisement from the egress PE to a remote CE is similar to that from a local CE to the ingress PE. The details are not described here. Note that the routes advertised by the egress PE to the remote CE are standard IPv4 routes.
After a PE receives routes of different VPNs from a local CE, if the next hops of these routes are reachable or these routes are recursive, the PE matches the export VPN targets of these routes against the import VPN targets of its local VPN instances. This process is called local route leaking. During local route leaking, the PE filters these routes based on a VRF import policy and modifies the attributes of eligible routes.
IPv4 L3VPN Packet Forwarding
On an IPv4 L3VPN backbone network, Ps are unaware of VPN routing information. VPN packets are forwarded between PEs over tunnels. Figure 3-10 shows an example of packet forwarding on an IPv4 L3VPN. Figure 3-10 shows packet transmission from CE1 to CE2. I-L indicates an inner label, and O-L indicates an outer label. The outer label directs the packet to the BGP next hop, and the inner label identifies the outbound interface for the packet or the VPN to which the packet belongs.
- CE1 sends an IP packet to the ingress PE.
- After receiving the packet from an interface bound to a VPN instance, the ingress PE performs the following steps:
- Searches the corresponding VPN forwarding table based on the RD of the bound VPN instance.
- Matches the destination IPv4 prefix against forwarding entries to search for the corresponding tunnel ID.
- Adds an I-L to the packet and finds the tunnel to be used based on the tunnel ID.
- Adds an outer label to the packet and sends the packet over the corresponding tunnel. In this example, the tunnel is an LSP, and the outer label is an MPLS label (O-L1).
- Transmits the double-tagged packet over the backbone network. Each P on the forwarding path swaps the outer label of the packet.
- After receiving the packet with double labels, the egress PE sends the packet to MPLS for processing. MPLS removes the outer label.
![]()
In this example, the final outer label of the packet is O-L2. If PHP is configured, O-L2 is removed on the penultimate hop, and the egress PE receives a packet with the inner label only.
- The egress PE determines which VPN forwarding table to use based on the inner label, searches this table for the outbound interface based on the IPv4 prefix, and then removes the inner label.
- The egress PE sends the packet through the corresponding outbound interface to CE2. At this time, the packet is a native IP packet.
In this manner, the packet is sent from CE1 to CE2. CE2 forwards the packet to the destination in the way it sends other IP packets.