Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Example: Configuring VPLS over GRE with IPsec VPNs

 

This example demonstrates a network scenario consisting of a central office and one branch office that will use VPLS, MPLS, GRE, and IPsec to create secure Ethernet connectivity over a Layer 3 network. This configuration can be expanded to add many other branch sites.

Requirements

Before you begin:

  • Ensure that a layer 3 network is in place for all branch offices and that there is an ingress (head-end) device at the central office configured to terminate the VPNs from each branch office.

  • Obtain IDP licenses for each SRX Series device. IDP is used to reassemble GRE packets that might become fragmented.

Overview

Junos OS can selectively choose whether traffic is processed by the flow engine or packet engine using the selective stateless packet-based feature. This feature allows you to combine flow and packet-based services in a single device. In this example, we describe a deployment scenario that uses this feature to deploy large-scale VPLS over GRE. This enables SRX devices to securely transport Ethernet traffic over Layer 3 networks when used in conjunction with IPsec.

In this scenario you configure a central office ingress (head-end) using an SRX650 device and one branch office using an SRX240 device. This setup is accomplished by carrying MPLS pseudowires over GRE, which in turn, is encapsulated in IPsec in order to guarantee data integrity and confidentiality. By default, SRX Series devices use secure flow forwarding. Because VPLS services are provided in packet-mode only, the configuration requires the GRE tunnel to be terminated in a packet-mode routing instance (the default routing instance).

Note

You can also use an MX Series device as the ingress (head-end) device, which is mentioned later in this topic.

To better understand this configuration, we will discuss two scenarios. The first scenario uses pseudowires to allow the creation of point-to-point circuits between two endpoints carried over the MPLS network. If we leave the signaling protocols aside (that is, there are a few ways to provision the pseudowires), these connections are just point-to-point connections. Using this approach provides an end-to-end wire between sites. This is beneficial from a traffic processing point of view because the gateways do not need to do MAC address learning, they simply forward anything they receive to the pseudowire. Because of this, it may be difficult to deploy this setup when trying to provide connectivity to multiple branch offices.

The second scenario could use VPLS to provide a Layer 2 network abstraction. With VPLS, endpoints are expected to negotiate LSPs and pseudowires with every other endpoint (that is, they are fully meshed). When a node receives an Ethernet frame from one of its LAN interfaces the source MAC address is learned, if it’s not already known, and flooded using every pseudowire connecting to all other branch nodes. However, if the destination has been previously learned, then the frame is sent to the appropriate destination. When an Ethernet frame is received through one of the pseudowires (that is, from the MPLS network), source MAC address learning is performed. The next time a frame is sent to that MAC it does not need to be flooded and the frame is flooded to every single LAN interface in the node, but not over the pseudowires. In other words, the network acts as a distributed Layer 2 switch providing any-to-any Ethernet connectivity between the devices connected to the different nodes in the network.

While the advantages of this second scenario is evident (any-to-any connectivity, automated provisioning, and simple abstraction), it comes at the cost of complexity. Every PE node has to perform Layer 2 learning and flooding of traffic, which can cause problems when either multiple broadcast/multicast or frames to unknown MAC addresses are used. As an example, if you had a topology with a thousand branch offices, each office that receives a broadcast packet must replicate it 999 times, encapsulate each copy in GRE and IPsec and forward the resulting traffic. Additionally, because each node performs Layer 2 learning, there are limitations in the maximum number of MAC addresses that each node can learn, limiting the total number of nodes in the domain.

In this example, we use a hybrid approach to these two scenarios. We use a circuit cross connect (CCC) at each branch office stitched to a VPLS instance at central office (ingress). This solution makes sense if most of the traffic flows from the branch offices to central office, and the branch-to-branch office traffic is always forwarded through the hub. The use of CCCs at branch offices combined with VPLS stitching at the central office provides a scalable way to deploy large hub-and-spoke topologies where Ethernet must be transported over an IP network (with or without encryption). At the expense of configuration complexity, it is possible to use SRX Series devices to terminate such connections, providing a scalable and cost-effective way to deploy small-to-large networks where Ethernet traffic is carried transparently using lower cost IP connections. Figure 1 shows this topology.

Figure 1: VPLS Deployment Scenario
VPLS Deployment Scenario

In this deployment, VPLS services are provided only in packet mode and must be configured in the default routing instance. Unfortunately, IPsec is only provided in flow mode. Hence, a flow-mode routing-instance is used that provides both GRE reassembly and IPsec termination. While the GRE termination is done in the default routing instance, a flow-mode routing instance is connected between the default routing instance and the Internet (or whatever Layer 3 network is used as a transport), and it terminates the IPsec tunnel towards the ingress device. Because it is likely that a single public IP address is available, the Internet-facing Interface is connected to the default routing instance and is used to terminate IKE; however, the tunnel interface (st0) is bound to the flow-mode routing instance. See Figure 2.

Figure 2: Branch Office Circuit Cross Connect Termination
Branch Office Circuit Cross
Connect Termination

When configuring the central office SRX650, the first thing you do is terminate the IPsec tunnels, GRE, and CCC connections. Because a SRX Series device is used as the ingress (head-end), the configuration to terminate the CCC circuits is identical to the one used at each branch office, with the exception that instead of one tunnel, multiple tunnels (and pseudowires) are terminated.

The pseudowires are stitched to a VPLS routing instance using logical tunnel (lt) interfaces. It is possible to use an lt interface unit to terminate a CCC connection and connect this unit to a different unit that is part of a VPLS routing instance. The overall result is as if the pseudowires were terminated directly in the VPLS routing instance. Figure 3 illustrates this configuration.

Figure 3: Central Office Ingress (Head-End) Configuration with an SRX Series Device
 Central Office Ingress (Head-End)
Configuration with an SRX Series Device

You can also use an MX Series device as the central office ingress (head-end) to terminate all branch office connections. The differences in the configuration are due to the way IPsec is configured and the fact that on MX Series devices IDP is not required to reassemble the GRE packets; MX Series devices natively support GRE reassembly. With this configuration, you still use lt interfaces to stitch the CCCs between the remote branch offices and the VPLS routing instance as shown in Figure 4.

Figure 4: Central Office Ingress (Head-End) Configuration with an MX Series Device
Central Office Ingress (Head-End)
Configuration with an MX Series Device

Configuration

In this example, we use SRX Series devices and the branch and ingress (head-end) sites will typically be connected to the Internet by Frame-Relay/T1-E1/xDSL/T3/E3 or even Ethernet. A provider MPLS network is not required.

Configuring the SRX240 Device at the Branch Office

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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode.

To configure the SRX240 at the branch office:

  1. Configure a GRE tunnel to the central office.
  2. Create a logical interface that connects to the default routing instance.
  3. Connect the logical tunnel interface to the flow mode virtual router.
  4. Connect the CCC interface to the branch LAN.
  5. Configure the interface bound to the default virtual router.
  6. Set the loopback interface to terminate the CCC connection.
  7. Bind the IPsec tunnel interface to the flow-mode virtual router.
  8. Set a static route address, which will be the default gateway to the Internet.
  9. Set a static route for the remote GRE tunnel endpoint.
  10. Set a static route for the loopback interface of the SRX650 ingress (head-end) device.
  11. Configure MPLS and the CCC using LDP as the label protocol.
  12. Configure the IPsec tunnel.Note

    The underlying IKE interface is not in the same routing instance as the tunnel interface.

  13. Configure security zones.Note

    In a production environment, host-inbound traffic should be restricted to only allow the necessary protocols and services.

  14. Configure IDP.
  15. Configure packet-mode filters.
  16. Configure the flow-mode virtual router.
  17. Disable syn check and sequence check to bypass LDP session from syn check and sequence check.
  18. Enable syn check and sequence check at the policy level.

Results

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

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

Configuring the SRX650 Device at the Central Office

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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode.

To configure the ingress (head-end) SRX650 device at the central office:

  1. Configure the interface bound to the default virtual router.
  2. Create the GRE tunnel from the SRX650 to the SRX240 device. Note

    As the network expands to include multiple branch offices, you will need to add a similar GRE tunnel configuration on the SRX650 device (head-end) along with a corresponding IPsec configuration to connect to each additional SRX device (SRX240).

  3. Configure a logical tunnel interface to stitch the CCC connection to the VPLS instance.
  4. Set unit 1000 to terminate the CCC connection.
  5. Configure the logical tunnel interface.
  6. Bind the logical tunnel interface to the default virtual router.
  7. Set the interface to the central office LAN network.
  8. Set the loopback interface to terminate the CCC connections to each SRX device.
  9. Bind the IPsec interface to the flow-mode virtual router.
  10. Set a static route for the remote GRE tunnel endpoint.
  11. Set a static route for the loopback interface of the SRX device.
  12. Configure MPLS and CCC using LDP as the label protocol.
  13. Configure the IPsec tunnel.Note

    The underlying IKE interface is not in the same routing instance as the tunnel interface.

  14. Configure security zones.Note

    In a production environment, restrict host-inbound traffic to only the necessary protocols and services.

  15. Configure IDP.
  16. Configure packet-mode filters.
  17. Configure the flow-mode virtual router.
  18. Configure the VPLS instance.
  19. Disable syn check and sequence check to bypass LDP session from syn check and sequence check.
  20. Enable syn check and sequence check at the policy level.

Results

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

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

Verification

Confirm that the configuration is working properly.

Verifying Interfaces

Purpose

Verify that the interfaces are configured properly on each device in the VPLS network.

Action

From configuration mode, enter show interfaces and verify that the IP addressing is correct for each interface, including logical tunnel (lt), loopback (lo), GRE (gr), IPsec tunnel st0, and GE interfaces.

Verifying an IPsec tunnel

Purpose

Verify that an IPsec tunnel is working.

Action

From operational mode, enter the show security ipsec security associations and the show security ipsec statistics command.

Verifying GRE

Purpose

Verify that GRE is working.

Action

From operational mode, enter the show security flow session protocol gre command. You can also do a ping between loopback addresses.

Verifying the CCC/L2 circuit.

Purpose

Verify that the CCC/L2 circuit is working.

Action

From operational mode, enter the show connections command.

Verifying that LDP sessions are working.

Purpose

Verify that LDP sessions are being created between devices.

Action

From operational mode, enter the show interfaces gr-0/0/0 detail command.