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: 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. |
The configuration for the VPLS routing instance statements is explained in the following sections:
- Configuring BGP Signaling for VPLS
- Configuring LDP Signaling for VPLS
- Configuring VPLS Routing Instance and VPLS Interface Connectivity
- Configuring the VPLS Encapsulation Type
- Configuring the VPLS MAC Table Timeout Interval
- Configuring the Size of the VPLS MAC Address Table
- Limiting the Number of MAC Addresses Learned from an Interface
- Removing Addresses from the MAC Address Database
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. |
Configure BGP signaling for the VPLS routing instance by completing the steps in the following sections:
- Configuring the VPLS Site Name and Site Identifier
- Configuring Automatic Site Identifiers for VPLS
- Configuring the Site Range
- Configuring the VPLS Site Interfaces
- Configuring the VPLS Site Preference
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. 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]
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]
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
All the Layer 2 circuits you configure for a VPLS site are listed as a set of logical interfaces within the VPLS site configuration.
To configure a logical 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 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
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]
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]
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]
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 Junos OS MPLS Applications Configuration 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]
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 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 MX Series routers. |
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.
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]
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.
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:
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.
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]
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]
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.
