close

keyboard_arrow_left

Table of Contents Expand all

play_arrow Common Configuration for All VPNs
- play_arrow VPNs Overview
- play_arrow Assigning Routing Instances to VPNs
- play_arrow Distributing Routes in VPNs
- play_arrow Distributing VPN Routes with Target Filtering
- play_arrow Configuring Forwarding Options for VPNs
  - Chained Composite Next Hops for VPNs and Layer 2 Circuits
  - Example: Configuring Chained Composite Next Hops for Direct PE-PE Connections in VPNs
- play_arrow Configuring Graceful Restart for VPNs
- play_arrow Configuring Class of Service for VPNs
  - VPNs and Class of Service
  - Rewriting Class of Service Markers and VPNs
- play_arrow Pinging VPNs
play_arrow Common Configuration for Layer 2 VPNs and VPLS
- play_arrow Overview
- play_arrow Layer 2 VPNs Configuration Overview
- play_arrow Configuring Layer 2 Interfaces
- play_arrow Configuring Path Selection for Layer 2 VPNs and VPLS
  - Understanding BGP Path Selection
  - Enabling BGP Path Selection for Layer 2 VPNs and VPLS
- play_arrow Creating Backup Connections with Redundant Pseudowires
  - Redundant Pseudowires for Layer 2 Circuits and VPLS
  - Configuring Redundant Pseudowires for Layer 2 Circuits and VPLS
- play_arrow Configuring Class of Service for Layer 2 VPNs
  - Configuring Traffic Policing in Layer 2 VPNs
- play_arrow Monitoring Layer 2 VPNs
play_arrow Configuring Group VPNs
- play_arrow Configuring Group VPNv2
play_arrow Configuring Public Key Infrastructure
- play_arrow Configuring Digital Certificate Validation
  - Understanding Digital Certificate Validation
  - Example: Improving Digital Certificate Validation by Configuring Policy OIDs on an MX Series Device
- play_arrow Configuring a Device for Certificate Chains
  - IKE Authentication (Certificate-Based Authentication)
  - Example: Configuring a Device for Peer Certificate Chain Validation
- play_arrow Managing Certificate Revocation
  - Online Certificate Status Protocol and Certificate Revocation Lists
  - Example: Improving Security by Configuring OCSP for Certificate Revocation Status
play_arrow Configuring Layer 2 Circuits
- play_arrow Overview
  - Layer 2 Circuit Overview
- play_arrow Layer 2 Circuits Configuration Overview
- play_arrow Configuring Class of Service with Layer 2 Circuits
- play_arrow Configuring Pseudowire Redundancy for Layer 2 Circuits
- play_arrow Configuring Load Balancing for Layer 2 Circuits
  - Reducing APS Switchover Time in Layer 2 Circuits
- play_arrow Configuring Protection Features for Layer 2 Circuits
- play_arrow Monitoring Layer 2 Circuits with BFD
  - Configuring BFD for VCCV for Layer 2 Circuits
  - Example: Configuring BFD for VCCV for Layer 2 Circuits
- play_arrow Troubleshooting Layer 2 Circuits
  - Tracing Layer 2 Circuit Operations
play_arrow Configuring VPWS VPNs
- play_arrow Overview
- play_arrow Configuring VPWS VPNs
play_arrow Configuring VPLS
play_arrow Connecting Layer 2 VPNs and Circuits to Other VPNs
- play_arrow Connecting Layer 2 VPNs to Other VPNs
- play_arrow Connecting Layer 2 Circuits to Other VPNs
play_arrow Configuration Statements and Operational Commands
- Junos CLI Reference Overview

list Table of Contents

English

Configuring Policies for Layer 2 Circuits

date_range 23-Nov-23

arrow_backward

arrow_forward

You can configure Junos routing policies to control the flow of packets over Layer 2 circuits. This capability allows you to provide different level of service over a set of equal-cost Layer 2 circuits. For example, you can configure a circuit for high-priority traffic, a circuit for average-priority traffic, and a circuit for low-priority traffic. By configuring Layer 2 circuit policies, you can ensure that higher-value traffic has a greater likelihood of reaching its destination.

The following sections explain how to configure Layer 2 circuit policies:

Configuring the Layer 2 Circuit Community

To configure a community for Layer 2 circuits, include the community statement.

community community-name {
    members [ community-ids ]; 
}

You can include this statement at the following hierarchy levels:

[edit policy-options]
[edit logical-systems logical-system-name policy-options]

name identifies the community or communities.

community-ids identifies the type of community or extended community:

A normal community uses the following community ID format:

as-number:community-value

as-number is the autonomous system (AS) number of the community member.

community-value is the identifier of the community member. It can be a number from 0 through 65,535.
An extended community uses the following community ID format:

type:administrator:assigned-number

type is the type of target community. The target community identifies the route’s destination.

administrator is either an AS number or an IP version 4 (IPv4) address prefix, depending on the type of community.

assigned-number identifies the local provider.

You also need to configure the community for the Layer 2 circuit interface; see Configuring a Community for the Layer 2 Circuit.

Configuring the Policy Statement for the Layer 2 Circuit Community

To configure a policy to send community traffic over a specific LSP, include the policy-statement statement:

policy-statement policy-name {
    term term-name {
        from community community-name;
        then {
            install-nexthop (except | lsp lsp-name | lsp-regex lsp-regular-expression);
            accept;
        }
    }
}

You can include this statement at the following hierarchy levels:

[edit policy-options]
[edit logical-systems logical-system-name policy-options]

To prevent the installation of any matching next hops, include the install-nexthop statement with the except option:

install-nexthop except;

You can include this statement at the following hierarchy levels:

[edit policy-options policy-statement policy-name term term-name then]
[edit logical-systems logical-system-name policy-options policy-statement policy-name term term-name then]

To assign traffic from a community to a specific LSP, include the install-nexthop statement with the lsp lsp-name option and the accept statement:

install-nexthop lsp lsp-name;
accept;

You can include these statements at the following hierarchy levels:

[edit policy-options policy-statement policy-name term term-name then]
[edit logical-systems logical-system-name policy-options policy-statement policy-name term term-name then]

You can also use a regular expression to select an LSP from a set of similarly named LSPs for the install-nexthop statement. To configure a regular expression, include the install-nexthop statement with the lsp-regex option and the accept statement:

install-nexthop lsp-regex lsp-regular-expression;
accept;

You can include these statements at the following hierarchy levels:

[edit policy-options policy-statement policy-name term term-name then]
[edit logical-systems logical-system-name policy-options policy-statement policy-name term term-name then]

Example: Configuring a Policy for a Layer 2 Circuit Community

The following example illustrates how you might configure a regular expression in a Layer 2 circuit policy. You create three LSPs to handle gold-tier traffic from a Layer 2 circuit. The LSPs are named alpha-gold, beta-gold, and delta-gold. You then include the install-nexthop statement with the lsp-regex option with the LSP regular expression .*-gold at the [edit policy-options policy-statement policy-name term term-name then] hierarchy level:

content_copy zoom_out_map
[edit policy-options]
policy-statement gold-traffic {
    term to-gold-LSPs {
        from community gold;
        then {
            install-nexthop lsp-regex .*-gold;
            accept;
        }
    }
}

The community gold Layer 2 circuits can now use any of the -gold LSPs. Given equal utilization across the three -gold LSPs, LSP selection is made at random.

You need to apply the policy to the forwarding table. To apply a policy to the forwarding table, configure the export statement at the [edit routing-options forwarding-table] hierarchy level:

content_copy zoom_out_map
[edit routing-options forwarding-table] 
export policy-name;

Verifying the Layer 2 Circuit Policy Configuration

To verify that you have configured a policy for the Layer 2 circuit, issue the show route table mpls detail command. It should display the community for ingress routes that corresponds to the Layer 2 circuits, as shown by the following example:

content_copy zoom_out_map
user@host> show route table mpls detail
so-1/0/1.0 (1 entry, 1 announced)
*L2VPN  Preference: 7
Next hop: via so-1/0/0.0 weight 1, selected
Label-switched-path to-community-gold
Label operation: Push 100000 Offset: -4
Next hop: via so-1/0/0.0 weight 1
Label-switched-path to-community-silver
Label operation: Push 100000 Offset: -4
Protocol next hop: 10.255.245.45
Push 100000 Offset: -4
Indirect next hop: 85333f0 314
State: <Active Int>
Local AS:   100 
Age: 22 
Task: Common L2 VC
Announcement bits (2): 0-KRT 1-Common L2 VC 
AS path: I
Communities: 100:1

For more information about how to configure routing policies, see Routing Policies, Firewall Filters, and Traffic Policers User Guide.

arrow_backward PREVIOUS Example: Configuring the Pseudowire Status TLV

NEXT arrow_forward Configuring LDP for Layer 2 Circuits

Layer 2 VPNs and VPLS User Guide for Routing Devices

ON THIS PAGE

Configuring Policies for Layer 2 Circuits

Configuring the Layer 2 Circuit Community

Configuring the Policy Statement for the Layer 2 Circuit Community

Example: Configuring a Policy for a Layer 2 Circuit Community

Verifying the Layer 2 Circuit Policy Configuration

Stay in touch

Helped me install or use the product
Accelerated my deployment

Discuss the product with a co-worker
Make a purchase inquiry