- 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
- Configuring BGP Route Target Filtering for VPNs
- Example: BGP Route Target Filtering for VPNs
- Example: Configuring BGP Route Target Filtering for VPNs
- Configuring Static Route Target Filtering for VPNs
- Understanding Proxy BGP Route Target Filtering for VPNs
- Example: Configuring Proxy BGP Route Target Filtering for VPNs
- Example: Configuring an Export Policy for BGP Route Target Filtering for VPNs
- Reducing Network Resource Use with Static Route Target Filtering for VPNs
- play_arrow Configuring Forwarding Options for VPNs
- play_arrow Configuring Graceful Restart for VPNs
- play_arrow Configuring Class of Service for VPNs
- play_arrow Pinging VPNs
-
- play_arrow Configuring Group VPNs
- play_arrow Configuring Public Key Infrastructure
- play_arrow Configuring Digital Certificate Validation
- play_arrow Configuring a Device for Certificate Chains
- play_arrow Managing Certificate Revocation
-
- play_arrow Configuring Layer 2 Circuits
- play_arrow 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
- play_arrow Configuring Protection Features for Layer 2 Circuits
- Egress Protection LSPs for Layer 2 Circuits
- Configuring Egress Protection Service Mirroring for BGP Signaled Layer 2 Services
- Example: Configuring an Egress Protection LSP for a Layer 2 Circuit
- Example: Configuring Layer 2 Circuit Protect Interfaces
- Example: Configuring Layer 2 Circuit Switching Protection
- play_arrow Monitoring Layer 2 Circuits with BFD
- play_arrow Troubleshooting Layer 2 Circuits
-
- play_arrow Configuring VPWS VPNs
- play_arrow Overview
- play_arrow Configuring VPWS VPNs
- Understanding FEC 129 BGP Autodiscovery for VPWS
- Example: Configuring FEC 129 BGP Autodiscovery for VPWS
- Example: Configuring MPLS Egress Protection Service Mirroring for BGP Signaled Layer 2 Services
- Understanding Multisegment Pseudowire for FEC 129
- Example: Configuring a Multisegment Pseudowire
- Configuring the FAT Flow Label for FEC 128 VPWS Pseudowires for Load-Balancing MPLS Traffic
- Configuring the FAT Flow Label for FEC 129 VPWS Pseudowires for Load-Balancing MPLS Traffic
-
- play_arrow Configuring VPLS
- play_arrow Overview
- play_arrow VPLS Configuration Overview
- play_arrow Configuring Signaling Protocols for VPLS
- VPLS Routing and Virtual Ports
- BGP Signaling for VPLS PE Routers Overview
- Control Word for BGP VPLS Overview
- Configuring a Control Word for BGP VPLS
- BGP Route Reflectors for VPLS
- Interoperability Between BGP Signaling and LDP Signaling in VPLS
- Configuring Interoperability Between BGP Signaling and LDP Signaling in VPLS
- Example: VPLS Configuration (BGP Signaling)
- Example: VPLS Configuration (BGP and LDP Interworking)
- play_arrow Assigning Routing Instances to VPLS
- Configuring VPLS Routing Instances
- Configuring a VPLS Routing Instance
- Support of Inner VLAN List and Inner VLAN Range for Qualified BUM Pruning on a Dual-Tagged Interface for a VPLS Routing Instance Overview
- Configuring Qualified BUM Pruning for a Dual-Tagged Interface with Inner VLAN list and InnerVLAN range for a VPLS Routing Instance
- Configuring a Layer 2 Control Protocol Routing Instance
- PE Router Mesh Groups for VPLS Routing Instances
- Configuring VPLS Fast Reroute Priority
- Specifying the VT Interfaces Used by VPLS Routing Instances
- Understanding PIM Snooping for VPLS
- Example: Configuring PIM Snooping for VPLS
- VPLS Label Blocks Operation
- Configuring the Label Block Size for VPLS
- Example: Building a VPLS From Router 1 to Router 3 to Validate Label Blocks
- play_arrow Associating Interfaces with VPLS
- play_arrow Configuring Pseudowires
- Configuring Static Pseudowires for VPLS
- VPLS Path Selection Process for PE Routers
- BGP and VPLS Path Selection for Multihomed PE Routers
- Dynamic Profiles for VPLS Pseudowires
- Use Cases for Dynamic Profiles for VPLS Pseudowires
- Example: Configuring VPLS Pseudowires with Dynamic Profiles—Basic Solutions
- Example: Configuring VPLS Pseudowires with Dynamic Profiles—Complex Solutions
- Configuring the FAT Flow Label for FEC 128 VPLS Pseudowires for Load-Balancing MPLS Traffic
- Configuring the FAT Flow Label for FEC 129 VPLS Pseudowires for Load-Balancing MPLS Traffic
- Example: Configuring H-VPLS BGP-Based and LDP-Based VPLS Interoperation
- Example: Configuring BGP-Based H-VPLS Using Different Mesh Groups for Each Spoke Router
- Example: Configuring LDP-Based H-VPLS Using a Single Mesh Group to Terminate the Layer 2 Circuits
- Example: Configuring H-VPLS With VLANs
- Example: Configuring H-VPLS Without VLANs
- Configure Hot-Standby Pseudowire Redundancy in H-VPLS
- Sample Scenario of H-VPLS on ACX Series Routers for IPTV Services
- play_arrow Configuring Multihoming
- VPLS Multihoming Overview
- Advantages of Using Autodiscovery for VPLS Multihoming
- Example: Configuring FEC 129 BGP Autodiscovery for VPWS
- Example: Configuring BGP Autodiscovery for LDP VPLS
- Example: Configuring BGP Autodiscovery for LDP VPLS with User-Defined Mesh Groups
- VPLS Multihoming Reactions to Network Failures
- Configuring VPLS Multihoming
- Example: VPLS Multihoming, Improved Convergence Time
- Example: Configuring VPLS Multihoming (FEC 129)
- Next-Generation VPLS for Multicast with Multihoming Overview
- Example: Next-Generation VPLS for Multicast with Multihoming
- play_arrow Configuring Point-to-Multipoint LSPs
- play_arrow Configuring Inter-AS VPLS and IRB VPLS
- play_arrow Configuring Load Balancing and Performance
- Configuring VPLS Load Balancing
- Configuring VPLS Load Balancing Based on IP and MPLS Information
- Configuring VPLS Load Balancing on MX Series 5G Universal Routing Platforms
- Example: Configuring Loop Prevention in VPLS Network Due to MAC Moves
- Understanding MAC Pinning
- Configuring MAC Pinning on Access Interfaces for Bridge Domains
- Configuring MAC Pinning on Trunk Interfaces for Bridge Domains
- Configuring MAC Pinning on Access Interfaces for Bridge Domains in a Virtual Switch
- Configuring MAC Pinning on Trunk Interfaces for Bridge Domains in a Virtual Switch
- Configuring MAC Pinning for All Pseudowires of the VPLS Routing Instance (LDP and BGP)
- Configuring MAC Pinning on VPLS CE Interface
- Configuring MAC Pinning for All Pseudowires of the VPLS Site in a BGP-Based VPLS Routing Instance
- Configuring MAC Pinning on All Pseudowires of a Specific Neighbor of LDP-Based VPLS Routing Instance
- Configuring MAC Pinning on Access Interfaces for Logical Systems
- Configuring MAC Pinning on Trunk Interfaces for Logical Systems
- Configuring MAC Pinning on Access Interfaces in Virtual Switches for Logical Systems
- Configuring MAC Pinning on Trunk Interfaces in Virtual Switches for Logical Systems
- Configuring MAC Pinning for All Pseudowires of the VPLS Routing Instance (LDP and BGP) for Logical Systems
- Configuring MAC Pinning on VPLS CE Interface for Logical Systems
- Configuring MAC Pinning for All Pseudowires of the VPLS Site in a BGP-Based VPLS Routing Instance for Logical Systems
- Configuring MAC Pinning on All Pseudowires of a Specific Neighbor of LDP-Based VPLS Routing Instance for Logical Systems
- Example: Prevention of Loops in Bridge Domains by Enabling the MAC Pinnning Feature on Access Interfaces
- Example: Prevention of Loops in Bridge Domains by Enabling the MAC Pinnning Feature on Trunk Interfaces
- Configuring Improved VPLS MAC Address Learning on T4000 Routers with Type 5 FPCs
- Understanding Qualified MAC Learning
- Qualified Learning VPLS Routing Instance Behavior
- Configuring Qualified MAC Learning
- play_arrow Configuring Class of Service and Firewall Filters in VPLS
- play_arrow Monitoring and Tracing 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
- Using the Layer 2 Interworking Interface to Interconnect a Layer 2 Circuit to a Layer 2 VPN
- Applications for Interconnecting a Layer 2 Circuit with a Layer 2 Circuit
- Example: Interconnecting a Layer 2 Circuit with a Layer 2 VPN
- Example: Interconnecting a Layer 2 Circuit with a Layer 2 Circuit
- Applications for Interconnecting a Layer 2 Circuit with a Layer 3 VPN
- Example: Interconnecting a Layer 2 Circuit with a Layer 3 VPN
-
- play_arrow Configuration Statements and Operational Commands
Understanding BGP Path Selection
For each prefix in the routing table, the routing protocol process selects a single best path. After the best path is selected, the route is installed in the routing table. The best path becomes the active route if the same prefix is not learned by a protocol with a lower (more preferred) global preference value, also known as the administrative distance. The algorithm for determining the active route is as follows:
Verify that the next hop can be resolved.
Choose the path with the lowest preference value (routing protocol process preference).
Routes that are not eligible to be used for forwarding (for example, because they were rejected by routing policy or because a next hop is inaccessible) have a preference of –1 and are never chosen.
Prefer the path with higher local preference.
For non-BGP paths, choose the path with the lowest preference2 value.
If the accumulated interior gateway protocol (AIGP) attribute is enabled, add the IGP metric and prefer the path with the lower AIGP attribute.
Prefer the path with the shortest autonomous system (AS) path value (skipped if the
as-path-ignore
statement is configured).A confederation segment (sequence or set) has a path length of 0. An AS set has a path length of 1.
Prefer the route with the lower origin code.
Routes learned from an IGP have a lower origin code than those learned from an exterior gateway protocol (EGP), and both have lower origin codes than incomplete routes (routes whose origin is unknown).
Prefer the path with the lowest multiple exit discriminator (MED) metric.
Depending on whether nondeterministic routing table path selection behavior is configured, there are two possible cases:
If nondeterministic routing table path selection behavior is not configured (that is, if the
path-selection cisco-nondeterministic
statement is not included in the BGP configuration), for paths with the same neighboring AS numbers at the front of the AS path, prefer the path with the lowest MED metric. To always compare MEDs whether or not the peer ASs of the compared routes are the same, include thepath-selection always-compare-med
statement.If nondeterministic routing table path selection behavior is configured (that is, the
path-selection cisco-nondeterministic
statement is included in the BGP configuration), prefer the path with the lowest MED metric.
Confederations are not considered when determining neighboring ASs. A missing MED metric is treated as if a MED were present but zero.
Note:MED comparison works for single path selection within an AS (when the route does not include an AS path), though this usage Is uncommon.
By default, only the MEDs of routes that have the same peer autonomous systems (ASs) are compared. You can configure routing table path selection options to obtain different behaviors.
Prefer strictly internal paths, which include IGP routes and locally generated routes (static, direct, local, and so forth).
Prefer strictly external BGP (EBGP) paths over external paths learned through internal BGP (IBGP) sessions.
Prefer the path whose next hop is resolved through the IGP route with the lowest metric. BGP routes that are resolved through IGP are preferred over unreachable or rejected routes.
Note:A path is considered a BGP equal-cost path (and will be used for forwarding) if a tie-break is performed after the previous step. All paths with the same neighboring AS, learned by a multipath-enabled BGP neighbor, are considered.
BGP multipath does not apply to paths that share the same MED-plus-IGP cost yet differ in IGP cost. Multipath path selection is based on the IGP cost metric, even if two paths have the same MED-plus-IGP cost.
If both paths are external, prefer the oldest path, in other words, the path that was learned first. This is done to minimize route-flapping. This rule is not used if any one of the following conditions is true:
path-selection external-router-id is configured.
Both peers have the same router ID.
Either peer is a confederation peer.
Neither path is the current active path.
Prefer a primary route over a secondary route. A primary route is one that belongs to the routing table. A secondary route is one that is added to the routing table through an export policy.
Prefer the path from the peer with the lowest router ID. For any path with an originator ID attribute, substitute the originator ID for the router ID during router ID comparison.
Prefer the path with the shortest cluster list length. The length is 0 for no list.
Prefer the path from the peer with the lowest peer IP address.
Routing Table Path Selection
The shortest AS path step of the algorithm, by default, evaluates the length of the AS path and determines the active path. You can configure an option that enables Junos OS to skip this step of the algorithm by including the as-path-ignore option.
Starting with Junos OS Release 14.1R8, 14.2R7, 15.1R4, 15.1F6, and 16.1R1, the as-path-ignore option is supported for routing instances.
The routing process path selection takes place before BGP hands
off the path to the routing table to makes its decision. To configure
routing table path selection behavior, include the path-selection
statement:
path-selection { (always-compare-med | cisco-non-deterministic | external-router-id); as-path-ignore; l2vpn-use-bgp-rules; med-plus-igp { igp-multiplier number; med-multiplier number; } }
For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.
Routing table path selection can be configured in one of the following ways:
Emulate the Cisco IOS default behavior (cisco-non-deterministic). This mode evaluates routes in the order that they are received and does not group them according to their neighboring AS. With
cisco-non-deterministic
mode, the active path is always first. All inactive, but eligible, paths follow the active path and are maintained in the order in which they were received, with the most recent path first. Ineligible paths remain at the end of the list.As an example, suppose you have three path advertisements for the 192.168.1.0 /24 route:
Path 1—learned through EBGP; AS Path of 65010; MED of 200
Path 2—learned through IBGP; AS Path of 65020; MED of 150; IGP cost of 5
Path 3—learned through IBGP; AS Path of 65010; MED of 100; IGP cost of 10
These advertisements are received in quick succession, within a second, in the order listed. Path 3 is received most recently, so the routing device compares it against path 2, the next most recent advertisement. The cost to the IBGP peer is better for path 2, so the routing device eliminates path 3 from contention. When comparing paths 1 and 2, the routing device prefers path 1 because it is received from an EBGP peer. This allows the routing device to install path 1 as the active path for the route.
Note:We do not recommend using this configuration option in your network. It is provided solely for interoperability to allow all routing devices in the network to make consistent route selections.
Always comparing MEDs whether or not the peer ASs of the compared routes are the same (always-compare-med).
Override the rule that If both paths are external, the currently active path is preferred (external-router-id). Continue with the next step (Step 12) in the path-selection process.
Adding the IGP cost to the next-hop destination to the MED value before comparing MED values for path selection (
med-plus-igp
).BGP multipath does not apply to paths that share the same MED-plus-IGP cost, yet differ in IGP cost. Multipath path selection is based on the IGP cost metric, even if two paths have the same MED-plus-IGP cost.
BGP Table path selection
The following parameters are followed for BGP's path selection:
Prefer the highest local-preference value.
Prefer the shortest AS-path length.
Prefer the lowest origin value.
Prefer the lowest MED value.
Prefer routes learned from an EBGP peer over an IBGP peer.
Prefer best exit from AS.
For EBGP-received routes, prefer the current active route.
Prefer routes from the peer with the lowest Router ID.
Prefer paths with the shortest cluster length.
Prefer routes from the peer with the lowest peer IP address. Steps 2, 6 and 12 are the RPD criteria.
Effects of Advertising Multiple Paths to a Destination
BGP advertises only the active path, unless you configure BGP to advertise multiple paths to a destination.
Suppose a routing device has in its routing table four paths to a destination and is configured to advertise up to three paths (add-path send path-count 3). The three paths are chosen based on path selection criteria. That is, the three best paths are chosen in path-selection order. The best path is the active path. This path is removed from consideration and a new best path is chosen. This process is repeated until the specified number of paths is reached.
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.