Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

IPv4 Traffic Over Layer 3 VPNs

Understanding IPv4 Route Distribution in a Layer 3 VPN

Within a VPN, the distribution of VPN-IPv4 routes occurs between the PE and CE routers and between the PE routers (see Figure 1).

Figure 1: Route Distribution Within a VPNRoute Distribution Within a VPN

This section discusses the following topics:

Distribution of Routes from CE to PE Routers

A CE router announces its routes to the directly connected PE router. The announced routes are in IPv4 format. The PE router places the routes into the VRF table for the VPN. In the Junos OS, this is the routing-instance-name.inet.0 routing table, where routing-instance-name is the configured name of the VPN.

The connection between the CE and PE routers can be a remote connection (a WAN connection) or a direct connection (such as a Frame Relay or Ethernet connection).

CE routers can communicate with PE routers using one of the following:

  • OSPF

  • RIP

  • BGP

  • Static route

Figure 2 illustrates how routes are distributed from CE routers to PE routers. Router PE1 is connected to two CE routers that are in different VPNs. Therefore, it creates two VRF tables, one for each VPN. The CE routers announce IPv4 routes. The PE router installs these routes into two different VRF tables, one for each VPN. Similarly, Router PE2 creates two VRF tables into which routes are installed from the two directly connected CE routers. Router PE3 creates one VRF table because it is directly connected to only one VPN.

Figure 2: Distribution of Routes from CE Routers to PE RoutersDistribution of Routes from CE Routers to PE Routers

Distribution of Routes Between PE Routers

When one PE router receives routes advertised from a directly connected CE router, it checks the received route against the VRF export policy for that VPN. If it matches, the route is converted to VPN-IPv4 format—that is, the 8-byte route distinguisher is prepended to the 4-byte VPN prefix to form a 12-byte VPN-IPv4 address. The route is then tagged with a route target community. The PE router announces the route in VPN-IPv4 format to the remote PE routers for use by VRF import policies. The routes are distributed using IBGP sessions, which are configured in the provider’s core network. If the route does not match, it is not exported to other PE routers, but can still be used locally for routing, for example, if two CE routers in the same VPN are directly connected to the same PE router.

The remote PE router places the route into its bgp.l3vpn.0 table if the route passes the import policy on the IBGP session between the PE routers. At the same time, it checks the route against the VRF import policy for the VPN. If it matches, the route distinguisher is removed from the route, and it is placed into the VRF table (the routing-instance-name.inet.0 table) in IPv4 format.

Figure 3 illustrates how Router PE1 distributes routes to the other PE routers in the provider’s core network. Router PE2 and Router PE3 each have VRF import policies that they use to determine whether to accept routes received over the IBGP sessions and install them in their VRF tables.

Figure 3: Distribution of Routes Between PE RoutersDistribution of Routes Between PE Routers

When a PE router receives routes advertised from a directly connected CE router (Router PE1 in Figure 3), it uses the following procedure to examine the route, convert it to a VPN route, and distribute it to the remote PE routers:

  1. The PE router checks the received route using the VRF export policy for that VPN.

  2. If the received route matches the export policy, the route is processed as follows:

    1. The route is converted to VPN-IPv4 format—that is, the 8-byte route distinguisher is prepended to the 4-byte VPN prefix to form the 12-byte VPN-IPv4 address.

    2. A route target community is added to the route.

    3. The PE router advertises the route in VPN-IPv4 format to the remote PE routers. The routes are distributed using IBGP sessions, which are configured in the provider’s core network.

  3. If the route does not match the export policy, it is not exported to the remote PE routers, but can still be used locally for routing—for example,if two CE routers in the same VPN are directly connected to the same PE router.

When the remote PE router receives routes advertised from another PE router (Routers PE2 and PE3 in Figure 3), it uses the following procedure to process the route:

  1. If the route is accepted by the import policy on the IBGP session between the PE routers, the remote PE router places the route into its bgp.l3vpn.0 table.

  2. The remote PE router checks the route’s route target community against the VRF import policy for the VPN.

  3. If it matches, the route distinguisher is removed from the route, and it is placed into the VRF table (the routing-instance-name.inet.0 table) in IPv4 format.

Distribution of Routes from PE to CE Routers

The remote PE router announces the routes in its VRF tables, which are in IPv4 format, to its directly connected CE routers.

PE routers can communicate with CE routers using one of the following routing protocols:

  • OSPF

  • RIP

  • BGP

  • Static route

Figure 4 illustrates how the three PE routers announce their routes to their connected CE routers.

Figure 4: Distribution of Routes from PE Routers to CE RoutersDistribution of Routes from PE Routers to CE Routers

Understanding VPN-IPv4 Addresses and Route Distinguishers

Because Layer 3 VPNs connect private networks—which can use either public addresses or private addresses, as defined in RFC 1918 (Address Allocation for Private Internets)—over the public Internet infrastructure, when the private networks use private addresses, the addresses might overlap with the addresses of another private network.

Figure 5 illustrates how private addresses of different private networks can overlap. Here, sites within VPN A and VPN B use the address spaces 10.1.0.0/16, 10.2.0.0/16, and 10.3.0.0/16 for their private networks.

Figure 5: Overlapping Addresses Among Different VPNsOverlapping Addresses Among Different VPNs

To avoid overlapping private addresses, you can configure the network devices to use public addresses instead of private addresses. However, this is a large and complex undertaking. The solution provided in RFC 4364 uses the existing private network numbers to create a new address that is unambiguous. The new address is part of the VPN-IPv4 address family, which is a BGP address family added as an extension to the BGP protocol. In VPN-IPv4 addresses, a value that identifies the VPN, called a route distinguisher, is prefixed to the private IPv4 address, providing an address that uniquely identifies a private IPv4 address.

Only the PE routers need to support the VPN-IPv4 address extension to BGP. When an ingress PE router receives an IPv4 route from a device within a VPN, it converts it into a VPN-IPv4 route by adding the route distinguisher prefix to the route. The VPN-IPv4 addresses are used only for routes exchanged between PE routers. When an egress PE router receives a VPN-IPv4 route, it converts the VPN-IPv4 route back to an IPv4 route by removing the route distinguisher before announcing the route to its connected CE routers.

VPN-IPv4 addresses have the following format:

  • Route distinguisher is a 6-byte value that you can specify in one of the following formats:

    • as-number:number, where as-number is an AS number (a 2-byte value) and number is any 4-byte value. The AS number can be in the range 1 through 65,535. We recommend that you use an Internet Assigned Numbers Authority (IANA)-assigned, nonprivate AS number, preferably the Internet service provider’s (ISP’s) own or the customer’s own AS number.

    • ip-address:number, where ip-address is an IP address (a 4-byte value) and number is any 2-byte value. The IP address can be any globally unique unicast address. We recommend that you use the address that you configure in the router-id statement, which is a nonprivate address in your assigned prefix range.

  • IPv4 address—4-byte address of a device within the VPN.

Figure 5 illustrates how the AS number can be used in the route distinguisher. Suppose that VPN A is in AS 65535 and that VPN B is in AS 666 (both these AS numbers belong to the ISP), and suppose that the route distinguisher for Site 2 in VPN A is 65535:02 and that the route distinguisher for Site 2 in VPN B is 666:02. When Router PE2 receives a route from the CE router in VPN A, it converts it from its IP address of 10.2.0.0 to a VPN-IPv4 address of 65535:02:10.2.0.0. When the PE router receives a route from VPN B, which uses the same address space as VPN A, it converts it to a VPN-IPv4 address of 666:02:10.2.0.0.

If the IP address is used in the route distinguisher, suppose Router PE2’s IP address is 172.168.0.1. When the PE router receives a route from VPN A, it converts it to a VPN-IPv4 address of 172.168.0.1:0:10.2.0.0/16, and it converts a route from VPN B to 172.168.0.0:1:10.2.0.0/16.

Route distinguishers are used only among PE routers to IPv4 addresses from different VPNs. The ingress PE router creates a route distinguisher and converts IPv4 routes received from CE routers into VPN-IPv4 addresses. The egress PE routers convert VPN-IPv4 routes into IPv4 routes before announcing them to the CE router.

Because VPN-IPv4 addresses are a type of BGP address, you must configure IBGP sessions between pairs of PE routers so that the PE routers can distribute VPN-IPv4 routes within the provider’s core network. (All PE routers are assumed to be within the same AS.)

You define BGP communities to constrain the distribution of routes among the PE routers. Defining BGP communities does not, by itself, distinguish IPv4 addresses.

Figure 6 illustrates how Router PE1 adds the route distinguisher 10458:22:10.1/16 to routes received from the CE router at Site 1 in VPN A and forwards these routes to the other two PE routers. Similarly, Router PE1 adds the route distinguisher 10458:23:10.2/16 to routes received by the CE router at Site 1 in VPN B and forwards these routes to the other PE routers.

Figure 6: Route DistinguishersRoute Distinguishers

Configuring IPv4 Packet Forwarding for Layer 3 VPNs

You can configure the router to support packet forwarding for IPv4 traffic in Layer 2 and Layer 3 VPNs. Packet forwarding is handled in one of the following ways, depending on the type of helper service configured:

  • BOOTP service—Clients send Bootstrap Protocol (BOOTP) requests through the router configured with BOOTP service to a server in the specified routing instance. The server recognizes the client address and sends a response back to the router configured with BOOTP service. This router forwards the reply to the correct client address in the specified routing instance.

  • Other services—Clients send requests through the router configured with the service to a server in the specified routing instance. The server recognizes the client address and sends a response to the correct client address in the specified routing instance.

To enable packet forwarding for VPNs, include the helpers statement:

You can include this statement at the following hierarchy levels:

  • [edit forwarding-options]

  • [edit logical-systems logical-system-name forwarding-options]

  • [edit routing-instances routing-instance-name forwarding-options]

    Note:

    You can enable packet forwarding for multiple VPNs. However, the client and server must be within the same VPN. Any Juniper Networks routing platforms with packet forwarding enabled along the path between the client and server must also reside within the same VPN.

The address and routing instance together constitute a unique server. This has implications for routers configured with BOOTP service, which can accept multiple servers.

For example, a BOOTP service can be configured as follows:

Even though the addresses are identical, the routing instances are different. A packet coming in for BOOTP service on instance-A is forwarded to 10.2.3.4 in the instance-A routing instance, while a packet coming in on instance-B is forwarded in the instance-B routing instance. Other services can only accept a single server, so this configuration does not apply in those cases.

Example: Configure a Basic MPLS-Based Layer 3 VPN

This example shows how to configure and validate a basic MPLS-based Layer 3 VPN on routers or switches running Junos OS. The IPv4 based example uses EBGP as the routing protocol between the provider and customer edge devices.

Note:

Our content testing team has validated and updated this example.

You can deploy an MPLS-based Layer 3 virtual private network (VPN) using routers and switches running Junos OS to interconnect customer sites with Layer 3 connectivity. While static routing is supported, Layer 3 VPNs typically have the customer devices exchange routing information with the provider network and require support for IP protocols, i.e., IPv4 and/or IPv6.

This is in contrast with a Layer 2 VPN, where the customer devices may not be based on IP protocols, and where routing, if any, occurs between the customer edge (CE) devices. Unlike a Layer 3 VPN where the CE device interacts (peers) with the provider edge device, in a Layer 2 VPN the customer traffic passes transparently through the provider core with any routing protocols running end-to-end between the CE devices.

MPLS-based VPNs require baseline MPLS functionality in the provider network. Once basic MPLS is operational, you are able to configure VPNs that use label-switched paths (LSPs) for transport over the provider core.

The addition of VPN services does not affect the basic MPLS switching operations in the provider network. In fact, the provider (P) devices require only a baseline MPLS configuration because they are not VPN aware. VPN state is maintained only on the provider edge (PE) devices. This is a key reason why MPLS-based VPNs scale so well.

Requirements

This example uses the following software and hardware components:

  • Junos OS Release 12.3 or later for routing and switching devices

    • Revalidated on Junos OS release 20.3R1

  • Two Provider edge (PE) devices

  • One provider (P) device

  • Two customer edge (CE) devices

The example focuses on how to add a Layer 3 VPN to a pre-existing MPLS baseline. A basic MPLS configuration is provided in case your network does not already have MPLS deployed.

To support MPLS-based VPNs the underlying MPLS baseline must provide the following functionality:

  • Core-facing and loopback interfaces operational with MPLS family support

  • An interior gateway protocol such as OSPF or IS-IS to provide reachability between the loopback addresses of the provider (P and PE) devices

  • An MPLS signalling protocol such as LDP or RSVP to signal LSPs

  • LSPs established between PE device loopback addresses

LSPs are needed between each pair of PE devices that participate in a given VPN. Its a good idea to build LSPs between all PE devices to accommodate future VPN growth. You configure LSPs at the [edit protocols mpls] hierarchy level. Unlike an MPLS configuration for a circuit cross-connect (CCC) connection, you do not need to manually associate the LSP with the PE device’s customer-facing (edge) interface. Instead, Layer 3 VPNs use BGP signalling to advertise site reachability. This BGP signaling automates the mapping of remote VPN sites to LSP forwarding next hops. This means that with a Layer 3 VPN explicit mapping of an LSP to a PE device’s edge-facing interface is not required.

Overview and Topology

Layer 3 VPNs allow customers to leverage the service provider’s technical expertise to ensure efficient site-to-site routing. The customer edge (CE) device typically uses a routing protocol, such as BGP or OSPF, to exchange routes with the service provider edge (PE) device. Static routing is supported for Layer 3 VPNs, but a dynamic routing protocol is generally preferred.

Definition of a VPN involves changes to the local and remote PE devices only. No additional configuration is needed on the provider devices (assuming they already have a working MPLS baseline), because these devices only provide basic MPLS switching functions. The CE devices do not use MPLS and require only a basic interface and routing protocol configuration so they can interact with the PE devices.

In a Layer 3 VPN you configure the CE devices to peer with the local PE device. This is in contrast to a Layer 2 VPN, where the CE devices peer to each other as if they were on a shared link, despite their being connected through an MPLS-based provider core.

Once an MPLS baseline is in place, you must configure the following functionality on the PE devices to establish your MPLS-based Layer 3 VPN:

  • A BGP group with family inet-vpn unicast support

  • A routing instance with instance type vrf and a routing protocol definition that is compatible with the attached CE device

  • The customer-facing interfaces on the PE devices configured with family inet along with an IPv4 address that places the interface on the same subnet as the attached CE device. If desired VLAN encapsulation and a corresponding VLAN ID can also be configured.

For proper end-to-end connectivity the CE device needs to be configured with a compatible IP subnet and routing protocol parameters to support peering with the PE device.

Figure 7 shows the topology used in this example. The figure details the interface names, IP addressing, and routing protocols used in the provider and customer networks. It also highlights the peering relationship between the CE and PE devices. In this example you expect each CE device to form an EBGP peering session to the local PE device. Note that the provider network and both customer sites have an assigned autonomous system number to support BGP operation. In this example routing policy is applied at the CE devices to have them advertise the direct routes for their provider facing and loopback interfaces.

Figure 7: An MPLS-Based Layer 3 VPN with EBGP as the PE-CE Routing ProtocolAn MPLS-Based Layer 3 VPN with EBGP as the PE-CE Routing Protocol

Quick Configurations

Use the configurations in this section to quickly get your MPLS-based Layer 3 VPN up and running. The configurations include a functional MPLS baseline to support your Layer 3 VPN. This example focuses on the VPN aspects of the configuration. Refer to the following links for additional information on the baseline MPLS functionality used in this example:

CLI Quick Configuration

Note:

The device configurations omit the management interface, static routes, system logging, system services, and user login information. These parts of the configuration vary by location and are not directly related to MPLS or VPN functionality.

Edit the following commands as needed for the specifics of your environment and paste them into the local CE (CE1) device terminal window when in configuration mode at the [edit] hierarchy:

The complete configuration for the CE1 device.

The complete configuration for PE1 device.

The complete configuration for the P device.

The complete configuration for the PE2 device.

The complete configuration for the CE2 device.

Be sure to commit the configuration changes on all devices when satisfied with your work. Congratulations on your new MPLS-based Layer 3 VPN! Refer to the Verification section for the steps needed to confirm your Layer 3 VPN is working as expected.

Configure the Local PE (PE1) Device for a MPLS-Based Layer 3 VPN

This section covers the steps needed to configure the PE1 device for this example. The focus in on the PE devices because that is where the VPN configuration is housed. Refer to the Quick Configurations section for the CE device and P device configurations used in this example.

Configure the MPLS Baseline (if needed)

Before you configure a Layer 3 VPN make sure the PE device has a working MPLS baseline. If you already having an MPLS baseline you can skip to the step-by-step procedure to add the Layer 3 VPN to the PE devices.

  • Configure the hostname.

  • Configure the core and loopback interfaces:

    Best Practice:

    While a Layer 3 VPN can perform fragmentation at the ingress PE, its best practice to design the network so the CE can send a maximum sized frame without needing fragmentation. To ensure fragmentation does not occur the provider network should support the largest frame that the CE devices can generate after the MPLS and virtual routing and forwarding (VRF) labels are added by the PE device. This example leaves the CE devices at the default 1500-byte maximum transmission unit (MTU) while configuring the provider core to support a 4000 byte MTU. This ensures the CE devices cannot exceed the MTU in the provider's network even with the MPLS and VRF encapsulation overhead.

  • Configure the protocols:

    Note:

    Traffic engineering is supported for RSVP-signaled LSPs but is not required for basic MPLS switching or VPN deployment. The provided MPLS baseline uses RSVP to signal LSPs, and enables traffic engineering for OSPF. However, no path constraints are configured so you expect the LSPs to be routed over the interior gateway protocol's shortest path.

  • Define the LSP to the remote PE device's loopback address:

The MPLS baseline is now configured on the PE1 device. Keep going to configure the Layer 3 VPN.

Procedure

Step-by-Step Procedure

Follow these steps to configure the PE1 device for a Layer 3 VPN.

  1. Configure the customer-facing interface:

    Tip:

    You can configure both an MPLS-based Layer 2 VPN and an MPLS-based Layer 3 VPN on the same PE device. However, you cannot configure the same customer edge-facing interface to support both a Layer 2 VPN and a Layer 3 VPN.

  2. Configure a BGP group for the peering between the local and remote PE devices. Use the PE device’s loopback address as the local address, and enable the inet-vpn unicast address family to support Layer 3 VPN route exchange. A routing policy for BGP is not needed on the PE devices in this example. By default the PE devices readvertise into IBGP the routes they learn over their EBGP peering to the CE device.

    Tip:

    You can specify other address families if the PE to PE IBGP session needs to support non-VPN route exchange, such as regular IPv4 or IPv6 routes using the inet or inet6 families, respectively.

  3. Configure the BGP group type as internal.

  4. Configure the remote PE device’s loopback address as a BGP neighbor.

  5. Configure the router ID to match its loopback address, and define the BGP autonomous system number needed for BGP peering.

  6. Configure the routing instance. Specify an instance name of CE1_L3vpn, and configure an instance-type of vrf.

  7. Configure the PE device’s customer-facing interface to belong to the routing instance.

  8. Configure the routing instance’s route distinguisher. This setting is used to distinguish the routes sent from a particular VRF on a particular PE device. It should be unique for each routing instance on each PE device.

  9. Configure the instance’s virtual routing and forwarding (VRF) table route target. The vrf-target statement adds the specified community tag to all advertised routes while automatically matching the same value for route import. Configuring matching route targets on the PE devices that share a given VPN is required for proper route exchange.

    Note:

    You can create more complex policies by explicitly configuring VRF import and export policies using the import and export options. See vrf-import and vrf-export for details.

  10. Configure the routing instance to support EBGP peering to the CE1 device. Direct interface peering to the CE1 end of the VRF link is used, and CE1’s autonomous system number is correctly specified with the peer-as parameter.

  11. Commit your changes at the PE1 device and return to CLI operational mode.

Results

Display the results of the configuration on the PE1 device. The output reflects only the functional configuration added in this example.

Configure the Remote PE (PE2) Device for a MPLS-Based Layer 3 VPN

This section covers the steps needed to configure the PE1 device for this example. The focus in on the PE devices because that is where the VPN configuration is housed. Refer to the Quick Configurations section for the CE device and P device configurations used in this example.

Configure the MPLS Baseline (if needed)

Before you configure a Layer 3 VPN make sure the PE device has a working MPLS baseline. If you already having an MPLS baseline you can skip to the step-by-step procedure to add the Layer 3 VPN to the PE devices.

  • Configure the hostname.

  • Configure the core and loopback interfaces:

    Best Practice:

    While a Layer 3 VPN can perform fragmentation at the ingress PE, its best practice to design the network so the CE can send a maximum sized frame without needing fragmentation. To ensure fragmentation does not occur the provider network should support the largest frame that the CE devices can generate after the MPLS and virtual routing and forwarding (VRF) labels are added by the PE device. This example leaves the CE devices at the default 1500-byte maximum transmission unit (MTU) while configuring the provider core to support a 4000 byte MTU. This ensures the CE devices cannot exceed the MTU in the provider's network even with the MPLS and VRF encapsulation overhead.

  • Configure the protocols:

    Note:

    Traffic engineering is supported for RSVP-signaled LSPs but is not required for basic MPLS switching or VPN deployment. The provided MPLS baseline uses RSVP to signal LSPs, and enables traffic engineering for OSPF. However, no path constraints are configured so you expect the LSPs to be routed over the interior gateway protocol's shortest path.

  • Define the LSP to the remote PE device's loopback address:

The MPLS baseline is now configured on the PE1 device. Keep going to configure the Layer 3 VPN.

Procedure

Step-by-Step Procedure

Follow these steps to configure the PE2 device for a Layer 3 VPN.

  1. Configure the customer-facing interface:

    Tip:

    You can configure both an MPLS-based Layer 2 VPN and an MPLS-based Layer 3 VPN on the same PE device. However, you cannot configure the same customer edge-facing interface to support both a Layer 2 VPN and a Layer 3 VPN.

  2. Configure a BGP group for the peering between the local and remote PE devices. Use the PE device’s loopback address as the local address, and enable the inet-vpn unicast address family to support Layer 3 VPN route exchange.

    Tip:

    You can specify other address families if the PE to PE IBGP session needs to support non-VPN route exchange, such as regular IPv4 or IPv6 routes using the inet or inet6 families, respectively.

  3. Configure the BGP group type as internal.

  4. Configure the PE1 device’s loopback address as a BGP neighbor.

  5. Configure the router ID to match its loopback address, and define the BGP autonomous system number.

  6. Configure the routing instance. Specify an instance name of CE2_L3vpn, with an instance-type of vrf.

  7. Configure the PE device’s customer-facing interface to belong to the routing instance.

  8. Configure the routing instance’s route distinguisher. This setting is used to distinguish the routes sent from a particular VRF on a particular PE device. It should be unique for each routing instance on each PE device.

  9. Configure the instance’s virtual routing and forwarding (VRF) table route target. The vrf-target statement adds the specified community tag to all advertised routes while automatically matching the same value for route import. Configuring matching route targets on the PE devices that share a given VPN is required for proper route exchange.

    Note:

    You can create more complex policies by explicitly configuring VRF import and export policies using the import and export options. See vrf-import and vrf-export for details.

  10. Configure the routing instance to support EBGP peering to the CE2 device. Direct interface peering to the CE2 end of the VRF link is used, and CE2’s autonomous system number is correctly specified with the peer-as parameter.

  11. Commit your changes at the PE2 device and return to CLI operational mode.

Results

Display the results of the configuration on the PE2 device. The output reflects only the functional configuration added in this example.

Verification

Perform these tasks to verify that the MPLS-based Layer 3 VPN works properly:

Verify Provider OSPF Adjacencies and Route Exchange

Purpose

Confirm the OSPF protocol is working properly in the provider network by verifying adjacency status and OSPF learned routes to the loopback addresses of the remote provider devices. Proper IGP operation is critical for the successful establishment of MPLS LSPs.

Action
Meaning

The output shows that the PE1 device has established an OSPF adjacency to the P device (192.168.0.2). It also shows that the P and remote PE device loopback addresses (192.168.0.2) and (192.168.0.3) are correctly learned via OSPF at the local PE device.

Verify MPLS and RSVP Interface Settings

Purpose

Verify that the RSVP and MPLS protocols are configured to operate on the PE device’s core-facing interface. This step also verifies that family mpls is correctly configured at the unit level of the PE device’s core-facing interface.

Action
Meaning

The output shows that MPLS and RSVP are correctly configured on the local PE device’s core and loopback interfaces.

Verify RSVP Signaled LSPs

Purpose

Verify that RSVP signaled ingress and egress LSPs are correctly established between the PE device’s loopback addresses.

Action
Meaning

The output shows that both the ingress and egress RSVP sessions are correctly established between the PE devices. Successful LSP establishment indicates the MPLS baseline is operational.

Verify BGP Session Status

Purpose

Verify that the IBGP session between the PE devices is correctly established with support for Layer 3 VPN network layer reachability information (NLRI). In this step you also confirm the local PE to CE EBGP session is established and correctly configured to exchange IPv4 routes.

Action
Meaning

The output shows the IBGP session to the remote PE device (192.168.0.3) has been correctly established (Establ), and through the Up/Dwn field, how long the session has been in the current state (6:18). The flaps field confirms that no state transitions have occurred (0), indicating the session is stable. Also note that Layer 3 VPN routes (NLRI) have been learned from the remote PE as shown by the presence of a bgp.l3vpn.0 table.

The display also confirms the EBGP session to the local CE1 device (172.16.1.1) is established and that IPv4 routes have been received from the CE1 device and installed in the CE1 device routing instance (CE1_L3vpn.inet.0)

This output confirms that the BGP peering between the PE devices, and to the CE device, is working properly to support your Layer 3 VPN.

Verify Layer 3 VPN Routes in the Routing Table

Purpose

Confirm that the routing table on the PE1 device is populated with Layer 3 VPN routes advertised by the remote PE. These routes are used to forward traffic to the remote CE device.

Action
Meaning

The show route table bgp.l3vpn.0 command displays the Layer 3 VPN routes that have been received from the remote PE device. The show route table CE1_L3vpn.inet.0 command lists the all routes that have been imported into the CE1_L3vpn routing instance. These entries represent the routes learned from the local EBGP peering to the CE1 device, in addition to those routes received from the remote PE2 device with a matching route target.

Both tables show the remote Layer 3 VPN routes are correctly associated with the lsp_to_pe2 LSP as a forwarding next hop. The outputs confirm the local PE device has learned the routes associated with the remote CE2 location from the PE2 device. It also shows that the local PE will forward Layer 3 VPN traffic to the remote PE2 device using MPLS transport over the provider network.

Ping the Remote PE Device Using the Layer 3 VPN Connection

Purpose

Verify Layer 3 VPN connectivity between the local and remote PE devices using ping. This command verifies the Layer 3 VPN routing and MPLS forwarding operation between the PE devices.

Action
Meaning

The output confirms that the Layer 3 VPN control and forwarding planes are operating correctly between the PE devices.

Verify End-to-End Operation of the CE Devices Over the Layer 3 VPN

Purpose

Verify Layer 3 VPN connectivity between the CE devices. This step confirms the CE devices have operational interfaces and are properly configured for EBGP based Layer 3 connectivity. This is done by verifying the local CE1 device has learned the remote CE device’s routes, and by confirming the CE devices are able to pass traffic end-to-end between their loopback addresses.

Action
Meaning

The output shows that Layer 3 VPN based connectivity is working correctly between the CE devices. The local CE device has learned the remote CE device’s VRF interface and loopback routes through BGP. The ping is generated to the loopback address of the remote CE device, and is sourced from the local CE device’s loopback address using the source 172.16.255.1 argument. Adding the do-not-fragment and size 1472 switches confirms that the CE devices are able to pass 1500-byte IP packets without evoking fragmentation in the local PE device.

Note:

The size 1472 argument added to the ping command generates 1472 bytes of echo data. An additional 8 bytes of Internet Control Message Protocol (ICMP) and 20 bytes of IP header are added to bring the total payload size to 1500-bytes. Adding the do-not-fragment switch ensures that the local CE and PE devices cannot perform fragmentation. This ping method confirms that fragmentation is not needed when exchanging standard 1500-byte maximum length Ethernet frames between the CE devices.

These results confirm the MPLS-based Layer 3 VPN is working correctly.