Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Configuring VPLS Routing Instances

To configure a VPLS routing instance, include the vpls statement:

You can include this statement at the following hierarchy levels:

  • [edit routing-instances routing-instance-name protocols]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name protocols]

    Note:

    ACX Series routers do not support the [edit logical-systems] hierarchy.

Note:

You cannot configure a routing protocol (OSPF, RIP, IS-IS or BGP) inside a VPLS routing instance (instance-type vpls). The Junos CLI disallows this configuration.

Note:

Starting in Junos OS Release 16.1, you can use the import-labeled-routes statement to specify one or more nondefault routing instances where you want MPLS pseudowire labeled routes to be leaked from the mpls.0 path routing table in the primary routing instance.

The configuration for the VPLS routing instance statements is explained in the following sections:

Configuring BGP Signaling for VPLS

You can configure BGP signaling for the VPLS routing instance. BGP is used to signal the pseudowires linking each of the PE routers participating in the VPLS routing instance. The pseudowires carry VPLS traffic across the service provider's network between the VPLS sites.

Note:

You cannot configure both BGP signaling and LDP signaling for the same VPLS routing instance. If you attempt to configure the statements that enable BGP signaling for the VPLS routing instance (the site, site-identifier, and site-range statements) and the statements that enable LDP signaling for the same instance (the neighbor and vpls-id statements), the commit operation fails.

Note:

In the VPLS documentation, the word router in terms such as PE router is used to refer to any device that provides routing functions.

Configure BGP signaling for the VPLS routing instance by completing the steps in the following sections:

Configuring the VPLS Site Name and Site Identifier

When you configure BGP signaling for the VPLS routing instance, on each PE router you must configure each VPLS site that has a connection to the PE router. All the Layer 2 circuits provisioned for a VPLS site are listed as the set of logical interfaces (using the interface statement) within the site statement.

You must configure a site name and site identifier for each VPLS site.

To configure the site name and the site identifier, include the site and the site-identifier statements:

The numerical identifier can be any number from 1 through 65,534 that uniquely identifies the local VPLS site.

You can include these statements at the following hierarchy levels:

  • [edit routing-instances routing-instance-name protocols vpls]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls]

Configuring Automatic Site Identifiers for VPLS

When you enable automatic site identifiers, the Junos OS automatically assigns site identifiers to VPLS sites. Only one site is allowed per routing instances when using the automatic-side-id function. To configure automatic site identifiers for a VPLS routing instance, include the automatic-site-id statement:

You can include this statement at the following hierarchy levels:

  • [edit routing-instances routing-instance-name protocols vpls site site-name]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls site site-name]

Note:

ACX Series routers do not support the [edit logical-systems] hierarchy.

The automatic-site-id statement includes a number of options that control different delays in network layer reachability information (NLRI) advertisements. All of these options are configured with default values. See the statement summary for the automatic-site-id statement for more information.

The automatic-site-id statement includes the following options:

  • collision-detect-time—The time in seconds to wait after a claim advertisement is sent to the other routers in a VPLS instance before a PE router can begin using a site identifier. If the PE router receives a competing claim advertisement for the same site identifier during this time period, it initiates the collision resolution procedure for site identifiers.

  • new-site-wait-time—The time in seconds to wait to receive VPLS information for a newly configured routing instance or a new site. This time interval is also applied whenever the automatic site identifier feature is activated on a VPLS routing instance other than at startup. Effectively, this timer indicates how long to wait before an attempt is made to allocate a site identifier. This timer is also triggered whenever a VPLS routing instance is enabled.

  • reclaim-wait-time—The time to wait before attempting to claim a site identifier after a collision. A collision occurs whenever an attempt is made to claim a site identifier by two separate VPLS sites.

  • startup-wait-time—The time in seconds to wait at startup to receive all the VPLS information for the route targets configured on the other PE routers included in the VPLS routing instance.

Configuring the Site Range

When you enable BGP signaling for each VPLS routing instance, you can optionally configure the site range. The site range specifies an upper limit on the maximum site identifier that can be accepted to allow a pseudowire to be brought up. You must specify a value from 1 through 65,534. The default value is 65,534. We recommend using the default. Pseudowires cannot be established to sites with site identifiers greater than the configured site range. If you issue the show vpls connections command, such sites are displayed as OR (out of range).

To configure the site range, include the site-range statement:

You can include this statement at the following hierarchy levels:

  • [edit routing-instances routing-instance-name protocols vpls]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls]

Note:

ACX Series routers do not support the [edit logical-systems] hierarchy.

There are networks that require that the site range be configured using a value smaller than the local site identifier, for example, a hub-and-spoke VPLS with multihomed sites. For this type of network, you need to allow pseudowires to be established between the spoke routers and the hub router. However, you also need to prevent pseudowires from being established between spoke routers directly. Due to the multihoming requirement of spoke sites, Layer 2 VPN NRLIs need to be accepted from other spoke routers (at least from spokes with the same site identifier as the locally configured sites) to determine the status of local spoke routers (active or not active) based on the local preference included in the NRLIs received from the other spoke routers.

This type of VPLS network can be implemented by, for example, numbering hub sites with identifiers 1 through 8 and spoke sites with identifiers 9 and larger. You can then configure a site range of 8 on each of the spoke sites. Although the spoke sites accept NRLIs and install them in the Layer 2 VPN routing tables (allowing the multihomed sites to determine the status of the local site), the spoke sites cannot establish pseudowires directly to the other spoke sites due to the configured site range.

The following configurations illustrate this concept. The configurations are for the VPLS routing instances on three routers, two spoke routers and one hub router:

Router 1—spoke:

Router 2—spoke:

Hub—router 3:

Configuring the VPLS Site Interfaces

You must configure an interface for each of the pseudowires you specify for the VPLS site.

To configure an interface for the VPLS site, include the interface statement:

You can include these statements at the following hierarchy levels:

  • [edit routing-instances routing-instance-name protocols vpls site site-name]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls]

You can also configure a limit on the number of MAC addresses that can be learned from the specified interface. For more information, see Limiting the Number of MAC Addresses Learned from an Interface.

Configuring the VPLS Site Preference

You can specify the local preference value advertised for a particular VPLS site. The site preference value is specified using the site-preference statement configured at the [edit routing-instances routing-instance-name protocols vpls site site-name] hierarchy level. By configuring the site-preference statement, a value configured for the local-preference statement at the [edit protocols bgp] hierarchy level is ignored by the VPLS routing instance. However, you can change the site preference value for VPLS routes exported to other routers by configuring an export policy. When a PE router receives multiple advertisements with the same VPLS edge (VE) device identifier, the advertisement with the highest local preference value is preferred.

To configure the VPLS site preference, include the site-preference statement:

You can also specify either the backup option or the primary option for the site-preference statement. The backup option specifies the preference value as 1, the lowest possible value, ensuring that the VPLS site is the least likely to be selected. The primary option specifies the preference value as 65,535, the highest possible value, ensuring that the VPLS site is the most likely to be selected.

For a list of hierarchy levels at which you can include the site-preference statement, see the statement summary section for this statement.

Configuring LDP Signaling for VPLS

You can configure LDP as the signaling protocol for a VPLS routing instance. This functionality is described in RFC 4762, Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling.

The Junos OS software does not support all of RFC 4762. When enabling LDP signaling for a VPLS routing instance, network engineers should be aware that only the following values are supported:

  • FEC—128 or 129

  • Control bit—0

  • Ethernet pseudowire type—0x0005

  • Ethernet tagged mode pseudowire type—0x0004

LDP signaled VPLS supports the Virtual Circuit Connectivity Verification (VCCV) Type Length Value (TLV) for pseudowire label mapping, label database display, and LDP trace. When you enable LDP signaling for a pseudowire, LDP advertises the VCCV capabilities to the neighboring routers. VCCV provides a control channel for a pseudowire and includes both operations and management functions (for example, connectivity verification). This control channel is established between the pseudowire's ingress and egress devices. Once established, connectivity verification messages can be sent over the VCCV control channel.

The Junos OS software supports the following VCCV capabilities for LDP signaled VPLS (defined in RFC 5085 Section 8.1):

  • VCCV connectivity check types:

    • Router Alert Label

    • MPLS pseudowire label with TTL=1

  • VCCV connectivity verification type:

    • LSP ping

If the peer device also advertises VCCV parameters during pseudowire setup, the Junos OS software selects the set of common advertised parameters to use as the method for performing VCCV OAM on the pseudowire.

The locally advertised and peer advertised VCCV parameters can be viewed using the show ldp database command as show here:

Be aware of the following behavior with regard to TLVs when configuring LDP-signaled VPLS in a network with equipment from other vendors:

  • When a Juniper Network’s device receives a TLV with an empty address, LDP accepts the TLV.

  • When a MAC address is withdrawn, LDP specifies a zero address (0.0.0.0) for the AddressList.

To enable LDP signaling for the set of PE routers participating in the same VPLS routing instance, you need to use the vpls-id statement configured at the [edit routing-instances routing-instance-name protocols vpls] hierarchy level to configure the same VPLS identifier on each of the PE routers. The VPLS identifier must be globally unique. When each VPLS routing instance (domain) has a unique VPLS identifier, it is possible to configure multiple VPLS routing instances between a given pair of PE routers.

LDP signaling requires that you configure a full-mesh LDP session between the PE routers in the same VPLS routing instance. Neighboring PE routers are statically configured. Tunnels are created between the neighboring PE routers to aggregate traffic from one PE router to another. Pseudowires are then signaled to demultiplex traffic between VPLS routing instances. These PE routers exchange the pseudowire label, the MPLS label that acts as the VPLS pseudowire demultiplexer field, by using LDP forwarding equivalence classes (FECs). Tunnels based on both MPLS and generic routing encapsulation (GRE) are supported.

Note:

You cannot configure both BGP signaling and LDP signaling for the same VPLS routing instance. If you attempt to configure the statements that enable BGP signaling for the VPLS routing instance (the site, site-identifier, and site-range statements), and the statements that enable LDP signaling for the same instance, neighbor and vpls-id, the commit operation fails.

To enable LDP signaling for the VPLS routing instance, complete the steps in the following sections:

Configuring LDP Signaling for the VPLS Routing Instance

To configure the VPLS routing instance to use LDP signaling, you must configure the same VPLS identifier on each PE router participating in the instance. Specify the VPLS identifier with the vpls-id statement:

You can include this statement at the following hierarchy levels:

  • [edit routing-instances routing-instance-name protocols vpls]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls]

Note:

ACX Series routers do not support the [edit logical-systems] hierarchy.

To configure the VPLS routing instance to use LDP signaling, you also must include the neighbor statement to specify each of the neighboring PE routers that are a part of this VPLS domain:

You can include this statement at the following hierarchy levels:

  • [edit routing-instances routing-instance-name protocols vpls]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls]

Note:

ACX Series routers do not support the [edit logical-systems] hierarchy.

Configuring LDP Signaling on the Router

To enable LDP signaling, you need to configure LDP on each PE router participating in the VPLS routing instance. A minimal configuration is to enable LDP on the loopback interface, which includes the router identifier (router-id), on the PE router using the interface statement:

You can include this statement at the following hierarchy levels:

  • [edit protocols ldp]

  • [edit logical-systems logical-system-name protocols ldp]

Note:

ACX Series routers do not support the [edit logical-systems] hierarchy.

You can enable LDP on all the interfaces on the router using the all option for the interfaces statement. For more information about how to configure LDP, see the MPLS Applications User Guide.

Configuring VPLS Routing Instance and VPLS Interface Connectivity

You can configure the VPLS routing instance to take down or maintain its VPLS connections depending on the status of the interfaces configured for the VPLS routing instance. By default, the VPLS connection is taken down whenever a customer-facing interface configured for the VPLS routing instance fails. This behavior can be explicitly configured by specifying the ce option for the connectivity-type statement:

You can alternatively specify that the VPLS connection remain up so long as an Integrated Routing and Bridging (IRB) interface is configured for the VPLS routing instance by specifying the irb option for the connectivity-type statement:

To ensure that the VPLS connection remain up until explicitly taken down, specify the permanent option for the connectivity-type statement:

This option is reserved for use in configuring Layer 2 Wholesale subscriber networks. See the Broadband Subscriber Management Solutions Guide for details about configuring a Layer 2 Wholesale network.

You can include this statement at the following hierarchy levels:

  • [edit routing-instances routing-instance-name protocols vpls]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls]

Note:

ACX Series routers do not support the [edit logical-systems] hierarchy.

ACX Series routers do not support irb interface in VPLS instance, therefore connectivity-type irb for VPLS is not supported.

Configuring the VPLS Encapsulation Type

You can specify a VPLS encapsulation type for the pseudowires established between VPLS neighbors. The encapsulation type is carried in the LDP-signaling messages exchanged between VPLS neighbors when pseudowires are created. You might need to alter the encapsulation type depending on what other vendors’ equipment is deployed within your network.

VPLS effectively provides a bridge between Ethernet networks. As a consequence, only two encapsulation types are available:

  • ethernet—Ethernet

  • ethernet-vlan—Ethernet virtual LAN (VLAN)

If you do not specify an encapsulation type for the VPLS routing instance or the VPLS neighbor, ethernet is used.

To specify an encapsulation type for the VPLS routing instance, include the encapsulation-type statement:

You can include this statement at the following hierarchy levels:

  • [edit routing-instances routing-instance-name protocols vpls]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls]

You can also specify an encapsulation type for a specific VPLS neighbor by including the encapsulation-type statement at the following hierarchy levels:

  • [edit routing-instances routing-instance-name protocols vpls neighbor address]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls neighbor address]

Configuring the MPLS Routing Table to Leak Routes a Nondefault Routing Instance

Starting in Junos OS Release 16.1, you can specify one or more nondefault routing instances where you want MPLS routes to be leaked from the mpls.0 path routing table in the primary routing instance. This capability is useful in an L2VPN/VPLS configuration when the remote PE router is learned from the IGP in a nondefault routing instance, because L2VPN/VPLS installs ingress-labeled routes only in the primary mpls.0 table.

By default, routes in the mpls.0 routing table in the primary routing instance are not leaked to the corresponding routing tables in nondefault routing instances. When L2VPN/VPLS traffic is received on the core-facing interface in a nondefault routing instance, the router performs a lookup in the table that corresponds to that interface, routing-instance-name.mpls.0. Because the routes are not leaked by default, then no routes are found in the routing-instance-name.mpls.0 routing table and all the incoming traffic is dropped.

To leak MPLS routes to a nondefault routing instance, include the import-labeled-routes statement and specify one or more routing instances where the routes need to be leaked:

You can include this statement at the following hierarchy levels:

  • [edit routing-instances routing-instance-name protocols vpls]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls]

Configuring the VPLS MAC Table Timeout Interval

You can modify the timeout interval for the VPLS table. We recommend you that configure longer values for small, stable VPLS networks and shorter values for large, dynamic VPLS networks. If the VPLS table does not receive any updates during the timeout interval, the router waits one additional interval before automatically clearing the MAC address entries from the VPLS table.

To modify the timeout interval for the VPLS table, include the mac-table-aging-time statement:

You can include this statement at the following hierarchy levels:

  • [edit routing-instances routing-instance-name protocols vpls]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls]

Note:

The mac-table-aging-time statement is not available on ACX Series and MX Series routers.

Note:

ACX Series routers do not support the [edit logical-systems] hierarchy.

Configuring the Size of the VPLS MAC Address Table

You can modify the size of the VPLS media access control (MAC) address table. The default table size is 512 MAC addresses, the minimum is 16 addresses, and the maximum is 65,536 addresses.

Note:

T4000 routers with Type 5 FPCs support up to 262,143 MAC addresses per VPLS routing instance. To enable the improved VPLS MAC address learning limit (that is, 262,143 MAC addresses), you must Include the enhanced-mode statement at the [edit chassis network-services] hierarchy level, reboot the router, and then modify the size of the VPLS MAC address table.

If the MAC table limit is reached, new MAC addresses can no longer be added to the table. Eventually the oldest MAC addresses are removed from the MAC address table automatically. This frees space in the table, allowing new entries to be added. However, as long as the table is full, new MAC addresses are dropped.

To change the VPLS MAC table size for each VPLS or VPN routing instance, include the mac-table-size statement:

You can include this statement at the following hierarchy levels:

  • [edit routing-instances routing-instance-name protocols vpls]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls]

Note:

ACX Series routers do not support the [edit logical-systems] hierarchy.

When you include the mac-table-size statement, the affected interfaces include all interfaces within the VPLS routing instance, including the local interfaces, the LSI interfaces, and the VT interfaces.

Note:

ACX Series routers do no support mac-table-size statement for VPLS.

Limiting the Number of MAC Addresses Learned from an Interface

You can configure a limit on the number of MAC addresses learned by a VPLS routing instance using the mac-table-size statement. If the MAC table limit is reached, new MAC addresses can no longer be added to the table. Eventually the oldest MAC addresses are removed from the MAC address table automatically. This frees space in the table, allowing new entries to be added. However, as long as the table is full, new MAC addresses are dropped.

Because this limit applies to each VPLS routing instance, the MAC addresses of a single interface can consume all the available space in the table, preventing the routing instance from acquiring addresses from other interfaces.

You can limit the number of MAC addresses learned from each interface configured for a VPLS routing instance. To do so, include the interface-mac-limit statement:

Note:

ACX Series routers do not support interface-mac-limit limit for VPLS.

You can include this statement at the following hierarchy levels:

  • [edit routing-instances routing-instance-name protocols vpls]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls]

The interface-mac-limit statement affects the local interfaces only (the interfaces facing CE devices).

Configuring the interface-mac-limit statement at the [edit routing-instances routing-instance-name protocols vpls] hierarchy level causes the same limit to be applied to all of the interfaces configured for that specific routing instance.

Note:

Starting in Junos OS Release 12.3R4, if you do not configure the parameter to limit the number of MAC addresses to be learned by a VPLS instance, the default value is not effective. Instead, if you do not include the interface-mac-limit option at the [edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls site site-name interfaces interface-name], hierarchy level, this setting is not present in the configuration with the default value of 1024 addresses. If you upgrade a router running a Junos OS release earlier than Release 12.3R4 to Release 12.3R4 or later, you must configure the interface-mac-limit option with a valid value for it to be saved in the configuration.

You can also limit the number of MAC addresses learned by a specific interface configured for a VPLS routing instance. This gives you the ability to limit particular interfaces that you expect might generate a lot of MAC addresses.

To limit the number of MAC addresses learned by a specific interface, include the interface-mac-limit statement at the following hierarchy levels:

  • [edit routing-instances routing-instance-name protocols vpls site site-name interfaces interface-name]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls site site-name interfaces interface-name]

Note:

ACX Series routers do not support the [edit logical-systems] hierarchy.

The MAC limit configured for an individual interface at this hierarchy level overrides any value configured at the [edit routing-instances routing-instance-name protocols vpls] hierarchy level. Also, the MAC limit configured using the mac-table-size statement can override the limit configured using the interface-mac-limit statement.

The MAC address limit applies to customer-facing interfaces only.

Removing Addresses from the MAC Address Database

You can enable MAC flush processing for the VPLS routing instance or for the mesh group under a VPLS routing instance. MAC flush processing removes MAC addresses from the MAC address database that have been learned dynamically. With the dynamically learned MAC addresses removed, MAC address convergence requires less time to complete.

You can clear dynamically learned MAC addresses from the MAC address database by including the mac-flush statement:

To clear dynamically learned MAC addresses globally across all devices participating in the routing instance, you can include the statement at the following hierarchy levels:

  • [edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls]

  • [edit routing-instances routing-instance-name protocols vpls]

To clear the MAC addresses on the routers in a specific mesh group, you can include the statement at the following hierarchy levels:

  • [edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls mesh-group mesh-group-name]

  • [edit routing-instances routing-instance-name protocols vpls mesh-group mesh-group-name]

Note:

On ACX Series routers, the mesh-group statement is supported only on ACX5000 line of routers. ACX5000 line of routers can support up to 8 user-defined mesh groups per VPLS routing instance.

Note:

ACX Series routers do not support the [edit logical-systems] hierarchy.

For certain cases where MAC flush processing is not initiated by default, you can also specify explicit-mac-flush-message-options to additionally configure the router to send explicit MAC flush messages under specific conditions. For a list of the explicit MAC flush message options you can include with this statement, see the summary section for this statement.

Related Documentation

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.

Release
Description
16.1
Starting in Junos OS Release 16.1, you can specify one or more nondefault routing instances where you want MPLS routes to be leaked from the mpls.0 path routing table in the primary routing instance.
12.3R4
Starting in Junos OS Release 12.3R4, if you do not configure the parameter to limit the number of MAC addresses to be learned by a VPLS instance, the default value is not effective.