Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

IPv6 Traffic over Layer 3 VPNs

Understanding IPv6 Layer 3 VPNs

The interfaces between the PE and CE routers of a Layer 3 VPN can be configured to carry IP version 6 (IPv6) traffic. IP allows numerous nodes on different networks to interoperate seamlessly. IPv4 is currently used in intranets and private networks, as well as the Internet. IPv6 is the successor to IPv4, and is based for the most part on IPv4.

In the Juniper Networks implementation of IPv6, the service provider implements an MPLS-enabled IPv4 backbone to provide VPN service for IPv6 customers. The PE routers have both IPv4 and IPv6 capabilities. They maintain IPv6 VPN routing and forwarding (VRF) tables for their IPv6 sites and encapsulate IPv6 traffic in MPLS frames that are then sent into the MPLS core network.

IPv6 for Layer 3 VPNs is supported for BGP and for static routes.

IPv6 over Layer 3 VPNs is described in RFC 4659, BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN.

Configuring Layer 3 VPNs to Carry IPv6 Traffic

You can configure IP version 6 (IPv6) between the PE and CE routers of a Layer 3 VPN. The PE router must have the PE router to PE router BGP session configured with the family inet6-vpn statement. The CE router must be capable of receiving IPv6 traffic. You can configure BGP or static routes between the PE and CE routers.

The following sections explains how to configure IPv6 VPNs between the PE routers:

Configuring IPv6 on the PE Router

To configure IPv6 between the PE and CE routers, include the family inet6-vpn statement in the configuration on the PE router:

For a list of hierarchy levels at which you can configure this statement, see the statement summary section for this statement.

You also must include the ipv6-tunneling statement:

You can include this statement at the following hierarchy levels:

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

Configuring the Connection Between the PE and CE Routers

To support IPv6 routes, you must configure BGP, OSPF version 3, IS-IS, or static routes for the connection between the PE and CE routers in the Layer 3 VPN. You can configure BGP to handle just IPv6 routes or both IP version 4 (IPv4) and IPv6 routes.

For more information about IS-IS see Example: Configuring IS-IS,

The following sections explain how to configure BGP and static routes:

Configuring BGP on the PE Router to Handle IPv6 Routes

To configure BGP in the Layer 3 VPN routing instance to handle IPv6 routes, include the bgp statement:

You can include this statement at the following hierarchy levels:

  • [edit routing-instances routing-instance-name protocols]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name protocols]

Configuring BGP on the PE Router for IPv4 and IPv6 Routes

To configure BGP in the Layer 3 VPN routing instance to handle both IPv4 and IPv6 routes, include the bgp statement:

You can include this statement at the following hierarchy levels:

  • [edit routing-instances routing-instance-name protocols]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name protocols]

Note:

The [edit logical-systems] hierarchy level is not applicable in ACX Series routers.

Configuring OSPF Version 3 on the PE Router

To configure OSPF version 3 in the Layer 3 VPN routing instance to handle IPv6 routes, include the ospf3 statement:

You can include this statement at the following hierarchy levels:

  • [edit routing-instances routing-instance-name protocols]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name protocols]

Note:

The [edit logical-systems] hierarchy level is not applicable in ACX Series routers.

Configuring Static Routes on the PE Router

To configure a static route to the CE router in the Layer 3 VPN routing instance, include the routing-options statement:

You can include this statement at the following hierarchy levels:

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

  • [edit logical-systems logical-system-name routing-instances routing-instance-name]

Note:

The [edit logical-systems] hierarchy level is not applicable in ACX Series routers.

Configuring IPv6 on the Interfaces

You need to configure IPv6 on the PE router interfaces to the CE routers and on the CE router interfaces to the PE routers.

To configure the interface to handle IPv6 routes, include the family inet6 statement:

You can include this statement at the following hierarchy levels:

  • [edit interfaces interface-name unit unit-number]

  • [edit logical-systems logical-system-name interfaces interface-name unit unit-number]

Note:

The [edit logical-systems] hierarchy level is not applicable in ACX Series routers.

If you have configured the Layer 3 VPN to handle both IPv4 and IPv6 routes, configure the interface to handle both IPv4 and IPv6 routes by including the unit statement:

You can include this statement at the following hierarchy levels:

  • [edit interfaces interface-name]

  • [edit logical-systems logical-system-name interfaces interface-name]

Note:

The [edit logical-systems] hierarchy level is not applicable in ACX Series routers.

Example: Tunneling Layer 3 VPN IPv6 Islands over an IPv4 Core Using IBGP and Independent Domains

This example shows how to configure Junos OS to tunnel IPv6 over a Layer 3 VPN IPv4 network. Internal BGP (IBGP) is used between the customer edge (CE) and provider edge (PE) devices, as described in Internet draft draft-marques-ppvpn-ibgp-version.txt, RFC2547bis networks using internal BGP as PE-CE protocol, instead of the more typical external BGP (EBGP) PE-CE connections.

Requirements

No special configuration beyond device initialization is required before you configure this example.

All PE routers participating in a Layer 3 VPN with the independent-domain statement in its configuration must be running Junos OS Release 6.3 or later.

Overview

This example shows one method of enabling a router to participate in a customer VPN autonomous-system (AS) domain and to transparently exchange routing information through a Layer 3 VPN without the customer network attributes being visible to the carrier network, and without the carrier network attributes being visible to the customer network.

As an added requirement, the customer network in this example is based on IPv6, while the provider network uses IPv4.

The independent-domain feature is useful when customer route attributes need to be transparently forwarded across the VPN network without even the service-provider (SP) AS path appearing in the routes. In a typical Layer 3 VPN, the route attributes such as the originator ID, cluster list, route metric, and AS path are not transparent from one CE device to another CE device.

For example, suppose you have a customer VRF whose AS is 1. The customer advertises routes to you through BGP (either IBGP or EBGP). Your core network (the primary routing instance) uses AS 3. Without independent-domain configured, if the customer advertises 10.0.0.0/24 to you through BGP, the prefix contains the customer’s AS 1 in the AS path. To transport the advertisement across the core to the other PE devices, your core AS 3 is added to the AS path by multiprotocol BGP (MP-BGP). The AS path is now 3 1. When the prefix is advertised out of the core back into the Layer 3 VPN at a remote PE device, the Layer 3 VPN AS 1 is added again, making the AS Path 1 3 1, which is an AS loop. The independent-domain statement ensures that only the ASs in the routing-instance are checked during loop detection, and the main, primary routing instances (your core’s AS 3) is not considered. This is done by using the attribute 128 (attribute set), which is an optional transitive attribute. The attribute set hides the route’s AS path, local preference, and so on, so that those do not appear during the loop check.

Note:

In Junos OS 10.4 and later, you can specify the no-attrset option of independent-domain so that instead of using attribute 128 (attribute set), Junos OS simply does loop checking on routing-instance ASs without considering your core’s AS used in MP-BGP. This is useful if you are using the local-as feature, and you only want to configure independent domains to maintain the independence of local ASs in the routing instance, and perform BGP loop detection only for the specified local ASs in the routing instance. In this case, you can disable the attribute set message.

Topology

Figure 5 shows the sample network.

Figure 1: Layer 3 VPN IPv6 Islands over an IPv4 Core Using IBGP and Independent DomainsLayer 3 VPN IPv6 Islands over an IPv4 Core Using IBGP and Independent Domains

CLI Quick Configuration shows the configuration for all of the devices in Figure 5.

The section Configuring Device PE1 describes the steps on Device PE1.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Device CE1

Device CE2

Device PE1

Device P

Device PE2

Configuring Device PE1

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Device PE1:

  1. Configure the interfaces.

  2. Configure MPLS on the interfaces.

  3. Configure BGP.

  4. Configure an interior gateway protocol (IGP).

  5. Configure a signaling protocol.

  6. Configure the routing instance.

  7. In the routing instance, include the AS number of the customer network, and include the independent-domain statement.

  8. In the main instance, configure the router ID and the provider AS number.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show routing-instances, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying That the CE Devices Have Connectivity

Purpose

Make sure that the tunnel is operating.

Action

From operational mode, enter the ping command.

Meaning

The IPv6 CE devices can communicate over the core IPv4 network.

Checking the AS Paths

Purpose

Make sure that the provider AS number does not appear in the CE device routing tables.

Action

From operational mode, enter the show route protocol bgp detail command.

Meaning

The output shows that for the BGP routes on the CE devices, the AS path attribute does not include the provider AS 64512.