Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Example: Transporting IPv6 Traffic Across IPv4 Using Filter-Based Tunneling

This example shows how to configure a unidirectional generic routing encapsulation (GRE) tunnel to transport IPv6 unicast transit traffic across an IPv4 transport network. To provide network connectivity to the two disjoint IPv6 networks, two MX Series 5G Universal Routing Platforms are configured with interfaces that can originate and understand both IPv4 and IPv6 packets. The configuration does not require the creation of tunnel interfaces on Tunnel Services physical interface cards (PICs) or on MPC3E Modular Port Concentrators (MPCs). Instead, you attach firewall filters to Ethernet logical interfaces hosted on Modular Interface Cards (MICs) or MPCs in the two MX Series routers.

Note:

Filter-based GRE tunneling is supported on PTX Series routers only when network services is set to enhanced-mode. For more information, see enhanced-mode.

Requirements

This example uses the following Juniper Networks hardware and Junos OS software:

  • Transport network—An IPv4 network running Junos OS Release 12.3R2 or later.

  • PE routers—Two MX80 routers installed as provider edge (PE) routers that connect the IPv4 network to two disjoint IPv6 networks that require a logical path from one network to the other.

  • Encapsulating interface—On the encapsulator (the ingress PE router), one Ethernet logical interface configured on the built-in 10-Gigabit Ethernet MIC.

  • De-encapsulating interfaces—On the de-encapsulator (the egress PE router), Ethernet logical interfaces configured on three ports of the built-in 10-Gigabit Ethernet MIC.

Before you begin configuring this example:

  1. On each PE router, use the show chassis fpc pic-status operational mode command to determine which router line cards support filter-based GRE IPv4 tunneling and then use the interfaces configuration statement to configure encapsulating and de-encapsulating interfaces.

    • At PE1, the encapsulator, configure one encapsulating interface on a supported line card.

    • At PE2, the de-encapsulator, configure three de-encapsulating interfaces on a supported line card.

  2. Check that IPv4 routing protocols are enabled across the network to support routing paths from the encapsulator to the de-encapsulator.

    Configure routing information by manually adding static routes to route tables or by configuring static or dynamic route-sharing protocols. For more information, see Transport and Internet Protocols User Guide.

  3. At PE1, ping the PE2 IPv4 loopback address to verify that the de-encapsulator is reachable from the encapsulator.

  4. At PE2, ping the CE2 router IPv6 loopback address to verify that the destination customer edge router is reachable from the de-encapsulator..

    IPv6 routing paths from PE2 to CE2 can be provided by static routes manually added to routing tables or by static or dynamic route-sharing protocols.

    • By default, PE2 forwards packets based on interface routes (direct routes) imported from the primary routing table.

    • As an option, the de-encapsulating filter can specify that the Packet Forwarding Engine uses an alternate routing table to forward payload packets to the destination customer network. In an optional configuration task in this example, you specify an alternate routing table by installing static routes from PE2 to C1 in the routing instance blue. You configure the routing information base (RIB) group blue_group to specify that the route information of inet6.0 is shared with blue.inet6.0, then you associate the PE2 interfaces with routes stored in both the default routes and the routing instance.

Overview

In this example you configure a unidirectional filter-based GRE IPv4 tunnel from Router PE1 to Router PE2, providing a logical path from IPv6 network C1 to IPv6 network C2.

Note:

To enable bidirectional filter-based GRE tunneling, you must configure a second tunnel in the reverse direction.

As an optional task in this example, you can create a RIB group, which specifies the sharing of routing information (including routes learned from peers, local routes resulting from the application of protocol policies to the learned routes, and the routes advertised to peers) of multiple routing tables.

Topology

Figure 1 shows the path of IPv6 traffic transported from network C1 to network C2, across an IPv4 transport network using a filter-based tunnel from PE1 to PE2 and without requiring tunnel interfaces.

Figure 1: Filter-Based Tunnel from PE1 to PE2 in an IPv4 NetworkFilter-Based Tunnel from PE1 to PE2 in an IPv4 Network

Table 1 summarizes the configuration of Router PE1 as the encapsulator. Table 2 summarizes the configuration of Router PE2 as the de-encapsulator.

Table 1: Encapsulator Components on PE1

Component

CLI Names

Description

 

 

 

 

Encapsulator

Device name:

IPv4 loopback:

IPv6 loopback:

PE1

10.255.1.1

2001:db8::1

MX80 router installed as an ingress PE router. PE1 connects the IPv4 network the customer edge router CE1 in the IPv6 source network C1.

Encapsulating interface

Interface name:

IPv4 address:

IPv6 address:

xe-0/0/0.0

10.0.1.10/30

::10.34.1.10/120

Customer-facing logical interface hosted on a 10-Gigabit Ethernet MIC. CE1 sends this interface IPv6 traffic that originates at end-user hosts and is destined for applications or hosts on the IPv6 destination network C2.

Encapsulation filter

Filter name:

gre_encap_1

IPv6 firewall filter whose action causes the Packet Forwarding Engine to encapsulate matched packets using the specified tunnel characteristics. Encapsulation consists of adding a GRE header, adding an IPv4 packet header, and then forwarding the resulting GRE packet through the GRE IPv4 tunnel.

Tunnel source interface

Interface name:

IPv4 address:

xe-0/0/2.0

10.0.1.12

Core-facing egress interface to the tunnel.

GRE tunnel template

Tunnel name:

tunnel_1

Defines the GRE IPv4 tunnel from Router PE1 (10.255.1.1) to Router PE2(10.255.2.2), using the tunneling protocol supported on IPv4 (gre).

Table 2: De-Encapsulator Components on PE2

Component

CLI Names

Description

 

 

 

De-encapsulator

Device name:

IPv4 loopback:

IPv6 loopback:

PE2

10.255.2.2

2001:fc3::2

MX80 router installed as an egress PE router to receive GRE packets forwarded from ingress router PE1 across a GRE IPv4 tunnel.

De-encapsulating interfaces

Interface name:

IPv4 address:

Interface name:

IPv4 address:

Interface name:

IPv4 address:

xe-0/0/0.0

10.0.2.24/30

xe-0/0/1.0

10.0.2.21/30

xe-0/0/2.0

10.0.2.22/30

Core-facing ingress logical interfaces hosted on 10-Gigabit Ethernet MICs. The interfaces receive GRE packets routed through the GRE IPv4 tunnel from PE1.

De-encapsulation filter

Filter name:

gre_decap_1

IPv4 firewall filter that applies the decapsulate action to GRE packets. The filter action causes the Packet Forwarding Engine to de-encapsulate matched packets.

De-encapsulation consists of removing the outer GRE header and then forwarding the inner IPv6 payload packet to its original destination on the destination IPv6 network by performing destination lookup on the default routing table.

Tunnel egress interface

Interface name:

IPv4 address:

IPv6 address:

xe-0/0/3.0

10.0.2.23/30

::20.34.2.23/120

Customer-facing interface though which the router forwards de-encapsulated IPv6 packets to the destination IPv6 network C2.

Configuration

To transport IPv6 packets from CE1 to CE2 across an IPv4 transport network using a filter-based tunnel from PE1 to PE2 and without configuring tunnel interfaces, perform these tasks:

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.

Configuring PE1 to Encapsulate IPv6 Packets

Configuring PE2 to De-Encapsulate GRE Packets

Optional: Configuring PE2 with an Alternate Routing Table

Configuring PE1 to Encapsulate IPv6 Packets

Step-by-Step Procedure

To configure Router PE1 to encapsulate IPv6 packets arriving from CE1:

  1. Configure the router loopback addresses.

  2. Configure the encapsulating interface IPv4 and IPv6 addresses and attach the encapsulating filter to the IPv6 input.

  3. Configure the core-facing egress interface to the tunnel.

  4. Define an IPv6 firewall filter that causes the Packet Forwarding Engine to encapsulate all packets.

    Note:

    The encapsulate firewall filter action is a terminating filter action. A filter-terminating action halts all evaluation of a firewall filter for a specific packet. The router performs the specified action, and no additional terms are examined.

  5. Define a GRE IPv4 tunnel template named tunnel_1 that specifies the host IP addresses of the one tunnel source interface and three tunnel destination interfaces.

    Note:

    You can tunnel multiple but distinct flows from 10.0.1.10 (the tunnel source interface on PE1) to 10.0.2.20 – 10.0.2.22 (the de-encapsulating interfaces on PE2) if you use the GRE option key number to uniquely identify each tunnel.

  6. If you are done configuring the device, commit the configuration.

Results

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

Router PE1

Confirm the firewall filter and tunnel template on the encapsulator.

Router PE1

Confirm the interfaces on the encapsulator.

Configuring PE2 to De-Encapsulate GRE Packets

Step-by-Step Procedure

To configure Router PE2 to de-encapsulate GRE packets arriving from the IPv4 tunnel:

  1. Configure the router loopback address.

  2. Configure the de-encapsulating interfaces.

  3. Configure the customer-facing egress interface to CE2.

  4. Apply the ingress de-encapsulating firewall filter to all forwarded packets.

  5. Define IPv4 filter gre_decap_1.

    Define an IPv4 filter that de-encapsulates and forwards all GRE packets.

  6. Configure term t1 to match packets transported across the tunnel tunnel_1 defined on Router PE1. The tunnel sends packets from Router PE1 (configured with IPv4 loopback address 10.255.1.1) to Router PE2 (configured with IPv4 loopback address 10.255.2.2).

  7. Configure term t1 to count and de-encapsulate matched packets.

    If the de-encapsulating filter action decapsulate references the blue routing instance, make sure that the routing instance is configured and that the RIB group blue_group defines the sharing of the alternate routes into the primary table.

  8. If you are done configuring the device, commit the configuration.

Results

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

Router PE2

Confirm the firewall filter on the de-encapsulator.

Note:

If the de-encapsulating filter action decapsulate references the blue routing instance, make sure that the routing instance is configured and that the RIB group blue_group defines the sharing of the alternate routes into the primary table.

Router PE2

Confirm the forwarding options (for attaching the de-encapsulating firewall filter to all input forwarded packets) on the de-encapsulator.

Router PE2

Confirm the interfaces on the de-encapsulator.

Optional: Configuring PE2 with an Alternate Routing Table

Step-by-Step Procedure

To configure Router PE2 with an alternate routing table:

  1. Configure the routing instance blue, and add static routes to CE2.

    The Junos OS software generates the routing table blue.inet6.0 using the routing information learned within the instance.

  2. Enable routes to remain in routing and forwarding tables, even if the routes become inactive. This allows a static route to remain in the table if the next hop is unavailable.

  3. Create a RIB group by explicitly creating the default routing table.

  4. Define the RIB group blue_group.

    In the import-rib statement, specify the primary routing table first.

  5. Associate the router interfaces with routing information specified by the RIB group.

  6. If you are done configuring the device, commit the configuration.

Results

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

Router PE2

If you configured an alternate routing table on Router PE2, confirm the routing instance configuration.

Router PE2

If you configured an alternate routing table on Router PE2, confirm the RIB group and direct routing configurations.

Verification

Confirm that the configurations are working properly.

Verifying Routing Information

Purpose

Verify that the direct routes include the alternate routing table information.

Action

To perform the verification:

  1. (Optional) To verify the routing instance blue on PE2, use the show route instance operational mode command to display the primary table and number of routes for that routing instance.

  2. (Optional) To view the routing table associated with the routing instance blue on PE2, use the show route table operational mode command

  3. (Optional) To verify that the alternate routes from routing instance blue have been imported to the PE2 forwarding table, use the show route forwarding-table operational mode command to display the contents of the router forwarding table and the routing instance forwarding table.

Verifying Encapsulation on PE1

Purpose

Verify the encapsulating interface on PE1.

Action

To perform the verification:

  1. Use the show interfaces filters operational mode command to verify that the encapsulating firewall filter is attached to the ingress of the encapsulating interface.

  2. Use the show interfaces operational mode command to verify that the encapsulating interface is receiving packets.

  3. Use the show firewall filter operational mode command to verify that ingress passenger protocol traffic triggers the encapsulating filter.

Meaning

If the encapsulating filter is attached to the encapsulating interface, and the encapsulating interface receives passenger protocol traffic, and the firewall filter statistics show that ingress passenger protocol traffic is being encapsulated, then GRE packets are being forwarded through the tunnel.

Verifying De-Encapsulation on PE2

Purpose

Verify the de-encapsulating interfaces on PE2.

Action

To perform the verification:

  1. On PE1, use the ping operational mode command to verify that PE2 is reachable.

  2. On PE2, use the show interfaces filter operational mode command to verify that the de-encapsulating firewall filter is attached to the ingress of the de-encapsulating interfaces.

  3. On PE2, use the show interfaces operational mode command to verify that the de-encapsulating interfaces are receiving packets.

    Depending on how routing is configured and which links are up and which links are down, some of the de-encapsulating interfaces might not be receiving packets although the tunnel is operating properly.

  4. On PE2, use the show firewall filter operational mode command to verify that ingress GRE traffic triggers the de-encapsulating filter.

Meaning

The verification confirms the following operational states and activities of the encapsulator:

  • PE2 is reachable from the PE1.

  • The de-encapsulating filter is attached to the input of all de-encapsulating interfaces.

  • The de-encapsulator is receiving traffic at de-encapsulating interfaces as expected.

  • GRE packets received at the de-encapsulating interfaces trigger the de-encapsulating firewall filter action.