Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Example: Configuring VPLS over GRE with IPSec VPNs

Requirements

Before you begin:

• Ensure that a layer 3 network is in place for all branch offices and that there is a 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 branch devices to securely transport Ethernet traffic over Layer 3 networks when used in conjunction with IPsec.

In this scenario you configure a central office 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 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 branch 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

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

When configuring the central office SRX650, the first thing you do is terminate the IPsec tunnels, GRE, and CCC connections. Because a branch SRX Series device is used as the 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 Head-End Configuration with an SRX Series Device

You can also use an MX Series device as the central office 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 routince instance as shown in Figure 4.

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

Configuration

In this example, we use SRX devices and the branch and 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
• Configuring the SRX650 Device at the Central Office

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

Step-by-Step Procedure

1. Configure a GRE tunnel to the central office.
   [edit interfaces]user@host# set gr-0/0/0 description "GRE tunnel to SRX650”user@host# set gr-0/0/0 unit 0 clear-dont-fragment-bit user@host# set gr-0/0/0 unit 0 tunnel source 10.1.1.2 user@host# set gr-0/0/0 unit 0 tunnel destination 10.1.1.1 user@host# set gr-0/0/0 unit 0 tunnel allow-fragmentation user@host# set gr-0/0/0 unit 0 family inet mtu 2000 user@host# set gr-0/0/0 unit 0 family inet filter input inet-packet-mode user@host# set gr-0/0/0 unit 0 family mpls mtu 1900 user@host# set gr-0/0/0 unit 0 family mpls filter input mpls-packet-mode
2. Create a logical interface that connects to the default routing instance.
   [edit interfaces]user@host# set lt-0/0/0 unit 0 encapsulation frame-relay user@host# set lt-0/0/0 unit 0 dlci 16 user@host# set lt-0/0/0 unit 0 peer-unit 1 user@host# set lt-0/0/0 unit 0 family inet user@host# set lt-0/0/0 unit 0 description "Flow-vr Instance"
3. Connect the logical tunnel interface to the flow mode virtual router.
   [edit interfaces]user@host# set lt-0/0/0 unit 1 encapsulation frame-relay user@host# set lt-0/0/0 unit 1 dlci 16 user@host# set lt-0/0/0 unit 1 peer-unit 0 user@host# set lt-0/0/0 unit 1 family inet filter input inet-packet-mode user@host# set lt-0/0/0 unit 1 family inet address 10.1.1.2/32
4. Connect the CCC interface to the branch LAN.
   [edit interfaces]user@host# set ge-0/0/1 encapsulation ethernet-ccc user@host# set ge-0/0/1 unit 0 description "CCC Interface to customer LAN" user@host# set ge-0/0/1 unit 0 family ccc filter input ccc-packet-mode
5. Configure the interface bound to the default virtual router.
   [edit interfaces]user@host# set ge-0/0/0 unit 0 family inet address 172.19.101.45/24
6. Set the loopback interface to terminate the CCC connection.
   [edit interfaces]user@host# set lo0 unit 0 family inet address 10.2.1.2/32
7. Bind the IPsec tunnel interface to the flow-mode virtual router.
   [edit interfaces]user@host# set st0 unit 0 family inet
8. Set a static route address, which will be the default gateway to the Internet.
   [edit routing-options]user@host# set static route 0.0.0.0/0 next-hop 172.19.101.1
9. Set a static route for the remote GRE tunnel endpoint.
   [edit routing-options]user@host# set static route 10.1.1.1/32 next-hop lt-0/0/0.1
10. Set a static route for the loopback interface of the SRX650 head-end device.
    [edit routing-options]user@host# set static route 10.2.1.1/32 next-hop gr-0/0/0.0
11. Configure MPLS and the CCC using LDP as the label protocol.
    [edit]user@host# set routing-options router-id 10.2.1.2 user@host# set protocols mpls interface gr-0/0/0.0 user@host# set protocols ldp interface gr-0/0/0.0 user@host# set protocols ldp interface lo0.0 user@host# set protocols l2circuit neighbor 10.2.1.1 interface ge-0/0/1.0 virtual-circuit-id 1
12. Configure the IPsec tunnel.

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

    [edit security]user@host# set ike policy SRX650 mode main user@host# set ike policy SRX650 proposal-set standard user@host# set ike policy SRX650 pre-shared-key ascii-text "$9$awGjqTz6uORmfORhSMWJGD" user@host# set ike gateway SRX650 ike-policy SRX650 user@host# set ike gateway SRX650 address 172.19.101.26 user@host# set ike gateway SRX650 external-interface ge-0/0/0.0 user@host# set ipsec policy SRX650 proposal-set standard user@host# set ipsec vpn SRX650 bind-interface st0.0 user@host# set ipsec vpn SRX650 ike gateway SRX650 user@host# set ipsec vpn SRX650 ike ipsec-policy SRX650 user@host# set ipsec vpn SRX650 establish-tunnels immediately
13. Configure security zones.

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

    [edit security]user@host# set zones security-zone untrust host-inbound-traffic system-services all user@host# set zones security-zone untrust host-inbound-traffic protocols all user@host# set zones security-zone untrust interfaces gr-0/0/0.0 user@host# set zones security-zone untrust interfaces lo0.0 user@host# set zones security-zone untrust interfaces lt-0/0/0.1 user@host# set zones security-zone untrust interfaces ge-0/0/0.0 user@host# set zones security-zone vpn host-inbound-traffic system-services all user@host# set zones security-zone vpn host-inbound-traffic protocols all user@host# set zones security-zone vpn interfaces st0.0 user@host# set zones security-zone trust-flow host-inbound-traffic system-services all user@host# set zones security-zone trust-flow host-inbound-traffic protocols all user@host# set zones security-zone trust-flow interfaces lt-0/0/0.0
14. Configure IDP.
    [edit security]user@host# set policies from-zone trust-flow to-zone vpn policy gre match source-address any user@host# set policies from-zone trust-flow to-zone vpn policy gre match destination-address any user@host# set policies from-zone trust-flow to-zone vpn policy gre match application junos-gre user@host# set policies from-zone trust-flow to-zone vpn policy gre then permit application-services idp user@host# set idp idp-policy gre-reassembly rulebase-ips rule match-all match application junos-gre user@host# set idp idp-policy gre-reassembly rulebase-ips rule match-all then action ignore-connection user@host# set idp active-policy gre-reassembly
15. Configure packet-mode filters.
    [edit firewall]user@host# set family inet filter inet-packet-mode term control-traffic from protocol tcp user@host# set family inet filter inet-packet-mode term control-traffic from port 22 user@host# set family inet filter inet-packet-mode term control-traffic from port 80 user@host# set family inet filter inet-packet-mode term control-traffic from port 8080 user@host# set family inet filter inet-packet-mode term control-traffic then accept user@host# set family inet filter inet-packet-mode term packet-mode then packet-mode user@host# set family inet filter inet-packet-mode term packet-mode then accept user@host# set family mpls filter mpls-packet-mode term packet-mode then packet-mode user@host# set family mpls filter mpls-packet-mode term packet-mode then accept user@host# set family ccc filter ccc-packet-mode term all then packet-mode user@host# set family ccc filter ccc-packet-mode term all then accept
16. Configure the flow-mode virtual router.
    [edit routing-instances]]user@host# set flow-vr instance-type virtual-routeruser@host# set flow-vr interface lt-0/0/0.0user@host# set flow-vr interface st0.0 user@host# set flow-vr routing-options static route 10.1.1.1/32 next-hop st0.0user@host# set flow-vr routing-options static route 10.1.1.2/32 next-hop lt-0/0/0.0

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

Step-by-Step Procedure

1. Configure the interface bound to the default virtual router.
   [edit interfaces]user@host# set ge-0/0/0 unit 0 family inet address 172.19.101.26/24
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 branch device (SRX240).

   [edit interfaces]user@host# set gr-0/0/0 unit 0 clear-dont-fragment-bituser@host# set gr-0/0/0 unit 0 tunnel source 10.1.1.1user@host# set gr-0/0/0 unit 0 tunnel destination 10.1.1.2user@host# set gr-0/0/0 unit 0 tunnel allow-fragmentationuser@host# set gr-0/0/0 unit 0 family inet mtu 1500user@host# set gr-0/0/0 unit 0 family inet filter input inet-packet-modeuser@host# set gr-0/0/0 unit 0 family mpls filter input mpls-packet-mode
3. Configure a logical tunnel interface to stitch the CCC connection to the VPLS instance.
   [edit interfaces]user@host# set lt-0/0/0 unit 0 description "VPLS hub port - Interconnect for CCC to SRX240"user@host# set lt-0/0/0 unit 0 encapsulation ethernet-vplsuser@host# set lt-0/0/0 unit 0 peer-unit 1000
4. Set unit 1000 to terminate the CCC connection.
   [edit interfaces]user@host# set lt-0/0/0 unit 1000 description "Stitch to VPLS for CCC to SRX240"user@host# set lt-0/0/0 unit 1000 encapsulation ethernet-cccuser@host# set lt-0/0/0 unit 1000 peer-unit 0user@host# set lt-0/0/0 unit 1000 family ccc filter input ccc-packet-mode
5. Configure the logical tunnel interface.
   [edit interfaces]user@host# set lt-0/0/0 unit 2000 encapsulation frame-relayuser@host# set lt-0/0/0 unit 2000 dlci 1user@host# set lt-0/0/0 unit 2000 peer-unit 2001user@host# set lt-0/0/0 unit 2000 family inet
6. Bind the logical tunnel interface to the default virtual router.
   [edit interfaces]user@host# set lt-0/0/0 unit 2001 encapsulation frame-relayuser@host# set lt-0/0/0 unit 2001 dlci 1user@host# set lt-0/0/0 unit 2001 peer-unit 2000user@host# set lt-0/0/0 unit 2001 family inet filter input inet-packet-modeuser@host# set lt-0/0/0 unit 2001 family inet address 10.1.1.1/32
7. Set the interface to the central office LAN network.
   [edit interfaces]user@host# set ge-0/0/1 unit 0user@host# set ge-0/0/1 encapsulation ethernet-vpls
8. Set the loopback interface to terminate the CCC connections to each branch device.
   [edit interfaces]user@host# set lo0 unit 0 family inet address 10.2.1.1/32
9. Bind the IPsec interface to the flow-mode virtual router.
   [edit interfaces]user@host# set st0 unit 0 family inet
10. Set a static route for the remote GRE tunnel endpoint.
    [edit routing-options]user@host# set static route 10.1.1.2/32 next-hop lt-0/0/0.2001
11. Set a static route for the loopback interface of the branch device.
    [edit]user@host# set routing-options static route 10.2.1.2/32 next-hop gr-0/0/0.0
12. Configure MPLS and CCC using LDP as the label protocol.
    [edit protocols]user@host# set mpls interface gr-0/0/0.0user@host# set ldp interface gr-0/0/0.0user@host# set ldp interface lo0.0user@host# set l2circuit neighbor 10.2.1.2 interface lt-0/0/0.1000 virtual-circuit-id 1
13. Configure the IPsec tunnel.

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

    [edit security]user@host# set ike policy SRX mode mainuser@host# set ike policy SRX proposal-set standarduser@host# set ike policy SRX pre-shared-key ascii-text "$9$yhxeMXVwgUjq7-jqmfn6rev"user@host# set ike gateway SRX240-1 ike-policy SRXuser@host# set ike gateway SRX240-1 address 172.19.101.45user@host# set ike gateway SRX240-1 external-interface ge-0/0/0.0user@host# set ipsec policy SRX proposal-set standarduser@host# set ipsec vpn SRX240-1 bind-interface st0.0user@host# set ipsec vpn SRX240-1 ike gateway SRX240-1user@host# set ipsec vpn SRX240-1 ike ipsec-policy SRXuser@host# set ipsec vpn SRX240-1 establish-tunnels immediately
14. Configure security zones.

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

    [edit security]user@host# set zones security-zone untrust host-inbound-traffic system-services alluser@host# set zones security-zone untrust host-inbound-traffic protocols alluser@host# set zones security-zone untrust interfaces lo0.0user@host# set zones security-zone untrust interfaces lt-0/0/0.2001user@host# set zones security-zone untrust interfaces gr-0/0/0.0user@host# set zones security-zone untrust interfaces ge-0/0/0.0user@host# set zones security-zone vpn host-inbound-traffic system-services alluser@host# set zones security-zone vpn host-inbound-traffic protocols alluser@host# set zones security-zone vpn interfaces st0.0user@host# set zones security-zone trust-flow host-inbound-traffic system-services alluser@host# set zones security-zone trust-flow host-inbound-traffic protocols alluser@host# set zones security-zone trust-flow interfaces lt-0/0/0.2000
15. Configure IDP.
    [edit security]user@host# set policies from-zone trust-flow to-zone vpn policy GRE match source-address anyuser@host# set policies from-zone trust-flow to-zone vpn policy GRE match destination-address anyuser@host# set policies from-zone trust-flow to-zone vpn policy GRE match application junos-greuser@host# set policies from-zone trust-flow to-zone vpn policy GRE then permit application-services idpuser@host# set policies from-zone vpn to-zone trust-flow policy GRE match source-address anyuser@host# set policies from-zone vpn to-zone trust-flow policy GRE match destination-address anyuser@host# set policies from-zone vpn to-zone trust-flow policy GRE match application junos-greuser@host# set policies from-zone vpn to-zone trust-flow policy GRE then permit application-services idpuser@host# set idp idp-policy gre-reassembly rulebase-ips rule match-gre match application junos-greuser@host# set idp idp-policy gre-reassembly rulebase-ips rule match-gre then action ignore-connectionuser@host# set idp active-policy gre-reassembly
16. Configure packet-mode filters.
    [edit firewall]user@host# set family inet filter inet-packet-mode term control-traffic from protocol tcpuser@host# set family inet filter inet-packet-mode term control-traffic from port 22user@host# set family inet filter inet-packet-mode term control-traffic from port 80user@host# set family inet filter inet-packet-mode term control-traffic from port 8080user@host# set family inet filter inet-packet-mode term control-traffic then acceptuser@host# set family inet filter inet-packet-mode term packet-mode then packet-modeuser@host# set family inet filter inet-packet-mode term packet-mode then acceptuser@host# set family mpls filter mpls-packet-mode term packet-mode then packet-modeuser@host# set family mpls filter mpls-packet-mode term packet-mode then acceptuser@host# set family ccc filter ccc-packet-mode term all then packet-modeuser@host#set family ccc filter ccc-packet-mode term all then accept
17. Configure the flow-mode virtual router.
    [edit routing-instances]user@host# set flow-vr instance-type virtual-routeruser@host# set flow-vr interface lt-0/0/0.2000user@host# set flow-vr interface st0.0user@host# set flow-vr routing-options static route 10.1.1.1/32 next-hop lt-0/0/0.2000user@host# set flow-vr routing-options static route 10.1.1.2/32 next-hop st0.0
18. Configure the VPLS instance.
    [edit routing-instances]user@host# set vpls-hub instance-type vplsuser@host# set vpls-hub interface lt-0/0/0.0user@host# set vpls-hub interface ge-0/0/1.0

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
• Verifying an IPsec tunnel
• Verifying GRE
• Verifying the CCC/L2 circuit.
• Verifying that LDP sessions are working.

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.